Shore J. - Agile Development. Filozofia programowania zwinnego.pdf

5 Spis tre ci Wprowadzenie ..............................................................................................................9 Cz I Zaczynamy 1. Dlaczego zwinne programowanie? ............................................................................ 19 Czym jest sukces? 20 Poza harmonogram 21 Znaczenie sukcesów na poziomie organizacji 22 Wkraczanie w wiat zwinnego programowania 23 2. Jak by zwinnym? ........................................................................................................25 Zwinne metody 26 Czy warto wymy la w asne metody? 27 Droga do mistrzostwa 27 Szukanie mentora 28 3. Zrozumie XP ...............................................................................................................29 Cykl ycia w XP 32 Zespó w XP 42 Poj cia zwi zane z XP 55 4. Wprowadzanie XP ....................................................................................................... 61 Czy XP to co dla nas? 61 Naprzód! 71 Ocena zwinno ci zespo u 83

6 S P S T R E C Cz II Stosowanie XP 5. My lenie ....................................................................................................................... 91 Programowanie w parach 93 Energiczna praca 102 Informacyjne miejsce pracy 107 Analizy przyczynowo-skutkowe 112 Retrospekcje 115 6. Wspó praca ................................................................................................................ 123 Zaufanie 126 Wspólna praca 137 Zaanga owanie prawdziwego klienta 147 Wspólny j zyk 152 Krótkie spotkania robocze 157 Standardy pisania kodu 161 Demonstracje iteracji 167 Raporty 174 7. Udost pnianie ............................................................................................................ 183 „W pe ni gotowe” 186 Brak b dów 191 Kontrola wersji 202 Dziesi ciominutowa kompilacja 211 Ci g a integracja 219 Wspó w asno kodu 229 Dokumentacja 234 8. Planowanie ................................................................................................................239 Wizja 241 Planowanie wydania 247 Gra planistyczna 262 Zarz dzanie ryzykiem 268 Planowanie iteracji 278 Zapas 293 Opowie ci 301 Szacowanie 309 9. Wytwarzanie .............................................................................................................323 Stopniowe zbieranie wymaga 325 Testy klienta 331 Wytwarzanie sterowane testami 339

S P S T R E C 7 Refaktoryzacja 360 Prosty projekt 372 Stopniowy rozwój projektu i architektury 380 Rozwi zania punktowe 391 Optymalizacja wydajno ci 395 Testy eksploracyjne 402 Cz III Mistrzostwo w dziedzinie programowania zwinnego 10. Warto ci i zasady ....................................................................................................... 415 Wspólne elementy 415 O warto ciach, zasadach i praktykach 416 Dalsza lektura 417 11. Usprawnianie procesu ............................................................................................... 419 Zrozumienie projektu 419 Dopracowywanie i adaptacja 420 amanie regu 421 12. Poleganie na ludziach ...............................................................................................425 Budowanie efektywnych zwi zków 425 Odpowiednie osoby do odpowiednich zada 427 Budowanie procesu dla ludzi 429 13. Eliminowanie marnotrawstwa ................................................................................. 431 Praca w ma ych, odwracalnych etapach 431 Szybkie wykrywanie niepowodze 433 Maksymalizacja liczby zada , których nie trzeba wykonywa 435 D enie do wysokiej przepustowo ci 436 14. Zapewnianie warto ci ...............................................................................................439 Wykorzystanie zwinno ci 439 Warto ma tylko kod gotowy do udost pnienia 441 Zapewnianie wyników biznesowych 442 Cz ste udost pnianie 444 15. D enie do doskona o ci technicznej .......................................................................447 Oprogramowanie nie istnieje 447 Projekt to narz dzie u atwiaj ce zrozumienie 448 Równowaga w projektach 449 Nienazwana cecha 449

8 S P S T R E C Doskona y projekt 450 Ogólne zasady projektowania 451 Zasady w praktyce 454 D enie do mistrzostwa 456 Literatura cytowana ..................................................................................................457 Skorowidz ..................................................................................................................463

9 Wprowadzenie Pytanie: Jak uda o ci si wyst pi w Carnegie Hall? Odpowied : Dzi ki praktyce, przyjacielu, dzi ki praktyce! Naszym celem jest przybli enie sztuki zwinnego wytwarzania oprogramowania (ang. agile development). Zwinne wytwarzanie oprogramowania, podobnie jak inne techniki programowania zespo owego, to przede wszystkim sztuka praktykowana przez ludzi, dlatego istotn rol odgrywaj cechy poszczególnych osób oraz interakcje mi dzy nimi. Aby opanowa zwinne wytwarzanie oprogramowania, trzeba nauczy si nieustannie ocenia wiele mo liwo ci i intuicyjnie wybiera najlepsz drog . W jaki sposób mo na posi tak trudn umiej tno ? Dzi ki praktyce! Niniejsza ksi ka jest przede wszystkim szczegó owym opisem jednego z podej do zwinnego wytwarzania oprogramowania: programowania ekstremalnego (ang. Extreme Programming — XP). Jest to praktyczny przewodnik, a rozs dne stosowanie si do przedstawionych tu porad pozwoli z powodzeniem zastosowa to podej cie w ka dym zespole lub pomo e ustali , e zwinne wytwarzanie oprogramowania w danej sytuacji nie jest najlepszym rozwi zaniem. Nast pnym zadaniem tej ksi ki jest pomoc w zg bieniu sztuki zwinnego wytwarzania oprogramowania. Pe ne opanowanie tej metodologii wymaga wyj cia poza zbiór omawianych praktyk. Zwinne programowanie w zbyt du ym stopniu zale y od kontekstu, aby jedno podej cie by o zawsze skuteczne. Istotnych jest tu zbyt wiele niuansów, aby mo na je by o opisa w jakiejkolwiek ksi ce. Mistrzostwo p ynie z wn trza; wynika z do wiadczenia i intuicyjnego zrozumienia skutków poszczególnych wyborów. Nie mo emy nauczy Czytelników, jaki wp yw ka da decyzja b dzie mia a na dan firm . Nawet nie próbujemy tego robi . To Czytelnik musi zadba o szczegó y i zrozumienie. To jedyna mo liwo , aby zg bi t sztuk . Nale y stosowa si do praktyk i obserwowa , co si dzieje. Trzeba przemy le , dlaczego pewne rozwi zania dzia aj lub nie, a nast pnie powtórzy proces. Co pozosta o takie samo, a co si zmieni o? Dlaczego? Nast pnie nale y jeszcze raz wykona te czynno ci. I jeszcze raz.

