Extreme Programming (XP) to jedna ze zwinnych metodologii programistycznych oprogramowanie. Autorami metodyki są Kent Beck, Ward Cunningham, Martin Fowler i inni.

Gra w planowanie

Nasz świat jest zbyt zmienny i nieprzewidywalny, by polegać na stałości sytuacji. To samo dzieje się przy tworzeniu oprogramowania: o rzadkim systemie można powiedzieć, że jego ostateczna forma była z góry dokładnie znana na samym początku tworzenia. Zwykle apetyt klienta przychodzi wraz z jedzeniem: ciągle chce coś zmienić, coś poprawić, coś wyrzucić z systemu. To jest zmienność wymagań, której wszyscy się boją. Na szczęście człowiek ma zdolność przewidywania możliwe opcje a tym samym utrzymać sytuację pod kontrolą.
W programowaniu ekstremalnym planowanie jest integralną częścią rozwoju, a fakt, że plany mogą się zmieniać, jest brany pod uwagę od samego początku. Tym punktem podparcia, techniką, która pozwala przewidzieć sytuację i bezboleśnie znosić zmiany, jest gra w planowanie. W trakcie takiej gry można szybko zebrać znane wymagania dla systemu, ocenić i zaplanować ich rozwój zgodnie z priorytetami.
Jak każda inna gra, planowanie ma swoich uczestników i swój cel. Kluczową postacią jest oczywiście klient. To on informuje o potrzebie konkretnej funkcjonalności. Programiści podają również przybliżoną ocenę każdej funkcjonalności. Piękno gry w planowanie tkwi w jedności celu i solidarności między deweloperem a klientem: w przypadku zwycięstwa wszyscy wygrywają, w przypadku porażki wszyscy przegrywają. Ale jednocześnie każdy uczestnik idzie do zwycięstwa na swój sposób: klient wybiera najważniejsze zadania zgodnie z budżetem, a programista ocenia zadania zgodnie ze swoją zdolnością do ich realizacji.
Programowanie ekstremalne zakłada, że ​​programiści są w stanie sami decydować, jak długo będą sobie radzić ze swoimi zadaniami i który z nich chętniej rozwiązałby jeden problem, a kto nie.
W idealnej sytuacji gra planistyczna z udziałem klienta i programisty powinna być rozgrywana co 3-6 tygodni, przed rozpoczęciem kolejnej iteracji rozwoju. Ułatwia to wprowadzanie poprawek zgodnie z sukcesami i porażkami poprzedniej iteracji.

Plan wydania

Plan wydań definiuje daty wydania i język użytkownika, który zostanie zaimplementowany w każdym wydaniu. Na tej podstawie możesz wybrać sformułowanie do następnej iteracji. Podczas iteracji tworzone są testy akceptacyjne i uruchamiane w ramach tej iteracji oraz wszystkich kolejnych iteracji, aby zapewnić prawidłowe działanie programu. Plan można zmienić w przypadku znacznego opóźnienia lub postępu po wynikach jednej z iteracji.
Iteracje. Iteracja sprawia, że ​​proces rozwoju jest dynamiczny. Nie musisz planować zadań programistycznych z dużym wyprzedzeniem. Lepiej jest zorganizować spotkanie planistyczne na początku każdej iteracji. Nie warto próbować wdrażać czegoś, co nie było zaplanowane. Nadal będziesz miał czas na wdrożenie tych pomysłów, gdy dotrą do tury zgodnie z planem wydania.
Przyzwyczajając się do nie dodawania funkcjonalności z wyprzedzeniem i korzystając z bezpośredniego planowania, możesz łatwo dostosować się do zmieniających się wymagań klientów.

Planowanie iteracji

Planowanie iteracji rozpoczyna się od spotkania na początku każdej iteracji w celu opracowania planu kroków prowadzących do osiągnięcia celów programu. Każda iteracja powinna trwać od jednego do trzech tygodni. Wypowiedzi w iteracji są sortowane według ich ważności dla klienta. Ponadto dodawane są zadania, które nie przeszły testów akceptacyjnych i wymagają poprawy. Oświadczenia i wyniki testów są przekładane na zadania programu. Zadania są zapisywane na kartach, które tworzą szczegółowy plan iteracji. Rozwiązanie każdego zadania zajmuje od jednego do trzech dni. Zadania, które wymagają mniej niż jednego dnia, można pogrupować razem, a duże zadania można podzielić na kilka mniejszych. Deweloperzy oceniają zadania i terminy, aby je wykonać. Dla dewelopera bardzo ważne jest ustalenie dokładnego czasu wykonania zadania. Po każdych trzech lub pięciu iteracjach może być konieczna ponowna ocena niektórych języków i rewizja planu wydania - jest to całkiem do przyjęcia. Jeśli najpierw wdrożysz najważniejsze obszary pracy, zawsze będziesz miał czas, aby zrobić maksimum dla swoich klientów. Styl programowania oparty na sekwencji iteracji usprawnia proces programowania.

Stałe spotkanie

Każdego ranka odbywa się spotkanie, aby omówić problemy, ich rozwiązania i zwiększyć koncentrację zespołu. Spotkanie odbywa się na stojąco, aby uniknąć długich dyskusji, które nie są interesujące dla wszystkich członków zespołu.
Na typowym spotkaniu większość uczestników nie wnosi nic, po prostu uczestniczy, aby usłyszeć, co inni mają do powiedzenia. Duża ilość czasu ludzi jest marnowana na otrzymanie niewielkiej ilości komunikacji. Dlatego udział wszystkich osób w spotkaniach odbiera zasoby projektowi i wprowadza chaos w planowaniu.
Do tego rodzaju komunikacji potrzebne jest spotkanie na stojąco. O wiele lepiej jest mieć jedno krótkie, obowiązkowe spotkanie niż wiele długich, w których i tak musi uczestniczyć większość programistów.
Jeśli masz codzienne spotkania na stojąco, to we wszystkich innych spotkaniach powinni uczestniczyć tylko ci ludzie, którzy są potrzebni i coś przyniosą. Co więcej, można nawet uniknąć niektórych spotkań. Przy ograniczonej liczbie uczestników większość spotkań może odbywać się spontanicznie przed monitorem, gdzie wymiana pomysłów jest znacznie intensywniejsza.
Codzienne poranne spotkanie to nie tylko kolejna strata czasu. Pozwoli to uniknąć wielu innych spotkań i zaoszczędzi więcej czasu niż zmarnowanego.

Prostota

Prosty projekt zawsze zajmuje mniej czasu niż skomplikowany. Więc zawsze rób najprostsze rzeczy, które mogą działać tylko. Zawsze szybciej i taniej jest zastąpić złożony kod od razu, zanim poświęcisz nad nim dużo czasu. Utrzymuj rzeczy tak proste, jak to możliwe, bez dodawania funkcji przed planowanym. Pamiętaj: utrzymanie prostego projektu to ciężka praca.

System metafor

Wybór systemu metafor jest potrzebny, aby utrzymać zespół w tej samej strukturze podczas nazywania klas i metod. To, jak nazywasz swoje obiekty, jest bardzo ważne dla zrozumienia ogólnego projektu systemu i ponownego wykorzystania kodu. Jeśli programista jest w stanie poprawnie odgadnąć, jak można nazwać istniejący obiekt, oszczędza to czas. Użyj systemu nazewnictwa dla swoich obiektów, który każdy może zrozumieć bez szczegółowej wiedzy o systemie.

Klient w miejscu pracy

Głównym problemem tworzenia oprogramowania jest brak wiedzy programistów w rozwijanym obszarze tematycznym. Programowanie ekstremalne również znalazło wyjście z tej sytuacji. Nie, to nie jest staż programisty w przedsiębiorstwie klienta – wtedy nie będzie chciał programować. Wręcz przeciwnie, to udział klienta w procesie rozwoju.
Jak programista, bez dokładnego zrozumienia istoty problemu i nie będąc telepatą, może odgadnąć, czego chce klient? Odpowiedź jest oczywista. przez większość w prosty sposób przezwyciężyć taką niedogodność – a Programowanie Ekstremalne uczy nas znajdować jak najwięcej proste rozwiązania- zada klientowi bezpośrednie pytanie. Bardziej rygorystyczne podejścia wymagają kompleksowej wstępnej analizy opracowywanego obszaru. W niektórych przypadkach jest to uzasadnione, choć kosztuje więcej. Prawdziwe doświadczenie prowadzenia prozaicznych projektów pokazuje, że nie da się z góry zebrać wszystkich wymagań. Co więcej, nawet jeśli założymy, że wszystkie wymagania są aktualnie gromadzone, nadal będzie jedno wąskie gardło: programy, jak wszystko w naturze, nie powstają od razu, a w międzyczasie procesy biznesowe mogą się zmieniać. Należy to wziąć pod uwagę.
Wielu wątpi w możliwość zaangażowania klienta w proces rozwoju. Rzeczywiście, klienci są różni. Jeśli nie ma możliwości przyciągnięcia klienta lub jego przedstawiciela, czasami warto zatrudnić tymczasowo specjalistę w opracowywanym obszarze. Taki krok zmniejszy niejasności w pracy, zwiększy szybkość rozwoju i zbliży projekt do tego, co klient chce otrzymać. Może to być również korzystne od strony finansowej: w końcu wynagrodzenie programisty czasami znacznie przewyższa wynagrodzenie specjalistów z innych branż.
Historia użytkownika. User Story (coś w rodzaju user story) to opis tego, jak system powinien działać. Każda historia użytkownika jest zapisana na karcie i reprezentuje pewną część funkcjonalności systemu, która ma logiczny sens z punktu widzenia Klienta. Formularz to jeden lub dwa akapity tekstu, który jest zrozumiały dla użytkownika (niezbyt techniczny).
Historię Użytkownika pisze Klient. Są one podobne do scenariuszy użytkowania systemu, ale nie ograniczają się do nich. interfejs użytkownika. Dla każdej historii pisane są testy funkcjonalne, aby potwierdzić, że ta historia jest poprawnie zaimplementowana - nazywane są również testami akceptacyjnymi.

Testowanie przed rozwojem

Testowanie w swoim klasycznym sensie jest dość nudną procedurą. Zazwyczaj zatrudniają testera, który okresowo wykonuje te same czynności i czeka na dzień, w którym ostatecznie zostanie przeniesiony na inne stanowisko lub pojawi się możliwość zmiany pracy.
W programowaniu ekstremalnym rola testowania jest ciekawsza: teraz najpierw jest test, a dopiero potem kod. Jak przetestować coś, co jeszcze nie istnieje? Odpowiedź jest prosta i banalna: przetestuj swoje myśli - czego można oczekiwać od przyszłego oprogramowania lub funkcjonalności. Pozwoli to lepiej zrozumieć, co programiści muszą zrobić, i sprawdzić funkcjonalność kodu, gdy tylko zostanie napisany.
Ale test też może nie działać. A co z pisaniem testu na test? A potem test na test i tak w nieskończoność? Zupełnie nie. Test dla testu zastąpi kod. Jak to? Ale spójrz: wyobraź sobie, że musisz naprawić nakrętkę na środku śruby, aby się nie obracała. Co oni w tym celu robią? Przykręć drugą nakrętkę blisko pierwszej, tak aby każda nakrętka zapobiegała obracaniu się kolejnej. Tak samo jest w programowaniu: test testuje kod, a kod testuje test.
Doświadczenie pokazuje, że takie podejście nie tylko nie spowalnia, ale także przyspiesza rozwój. W końcu wiedza o tym, co należy zrobić i wymagany nakład pracy, pozwoli zaoszczędzić czas, odmawiając wdrożenia nieodebranych ten moment Detale.

Programowanie par

