planowanie gry
planowanie XP rozwiązuje dwa kluczowe pytania w rozwoju oprogramowania: przewidywanie, co zostanie osiągnięte w terminie i określenie, co dalej. Nacisk kładzie się na kierowanie projektem – co jest dość proste-a nie na dokładne przewidywanie, co będzie potrzebne i jak długo potrwa – co jest dość trudne., Istnieją dwa kluczowe etapy planowania w XP, rozwiązujące te dwa pytania:
planowanie wydania jest praktyką, w której Klient przedstawia programistom pożądane funkcje, a programiści szacują ich trudność. Mając pod ręką kosztorysy i wiedzę o znaczeniu funkcji, Klient opracowuje plan projektu. Początkowe plany wydania gry są nieprecyzyjne: ani priorytety, ani szacunki nie są naprawdę solidne, a dopóki zespół nie zacznie pracować, nie będziemy wiedzieć, jak szybko pójdą., Jednak nawet pierwszy plan wydania jest wystarczająco dokładny do podejmowania decyzji, a zespoły ds. PD regularnie zmieniają plan wydania.
planowanie iteracji jest praktyką, w ramach której zespół co kilka tygodni otrzymuje wskazówki. Zespoły XP budują oprogramowanie w dwutygodniowych „iteracjach”, dostarczając użyteczne oprogramowanie na koniec każdej iteracji. Podczas planowania iteracji Klient przedstawia pożądane funkcje na najbliższe dwa tygodnie. Programiści dzielą je na zadania i szacują ich koszt (na dokładniejszym poziomie szczegółowości niż w planowaniu wydań)., Na podstawie ilości pracy wykonanej w poprzedniej iteracji, zespół zapisuje się na to, co zostanie wykonane w bieżącej iteracji.
te etapy planowania są bardzo proste, ale zapewniają bardzo dobre informacje i doskonałą kontrolę nad sterowaniem w rękach klienta. Co kilka tygodni ilość postępów jest całkowicie widoczna. Nie ma „dziewięćdziesiąt procent zrobione” w XP: fabuła została zakończona, lub nie było., To skupienie się na widoczności skutkuje małym paradoksem: z jednej strony, przy tak dużej widoczności, Klient jest w stanie anulować projekt, jeśli postępy nie są wystarczające. Z drugiej strony postęp jest tak widoczny, a możliwość decydowania, co będzie dalej, jest tak kompletna, że projekty XP zazwyczaj dostarczają więcej tego, co jest potrzebne, przy mniejszej presji i stresie.
testy klienta
w ramach prezentacji każdej pożądanej funkcji, klient XP definiuje jeden lub więcej automatycznych testów akceptacyjnych, aby pokazać, że funkcja działa., Zespół buduje te testy i wykorzystuje je, aby udowodnić sobie i klientowi, że funkcja jest poprawnie zaimplementowana. Automatyzacja jest ważna, ponieważ w prasie czasu, testy ręczne są pomijane. To jak wyłączanie świateł, gdy noc robi się najciemniejsza.
najlepsze zespoły XP traktują swoje testy klientów tak samo, jak testy programistów: po uruchomieniu testu zespół utrzymuje je poprawnie. Oznacza to, że system tylko poprawia się, zawsze nacinając do przodu, nigdy nie cofając się.,
Małe Wydania
zespoły XP ćwiczą małe wydania na dwa ważne sposoby:
Po pierwsze, zespół wydaje uruchomione, przetestowane oprogramowanie, dostarczając wartość biznesową wybraną przez Klienta, w każdej iteracji. Klient może korzystać z tego oprogramowania w dowolnym celu, niezależnie od tego, czy jest to ocena, czy nawet wydanie użytkownikom końcowym (wysoce zalecane). Najważniejszym aspektem jest to, że oprogramowanie jest widoczne i podane klientowi na końcu każdej iteracji. Dzięki temu wszystko jest otwarte i namacalne.
Po Drugie, zespoły XP często udostępniają swoim użytkownikom końcowym., XP web projects wypuszcza tak często jak codziennie, w house projects co miesiąc lub częściej. Nawet produkty owinięte w folię termokurczliwą są wysyłane tak często, jak co kwartał.
może się wydawać, że tworzenie dobrych wersji tak często jest niemożliwe, ale zespoły z całego świata robią to cały czas. Zobacz ciągła Integracja, aby dowiedzieć się więcej na ten temat, i zauważ, że te częste Wydania są niezawodne dzięki obsesji XP na punkcie testowania, jak opisano tutaj w testach klientów i Test-Driven Development.
Simple Design
zespoły XP budują oprogramowanie do prostego, ale zawsze odpowiedniego projektu., Zaczynają się one proste, a dzięki testom programistycznym i ulepszaniu projektu zachowują to w ten sposób. Zespół XP utrzymuje projekt dokładnie dostosowany do aktualnej funkcjonalności systemu. Nie ma zmarnowanego ruchu, a oprogramowanie jest zawsze gotowe na to, co dalej.
projektowanie W XP nie jest rzeczą jednorazową, ani z góry, jest rzeczą wszechczasów. Istnieją etapy projektowania w planowaniu wydań i planowaniu iteracji, a zespoły angażują się w szybkie sesje projektowe i zmiany projektu poprzez refaktoryzację w trakcie całego projektu., W procesie przyrostowym, iteracyjnym, takim jak programowanie Ekstremalne, dobry projekt jest niezbędny. Dlatego tak duży nacisk kładzie się na projektowanie w trakcie całego procesu rozwoju.
Programowanie par
Wszystkie programy produkcyjne w XP są budowane przez dwóch programistów, siedzących obok siebie, na tej samej maszynie. Ta praktyka zapewnia, że cały kod produkcyjny jest sprawdzany przez co najmniej jednego innego programistę i skutkuje lepszym projektowaniem, lepszym testowaniem i lepszym kodem.
może wydawać się nieefektywne mieć dwóch programistów wykonujących „pracę jednego programisty” , ale jest odwrotnie., Badania nad programowaniem w parach pokazują, że parowanie tworzy lepszy kod mniej więcej w tym samym czasie, co programiści pracujący pojedynczo. Zgadza się: dwie głowy są lepsze niż jedna!
niektórzy programiści sprzeciwiają się parowaniu programowania bez próby. Trzeba trochę praktyki, aby zrobić dobrze, i trzeba to zrobić dobrze przez kilka tygodni, aby zobaczyć wyniki. Dziewięćdziesiąt procent programistów, którzy uczą się programowania w parach, preferuje go, więc gorąco polecamy go wszystkim zespołom.
parowanie, oprócz zapewnienia lepszego kodu i testów, służy również do przekazywania wiedzy w całym zespole., W miarę przełączania się par każdy otrzymuje korzyści ze specjalistycznej wiedzy każdego. Programiści uczą się, doskonalą swoje umiejętności, stają się bardziej wartościowi dla zespołu i firmy. Parowanie, nawet samo w sobie poza PD, jest wielką wygraną dla wszystkich.
Test-Driven Development
Extreme Programming ma obsesję na punkcie sprzężenia zwrotnego, a przy tworzeniu oprogramowania dobre sprzężenie zwrotne wymaga dobrych testów. Zespoły najlepszych XP ćwiczą „Test-driven development”, pracując w bardzo krótkich cyklach dodawania testu, a następnie sprawiając, że działa., Niemal bez wysiłku zespoły produkują kod z prawie 100-procentowym pokryciem testowym, co jest wielkim krokiem naprzód w większości sklepów. (Jeśli twoi programiści już robią jeszcze bardziej wyrafinowane testy, więcej mocy dla Ciebie. Tak trzymać, to może tylko pomóc!)
nie wystarczy pisać testów: trzeba je uruchomić. Tutaj również ekstremalne programowanie jest ekstremalne. Te „testy programistyczne” lub „testy jednostkowe” są gromadzone razem i za każdym razem, gdy programista wydaje dowolny kod do repozytorium (a pary zazwyczaj wypuszczają dwa razy dziennie lub więcej), każdy z testów programisty musi działać poprawnie., Na sto procent, cały czas! Oznacza to, że programiści otrzymują natychmiastową informację zwrotną o tym, jak sobie radzą. Dodatkowo testy te zapewniają bezcenne wsparcie w miarę ulepszania projektu oprogramowania.
doskonalenie projektu (Refaktoryzacja)
Programowanie Ekstremalne koncentruje się na dostarczaniu wartości biznesowej w każdej iteracji. Aby to osiągnąć w trakcie całego projektu, oprogramowanie musi być dobrze zaprojektowane. Alternatywą byłoby spowolnienie i ostatecznie utknąć., So XP wykorzystuje proces ciągłego doskonalenia projektu o nazwie refaktoring, z tytułu książki Martina Fowlera „Refactoring: Improving the Design of Existing Code”.
proces refaktoryzacji skupia się na usunięciu duplikacji (pewna oznaka słabej konstrukcji) oraz na zwiększeniu „spójności” kodu, przy jednoczesnym obniżeniu „sprzężenia”. Wysoka spójność i niskie sprzężenie są uznawane za cechy dobrze zaprojektowanego kodu od co najmniej trzydziestu lat. W rezultacie zespoły XP zaczynają od dobrego, prostego projektu i zawsze mają dobry, prosty projekt oprogramowania., Pozwala to im utrzymać szybkość rozwoju, a w rzeczywistości ogólnie zwiększyć szybkość w miarę rozwoju projektu.
Refaktoryzacja jest oczywiście silnie wspierana przez kompleksowe testy, aby mieć pewność, że wraz z rozwojem projektu nic nie jest zepsute. W związku z tym testy klienta i testy programistów są krytycznym czynnikiem umożliwiającym. Praktyki XP wspierają się wzajemnie: są silniejsze razem niż osobno.
ciągła Integracja
zespoły programistyczne zapewniają pełną integrację systemu przez cały czas. Mówimy, że codzienne buildy są dla mięczaków: zespoły PD budują kilka razy dziennie., (Jedna czterdziestoosobowa drużyna PD buduje co najmniej osiem lub dziesięć razy dziennie!)
korzyści z tej praktyki można zauważyć, myśląc o projektach, o których być może słyszałeś (lub nawet byłeś częścią), w których proces budowania był co tydzień lub rzadziej i zwykle prowadził do „piekła integracji”, gdzie wszystko się zepsuło i nikt nie wiedział dlaczego.
rzadka integracja prowadzi do poważnych problemów w projekcie oprogramowania., Po pierwsze, chociaż integracja ma kluczowe znaczenie dla wysyłania dobrego kodu roboczego, zespół nie jest przy tym praktykowany i często jest delegowany do osób, które nie są zaznajomione z całym systemem. Po drugie, rzadko zintegrowany kod jest często – powiedziałbym zazwyczaj-błędnym kodem. W czasie integracji pojawiają się problemy, które nie są wykrywane przez żadne testy przeprowadzane na niezintegrowanym systemie. Po trzecie, słaby proces integracji prowadzi do długiego zamrożenia kodu., Zamrożenie kodu oznacza, że masz długi okres czasu, kiedy programiści mogą pracować nad ważnymi funkcjami, ale te funkcje muszą zostać wstrzymane. Osłabia to twoją pozycję na rynku lub użytkowników końcowych.
kolektywna własność kodu
w ekstremalnych projektach programistycznych każda para programistów może ulepszyć dowolny kod w dowolnym momencie. Oznacza to, że cały kod czerpie korzyści z uwagi wielu ludzi, co zwiększa jakość kodu i zmniejsza wady., Jest jeszcze jedna ważna korzyść: gdy kod jest własnością osób fizycznych, wymagane funkcje są często umieszczane w niewłaściwym miejscu, ponieważ jeden programista odkrywa, że potrzebuje funkcji gdzieś w kodzie, której nie posiada. Właściciel jest zbyt zajęty, aby to zrobić, więc programista umieszcza tę funkcję w swoim własnym kodzie, gdzie nie należy. Prowadzi to do brzydkiego, trudnego do utrzymania kodu, pełnego powielania i o niskiej (złej) spójności.
kolektywna własność mogłaby być problemem, gdyby ludzie ślepo pracowali nad kodem, którego nie rozumieli., XP unika tych problemów dzięki dwóm kluczowym technikom: programista testuje błędy, a programowanie w parze oznacza, że najlepszym sposobem pracy nad nieznanym kodem jest sparowanie z ekspertem. Oprócz zapewnienia dobrych modyfikacji w razie potrzeby, praktyka ta rozprzestrzenia wiedzę w całym zespole.
standard kodowania
zespoły XP stosują wspólny standard kodowania, dzięki czemu cały kod w systemie wygląda tak, jakby został napisany przez jedną – bardzo kompetentną – osobę., Specyfika standardu nie jest ważna: ważne jest, aby cały kod wyglądał znajomo, na poparcie zbiorowej własności.
metafora
zespoły programistyczne rozwijają wspólną wizję działania programu, którą nazywamy „metaforą”. W najlepszym razie metafora jest prostym sugestywnym opisem działania programu, takim jak” ten program działa jak UL pszczół, wychodząc na pyłek i doprowadzając go z powrotem do ula ” jako opis systemu wyszukiwania informacji opartego na agentach.
czasami wystarczająca poetycka metafora nie powstaje., W każdym razie, z żywymi obrazami lub bez nich, zespoły PD używają wspólnego systemu nazw, aby upewnić się, że wszyscy rozumieją, jak działa system i gdzie szukać, aby znaleźć funkcjonalność, której szukasz, lub znaleźć odpowiednie miejsce, aby umieścić funkcjonalność, którą chcesz dodać.
Pracują ciężko i w tempie, które może być utrzymane w nieskończoność. Oznacza to, że pracują w godzinach nadliczbowych, gdy jest to skuteczne, i że zwykle pracują w taki sposób, aby zmaksymalizować produktywność tydzień po tygodniu., W dzisiejszych czasach jest całkiem dobrze zrozumiane, że projekty marszu śmierci nie są ani produktywne, ani nie produkują wysokiej jakości oprogramowania. Drużyny PD są w nim po to, aby wygrać, a nie umrzeć.
podsumowanie
Programowanie Ekstremalne jest dyscypliną rozwoju oprogramowania opartą na wartościach prostoty, komunikacji, sprzężenia zwrotnego i odwagi. Działa poprzez połączenie całego zespołu w obecności prostych praktyk, z wystarczającą ilością informacji zwrotnych, aby umożliwić zespołowi zobaczenie, gdzie się znajdują i dostosowanie praktyk do ich wyjątkowej sytuacji.