1 0 W P R O W A D Z E N E Na pocz tku zrozumienie sposobu wykonywania poszczególnych praktyk mo e sprawia trudno ci. Na papierze wygl daj na proste, jednak stosowanie ich jest zwykle trudniejsze. Nale y je powtarza do momentu, kiedy zespó nie b dzie mia problemów z ich wykonywaniem. Wraz z opanowywaniem XP mo e si okaza , e niektóre z proponowanych regu nie dzia aj w danym zespole. Na pocz tku trudno stwierdzi , czy problemem s same regu y, czy sposób ich realizacji. Nale y stosowa zasady do momentu, kiedy przyczyna trudno ci stanie si oczywista. Wtedy mo na z ama zasady i zmodyfikowa zalecane podej cie tak, aby lepiej przystawa o do danej sytuacji. W cz ciach I i II opisujemy proponowan przez nas wersj XP. Cz I pomaga rozpocz stosowanie programowania ekstremalnego. W cz ci II przedstawiamy szczegó owo wszystkie praktyki XP. Opanowanie tych dwóch cz ci wymaga wielu miesi cy pracy. Kiedy Czytelnik b dzie ju gotowy na z amanie regu , mo e przej do cz ci III. Krótkie ostrze enie: w cz ci III nie ma nic, co mo e pomóc w stosowaniu XP. Jest ona natomiast pe na przemy le , które u atwiaj pe niejsze zrozumienie XP i zwinnego wytwarzania oprogramowania. Pewnego dnia mo e si okaza , e regu y ju Czytelnika nie interesuj . W ko cu XP i zwinne wytwarzanie oprogramowania nie polegaj na stosowaniu si do zasad. Czytelnik stwierdzi: „Chodzi o prostot i informacje zwrotne, komunikacj i zaufanie. O zapewnianie warto ci i odwag do robienia odpowiednich rzeczy w odpowiednim czasie”. B dzie ci gle ocenia niezliczone mo liwo ci i intuicyjnie wybiera najlepsz drog . W tym momencie mo na przekaza ksi k innej osobie — nawet je li egzemplarz ma pozaginane rogi i nosi lady u ytkowania — aby tak e ona opanowa a sztuk zwinnego wytwarzania oprogramowania. Dla pragmatyków A co z tymi, którzy nie chc zg bia tej tak zwanej „sztuki”, a jedynie tworzy dobre oprogramowanie? Ta ksi ka jest przeznaczona tak e dla tych osób. Wystarczy im lektura cz ci I i II. Zebrali my lata do wiadcze w dziedzinie zwinnego wytwarzania oprogramowania i programowania ekstremalnego w jedno ci le zdefiniowane i kompletne podej cie. Takie nastawienie pozwala nam u ywa prostego, bezpo redniego j zyka bez dodatkowych wyja nie i dygresji. Przedstawiamy wiele praktycznych wskazówek. Uczciwie przyznajemy, kiedy omawiane podej cie nie dzia a i jakie inne mo liwo ci warto wtedy rozwa y . Opisywanie tylko jednego podej cia ma pewn wad : adna pojedyncza metodologia nie spe nia potrzeb wszystkich u ytkowników. Przedstawiane porady mog nie nadawa si dla danego zespo u lub nie dzia a w okre lonej sytuacji. Przed zastosowaniem wskazówek w praktyce nale y koniecznie zapozna si z rozdzia em 4. Je li zespó nie mo e zastosowa ca ego podej cia, czasem mo liwe jest wykorzystanie wybranych praktyk wchodz cych w sk ad XP. Punkty „Przeciwwskazania” przy ka dej praktyce omawianej w cz ci II zawieraj informacje o tym, kiedy nie nale y stosowa danej

O W P R A W K A C H 1 1 metody. Je li zespó stwierdzi, e warunki s niesprzyjaj ce, mo e zapozna si z punktem „Inne mo liwo ci”, aby dowiedzie si , jakich technik u y w zamian. Nie nale y posuwa si za daleko i automatycznie stwierdza , e dana praktyka nie b dzie dzia a w okre lonych okoliczno ciach. Niektóre pomys y opisane w tej ksi ce s sprzeczne z intuicj lub nie wygl daj na ciekawe. Wi kszo z nich dzia a najlepiej w po czeniu z pozosta ymi, dlatego je li jest to mo liwe, warto przez kilka miesi cy wypróbowa wszystkie metody w ich oryginalnej postaci, zebra praktyczne do wiadczenia i dopiero wtedy je modyfikowa . Stosujemy omawiane tu techniki od lat. W odpowiednim rodowisku s naprawd skuteczne. Zwinne wytwarzanie oprogramowania okaza o si ciekawsze i da o wi cej sukcesów ni jakiekolwiek inne podej cie do programowania zespo owego, które stosowali my. Zach camy do wypróbowania tej metodologii. Kto powinien przeczyta t ksi k ? Ta ksi ka przeznaczona jest dla wszystkich, którzy pracuj w zespole stosuj cym zwinne wytwarzanie oprogramowania, znajd si w takim zespole lub chc do niego do czy . Obejmuje to oczywi cie programistów, ale tak e ekspertów z dziedziny aplikacji, testerów, mened erów projektu, architektów, projektantów i analityków biznesowych. Zespo y stosuj ce omawiane podej cie s wielofunkcyjne, co uwzgl dniamy w tej ksi ce. Liderzy i inne osoby zainteresowane wprowadzeniem zwinnego wytwarzania oprogramowania w zespole lub organizacji powinny przeczyta t ksi k w ca o ci, od pocz tku do ko ca. Cz I jest wst pem do zagadnie zwi zanych ze zwinnym wytwarzaniem oprogramowania i opisuje wprowadzanie XP w zespole. Cz II zawiera szczegó owy opis poszczególnych praktyk XP. Cz III wykracza poza XP. Omawiamy tu zasady, które pozwalaj utworzy w asne zwinne metody przez przystosowanie XP do konkretnej sytuacji. Osoby, które chc dowiedzie si tylko tego, co b dzie im potrzebne w pracy, powinny skoncentrowa si przede wszystkim na cz ci II. Warto rozpocz od lektury rozdzia u 3. w cz ci I, aby pozna ogólny obraz podej cia, a nast pnie przej do tych praktyk w cz ci II, które zwi zane s z zadaniami danej osoby. Omówienie ka dej praktyki rozpoczyna si od przedstawienia osób, dla których jest przydatna. S to na przyk ad „Programi ci”, „Klienci” lub „Testerzy”. Osoby, które s po prostu zainteresowane zwinnym wytwarzaniem oprogramowania, powinny zacz od lektury cz ci I. Rozdzia 3. to dobre wprowadzenie do tematu. Nast pnie mog przejrze praktyki omówione w cz ci II, zaczynaj c od tych, które wygl daj na najciekawsze. Opisy praktyk mo na czyta w dowolnej kolejno ci. O wprawkach Czy Czytelnik s ysza kiedy , jak muzyk gra gamy? To w a nie wprawki (cho do nudne). S u one do nauki przez precyzyjne i staranne powtarzanie. W pewnym momencie mo na zaprzesta takich wicze , a umiej tno ci i tak pozostan .