Cały kod systemu produkcyjnego jest napisany parami. Dwaj deweloperzy siedzą obok siebie. Jedna tarcza, druga zegarki. Zmieniają się od czasu do czasu. Nie wolno pracować samemu. Jeśli z jakiegoś powodu drugi z pary coś przeoczył (chorował, odszedł itp.), jest zobowiązany do przejrzenia wszystkich zmian dokonanych przez pierwszego.
Brzmi to niecodziennie, ale po krótkim okresie przystosowania większość ludzi świetnie pracuje w parach. Nawet im się to podoba, bo praca jest wykonywana zauważalnie szybciej. Obowiązuje zasada „Jedna głowa jest dobra, ale dwie lepsze”. Pary zazwyczaj znajdują bardziej optymalne rozwiązania. Ponadto znacznie zwiększa się jakość kodu, zmniejsza się liczba błędów, a wymiana wiedzy między programistami jest przyspieszona. Podczas gdy jedna osoba skupia się na strategicznym spojrzeniu na obiekt, druga osoba wdraża jego właściwości i metody.

Zmiana stanowisk

W kolejnej iteracji wszyscy pracownicy powinni zostać przeniesieni do nowych obszarów pracy. Takie ruchy są konieczne, aby uniknąć izolacji wiedzy i wyeliminować wąskie gardła. Szczególnie owocna jest zamiana jednego z programistów na programowanie w parach.

Własność zbiorowego kodu

Zbiorowa własność kodu zachęca programistów do zgłaszania pomysłów na wszystkie części projektu, a nie tylko ich własne moduły. Każdy programista może zmienić dowolny kod, aby dodać funkcjonalność i naprawić błędy.
Na pierwszy rzut oka wygląda to na chaos. Biorąc jednak pod uwagę, że przynajmniej każdy kod jest tworzony przez kilku programistów, że testy pozwalają sprawdzić poprawność wprowadzonych zmian i że w rzeczywistości nadal trzeba rozumieć czyjś kod w taki czy inny sposób, staje się jasne ta zbiorowa własność kodu znacznie ułatwia wprowadzanie zmian i zmniejsza ryzyko związane z wysoką specjalizacją członka zespołu.

Konwencja kodowania

Jesteś w zespole, który od dłuższego czasu pracuje nad tym projektem. Ludzie przychodzą i odchodzą. Nikt nie koduje sam, a kod należy do wszystkich. Zawsze będą chwile, kiedy trzeba będzie zrozumieć i poprawić czyjś kod. Deweloperzy będą usuwać lub zmieniać zduplikowany kod, analizować i ulepszać klasy innych osób i tak dalej. Z czasem nie będzie można powiedzieć, kto jest autorem poszczególnych zajęć.
Dlatego każdy musi przestrzegać wspólnych standardów kodowania - formatowania kodu, klasy, zmiennej, stałego nazewnictwa, stylu komentarza. W ten sposób będziemy pewni, że dokonując zmian w czyimś kodzie (co jest niezbędne do agresywnego i ekstremalnego postępu naprzód), nie zmienimy go w babilońskie pandemonium.
Powyższe oznacza, że ​​wszyscy członkowie zespołu muszą uzgodnić wspólne standardy kodowania. Nieważne co. Zasada jest taka, że ​​wszyscy są im posłuszni. Ci, którzy nie chcą ich przestrzegać, opuszczają zespół.

Częsta integracja

Deweloperzy, jeśli to możliwe, powinni integrować i publikować swój kod co kilka godzin. W każdym razie nigdy nie należy przechowywać zmian dłużej niż jeden dzień. Częsta integracja pozwala uniknąć wyobcowania i fragmentacji w rozwoju, gdzie programiści nie mogą komunikować się w sensie wymiany pomysłów lub ponownego wykorzystania kodu. Każdy musi pracować z Ostatnia wersja.
Każda para programistów powinna rozdać swój kod, gdy tylko jest ku temu rozsądna okazja. Może to mieć miejsce, gdy wszystkie testy UnitTest przejdą 100%. Przesyłając zmiany kilka razy dziennie, zmniejszasz problemy z integracją prawie do zera. Integracja to działanie typu „zapłać teraz lub zapłać więcej później”. Dlatego, integrując zmiany codziennie w małych porcjach, nie będziesz musiał poświęcać tygodnia na powiązanie systemu tuż przed dostarczeniem projektu. Zawsze pracuj na najnowszej wersji systemu.

Czterdziestogodzinny tydzień pracy

Człowiek, zwłaszcza programista, jest w stanie zrobić wiele dla biznesu: zostać w pracy, iść do pracy na weekend, odmówić urlopu, nie zasnąć przez kilka dni, siedząc przy klawiaturze . .. Ogólnie rzecz biorąc, nie możesz nic zrobić ze względu na swoją ulubioną rozrywkę. Ale ekstremalne programowanie kategorycznie sprzeciwia się takiemu poświęceniu i łamaniu przyjętych norm prawa pracy.
Jest to podyktowane nie tylko względami legalności i człowieczeństwa, ale przede wszystkim koniecznością zwiększenia efektywności pracy i ścisłej organizacji. W końcu programowanie ekstremalne to gra zbiorowa, przeznaczona nie dla jednostek, ale dla całej grupy jako całości. A coś takiego jak np. programowanie w parach jest możliwe tylko wtedy, gdy biorytmy jej uczestników są zsynchronizowane. A to niemożliwe, jeśli jedna osoba przychodzi do pracy o dziewiątej, a druga o dwunastej, albo jedna uzna, że ​​lepiej mu pracować w sobotę i niedzielę, a druga jest niewygodna.
Ale co najważniejsze, aby zachować zdrowie i wydajność, człowiek potrzebuje dobrego wypoczynku. Ośmiogodzinny dzień pracy i pięciodniowy tydzień pracy są ustalane właśnie ze względu na maksymalną produktywność. W wielu firmach zachodnich spóźnienie z pracy jest uważane za słabe wyniki w nauce lub nieumiejętność właściwego zarządzania czasem pracy. W większości przypadków to prawda. Tak, a z medycznego punktu widzenia opóźnienia w pracy prowadzą do ciągłego zmęczenia, drażliwości i zmniejszonej aktywności mózgu. Czy to jest wydajne? Ale jak zorganizować stałą otwartą komunikację między programistami w takim zespole i czy programowanie w parach będzie możliwe? Odpowiedź jest negatywna. Zasady są zasadami i należy ich przestrzegać.

Wniosek

Te techniki nie są połączone przypadkiem. Ich konsekwentne połączenie jest w stanie wprowadzić proces rozwoju w intelektualny rezonans, znacznie podnosząc jakość produktu i przybliżając czas jego wydania. Główną zaletą całego programowania ekstremalnego jest przewidywalność i minimalizacja kosztów rozwoju; dostarczenie klientowi produktu, który chce otrzymać w momencie wydania; i oczywiście komunikacja i szkolenie programistów w pracy.

Bibliografia:

Extreme Programming (XP) powstało jako ewolucyjna oddolna metoda tworzenia oprogramowania. Takie podejście jest przykładem tzw. metody Agile Development. Grupa metod „na żywo” obejmuje, oprócz programowania ekstremalnego, metody SCRUM, DSDM (Dynamic Systems Development Method), Feature-Driven Development (rozwój sterowany funkcjami systemu) itp.

Podstawowe zasady tworzenia oprogramowania „na żywo” są ustalone w manifeście rozwoju „na żywo”, który pojawił się w 2000 roku.

• · Ludzie zaangażowani w projekt i ich komunikacja są ważniejsze niż procesy i narzędzia.
• · Program roboczy jest ważniejszy niż obszerna dokumentacja.
• · Współpraca z klientem jest ważniejsza niż omawianie szczegółów umowy.
• · Praktykowanie zmian jest ważniejsze niż podążanie za planami.

Metody „na żywo” pojawiły się jako protest przeciwko nadmiernej biurokratyzacji wytwarzania oprogramowania, nadmiarowi dokumentów pobocznych, które nie są niezbędne do uzyskania efektu końcowego, które muszą być opracowane w trakcie projektu zgodnie z większością „ciężkich” procesów , dodatkowa praca wspierać stały proces organizacji, zgodnie z wymaganiami np. CMM. Większość z tych prac i dokumentów nie jest bezpośrednio związana z tworzeniem oprogramowania i zapewnieniem jakości, ale ma na celu spełnienie formalnych klauzul umów deweloperskich, uzyskanie i potwierdzenie certyfikatów na zgodność z różnymi normami.

Metody „na żywo” pozwalają większości wysiłków programistów na skupienie się na faktycznych zadaniach rozwoju i satysfakcji prawdziwe potrzeby użytkowników. Brak stosu dokumentów i konieczność utrzymywania ich w spójnym stanie pozwala szybciej i sprawniej reagować na zmiany wymagań i środowiska, w którym przyszły program będzie musiał działać.

Niemniej jednak XP posiada własny schemat procesu rozwoju (choć, ogólnie rzecz biorąc, szeroko stosowane rozumienie „procesu rozwoju” jako dość sztywnego schematu działań jest sprzeczne z samą ideą „życia” rozwoju), pokazanej na rys. 1. .

Według autorów XP, technika ta nie tyle opiera się na ogólnych wzorcach działania, ile na kombinacji następujących technik. To powiedziawszy, każda technika jest ważna, a bez niej rozwój jest uważany za pozbawiony doświadczenia, według Kenta Becka, jednego z autorów tego podejścia wraz z Wardem Cunninghamem i Ronem Jeffriesem.

· żyjący planowanie gra)

Jego zadaniem jest jak najszybsze określenie ilości pracy, jaką należy wykonać przed kolejną wersją oprogramowania. Decyzję podejmuje się po pierwsze na podstawie priorytetów klienta (tj. jego potrzeb, tego, czego potrzebuje od systemu, aby skuteczniej prowadzić swój biznes), a po drugie na podstawie oceny techniczne(tj. oszacowanie złożoności rozwoju, kompatybilność z innymi elementami systemu itp.). Plany zmieniają się, gdy tylko zaczynają odbiegać od rzeczywistości lub życzeń klienta.

Rys.1

· Częsty zmiana wersje (małe wydania)

Pierwsza działająca wersja powinna pojawić się tak szybko, jak to możliwe i powinna być natychmiast używana. Kolejne wersje przygotowywane są w dość krótkich odstępach czasu (od kilku godzin z niewielkimi zmianami w mały program, do miesiąca lub dwóch z poważnym przetwarzaniem dużego systemu). Wersje (wydania) produktu powinny jak najczęściej trafiać do produkcji. Praca nad każdą wersją powinna zająć jak najmniej czasu. Jednocześnie każda wersja powinna być wystarczająco znacząca pod względem użyteczności dla biznesu.

· Metafora systemu

Metafora, w dość prostej i zrozumiałej dla zespołu formie, powinna opisywać główny mechanizm systemu. Koncepcja ta przypomina architekturę, ale znacznie prościej, w jednym czy dwóch frazach, opisać główną istotę przyjętego rozwiązania techniczne.

Architektura to pewne wyobrażenie o elementach systemu i sposobie ich połączenia. Deweloperzy wykorzystują architekturę, aby zrozumieć, gdzie w systemie są dodawane nowe funkcje i z czym będą wchodzić w interakcje nowe komponenty.

Metafora systemu jest analogiczna do tego, co większość technik nazywa architekturą. Metafora systemu daje zespołowi wyobrażenie o tym, jak obecnie działa system, gdzie dodawane są nowe komponenty i jaką formę powinny przybrać.

· Prosty projekt rozwiązania (proste projekt)

W dowolnym momencie system powinien być zaprojektowany tak prosto, jak to tylko możliwe. Nie musisz z góry dodawać funkcji - tylko po wyraźnym poproszeniu o to. Cała nadmierna złożoność jest usuwana, gdy tylko zostanie odkryta.