1 2 W P R O W A D Z E N E Programowanie ekstremalne to wprawka do rozwoju oprogramowania. Mamy nadziej , e dzi ki stosowaniu XP tydzie po tygodniu Czytelnikom uda si opanowa zwinne wytwarzanie oprogramowania. W pewnym momencie praktyki zmieni si , ale zasady stoj ce u ich podstaw pozostan takie same. Oprócz ogólnej wprawki w postaci programowania ekstremalnego, przedstawiamy mini wprawki zwi zane z ka dym g ównym zagadnieniem zwinnego wytwarzania oprogramowania. Zespo y rozpoczynaj ce korzystanie z tego podej cia mog wiczy wprawki w celu poprawy swych umiej tno ci. Wraz z nabywaniem do wiadczenia warto spojrze na te wiczenia z szerszej perspektywy i wykorzysta je jako pomoc w po czeniu szczegó owych praktyk z cz ci II z ogólnymi zasadami z cz ci III. UWAGA Przedstawione wprawki s przydatne tak e zespo om, które obecnie nie stosuj XP. Aby wprawki by y skuteczne, nale y je przemy le . Ka da wprawka daje pewne informacje, jednak nie pokazuje, co z nimi zrobi . Trzeba przemy le poszczególne wiczenia. Czego Czytelnik si z nich nauczy ? Co by o irytuj ce, a co ciekawe? Jak zdobyta wiedza wp yn a na jako pracy? Jak Czytelnik chce wykorzysta zdobyte informacje? Bez uwagi i zastanowienia — czyli rozwagi — wprawki to jedynie gierki. UWAGA To nie przypadek, e do zg bienia sztuki zwinnego wytwarzania oprogramowania potrzebna jest rozwaga. Aby metodologia ta by a skuteczna, trzeba my le o czym wi cej ni tylko o praktykach XP. Przedstawione tu mini wprawki — zreszt podobnie jak wiczenia dla muzyków — dzia aj najlepiej, kiedy s powtarzane. Zaprojektowali my je tak, aby zajmowa y oko o pó godziny, dzi ki czemu mo na (i nale y) wiczy je ka dego dnia przynajmniej przez tydzie . wiczenia ze zwinnego programowania, inaczej ni wprawki muzyczne, s najbardziej skuteczne, kiedy wykonuje je ca y zespó . Im lepiej wszyscy jego cz onkowie zrozumiej proces i swoje miejsce w nim, tym wy szy b dzie poziom wspó pracy. Najpierw trzeba znale ciche miejsce pracy, w którym wygodnie zmieszcz si wszyscy cz onkowie zespo u. W pomieszczeniu powinna znajdowa si tablica lub ciana, na której mo na powiesi lub przypi karteczki. Potrzebna jest na tyle du a przestrze , aby mo na by o podzieli zespó na dwu- lub trzyosobowe grupy, których cz onkowie b d mogli po cichu rozmawia ze sob , nie przeszkadzaj c przy tym innym. Odkryli my, e warto u y czasomierza (stopera lub minutnika), aby sesja toczy a si p ynnie. Ka da wprawka sk ada si z kilku cz ci trwaj cych od 5 do 10 minut. Cho na pocz tku czas b dzie up ywa szybko, nale y przestrzega ogranicze . Nast pnego dnia zespó ponownie b dzie wykonywa wiczenie, dlatego nic si nie stanie, je li w ci gu jednej sesji nie uda si uko czy wszystkich zada . Nale y wyznaczy jednego z cz onków zespo u, aby usprawnia prac zespo u, kontroluj c czas (mo e na przyk ad informowa w odpowiednim momencie, e zosta a jedna minuta) i zach caj c do dyskusji. Pierwsza sesja mo e by trudna, jednak dobry moderator mo e zach ci wszystkich do dalszej pracy.

P O D Z K O W A N A 1 3 Zalecamy, aby po zako czeniu ka dej wprawki po wi ci kilka minut na podsumowanie. Czego zespó si nauczy ? Czy pojawi y si pytania lub pomys y, które warto uwzgl dni w pracy? Czy po powtarzaniu wicze przez tydzie zespó wci si poprawia? Osoby poznaj ce dopiero XP i zwinne wytwarzanie oprogramowania gor co zach camy do wykonywania ka dej wprawki w trakcie zespo owego zapoznawania si z poszczególnymi rozdzia ami. W czasie wykonywania wprawek mo na — oprócz poznawania poszczególnych zagadnie zwinnego wytwarzania oprogramowania — lepiej zobaczy , jak zespó pracuje w trakcie projektów prowadzonych z wykorzystaniem tego podej cia. O zaimkach W pozosta ych cz ciach ksi ki u ywamy raczej liczby pojedynczej ni mnogiej, pisz c w pierwszej osobie — piszemy „ja” zamiast „my”. Zamie cili my tu wiele osobistych anegdot i do wiadcze , przy których opisywaniu wygodniej stosowa liczb pojedyncz . Jednak ksi ka ta to bez w tpienia efekt wspó pracy dwóch autorów, a wykorzystanie formy „ja” wynika tylko z wygody. Przyk adowy kod Ta ksi ka zosta a napisana po to, aby pomaga w wykonywaniu zada . Czytelnik mo e u ywa przedstawionego tu kodu w programach i dokumentacji. Nie trzeba wyst powa o zezwolenie, je li wykorzystane fragmenty kodu nie s du e. Przyk adowo, napisanie programu zawieraj cego kilka kawa ków kodu z tej ksi ki nie wymaga pozwolenia. Jednak sprzeda lub rozpowszechnianie p yt CD-ROM z przyk adami z ksi ek wydawnictwa O’Reilly wymaga zezwolenia. Do udzielania odpowiedzi na pytania przez cytowanie ksi ki i przytaczanie przyk adowego kodu pozwolenie nie jest potrzebne. Trzeba jednak wyst pi o nie w przypadku umieszczania du ych fragmentów kodu w dokumentacji produktów. Doceniamy podawanie ród a kodu, ale nie wymagamy tego. Zwykle podawane dane obejmuj : autora, tytu , wydawc i numer ISBN. Na przyk ad: Agile Development. Filozofia programowania zwinnego, James Shore i Shane Warden, 2008, ISBN: 978-83-246-1614-5. Je li Czytelnik uwa a, e sposób wykorzystania przyk adowego kodu wykracza poza zasady dozwolonego u ytku, prosimy o kontakt pod nast puj cym adresem: permissions@oreilly.com. Podzi kowania Jeste my wdzi czni Elisabeth Hendrickson za wk ad w punkt „Testy eksploracyjne”. Jej do wiadczenie i umiej tno pisania sprawi y, e ten fragment to prawdziwa pere ka. Wi cej informacji o pracach Elisabeth mo na znale pod adresem http://www.testobsessed.com/. Podkradali my pomys y z wszystkich mo liwych róde . Kent Beck, Ron Jeffries i Ward Cunningham to autorzy wielu idei, które doprowadzi y do powstania XP, a my swobodnie korzystali my z ich prac. Kent Beck wprowadzi nas nie tylko do samego XP, ale te przedstawi pomys wicze w postaci wprawek. Ward Cunningham to autor poj cia „d ugu technicznego”,

1 4 W P R O W A D Z E N E z którego cz sto korzystamy. Seria artyku ów Briana Maricka, Agile Testing Directions1 , mia a wp yw na postrzeganie przez nas testów w zwinnym wytwarzaniu oprogramowania i roli testerów w zespo ach stosuj cych to podej cie. James przez pó roku pracowa z Joshu Keriewskim przy projekcie przemys owego XP (ang. Industrial XP — IXP)2 . Projekt ten by ród em wielu do wiadcze . Praktyka Wizja powsta a na podstawie praktyki Planowanie projektu z IXP. David Schwartz i Amy Schwab z firmy True North pgs, Inc.3 to autorzy u ywanej przez nas wersji Wizji, a tak e poj cia spo eczno projektowa. Prowadzone przez nich warsztaty Mastering Projects s doskona e. Zach camy wszystkich, którzy maj tak mo liwo , do wzi cia w nich udzia u. Dzi kujemy naszej redaktorce, Mary Tresler O’Brien, za wizj (kiedy by a potrzebna), zaufanie (w odpowiednich momentach) i terminy (kiedy trzeba by o nas postraszy ). Ta ksi ka nie by aby tym, czym jest, bez delikatnego sugerowania nam kierunków odmiennych od naszych pocz tkowych pomys ów. Podzi kowania nale si te ca ej armii korektorów. Zamie cili oni na li cie dyskusyjnej ponad tysi c komentarzy. Osoby, którym jeste my winni szczególn wdzi czno za ich rozbudowane uwagi, to: Adrian Howard, Adrian Sutton, Ann Barcomb, Andy Lester, Anthony Williams, Bas Vodde, Bill Caputo, Bob Corrick, Brad Appletown, Chris Wheeler, Clarke Ching, Da i Ingólfsson, Diana Larsen, Erik Petersen, George Dinwiddie, Ilja Preuß, Jason Yip, Jeff Olfert, Jeffrey Palermo, Jonathan Clarke, Keith Ray, Kevin Rutherford, Kim Gräsman, Lisa Crispin, Mark Waite, Nicholas Evans, Philippe Antras, Randy Coulman, Robert Schmitt, Ron Jeffries, Shane Duan, Tim Haughton i Tony Byrne. Specjalne podzi kowania nale si Brianowi Marickowi, Kenowi Pughowi i Markowi Streibeckowi za komentarze do kompletnego szkicu ksi ki. James Shore Wszystkie dzie a opieraj si na wcze niejszych dokonaniach. Mia em szcz cie sta na ramionach nie jednego, ale wielu gigantów. Bez wyj tkowych prac takich osób jak Kent Beck, Alistair Cockburn, Ward Cunningham, Tom DeMarco, Martin Fowler, Ron Jeffries, Timothy Lister, Steve McConnel i Gerald Weinberg moje zrozumienie procesu rozwoju oprogramowania by oby du o ubo sze. To dzi ki nim mog a powsta niniejsza ksi ka. Szczególnie dzi kuj Alistairowi Cockburnowi za wspania omy lne zaproszenie mnie do „okr g ego sto u” i wprowadzenie w spo eczno stosuj c zwinne wytwarzanie oprogramowania. O ile giganci umo liwili mi napisanie tej ksi ki, Kim Eaves i zespó z firmy Denali przystawili drabin . Bez ich gor cego wsparcia nigdy nie móg bym wypróbowa tego szalonego podej cia, jakim jest XP. Dzi kuj te Robowi Myersowi za zawsze przyjazne wys uchiwanie mych tyrad. Dzi kuj te wspó autorowi tej ksi ki i memu przyjacielowi, Shane’owi Wardowi. Ten projekt rozwin si ze 100-stronicowego drugiego wydania w 400-stronicow ceg , a Shane nie poskar y si ani razu. Dzi kuj za wytrzymanie ze mn . (A poza tym — wysz a nam niez a ksi ka). 1 http://www.testing.com/cgi-bin/blog/2004/05/26 2 http://www.industrialxp.org/ 3 http://www.projectcommunity.com/

P O D Z K O W A N A 1 5 Na zako czenie chc podzi kowa Neeru, mojej kochaj cej i cierpliwej onie. Zawsze s dzi em, e podzi kowania autorów dla ich rodzin to frazesy. Teraz ju je rozumiem. Nie uko czy bym tej ksi ki bez wsparcia ony. Shane Warden Dzi kuj Jimowi za dyskusje w trakcie pisania pierwszej wersji tej ksi ki (wysz o to jej na dobre) i za przekonanie mnie do sensu przygotowania drugiego wydania. Dzi kuj Allison i Andrew za narz dzia, których u ywa em przy pisaniu niniejszej ksi ki. Podzi kowania nale si te mej rodzinie za wsparcie (i za to, e nie narzekali zbytnio, kiedy siedzia em na górze i bardzo powoli pisa em), a tak e znajomym za wyci ganie mnie od czasu do czasu z domu. Dzi kuj równie wszystkim innym osobom, które wnios y wk ad w projekt Parrot i rozwój j zyka Perl 6. Nie wiadomie sta y si one wspó pracownikami, przyk adami i ofiarami opisanymi przy okazji niektórych pomys ów przedstawionych w tej ksi ce. Praca, któr razem wykonujemy, nie przestaje mnie zdumiewa .

1 6 W P R O W A D Z E N E

Cz I Zaczynamy