XP wynika z tego, że w trakcie pracy warunki problemu mogą się wielokrotnie zmieniać, co oznacza, że ​​tworzony produkt nie powinien być projektowany z góry całkowicie i kompletnie. Jeśli na samym początku pracy starasz się szczegółowo zaprojektować system od początku do końca, marnujesz swój czas. XP sugeruje, że projektowanie jest tak ważnym procesem, że musi być wykonywane w sposób ciągły przez cały czas trwania projektu. Projekt należy wykonywać małymi krokami, uwzględniając stale zmieniające się wymagania. W każdym momencie staramy się zastosować najprostszy projekt, który odpowiada aktualnemu zadaniu. Jednocześnie zmieniamy go wraz ze zmianą warunków problemu.

· Rozwój na podstawa testowanie (na podstawie testów rozwój)

Deweloperzy najpierw piszą testy, a następnie próbują zaimplementować swoje moduły, aby testy działały. Klienci z wyprzedzeniem piszą testy, które demonstrują główne funkcje systemu, dzięki czemu widać, że system naprawdę działa.

XP skupia się na dwóch rodzajach testowania:

ü testowanie jednostek (testowanie jednostkowe);

ü testy akceptacyjne (testy akceptacyjne).

ekstremalne oprogramowanie do programowania

Deweloper nie może być pewien poprawności napisanego przez siebie kodu, dopóki nie zadziałają absolutnie wszystkie testy jednostkowe tworzonego przez niego systemu. Testy jednostkowe umożliwiają deweloperom sprawdzenie, czy ich kod działa poprawnie. Pomagają również innym programistom zrozumieć, dlaczego dany fragment kodu jest potrzebny i jak działa. Testy jednostkowe pozwalają również programiście na refaktoryzację bez obaw.

Testy akceptacyjne pozwalają upewnić się, że system rzeczywiście posiada deklarowane możliwości. Dodatkowo testy akceptacyjne pozwalają sprawdzić poprawność działania opracowanego produktu.

W przypadku XP podejście zwane TDD (Test Driven Development) jest bardziej priorytetowe, najpierw pisany jest test, który nie przechodzi, następnie pisany jest kod, aby test przeszedł pomyślnie, a następnie kod jest refaktoryzowany.

· Stały refaktoryzacja

Nie jest tajemnicą, że każda dodana nowa funkcja i rosnący kod utrudnia tworzenie, łapanie błędów i wprowadzanie kolejnych zmian. Jedną ze sztuczek Extreme Programming jest rekompensowanie dodatkowej funkcjonalności poprzez ulepszenie kodu. To jest refaktoryzacja lub refaktoryzacja kodu.

Programiści nieustannie przerabiają system, aby wyeliminować niepotrzebną złożoność, zwiększyć zrozumiałość kodu, zwiększyć jego elastyczność, ale bez zmiany jego zachowania, co jest weryfikowane poprzez uruchamianie po każdym przerobieniu testów. Jednocześnie preferowane są bardziej eleganckie i elastyczne rozwiązania w porównaniu z tymi, które po prostu dają pożądany efekt. Komponenty zrefaktoryzowane niepomyślnie powinny być wykrywane podczas uruchamiania testów i przywracane do ostatniego spójnego stanu (wraz z komponentami od nich zależnymi).

Refaktoryzacja to technika ulepszania kodu bez zmiany jego funkcjonalności. XP sugeruje, że raz napisany kod prawie na pewno będzie powtarzany wiele razy w trakcie projektu. Twórcy XP nieustannie przerabiają kod, który napisali wcześniej, aby go ulepszyć. Ten proces nazywa się refaktoryzacją. Brak pokrycia testowego prowokuje do odrzucenia refaktoryzacji, ze względu na obawę przed złamaniem systemu, co prowadzi do stopniowej degradacji kodu.

· Programowanie w parach (para programowanie)

Doświadczeni programiści zauważyli, że okresowe przeglądanie cudzego kodu ma pozytywny wpływ na jego jakość. Extreme Programers opracowali takie podejście: podczas tworzenia kod jest stale aktualizowany za pomocą techniki zwanej programowaniem w parach.

Kodowanie wykonuje dwóch programistów na jednym komputerze. Parowanie jest arbitralne i różni się w zależności od problemu. Ten, w którego rękach próbuje klawiatura w najlepszy możliwy sposób rozwiązać aktualny problem. Drugi programista analizuje pracę pierwszego i doradza, rozważa konsekwencje pewnych decyzji, nowe testy, mniej bezpośrednie, ale bardziej elastyczne rozwiązania. W razie potrzeby klawiatura jest swobodnie przenoszona z jednej na drugą. Podczas pracy nad projektem pary nie są stałe: zaleca się ich mieszanie tak, aby każdy programista w zespole miał dobre rozeznanie w całym systemie. W ten sposób programowanie w parach poprawia interakcję w zespole.

· Kolektyw posiadanie kod (zbiorczy własność)

Kolektyw posiadanie oznacza, że ​​każdy członek zespołu odpowiada za całość źródło. W ten sposób każdy ma prawo do wprowadzania zmian w dowolnej części programu. Programowanie w parach wspiera tę praktykę: pracując w różnych parach, wszyscy programiści zapoznają się ze wszystkimi częściami kodu systemu. Ważną zaletą zbiorowego posiadania kodu jest to, że przyspiesza proces rozwoju, ponieważ gdy pojawi się błąd, każdy programista może go naprawić.

Dając każdemu programiście prawo do zmiany kodu, narażamy się na ryzyko wprowadzenia błędów od programistów, którzy myślą, że wiedzą, co robią, ale nie biorą pod uwagę niektórych zależności. Dobrze zdefiniowane testy UNIT rozwiązują ten problem: jeśli niesprawdzone zależności generują błędy, następne uruchomienie testów UNIT zakończy się niepowodzeniem.

· Stały integracja (ciągła integracja)

System jest montowany i integrowany, testowany tak często, jak to możliwe, kilka razy dziennie, za każdym razem, gdy kilku programistów kończy implementację funkcji.

Jeśli wystarczająco często integrujesz swój system, możesz uniknąć większości związanych z nim problemów. W tradycyjnych metodach integracja z reguły odbywa się na samym końcu pracy nad produktem, kiedy uważa się, że wszystkie komponenty tworzonego systemu są w pełni gotowe. W XP integracja kodu całego systemu odbywa się kilka razy dziennie, po upewnieniu się przez programistów, że wszystkie testy jednostkowe działają poprawnie.

Pomimo swojej prostoty, technika ta ma swoje własne zasady użytkowania, takie jak powodzenie istniejących testów jednostkowych dla zintegrowanej funkcjonalności, obecność testów funkcjonalnych lub akceptacyjnych i oczywiście możliwość powrotu do poprzedniego stanu. Z reguły integracja i rozwiązywanie towarzyszących trudności odbywa się na: oddzielny komputer kilku programistów. Pozwala to zminimalizować ryzyko niepożądanych konsekwencji integracji.

· 40 godzin pracujący tydzień

Nadgodziny są postrzegane jako oznaka dużych problemów w projekcie. Zabrania się pracy w godzinach nadliczbowych przez 2 tygodnie z rzędu - to wyczerpuje programistów i sprawia, że ​​ich praca jest znacznie mniej wydajna.

Człowiek, zwłaszcza programista, jest zdolny do wielu rzeczy ze względu na biznes: zostać w pracy, iść do pracy na weekend, odmówić urlopu, nie zasnąć przez kilka dni, siedząc przy klawiaturze ... Ogólnie rzecz biorąc, nie możesz nic zrobić ze względu na swoją ulubioną rozrywkę. Ale ekstremalne programowanie kategorycznie sprzeciwia się takiemu poświęceniu i łamaniu przyjętych norm prawa pracy.

Jest to podyktowane nie tylko względami legalności i człowieczeństwa, ale przede wszystkim koniecznością zwiększenia efektywności pracy i ścisłej organizacji. W końcu programowanie ekstremalne to gra zbiorowa, przeznaczona nie dla jednostek, ale dla całej grupy jako całości. A coś takiego jak np. programowanie w parach jest możliwe tylko wtedy, gdy biorytmy jej uczestników są zsynchronizowane. A to niemożliwe, jeśli jedna osoba przychodzi do pracy o dziewiątej, a druga o dwunastej, albo jedna uzna, że ​​lepiej mu pracować w sobotę i niedzielę, a druga jest niewygodna.

Ale co najważniejsze, aby zachować zdrowie i wydajność, człowiek potrzebuje dobrego wypoczynku. Ośmiogodzinny dzień pracy i pięciodniowy tydzień pracy są ustalane właśnie ze względu na maksymalną produktywność. W wielu firmach zachodnich spóźnienie z pracy jest uważane za słabe wyniki w nauce lub nieumiejętność właściwego zarządzania czasem pracy. W większości przypadków to prawda. Tak, a z medycznego punktu widzenia opóźnienia w pracy prowadzą do ciągłego zmęczenia, drażliwości i zmniejszonej aktywności mózgu. Czy to jest wydajne? Ale jak zorganizować stałą otwartą komunikację między programistami w takim zespole i czy programowanie w parach będzie możliwe? Odpowiedź jest negatywna. Zasady są zasadami i należy ich przestrzegać.

· Włączenie klient w polecenie (na miejscu klient)

Głównym problemem tworzenia oprogramowania jest brak wiedzy programistów w rozwijanym obszarze tematycznym. Programowanie ekstremalne również znalazło wyjście z tej sytuacji. Nie, to nie jest staż programisty w przedsiębiorstwie klienta – wtedy nie będzie chciał programować. Wręcz przeciwnie, to udział klienta w procesie rozwoju.

W ramach zespołu programistycznego zawsze jest przedstawiciel klienta, który jest dostępny przez cały dzień pracy i jest w stanie odpowiedzieć na wszystkie pytania dotyczące systemu. Jego obowiązkiem jest odpowiadanie odpowiednio szybko na wszelkiego rodzaju pytania dotyczące funkcji systemu, jego interfejsu, wymaganej wydajności, prawidłowe działanie systemy w trudnych sytuacjach, konieczność komunikacji z innymi aplikacjami itp.

Wielu wątpi w możliwość zaangażowania klienta w proces rozwoju. Rzeczywiście, klienci są różni. Jeśli nie ma możliwości przyciągnięcia klienta lub jego przedstawiciela, czasami warto zatrudnić tymczasowo specjalistę w opracowywanym obszarze. Taki krok zmniejszy niejasności w pracy, zwiększy szybkość rozwoju i zbliży projekt do tego, co klient chce otrzymać. Może to być również korzystne od strony finansowej: w końcu wynagrodzenie programisty czasami znacznie przewyższa wynagrodzenie specjalistów z innych branż.

· Stosowanie kod Jak fundusze komunikacja

Kod jest postrzegany jako najważniejszy środek komunikacji w zespole. Przejrzystość kodu jest jednym z najważniejszych priorytetów. Konieczne jest przestrzeganie standardów kodowania, które zapewniają taką przejrzystość. Takie standardy, oprócz przejrzystości kodu, powinny zapewniać minimum wyrażeń (brak powielania kodu i informacji) i powinny być akceptowane przez wszystkich członków zespołu.

· otwarty pracujący przestrzeń (otwarta obszar roboczy)

Zespół mieści się w jednym pomieszczeniu, wystarczająco przestronnym, aby ułatwić komunikację i możliwość wspólnych dyskusji przy planowaniu i podejmowaniu ważnych decyzji technicznych.

· Zmiana zasady na konieczne (po prostu zasady)

Każdy członek zespołu musi zaakceptować wymienione zasady, ale w razie potrzeby zespół może je zmienić, jeśli wszyscy jego członkowie zgodzą się na tę zmianę.

Jak widać z zastosowanych technik, XP jest przeznaczony do wykorzystania w małych zespołach (nie więcej niż 10 programistów), co również podkreślają autorzy tej techniki. Większy rozmiar zespołu niszczy łatwość komunikacji niezbędną do odniesienia sukcesu i uniemożliwia wiele z wymienionych technik.

Extreme Programming to odejście od tradycyjnego procesu tworzenia programów – zamiast jednorazowego planowania, analizy i projektowania systemu z długofalową perspektywą, teraz programiści wdrażają wszystkie te operacje stopniowo podczas rozwoju.

Początkowo istniał model „wodospadowy” (rys. 1a): prosimy użytkowników o jednoznaczne sformułowanie swoich wymagań; projektujemy system, który zrobi wszystko, czego chcą użytkownicy; piszemy kod; testujemy program, aby upewnić się, że robi to, co powinien. Wszystko wychodzi świetnie.

W rzeczywistości rzeczy nie były różowe. Przed rozpoczęciem rozwoju użytkownicy nie są jeszcze w stanie jednoznacznie sformułować swoich wymagań. Nie zawsze wiedzieli, czego chcą, czasem zaprzeczali sobie i zmieniali poglądy na ten problem. Ale to nie tylko użytkownicy. My, programiści, po przejściu trzech czwartych drogi i stwierdzeniu, że w rzeczywistości wykonaliśmy tylko jedną trzecią pracy, cieszyliśmy się z tego ogromnego sukcesu.

Tak więc długi cykl rozwoju jest zły, ponieważ nie jest w stanie dostosować się do zmian. Wtedy może trzeba skrócić cykl, a wszystkie problemy zostaną rozwiązane? Na ryc. 1b ilustruje przekształcenie modelu kaskadowego w model iteracyjny.

Przypomnijmy, że model kaskadowy nie pojawił się znikąd – była to naturalna reakcja na te szokujące szacunki, które pokazały, że cena wprowadzania zmian w programie z czasem bardzo rośnie. Jeśli to prawda, to najważniejsze, dalekosiężne decyzje należy podejmować na najwcześniejszym etapie cyklu życia programu, aby później nie trzeba było za nie słono płacić.

Środowisko akademickie programistów zajęło się problemem wysokich kosztów zmian i stworzyło nowe technologie - relacyjne bazy danych, programowanie modułowe, ukrywanie informacji. Ale co, jeśli wszystkie te prace wyczerpały już swój potencjał? I możemy znaleźć nowy sposób obniżyć koszty wprowadzania zmian nie rozcinając „wodospadu” na kawałki, a po prostu mieszając wszystkie jego składniki? Wynik pokazano na rysunku 1c. Nazwaliśmy to „Programowaniem ekstremalnym” (XP).

Anatomia XP

XP odchodzi od tradycyjnego procesu tworzenia system oprogramowania i zamiast jednorazowego planowania, analizy i projektowania w perspektywie długoterminowej, w XP, wszystkie te działania są wdrażane stopniowo podczas rozwoju, dzięki czemu osiąga się znaczną redukcję kosztów zmian w programie. Metody XP zostały zaprojektowane z myślą o ich łącznym zastosowaniu, więc jeśli zrozumiesz jedną z nich, nieuchronnie zrozumiesz pozostałe (patrz pasek boczny). Pasek boczny śledzi tło historyczne tego podejścia).

Cykl rozwoju XP

Na ryc. 2 proces XP jest związany z różnymi osiami czasu, gdzie lata, miesiące, tygodnie i dni są używane jako jednostka miary. Klient ustala kolejną wersję (wydanie) systemu, wybierając ze wszystkich możliwych funkcjonalności najbardziej wartościowe (w XP nazywane są one historyjkami - historyjkami). O wartości funkcji decydują koszty materiałowe i czasowe ich realizacji przez zespół programistów.

Klient określa wątki do następnej iteracji, wybierając najważniejsze wątki spośród pozostałych w wersji, ponownie na podstawie szacunkowego kosztu i szybkości ich opracowania. Programiści rozkładają historie na lokalne zadania i każdy bierze odpowiedzialność za jedno z nich. Następnie programista przekształca swój problem w zestaw przypadków testowych, których pomyślne wykonanie pokaże, że problem został całkowicie rozwiązany. Pracując w parze z partnerem, programista osiąga normalne działanie testów, jednocześnie rozwijając wspólny projekt. Dzięki temu możliwa jest realizacja najprostszej architektury systemu jako całości.

Historie

Z punktu widzenia XP okres poprzedzający pierwsze uruchomienie systemu do rzeczywistego działania jest niebezpieczną anomalią w koło życia projekt i należy go jak najszybciej przezwyciężyć. Jednak pracę nad każdym projektem trzeba jakoś zacząć.

Przede wszystkim należy zdecydować, do czego system jest ogólnie przeznaczony i co powinien umieć w pierwszej kolejności. Z reguły do ​​podjęcia takich decyzji potrzebna jest pewna analiza. Symbolizuje go wąski niebieski prostokąt na ryc. 1s. Nie możesz zacząć programować, dopóki nie zrozumiesz, co tak naprawdę trzeba zaprogramować.

Wyniki analizy ogólnej prezentowane są w postaci historyjek – indeksów wymieniających możliwe zastosowania systemu. Konieczne jest, aby każda historia była skoncentrowana na konkretnych celach biznesowych, aby można ją było przetestować i ocenić za pomocą wskaźniki ilościowe. wystarczy miesiąc dopuszczalny czas formułować historie do 10-cio osoboletniego projektu. Oczywiste jest, że ten czas nie wystarczy na szczegółowe przestudiowanie wszystkich możliwe problemy. Ale nigdy nie będzie czasu na analizę wszystkich problemów, jeśli w ogóle zamierzasz przejść do wdrożenia systemu.

Wersja

Jak widać na ryc. 2, nie wdrażamy wszystkich historii jednocześnie. Klient najpierw wybiera mały zestaw najważniejszych historii, które są ze sobą logicznie powiązane. A przede wszystkim je programujemy i uruchamiamy. Potem wszystko inne zostaje zaimplementowane.

Dobieranie historii do wersji systemu można porównać do zakupów w supermarkecie. Idziesz do sklepu ze sto dolarów w kieszeni. Zastanów się, czego potrzebujesz w pierwszej kolejności. Spójrz na metki. I zdecyduj, co kupić. W grze w planowanie produkty to historie, a metki z cenami to szacunki na temat historii. Twój budżet zależy od liczby szacunkowych historii dostarczonych przez zespół programistów w danej jednostce czasu.

Kupujący (klient) może albo wypełnić swój koszyk (wybrać zestaw historyjek), po czym programiści obliczą ostateczny termin ich realizacji, albo ustalić termin, do którego programiści obliczą budżet, a klient odbierze wymagana liczba opowiadań za otrzymaną kwotę.

Iteracja

Celem każdej iteracji jest wprowadzenie do produkcji kilku nowych, przetestowanych i gotowych do uruchomienia historii. Proces ten zaczyna się od planu, który określa, jakie historie zostaną wdrożone i jak zespół programistów wykona to zadanie. W trakcie opracowywania klient wymyśla testy funkcjonalne. Pod koniec iteracji testy powinny być uruchomione, a programiści powinni być gotowi na następną iterację.

Przystępując do planowania iteracji, programiści ponownie proszą klienta o wybranie najbardziej wartościowych historii, tym razem spośród pozostałych do wdrożenia w tej wersji. Deweloperzy dzielą historie na zadania – moduły, które jedna osoba może ukończyć w ciągu kilku dni. Jeśli istnieje kilka wyzwań technicznych, takich jak przeprowadzka do: Nowa wersja baz danych, znajdują się one również na liście ogólnej.

Programiści biorą wówczas odpowiedzialność za realizację określonych zadań. Po rozdzieleniu wszystkich zadań programista odpowiedzialny za zadanie ocenia je, tym razem według liczby idealnych dni programowania. Następnie zbierane są szacunkowe zadania wszystkich programistów zespołu i jeśli jedni z nich planują poświęcić więcej czasu na wdrożenie, a inni mniej, obciążenie pracą w zespole jest odpowiednio redystrybuowane.

Podczas iteracji programiści realizują swoje zadania. Po zakończeniu zadań ich kod jest integrowany z całym systemem i wraz z nim testowany. Albo wszystkie testy przechodzą pomyślnie, albo kod nie może zostać zintegrowany z systemem. Podczas iteracji do całej serii testów dodawane są testy funkcjonalne dostarczone przez klienta. Pod koniec iteracji wszystkie testy dla poszczególne moduły i wszystkie testy funkcjonalne.

Zadanie

W celu realizacji zadania, odpowiedzialny za nie programista w pierwszej kolejności szuka partnera, ponieważ ostateczny kod jest zawsze pisany przez dwie osoby na tej samej maszynie. W przypadku pojawienia się pytań dotyczących tematyki lub metod realizacji, partnerzy odbywają krótkie (15-minutowe) spotkanie z klientem i/lub programistami, którzy znają się na zagadnieniach kodowania, które najprawdopodobniej będą związane z kodem tego zadania podczas implementacja.

Na podstawie wyników tego spotkania programiści sporządzają listę przypadków testowych, które należy uruchomić przed zakończeniem zadania. Z listy wybierany jest taki test, w realizacji którego programiści są całkowicie pewni i przy pomocy którego będą mogli lepiej zrozumieć istotę problemu. Trwa pisanie programu testowego. Jeśli od razu zadziała, możesz przejść dalej. Jednak z reguły nie jest bez problemów. Jeśli test nie działa, możliwa jest jedna z następujących sytuacji:

• znamy prosty sposób, aby to zadziałało i działamy w ten sposób;
• znamy skomplikowany i bardzo denerwujący sposób, aby to zadziałało, ale rozumiemy, jak zmienić architekturę systemu i sprawić, by przypadek testowy działał poprawnie bez dodatkowego wysiłku. Następnie postanawiamy przerobić system;
• znamy trudny i nieprzyjemny sposób, aby to zadziałało i nie widzimy sposobu na przeróbkę systemu, więc idziemy trudną drogą.

Po przeprowadzeniu testu możemy ponownie zrozumieć, jak ulepszyć system, co zrobimy.

Jest prawdopodobne, że podczas implementacji przypadku testowego znajdziemy inny przypadek testowy, który również powinien zadziałać. Przynosimy nowy test do swojej listy i kontynuuj rozwój. Być może okaże się, że skala restrukturyzacji systemu wykracza poza wymagania obecnego testu, wtedy naprawimy ten fakt i przejdziemy dalej. W końcu naszym celem jest skupienie się na szczegółach i skuteczne rozwiązanie konkretnego problemu, ale jednocześnie nie zatracenie ogólnej idei systemu, która powstaje podczas intensywnej pracy nad kodami.

Test

Jeśli mówimy o kluczowej metodzie XP, to jest to oczywiście testowanie jednostkowe. Jak już widać, testowanie jednostkowe jest istotną częścią codziennej pracy każdego programisty. Dwie cechy sprawiają, że proces testowania XP jest znacznie bardziej wydajny niż tradycyjne metody: programiści piszą własne testy i robią to przed kodowaniem. Oczywiście, jeśli podchodzisz do programowania jako do stopniowego badania problemu, a badanie problemu uważasz za najskuteczniejszy środek informacja zwrotna z klientem najbardziej skorzystasz na testach napisanych przez stronę trzecią kilka dni lub tygodni po zakończeniu kodowania. XP uwzględnia konwencjonalną wiedzę, że programiści nie mogą właściwie przetestować własnego kodu i dlatego wymaga od nich pracy w parach.

Niektóre metodologie, w szczególności Cleanroom, zabraniają programistom testowania, a w niektórych przypadkach nawet kompilowania ich programów. Zazwyczaj programista pisze kod, kompiluje go, upewnia się, że działa, a następnie przesyła go do jakiejś organizacji testującej. Tradycyjne metody analizy porównawczej to przechodzenie przez kod i zmienne, interpretowanie wyników instrukcji drukowania, testowanie przycisków menu i tak dalej.