1 9 ROZDZIA 1 Dlaczego zwinne programowanie? Zwinne wytwarzanie oprogramowania (ang. agile development) jest popularne. Wszystkie „fajne” firmy korzystaj z tego podej cia: Google, Yahoo, Symantec, Microsoft i tak dalej1 . Znam firm , która zmieni a nazw na Agili-co tam, aby przy czy si do trendu. Organizacja ta zadzwoni a do mnie z pro b , abym usprawni ich „zwinne procesy”, które po dok adniejszej analizie okaza y si niczym wi cej jak zlecaniem programowania firmom zewn trznym w innym kraju ni zwykle. Oczekuj , e w bardzo niedalekiej przysz o ci w ofercie du ych firm konsultingowych pojawi si Certyfikowane zwinne procesy i Certyfikowani konsultanci do spraw zwinnego programowania. Prosz , nie dajcie si wci gn w ten ba agan. W 1986 roku Brooks zapowiedzia , e uniwersalne rozwi zania nie powstan , e do roku 1996 adna pojedyncza technologia ani technika zarz dzania nie doprowadzi do dziesi ciokrotnego wzrostu produktywno ci, niezawodno ci lub prostoty [Brooks]. I rzeczywi cie, nikomu si to nie uda o. Równie zwinne wytwarzanie oprogramowania nie jest uniwersalnym rozwi zaniem. Co wi cej, nie zalecam stosowania zwinnego programowania, je li ma s u y wy cznie zwi kszeniu produktywno ci. Zalety tego podej cia — tak e mo liwo cz stszego udost pniania oprogramowania — wynikaj z odmiennego trybu pracy, a nie z szybszego wykonywania zada . Cho wed ug anegdotycznych wzmianek zespo y stosuj ce zwinne programowanie wykazuj si ponadprzeci tn wydajno ci 2 , efekt ten nie powinien by g ówn przyczyn wprowadzania tego podej cia. Zespó potrzebuje czasu na opanowanie zwinnego wytwarzania oprogramowania. W trakcie nauki — a mo e to zaj kwarta lub dwa — cz onkowie grupy b d pracowa wolniej, a nie szybciej. Ponadto nacisk na produktywno czasem zach ca zespó do stosowania uproszcze i mniejszego rygoru w pracy, co mo e doprowadzi do spadku wydajno ci. 1 ród o: ró ne raporty u ytkowników na konferencjach po wi conych programowaniu ekstremalnemu i zwinnemu programowaniu. 2 Zobacz na przyk ad [Van Schooenderwoert], [Mah] i [Anderson 2006].

2 0 R O Z D Z A 1 D A C Z E G O Z W N N E P R O G R A M O W A N E ? Zwinne wytwarzanie oprogramowania jest obecnie modne, ale to nie powód, aby stosowa to podej cie. W trakcie podejmowania decyzji dotycz cej jego wprowadzenia wa na jest odpowied na tylko jedno pytanie. Czy zwinne wytwarzanie oprogramowania pomo e w osi ganiu wi kszych sukcesów? Kiedy zespó odpowie na to pytanie, b dzie wiedzia , czy powinien stosowa zwinne programowanie. Czym jest sukces? Tradycyjnie sukces uto samiany jest z dostarczeniem produktu na czas, w oczekiwanej cenie i zgodnie ze specyfikacj . Standish prezentuje kilka klasycznych definicji [Standish]: Udane „Oprogramowanie uko czono na czas, po oczekiwanych kosztach, z mechanizmami i funkcjami zgodnymi z wyj ciow specyfikacj ”. Z problemami „Oprogramowanie jest gotowe i dzia a, ale przekroczono bud et oraz harmonogram, a mechanizmy i funkcje s ubo sze ni w wyj ciowej specyfikacji”. Nieudane „W pewnym miejscu cyklu rozwoju rozwój oprogramowania anulowano”. Mimo popularno ci tych definicji, nie s one w pe ni poprawne. Projekt mo e by udany, nawet je li producent nie zarobi na nim ani grosza. Z kolei nawet je li przyniesie milionowe zyski, mo na go uzna za problematyczny. W magazynie „CIO” znajduje si komentarz do tej osobliwo ci: Nawet te projekty, które spe niaj wszystkie tradycyjne kryteria powodzenia — w zakresie czasu, bud etu i specyfikacji — mog okaza si nieudane, poniewa produkty nie s atrakcyjne dla u ytkowników lub w ostatecznym rozrachunku nie zapewniaj firmie korzy ci. […] Podobnie, projekty uznawane za nieudane wed ug tradycyjnych miar z bran y IT mog okaza si sukcesem, kiedy — mimo problemów w obszarze kosztów, czasu lub specyfikacji — system jest uwielbiany przez odbiorców i zapewnia nieoczekiwane korzy ci. Na przyk ad w firmie wiadcz cej us ugi finansowe nowy system […] zosta dostarczony z sze ciomiesi cznym opó nieniem i kosztowa ponad dwa razy wi cej, ni zak adano (ostateczny koszt wyniós 5,7 miliona dolarów). Jednak projekt zwi kszy elastyczno organizacji (po 13 miesi cach) i oceniono go jako wielki sukces. Wysoko umarzanych kredytów spad a o 33 miliony dolarów, a krótszy czas potrzebny na zapewnienie korzy ci i wy sza wydajno doprowadzi y do 50-procentowego wzrostu w liczbie jednocze nie prowadzonych testów strategii ci gania wierzytelno ci3 . 3 Nelson R. Ryan, Applied Insight — Tracks in the Snow, „CIO Magazine”. http://www.cio.com/archive/090106/ applied.html. Mimo popularno ci tych definicji, czego w nich brakuje.