XP nie wprowadza żadnych nowych technik testowania w porównaniu z metodami konwencjonalnymi. Tyle, że testowanie odbywa się w innej formie i zamiast robić coś, co nie zostawi śladu po zakończeniu testowania, tworzysz testy na dłuższą metę. Testy te działają dzisiaj, będą działać w dniu zakończenia integracji systemu i następnego dnia, za tydzień i za rok. Zaufanie do normalnego działania każdego testu stopniowo buduje wśród programistów zaufanie do normalnego działania systemu jako całości.

Jak już wspomniano, klienci również wymyślają testy. Na początku iteracji klient musi znaleźć te czynniki, które przekonają go, że historie dla tej iteracji są w pełni zaimplementowane. Formalizuje swoje przemyślenia na ten temat w testach dla systemu jako całości. Klient może samodzielnie pisać testy z wykorzystaniem tekstowych lub graficznych języków skryptowych lub powierzyć je programiście, który będzie korzystał z własnych narzędzi testujących. Takie testy również budują zaufanie, tym razem zaufanie klienta do poprawnego działania systemu.

Masz problemy?

Omówienie tej lub innej metody programowania w warunkach, w których działa idealnie, nie jest trudne. O wiele bardziej interesujące jest wiedzieć, co zrobisz, jeśli znajdziesz się w nieprzewidzianej lub niepożądanej sytuacji.

Ponowna ocena własnych możliwości. Czasami bierzesz na siebie więcej, niż jesteś w stanie znieść. Konieczne jest maksymalne zminimalizowanie liczby takich sytuacji, jak najczęstsze odwoływanie się do ilościowych ocen swojej pracy. Jeśli czujesz się przytłoczony, najpierw poszukaj przyczyny w sobie. Przeanalizuj: być może jesteś zbyt rozproszony w rozwiązywaniu praktycznych problemów. Czy jesteś w pełni zaangażowany w testowanie, współpracę z partnerem, przerabianie systemu i integrację? Czy robisz więcej niż to, czego w tej chwili potrzebuje klient?

Jeśli nie możesz znaleźć wewnętrznych rezerw, aby przyspieszyć rozwój, poproś klienta o pomoc. Zachowanie odpowiedzialności za obciążenie pracą, którego nie możesz zagwarantować, sfrustruje plan, pogorszy jakość systemu i ostatecznie sprawi, że będzie on całkowicie bezużyteczny. Nie pozwól sobie na to. Ponownie oceń swoje możliwości w oparciu o zdobyte doświadczenie, a następnie poproś klienta o ponowne rozważenie swoich wymagań. Jeśli jesteś w stanie zaimplementować tylko dwie z trzech historii, pozwól mu określić, które historie ma zająć się jako pierwsze, a które zachować do następnej iteracji lub wersji. Czy nie ma takiej historii, której niektóre części są ważniejsze od innych? Następnie można rozłożyć jego implementację na etapy i bezzwłocznie zaprogramować bardziej istotne komponenty, a mniej ważne nieco później.

Jeśli klient nie współpracuje. Wyobraź sobie sytuację, w której klient nie akceptuje reguł Twojej gry. Nie wymyśla testów, nie ustala priorytetów, nie formułuje historii. Przede wszystkim spróbuj zainstalować związek zaufania z klientem. Zwiększając funkcjonalność systemu od iteracji do iteracji, daj klientowi możliwość kontrolowania procesu rozwoju. Jeśli wzajemne zaufanie nie wyjdzie, przeanalizuj, czy to twoja wina. Czy robisz wszystko dla efektywnej interakcji z klientem?

Jeśli nie jesteś w stanie samodzielnie rozwiązać tego problemu, skontaktuj się z klientem w celu uzyskania pomocy. Zasady XP po prostu nie pozwalają programistom rozwijać się poprzez zgadywanie potrzeb ich klientów. Wyjaśnij lub zademonstruj klientowi na przykładzie kolejność prac w XP. Jeśli nie zmieni swojego stosunku do ciebie, postaraj się, aby twoje argumenty były bardziej opisowe. Jeśli okaże się, że w zasadzie nikomu poza Tobą zależy na rozwiązaniu tego problemu, być może ten projekt ma niski priorytet w działaniach klienta i nie powinieneś w ogóle nalegać na jego kontynuowanie.

Rotacja pracowników. Załóżmy, że jeden z członków zespołu postanowił go opuścić. Czy znajdziesz się w impasie z powodu braku niezbędnych dokumentów lub raportów? Przede wszystkim zauważ, że pewna rotacja personelu jest korzystna dla zespołu programistycznego i jego poszczególnych członków. Chciałbym oczywiście, aby wyjeżdżając ludzie kierowali się pozytywnymi motywami. Jeśli wracając do domu pod koniec przyszłego tygodnia, programista zobaczy konkretne pozytywne rezultaty jego działalność, prawdopodobieństwo rozczarowania w pracy i pojawienie się chęci odejścia jest znacznie zmniejszone.

Jeśli ktoś opuści projekt XP, wcale nie oznacza to, że sam zabierze ze sobą znane mu sekrety. Każda linia w systemie jest zawsze kontrolowana przez dwie osoby. A jakiekolwiek informacje wydostaną się z pracowni nie zaszkodzą pracy zespołu, ponieważ programiści będą mogli przeprowadzić testy i sprawdzić, czy nie wydarzyło się coś nieoczekiwanego bez ich wiedzy.

Nowi członkowie zespołu XP w trakcie pracy nad dwoma pierwszymi iteracjami ograniczają się do pomocy bardziej doświadczonemu partnerowi z pary, studiowania testów i komunikacji z klientem. Czując większe zaufanie do swoich możliwości, będą mogli wziąć odpowiedzialność za określone zadanie. Podczas opracowywania kolejnych kilku iteracji wydajność nowicjuszy wzrasta tak bardzo, że są oni w stanie wykazać każdemu terminową realizację określonych zadań. Po kilku miesiącach nie można ich już odróżnić od doświadczonych członków zespołu.

Trudnym problemem są programiści, którzy nie są przyzwyczajeni do pracy w zespole. XP to ciężki, wspólny wysiłek i nie każdy jest w stanie przystosować się do tego rodzaju pracy. Konieczna może być rezygnacja ze starych nawyków, a to wcale nie jest łatwe, zwłaszcza dla programistów, którzy wysoko siebie cenią. Ale w końcu wiele form informacji zwrotnej w XP pozwala określić, kto może, a kto nie może pracować w zespole. Jeśli któryś z Was ciągle nie wykonuje zadania, integracja jego modułów zawsze sprawia problemy pozostałym członkom zespołu, nigdy nie próbuje przerabiać systemu, nie pracuje w parach, nie przeprowadza testów itp. Wszyscy w zespole zrozumieją, co jest czym. A całemu zespołowi lepiej będzie tylko wtedy, gdy taka osoba odejdzie, niezależnie od jego umiejętności i doświadczenia.

Zmieniające się wymagania. Problem problemów większości systemów programistycznych jest zupełnie inny niż w przypadku XP. Stworzony dziś w celu rozwiązywania konkretnych problemów, projekt XP poradzi sobie z wszelkimi zmianami funkcjonalności w przyszłości z taką samą wydajnością. Łatwiej będzie zrobić coś podobnego do tego, co już zostało zrobione, ponieważ XP wyznaje zasadę „sformułuj każdą myśl raz i tylko raz”. To właśnie w takim przetwarzaniu najczęściej pojawia się potrzeba. Ale nawet w przypadku, gdy pojawi się zupełnie nowe wymaganie dla systemu, nie trzeba pośpiesznie budować nowych mechanizmów jego działania.

Na początku nie miałem jasnego pojęcia o zdolności XP do zmian. W pierwszej wersji XP proces wyboru narracji był częścią planowania wersji, a historie były przypisywane do wszystkich iteracji w wersji. Deweloperzy odkryli następnie, że przy mniejszym wysiłku planistycznym mogą osiągnąć: najlepsze wyniki. Dlatego teraz klient jest proszony o określenie tylko tych historii, które powinny być obecne w następnej iteracji. Jeśli pojawi się Nowa historia, umieszczasz go w rezerwie i nie tasujesz reszty iteracji. Za tydzień lub dwa, jeśli nowa historia nie straciła jeszcze na aktualności, klient ją wybierze.

Planując za każdym razem jedną iterację, osiągamy stopniowy samorozwój i samopodobieństwo systemu. W skali miesięcy i lat mamy do czynienia z historiami danej wersji systemu, a następnie z historiami przyszłych wersji. W skali tygodni i miesięcy mamy do czynienia z historiami z tej iteracji, a następnie z historiami, które pozostają w tej wersji. W skali dni i tygodni mamy do czynienia z zadaniem, nad którym aktualnie pracujemy, a następnie z zadaniami pozostałymi w iteracji. Wreszcie, w skali minut i dni, mamy do czynienia z testem, który obecnie wykonujemy, a następnie z innymi przypadkami testowymi, które możemy wymyślić.

Bez wątpienia XP to elegancki, logicznie kompletny pomysł. Granice jego stosowalności nie są jeszcze do końca jasne. Przyjmując takie podejście teraz, musisz wykazać się odwagą, elastycznością i chęcią porzucenia projektu, jeśli się nie powiedzie. XP należy najpierw wypróbować w tych projektach, w których korzyści z tego podejścia są oczywiste: w niestandardowych lub wewnętrznych projektach małych systemów, dla których wymagania nie są jasno określone i mogą się zmieniać.

Jeśli chcesz doświadczyć XP, nie próbuj robić wszystkiego na raz. Wybierz najbardziej denerwujący problem i spróbuj go rozwiązać za pomocą XP. Kiedy ten problem przestanie być najbardziej dokuczliwy, poszukaj następnego i powtórz proces. Idąc dalej, prawdopodobnie odkryjesz, że żadna z twoich starych metod już nie działa. Wtedy nie będziesz już mógł się z nimi skontaktować. Ten stopniowy proces onboardingu daje Ci szansę na wypracowanie własnego stylu rozwoju, który poprowadzi Cię w każdej sytuacji, a tym samym zmniejszy ryzyko problemów z XP.

Silne rozróżnienie w XP między decyzjami biznesowymi a technicznymi pochodzi z pracy architekta Christophera Alexandra. W swojej książce The Timeless Way of Building zwraca uwagę, że ci, którzy zarządzają budynkiem, muszą mieć możliwość podejmowania ważnych decyzji podczas jego budowy.

Zasady XP dotyczące szybkiej ewolucji planu zgodnie ze zmianami technicznymi i biznesowymi odzwierciedlają zasady metodologii Scrum i języka szablonów Episodes opracowanego przez Warda Cunninghama.

Pomysł sprecyzowania i zaplanowania projektu pod kątem możliwych do zrealizowania możliwości sięga prac Ivara Jakobsona.

Tom Gilb jest ewolucyjnym guru inżynierii. Jego ostatnie prace skupiają się na przygotowaniu i uruchomieniu oprogramowania w ciągu kilku tygodni, a następnie na rozwoju.

Model spiralny autorstwa Barry'ego Boehma był pierwszą reakcją na przestarzałość modelu wodospadu. Przez długi czas w opanowaniu potężnych technologii nikt nie mógł prześcignąć Dave'a Thomasa i jego kolegów z Object Technology International, którzy stworzyli metodę JIT.

Korzenie zasady metafory stosowanej w XP można odnaleźć w książkach George'a Lakoffa i Marka Johnsona, a zwłaszcza w ich najnowszej pracy Philoslphy in the Flesh. Zasadę tę zaproponował również Richard Coine, który połączył metaforę i rozwój oprogramowania w kategoriach filozofii postmodernistycznej.

Wreszcie, znaczna część nacisku XP na organizację biura wywodzi się z pracy Jima Copliena, Toma DeMarco i Tima Listera, którzy zauważyli wpływ warunków środowiskowych na pracę programistów.

Przykłady realizacji projektów z wykorzystaniem XP