P O Z A H A R M O N O G R A M 2 1 Poza harmonogram Sukces musi zale e od czego innego ni mieszczenie si w terminie, ale od czego? Kiedy by em dzieckiem, cieszy a mnie sama zabawa. Uwielbia em wyzwania zwi zane z programowaniem. Ka de uruchomienie aplikacji traktowa em jak wielkie zwyci stwo. Wtedy nawet program, który nie dzia a , traktowa em jak pewnego rodzaju sukces, je li tylko tworzenie go sprawia o mi rado . Powodzenie postrzega em g ównie w kategoriach osobistych nagród. Kiedy nabra em do wiadczenia, zacz em pisa bardziej skomplikowane programy i cz sto gubi em si w ich dzia aniu. Musia em porzuci niektóre projekty przed ich uko czeniem. Zacz em wierzy , e kluczem do sukcesu jest atwo konserwacji. Spostrze enie to potwierdzi o si , kiedy podj em prac i zacz em wspó pracowa z zespo ami innych programistów. By em z siebie dumny, kiedy napisa em kod, który by elegancki i atwy w konserwacji. Sukces oznacza wtedy doskona o techniczn . Niektóre projekty ko cz si niepowodzeniem mimo dobrego kodu. Nawet doskonale przeprowadzone projekty mog by nieciekawe dla u ytkowników. Doszed em do wniosku, e zespó projektowy, w którym pracuj , jest cz ci wi kszego systemu, obejmuj cego dziesi tki, setki, a nawet tysi ce osób. Produkty maj zapewnia zadowolenie ich wszystkich, a przede wszystkim tych, którzy odpowiadaj za wysoko mojej pensji. Dla osób, które op acaj prac , warto oprogramowania musi przewy sza jego koszty. Sukces oznaczania zapewnianie korzy ci firmie. Przedstawione definicje nie s ze sob sprzeczne. Wa ny jest sukces na wszystkich trzech poziomach (zobacz rysunek 1.1). Bez powodzenia na poziomie osobistym twórca b dzie mia problemy z umotywowaniem siebie i pracowników. Bez sukcesu technicznego kod ród owy w pewnym momencie za amie si pod swym ci arem. Przy braku powodzenia na poziomie organizacji mo e si okaza , e zespó nie jest ju potrzebny. Rysunek 1.1. Oblicza sukcesu

2 2 R O Z D Z A 1 D A C Z E G O Z W N N E P R O G R A M O W A N E ? Znaczenie sukcesów na poziomie organizacji Zespo y programistyczne cz sto zaniedbuj sukces na poziomie firmy na rzecz atwiejszego do osi gni cia powodzenia technicznego i osobistego. Nale y jednak pami ta o tym, e nawet je li dana osoba nie bierze odpowiedzialno ci za sukces organizacji, jej prze o eni oceniaj zespó na tym poziomie. Wy sza kadra zarz dzaj ca i dyrektorzy wykonawczy prawdopodobnie nie b d zwraca uwagi na to, czy oprogramowanie jest eleganckie, atwe w konserwacji, a nawet lubiane przez u ytkowników. Dla prze o onych licz si wyniki, czyli zwrot z inwestycji w projekt. Je li zespó nie osi ga sukcesów w tym obszarze, mened erowie podejm dzia ania, które zapewni powodzenie. Niestety, wy sza kadra zarz dzaj ca zwykle nie ma czasu lub odpowiedniej perspektywy, aby w ka dym projekcie stosowa wyrafinowane rozwi zania. Dlatego cz ciej u ywaj miecza ni skalpela i s usznie oczekuj , e to zespó projektowy zajmie si szczegó ami. Kiedy mened erowie s niezadowoleni z wyników zespo u, wyci gaj miecze. Najbardziej oczywisty obiekt ci to koszty. S dwa proste sposoby na ich zmniejszenie: bardzo krótkie terminy, które maj skróci czas wytwarzania, oraz zlecanie zada firmom maj cym siedziby w pa stwach o ni szych kosztach pracy. Mo na te zastosowa oba te rozwi zania jednocze nie. S to jednak nieeleganckie techniki. Krótkie terminy cz sto wyd u aj czas pracy zamiast go skraca [McConnell 1999, s. 220], a zlecanie zada firmom zewn trznym wi e si z ukrytymi kosztami [Overby]. Czy krótkie terminy i gro ba zlecenia zada firmom zewn trznym brzmi znajomo? Je li tak, pora na wzi cie przez zespó odpowiedzialno ci za sukces, i to nie tylko osobisty i techniczny, ale tak e na poziomie organizacji. CO CENI ORGANIZACJE? Cho warto n ektórych projektów wyn ka bezpo redn o ze sprzeda y, ko zy c organ zacj obejmuj tak e czynn k nne n dochody Projekty zapewn aj warto na w e e sposobów n e zawsze mo na wycen je w z otówkach groszach Mo na wyró n nast puj ce ród a warto c (obok dochodów oszcz dno c )4 odró n an e s od konkurencj ; kreowan e mark ; wzrost oja no c k entów; spe n an e wymaga prawnych; oryg na ne badan a; nformacje strateg czne 4 Oparte cz ciowo na [Danne i Cleland-Huang].

W K R A C Z A N E W W A T Z W N N E G O P R O G R A M O W A N A 2 3 Wkraczanie w wiat zwinnego programowania Czy zwinne wytwarzanie oprogramowania pomo e zespo owi w osi ganiu wi kszych sukcesów? Mo liwe. Zwinne programowanie koncentruje si osi ganiu celów osobistych, technicznych oraz organizacji. Je li zespó ma problemy w którym z tych obszarów, wdro enie zwinnego wytwarzania oprogramowania mo e okaza si pomocne. Sukces na poziomie organizacji Zwinne metody pozwalaj osi gn sukces na poziomie organizacji poprzez koncentracj na zapewnianiu warto ci i zmniejszaniu kosztów. Bezpo rednio przek ada si to na wy szy zwrot z inwestycji. Zwinne metody powoduj tak e wczesne ustalanie oczekiwa , dlatego je li projekt nie prowadzi do sukcesu organizacji, wiadomo o tym na tyle wcze nie, e mo na anulowa go przed poniesieniem wysokich nak adów. Zespo y stosuj ce zwinne programowanie zwi kszaj warto dzi ki w czeniu w prac ekspertów biznesowych i skoncentrowaniu wysi ków na podstawowych warto ciach, które projekt ma zapewnia organizacji. W projektach realizowanych zgodnie ze zwinnym podej ciem jako pierwsze przygotowywane s najbardziej warto ciowe funkcje, a zespó cz sto udost pnia nowe wersje, co znacznie zwi ksza warto . Kiedy zmieni si potrzeby biznesowe lub zespó zdob dzie nowe informacje, mo na zmieni kierunek prac, aby dostosowa go do zaistnia ej sytuacji. Do wiadczone zespo y stosuj ce zwinne podej cie poszukuj nieoczekiwanych mo liwo ci, które pozwol ulepszy plan dzia ania. Takie zespo y pozwalaj zmniejszy koszty. Po cz ci wynika to z doskona o ci technicznej. W najlepszych zwinnych projektach pojawia si tylko kilka b dów miesi cznie. Mniejsze jest tak e marnotrawstwo, co jest efektem wczesnego anulowania s abych projektów i zast powania kosztownych praktyk rozwoju prostszymi. Komunikacja w zwinnych zespo ach jest szybka i precyzyjna, a praca jest mo liwa nawet w przypadku nieobecno ci kluczowych osób. Cz onkowie regularnie kontroluj proces i nieustannie usprawniaj kod, dzi ki czemu konserwacja oprogramowania i wprowadzanie w nim poprawek s atwiejsze. Sukces techniczny Programowanie ekstremalne, czyli zwinna metoda, na której koncentruj si w tej ksi ce, szczególnie dobrze nadaje si do zapewniania sukcesu technicznego. Programi ci stosuj cy XP wspó pracuj ze sob , co pomaga im kontrolowa drobne szczegó y istotne w doskona ych produktach, a jednocze nie gwarantuje, e ka dy fragment kodu przejrz przynajmniej dwie osoby. Programi ci nieustannie integruj kod, co umo liwia zespo owi udost pnienie oprogramowania w ka dym momencie, kiedy ma to sens biznesowy. Ca y zespó koncentruje si na ca kowitym uko czeniu jednej funkcji przed przyst pieniem do pracy nad nast pn . Zapobiega to nieoczekiwanym opó nieniom w momencie udost pniania produktu i umo liwia swobodne zmienianie kierunku. Programowanie ekstremalne obejmuje, obok struktury rozwoju, zaawansowane praktyki techniczne, które prowadz do osi gni cia doskona o ci technicznej. Najbardziej znan technik jest wytwarzanie sterowane testami. Pomaga ono pisa kod, który dzia a dok adnie tak, jak programi ci tego oczekuj . Zespo y stosuj ce XP tworz tak e proste, nieustannie zmieniaj ce si projekty, które mo na atwo zmodyfikowa przy zmianie planów.