Acxiom: na drodze do wspólnego celu

Ji Hannula

Zespół: menedżerowie, analitycy biznesowi, programiści, testerzy, pisarze techniczni

Aplikacja: baza danych zarządzania kampaniami

Okres realizacji: 3 lata

Acxiom stworzył aplikację do zarządzania biznesem opartą na hurtowni danych przy użyciu rozproszonego zestawu narzędzi programistycznych Forte. Niewielki zespół programistów – zaledwie 10 osób – przy tworzeniu aplikacji mocno przestrzegał zasad programowania obiektowego i wspólnego rozwoju. Z trzech lat rozwoju, w ciągu ostatnich dwóch, zespół, w skład którego wchodzili menedżerowie, analitycy biznesowi, programiści, testerzy i pisarze techniczni, używał metod Extreme Programming i tak odniósł sukces.

Do niedawna Acxiom uważał projekt za sukces, jeśli był prosty, a niektóre z wcześniej zbudowanych systemów kwalifikowały się jako część nowej aplikacji. Okazało się jednak, że nic dobrego z tego nie wyszło. Przeróbka systemu stała się krytycznym elementem rozwoju. Wyraźnie zdaliśmy sobie sprawę, że bojąc się zmieniać te części programu, których funkcji jeszcze nie znamy, nie możemy uważać się za dobrych programistów. Pozwalamy programowi nas kontrolować. Gdybyśmy nie wiedzieli co podany kod, nie baliśmy się w to wejść i to rozgryźć. Lepiej zrobić to sam pewna część kodu niż uczynić całą aplikację zakładnikiem w osobnym jej kawałku.

Wiele wysiłku włożono w testy jednostkowe, ponieważ Forte nie oferuje wbudowanych podstawowych narzędzi testowych. Musieliśmy stworzyć własne i wykorzystać je do pomyślnego testowania. Niedawno przeszliśmy na język programowania Java i teraz używamy JUnit jako narzędzia testowego.

Kiedy po raz pierwszy zaczęliśmy pracować na zasadach XP, byli wśród nas programiści, którzy nie chcieli korzystać z jego metod. Uważali, że te metody nie pasują do opracowanego przez nich stylu programowania i uniemożliwią im produktywność. W rezultacie większość problemów pojawiła się z komponentami systemu napisanymi przez te osoby. Deweloperzy ci zlekceważyli pracę zespołową i stali się gorsi pod względem umiejętności od innych członków zespołu, którzy wykorzystali daną im możliwość uczenia się od siebie nawzajem. Dwóch doświadczonych programistów, którzy ściśle ze sobą współpracują, i reszta zespołu zawsze przewyższają „indywidualne” umiejętnościami, nawet jeśli ma on siedem przęseł na czole.

Zdaliśmy sobie sprawę, że każdy członek zespołu musi przestrzegać zasad XP, w przeciwnym razie takie podejście nie zadziała. Teraz od razu ostrzegamy potencjalnego dewelopera, że ​​jeśli nie jest zadowolony z przyjętego przez nas stylu, powinien lepiej poszukać pracy w innym zespole. Jedna osoba, która nie jest zainteresowana wybraną metodą rozwoju, może zniweczyć wysiłki całego zespołu. Istotą XP jest kolektywne rozwijanie nowych pomysłów w procesie tworzenia systemu.

Istnieje błędne przekonanie na temat HR, że to podejście hamuje aktywność twórczą i rozwój indywidualnych zdolności dewelopera. W rzeczywistości wszystko jest odwrotnie. XP stymuluje rozwój twórczy programisty i daje szansę poszczególnym członkom zespołu zabłysnąć. Najważniejsze jest, aby zdecydować i mocno trzymać się obranego kierunku.

„Programowanie ekstremalne” nie postawiło naszego zespołu w ekstremalnych warunkach. Ta metoda wykorzystuje dobrze znane i w dużej mierze znane podejścia programistyczne. Wszyscy ściśle ze sobą współpracują i wspólnie zmierzają do celu.

DaimlerChrysler: najlepszy zespół na świecie

Chet Hendriksen

Zespół: 15 osób, w tym 10 programistów

Aplikacja: pełna automatyzacja naliczania wynagrodzeń

Okres realizacji: 4 lata

Prace nad projektem C3 rozpoczęły się w styczniu 1995 roku. Chrysler Corporation zawarła umowę z firmą partnerską, zgodnie z którą projekt podjął się wspólny zespół programistów z obu organizacji. Nasi partnerzy zastosowali metodologię rozwoju skoncentrowaną na użytkowaniu GUI i zignorować automatyzację testów. W rezultacie powstał system, który obfitował w niezbyt imponującą grafikę i nieprawidłowo obliczał wynagrodzenie dla większości pracowników. Taki system potrzebowałby około 100 dni na wygenerowanie miesięcznej listy płac. Zdaliśmy sobie sprawę, że program, który napisaliśmy, nigdy tak naprawdę nie zostanie użyty.

Skontaktowaliśmy się z Kent Beck, aby pomóc dostroić wydajność systemu. Znalazł w nas te same zjawiska, z którymi stale się spotyka, podejmując się zadania dostrajania wydajności: źle zaprojektowany kod, testy, których nie można powtórzyć, kierownictwo, które straciło zaufanie do swojego projektu. Kent Beck zalecił wyrzucenie całego kodu, który został napisany i rozpoczęcie pełnego projektu XP.

Poprzednia umowa została rozwiązana, a Chrysler prawie w połowie zaktualizował swój zespół programistów. Od tego momentu działaliśmy zgodnie z zasadami XP. Przypisano obowiązki, zaplanowano iteracje, ustalono zasady testowania, przetestowano programowanie w parach i przyjęto jako standard. Pod koniec 33. tygodnia mieliśmy system, w którym mogliśmy już zacząć debugować wydajność i przeprowadzać równoległe testy. Mogliśmy zacząć poprawiać wydajność, ponieważ system był dobrze przemyślany i posiadał kopię zapasową komplet testy jednostkowe. Byliśmy gotowi do testów równoległych, ponieważ seria testów funkcjonalnych jasno pokazała klientowi, że system posiada wymagane możliwości.

Ta faza wdrożenia C3 rozpoczęła się w maju 1997 r., chociaż przewidywaliśmy wcześniejszą datę. Niepowodzenie naszych planów było spowodowane dwoma czynnikami. Najpierw postanowiliśmy wymienić tylko elementy wewnętrzne system płatności. Wszystkie zewnętrzne interfejsy pozostały nietknięte. Dopasuj wyjście nowy system elementy starego okazały się znacznie więcej wymagające zadanie niż się spodziewaliśmy. Po drugie, postanowiliśmy nie wprowadzać specjalnych wymagań w żadnym okresie rozliczeniowym, takich jak przetwarzanie W-2, podział zysków lub ogólna podwyżka. wynagrodzenie. W rezultacie to, co należało zrobić w listopadzie, zostało przesunięte na kwiecień.

Od czasu uruchomienia systemu naliczania płatności miesięcznych dodaliśmy kilka nowych funkcji oraz automatyczne naliczanie płatności co dwa tygodnie. Lista płac dla grupy pilotażowej jest obliczana od sierpnia 1998 r. i mamy nadzieję, że do listopada 1999 r. będziemy mieli działający system dla pozostałych pracowników.

Bazując na doświadczeniu zdobytym podczas tego długiego rozwoju, mogę powiedzieć, że nie spełniliśmy oczekiwań naszego kierownictwa i naszych klientów tylko wtedy, gdy odeszliśmy od zasad XP. Kiedy proces testowania stał się decydujący w toku rozwoju, kiedy pisaliśmy kod parami, kiedy wdrażano najprostsze, najprawdopodobniej działające funkcje, staliśmy się najlepszym zespołem, jaki mógł być.

Ford Motor: wyjątkowe połączenie wydajności i jakości

Don Wells

Zespół: 17 osób, w tym 12 programistów

Aplikacja: system analizy kosztów

Okres realizacji: 6 lat

Dział systemów finansowych Ford Motor Company opracowuje system analityczny Vehicle Costing and Profit System (VCAPS), który generuje raporty dotyczące przychodów z produkcji, wydatków, dochodu netto i zysku. Dane wejściowe do systemu to specyfikacje produktów inżynieryjnych, koszty stałe i wydatki oraz koszty zmienne, takie jak godziny pracy. VCAPS agreguje wszystkie te dane i przygotowuje szczegółowe raporty z analizą kosztów, które umożliwiają efektywne prognozowanie i podejmowanie decyzji w firmie. Prace nad projektem VCAPS rozpoczęły się w 1993 roku. Opracowany przy użyciu VisualWorks i GemStone Smalltalk. VCAPS jest obecnie utrzymywany przez niewielki zespół ludzi i wkrótce zostanie zastąpiony przez bardziej nowoczesną aplikację.

Realizując projekt VCAPS musieliśmy rozwiązać dwa poważne problemy. Po pierwsze, analitycy chcieli wprowadzić zmiany w systemie, jednocześnie uzyskując nowe funkcje, które już działały. Wymagania ciągle się zmieniały, a my po prostu nie mogliśmy za nimi nadążyć. Po drugie, istniały pewne ograniczenia dotyczące czasu działania systemu. Jednocześnie system poświęcał dużo czasu na przetwarzanie danych i wymagał ręcznego wprowadzania długich sekwencji. Każdy błąd prowadził do konieczności restartu i utraty cennego czasu.

Z pomocą XP osiągnęliśmy unikalną kombinację możliwości: byliśmy w stanie szybko reagować na stale zmieniające się wymagania i osiągnęliśmy jakość systemu, która pozwoliła nam uniknąć niebezpiecznych restartów.

Prace nad metodami XP rozpoczęły się od etapu planowania. I okazało się, że to pomyłka. Klienci i kierownictwo nie są przyzwyczajeni do wspólnego ustalania harmonogramów pracy. To, co wydarzyło się w rezultacie, było pozbawione wiarygodności i praktycznego zastosowania. Musieliśmy przejść na plany MS Project, które można było zmieniać bez umawiania walnych zgromadzeń, a za pomocą których otrzymywaliśmy plany w znanej zarządowi formie.

Następnie wykonaliśmy kilka testów jednostkowych i po roku przetestowano 40% systemu, a kierownictwo odnotowało 40% redukcję liczby komunikatów o błędach. Później szczególną uwagę poświęcono XP.

Rozwiązaliśmy problemy, wdrażając wszystkie nowe metody XP. Testy pozwoliły nam przejść do ciągłej integracji i częstych zmian wersji. To z kolei utorowało drogę do zbiorowej własności i przeprojektowania systemu. Naszym celem było stworzenie prostego projektu. Wreszcie nadszedł moment, w którym postanowiliśmy spróbować programować w parach. I musieliśmy ciężko pracować, aby osiągnąć ten sukces. Początkowo nasi programiści uznali tę metodę za wyjątkowo niewygodną; Zajęło mi trochę czasu, aby się do tego przyzwyczaić i poczuć w nim całkiem komfortowo.

Po półtora roku liczba awarii systemu spadła tak bardzo, że nasi klienci i kierownictwo mogli stwierdzić znacznie wyższą stabilność systemu. Dla nas symbolizowało to sukces zasad XP.

System Taryfowy: testy, które możesz przeczytać

Rob Mi

Zespół: trzech programistów

Aplikacja: system kalkulacji taryf transportowych,

Okres realizacji: 3 miesiące

System Taryfowy jest częścią dużego projektu realizowanego przy użyciu SmallTalk/GemStone w jednej z największych międzynarodowych firm specjalizujących się w transporcie kontenerowym. Podejście XP umożliwiło przejście przez wszystkie etapy rozwoju tego podsystemu, od koncepcji do uruchomienia, w trzy miesiące przez trzy osoby. Rezultat był niezwykle stabilny i łatwy w utrzymaniu.