2 4 R O Z D Z A 1 D A C Z E G O Z W N N E P R O G R A M O W A N E ? Sukces osobisty Sukces osobisty jest, no có , osobisty. Zwinne programowanie mo e nie spe nia wszystkich wymaga w obszarze sukcesu osobistego. Jednak po przyzwyczajeniu si do tej techniki u ytkownik, niezale nie od zajmowanego stanowiska, prawdopodobnie odkryje wiele jej zalet. Kierownictwo i wy sza kadra zarz dzaj ca Te osoby doceni d ugowieczno oprogramowania i koncentracj zespo u na zapewnianiu wysokiego zwrotu z inwestycji. U ytkownicy, udzia owcy, eksperci z dziedziny i mened erowie produktu Te osoby doceni wp yw, jaki maj na kierunek rozwoju oprogramowania, a tak e koncentracj zespo u na dostarczeniu u ytecznych i warto ciowych programów oraz wysok cz stotliwo udost pniania wersji. Mened erowie produktu i projektu Mened erowie doceni mo liwo zmiany kierunku prac w obliczu nowych potrzeb biznesowych, zdolno zespo u do podejmowania i spe niania zobowi za oraz wy sze zadowolenie udzia owców. Programi ci Programi ci doceni wy sz jako pracy wynikaj c z podniesienia jako ci technicznej, wi kszego wp ywu na szacunki i harmonogramy oraz niezale no ci zespo u. Testerzy Testerzy doceni traktowanie ich jak pe noprawnych cz onków zespo u, mo liwo wp ywu na jako na wszystkich etapach projektu oraz bardziej wymagaj c i mniej schematyczn prac . Praca w zwinnych zespo ach to jeden z najprzyjemniejszych okresów w mojej karierze. Wystarczy, e wyobra sobie przyjacielsk atmosfer w zespole, który wspó pracuje w celu zaprojektowania i udost pnienia produktu o trwa ej warto ci, gdzie ka dy cz onek grupy z entuzjazmem przyczynia si do skutecznego dzia ania ca o ci. Wyobra sobie branie odpowiedzialno ci za dany obszar — techniczny, biznesowych lub zwi zany z zarz dzaniem — i zaufanie reszty zespo u do moich zawodowych s dów i umiej tno ci. Jak e przyjemne jest rozwi zywanie problemów projektowych i obserwowanie poprawy jako ci. Zwinne programowanie zmienia obraz bran y. Rozwój i udost pnianie oprogramowania w nowy sposób wymaga du o pracy i pomy lunku. Jednak je li zespó stosuje omawiane podej cie spójnie i przestrzegaj c wszelkich zasad, mo e uzyska niezwyk e wyniki. B dzie regularnie wytwarza naprawd warto ciowe oprogramowanie i ka dego tygodnia demonstrowa post py. Ponadto rozwój oprogramowania stanie si przyjemniejszy ni kiedykolwiek wcze niej. Wszyscy gotowi? Zaczynamy.

2 5 ROZDZIA 2 Jak by zwinnym? Co oznacza „bycie zwinnym”? Odpowied jest bardziej skomplikowana, ni mo e si wydawa . Zwinne wytwarzanie oprogramowania to nie specyficzny proces, który mo na zastosowa . aden zespó nie stosuje Zwinnej Metody. Nie ma czego takiego. Zwinne wytwarzanie oprogramowania to filozofia. To sposób my lenia o rozwoju oprogramowania. Podstawowym opisem tego podej cia jest manifest zwinno ci (ang. Agile Manifesto), obejmuj cy zbiór 4 warto ci (rysunek 2.1) i 12 zasad (rysunek 2.2). Rysunek 2.1. Warto ci zwinnej filozofii

2 6 R O Z D Z A 2 J A K B Y Z W N N Y M ? Rysunek 2.2. Zasady zwinnej filozofii Aby „by zwinnym”, trzeba realizowa warto ci i stosowa si do zasad zwinnego podej cia. Zwinne metody Metoda lub proces to sposób pracy. Kiedy pracownik wykonuje jakie zadanie, uczestniczy w procesie. Niektóre procesy s zapisane, na przyk ad opis sk adania mebli. Inne, na przyk ad sprz tanie mieszkania, s tworzone dora nie i nieformalne. Zwinne metody to procesy zgodne ze zwinn filozofi . Nale do nich na przyk ad programowanie ekstremalne i m yn (ang. scrum). Zwinne metody sk adaj si z pojedynczych elementów nazywanych praktykami. S to na przyk ad: stosowanie kontroli wersji, wyznaczanie standardów pisania kodu i cotygodniowe przedstawianie wersji demonstracyjnej udzia owcom. Wi kszo tych praktyk jest w u ytku od wielu lat. Zwinne metody cz je w wyj tkowy sposób: z naciskiem na elementy zgodne ze zwinn filozofi , z pomini ciem pozosta ych zagadnie i w po czeniu z kilkoma nowymi pomys ami. Efektem jest lekki i skuteczny zbiór wzajemnie wspomagaj cych si technik.