Rozpoczynając pracę nad projektem, od razu postanowiliśmy mocno trzymać się kilku podstawowe zasady XP: zawsze koduj parami, utrzymuj architekturę tak prostą, jak to tylko możliwe, aktywnie przerabiaj system i pisz wiele testów jednostkowych. Wszystkie te zasady okazały się skuteczne. Jeden pomysł na XP wydawał nam się początkowo trochę naciągany - napisać testy kodu przed napisaniem właściwego kodu. Tym bardziej zaskoczyło nas, że ta zasada pozwala nam identyfikować problemy architektoniczne i przyspiesza proces tworzenia.

Od samego początku zastosowaliśmy inną metodę XP - zbieranie wymagań użytkowników w formie historyjek. Wyniki nie były całkowicie jednoznaczne. Jesteśmy programistami i zajmujemy się przede wszystkim kodowaniem, więc wyszukiwanie wspólny język z użytkownikami stało się dla nas wyzwaniem. Aby jeszcze bardziej skomplikować sprawę, chcieliśmy, aby historie użytkowników były zarówno istotne, jak i jednoznaczne, i aby to zrobić, musieli im aktywnie pomagać. W końcu doszliśmy do wniosku, że XP brakowało jednej specjalnej roli. Potrzebowaliśmy osoby, której głównym zadaniem będzie interakcja z użytkownikami. Oczywiście musi mieć odpowiednie umiejętności.

Tworząc i przerabiając przypadki testowe zdaliśmy sobie sprawę, że do pisania podstawowych obiektów domenowych bardzo przydatne będą wymyślone specjalnie dla nich małe języki, dzięki którym kod testowy stanie się znacznie bardziej zwięzły i czytelny. Ponadto przestaliśmy tracić czas na wymyślanie sposobów ustawiania instancji obiektów w procesie pisania testów oraz definiowaliśmy gramatyki dla dziesięciu klas domenowych. Gramatyka automatycznie generuje parser, który jest używany przez konstruktora do tworzenia obiektu domeny. Kod do tworzenia instancji obiektu przy użyciu standardowych konstruktorów będzie bardzo długi, prawie nieczytelny i mało podobny do samego przypadku testowego.

Obejmując zmiany z programowaniem ekstremalnym, Kent Beck. Komputer, październik 1999, s. 70-77, Przedruk za zgodą, Copyright IEEE, 1999, Wszelkie prawa zastrzeżone.

Extreme Programming (XP) to uproszczona metodologia tworzenia oprogramowania dla małych i średnich zespołów programistycznych tworzących oprogramowanie o niejasnych lub szybko zmieniających się wymaganiach.

Główne cele XP to: zwiększenie zaufania klientów do oprogramowania, dostarczając prawdziwy dowód sukcesu rozwoju procesu rozwoju i gwałtowne skrócenie czasu opracowywania produktu . Jednocześnie XP koncentruje się na minimalizowaniu błędów na wczesnych etapach rozwoju. Dzięki temu możliwe jest osiągnięcie prędkość maksymalna wydanie gotowego produktu i pozwala mówić o przewidywalności pracy. Prawie wszystkie techniki XP mają na celu poprawę jakości oprogramowania.

Zasady XP

Główne zasady to:

• Iteracja. Rozwój odbywa się w krótkich iteracjach w obecności aktywnej relacji z klientem. Proponuje się, aby iteracje jako takie były krótkie, zalecany czas trwania to 2-3 tygodnie i nie więcej niż 1 miesiąc. W jednej iteracji grupa programistów musi zaimplementować kilka funkcji systemu, z których każda jest opisana w historyjce użytkownika. Historyjki użytkownika (UI) w tym przypadku są wstępną informacją, na podstawie której tworzony jest moduł. Różnią się one od przypadków użycia (UT). Opis PI jest krótki - 1-2 akapity, podczas gdy PI jest zwykle dość szczegółowo opisany, z przepływami głównymi i alternatywnymi, i jest uzupełniony modelem. UI są pisane przez samych użytkowników, którzy w XP są częścią zespołu, w przeciwieństwie do UI, które są opisane przez analityka systemowego. Brak sformalizowania opisu danych wejściowych projektu w XP ma być zrekompensowany aktywnym włączeniem klienta w proces rozwoju jako pełnoprawny członek zespołu.
• Prostota rozwiązań. Przyjęto pierwsze najprostsze rozwiązanie robocze. Ekstremalny charakter metody wiąże się z wysoki stopień ryzyko decyzji ze względu na powierzchowność analizy i sztywny harmonogram. Minimalny zestaw głównych funkcji systemu jest implementowany przy pierwszej i każdej kolejnej iteracji; funkcjonalność jest rozszerzana w każdej iteracji.
• Intensywny rozwój przez małe zespoły(nie więcej niż 10 osób) i programowanie par(gdy dwóch programistów wspólnie tworzy kod w jednym miejscu pracy), aktywna komunikacja w grupie i między grupami. Wszystko to ma na celu jak najwcześniejsze wykrywanie problemów (zarówno błędów, jak i niedotrzymanych terminów). Programowanie w parach ma na celu rozwiązanie problemu stabilizacji projektu. Przy korzystaniu z metodologii XP istnieje duże ryzyko utraty kodu z powodu odejścia programisty, który nie wytrzymał napiętego harmonogramu pracy. W tym przypadku drugi programista z pary pełni rolę „spadkobiercy” kodu. Nie bez znaczenia jest również sposób rozmieszczenia grup w przestrzeni roboczej – XP korzysta z otwartej przestrzeni roboczej, co oznacza szybki i bezpłatny dostęp dla wszystkich dla wszystkich.
• Opinie klientów, którego przedstawiciel jest faktycznie zaangażowany w proces rozwoju.
• Wystarczający stopień odwagi i gotowość do podejmowania ryzyka.

Sztuczki XP (ćwiczenia)

Zazwyczaj XP charakteryzuje się zestawem 12 zasad (praktyk), których należy przestrzegać, aby osiągnąć dobry wynik. Żadna z praktyk nie jest zasadniczo nowa, ale łączy je w XP.

1. Planowanie procesu. Zbiera się cały zespół programistów, wspólnie podejmuje się decyzję, które cechy systemu zostaną zaimplementowane w kolejnej iteracji. O złożoności implementacji każdej właściwości decydują sami programiści.
2. Bliska interakcja z klientem. Przedstawiciel klienta musi być członkiem zespołu XP. Pisze interfejs użytkownika, wybiera historie, które zostaną zaimplementowane w określonej iteracji i odpowiada na pytania związane z biznesem. Przedstawiciel klienta musi być ekspert w zautomatyzowanym obszarze tematycznym. Konieczna jest stała informacja zwrotna od przedstawiciela klienta.
3. Ogólne zasady nazewnictwa systemów. Dobre konwencje nazewnictwa systemów łatwość nazewnictwa klasy i zmienne. Zespół programistów powinien mieć jednolite konwencje nazewnictwa.
4. Prosta architektura. Każda właściwość systemu powinna być zaimplementowana w możliwie najprostszy sposób. Programiści w zespole XP pracują pod hasłem: „Nic więcej!”. Przyjęto pierwsze proste rozwiązanie robocze, aktualnie wdrażany jest wymagany poziom funkcjonalności. Oszczędza to czas programisty.
5. Refaktoryzacja. Jest to optymalizacja istniejącego kodu w celu jego uproszczenia, taka praca powinna być wykonywana na bieżąco. Utrzymując przejrzystość kodu i definiując jego elementy tylko raz, programiści zmniejszają liczbę błędów, które muszą zostać później naprawione. Wdrażając każdą nową właściwość systemu, programista musi rozważyć, czy istniejący kod można uprościć i w jaki sposób pomoże to zaimplementować nową właściwość. Ponadto nie można łączyć refaktoryzacji z projektowaniem: jeśli tworzysz nowy kod, refaktoryzacja powinna zostać odroczona.
6. Programowanie w parach. Wszyscy programiści powinni pracować w parach: jeden pisze kod, drugi wygląda. Dlatego konieczne jest umieszczenie grupy programistów w jednym miejscu. XP najlepiej sprawdza się w nierozproszonych zespołach programistów i użytkowników.
7. 40-godzinny tydzień pracy. Programista nie powinien pracować dłużej niż 8 godzin dziennie. Potrzeba nadgodzin jest wyraźnym wskaźnikiem problemu w tym konkretnym obszarze rozwoju. Znalezienie przyczyn nadgodzin i ich szybka eliminacja to jedna z podstawowych zasad.
8. Własność zbiorowego kodu. Każdy programista w zespole musi mieć dostęp do kodu dowolnej części systemu oraz prawo do wprowadzania zmian w dowolnym kodzie. Obowiązkowa zasada: jeśli programista dokonał zmian i system nie działa po tym poprawnie, to ten programista musi poprawić błędy.
9. Jednolite standardy kodowania. Standardy kodowania są potrzebne do obsługi innych praktyk: udostępniania kodu, programowania w parach i refaktoryzacji. Bez jednego standardu wykonywanie tych praktyk jest przynajmniej trudniejsze, ale w rzeczywistości jest to generalnie niemożliwe: grupa będzie pracować w trybie ciągłego braku czasu. Zespół od dłuższego czasu pracuje nad projektem. Ludzie przychodzą i odchodzą. Nikt nie koduje sam, a kod należy do wszystkich. Zawsze będą chwile, kiedy trzeba będzie zrozumieć i poprawić czyjś kod. Deweloperzy będą usuwać zduplikowany kod, analizować i ulepszać klasy innych osób itd. Z czasem nie będzie można stwierdzić, kto jest autorem danej klasy. Dlatego każdy musi przestrzegać wspólnych standardów kodowania - formatowania kodu, klasy, zmiennej, stałego nazewnictwa, stylu komentarza. Powyższe oznacza, że ​​wszyscy członkowie zespołu muszą uzgodnić wspólne standardy kodowania. Nieważne co, ale każdy jest zobowiązany do ich posłuszeństwa.
10. Małe wydania. Minimalna iteracja to jeden dzień, maksymalna to miesiąc; im częściej publikowane są wydania, tym więcej usterek w systemie zostanie ujawnionych. Pierwsze wydania pomagają zidentyfikować braki na najwcześniejszych etapach, następnie funkcjonalność systemu jest rozbudowywana w oparciu o UI. Ponieważ użytkownik jest włączony w proces rozwoju od pierwszego wydania, ocenia system i wydaje historyjkę użytkownika oraz komentarze. Na tej podstawie określana jest kolejna iteracja, czyli jaka będzie nowa wersja. Wszystko w XP polega na dostarczaniu użytkownikom ciągłych informacji zwrotnych.
11. Ciągła integracja. Integracja nowych części systemu powinna następować tak często, jak to możliwe, przynajmniej raz na kilka godzin. Podstawowa zasada integracji jest następująca: integrację można przeprowadzić, jeśli wszystkie testy przejdą pomyślnie. Jeśli testy nie zakończą się pomyślnie, to programista musi albo wprowadzić poprawki, a następnie zintegrować elementy systemu, albo wcale ich nie integrować. Ta zasada jest sztywna i jednoznaczna. Jeżeli w tworzonej części systemu wystąpi co najmniej jeden błąd, to integracja nie może zostać przeprowadzona. Częsta integracja pozwala szybciej uzyskać gotowy system, zamiast spędzać tydzień na montażu.
12. Testowanie. W przeciwieństwie do większości innych metodologii, testowanie w XP jest jednym z najważniejszych komponentów. Skrajne podejście zakłada, że testy są pisane przed napisaniem kodu . Każdy moduł musi mieć test jednostkowy - test dla tego modułu. W ten sposób XP przeprowadza testy regresji, "nieponiżającą jakość" podczas dodawania funkcji. Większość błędów jest korygowana na etapie kodowania. Testy są pisane przez samych programistów, każdy z nich ma prawo napisać test dla dowolnego modułu. Kolejna ważna zasada: test określa kod, a nie odwrotnie (programowanie sterowane testami), czyli fragment kodu jest umieszczany w repozytorium wtedy i tylko wtedy, gdy wszystkie testy przeszły pomyślnie, w przeciwnym razie ta zmiana kodu jest odrzucana.