D R O G A D O M S T R Z O S T W A 2 7 Czy warto wymy la w asne metody? Skoro ustalone zwinne metody cz istniej ce praktyki, wiele osób mo e s dzi , e dobrym pomys em jest utworzenie w asnej zwinnej techniki przez po czenie praktyk z ró nych metod. Na pozór wydaje si to do atwe. Jest przecie wiele dobrych zwinnych praktyk, spo ród których mo na wybiera . Jednak je li u ytkownik nigdy wcze niej nie stosowa zwinnego programowania, tworzenie ca kiem nowej zwinnej metody to z y pomys . Podobnie jak programowanie to co wi cej ni pisanie kodu, zwinne wytwarzanie oprogramowania to co wi cej ni tylko praktyki. Praktyki to odzwierciedlenie le cych u ich podstaw zasad zwinnej filozofii, których szerszy opis zawiera cz III. Dopiero kiedy u ytkownik dog bnie zrozumie te zasady — czyli opanuje sztuk zwinnego wytwarzania oprogramowania — b dzie potrafi wybra odpowiednie praktyki. Zwinne praktyki cz sto maj dwie lub nawet trzy funkcje i rozwi zuj jednocze nie kilka problemów w rozwoju oprogramowania oraz wspomagaj si wzajemnie w pomys owy i zaskakuj cy sposób. Ka dy projekt i sytuacja s oczywi cie wyj tkowe, dlatego dobrym pomys em jest dostosowanie zwinnych metod do panuj cych warunków. Zamiast tworzy zwinn metod od podstaw, lepiej jest rozpocz od istniej cej, sprawdzonej techniki i stopniowo j usprawnia . Nale y dostosowa j do danej sytuacji, ustali , kiedy dzia a, a kiedy nie, spróbowa okre li , jak mo na j usprawni , a nast pnie powtórzy ca y proces od pocz tku. Tak post puj eksperci. Droga do mistrzostwa Podstawowym przes aniem tej ksi ki jest to, e opanowanie sztuki zwinnego wytwarzania oprogramowania wymaga praktycznego do wiadczenia w u ytkowaniu specyficznej, dobrze okre lonej zwinnej metody. Wybra em w tym celu programowanie ekstremalne. Podej cie to ma kilka zalet: Spo ród wszystkich znanych mi zwinnych metod XP jest najbardziej kompletne. K adzie si tu du y nacisk na praktyki techniczne, a podej cie to obejmuje te popularne praktyki zespo owe i strukturalne. XP to dobrze przetestowana metoda. Dost pne s tysi ce stron z obja nieniami, raportami z u ytkowania i krytyk . Mo liwo ci i ograniczenia tego podej cia s bardzo dobrze znane. Mam du o do wiadczenia w korzystaniu z XP, co umo liwia mi dzielenie si przemy leniami i praktycznymi wskazówkami, które pomog Czytelnikom atwiej zastosowa t metod . Aby opanowa sztuk zwinnego programowania — lub tylko pozna XP, aby osi gn wi ksze sukcesy — nale y wykona nast puj ce kroki: 1. Ustalenie, dlaczego zespó chce u ywa zwinnego programowania. Czy podej cie to sprawi, e zespó lub organizacja b d odnosi y wi ksze sukcesy? W jaki sposób? Mo liwe odpowiedzi zawiera podrozdzia „Wkraczanie w wiat zwinnego programowania” w rozdziale 1. 2. Okre lenie, czy podej cie opisane w tej ksi ce nadaje si dla danego zespo u. Wi cej informacji na ten temat zawiera podrozdzia „Czy XP to co dla nas?” w rozdziale 4.

2 8 R O Z D Z A 2 J A K B Y Z W N N Y M ? 3. Zastosowanie tak wielu praktyk XP, jak to mo liwe (zobacz rozdzia 4.). Praktyki XP wzajemnie si wspomagaj , dlatego dzia aj najlepiej, kiedy zespó stosuje je wszystkie. 4. Staranne i sta e stosowanie praktyk XP (zobacz cz II). Je li która z praktyk nie sprawdza si , nale y ci lej zastosowa si do opisu z ksi ki. Zespo y poznaj ce XP cz sto stosuj praktyki zbyt krótko. Nale y oczekiwa , e up ynie od dwóch do sze ciu miesi cy, zanim zespó w wystarczaj cym stopniu je opanuje. Nast pny okres od dwóch do sze ciu miesi cy jest potrzebny, aby praktyki te sta y si drug natur pracowników. 5. Kiedy zespó upewni si , e prawid owo stosuje XP — wymaga to kilku miesi cy pracy — mo e rozpocz eksperymenty i wprowadza zmiany, które nie s opisane w ksi ce (zobacz cz III). Przy ka dej modyfikacji nale y zaobserwowa , co si dzieje, a nast pnie wprowadzi dalsze poprawki. Szukanie mentora W czasie dostosowywania XP do istniej cych warunków zespó prawdopodobnie natrafi na problemy i wyzwania. Przedstawiam rozwi zania wielu cz sto spotykanych problemów, jednak mog wyst pi sytuacje, których nie opisuj . W takim przypadku potrzebny b dzie mentor, czyli niezale ny ekspert z obszaru sztuki zwinnego wytwarzania oprogramowania. UWAGA Je li uda si zaanga owa eksperta, aby bezpo rednio prowadzi zespó , to bardzo dobrze. Jednak nawet dla do wiadczonych coachów korzystne jest spojrzenie z dystansu w momencie wyst pienia problemów. Najtrudniejszym aspektem poszukiwa mentora jest znalezienie osoby z wystarczaj cym do wiadczeniem w obszarze zwinnego wytwarzania oprogramowania. Warto sprawdzi nast puj ce ród a: inne grupy stosuj ce XP w danej organizacji; inne firmy stosuj ce XP w okre lonym regionie; lokaln grup u ytkowników XP i zwinnych metod; konsultantów z dziedziny XP i zwinnego programowania; list dyskusyjn na temat XP: extremeprogramming@yahoogroups.com. Nie potrafi przewidzie wszystkich mo liwych problemów, jednak mog pomóc w ich dostrze eniu. W ksi ce umie ci em wiele porad podobnych do tej: „Je li nie mo na co tydzie zademonstrowa post pów, jest to wyra na oznaka problemów. Nale y zwolni prac na tydzie i ustali , co nie dzia a. Warto poprosi o pomoc mentora”. Kiedy sugeruj skorzystanie z pomocy mentora, mam na my li to, e prawid owe rozwi zanie zale y od szczegó ów konkretnej sytuacji. Mentor mo e pomóc w rozwi zaniu problemu i da wskazówki specyficzne dla warunków. Zespo y poznaj ce XP cz sto stosuj praktyki zbyt krótko.