Proces XP jest nieformalny, ale wymaga wysokiego poziomu samodyscypliny. Jeśli ta zasada nie jest przestrzegana, XP natychmiast zamienia się w chaotyczny i niekontrolowany proces. XP nie wymaga od programistów pisania wielu raportów i budowania wielu modeli. W XP każdy programista jest uważany za wykwalifikowanego pracownika, który jest profesjonalny i odpowiedzialny za swoje obowiązki. Jeśli zespół tego nie posiada, wdrażanie XP jest absolutnie bezcelowe - lepiej zacząć odbudowywać zespół. Ryzyko rozwoju jest redukowane tylko w zespole, który jest idealnie dopasowany do XP, we wszystkich innych przypadkach XP jest procesem rozwoju o najwyższym stopniu ryzyka, ponieważ po prostu nie ma innych metod zmniejszania ryzyka komercyjnego, poza czynnikiem ludzkim, w XP.

I inni.

Nazwa metodyki wzięła się od idei stosowania użytecznego tradycyjne metody i praktyki tworzenia oprogramowania, podnosząc je na nowy, „ekstremalny” poziom. Czyli np. praktyka wykonywania rewizji kodu, która polega na sprawdzaniu przez jednego programistę kodu napisanego przez innego programistę, w wersji „ekstremalnej” to „programowanie w parach”, gdy jeden programista koduje, a jego partner na jednocześnie stale przegląda nowo napisany kod.

Encyklopedyczny YouTube

1 / 5

Programowanie ekstremalne (XP) — podstawowe techniki

Seminarium internetowe Hexlet nr 6: Ekstremalne programowanie

wskazówki dotyczące życia. Dlaczego brać udział w konkursach programistycznych?

032. Programowanie w parach - Sergey Berezhnoy

Ekstremalny kanał programowania v. 2,0

Napisy na filmie obcojęzycznym

Podstawowe sztuczki XP

The Twelve Basic Techniques of Extreme Programming (według pierwszego wydania książki) Wyjaśnienie programowania ekstremalnego) można podzielić na cztery grupy:

• Krótki cykl sprzężenia zwrotnego (sprzężenie zwrotne na dokładną skalę)
  • Rozwój poprzez testowanie (Test-driven development)
  • Planowanie gry
  • Klient jest zawsze obecny (Cały zespół, Klient na miejscu)
  • Programowanie par
• Proces ciągły, a nie wsadowy
  • Ciągła integracja
  • Refaktoryzacja (ulepszenie projektu, refaktoryzacja)
  • Częste małe wydania
• Zrozumienie dzielone przez wszystkich
  • Prostota
  • Metafora systemu
  • Własność zbiorowego kodu lub wybrane wzorce projektowe (własność zbiorowa wzorców)
  • Standard kodowania lub konwencje kodowania
• Ubezpieczenie społeczne programisty (opieka programisty):
  • 40-godzinny tydzień pracy (Zrównoważone tempo, 40-godzinny tydzień pracy)

Testowanie

XP polega na pisaniu testów automatycznych (kod programu napisany specjalnie w celu przetestowania logiki innego) kod programu). Szczególną uwagę zwraca się na dwa rodzaje testów:

• testowanie jednostkowe modułów;

Deweloper nie może być pewien poprawności napisanego przez siebie kodu, dopóki nie zadziałają absolutnie wszystkie testy jednostkowe tworzonego przez niego systemu. Testy jednostkowe (testy jednostkowe) pozwalają programistom upewnić się, że każdy z nich z osobna działa poprawnie. Pomagają również innym programistom zrozumieć, dlaczego dany fragment kodu jest potrzebny i jak działa - w trakcie badania kodu testowego logika testowanego kodu staje się jasna, ponieważ jasne jest, jak należy go używać. Testy jednostkowe pozwalają również programiście na refaktoryzację bez obaw.

Testy funkcjonalne mają na celu przetestowanie działania logiki utworzonej przez interakcję kilku (często dość imponujących rozmiarów) części. Są one mniej szczegółowe niż testy jednostkowe, ale obejmują o wiele więcej - czyli testy, które w swoim wykonaniu wpływają na większą ilość kodu, mają oczywiście większą szansę na wykrycie jakiegoś nieprawidłowego zachowania. Z tego powodu w programowaniu przemysłowym pisanie testów funkcjonalnych często ma pierwszeństwo przed pisaniem testów jednostkowych.

W przypadku XP podejście zwane TDD (od angielskiego test-driven development - rozwój poprzez testowanie) ma wyższy priorytet. Zgodnie z tym podejściem najpierw pisze się test, który początkowo zawodzi (ponieważ logika, którą powinien sprawdzić po prostu jeszcze nie istnieje), a następnie implementowana jest logika niezbędna do pomyślnego przejścia testu. TDD w pewnym sensie pozwala na napisanie kodu, który jest wygodniejszy w obsłudze - bo pisząc test, gdy nie ma jeszcze logiki, najłatwiej zadbać o wygodę przyszłego systemu.

Gra w planowanie

Głównym celem gry w planowanie jest szybkie ułożenie szorstkiego planu pracy i ciągłe aktualizowanie go, gdy warunki zadania stają się jaśniejsze. Artefakty gry planistycznej to zestaw papierowych kart zawierających życzenia klienta (historie klientów) i przybliżony plan pracy nad wydaniem następnej lub kilku mniejszych wersji produktu. Krytycznym czynnikiem, który sprawia, że ​​ten styl planowania jest skuteczny, jest to, że w tym przypadku klient jest odpowiedzialny za podejmowanie decyzji biznesowych, a zespół programistów jest odpowiedzialny za podejmowanie decyzji technicznych. Jeśli ta zasada nie jest przestrzegana, cały proces się rozpada.

Klient zawsze tam jest

„Klient” w XP to nie ten, który płaci rachunki, ale końcowy użytkownik oprogramowania. XP twierdzi, że klient musi być w kontakcie przez cały czas i być dostępny w przypadku pytań.

Programowanie par

Programowanie par zakłada, że ​​cały kod jest tworzony przez pary programistów pracujących na tym samym komputerze. Jeden z nich pracuje bezpośrednio z tekstem programu, drugi przygląda się swojej pracy i śledzi ogólny obraz tego, co się dzieje. W razie potrzeby klawiatura jest swobodnie przenoszona z jednej na drugą. Podczas pracy nad projektem pary nie są stałe: zaleca się ich mieszanie tak, aby każdy programista w zespole miał dobre rozeznanie w całym systemie. W ten sposób programowanie w parach zwiększa interakcję w zespole.

Ciągła integracja

Jeśli wystarczająco często integrujesz rozwijany system, możesz uniknąć większości związanych z nim problemów. W tradycyjnych metodach integracja z reguły odbywa się na samym końcu pracy nad produktem, kiedy uważa się, że wszystkie komponenty tworzonego systemu są w pełni gotowe. W XP integracja kodu całego systemu odbywa się kilka razy dziennie, po upewnieniu się przez programistów, że wszystkie testy jednostkowe działają poprawnie.

Refaktoryzacja

Refaktoryzacja to technika ulepszania kodu bez zmiany jego funkcjonalności. XP sugeruje, że raz napisany kod prawie na pewno będzie powtarzany wiele razy w trakcie projektu. Twórcy XP nieustannie przerabiają kod, który napisali wcześniej, aby go ulepszyć. Ten proces nazywa się refaktoryzacją. Brak pokrycia testowego prowokuje do odrzucenia refaktoryzacji ze względu na obawę przed złamaniem systemu, co prowadzi do stopniowej degradacji kodu.

Częste małe wydania

Wersje (wydania) produktu powinny jak najczęściej trafiać do produkcji. Praca nad każdą wersją powinna zająć jak najmniej czasu. Jednocześnie każda wersja powinna być wystarczająco znacząca pod względem użyteczności dla biznesu.

Im wcześniej zostanie wydana pierwsza działająca wersja produktu, tym wcześniej klient zacznie otrzymywać z tego tytułu dodatkowy zysk. Pamiętaj, że pieniądze zarobione dzisiaj są warte więcej niż pieniądze zarobione jutro. Im szybciej klient zacznie korzystać z produktu, tym szybciej programiści otrzymają od niego informację o tym, co spełnia wymagania klienta. Te informacje mogą być niezwykle pomocne przy planowaniu kolejnego wydania.

Łatwość projektowania

XP wynika z tego, że w trakcie pracy warunki problemu mogą się wielokrotnie zmieniać, co oznacza, że ​​tworzony produkt nie powinien być projektowany z góry całkowicie i kompletnie. Próba szczegółowego zaprojektowania systemu na samym początku pracy to strata czasu. XP sugeruje, że projektowanie jest tak ważnym procesem, że musi być wykonywane w sposób ciągły przez cały czas trwania projektu. Projekt należy wykonywać małymi krokami, uwzględniając stale zmieniające się wymagania. W każdym momencie powinieneś próbować użyć najprostszego projektu, który pasuje do bieżącego problemu i zmieniać go w miarę zmiany warunków problemu.

Metafora systemu

Architektura jest reprezentacją składników systemu i ich wzajemnych relacji. Deweloperzy muszą przeanalizować architekturę oprogramowania, aby zrozumieć, gdzie w systemie muszą dodać nową funkcjonalność i z czym nowy komponent będzie współpracował.

Metafora systemu jest analogiczna do tego, co większość technik nazywa architekturą. Metafora systemu daje zespołowi wyobrażenie o tym, jak obecnie działa system, gdzie dodawane są nowe komponenty i jaką formę powinny przybrać.

Wybór dobrej metafory ułatwia zespołowi programistycznemu zrozumienie działania systemu. Czasami nie jest to łatwe.

Standardy kodowania

Wszyscy członkowie zespołu muszą w trakcie pracy przestrzegać wymagań wspólnych standardów kodowania. A tym samym:

• członkowie zespołu nie tracą czasu na kłótnie o rzeczy, które faktycznie nie wpływają na szybkość pracy nad projektem;
• zapewnione jest skuteczne wdrażanie innych praktyk.

Jeśli zespół nie stosuje jednolitych standardów kodowania, deweloperom trudniej jest dokonać refaktoryzacji; przy zmianie partnerów w parach jest więcej trudności; ogólnie rzecz biorąc, postęp projektu jest trudny. W ramach XP należy zadbać o to, aby trudno było zrozumieć, kto jest autorem tego czy innego fragmentu kodu - cały zespół pracuje w sposób jednolity, jak jedna osoba. Zespół musi stworzyć zestaw zasad, a następnie każdy członek zespołu musi przestrzegać tych zasad podczas procesu kodowania. Lista zasad nie powinna być wyczerpująca ani zbyt obszerna. Zadaniem jest sformułowanie ogólnych wytycznych, które sprawią, że kod będzie zrozumiały dla każdego z członków zespołu. Standard kodowania powinien być początkowo prosty, a następnie, w miarę zdobywania doświadczenia przez zespół programistów, może stopniowo stać się bardziej złożony. Nie trzeba poświęcać zbyt wiele czasu na wstępne opracowanie normy.

Własność zbiorowa

Własność zbiorowa oznacza, że ​​każdy członek zespołu jest odpowiedzialny za cały kod źródłowy. W ten sposób każdy ma prawo do wprowadzania zmian w dowolnej części programu. Programowanie w parach wspiera tę praktykę: pracując w różnych parach, wszyscy programiści zapoznają się ze wszystkimi częściami kodu systemu. Ważną zaletą zbiorowego posiadania kodu jest to, że przyspiesza proces rozwoju, ponieważ gdy pojawi się błąd, każdy programista może go naprawić.