Shore J Agile Development Filozofia programowania zwinnego

Spis treļci

Wprowadzenie ..............................................................................................................9

Czýļë I

Zaczynamy

1. Dlaczego zwinne programowanie? ............................................................................ 19 Czym jest sukces? Poza harmonogram Znaczenie sukcesów na poziomie organizacji Wkraczanie w Ĉwiat zwinnego programowania

20 21 22 23

2. Jak byë zwinnym? ........................................................................................................25 Zwinne metody Czy warto wymyĈlaè wäasne metody? Droga do mistrzostwa Szukanie mentora

26 27 27 28

3. Zrozumieë XP ...............................................................................................................29 Cykl Ĕycia w XP Zespóä w XP Pojöcia zwiñzane z XP

32 42 55

4. Wprowadzanie XP ....................................................................................................... 61 Czy XP to coĈ dla nas? Naprzód! Ocena zwinnoĈci zespoäu

61 71 83

5

Czýļë II

Stosowanie XP

5. Myļlenie ....................................................................................................................... 91 Programowanie w parach Energiczna praca Informacyjne miejsce pracy Analizy przyczynowo-skutkowe Retrospekcje

93 102 107 112 115

6. Wspóĥpraca ................................................................................................................ 123 Zaufanie Wspólna praca ZaangaĔowanie prawdziwego klienta Wspólny jözyk Krótkie spotkania robocze Standardy pisania kodu Demonstracje iteracji Raporty

126 137 147 152 157 161 167 174

7. Udostýpnianie ............................................................................................................ 183 „W peäni gotowe” Brak bäödów Kontrola wersji Dziesiöciominutowa kompilacja Ciñgäa integracja WspóäwäasnoĈè kodu Dokumentacja

186 191 202 211 219 229 234

8. Planowanie ................................................................................................................239 Wizja Planowanie wydania Gra planistyczna Zarzñdzanie ryzykiem Planowanie iteracji Zapas OpowieĈci Szacowanie

241 247 262 268 278 293 301 309

9. Wytwarzanie .............................................................................................................323 Stopniowe zbieranie wymagaþ Testy klienta Wytwarzanie sterowane testami 6

SP S TREĻC

325 331 339

Refaktoryzacja Prosty projekt Stopniowy rozwój projektu i architektury Rozwiñzania punktowe Optymalizacja wydajnoĈci Testy eksploracyjne

360 372 380 391 395 402

Czýļë III Mistrzostwo w dziedzinie programowania zwinnego 10. Wartoļci i zasady ....................................................................................................... 415 Wspólne elementy O wartoĈciach, zasadach i praktykach Dalsza lektura

415 416 417

11. Usprawnianie procesu ............................................................................................... 419 Zrozumienie projektu Dopracowywanie i adaptacja ãamanie reguä

419 420 421

12. Poleganie na ludziach ...............................................................................................425 Budowanie efektywnych zwiñzków Odpowiednie osoby do odpowiednich zadaþ Budowanie procesu dla ludzi

425 427 429

13. Eliminowanie marnotrawstwa ................................................................................. 431 Praca w maäych, odwracalnych etapach Szybkie wykrywanie niepowodzeþ Maksymalizacja liczby zadaþ, których nie trzeba wykonywaè DñĔenie do wysokiej przepustowoĈci

431 433 435 436

14. Zapewnianie wartoļci ...............................................................................................439 Wykorzystanie zwinnoĈci WartoĈè ma tylko kod gotowy do udostöpnienia Zapewnianie wyników biznesowych Czöste udostöpnianie

439 441 442 444

15. DéŜenie do doskonaĥoļci technicznej .......................................................................447 Oprogramowanie nie istnieje Projekt to narzödzie uäatwiajñce zrozumienie Równowaga w projektach Nienazwana cecha

447 448 449 449

SP S TREĻC

7

Doskonaäy projekt Ogólne zasady projektowania Zasady w praktyce DñĔenie do mistrzostwa

450 451 454 456

Literatura cytowana ..................................................................................................457 Skorowidz ..................................................................................................................463

8

SP S TREĻC

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.

9

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

10

WPROWADZEN E

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ñ.

O WPRAWKACH

11

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.

12

WPROWADZEN E

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: [email protected].

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”,

PODZ üKOWAN A

13

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/

14

WPROWADZEN E

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è.

PODZ üKOWAN A

15

16

WPROWADZEN E

Czýļë I Zaczynamy

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].

19

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ñ”.

Mimo popularnoĈci tych definicji, czegoĈ w nich brakuje.

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.

20

ROZDZ AĤ 1

D ACZEGO ZW NNE PROGRAMOWAN E?

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

POZA HARMONOGRAM

21

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 x odróŜn an e s ý od konkurencj ; x kreowan e mark ; x wzrost oja noļc k entów; x speĥn an e wymagaħ prawnych; x oryg na ne badan a; x nformacje strateg czne

4

Oparte czöĈciowo na [Danne i Cleland-Huang].

22

ROZDZ AĤ 1

D ACZEGO ZW NNE PROGRAMOWAN E?

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.

WKRACZAN E W ĻW AT ZW NNEGO PROGRAMOWAN A

23

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.

24

ROZDZ AĤ 1

D ACZEGO ZW NNE PROGRAMOWAN E?

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 25

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.

26

ROZDZ AĤ 2

JAK BYê ZW NNYM?

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: x 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. x 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.

x 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.

DROGA DO M STRZOSTWA

27

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 Zespoäy poznajñce XP czösto miesiöcy, zanim zespóä w wystarczajñcym stosujñ praktyki zbyt krótko. 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: x inne grupy stosujñce XP w danej organizacji; x inne firmy stosujñce XP w okreĈlonym regionie; x lokalnñ grupö uĔytkowników XP i zwinnych metod; x konsultantów z dziedziny XP i zwinnego programowania; x listö dyskusyjnñ na temat XP: [email protected].

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.

28

ROZDZ AĤ 2

JAK BYê ZW NNYM?

ROZDZIAĤ 3

Zrozumieë XP

„Witamy w zespole, Patryku” — powiedziaäa Kasia, uĈmiechajñc siö do ĈwieĔo upieczonego absolwenta. „Pozwól, Ĕe ciö oprowadzö. Jak juĔ wspomniaäam w czasie rozmowy, stosujemy programowanie ekstremalne. Niektóre rzeczy mogñ róĔniè siö od tego, czego nauczyäeĈ siö w szkole”. „Nie mogö siö doczekaè, kiedy zacznö” — powiedziaä Patryk. „W szkole uczestniczyäem w kursie z inĔynierii oprogramowania, gdzie poznaäem cykl Ĕycia oprogramowania. Miaäo to duĔo sensu. Prowadzñcy wspominaä teĔ o XP, jednak odniosäem wraĔenie, Ĕe polega to gäównie na pracy w parach i rozpoczynaniu od pisania testów. Czy rzeczywiĈcie tak jest?”. „Nie do koþca” — odpowiedziaäa Kasia. „Programujemy w parach i najpierw piszemy testy, jednak XP to coĈ znacznie wiöcej. MoĔesz zadawaè mi pytania. WyjaĈniö ci, czym XP róĔni siö od tego, czego siö nauczyäeĈ”. Patryk zastanawiaä siö przez chwilö. „Jednñ z rzeczy, które pamiötam z kursu, jest to, Ĕe wszystkie metody rozwoju opierajñ siö na nastöpujñcym cyklu wytwarzania oprogramowania: analizy, projektowanie, pisanie kodu i testy (rysunek 3.1). W której fazie obecnie siö znajdujecie? Na etapie analiz? Projektowania? A moĔe pisania kodu lub testowania?”. „Tak!” — uĈmiechnöäa siö Kasia, nie mogñc powstrzymaè siö przed odrobinñ popisywania siö. „Nie rozumiem. W której z nich?”. „We wszystkich. Pracujemy nad analizami, projektem, pisaniem kodu oraz testami. Równolegle. Aha, ponadto co tydzieþ instalujemy oprogramowanie”. Patryk wyglñdaä na zdezorientowanego. Czy rozmówczyni stroi sobie z niego Ĕarty? Kasia zaĈmiaäa siö — „Sam zobaczysz! ChodĒ, oprowadzö ciö”. „To jest pokój, w którym pracujemy. Jak widzisz, wszyscy siedzimy w jednym duĔym pomieszczeniu. Uäatwia to wspóäpracö”. Kasia zaprowadziäa Patryka do duĔej tablicy, przy której staä möĔczyzna przyglñdajñcy siö dziesiñtkom karteczek. „Borys, poznaj Patryka, naszego nowego programistö. Borys to menedĔer produktu. Nad czym obecnie pracujesz?”.

29

Rysunek 3.1. Tradycyjny cykl Ĕycia

„Staram siö ustaliè, jakie zmiany naleĔy wprowadziè w planie wydaþ w odpowiedzi na informacje z zeszäotygodniowego spotkania z uĔytkownikami. Bardzo podoba im siö nasza dotychczasowa praca, jednak majñ teĔ kilka naprawdö dobrych pomysäów. Staram siö ustaliè, czy ich propozycje sñ warte przeäoĔenia na póĒniej prac nad funkcjñ, którñ mieliĈmy zaczñè rozwijaè w przyszäym tygodniu. Nasze sukcesy sprawiäy, Ĕe zostaliĈmy dostrzeĔeni w firmie, dlatego zaczynajñ pojawiaè siö nowe Ĕñdania. Muszö wymyĈliè, jak zachowaè tok pracy bez zraĔenia zbyt wielu osób”. „Wyglñda na ciöĔkie zadanie” — stwierdziäa Kasia. „MoĔesz wiöc powiedzieè, Ĕe pracujesz nad wymaganiami, prawda?”. „Pracujö nad uszczöĈliwianiem udziaäowców” — Borys wzruszyä ramionami, obracajñc siö do tablicy. „Nie zwracaj na niego uwagi” — wyszeptaäa Kasia do Patryka, kiedy odeszli. „Pracuje pod duĔñ presjñ. Caäy projekt to jego pomysä. Zaoszczödziä dla firmy juĔ ponad dwa i póä miliona, jednak obecnie znaczenie zaczynajñ mieè pewne kwestie polityczne. Na szczöĈcie my, programiĈci, nie musimy siö tym przejmowaè. Borys i Renata zajmñ siö wszystkim — Renata to menedĔer projektu”. „Chwileczkö! MyĈlaäem, Ĕe to Borys jest menedĔerem projektu?”. „Nie, Borys to menedĔer produktu. Podejmuje decyzje na temat tego, co bödziemy tworzyè — oczywiĈcie z pomocñ udziaäowców i innych czäonków zespoäu. Z kolei Renata to menedĔer projektu. Dba o to, aby praca przebiegaäa päynnie. Pomaga zarzñdowi zrozumieè, czym siö zajmujemy, i zaäatwia potrzebne sprawy. Na przykäad przekonaäa dziaä infrastruktury, aby usunñä Ĉcianki miödzy komórkami, dziöki czemu mamy wygodne otwarte pomieszczenie robocze”. „Pozwól, Ĕe przedstawiö ci kilku innych czäonków zespoäu” — ciñgnöäa Kasia, prowadzñc Patryka do dwóch osób siedzñcych przy komputerze. „To Maria i Jacek. Maria to inĔynier mechanik. Zwykle pracuje w dziale produkcji, jednak poprosiliĈmy jñ, aby doäñczyäa do nas

30

ROZDZ AĤ 3

ZROZUM Eê XP

jako przedstawiciel klienta na czas tego projektu. PomoĔe nam zrozumieè problemy, jakie wystöpujñ w miejscu pracy. Jacek to jeden z naszych testerów. Jest szczególnie dobry w wykrywaniu braków w wymaganiach. Hej, to Patryk, nasz nowy programista”. Patryk kiwnñä gäowñ na powitanie. „Chyba wiem, czym siö zajmujecie. To wyglñda na dokumentacjö wymagaþ”. „CoĈ w tym rodzaju” — odpowiedziaä Jacek. „Sñ to testy przygotowane przez klientów na potrzeby tej iteracji. Pomogñ nam ustaliè, czy oprogramowanie robi to, co powinno”. „Testy klientów?” — zapytaä Patryk. „Tak naprawdö sñ to przykäady” — odpowiedziaäa Maria. „Ten konkretny zestaw dotyczy gäównie rozmieszczenia przedmiotów w magazynie. Chcemy, aby najczöĈciej uĔywane rzeczy byäy najbardziej dostöpne, jednak trzeba uwzglödniè takĔe inne warunki. Przedstawiamy przykäady róĔnych sposobów wyboru przedmiotów i ich przechowywania”. „MoĔesz zobaczyè, jak przebiega praca” — podjñä Jacek. „Popatrz, przetestujö te przykäady”. Jacek wcisnñä klawisz na klawiaturze i na ekranie pojawiäa siö kopia dokumentu. Niektóre fragmenty byäy zaznaczone na zielono, podczas gdy inne — na czerwono. „ZauwaĔ, Ĕe wczesne przykäady sñ zaznaczone na zielono. Oznacza to, Ĕe programiĈci juĔ je opracowali. PóĒniejsze przykäady sñ czerwone, poniewaĔ dotyczñ wyjñtkowych warunków, dla których programiĈci nie napisali jeszcze kodu. A ten tutaj jest zupeänie nowy. Maria zwróciäa uwagö na pewne warunki brzegowe, których nie uwzglödniliĈmy w odpowiedni sposób. Niektóre z tych przypadków sñ juĔ gotowe — sñ zaznaczone na zielono — jednak inne wymagajñ jeszcze nieco pracy. Musimy poinformowaè o nich programistów”. „W zasadzie moĔesz juĔ to zrobiè” — stwierdziäa Maria, a wszyscy usäyszeli zduszone przekleþstwo z okolic tablicy. „Wyglñda na to, Ĕe Borysowi przyda siö pomoc przy planie wydaþ. Miäo byäo ciö poznaè, Patryku”. „ChodĒ” — powiedziaä Jacek. „Przedstawimy ciö z Kasiñ innym programistom”. „Pewnie” — odpowiedziaä Patryk. „Jednak najpierw powiedz mi coĈ o dokumencie, nad którym pracujesz. Czy zawiera on wymagania, czy testy?”. „I to, i to” — odpowiedziaä Jacek z bäyskiem w oku. „A jednoczeĈnie ani jedno, ani drugie. To po prostu sposób na upewnienie siö, Ĕe trudne zadania zostanñ prawidäowo wykonane. Czy to waĔne, jak nazwiemy ten dokument?”. „Mam wraĔenie, Ĕe doĈè luĒno do tego podchodzisz” — stwierdziä Patryk. „W zeszäym roku byäam na staĔu w firmie, w której nikt nawet nie pomyĈlaäby o rozpoczöciu pisania kodu przed zatwierdzeniem wymagaþ i projektu. A ty nagle dodajesz funkcje i poprawiasz wymagania w trakcie pisania kodu!”. „Jest to wystarczajñco szalone, aby dziaäaäo” — powiedziaä Jacek. „Inaczej mówiñc” — dodaäa Kasia — „kiedyĈ teĔ mieliĈmy formalne bramki procesowe i stosowaliĈmy zatwierdzanie. SpödzaliĈmy caäe dnie na dyskusjach na temat najdrobniejszych szczegóäów w dokumentach. Obecnie koncentrujemy siö na prawidäowym wykonywaniu odpowiednich zadaþ, a nie na dokumentach. Wymaga to duĔo mniej pracy. Na wszystkich etapach — od ustalania wymagaþ do udostöpnienia produktu — pracujemy wspólnie, dlatego popeäniamy mniej bäödów i potrafimy äatwiej rozwiñzywaè problemy”.

CYK

śYC A W XP

31

„Ze mnñ byäo trochö inaczej” — dodaä Jacek. „Nie pracujö tu tak däugo jak Kasia. W mojej poprzedniej firmie w ogóle nie mieliĈmy struktury pracy. Ludzie po prostu robili to, co uznali za säuszne. Na poczñtku to podejĈcie nawet siö sprawdzaäo, jednak po kilku latach pojawiäy siö olbrzymie problemy z jakoĈciñ. MieliĈmy nieustanne problemy z realizacjñ terminów i ciñgle pojawiaäy siö niespodzianki, które uniemoĔliwiaäy udostöpnienie oprogramowania na czas. Jednak tu moĔemy robiè to, co uwaĔamy za säuszne, a struktura jest wystarczajñco Ĉcisäa, aby kaĔdy mógä zrozumieè, co siö dzieje, oraz osiñgaè staäe postöpy”. „To znacznie uäatwia nam pracö” — entuzjastycznie stwierdziäa Kasia. „Potrafimy zrobiè teraz duĔo wiöcej…” „…oraz nasza praca ma wyĔszñ jakoĈè” — dokoþczyä Jacek. „Musisz uwaĔaè na Kasiö — ona chyba nigdy nie przestanie nawijaè o tym, jak wspaniale jest wspólnie pracowaè” — Jacek uĈmiechnñä siö szeroko. „Tak naprawdö ma racjö. To naprawdö Ĉwietne przeĔycie. Teraz chodĒmy powiedzieè innym programistom o nowych przykäadach, które dodaäem z Mariñ”.

Cykl Ŝycia w XP Jednñ z najbardziej zdumiewajñcych zalet XP jest moĔliwoĈè wyeliminowania etapu zbierania wymagaþ, projektowania i testowania, a takĔe zwiñzanych z nimi formalnych dokumentów. Tak dalece róĔni siö to od tego, czego programiĈci zwykle uczñ siö o rozwoju oprogramowania, Ĕe wiele osób uwaĔa, iĔ to tylko czcze fantazje. „Ludzie od XP najwyraĒniej nie wiedzñ, o czym mówiñ” — stwierdzajñ. „Nie dalej jak w zeszäym miesiñcu uczestniczyäem w projekcie, który siö nie powiódä z uwagi na niewystarczajñce wymagania i projekt. Potrzebujemy wiöcej wymagaþ, projektów i testów, a nie mniej!”. To prawda. W projektach rozwoju oprogramowania rzeczywiĈcie potrzebnych jest wiöcej wymagaþ, projektów i testów. Dlatego zespoäy stosujñce XP pracujñ nad tymi elementami codziennie. Naprawdö, kaĔdego dnia. W XP istotna jest wspóäpraca twarzñ w twarz. Jest to rozwiñzanie tak wydajne w zakresie eliminacji opóĒnieþ w komunikacji i nieporozumieþ, Ĕe zespóä nie potrzebuje odröbnych faz. UmoĔliwia to codziennñ pracö nad wszystkimi elementami i równolegäe przechodzenie przez etapy, jak przedstawia to rysunek 3.2.

Rysunek 3.2. Cykl Ĕycia w XP

32

ROZDZ AĤ 3

ZROZUM Eê XP

Dziöki równolegäym etapom zespoäy stosujñce XP co tydzieþ udostöpniajñ oprogramowanie, które moĔna zainstalowaè. W kaĔdej iteracji pracownicy analizujñ, projektujñ, piszñ kod, testujñ i instalujñ podzbiór funkcji. Choè to podejĈcie nie zawsze zwiöksza wydajnoĈè zespoäu1, powoduje, Ĕe zespóä duĔo czöĈciej otrzymuje informacje zwrotne. Dziöki temu pracownicy mogñ äatwo powiñzaè sukcesy i poraĔki z ich przyczynami. IloĈè niesprawdzonej pracy jest bardzo maäa, co umoĔliwia bäyskawiczne poprawianie niektórych bäödów, na przykäad wtedy, kiedy w czasie pisania kodu programista wykryje usterkö projektowñ lub kiedy klient stwierdzi w czasie przeglñdu, Ĕe ukäad interfejsu uĔytkownika jest maäo zrozumiaäy i nieelegancki. ćcisäa pötla informacji zwrotnych umoĔliwia zespoäom stosujñcym XP szybkie usprawnianie planów. DuĔo äatwiej jest klientom dopracowaè pomysä na funkcjö, jeĈli mogñ zaĔñdaè jej dodania i rozpoczñè pracö z dziaäajñcym prototypem juĔ po kilku dniach. To samo dotyczy testów, projektów i zasad pracy zespoäu. Wszelkie informacje uzyskane na jednym etapie mogñ zmieniè sposób myĈlenia o dalszym rozwoju oprogramowania. JeĈli pracownik wykryje usterkö projektowñ w czasie pisania kodu lub przeprowadzania testów, moĔe uĔyè tej wiedzy w trakcie dalszej pracy nad wymaganiami i projektem systemu w nastöpnych iteracjach.

Jak to dziaĥa? Zespoäy stosujñce XP wykonujñ równolegle niemal wszystkie zadania zwiñzane z rozwojem oprogramowania. Analizy, projektowanie, pisanie kodu, testowanie, a nawet instalowanie odbywajñ siö bardzo czösto. Oznacza to jednoczesne wykonywanie wielu czynnoĈci. W XP odbywa siö to w ramach iteracji, czyli tygodniowych etapów pracy. KaĔdego tygodnia zespóä trochö planuje, nieco projektuje, pisze czöĈè kodu, przeprowadza kilka testów i tak dalej. Ludzie pracujñ nad opowieĈciami (ang. stories). Sñ to bardzo maäe funkcje lub ich fragmenty, majñce wartoĈè dla klientów. KaĔdego tygodnia zespóä zobowiñzuje siö do opracowania od czterech do dziesiöciu opowieĈci. W tym czasie jego czäonkowie pracujñ nad wszystkimi etapami rozwoju kaĔdej z nich. Pod koniec tygodnia instalujñ oprogramowanie na potrzeby wewnötrznego przeglñdu. W niektórych przypadkach wdraĔajñ rozwiñzanie w siedzibie klienta. PoniĔsze punkty pokazujñ miejsce tradycyjnych, opartych na etapach czynnoĈci w iteracjach modelu XP.

Planowanie KaĔdy zespóä stosujñcy XP obejmuje kilku ekspertów biznesowych — przedstawicieli klienta (ang. on-site customer) — którzy odpowiadajñ za podejmowanie decyzji biznesowych. Przedstawiciele klienta sterujñ projektem w odpowiednim kierunku, wyjaĈniajñc wizjö, tworzñc opowieĈci, budujñc plan wydaþ i zarzñdzajñc ryzykiem. ProgramiĈci przedstawiajñ szacunki i sugestie, które sñ äñczone z priorytetami klienta w procesie zwanym grñ planistycznñ (ang. the planning game). Zespóä wspólnie stara siö przygotowaè maäe, czöste wydania, co sprzyja maksymalizacji wartoĈci produktu. 1

Niezwykle trudno jest zbadaè produktywnoĈè. Nie znam zbyt wielu formalnych badaþ nad produktywnoĈciñ zespoäów stosujñcych XP, ale anegdotyczne dowody wskazujñ na to, Ĕe zwinne zespoäy sñ bardziej wydajne od tradycyjnych.

CYK

śYC A W XP

33

Wysiäki zwiñzane z planowaniem sñ najbardziej intensywne w czasie kilku pierwszych tygodni trwania projektu. PóĒniej klienci wciñĔ przeglñdajñ i poprawiajñ wizjö oraz plan wydaþ, aby uwzglödniè nowe moĔliwoĈci i nieoczekiwane zdarzenia. Oprócz ogólnego planu wydaþ zespóä tworzy na poczñtku kaĔdej iteracji szczegóäowy plan na najbliĔszy tydzieþ. Zespóä codziennie pokrótce omawia postöpy na krótkim spotkaniu roboczym, a miejsce pracy sprzyjajñce wymianie informacji sprawia, Ĕe wszyscy znajñ stan projektu.

Analizy Zamiast okreĈlaè wymagania w czasie fazy analiz poprzedzajñcej dalsze prace, zespóä przez caäy czas wspóäpracuje z przedstawicielami klienta. Czasem sñ to prawdziwi klienci, ale nie musi tak byè — zaleĔy to od typu projektu. Jednak zawsze sñ to osoby, które potrafiñ doskonale okreĈliè, co oprogramowanie powinno robiè. Przedstawiciele klienta odpowiadajñ za okreĈlanie wymagaþ stawianych oprogramowaniu. UĔywajñ przy tym wäasnej wiedzy, którñ majñ jako klienci, a takĔe tradycyjnych technik zbierania wymagaþ. Kiedy programiĈci potrzebujñ informacji, po prostu zadajñ pytanie. Klienci sami odpowiadajñ za organizacjö swej pracy i muszñ byè gotowi, kiedy inni czäonkowie zespoäu poproszñ o informacje. Klienci okreĈlajñ ogólne wymagania zwiñzane z opowieĈciñ przed przedstawieniem przez programistów szacunków dotyczñcych pracochäonnoĈci, a nastöpnie podajñ szczegóäowe wymagania przed rozpoczöciem pisania kodu. Niektóre wymagania sñ skomplikowane lub trudne do zrozumienia. Klienci formuäujñ je w bardziej formalny sposób przy pomocy testerów, tworzñc testy klienta, czyli szczegóäowe, automatycznie sprawdzane przykäady. Klienci i testerzy przygotowujñ testy klienta dla opowieĈci mniej wiöcej w tym samym czasie, kiedy programiĈci piszñ jej kod. Aby uäatwiè komunikacjö, programiĈci uĔywajñ w projekcie i kodzie zrozumiaäego jözyka. Wyglñd i styl interfejsu uĔytkownika (UI) trudno jest zaprojektowaè przy uĔyciu automatycznych testów klienta. W trakcie prac nad UI klienci uczestniczñ w tworzeniu szkiców ekranów aplikacji. W niektórych przypadkach klient wspóäpracuje z programistami przy tworzeniu ekranów za pomocñ kreatorów UI. Niektóre zespoäy obejmujñ projektanta interakcji, który odpowiada za UI aplikacji.

Projektowanie i pisanie kodu W XP projekty i architektura sñ tworzone stopniowo. WiñĔe siö to z ciñgäym tworzeniem i usprawnianiem projektu w maäych krokach. SäuĔy do tego wytwarzanie sterowane testami (ang. test-driven development — TDD). Proces ten äñczy nierozerwalnie testowanie, pisanie kodu, projektowanie i rozwój architektury. Aby uäatwiè przebieg tego procesu, programiĈci pracujñ w parach, co zwiöksza iloĈè mocy umysäowych poĈwiöcanych kaĔdemu zadaniu i gwarantuje, Ĕe jedna osoba zawsze ma czas pomyĈleè o bardziej ogólnych zagadnieniach projektowych. ProgramiĈci odpowiadajñ takĔe za zarzñdzanie Ĉrodowiskiem programistycznym. UĔywajñ systemu kontroli wersji do zarzñdzania konfiguracjñ i konserwujñ automatycznñ kompilacjö. Co kilka godzin ma miejsce integracja kodu, a programiĈci muszñ siö upewniè, Ĕe technicznie moĔliwa jest instalacja kaĔdej zintegrowanej wersji.

34

ROZDZ AĤ 3

ZROZUM Eê XP

Aby uäatwiè sobie pracö, programiĈci stosujñ standardy pisania kodu i wspóädzielñ go. Zespóä stosuje jeden sposób formatowania kodu, a wszyscy odpowiadajñ za rozwiñzywanie problemów w kodzie niezaleĔnie od tego, kto jest jego autorem.

Testy Metody XP obejmujñ zaawansowany zestaw praktyk zwiñzanych z testowaniem. KaĔdy czäonek zespoäu — programista, klient i tester — ma wpäyw na jakoĈè oprogramowania. W gotowych produktach przygotowanych przez sprawny zespóä stosujñcy XP pojawia siö tylko kilka bäödów miesiöcznie. ProgramiĈci to pierwsza linia obrony w wytwarzaniu sterowanym testami. Proces TDD prowadzi do utworzenia automatycznych testów jednostek i testów integracji. W niektórych przypadkach programiĈci mogñ przygotowaè takĔe testy kompleksowe. Pomagajñ one upewniè siö, Ĕe oprogramowanie dziaäa zgodnie z zamierzeniami programistów. Z kolei testy klienta pomagajñ zagwarantowaè, Ĕe zamiary programistów odpowiadajñ oczekiwaniom klientów. Klienci kontrolujñ toczñce siö prace, aby upewniè siö, Ĕe UI dziaäa w oczekiwany sposób. Tworzñ teĔ automatyzowane póĒniej przez programistów przykäady, które odzwierciedlajñ skomplikowane reguäy biznesowe. Testerzy pomagajñ zespoäowi ustaliè, czy wysiäki programistów doprowadziäy do powstania kodu wysokiej jakoĈci. UĔywajñ testów eksploracyjnych do wyszukiwania niespodzianek i luk w oprogramowaniu. Kiedy testerzy znajdñ bäñd, zespóä przeprowadza analizy przyczynowoskutkowe i zastanawia siö, jak usprawniè proces, aby zapobiec wystñpieniu podobnych bäödów w przyszäoĈci. Testerzy badajñ takĔe pozafunkcjonalne cechy oprogramowania, na przykäad wydajnoĈè i stabilnoĈè. Klienci mogñ nastöpnie uĔyè tych informacji do zdecydowania, czy naleĔy utworzyè dodatkowe opowieĈci. Zespóä nie przeprowadza Ĕadnych röcznych testów regresji. TDD i testy klienta prowadzñ do utworzenia rozbudowanego zestawu automatycznych testów regresji. Po znalezieniu bäödów programiĈci przygotowujñ automatyczne testy niezbödne do upewnienia siö, Ĕe dane usterki zostaäy naprawione. Taki zestaw wystarcza, aby zapobiec wystñpieniu regresji. Za kaĔdym razem, kiedy programiĈci przeprowadzajñ integracjö (czyli co kilka godzin), uruchamiajñ caäy zestaw testów regresji, aby sprawdziè, czy któraĈ z funkcji programu nie przestaäa dziaäaè. Zespóä stosuje teĔ dodatkowe techniki na rzecz zapewnienia jakoĈci: programowanie w parach, energicznñ pracö i zapas w iteracjach. Te praktyki zwiökszajñ wĈród czäonków zespoäu moc umysäowñ dostöpnñ do tworzenia oprogramowania wysokiej jakoĈci.

Instalowanie W zespoäach stosujñcych XP oprogramowanie jest gotowe do instalacji pod koniec kaĔdej iteracji. Instalowanie programów na potrzeby wewnötrznych udziaäowców odbywa siö kaĔdego tygodnia w ramach przygotowaþ do cotygodniowej prezentacji iteracji. WdraĔanie oprogramowania w siedzibie prawdziwych klientów ma miejsce wtedy, kiedy wymagajñ tego potrzeby biznesowe. Dopóki zespóä jest aktywny, dopóty konserwuje oprogramowanie, które udostöpniä. W niektórych organizacjach zespóä moĔe takĔe Ĉwiadczyè pomoc technicznñ w zakresie utworzonego programu (wtedy przydaje siö „batman”; zobacz podrozdziaä „Planowanie iteracji” w rozdziale 8.). W innych sytuacjach odpowiada za to odröbny zespóä obsäugi

CYK

śYC A W XP

35

technicznej. Po zakoþczeniu projektu takĔe obowiñzki zwiñzane z konserwacjñ moĔe przejñè inny zespóä. W takim przypadku oryginalny zespóä powinien w ciñgu kilku ostatnich tygodni pracy przygotowaè dokumentacjö i przeprowadziè niezbödne szkolenia.

PRAKTYKI XP NA POSZCZEGÓLNYCH ETAPACH abe a 3 1 pokazuje, jak praktyk XP w éŜé s ý z tradycyjnym etapam Na eŜy pam ýtaë, Ŝe XP op era s ý na teracjach, a n e na fazach Zespóĥ w kaŜdym tygodn u wykonuje wszystk e aktywnoļc , a w ýkszoļë z n ch — codz enn e Tabela 3.1. Praktyki XP w poszczególnych etapach Praktyka XP

Projektowan e p san e kodu

Testy

+

+

+

+

Planowan e

Anal zy

Ene giczna p aca

+

+

nfo macyjne miejsce p acy

+

Analizy p zyczynowo skutkowe

+

+

Ret ospekcje

+

+

WdraŜan e

Myļlen e P og amowanie w pa ach

+

Wspóĥpraca Zaufanie

+

+

+

+

Wspólna p aca

+

+

+

+

ZaangaŜowanie p awdziwego klienta

+

Wspólny jýzyk

+

K ótkie spotkania obocze

+

Standa dy pisania kodu

+

Demonst acja ite acji Rapo ty

+

+ +

+

+

+

+

Udostýpn an e „W peĥni gotowe”

+

+

B ak bĥýdów

+

Kont ola we sji

+

Dziesiýciominutowa kompilacja

+

+

Ciégĥa integ acja

+

+

Wspóĥwĥasnoļë kodu

+

Dokumentacja

+

Planowan e Wizja

+

+

Planowanie wydaħ

+

+

G a planistyczna

+

+

36

ROZDZ AĤ 3

+

ZROZUM Eê XP

Praktyka XP

Planowan e

Za zédzanie yzykiem

+

Anal zy

Projektowan e p san e kodu

Planowanie ite acji

+

+

Zapas

+

+

Opowieļci

+

Szacowanie

+

Testy

WdraŜan e

+

Wytwarzan e Stopniowe ok eļlanie wymagaħ

+

Testy klienta

+

+ +

Wytwa zanie ste owane testami

+

Refakto yzacja

+

P osty p ojekt

+

Stopniowe two zenie p ojektu i a chitektu y

+

Rozwiézania punktowe

+

Optymalizacja wydajnoļci

+

Testy eksplo acyjne

+

+

Historii ciég dalszy „Proszö o uwagö! Poznajcie Patryka, naszego nowego programistö” — gäoĈno powiedziaäa Kasia. Kasia, Jacek i Patryk podeszli do kilku duĔych stoäów. MoĔna byäo na nich zauwaĔyè porozrzucane karteczki i däugopisy. Na Ĉcianach wisiaäy tablice. SzeĈciu programistów pracowaäo w parach przy trzech stanowiskach. „Witaj, Patryku” — zespóä odpowiedziaä chórem. Kasia przedstawiäa wszystkich. „Witamy na pokäadzie” — powiedziaä Janek, jeden z programistów. Wstaä i podniósä Ĕóätego gumowego kurczaka ze stoäu obok. „Integrujemy dziĈ z Karolem zmiany, które wprowadziliĈmy” — poinformowaä pozostaäych czäonków grupy. Kilka osób, które wróciäy juĔ do swych zadaþ, odruchowo pokiwaäo gäowñ. „WprowadziliĈmy z Mariñ kilka zmian w testach klienta” — powiedziaä Jacek. „Kto pracuje nad opowieĈciñ dotyczñcñ magazynu?”. „My” — powiedziaä Janek. „O co chodzi?”. „DodaliĈmy kilka przykäadów uwzglödniajñcych nowe warunki brzegowe. Sñ doĈè proste, jeĈli jednak bödziesz miaä jakieĈ pytania, daj znaè”. „Pewnie” — odpowiedziaä Janek. „Swojñ drogñ, juĔ prawie skoþczyliĈmy ostatni fragment logiki biznesowej do tej opowieĈci. Jak tylko to zrobimy, zajmiemy siö przykäadami”. „Dziöki!”. Jacek skierowaä siö do Marii i Borysa, którzy stali przy tablicy planistycznej.

CYK

śYC A W XP

37

„Janku, moĔesz poĈwiöciè mi kilka minut, zanim zaczniesz nastöpne zadanie?” — zapytaäa Kasia. Janek spojrzaä pytajñco na swego partnera z pary, Karola, który przysäuchiwaä siö rozmowie. Karol potwierdziä, podnoszñc kciuk do góry. „Pewnie. I tak czekamy wäaĈnie na ukoþczenie testów kompilacji”. „ćwietnie” — powiedziaäa Kasia. „Pomagam Patrykowi zorientowaè siö w nowej pracy. Chciaä dowiedzieè siö, na jakim etapie rozwoju obecnie siö znajdujemy. Czy moĔesz wyjaĈniè, czym siö teraz zajmujesz?”. Janek rzuciä Patrykowi peäne zrozumienia spojrzenie. „Stara siö zrozumieè „równolegäe etapy”, co? Przepraszam” — rozeĈmiaä siö. „Tylko Ĕartujö, KaĈka! To naprawdö coĈ trochö innego. Jestem pewien, Ĕe Kasia nie moĔe siö doczekaè, aĔ powiem: tak, jednoczeĈnie przeprowadzamy testy, projektujemy, piszemy kod i integrujemy go. Instalujemy oprogramowanie co tydzieþ, a poniewaĔ jest to rozwiñzanie wewnötrzne, wdraĔamy program w Ĉrodowisku produkcyjnym, jednak dzieje siö to automatycznie. Prawdziwa praca nad instalacjñ polega na aktualizowaniu skryptów instalacyjnych, co robimy w ciñgu tygodnia, kiedy jest to potrzebne. Obecnie razem z Karolem integrujemy kod, co wszyscy robiñ co kilka godzin. WczeĈniej stosowaliĈmy wytwarzanie sterowane testami i refaktoryzacjö do równoczesnego testowania, pisania kodu i projektowania”. Janek wskazaä innñ parö przy stanowisku. „Jurek i Sara robiñ dokäadny przeglñd opowieĈci, którñ skoþczyliĈmy wczoraj. Sara pracuje jako tester i jest bardzo dobra w testach eksploracyjnych”. Janek spojrzaä na trzeciñ parö, która z zaangaĔowaniem rozmawiaäa ze sobñ i szkicowaäa coĈ na tablicy. „Wyglñda na to, Ĕe Marek i Ala rozwiñzujñ jakiĈ wiökszy problem projektowy. Stosujemy stopniowy rozwój projektu i architektury, dlatego nieustannie poszukujemy sposobów na ulepszenie projektów”. Ala rozejrzaäa siö po sali. „Mamy tu coĈ, czemu powinna przyjrzeè siö caäa grupa. Czy mogö prosiè wszystkich o uwagö?”. „Pewnie” — powiedziaä Jurek, odsuwajñc siö od biurka. Popatrzyä na partnerkö, która przytaknöäa. „I tak potrzebowaliĈmy przerwy”. Kiedy Ala zaczöäa rysowaè coĈ na tablicy, Patryk zastanawiaä siö nad tym, co zobaczyä. Borys zajmowaä siö planowaniem. Jacek i Maria pracowali nad wymaganiami i testami — nie, nad przykäadami. Karol i Janek integrowali kod, a kilka minut wczeĈniej przeprowadzali testy, projektowali i pisali kod. Marek i Ala zajmowali siö projektowaniem. Z kolei Jurek i Sara przeprowadzali dalsze testy. Jednak nie wyglñdaäo to tak prosto. Wszystko wydawaäo siö päynne. Czäonkowie zespoäu pracowali co chwilö nad czymĈ innym. Jacek i Maria cofnöli siö od okreĈlania wymagaþ do planowania, a wszyscy programiĈci przeskakujñ miödzy integracjñ i testami a projektowaniem. Patryk zmarszczyä brwi. Jak moĔna siö w tym wszystkim poäapaè? „Nie martw siö” — szepnöäa Kasia, która zauwaĔyäa niepokój Patryka. „Wszystko to nie jest tak skomplikowane, na jakie wyglñda. Jacek ma racjö — nie przejmuj siö tym, jak nazwaè to, co robisz. Wszyscy robimy to samo — dbamy o to, aby zadania zostaäy wykonane. Wspóäpracujemy ze sobñ, aby tak siö staäo, a przy tym przeskakujemy miödzy róĔnymi tradycyjnymi zadaniami zgodnie z wymogami sytuacji. JeĈli skoncentrujesz siö bardziej nad tym, co udostöpniamy, zamiast próbowaè okreĈliè, na jakim etapie cyklu rozwoju siö znajdujemy, wszystko nabierze sensu”.

38

ROZDZ AĤ 3

ZROZUM Eê XP

Patryk potrzñsnñä gäowñ. „Skñd jednak wiesz, co trzeba zrobiè? Wszystko to wyglñda bardzo chaotycznie”. Kasia wskazaäa tablicö zapeänionñ karteczkami. „To nasz plan na ten tydzieþ. Zadania oznaczone na zielono sñ ukoþczone, a na biaäo — jeszcze nie. Jest poniedziaäek rano, a udostöpniamy wersjö w Ĉrodö, dlatego mamy jeszcze okoäo póä tygodnia pracy. Jak oceniasz nasze postöpy?”. Patryk spojrzaä na tablicö. Mniej wiöcej wokóä poäowy karteczek widoczne byäo zielone kóäko. „JesteĈcie mniej wiöcej w poäowie?” — zgadnñä. Kasia rozpromieniäa siö — „Doskonale! Staramy siö, aby karteczki byäy aktualne. Staraj siö o tym pamiötaè przez pierwszy tydzieþ lub dwa, a wszystko bödzie dobrze”.

MAĤE KĤAMSTEWKO Wspomn aĥem, Ŝe stosowan e XP w sposób op sany w tej ks éŜce to jedyna moŜ woļë o n eprawda stoté XP n e sé praktyk , a e podejļc e do rozwoju oprogramowan a Beck p sze, Ŝe XP obejmuje f ozof ý wytwa zan a oprogramowan a, zb ór praktyk, zestaw uzupeĥn ajécych s ý zasad spoĥecznoļë [Beck 2004] KaŜdy doļw adczony zespóĥ stosujécy XP ma wĥasny sposób korzystan a z tego podejļc a Po opanowan u sztuk programowan a zw nnego býdz e go m aĥ takŜe Czyte n k W czýļc ach býdý podtrzymywaĥ to maĥe kĥamstwo tw erdz ĥ, Ŝe jest ty ko jeden sposób na uŜywan e XP W ten sposób duŜo ĥatw ej jest nauczyë s ý tego podejļc a W trakc e nauk warto pam ýtaë, Ŝe Ŝadna praktyka n e jest n ezm enna Zawsze moŜna wypróbowaë róŜne zm any Wa to zapoznaë s ý z podrozdz aĥem „Droga do m strzostwa” w rozdz a e 2 , a czýļë zaw era da sze wskazówk na ten temat Jest k ka róŜn c m ýdzy proponowanym p zeze mn e podejļc em do XP a op sem tej metody w nnych ks éŜkach W ýkszoļë rozb eŜnoļc to drobne kwest e zw ézane ze sty em, jednak wprowadz ĥem takŜe k ka stotnych zm an do praktyk XP z obszaru p anowan a testów akceptacj Majé one rozw ézywaë czýsto spotykane prob emy, które zaobse wowaĥem w trakc e pracy w zespoĥach stosujécych XP Zm any te, podobn e jak sama metoda XP, sé wyn k em w e u at teracyjnego usprawn an a Jednym z prob emów, jak e zauwaŜyĥem w zespoĥach stosujécych XP, jest to, Ŝe p zedstaw c e om k enta czýsto spraw a trudnoļë p anowan e wydaħ XP daje swobodý zm any zdan a w dowo nym momenc e, a k enc skwap w e z tego korzystajé — n eraz zbyt czýsto Rozwój przeradza s ý wtedy w zwinne miotanie siý, co wyn ka z tego, Ŝe k enc nadm ern e reagujé na kaŜdé moŜ woļë zm en ajé k erunek prac za kaŜdym razem, k edy pojaw s ý nowy pomysĥ Powoduje to, Ŝe zespóĥ n gdy n e moŜe ukoħczyë n czego wartoļc owego ma trudnoļc z prezentacjé postýpów prac Aby zapob ec temu prob emow , dodaĥem praktyký W zja bardz ej szczegóĥowo op saĥem praw dĥowe p anowan e wydaħ Dodaĥem takŜe praktyký Za zédzan e yzyk em, aby pomóc zespoĥom zrozum eë, jak zete n e podejmowaë dĥugoterm nowe zobow ézan a ZauwaŜyĥem teŜ, Ŝe zespoĥy czýsto majé trudnoļc z automatycznym testam akceptacj Choë majé one „ nformowaë k entów o tym, k edy system dz aĥa, a program stów o zadan ach do wykonan a” [Jeffr es nn ], stw erdz ĥem, Ŝe czýsto sé zbyt ubog e, aby mogĥy speĥn aë te funkcje W praktyce n ektórzy k enc ma tw é s ý, Ŝe w wyn ku p zygotowan a testów akceptacj powstan e oprogramowan e, które wprawdz e przejdz e testy, a e n e býdz e zgodne z stoté oczek waħ Co gorsza, w ýkszoļë zespoĥów p zygotowuje te testy jako testy na poz om e systemu, d atego ch utwo zen e konse wacja wymagajé duŜo pracy ak e testy dz aĥajé powo prowadzé do prob emów z komp acjé ntegracjé Mów éc krótko, odkryĥem, Ŝe automatyczne testy akceptacj wymagajé w ýcej kosztów, n Ŝ sé tego wa te W tej ks éŜce zastép ĥem automatyczne testy akceptacj p zeg édam dokonywanym p zez k entów, testam k enta testam eksp oracyjnym Przeg édy angaŜujé k entów w proces rozwoju, co umoŜ w a m przekazan e zarówno ducha, jak tery pot zeb esty k enta to odm ana automatycznych testów akceptacj Koncentrujé s ý na maĥych

CYK

śYC A W XP

39

testach konkretnych funkcj , a n e na testach na poz om e systemu Ce em ch stosowan a jest p zede wszystk m p zekazan e skomp kowanych reguĥ b znesowych, a n e potw erdzen e praw dĥowego opracowan a opow eļc esty eksp oracyjne to sprawdz an praktyk stosowanych p zez zespóĥ, któ y odbywa s ý po zakoħczen u zadan a Jeļ zespóĥ pracuje praw dĥowo, czba bĥýdów pow nna byë b ska zeru esty eksp oracyjne pomagajé upewn ë s ý, Ŝe rzeczyw ļc e tak jest M mo wprowadzonych zm an przedstaw ĥem w tej ks éŜce ty ko trzy zupeĥn e nowe praktyk (tabe a 3 2) śadna z n ch n e zostaĥa wymyļ ona przez mn e Zaadaptowaĥem je z nnych metod wypróbowaĥem w rzeczyw stych projektach Tabela 3.2. Nowe praktyki w XP Nowa praktyka

Funkcja

Wizja

Koncent uje wysiĥki i zapobiega czýsto wystýpujécemu p oblemowi „zwinnego miotania siý”

Za zédzanie yzykiem

Zwiýksza zdolnoļë zespoĥu do podejmowania i ealizowania zobowiézaħ Zmniejsza koszty

Testy eksplo acyjne

Zwiýkszajé jakoļë i pomagajé teste om w integ acji

Jest teŜ k ka techn k, które doj zaĥe zespoĥy stosujé ntu cyjn e w ramach XP, jednak w nnych ks éŜkach n e sé one op sane jako praktyk Dodaĥem takŜe grupý tak ch metod (tabe a 3 3) Tabela 3.3. ObjaĈnione praktyki Objaļn ana praktyka Ret ospekcja Zaufanie Wspólny jýzyk K ótkie spotkania obocze Demonst acje ite acji Rapo ty „W peĥni gotowe” B ak bĥýdów Kont ola we sji Dokumentacja Testy klienta Rozwiézania punktowe Optymalizacja wydajnoļci

N ektóre standardowe praktyk XP sé rzadko uŜywane sam ch n e stosujý (tabe a 3 4) Pom néĥem je w tej ks éŜce Tabela 3.4. Praktyki pominiöte w tej ksiñĔce Pom n ýta praktyka

Powód

Metafo a

Zastépiona p zez Z ozumiaĥy jýzyk

Maĥe zespoĥy

B ak osobistego doļwiadczenia Nie jest niezbýdna

Negocjowany zak es p ac

Niskie doļwiadczenie osobiste Nie jest niezbýdna

Opĥata za uŜytkowanie

B ak osobistego doļwiadczenia Nie jest niezbýdna

40

ROZDZ AĤ 3

ZROZUM Eê XP

abe a 3 5 pokazuje, jak praktyk op sane w tej ks éŜce odpow adajé praktykom XP zaproponowanym przez Becka Doĥéczyĥem takŜe ko umný op sujécé praktyk mĥyna, czy nnej popu arnej zw nnej metody Tabela 3.5. Odpowiadajñce sobie praktyki Drug e wydan e XPa

P erwsze wydan e XPb

P og amowanie w pa ach

P og amowanie w pa ach

P og amowanie w pa ach

Brak

Ene giczna p aca

Ene giczna p aca

40 godzinny tydzieħ p acy

Ukryta

nfo macyjne miejsce p acy

nfo macyjne miejsce p acy

Ukryta

Ukryta

Analizy p zyczynowo skutkowe

Analizy p zyczynowo skutkowe

Ukryta

Ukryta

Ret ospekcje

Ukryta

Ukryta

Ukryta

Ta ks éŜka

Mĥync

Myļlenie

Wspóĥpraca Zaufanie

Ukryta

Ukryta

Ukryta

(w amach Zaufania)

Ciégĥoļë zespoĥu

Brak

Ukryta

Wspólna p aca

Wspólna p aca

Ukryta

Otwa te pomieszczenie obocze

Ukryta

Caĥy zespóĥ

P zedstawiciel klienta

Zespóĥ w m ynie

ZaangaŜowanie p awdziwego klienta

ZaangaŜowanie p awdziwego klienta

Ukryta

Ukryta

Wspólny jýzyk

Ukryta

(zastýpuje Metafo ý)

Brak

K ótkie spotkania obocze

Ukryta

Ukryta

Codzienny mĥyn

Standa dy pisania kodu

Ukryta

Standa dy pisania kodu

Brak

Demonst acja ite acji

Ukryta

Ukryta

B yskawiczny p zegléd

Rapo ty

Ukryta

Ukryta

Ukryta

Udostýpn an e „W peĥni gotowe”

Ukryta

Ukryta

Ukryta

B ak bĥýdów

Ukryta

Ukryta

Brak

Kont ola we sji

Ukryta

Ukryta

Brak

(w amach Kont oli we sji)

Pojedyncza baza kodu

Ukryta

Brak

Dziesiýciominutowa kompilacja

Dziesiýciominutowa kompilacja

Ukryta

Brak

Ciégĥa integ acja

Ciégĥa integ acja

Ciégĥa integ acja

Brak

Wspóĥwĥasnoļë kodu

Wspóĥdzielony kod

Wspó wĥasnoļë

Brak

Dokumentacja

Ukryta

Ukryta

Ukryta

Brak

Brak

Ukryta

Planowan e Wizja Planowanie wydaħ

Cykl kwa talny

Maĥe wydania

Dziennik zadaħ p oduktu

(w amach Planowania wydaħ)

Stopniowe instalowanie

Ukryta

Ukryta

(w amach Planowania wydaħ)

Codzienne instalowanie

Ukryta

Brak

G a planistyczna

Ukryta

G a planistyczna

Ukryta

Za zédzanie yzykiem

Brak

Brak

Brak

CYK

śYC A W XP

41

Ta ks éŜka

Drug e wydan e XPa

P erwsze wydan e XPb

Mĥync

Planowanie ite acji

Cykl tygodniowy

Ukryta

Sp int

Zapas

Zapas

Ukryta

Ukryta

Opowieļci

Opowieļci

Ukryta

Pozycje w dzienniku zadaħ

Szacowanie

Ukryta

Ukryta

Szacowanie

Stopniowe ok eļlanie wymagaħ

Ukryta

Ukryta

Ukryta

Testy klienta

Ukryta

Testy

Brak

Wytwa zanie ste owane testami

P og amowanie pop zedzane testami

Testy

Brak

Refakto yzacja

Ukryta

Refakto yzacja

Brak

P osty p ojekt

Stopniowy ozwój p ojektu

P osty p ojekt

Brak

Stopniowy ozwój p ojektu i a chitektu y

Stopniowy ozwój p ojektu

P osty p ojekt

Brak

Rozwiézania punktowe

Ukryta

Ukryta

Brak

Optymalizacja wydajnoļci

Ukryta

Ukryta

Brak

Testy eksplo acyjne

Brak

Brak

Brak

Brak

Malejéce zespo y

Brak

Brak

Brak

Negocjowany zak es p ac

Ukryta

Brak

Brak

Opĥata za uŜytkowanie

Brak

Brak

Ukryta

Ukryta

Ukryta

Mist z mĥyna

Ukryta

Ukryta

Ukryta

Wĥaļciciel p oduktu

Brak

Brak

Brak

Niestanda dowe zakoħczenie sp intu

Brak

Brak

Brak

Cel sp intu

Wytwarzan e

Pom n ýte w ks éŜce

a

[Beck 2004]

b

[Beck 1999]

c

[Schwaber Beed e]

Legenda Brak — a praktyka n e na eŜy do metody, choë n ektóre zespoĥy mogé jé dodaë Ukryta — Choë okreļ ony pomysĥ n e jest praktyké w tej metodz e, zakĥada s ý jego obecnoļë ub jest on op sany w nny sposób

Zespóĥ w XP Samodzielna praca nad wäasnym projektem — „bycie samemu sobie panem” — moĔe byè bardzo interesujñca. Nie ma tu pytaþ o rozwijane funkcje, ich oczekiwane dziaäanie, prawidäowe funkcjonowanie oprogramowania czy zadowolenie udziaäowców. Wszystkie odpowiedzi znajdujñ siö w jednym umyĈle. 42

ROZDZ AĤ 3

ZROZUM Eê XP

Zespoäowe wytwarzanie oprogramowania odbywa siö inaczej. Te same informacje sñ rozproszone miödzy wielu czäonków zespoäu. Poszczególne osoby majñ róĔne informacje: x Wiedzö o tym, jak zaprojektowaè oprogramowanie i napisaè jego kod (programiĈci,

projektanci i architekci). x Powody, dla których oprogramowanie jest waĔne (menedĔer produktu). x Reguäy, z którymi oprogramowanie powinno byè zgodne (eksperci z dziedziny). x Oczekiwany sposób dziaäania oprogramowania (projektanci interakcji). x Oczekiwany wyglñd interfejsu (projektanci grafiki). x MoĔliwe miejsca wystöpowania bäödów (testerzy). x Sposoby interakcji z innymi dziaäami firmy (menedĔer projektu). x Nawyki, które naleĔy usprawniè (coach).

Do odniesienia sukcesu potrzebna jest caäa ta wiedza. W czasie rozwoju XP uwzglödniono ten fakt, dlatego podejĈcie to stosujñ zespoäy wielofunkcyjne, skäadajñce siö z róĔnych osób, które wspólnie odgrywajñ wszystkie role zespoäowe.

Caĥy zespóĥ Zespoäy stosujñce XP pracujñ wspólnie w otwartym pomieszczeniu roboczym. Na poczñtku kaĔdej iteracji zespóä spotyka siö przy okazji wielu zadaþ: demonstracji iteracji, retrospekcji i planowania iteracji. Zwykle spotkania te zajmujñ äñcznie od dwóch do czterech godzin. Zespóä spotyka siö takĔe w trakcie codziennych krótkich spotkaþ roboczych, które zazwyczaj trwajñ od piöciu do dziesiöciu minut. Oprócz tych zaplanowanych dziaäaþ kaĔda osoba w zespole samodzielnie planuje swñ pracö. Nie oznacza to, Ĕe wszyscy pracujñ niezaleĔnie od siebie; po prostu nie ma ĈciĈle ustalonego harmonogramu. Czäonkowie zespoäu ustalajñ szczegóäy kaĔdego spotkania wtedy, kiedy jest to potrzebne. Czasem takie spotkania sñ nieformalne: ktoĈ po prostu wstaje i ogäasza, Ĕe chciaäby omówiè okreĈlone zagadnienie. Samodzielna organizacja to cecha charakterystyczna zwinnych zespoäów.

Przedstawiciele klienta Przedstawiciele klienta — czösto nazywani po prostu klientami — odpowiadajñ za okreĈlanie ksztaätu oprogramowania rozwijanego przez zespóä. Pozostali czäonkowie grupy mogñ i powinni przedstawiaè wäasne sugestie i pomysäy, jednak gäównñ odpowiedzialnoĈè za ustalenie, co jest wartoĈciowe dla udziaäowców, ponoszñ wäaĈnie klienci. NajwaĔniejsze zadanie klientów to planowanie wydania. Jest to wieloaspektowa czynnoĈè. Klienci muszñ przekazaè innym osobom wizjö projektu, przedstawiè funkcje i opowieĈci, ustaliè, jak poäñczyè funkcje w maäe, czösto udostöpniane wydania, zarzñdzaè ryzykiem i utworzyè wykonalny plan przez koordynacjö dziaäaþ z programistami i uczestnictwo w grze planistycznej. Przedstawicielem klienta moĔe byè prawdziwy klient, jednak nie zawsze tak jest. ZaleĔy to od typu projektu. Jednak klienci zawsze dopracowujñ plany na podstawie informacji zwrotnych uzyskanych od prawdziwych klientów i innych zainteresowanych osób. Jednym ze sposobów na uzyskanie takich informacji sñ cotygodniowe demonstracje iteracji prowadzone przez klientów. ZESPÓĤ W XP

43

Nastöpnym zadaniem klientów — obok planowania — jest udostöpnianie szczegóäowych wymagaþ programistom, kiedy ci o nie poproszñ. W XP dokumenty z wymaganiami säuĔñ jedynie jako narzödzie wspomagajñce pamiöè klientów. Oni sami peäniñ funkcjö Ĕywych dokumentów z wymaganiami i zdobywajñ informacje w terminie umoĔliwiajñcym wykorzystanie ich przez programistów oraz udostöpniajñ je w razie potrzeby. Klienci pomagajñ takĔe przekazywaè wymagania, tworzñc makiety, przeglñdajñc dotychczasowe efekty prac i tworzñc szczegóäowe testy klienta, które wyjaĈniajñ zäoĔone zasady biznesowe. Aby taka komunikacja byäa efektywna, caäy zespóä musi pracowaè w jednym miejscu. Zwykle rolö przedstawicieli klientów odgrywajñ menedĔerowie produktu, eksperci z dziedziny, projektanci interakcji i analitycy biznesowi. Jednym z najtrudniejszych aspektów budowy zespoäów wielofunkcyjnych jest znalezienie osób, które majñ wystarczajñce umiejötnoĈci i chöci, aby peäniè funkcjö przedstawiciela klienta. Nie naleĔy lekcewaĔyè tej roli. Jest ona kluczowa z uwagi na zwiökszenie wartoĈci udostöpnianych produktów. Sprawny zespóä przygotuje technicznie doskonaäe oprogramowanie bez przedstawiciela klienta, jednak aby odnieĈè prawdziwy sukces, oprogramowanie musi takĔe mieè wartoĈè dla inwestorów. Wymaga to uwzglödnienia punktu widzenia przedstawiciela klienta.

UWAGA NaleĔy wäñczyè do zespoäu dokäadnie jednego menedĔera produktu i wystarczajñcñ liczbö innych przedstawicieli klientów, aby mogli znajdowaè siö wciñĔ o jeden krok przed programistami. Zgodnie z praktycznñ reguäñ moĔna zaczñè od zaangaĔowania dwóch przedstawicieli klientów (wäñcznie z menedĔerem produktu) na kaĔdych trzech programistów.

Coffin opisuje doĈwiadczenia dwóch prawie identycznych zespoäów [Coffin]. Jeden z nich obejmowaä przedstawiciela klienta, drugi nie. Zespóä bez klienta pracowaä 15 miesiöcy i utworzyä produkt o przeciötnej wartoĈci. ãñczny koszt projektu przekroczyä poczñtkowe szacunki, a aplikacja nie speäniäa oczekiwaþ uĔytkowników w zakresie funkcjonalnoĈci systemu […], dopiero w drugiej i trzeciej wersji zapewniono prawdziwñ wartoĈè biznesowñ, a nawet wtedy nowy system nie byä w peäni wartoĈciowy dla uĔytkowników, poniewaĔ wymagaä zmian w sposobie pracy, nie dajñc przy tym znaczñcych korzyĈci. Zespóä z tej samej firmy skäadajñcy siö z takiej samej liczby programistów i stosujñcy ten sam proces rozwoju przygotowaä póĒniej bardzo wartoĈciowy produkt w niecaäe trzy miesiñce. Pierwsza wersja produkcyjna byäa gotowa po 9 tygodniach pracy […], przekroczono oczekiwania w zakresie harmonogramu i funkcjonalnoĈci, a jednoczeĈnie zespóä nie przekroczyä budĔetu […]. W ciñgu dwóch pierwszych miesiöcy uĔywania oprogramowania w Ĉrodowisku produkcyjnym za pomocñ nowego systemu wpisano ponad 25000 cytowaþ. Zespóä rozwijajñcy aplikacjö mniej wiöcej co szeĈè tygodni wypuszczaä nowe wydanie. KaĔde z nich stanowiäo dla zespoäu programistów i klientów nowñ okazjö do zapewnienia wartoĈci firmie i uäatwienia pracy uĔytkownikom. Jednñ z gäównych przyczyn sukcesu byäo zaangaĔowanie klientów. DuĔa czöĈè niedociñgniöè pierwszego systemu wynikaäa z zaniku nawiñzanej poczñtkowo atmosfery wspóäpracy. Gdyby uĔytkownicy byli bardziej zaangaĔowani w projekt, powstaäby system duĔo bardziej dostosowany do ich potrzeb. Klienci mieliby mocniejsze poczucie wäasnoĈci, a komunikacja miödzy poszczególnymi grupami byäaby bardziej swobodna. 44

ROZDZ AĤ 3

ZROZUM Eê XP

[…] Wiele osób w organizacji zauwaĔyäo sukces drugiego systemu i wyciñgnöäo wnioski z tego projektu […], inne zespoäy projektowe zmieniäy fizyczny ukäad stanowisk pracy i przeksztaäciäy go na wspólny pokój projektowy, podobny do tego, którego uĔywaä zespóä pracujñcy nad drugim systemem. ZaangaĔowanie klientów ma olbrzymi wpäyw na sukces w rozwoju produktu. Warto poĈwiöciè JeĈli klienci nie przychodzñ dodatkowe wysiäki na wäñczenie klientów w zespóä. do zespoäu, trzeba przenieĈè Jednym ze sposobów jest przeniesienie zespoäu do zespóä do klienta. siedziby odbiorcy, zamiast zapraszania uĔytkowników do biura producenta. NaleĔy upewniè siö, Ĕe klienci zgadzajñ siö na takie rozwiñzanie i dysponujñ wystarczajñcñ przestrzeniñ.

PO CO Aś TYLU KLIENTÓW? Dwóch k entów na kaŜdych t zech program stów to duŜo, prawda? Zaczynaĥem od duŜo mn ejszej czby, jednak czýsto k enc n e nadéŜa za program stam W koħcu, po wypróbowan u róŜnych moŜ woļc w k ku sprawn e funkcjonujécych zespoĥach, doszedĥem do stosunku dwóch na trzech Zapytaĥem takŜe coachów z dz edz ny XP o ch doļw adczen a Wedĥug powszechnych op n stosunek dwóch na trzech jest optyma ny W ýkszoļë projektów, nad któ ym pracowaĥem, dotyczyĥa zĥoŜonej dz edz ny prob emowej, d atego jeļ oprogramowan e jest doļë proste, moŜna zapros ë mn ejszé czbý k entów Warto pam ýtaë, Ŝe k enc majé w e e zadaħ Muszé usta ë, co zapewn a najw ýkszé wartoļë, okreļ ë pr orytety, uwzg ýdn ë wszystk e szczegóĥy, o jak e mogé zapytaë program ļc , oraz zna eŚë czas na przeg édy testy k enta P zy tym caĥy czas muszé wyp zedzaë o krok program stów, któ zy c ég e sé tuŜ za n m przeb jajé s ý przez opow eļc jak odoĥamacz o powaŜna funkcja, której n e wo no ekcewaŜyë

MenedŜer produktu (inaczej: wĥaļciciel produktu) MenedĔer produktu ma tylko jedno zadanie w trakcie projektów rozwijanych za pomocñ XP, jednak jest ono bardzo trudne. Polega na zarzñdzaniu wizjñ produktu i propagowaniu jej. W praktyce oznacza to dokumentowanie wizji, przekazywanie jej udziaäowcom, zbieranie informacji zwrotnych, generowanie funkcji i opowieĈci, wyznaczanie priorytetów na potrzeby planowania wydaþ, okreĈlanie kierunku dziaäaþ dla przedstawicieli klientów, przeglñdanie dotychczas wykonanej pracy, prowadzenie demonstracji iteracji, zapraszanie prawdziwych klientów i uwzglödnianie zasad organizacji.

UWAGA MenedĔerowie produktu czösto odpowiadajñ nie tylko za zarzñdzanie wizjñ produktu i propagowanie jej, ale teĔ za udane wprowadzanie produktu na rynek. MoĔe to oznaczaè reklamö i promocjö, przygotowywanie szkoleþ i tak dalej. Te standardowe obowiñzki zwiñzane z zarzñdzaniem produktem wykraczajñ poza zakres tej ksiñĔki.

Najlepsi menedĔerowie produktu dobrze rozumiejñ rynek niezaleĔnie od tego, czy ogranicza siö on do jednej organizacji (tak jak w przypadku niestandardowego oprogramowania), czy obejmuje wiele firm (tak jak przy oprogramowaniu komercyjnym). Dobry menedĔer produktu

ZESPÓĤ W XP

45

intuicyjnie wie, co daje oprogramowanie, a takĔe dlaczego kaĔde wykonywane zadanie to najwaĔniejsza rzecz, jakñ zespóä projektowy moĔe robiè w danym czasie. Doskonaäy menedĔer produktu charakteryzuje siö rzadkñ kombinacjñ umiejötnoĈci. Oprócz wizji musi mieè autorytet, aby podejmowaè trudne decyzje dotyczñce tego, co znajdzie siö w produkcie, a co nie. Musi mieè teĔ zdolnoĈci polityczne, aby godziè sprzeczne interesy udziaäowców, äñczyè je w wizji produktu i potrafiè powiedzieè „nie” Ĕñdaniom, których uwzglödnienie jest niemoĔliwe. MenedĔerowie produktu tej klasy czösto sñ bardzo zapracowani. Czäonkowie zespoäu mogñ mieè problemy z uzyskaniem wystarczajñcej uwagi z ich strony. NaleĔy zachowaè cierpliwoĈè. MenedĔer produktu peäni jednñ z najwaĔniejszych ról w zespole. Trzeba pozyskaè pomoc menedĔera projektu i przypomnieè innym, Ĕe rozwój oprogramowania to bardzo kosztowny proces. JeĈli program nie bödzie wystarczajñco cenny, aby warto mu poĈwiöciè czas dobrego menedĔera produktu — czyli takiego, który stanowi róĔnicö miödzy sukcesem a poraĔkñ — moĔliwe, Ĕe w ogóle nie naleĔy go rozwijaè. Trzeba upewniè siö, Ĕe menedĔer produktu jest w peäni skupiony na danym projekcie. Kiedy zespóä zacznie funkcjonowaè sprawnie, menedĔer produktu moĔe zaczñè zmniejszaè zaangaĔowanie. Choè eksperci z dziedziny i inni przedstawiciele klientów mogñ przez pewien czas zastñpiè menedĔera produktu, praca nad projektem moĔe zboczyè z wytyczonego kierunku, jeĈli nie bödzie on uczestniczyä w kaĔdej iteracji. Rooney doĈwiadczyä tego problemu, a skutki byäy opäakane [Rooney]: Nie byliĈmy pewni, jakie sñ priorytety. Nie wiedzieliĈmy, nad czym mamy pracowaè w nastöpnym kroku. WybieraliĈmy opowieĈci z ogólnej listy, jednak brakowaäo nam wytycznych od Klienta [menedĔera produktu] okreĈlajñcych, czym powinniĈmy siö zajñè. Trwaäo to przez kilka miesiöcy. Wtedy odkryliĈmy, Ĕe WäaĈciciel Zäota [wäaĈciciel projektu] jest zirytowany — i to powaĔnie. Okazaäo siö, Ĕe nie pracowaliĈmy nad tym, nad czym jego zdaniem powinniĈmy. W przewidywalnym Ĉrodowisku i przy delegowaniu zadaþ solidnej grupie przedstawicieli klientów menedĔer produktu moĔe poĈwiöcaè wiökszoĈè czasu na inne czynnoĈci, jednak powinien uczestniczyè w kaĔdej retrospekcji, kaĔdej demonstracji iteracji i w wiökszoĈci sesji planowania wydania. W niektórych firmach rolö menedĔera produktu peäni komitet, jednak odradzam to rozwiñzanie. Zespóä potrzebuje spójnej wizji, którñ moĔe siö kierowaè, a odkryäem, Ĕe komitety majñ problemy z tworzeniem jednoznacznych, przekonujñcych wizji. W komitetach, które odniosäy sukces, jeden z czäonków w praktyce peäniä funkcjö menedĔera produktu. Zachöcam do bezpoĈredniego wyznaczenia menedĔera produktu. Jego rola moĔe ograniczaè siö do tworzenia spójnej wizji na podstawie pomysäu czäonków komitetu, jednak zadanie to wymaga wiele pracy. W takiej sytuacji trzeba koniecznie zadbaè o to, aby menedĔer produktu miaä wysokie umiejötnoĈci polityczne.

Eksperci z dziedziny WiökszoĈè programów dziaäa w konkretnej branĔy, na przykäad finansowej, w której obowiñzujñ specyficzne reguäy prowadzenia biznesu. Aby oprogramowanie dobrze dziaäaäo w danej dziedzinie, musi wiernie i dokäadnie realizowaè te zasady. Sñ to reguäy z dziedziny, a wiedza na ich temat to wiedza z dziedziny.

46

ROZDZ AĤ 3

ZROZUM Eê XP

WiökszoĈè programistów ma luki w wiedzy z dziedziny, nawet jeĈli pracujñ w danej branĔy od lat. W wielu przypadkach w samej dziedzinie brakuje jasnej definicji wszystkich zasad. Podstawy mogñ byè proste, jednak w drobnych szczegóäach reguäy z dziedziny sñ czasem niejasne, a nawet sprzeczne. Zespoäowi eksperci z dziedziny odpowiadajñ za okreĈlenie tych szczegóäów i muszñ mieè wszystkie odpowiedzi w maäym palcu. Eksperci z dziedziny sñ specjalistami z danego obszaru. Mogñ to byè na przykäad analitycy z branĔy finansowej lub doktorzy chemii. Eksperci z dziedziny spödzajñ wiökszoĈè czasu z zespoäem, dopracowujñc szczegóäy przygotowywanych opowieĈci i bödñc w gotowoĈci do udzielenia odpowiedzi na pytania programistów. Przy zäoĔonych reguäach tworzñ testy klienta (czösto przy pomocy testerów), aby uäatwiè przekazywanie niuansów.

UWAGA W maäych zespoäach menedĔer produktu czösto peäni teĔ funkcjö eksperta z dziedziny.

Projektanci interakcji Interfejs uĔytkownika to publiczne oblicze produktu. Dla wielu uĔytkowników UI jest produktem. Oceniajñ oni jakoĈè oprogramowania wyäñcznie na podstawie UI. Projektanci interakcji pomagajñ okreĈliè UI produktu. Ich praca koncentruje siö na zrozumieniu uĔytkowników, ich potrzeb i sposobów korzystania z produktu. Wykonujñ takie zadania jak przeprowadzanie wywiadów z uĔytkownikami, tworzenie postaci, przeglñdanie papierowych prototypów z uĔytkownikami i obserwowanie korzystania z oprogramowania.

UWAGA Nie naleĔy myliè projektowania grafiki z projektowaniem interakcji. Projektanci grafiki przekazujñ pomysäy i styl za pomocñ obrazów i ukäadu elementów. Projektanci interakcji koncentrujñ siö na typach osób korzystajñcych z produktu, ich potrzebach oraz na tym, aby produkt jak najlepiej je speäniaä.

W zespole czasem brakuje specjalisty z obszaru projektowania interakcji. Niektóre firmy powierzajñ tö rolö projektantowi grafiki, menedĔerowi produktu lub programiĈcie. Projektanci interakcji dzielñ swój czas miödzy wspóäpracö z zespoäem a wspóäpracö z uĔytkownikami. Majñ wkäad w planowanie wydania, poniewaĔ doradzajñ zespoäowi w zakresie potrzeb i priorytetów uĔytkowników. W czasie kaĔdej iteracji pomagajñ zespoäowi przygotowywaè makiety z elementami UI zwiñzanymi z obecnie rozwijanymi opowieĈciami. Kiedy prace nad opowieĈciñ zbliĔajñ siö do koþca, przeglñdajñ wyglñd i styl UI oraz upewniajñ siö, Ĕe interfejs dziaäa zgodnie z oczekiwaniami. PoniewaĔ XP jest szybkie, iteracyjne i oparte na informacjach zwrotnych, rozwój oprogramowania przy uĔyciu tej metody odbywa siö w Ĉrodowisku odmiennym od tego, do którego projektanci interakcji sñ przyzwyczajeni. Zamiast spödzaè czas na badaniach uĔytkowników i definiowaniu ich zachowaþ przed rozpoczöciem programowania, projektanci muszñ iteracyjnie dopracowywaè modele, równolegle do iteracyjnego usprawniania samego programu.

ZESPÓĤ W XP

47

Choè projektowanie interakcji w XP odbywa siö inaczej niĔ w innych metodach, nie naleĔy umniejszaè roli tego zadania. W XP co tydzieþ powstaje dziaäajñcy program, co daje duĔo moĔliwoĈci projektantom interakcji. Majñ oni okazjö przedstawiè oprogramowanie uĔytkownikom, zaobserwowaè wzorce uĔytkowania i wykorzystaè informacje zwrotne do przygotowania zmian juĔ w nastöpnym tygodniu.

Analitycy biznesowi W tradycyjnych zespoäach analitycy biznesowi zwykle peäniñ rolö äñcznika miödzy klientami a programistami, a ich zadaniem jest wyjaĈnianie i dopracowywanie potrzeb klientów, tak aby moĔna przeksztaäciè je na specyfikacjö wymagaþ funkcjonalnych. W zespoäach stosujñcych XP analitycy biznesowi wspomagajñ zespóä, który obejmuje juĔ menedĔera produktu i ekspertów z dziedziny. Analitycy takĔe tu wyjaĈniajñ i dopracowujñ potrzeby klientów, ale robiñ to w ramach wspomagania innych przedstawicieli klientów, a nie w ich zastöpstwie. Analitycy pomagajñ klientom przemyĈleè szczegóäy, o których äatwo zapomnieè, a takĔe uäatwiajñ programistom opis technicznych kosztów i zysków w jözyku biznesu.

Programiļci Doskonaäa wizja produktu wymaga solidnej realizacji. WiökszoĈè zespoäów stosujñcych XP to konstruktorzy oprogramowania o róĔnych specjalizacjach. KaĔdy z nich ma bezpoĈredni wkäad w rozwój kodu. Aby to podkreĈliè, w XP wszyscy konstruktorzy sñ nazywani programistami.

UWAGA Zespóä powinien liczyè od 4 do 10 programistów. Trzeba pamiötaè o zaangaĔowaniu przynajmniej jednego starszego programisty, projektanta lub architekta z duĔym doĈwiadczeniem projektowym, który przy tym dobrze radzi sobie z pisaniem kodu. Uäatwi to zespoäowi udanñ realizacjö stopniowego rozwoju projektu i architektury przy stosowaniu XP.

O ile zadaniem klientów jest maksymalizacja wartoĈci produktu, programiĈci majñ zminimalizowaè koszty jego rozwoju. Odpowiadajñ za okreĈlenie najbardziej efektywnego sposobu realizacji planowanych opowieĈci. ProgramiĈci przedstawiajñ szacunki potrzebnych nakäadów pracy, proponujñ inne rozwiñzania i pomagajñ klientom utworzyè wykonalny plan, uczestniczñc w grze planistycznej. ProgramiĈci spödzajñ wiökszoĈè czasu na programowaniu w parach. Stosujñ wytwarzanie sterowane testami i w ramach tego procesu piszñ testy, implementujñ kod, dokonujñ refaktoryzacji oraz stopniowo rozwijajñ projekt i architekturö aplikacji. DuĔo uwagi poĈwiöcajñ jakoĈci projektu i sñ Ĉwiadomi däugu technicznego (wyjaĈnienie pojöcia „däug techniczny” zawiera podrozdziaä „Pojöcia zwiñzane z XP” w dalszej czöĈci rozdziaäu) oraz jego wpäywu na czas rozwoju i przyszäe koszty konserwacji. ProgramiĈci gwarantujñ takĔe, Ĕe klienci bödñ mogli pod koniec kaĔdej iteracji poprosiè o udostöpnienie oprogramowania. Przy pomocy caäego zespoäu programiĈci starajñ siö uniknñè bäödów w gotowych programach. Konserwujñ dziesiöciominutowñ kompilacjö, dziöki czemu w kaĔdym momencie moĔna skompilowaè kompletne rozwiñzanie. Stosujñ kontrolö wersji

48

ROZDZ AĤ 3

ZROZUM Eê XP

i nieustannie integrujñ kod, dlatego prawie caäe rozwiñzanie — oprócz kilku ostatnich godzin pracy — jest zintegrowane i przetestowane. Gotowe rozwiñzanie to wynik wspólnej pracy wszystkich programistów. Na poczñtku projektu ustalajñ oni standardy pisania kodu, co umoĔliwia ponoszenie wspólnej odpowiedzialnoĈci za kod. ProgramiĈci majñ prawo i obowiñzek naprawiania wszelkich zauwaĔonych problemów, i to niezaleĔnie od fragmentu aplikacji, w której wystñpiäa usterka. ProgramiĈci oczekujñ od klientów informacji na temat rozwijanego oprogramowania. Zamiast zgadywaè, zadajñ pytania jednemu z przedstawicieli klientów. Aby takie rozmowy byäy moĔliwe, programiĈci rozwijajñ oprogramowanie przy uĔyciu zrozumiaäego jözyka. Pomagajñ takĔe klientom w testach, automatyzujñc przygotowane przez nich przykäady. Ostatnim zadaniem programistów jest uäatwienie däugoterminowej konserwacji produktu. Wymaga to udostöpnienia dokumentacji w odpowiednich momentach.

Projektanci i architekci W zespole stosujñcym XP wszyscy piszñ kod i wszyscy projektujñ. Wytwarzanie sterowane testami äñczy projektowanie, testy i pisanie kodu w jedno ciñgäe zadanie. Mimo to niezbödni sñ doĈwiadczeni projektanci i architekci. Ich zadaniem jest wyznaczanie zespoäowi drogi w trakcie stopniowego rozwoju projektu i architektury oraz pomoc w dostrzeganiu moĔliwoĈci uproszczenia skomplikowanych projektów. Peäniñ raczej rolö wspóäpracowników — czyli programistów — niĔ nauczycieli. Bardziej pokazujñ moĔliwoĈci, niĔ wydajñ polecenia.

Specjaliļci do spraw technicznych Rola „programisty” w XP oprócz oczywistych funkcji (programista, konstruktor, inĔynier oprogramowania) obejmuje takĔe inne zadania zwiñzane z rozwojem programu. Programista moĔe byè projektantem baz danych, ekspertem z dziedziny zabezpieczeþ lub architektem sieci. ProgramiĈci w XP to specjaliĈci z wielu dziedzin. Choè kaĔda osoba jest ekspertem w okreĈlonym obszarze, od wszystkich oczekuje siö, Ĕe podejmñ pracö nad dowolnñ czöĈciñ systemu, która akurat wymaga uwagi. (Wiöcej informacji na ten temat zawiera podrozdziaä „WspóäwäasnoĈè kodu” w rozdziale 7.).

Testerzy Testerzy pomagajñ zespoäom stosujñcym XP osiñgaè wysokñ jakoĈè juĔ od samego poczñtku. Stosujñ umiejötnoĈè krytycznego myĈlenia, aby pomóc klientom w rozwaĔeniu wszystkich moĔliwoĈci przy wyobraĔaniu sobie przyszäego produktu. Pomagajñ teĔ wykryè luki w wymaganiach oraz asystujñ przy testach klienta2.

UWAGA NaleĔy zaangaĔowaè wystarczajñco wielu testerów, aby mogli przez caäy czas wyprzedzaè programistów. Zgodnie z praktycznñ reguäñ na czterech programistów powinien przypadaè jeden tester. 2

Omówienie obowiñzków testerów opiera siö na mojej wersji XP (zobacz ramkö „Maäe käamstewko” we wczeĈniejszej czöĈci rozdziaäu). W klasycznej odmianie XP nie ma odröbnej funkcji „tester”.

ZESPÓĤ W XP

49

Testerzy odpowiadajñ takĔe za badania techniczne. Stosujñ testy eksploracyjne, aby pomóc zespoäowi w ustaleniu, czy metody zapobiegania pojawianiu siö bäödów w gotowym oprogramowaniu sñ skuteczne. Testerzy udostöpniajñ takĔe informacje o pozafunkcjonalnych cechach oprogramowania, takich jak wydajnoĈè, skalowalnoĈè i stabilnoĈè. Wymaga to zastosowania zarówno testów eksploracyjnych, jak i däugich testów automatycznych. Jednak testerzy nie sprawdzajñ caäego oprogramowania pod kñtem bäödów. Zespóä nie liczy na to, Ĕe testerzy znajdñ bäödy, które programiĈci bödñ mogli naprawiè, ale przede wszystkim stara siö od poczñtku tworzyè kod niemal caäkowicie wolny od usterek. Kiedy testerzy wykryjñ bäödy, pomagajñ pozostaäym osobom ustaliè, co zawiodäo, dziöki czemu caäy zespóä moĔe zapobiegaè przyszäemu wystöpowaniu usterek danego typu. Te zadania wymagajñ twórczego myĈlenia, elastycznoĈci i doĈwiadczenia w definiowaniu planów testów. PoniewaĔ zespoäy stosujñce XP zwykle automatyzujñ proces testowania zamiast wykonywaè röczne testy regresji, najlepiej czujñ siö w nich testerzy przyzwyczajeni do samodzielnej pracy. W niektórych zespoäach stosujñcych XP nie ma osób zajmujñcych siö tylko testami. W takich grupach rolö testerów przejmujñ programiĈci i klienci.

DLACZEGO TAK NIEWIELU TESTERÓW? Podobn e jak przy czb e k entów, stosunek testerów do program stów usta ĥem metodé prób bĥýdów Proponowana czba testerów moŜe nawet okazaë s ý n eco zawyŜona W odnoszécych sukcesy zespoĥach, w których pracowaĥem, znajdowaĥ s ý jeden tester na szeļc u program stów, a w n ektórych grupach stosujécych XP w ogó e n e ma osób peĥn écych tý funkcjý Rýczne testy opa te na skryptach, zwĥaszcza testy regresj , sé n ezwyk e pracochĥonne wymagajé wysok ego stosunku czby testerów do program stów W XP n e stosuje s ý testów tego typu Ponadto to program ļc p zygotowujé w ýkszoļë testów automatycznych (w czas e wytwarzan a sterowanego testam ), co dodatkowo zmn ejsza czbý potrzebnych testerów Jeļ zespóĥ pracuje nad stn ejécym kodem mus p zeprowadz ë w e e rýcznych testów regresj , stosunek czby testerów do program stów býdz e prawdopodobn e wyŜszy n Ŝ proponowany w tym m ejscu

Coachowie Zespoäy stosujñce XP organizujñ siö samodzielnie, co oznacza, Ĕe kaĔdy czäonek zespoäu okreĈla, jak moĔe w danym momencie najlepiej przyczyniè siö do uzyskania postöpów w pracy grupy. W takich zespoäach nie ma tradycyjnych ról kierowniczych. Zamiast tego liderzy w zespoäach stosujñcych XP kierujñ, dajñc przykäad. W wiökszym stopniu pomagajñ pracownikom wykorzystaè ich potencjaä, niĔ ustalajñ zadania i przydzielajñ je poszczególnym osobom. Aby podkreĈliè tö róĔnicö, liderów w takich zespoäach nazywa siö coachami. Z czasem, kiedy zespóä nabierze doĈwiadczenia i nauczy siö samodzielnie organizowaè, bezpoĈrednie przywództwo stanie siö mniej potrzebne, a rola lidera zacznie przechodziè miödzy osobami w odpowiedzi na wymogi sytuacji. Praca coacha jest delikatna. Musi on zapewniè powodzenie zespoäu. Coachowie pomagajñ rozpoczñè proces, przygotowujñc wspólne pomieszczenie robocze i upewniajñc siö, Ĕe

50

ROZDZ AĤ 3

ZROZUM Eê XP

w skäad zespoäu wchodzñ odpowiednie osoby. Pomagajñ stworzyè warunki do energicznej pracy i asystujñ przy tworzeniu informacyjnego miejsca pracy. Jednym z najwaĔniejszych zadaþ coacha jest uäatwienie zespoäowi komunikacji z resztñ organizacji. Coach pomaga grupie zdobyè zaufanie i dobrñ opiniö w firmie, a czösto bierze odpowiedzialnoĈè za prezentowanie wyników. Coachowie pomagajñ czäonkom zespoäu zachowaè samodyscyplinö, uäatwiajñc zachowanie kontroli nad trudniejszymi praktykami, takimi jak zarzñdzanie ryzykiem, wytwarzanie sterowane testami, zapas oraz stopniowy rozwój projektu i architektury.

UWAGA Coach to inna funkcja niĔ mentor (zobacz punkt „Szukanie mentora” w rozdziale 2.). Mentor to osoba spoza zespoäu, którñ jego czäonkowie mogñ poprosiè o pomoc.

Coach programista KaĔdy zespóä potrzebuje coacha programisty, który odpowiada za pomoc innym programistom w zakresie technicznych praktyk XP. Funkcjö tö czösto peäni starszy programista, który moĔe zajmowaè stanowisko „kierownika technicznego” lub „architekta”. MoĔe to byè nawet menedĔer funkcjonalny. Choè niektórzy coachowie programiĈci sñ dobrymi coachami ogólnymi, wiökszoĈè wymaga pomocy ze strony menedĔera projektu. Coachowie programiĈci wykonujñ ponadto zadania zwykäych programistów i w peäni uczestniczñ w wytwarzaniu oprogramowania.

MenedŜer projektu MenedĔerowie projektu pomagajñ zespoäowi wspóäpracowaè z resztñ organizacji. Zwykle dobrze radzñ sobie z nauczaniem praktyk niezwiñzanych z programowaniem. W tej roli dobrze sprawdzajñ siö takĔe niektórzy menedĔerowie funkcjonalni. WiökszoĈè menedĔerów projektu nie ma jednak wystarczajñcej wiedzy technicznej, aby szkoliè innych z obszaru praktyk programistycznych, co wymaga pomocy ze strony coacha programisty. MenedĔerowie projektu mogñ takĔe peäniè funkcjö klientów.

UWAGA NaleĔy zaangaĔowaè coacha programistö i zastanowiè siö nad wäñczeniem do zespoäu menedĔera projektu.

Pozostali czĥonkowie zespoĥu Przedstawione wczeĈniej role sñ najczöĈciej spotykane, ale lista ta nie jest kompletna. Brak opisu danej funkcji nie oznacza, Ĕe jest ona nieodpowiednia dla zespoäów stosujñcych XP. Grupa powinna skäadaè siö z dokäadnie takich specjalistów, jacy sñ potrzebni do udanego i ekonomicznego ukoþczenia projektu. Na przykäad w skäad jednego z zespoäów, w których pracowaäem, wchodziä autor dokumentacji technicznej i analityk ze znajomoĈciñ standardu ISO 9001.

ZESPÓĤ W XP

51

Spoĥecznoļë projektowa Projekty nie sñ realizowane w próĔni. Wokóä kaĔdego zespoäu istnieje caäy ekosystem. Rozszerza siö on poza zespóä i obejmuje spoäecznoĈè projektowñ3. W jej skäad wchodzñ wszystkie osoby, które majñ wpäyw na projekt lub zaleĔñ od jego wyników. Warto pamiötaè o tej spoäecznoĈci przy uruchamianiu projektu opartego na XP, poniewaĔ jej czäonkowie mogñ mieè wpäyw na powodzenie prac. Dwóch czäonków spoäecznoĈci projektowej, o których äatwo zapomnieè, to dziaäy kadr i infrastruktury organizacji. Dziaä kadr czösto odpowiada za przeglñdy wydajnoĈci i obliczanie wynagrodzenia. Mechanizmy stosowane w tym dziale mogñ nie przystawaè do zespoäowego charakteru pracy w zespoäach stosujñcych XP (zobacz punkt „Zaufanie” w rozdziale 6.). Aby zastosowaè podejĈcie XP, potrzebna jest pomoc dziaäu infrastruktury przy tworzeniu otwartego pomieszczenia roboczego (zobacz punkt „Wspólna praca” w rozdziale 6.).

Udziaĥowcy Udziaäowcy stanowiñ duĔñ czöĈè spoäecznoĈci projektowej. Nie tylko wyniki projektu majñ na nich wpäyw, ale takĔe jego powodzenie jest dla nich waĔne. Udziaäowcy to miödzy innymi uĔytkownicy koþcowi, kupcy, menedĔerowie i kierownictwo. Choè nie uczestniczñ oni w codziennej pracy nad rozwojem, naleĔy zaprosiè ich na demonstracjö kaĔdej iteracji. Przedstawiciele klientów, zwäaszcza menedĔer produktu, odpowiadajñ za zrozumienie potrzeb udziaäowców, okreĈlenie, które z nich sñ najwaĔniejsze, a takĔe ustalenie, jak najlepiej je zaspokoiè.

Wĥaļciciel projektu WäaĈciciel projektu (ang. executive sponsor) to bardzo waĔna postaè: odpowiada za finanse projektu. NaleĔy poĈwiöciè szczególnñ uwagö okreĈleniu, kim jest wäaĈciciel projektu i jakie sñ jego oczekiwania. To ostateczny klient zespoäu. Trzeba regularnie przedstawiaè mu wersje demonstracyjne i upewniaè siö, Ĕe projekt toczy siö zgodnie z jego oczekiwaniami.

PRAKTYKI XP WEDĤUG RÓL abe a 3 6 przedstaw a praktyk , które na eŜy poznaë, aby nauczyë s ý stosowaë podejļc e XP Oczyw ļc e zawsze moŜna zapoznaë s ý z w ýkszé ch czbé Zwĥaszcza osoby, które peĥn é ro ý dera ( ub chc aĥyby zajmowaë to stanow sko), pow nny poznaë wszystk e praktyk Tabela 3.6. Praktyki XP wedäug ról Praktyk XP

Przedstaw c ele kl enta

Program ļc

Testerzy

Coachow e

Myļlen e P og amowanie w pa ach

3

+

Ene giczna p aca

+

nfo macyjne miejsce p acy

+

Analizy p zyczynowo skutkowe

+

Ret ospekcja

+

Dziökujö za to pojöcie Davidowi Schmaltzowi i Amy Schwartz z True North pgs, Inc.

52

ROZDZ AĤ 3

ZROZUM Eê XP

Praktyk XP

Przedstaw c ele kl enta

Program ļc

Testerzy

Coachow e

Wspóĥpraca Zaufanie

+

Wspólna p aca

+

ZaangaŜowanie p awdziwych klientów

+

Z ozumiaĥy jýzyk

+

K ótkie spotkania obocze

+

Standa dy pisania kodu

+

Demonst acja ite acji

+

+

Rapo ty

+

Wydan a +

+

+

B ak bĥýdów

„W peĥni gotowe”

+

+

+

+

Kont ola we sji

+

Dziesiýciominutowa kompilacja

+

Ciégĥa integ acja

+

Wspóĥwĥasnoļë kodu

+

Dokumentacja

+

Planowan e Wizja

+

+

Planowanie we sji

+

+

G a planistyczna

+

Za zédzanie yzykiem

+

Planowanie ite acji

+

+

Zapas

+

Opowieļci

+

Szacowanie

+

Wytwarzan e Stopniowe ok eļlanie wymagaħ

+

Testy klienta

+

+ +

Wytwa zanie ste owane testami

+

Refakto yzacja

+

P osty p ojekt

+

Stopniowy ozwój p ojektu i a chitektu y

+

Rozwiézania punktowe

+

Optymalizacja wydajnoļci

+

Testy eksplo acyjne

+

+

+

= e ro e sé zw ézane z dané praktyké Jej poznan e jest pomocne, a e n eobow ézkowe + = Na eŜy starann e zapoznaë s ý z dané praktyké

ZESPÓĤ W XP

53

Przypisywanie ról Dokäadna struktura zespoäu nie jest bardzo istotna, jeĈli tylko grupa posiada caäñ niezbödnñ wiedzö. Budowa zespoäu zwykle zaleĔy przede wszystkim od zwyczajów panujñcych w organizacji. Inaczej mówiñc, jeĈli menedĔerowie projektu i testerzy to typowi czäonkowie zespoäów w danej organizacji, warto ich zaangaĔowaè. W przeciwnym razie ich obecnoĈè nie jest niezbödna. Nie trzeba przypisywaè róĔnych osób do poszczególnych ról — niektórzy czäonkowie zespoäu mogñ peäniè kilka funkcji. Trzeba jednak pamiötaè, Ĕe ktoĈ musi wykonywaè zadania zwiñzane z danñ rolñ, nawet jeĈli nie jest ona formalnie przypisana do Ĕadnej osoby. Jednak uwaĔam, Ĕe warto bezpoĈrednio obsadziè przynajmniej role „menedĔera produktu” (ta osoba moĔe wykonywaè takĔe inne zadania klienta) i „coacha programisty” (który ponadto peäni obowiñzki zwykäego programisty). Pozostaäe role moĔna äñczyè ze sobñ. MenedĔerowie produktu to zwykle eksperci z dziedziny i czösto mogñ peäniè takĔe obowiñzki menedĔera projektu. Jeden z klientów moĔe odgrywaè rolö projektanta interakcji, zwykle przy pomocy programisty UI. W obszarze pisania kodu wielu programistów ma rozlegäñ wiedzö i zna wiele technologii. W przypadku braku testerów zarówno programiĈci, jak i klienci powinni wykonywaè w wolnym czasie ich zadania.

Wielkoļë zespoĥu Wskazówki przedstawione w tej ksiñĔce sñ oparte na zaäoĔeniu, Ĕe zespóä liczy od 4 do 10 programistów (od 5 do 20 wszystkich czäonków). W nowych zespoäach zaangaĔowanie od 4 do 6 programistów to dobry punkt wyjĈcia. Zastosowanie w zespole skäadajñcym siö z szeĈciu programistów wytycznych dotyczñcych stosunku liczby róĔnych pracowników prowadzi do utworzenia grupy, która obejmuje ponadto czterech klientów, jednego testera i menedĔera projektu, co daje razem 12 osób. Czösto okazuje siö, Ĕe jest to naturalny limit, powyĔej którego wspóäpraca w zespole staje siö trudna. Zespoäy stosujñce XP mogñ byè bardzo maäe i skäadaè siö z tylko jednego doĈwiadczonego programisty i jednego menedĔera produktu. Jednak stosowanie kompletnej metody XP w tak maäych grupach to pewna przesada. Najmniejszy zespóä, w którym moim zdaniem warto uĔyè XP, skäada siö z piöciu osób: czterech programistów (jeden z nich powinien peäniè obowiñzki coacha) i jednego menedĔera produktu (który jest jednoczeĈnie menedĔerem projektu, ekspertem z dziedziny i testerem). W takim zespole moĔe siö okazaè, Ĕe menedĔer produktu ma za duĔo obowiñzków. W takiej sytuacji programiĈci muszñ go wspomóc. Pomocne bödzie wtedy doäñczenie do grupy eksperta z dziedziny lub testera. Na drugim kraþcu skali znajdujñ siö zespoäy oparte na 10 programistach, co prowadzi do utworzenia 20-osobowej grupy, która skäada siö dodatkowo z szeĈciu klientów, trzech testerów i menedĔera projektu. MoĔna utworzyè nawet wiökszy zespóä, jednak wymaga to zastosowania specjalnych praktyk, których omawianie wykracza poza zakres tej ksiñĔki. Jednak przed rozszerzeniem zespoäu do ponad 12 osób warto siö zastanowiè. W wiökszych grupach koszty komunikowania siö i przebiegu procesu sñ wyĔsze, co zmniejsza produktywnoĈè jednostkowñ. ãñczne koszty mogñ nawet zmniejszyè ogólnñ wydajnoĈè. JeĈli to moĔliwe, warto raczej zatrudniè bardziej produktywnych czäonków zespoäu niĔ powiökszaè grupö.

54

ROZDZ AĤ 3

ZROZUM Eê XP

20-osobowy zespóä wymaga zaawansowanych technik XP. NaleĔy unikaè pracy w tak duĔych grupach, chyba Ĕe organizacja odnosiäa juĔ duĔe sukcesy, stosujñc to podejĈcie w mniejszych zespoäach. Przy pracy w takich grupach niezbödne sñ ciñgäe przeglñdy, dostosowywanie procesu i doĈwiadczony coach.

NaleĔy preferowaè lepsze nad wiöksze.

Peĥnoetatowi czĥonkowie zespoĥu Wszyscy czäonkowie zespoäu powinni przebywaè z grupñ w peänym wymiarze godzin i poĈwiöcaè projektowi caäñ uwagö. Dotyczy to przede wszystkim klientów, którzy czösto sñ zaskoczeni poziomem zaangaĔowania wymaganym od nich w XP. W niektórych organizacjach powszechne jest przypisywanie osób do wielu równolegle toczñcych siö projektów. Takie czöĈciowe przypisywanie szczególnie czösto ma miejsce w organizacjach opartych na zarzñdzaniu sieciowym. JeĈli czäonkowie zespoäu majñ po dwóch kierowników — jednego w ramach projektu i drugiego zwiñzanego ze stanowiskiem — prawdopodobnie pracujñ w organizacji tego typu. JeĈli w danej firmie stosuje siö czöĈciowe CzöĈciowe przypisywanie przypisywanie, mam dla jej pracowników dobrñ to bardzo niewydajna technika. wiadomoĈè: organizacja moĔe bäyskawicznie zwiökszyè produktywnoĈè, przypisujñc osoby do tylko jednego projektu naraz. CzöĈciowe przypisywanie to bardzo niewydajna technika. Osoby pracujñce w ten sposób nie czujñ siö zwiñzane z zespoäem, czösto sñ niedostöpne, kiedy ktoĈ chce z nimi porozmawiaè lub zadaè pytanie, a takĔe muszñ przerzucaè siö miödzy zadaniami, co prowadzi do znacznego ukrytego spadku wydajnoĈci. „Minimalne koszty to 15% […]. Pracownicy o fragmentarycznej wiedzy mogñ wyglñdaè na bardzo zajötych, jednak ich praca to w duĔym stopniu po prostu chaotyczne przeskakiwanie miödzy zadaniami” [DeMarco 2002, s. 19 – 20].

UWAGA JeĈli zespóä ma wiele doraĒnych zleceþ, korzystne moĔe byè wprowadzenie roli „batmana”. Opis tej funkcji zawiera podrozdziaä „Planowanie iteracji” w rozdziale 8.

Nie chcö przez to powiedzieè, Ĕe wszystkie osoby musza pracowaè z zespoäem przez caäy czas trwania projektu. MoĔna doäñczyè kogoĈ do zespoäu tymczasowo, aby pomógä rozwiñzaè problem. Jednak w czasie, kiedy ta osoba wspóäpracuje z grupñ, powinna byè w peäni zaangaĔowana i zawsze dostöpna.

Pojýcia zwiézane z XP XP, podobnie jak kaĔda inna wyspecjalizowana dziedzina, ma odröbne säownictwo. Ujmuje ono szereg istotnych zagadnieþ w zwiözäe pojöcia. Wszelkie powaĔne analizy XP (i programowania zwinnego w ogóle) opierajñ siö na tym säownictwie. PoniĔej przedstawione sñ najczöĈciej uĔywane pojöcia.

POJüC A ZW èZANE Z XP

55

Rozpoznanie momentu, w którym zespóä ma juĔ wystarczajñcñ iloĈè informacji, jest trudne. Przy stosowaniu przedziaäów czasu (ang. timeboxing) zespóä ustala czas na analizy lub dyskusje i niezaleĔnie od uzyskanych wyników koþczy pracö, kiedy ten okres upäynie. Jest to trudna, ale wartoĈciowa technika. Trudno zaprzestaè pracy nad problemem, kiedy rozwiñzanie jest na wyciñgniöcie röki. Jednak okreĈlenie momentu, w którym osiñgniöto maksymalny moĔliwy postöp, to waĔna umiejötnoĈè w zarzñdzaniu czasem. Stosowanie przedziaäów czasu na przykäad w trakcie spotkaþ pozwala uniknñè niepotrzebnych sporów.

Ostatni moment na podjýcie zobowiézaħ W XP zmiany sñ traktowane jak okazje do wykorzystania i jak moĔliwoĈè nauczenia siö czegoĈ waĔnego. Dlatego zespoäy stosujñce XP odkäadajñ angaĔowanie siö do ostatniego momentu na podjöcie zobowiñzaþ4. Warto zwróciè uwagö na to, Ĕe jest to ostatni moment na podjöcie zobowiñzaþ, a nie ostatni moĔliwy moment. Jak opisali to Poppendieck i Poppendieck, naleĔy podejmowaè decyzje w „momencie, w którym brak wyboru uniemoĔliwia realizacjö innych moĔliwoĈci. JeĈli zobowiñzania zostanñ podjöte póĒniej, wybór bödzie wymuszony, a ten sposób podejmowania decyzji zwykle nie jest najlepszy” [Poppendieck i Poppendieck]. Dziöki odroczeniu decyzji do tego istotnego momentu moĔna zwiökszyè jej säusznoĈè, zmniejszyè potrzebne nakäady pracy i wpäyw zmian. Dlaczego? OpóĒnienie daje czas na zebranie dodatkowych informacji przydatnych przy podejmowaniu decyzji, co zwiöksza prawdopodobieþstwo dokonania prawidäowego wyboru. To z kolei zmniejsza nakäady pracy, poniewaĔ nie trzeba wykonywaè przeróbek wynikajñcych z podjöcia bäödnych decyzji. Reagowanie na zmiany jest äatwiejsze, poniewaĔ istnieje mniejsze prawdopodobieþstwo, Ĕe trzeba bödzie zmieniè decyzjö lub dokonaè dodatkowych modyfikacji. Podrozdziaä „Planowanie wydania” w rozdziale 8. zawiera przykäad zastosowania tej techniki.

Opowieļci OpowieĈci (ang. stories) przedstawiajñ niezaleĔne, pojedyncze elementy projektu. Zwykle odpowiadajñ odröbnym funkcjom, a na ich realizacjö zespóä potrzebuje dnia lub dwóch pracy. OpowieĈci sñ skoncentrowane na kliencie i opisujñ efekty w kategoriach wyników biznesowych. Nie zawierajñ szczegóäów implementacji ani peänej specyfikacji wymagaþ. Tradycyjnie sñ to po prostu informacje mieszczñce siö na karteczkach i säuĔñce do planowania zadaþ. Wiöcej informacji na ten temat zawiera punkt „OpowieĈci” w rozdziale 8.

Iteracje Iteracja to peäny cykl, przez który przechodzñ zespoäy stosujñce XP, a obejmuje: projektowanie, pisanie kodu, sprawdzanie go i udostöpnianie. Jest to przedziaä czasu, który zwykle trwa od jednego do trzech tygodni. Nowo powstaäym zespoäom polecam iteracje jednotygodniowe 4

Pojöcie „ostatni moment na podjöcie zobowiñzaþ” (ang. last responsible moment) wymyĈlili pracownicy organizacji Lean Construction Institute. W dziedzinie rozwoju oprogramowania spopularyzowano je w [Poppendieck i Poppendieck].

POJüC A ZW èZANE Z XP

57

(zobacz podrozdziaä „Planowanie iteracji” w rozdziale 8.). KaĔda iteracja rozpoczyna siö od wyboru przez klienta opowieĈci opracowywanych przez zespóä w danym tygodniu. Koniec to moment, kiedy zespóä utworzy oprogramowanie, które klient moĔe zainstalowaè i wypróbowaè. Poczñtek kaĔdej iteracji to czas, kiedy klient moĔe zmieniè kierunek realizacji projektu. Krótsze iteracje umoĔliwiajñ czöstsze dostosowywanie. Iteracje o staäej däugoĈci zapewniajñ ĈciĈle okreĈlony rytm rozwoju. Choè moĔe siö wydawaè, Ĕe krótkie i czöste iteracje wiñĔñ siö z wysokimi kosztami planowania, zwykle proces ten trwa proporcjonalnie do däugoĈci iteracji. Wiöcej informacji o iteracjach w podejĈciu XP zawiera podrozdziaä „Planowanie iteracji”.

Szybkoļë W dobrze zaprojektowanych systemach szacunki programistów dotyczñce nakäadów pracy sñ zwykle powtarzalne, ale niedokäadne. Zdarzajñ siö takĔe przerwy, które powodujñ, Ĕe szacunki däugoĈci pracy nie odpowiadajñ czasowi kalendarzowemu. SzybkoĈè to prosty sposób na odwzorowanie szacunkowych nakäadów pracy na daty. Jej wysokoĈè odpowiada sumie szacunków dotyczñcych opowieĈci ukoþczonych w jednej iteracji. Ogólnie zespóä powinien zachowywaè tö samñ szybkoĈè w kaĔdej iteracji. UmoĔliwia to podejmowanie zobowiñzaþ w iteracjach i przewidywanie czasu wydania. Jednostki miary sñ celowo ogólne. SzybkoĈè to technika przeksztaäcania szacunków dotyczñcych nakäadów pracy na czas kalendarzowy i nie dotyczy wydajnoĈci. Wiöcej informacji na ten temat zawiera podrozdziaä „SzybkoĈè” w rozdziale 8.

Teoria ograniczeħ Teoria ograniczeþ Goldratta [Goldratt 1992] opisuje miödzy innymi, Ĕe kaĔdy system ma jedno ograniczenie, które okreĈla jego ogólnñ przepustowoĈè. W tej ksiñĔce zakäadam, Ĕe to programiĈci sñ tym ograniczeniem dla zespoäu. NiezaleĔnie od liczby testerów i klientów, wiökszoĈè zespoäów programistycznych moĔe ukoþczyè projekty tylko tak szybko, jak programiĈci potrafiñ je napisaè. JeĈli reszta zespoäu zanadto wyprzedzi programistów, praca nawarstwi siö, dotrzymanie terminów bödzie niemoĔliwe, a kod bödzie wymagaä przeróbek, co dodatkowo spowolni programistów. Dlatego to programiĈci wyznaczajñ tempo i ich szacunki sñ uĔywane przy planowaniu. Dopóki to programiĈci sñ ograniczeniem, klienci i testerzy majñ wiöcej swobody w harmonogramie i majñ wystarczajñco duĔo czasu na wykonanie zadaþ, zanim ich efekty bödñ potrzebne programistom. Choè w tej ksiñĔce zakäadam, Ĕe to programiĈci sñ ograniczeniem, nie musi tak byè. Zwäaszcza w pracy nad istniejñcym odziedziczonym kodem ograniczeniem sñ testy, a nie programowanie. OdpowiedzialnoĈè za szacunki i wyznaczanie szybkoĈci zawsze spada na osoby, które zajmujñ siö zadaniem ograniczajñcym tempo pracy — w tym przypadku bödñ to testerzy. ProgramiĈci majñ wtedy mniej zadaþ niĔ testerzy i zarzñdzajñ swym czasem tak, aby skoþczyè pracö, zanim testerzy bödñ gotowi do przetestowania opowieĈci.

58

ROZDZ AĤ 3

ZROZUM Eê XP

Co powinny robiè pozostaäe osoby w wolnym czasie? Pomagaè w eliminowaniu ograniczeþ. JeĈli ograniczeniem jest praca testerów, programiĈci mogñ rozwijaè i usprawniaè testy automatyczne.

Rozwaga ZwinnoĈè, czyli umiejötnoĈè efektywnego reagowania na zmiany, wymaga, aby kaĔdy poĈwiöcaä uwagö na proces i praktyki rozwoju. Na tym wäaĈnie polega rozwaga (ang. mindfulness). Czasem zalegäe zmiany sñ wyrafinowane. JeĈli dodanie nowej funkcji jest trudniejsze niĔ w poprzednim tygodniu, moĔe to oznaczaè wzrost däugu technicznego. Zespóä moĔe teĔ zauwaĔyè zmianö w iloĈci i treĈci informacji zwrotnych od klientów. XP daje duĔo moĔliwoĈci w obszarze zbierania informacji zwrotnych z kodu, od wspóäpracowników i przy kaĔdym wykonywanym zadaniu. NaleĔy to wykorzystaè. Trzeba zachowaè czujnoĈè. Zwracaè uwagö na to, co siö zmienia, a co nie, a takĔe czösto omawiaè wyniki.

POJüC A ZW èZANE Z XP

59

60

ROZDZ AĤ 3

ZROZUM Eê XP

ROZDZIAĤ 4

Wprowadzanie XP

„Potrafiö zrozumieè, jak XP moĔe dziaäaè w projektach informatycznych, ale wytwarzanie produktów to coĈ zupeänie innego” — zespóä rozwoju produktu. „Potrafiö zrozumieè, jak XP moĔe dziaäaè przy rozwoju produktu, ale projekty informatyczne to coĈ zupeänie innego” — wewnötrzny zespóä programistyczny. Przed wprowadzeniem XP trzeba ustaliè, czy podejĈcie to jest odpowiednie w danej sytuacji. Czösto automatycznñ reakcjñ na XP jest stwierdzenie: „OczywiĈcie, ta metoda dziaäa w innych zespoäach, ale u nas prawdopodobnie siö nie sprawdzi”. Spróbujö podwaĔyè to zaäoĔenie. Pomogäem wprowadzaè XP wielu róĔnym zespoäom: 20MoĔliwoĈè zastosowania XP i 1-osobowym; w wielkich korporacjach i w maäych, zaleĔy od organizacji i ludzi, poczñtkujñcych organizacjach; w firmach rozwijajñcych a nie od typu projektu. programy komercyjne i u wewnötrznych oraz zewnötrznych producentów oprogramowania; twórcom oprogramowania chronionego prawem autorskim i o otwartym dostöpie do kodu Ēródäowego. W tym czasie nauczyäem siö, Ĕe miödzy zespoäami programistycznymi jest wiöcej podobieþstw niĔ róĔnic. MoĔliwoĈè wprowadzenia XP w o wiele wiökszym stopniu zaleĔy od organizacji i zaangaĔowanych osób niĔ od typu projektu.

Czy XP to coļ dla nas? XP moĔna zastosowaè w wielu róĔnych sytuacjach, choè dobór praktyk zaleĔy od warunków. Praktyki omówione w tej ksiñĔce dajñ najwiökszñ szansö na powodzenie. Prowadzi to do pewnych wymagaþ wstöpnych i zaleceþ dotyczñcych Ĉrodowiska, w którym zespóä pracuje. Nie trzeba ĈciĈle speäniaè tych kryteriów, jednak jeĈli jest to moĔliwe, warto spróbowaè zmieniè Ĉrodowisko. Zapewni to najwiöksze szanse na odniesienie sukcesu. Jak stwierdziä Martin Fowler1:

1

http://martinfowler.com/bliki/EnterpriseRails.html.

61

Pod tym wzglödem dostrzegam podobieþstwa miödzy DHH [David Heinemeier Hansson, twórca Ruby on Rails] a Kentem Beckiem. JeĈli przedstawiè im ograniczony Ĉwiat, spojrzñ na ograniczenia uznawane przez ogóä za staäe, uznajñ je za nieistotne i stworzñ Ĉrodowisko pozbawione tych przeszkód. Ja nie mam tej cechy. Zwykle próbujö pracowaè w ramach ograniczeþ, caäy czas próbujñc je przesuwaè, podczas gdy oni po prostu podkäadajñ pod przeszkody intelektualnñ bombö i ruszajñ dalej. Dlatego potrafili stworzyè coĈ takiego jak programowanie ekstremalne i Rails, które to technologie byäy prawdziwym przeäomem w branĔy. Inaczej mówiñc, jeĈli organizacja stawia bariery miödzy pracñ zespoäu a sukcesem, nie naleĔy tego akceptowaè, tylko znaleĒè sposób na pozbycie siö przeszkód. To najprostsza droga do powodzenia. Podobnie, jeĈli zespóä chce wprowadziè XP, powinien zrobiè wszystko, co moĔliwe, aby speäniè poniĔsze wymagania wstöpne i zastosowaè siö do zaleceþ. Jest to duĔo lepsze rozwiñzanie niĔ ciñgäe zmaganie siö z ograniczeniami.

Wymaganie wstýpne numer 1: wsparcie zarzédu Bardzo trudno jest stosowaè XP wbrew zarzñdowi. Najlepsze jest aktywne wsparcie ze strony menedĔerów. Aby stosowaè XP w wersji opisanej w tej ksiñĔce, potrzebne bödñ: x wspólne pomieszczenie robocze ze stanowiskami do pracy w parach (zobacz podrozdziaä

„Wspólna praca” w rozdziale 6.);

x przypisanie czäonków zespoäu wyäñcznie do danego projektu opartego na XP (zobacz

podrozdziaä „Zespóä w XP” w rozdziale 3.); x menedĔer produktu, przedstawiciele klientów i testerzy (te funkcje takĔe sñ opisane

w podrozdziale „Zespóä w XP” w rozdziale 3.). Czösto w speänieniu tych trzech wymagaþ potrzebna jest pomoc zarzñdu. Ponadto w im wiökszym stopniu zarzñd zapewni poniĔsze elementy, tym lepiej: x uprawnienia dla zespoäu w obszarze caäego procesu rozwoju, wäñcznie z kompilacjami,

budowñ bazy danych i kontrolñ wersji; x praktyki zwiñzane z ocenñ i wynagrodzeniem dostosowane do pracy zespoäowej; x akceptacja nowych sposobów przedstawiania postöpów i wyników (zobacz podrozdziaä

„Raporty” w rozdziale 6.); x cierpliwoĈè w obliczu obniĔonej produktywnoĈci w czasie, kiedy zespóä dopiero siö uczy.

Jeļli zarzéd nie wspiera zespoĥu… JeĈli zarzñd ma wspieraè wprowadzenie XP, musi wierzyè w korzyĈci, jakie daje to podejĈcie. Warto zastanowiè siö, na czym zaleĔy decydentom. Co dla czäonków zarzñdu oznacza sukces organizacji? Co oznacza dla nich sukces osobisty? Jak wprowadzenie XP pomoĔe im osiñgnñè sukcesy? Jakie sñ zagroĔenia zwiñzane z wprowadzaniem XP, jak moĔna je zniwelowaè i co sprawia, Ĕe stosowanie XP jest warte poniesienia ryzyka? Trzeba myĈleè w kategoriach postrzegania sukcesu przez menedĔerów, a nie wäasnego powodzenia.

62

ROZDZ AĤ 4

WPROWADZAN E XP

JeĈli w firmie pracuje zaufany menedĔer, do którego moĔna siö zwróciè, warto poprosiè go o pomoc i radö. JeĈli w organizacji nie ma takiej osoby, moĔna porozmawiaè z mentorem (zobacz podrozdziaä „Szukanie mentora” w rozdziale 2.). Inne dobre Ēródäo wiedzy to ksiñĔka Fearless Change: Patterns for Introducing New Ideas [Manns i Rising]. JeĈli zarzñd odrzuca starania zespoäu, zwykle nie naleĔy wprowadzaè XP. MoĔliwe, Ĕe uda siö stopniowo dowieĈè wartoĈci XP przez przyjöcie pewnych pojedynczych praktyk (zobacz punkt „Ekstremalne rozwiñzania: stosowanie fragmentów XP” w dalszej czöĈci rozdziaäu).

Wymaganie wstýpne numer 2: zgoda zespoĥu Zgoda zespoäu na wprowadzenie XP jest równie waĔna jak wsparcie zarzñdu. JeĈli czäonkowie zespoäu nie chcñ stosowaè XP, prawdopodobnie podejĈcie to nie bödzie dziaäaè. XP wymaga dobrej woli czäonków zespoäu. Nie ma moĔliwoĈci narzucenia procesu osobie, która nie chce go uĔywaè.

Jeļli czĥonkowie zespoĥu siý opierajé… Zmuszanie pracowników do stosowania XP wbrew ich woli to zäy pomysä. W najlepszym przypadku czäonkowie zespoäu znajdñ sposób na opuszczenie grupy, w razie potrzeby rezygnujñc z pracy. W najgorszym — pozostanñ w zespole i bödñ ukrycie sabotowaè jego pracö. Niezdecydowani sceptycy nie stanowiñ wiökszego problemu. JeĈli ktoĈ stwierdzi: „Nie chcö stosowaè XP, jednak widzö, Ĕe pozostali czäonkowie zespoäu majñ na to ochotö, wiöc wypróbujmy to podejĈcie przez kilka miesiöcy”, wtedy wszystko jest w porzñdku. Taka osoba moĔe w koþcu przekonaè siö do metody. W przeciwnym razie po kilku miesiñcach bödzie moĔna lepiej okreĈliè, co zrobiè, aby zaspokoiè potrzeby caäego zespoäu.

UWAGA Jednym ze sposobów na uzyskanie zgody na wypróbowanie XP jest obietnica ponownego rozwaĔenia tej decyzji po upäywie okreĈlonego czasu. JeĈli to moĔliwe, powinny to byè przynajmniej dwa lub trzy miesiñce. JeĈli wtedy zespóä wciñĔ nie chce stosowaè XP, naleĔy zrezygnowaè z wprowadzania metody.

JeĈli tylko jeden lub dwóch czäonków zespoäu sprzeciwia siö wprowadzeniu XP, a osoby te sñ zainteresowane pracñ przy innym projekcie, naleĔy zezwoliè im na zmianö grupy, dziöki czemu zespóä bödzie mógä wypróbowaè metodö. JeĈli nie ma innych projektów lub wprowadzeniu XP sprzeciwia siö wiöcej osób, nie naleĔy stosowaè tego podejĈcia.

Wymaganie wstýpne numer 3: praca zespoĥu w jednym miejscu Wiele praktyk XP wymaga szybkiej i äatwej komunikacji. Aby byäa ona moĔliwa, czäonkowie zespoäu muszñ pracowaè w jednym pomieszczeniu.

Jeļli zespóĥ nie pracuje w jednym miejscu… Poäñczenie zespoäu ma duĔy wpäyw na jego efektywnoĈè. Nie naleĔy z góry zakäadaè, Ĕe grupa nie moĔe pracowaè w jednym miejscu. Trzeba pamiötaè, Ĕe zebranie zespoäu razem to najlepsze rozwiñzanie.

CZY XP TO COĻ D A NAS?

63

Jednak dozwolone jest, aby jedna lub dwie osoby, które nie peäniñ kluczowych funkcji, czasem pracowaäy osobno. Dla zespoäu czösto zaskakujñca jest trudnoĈè komunikowania siö z takimi ludĒmi. W rzeczywistoĈci porozumiewanie siö z nimi jest równie trudne jak wczeĈniej; to po prostu komunikacja z resztñ zespoäu jest äatwiejsza. Warto porozmawiaè z mentorem (zobacz podrozdziaä „Szukanie mentora” w rozdziale 2.), aby ustaliè najlepsze rozwiñzanie tego problemu. JeĈli wiele osób pracuje w innym miejscu, jeĈli najwaĔniejsi czäonkowie sñ czösto nieobecni lub jeĈli zespóä jest rozproszony po kilku siedzibach, potrzebna jest pomoc wykraczajñca poza zakres tej ksiñĔki. W zespoäach rozproszonych moĔna zastosowaè XP lub inne metody zwinne, jednak jest to skomplikowane zagadnienie, którego omawianie wykracza poza zakres przedstawianych tu analiz. Warto poprosiè o pomoc mentora i zapoznaè siö z pomysäami z podrozdziaäu „Wspólna praca” w rozdziale 6.

Wymaganie wstýpne numer 4: przedstawiciele klientów Przedstawiciele klientów to klucz do sukcesu zespoäów stosujñcych XP. To oni — z menedĔerem produktu na czele — okreĈlajñ, które funkcje zespóä bödzie rozwijaä. Inaczej mówiñc, to ich decyzje majñ wpäyw na wartoĈè oprogramowania.

Decyzje przedstawicieli klientów okreĈlajñ wartoĈè oprogramowania.

SpoĈród wszystkich przedstawicieli klientów najwaĔniejszy jest menedĔer produktu. To on ma najwiökszy wpäyw na wartoĈè oprogramowania. Dobry menedĔer produktu wybiera funkcje, które zapewniñ wartoĈè firmie. Zäy menedĔer sprawia, Ĕe zespóä marnuje czas na rozwój maäo istotnych mechanizmów. WaĔni sñ teĔ eksperci z dziedziny i zwykle równieĔ projektanci interakcji. Wykonujñ oni zadania odpowiadajñce wczesnej fazie zbierania wymagaþ, wspóäpracujñ z zespoäem przy przygotowywaniu planu rozwoju nastöpnych funkcji i odpowiadajñ na pytania dotyczñce tego, jak oprogramowanie ma dziaäaè.

Jeļli menedŜer produktu jest zbyt zajýty, aby mógĥ przebywaë z zespoĥem… JeĈli do zespoäu naleĔy doĈwiadczony menedĔer produktu, który podejmuje decyzje wysokiego poziomu dotyczñce funkcji i priorytetów, jednak nie zawsze jest dostöpny i nie moĔe przez caäy czas przebywaè z zespoäem, moĔna poprosiè analityka biznesowego lub innego przedstawiciela klienta o peänienie roli poĈrednika. Taka osoba dziaäa w zastöpstwie menedĔera produktu i podejmuje szczegóäowe decyzje zgodne z przygotowanymi przez niego ogólnymi wytycznymi. To rozwiñzanie sprawdza siö, jeĈli poĈrednik ma wiedzö umoĔliwiajñcñ mu zastöpowanie menedĔera produktu. JeĈli nie potrafi samodzielnie odpowiadaè na pytania i musi uzgadniaè kaĔdñ decyzjö z prawdziwym menedĔerem, powstajñ zbyt duĔe opóĒnienia, aby wersja XP prezentowana w tej ksiñĔce byäa skuteczna.

Jeļli menedŜerowi produktu brakuje doļwiadczenia… Nie sprawia to problemu, jeĈli tylko dostöpni sñ bardziej doĈwiadczeni wspóäpracownicy, których menedĔer moĔe poprosiè o radö.

64

ROZDZ AĤ 4

WPROWADZAN E XP

Jeļli w ogóle nie moŜna zaangaŜowaë menedŜera produktu… Zapotrzebowanie na dobrych menedĔerów produktu jest duĔe, a brak takiej osoby to powaĔne zagroĔenie. Odpowiedni kandydat na to stanowisko nie musi mieè tytuäu „menedĔera produktu” (zobacz podrozdziaä „ZaangaĔowanie prawdziwych klientów” w rozdziale 6.), jednak w XP w zespoäach potrzebny jest ktoĈ z bogatñ wiedzñ z dziedziny, kto bödzie odpowiadaä za wybór funkcji i okreĈlanie priorytetów. Warto przypomnieè decydentom o kosztach rozwoju (mogñ to byè setki tysiöcy zäotych) i wartoĈci, jakñ da oprogramowanie (nawet miliony zäotych). Ta wartoĈè zaleĔy od zaangaĔowania dobrego menedĔera produktu. Czy na pewno warto oszczödzaè na tym aspekcie? JeĈli nie moĔna znaleĒè menedĔera produktu, jego funkcjö powinien przejñè ktoĈ z zespoäu programistycznego, jednak jest to doĈè ryzykowne podejĈcie, poniewaĔ taka osoba zwykle nie ma doĈwiadczenia biznesowego potrzebnego do zapewnienia sukcesu na poziomie organizacji. JeĈli nie moĔna zaangaĔowaè menedĔera produktu, naleĔy zapytaè mentora o moĔliwoĈè zrekompensowania tego braku.

Jeļli nie moŜna zaangaŜowaë innych przedstawicieli klientów… PoniewaĔ w XP nie ma wczesnej fazy zbierania wymagaþ, praca zwiñzana z ich ustalaniem odbywa siö równolegle z rozwojem oprogramowania. Skraca to czas rozwoju i oznacza, Ĕe przynajmniej jedna osoba (a zwykle wiöcej) musi caäy czas pracowaè nad zbieraniem wymagaþ. W przypadku wiökszych zespoäów to zadanie jest zwykle zbyt obciñĔajñce, aby mógä mu podoäaè sam menedĔer produktu. Zwykle menedĔer zleca pracö nad szczegóäami grupie ekspertów z dziedziny. W rozwoju aplikacji ze skomplikowanym interfejsem uĔytkownika uczestniczyè moĔe teĔ projektant interakcji. UmoĔliwia to menedĔerowi produktu koncentracjö na koordynowaniu pracy z udziaäowcami i ustalaniu odpowiedzi na pytania z obszaru wartoĈci i priorytetów. Niektórzy analitycy biznesowi sñ jednoczeĈnie ekspertami z dziedziny. NaleĔy zachowaè ostroĔnoĈè przy angaĔowaniu analityków, którzy nie sñ ekspertami. Choè mogñ oni uzyskaè informacje od prawdziwych ekspertów, proces ten niezmiennie prowadzi do nieporozumieþ i opóĒnieþ. JeĈli tylko w zespole znajduje siö osoba, która peäni funkcjö przedstawiciela klienta, moĔna stosowaè XP. Jednak im mniejsza jest wiedza klientów, tym bardziej zagroĔona jest wartoĈè oprogramowania.

Wymaganie wstýpne numer 5: odpowiednia wielkoļë zespoĥu Pisaäem tö ksiñĔkö z myĈlñ zarówno o duĔych zespoäach, obejmujñcych do 20 pracowników, jak i zupeänie maäych, skäadajñcych siö z tylko jednej osoby. Jednak zespoäy dopiero poznajñce XP powinny obejmowaè od 4 do 6 programistów i nie wiöcej niĔ 12 osób äñcznie (zobacz podrozdziaä „Zespóä w XP” w rozdziale 3.). Zalecam teĔ angaĔowanie parzystej liczby programistów, aby wszyscy mogli programowaè w parach (zobacz podrozdziaä „Programowanie w parach” w rozdziale 5.). JeĈli potrzebna jest ciñgäa pomoc techniczna, moĔna zatrudniè dodatkowego programistö, co daje razem piöè lub siedem osób peäniñcych tö funkcjö, dziöki czemu zespóä bödzie obejmowaä „batmana” (zobacz podrozdziaä „Planowanie iteracji” w rozdziale 8.).

CZY XP TO COĻ D A NAS?

65

W zespoäach obejmujñcych mniej niĔ czterech programistów czösto brakuje potrzebnej róĔnorodnoĈci intelektualnej. Trudniej jest teĔ stosowaè programowanie w parach, które jest istotnñ technikñ wspomagajñcñ XP. Z kolei w duĔych zespoäach wystöpujñ problemy z koordynacjñ. O ile doĈwiadczone zespoäy potrafiñ sobie z nimi poradziè, nowym grupom stosujñcym XP zwykle sprawia to trudnoĈè.

Jeļli liczba programistów jest nieparzysta… Najäatwiejszym rozwiñzaniem tego problemu jest doäñczenie lub usuniöcie jednego programisty, aby ich liczba byäa parzysta. JeĈli nie moĔna tego zrobiè, zespóä wciñĔ moĔe stosowaè praktyki XP, jednak warto spróbowaè znaleĒè dla dodatkowego programisty waĔne zadania zwiñzane z kodem nieprodukcyjnym. Uäatwia to grupie spójne stosowanie technicznych praktyk XP i poprawia jakoĈè kodu.

Jeļli zespóĥ obejmuje wiýcej niŜ siedmiu programistów… Problemy z koordynacjñ w duĔych zespoäach mogñ utrudniaè poznawanie XP. Warto rozwaĔyè zatrudnienie doĈwiadczonego coacha, który przeprowadzi zespóä przez trudne poczñtki. Korzystne moĔe byè teĔ zatrudnienie innego programisty z doĈwiadczeniem w XP, który pomoĔe coachowi w prowadzeniu zespoäu. W zespoäach obejmujñcych wiöcej niĔ dziesiöciu programistów potrzebna jest pomoc wykraczajñca poza zakres tej ksiñĔki. Aby dostosowaè XP do tak duĔych grup, trzeba zatrudniè doĈwiadczonego coacha.

Jeļli w skĥad zespoĥu wchodzi mniej niŜ czterech programistów… Nawet w maäych zespoäach moĔna stosowaè wiökszoĈè praktyk XP, jednak prawdopodobnie programowanie w parach bödzie wtedy utrudnione. W takiej sytuacji najlepiej zaangaĔowaè sumiennych programistów, dla których bardzo waĔne jest tworzenie kodu wysokiej jakoĈci. Pasja pomoĔe im zachowaè dyscyplinö przy stosowaniu technicznych praktyk XP. Problemy moĔe sprawiaè takĔe zachöcenie przedstawicieli klientów do ciñgäego przebywania z zespoäem. Dlatego warto pracowaè blisko klienta, aby moĔna byäo zdobyè jego uwagö, kiedy jest to potrzebne.

Jeļli wielu programistów pracuje samodzielnie… W niektórych organizacjach — zwäaszcza informatycznych — rozwijanych jest wiele maäych projektów, a nie jeden duĔy. Struktura pracy opiera siö wtedy na przypisywaniu jednego programisty do kaĔdego projektu. Choè to podejĈcie ma zaletö w postaci bezpoĈredniego powiñzania programistów z projektami, ma teĔ kilka wad. Jest wysoce ryzykowne, poniewaĔ za kaĔdy projekt odpowiada tylko jeden programista. W przypadku jego odejĈcia nie ma nikogo, kto moĔe kontynuowaè pracö. Zastöpcy muszñ poznawaè projekt od podstaw. Ponadto jakoĈè kodu moĔe byè niĔsza. W projektach tego typu nie moĔna przeprowadziè przeglñdu kodu przez wspóäpracownika, dlatego rozwiñzania sñ czösto specyficzne dla programisty. Prowadzi to do powstawania systemów kominowych (ang. stovepipe systems), w których programiĈci rozwiñzujñ ten sam problem na róĔne sposoby. Mäodzi programiĈci,

66

ROZDZ AĤ 4

WPROWADZAN E XP

pozbawieni pomocy starszych kolegów, tworzñ zawiäe, chaotyczne systemy i nie majñ moĔliwoĈci poznania lepszych rozwiñzaþ. Starsi programiĈci, nie zdajñc sobie sprawy z braku doĈwiadczenia mäodszych kolegów, tworzñ nadmiernie zaawansowany kod, który jest trudny do zrozumienia przez innych. Zespóä stosujñcy XP moĔe obejmowaè od czterech do siedmiu programistów, którzy jednoczeĈnie pracujñ nad danym projektem, co umoĔliwia szybsze wykonanie pracy (zobacz podrozdziaä „Planowanie wydaþ” w rozdziale 8.). Dziöki wspólnej pracy starsi programiĈci mogñ podszkoliè mäodszych kolegów i moĔna uniknñè powstawania systemów kominowych. Poäñczenie programistów w jednym zespole ma teĔ pewne wady. Najwiökszñ z nich jest pozorny brak reakcji. Choè projekty trwajñ krócej, nie ma jednego, prowadzñcego je programisty, z którym klienci mogliby porozmawiaè o stanie ich projektów. Zespóä zawsze pracuje nad tylko jednym projektem, dlatego inni klienci mogñ czuè siö ignorowani. Aby rozwiñzaè ten problem, warto rozwaĔyè wyznaczenie jednego programisty do obsäugi Ĕñdaþ klientów i wykonywania drobnych poprawek (zobacz podrozdziaä „Planowanie iteracji” w rozdziale 8.). Potrzebna jest takĔe wpäywowa, niezaleĔna osoba z wiedzñ biznesowñ, która bödzie peäniè rolö menedĔera produktu, rozwiñzywaè konflikty miödzy klientami i okreĈlaè priorytety.

Wymaganie wstýpne numer 6: stosowanie wszystkich praktyk Czösto czäonków zespoäu kusi, aby zignorowaè lub pominñè niektóre praktyki XP, zwäaszcza te, które sprawiajñ im trudnoĈè. NaleĔy siö tego wystrzegaè. PodejĈcie XP jest zaprojektowane tak, aby minimalizowaè marnotrawstwo. Prawie kaĔda praktyka bezpoĈrednio przyczynia siö do tworzenia wartoĈciowego oprogramowania. Przykäadowo, programowanie w parach wspomaga wspóäwäasnoĈè kodu, która jest niezbödna przy refaktoryzacji. Refaktoryzacja pozwala na stopniowy rozwój projektu i architektury. Ten ostatni proces umoĔliwia planowanie skoncentrowane na kliencie i czöste wydania, co jest kluczem do efektów charakterystycznych dla XP: powiökszania wartoĈci i udostöpniania udanego oprogramowania. UĔywanie XP nie wymaga perfekcji. Nic siö nie stanie, jeĈli zespóä od czasu do czasu nieprawidäowo zastosuje jednñ z praktyk. Jednak podejĈcie to rzadko daje oczekiwane wyniki, jeĈli grupa dowolnie usuwa poszczególne elementy metody.

Jeļli dana praktyka nie pasuje… Czasem wydaje siö, Ĕe praktyki XP nie pasujñ do okreĈlonej organizacji. MoĔe to byè prawdñ, jednak moĔliwe, Ĕe zespóä po prostu Ēle siö czuje, stosujñc danñ praktykö, lub nie zna jej wystarczajñco dobrze. Czy praktyka na pewno nie dziaäa, czy moĔe grupa po prostu nie chce jej uĔywaè? XP funkcjonuje duĔo lepiej, kiedy zespóä stosuje wszystkie praktyki, a nie wybiera tylko te, które lubi. JeĈli na pewno wiadomo, Ĕe dana praktyka nie dziaäa, naleĔy jñ zastñpiè. Przykäadowo, aby wykorzystaè zalety wspóäwäasnoĈci kodu bez programowania w parach, trzeba zapewniè czäonkom zespoäu inny sposób na wspóädzielenie informacji o bazie kodu. NaleĔy teĔ wymyĈliè techniki zapewniajñce pozostaäe korzyĈci programowania w parach.

CZY XP TO COĻ D A NAS?

67

Zastöpowanie praktyk wymaga ciñgäego usprawniania i dogäöbnego zrozumienia XP. Warto poprosiè o pomoc mentora (zobacz podrozdziaä „Szukanie mentora” w rozdziale 2.) i rozwaĔyè zatrudnienie doĈwiadczonego coacha z dziedziny XP.

Zalecenie numer 1: nowy kod bazowy Przy stosowaniu XP niezbödny jest kod, w którym äatwo wprowadzaè zmiany. JeĈli sprawia to trudnoĈè, zespóä bödzie miaä problemy przy stosowaniu technicznych praktyk XP, co z kolei wywrze negatywny wpäyw na praktyki zwiñzane z planowaniem. Zespoäy stosujñce XP wkäadajñ wiele wysiäku w to, aby kod byä przejrzysty i umoĔliwiaä äatwe wprowadzanie zmian. Jest to proste, jeĈli grupa tworzy zupeänie nowy kod bazowy. TakĔe w przypadku pracy nad istniejñcym kodem moĔna stosowaè praktyki XP, jednak jest to trudniejsze. Nawet poprawnie konserwowany kod zwykle nie ma prostego projektu i zestawu automatycznych testów jednostek niezbödnych w XP (i rozwijanych w czasie stosowania tej metody). Zespoäy dopiero poznajñce XP czösto dokonujñ zdumiewajñcego odkrycia miödzy drugim a czwartym miesiñcem pracy. „To najlepszy kod, nad jakim kiedykolwiek pracowaäem!” — stwierdzajñ, po czym zaczynajñ dostrzegaè wartoĈè XP. Aby w peäni zrozumieè i doceniè techniczne praktyki XP, trzeba wypróbowaè, jak skuteczne jest ich wspólne dziaäanie. Pozwala to uzyskaè caäkowitñ pewnoĈè co do jakoĈci kodu, testów i kompilacji. Trzeba poczuè radoĈè z wprowadzania duĔych usprawnieþ za pomocñ maäych zmian. Tego typu doznania sñ duĔo rzadsze przy pracy nad istniejñcym kodem. JeĈli to moĔliwe, lepiej jest pozostawiè gotowy kod zespoäom z wiökszym doĈwiadczeniem w stosowaniu XP.

Jeļli zespóĥ musi pracowaë nad istniejécym kodem… MoĔna sobie poradziè z tym problemem. Zobacz podrozdziaä „Stosowanie XP do istniejñcych projektów” w dalszej czöĈci rozdziaäu.

Zalecenie numer 2: wysokie umiejýtnoļci w obszarze projektowania Prosty projekt, w którym moĔna äatwo wprowadzaè zmiany, to podstawa XP. Oznacza to, Ĕe przynajmniej jedna osoba w zespole — najlepiej naturalny lider — musi mieè wysokie umiejötnoĈci w obszarze projektowania. Osobom, które nie majñ wysokich umiejötnoĈci w zakresie tworzenia projektów, trudno wykryè podobne zdolnoĈci u innych. Jednñ ze wskazówek jest zrozumienie i docenianie projektowania skoncentrowanego na dziedzinie. Wymaga to znaczñcej zmiany myĈlenia: z imperatywnego projektowania proceduralnego w kierunku deklaratywnego projektowania obiektowego. ProgramiĈci pozbawieni zdolnoĈci projektowania majñ z tym trudnoĈci.

Jeļli nikt nie jest uzdolnionym projektantem… Nawet w obliczu braku osoby o wysokich umiejötnoĈciach w obszarze projektowania, stosujñc XP, moĔna osiñgnñè przynajmniej takie wyniki, jak uĔywajñc dowolnej innej metody, a prawdopodobnie nawet lepsze, poniewaĔ XP obejmuje praktyki i wskazówki technologiczne. Jednak nie oznacza to pewnego sukcesu. NaleĔy rozpoczñè pracö powoli i w równym tempie oraz w jak najwiökszym stopniu korzystaè z pomocy doĈwiadczonych osób.

68

ROZDZ AĤ 4

WPROWADZAN E XP

W tym czasie trzeba rozpoczñè doksztaäcanie! Dobrym punktem wyjĈcia sñ ksiñĔki DomainDriven Design [Evans] i Patterns of Enterprise Application Architecture [Fowler 2002a]. Warto zastanowiè siö nad udziaäem w szkoleniach lub zatrudnieniem mentora dla zespoäu. NaleĔy jednak uwaĔaè. Wysokie zdolnoĈci w obszarze projektowania sñ równie istotne, co rzadkie. NaleĔy poprosiè kogoĈ, kto ma takie umiejötnoĈci, o pomoc w ocenie dokonanych wyborów.

Zalecenie numer 3: jýzyk ĥatwy do refaktoryzacji XP wymaga refaktoryzacji w celu ciñgäego ulepszania istniejñcych projektów, dlatego kaĔdy jözyk, który jest trudny do refaktoryzacji, utrudnia takĔe stosowanie XP. SpoĈród wspóäczesnych popularnych jözyków najlepsze pod tym wzglödem sñ jözyki obiektowe i dynamiczne, z automatycznym przywracaniem pamiöci. Z kolei takie jözyki jak C i C++ sñ trudniejsze do refaktoryzacji.

Jeļli zespóĥ uŜywa jýzyka trudnego do refaktoryzacji… TakĔe wtedy moĔna stosowaè XP, jednak jeĈli to moĔliwe, warto doäñczyè do zespoäu osobö z doĈwiadczeniem w refaktoryzacji w danym jözyku.

Zalecenie numer 4: doļwiadczony coach programista Niektóre osoby to naturalni liderzy. Potrafiñ podejmowaè decyzje, ale uwzglödniajñ opinie innych. Sñ kompetentni, ale szanujñ zdolnoĈci innych. Czäonkowie zespoäu powaĔajñ takie osoby i ufajñ im. MoĔna rozpoznaè lidera, obserwujñc, jaki ma wpäyw na grupö. NiezaleĔnie od zajmowanego przez lidera stanowiska, inne osoby zwracajñ siö do niego po radö.

UWAGA Przywództwo jest niezaleĔne od tytuäów i stanowisk. Liderami sñ te osoby, które majñ wielu zwolenników, a nie te o skäonnoĈci do wydawania poleceþ. Aby ustaliè, kto jest prawdziwym liderem w zespole, naleĔy zwróciè uwagö na osoby, za którymi inne osoby chcñ podñĔaè.

XP wymaga samoorganizujñcych siö zespoäów. W grupach tego typu nie ma narzuconej hierarchii. Zespóä sam ustala, kto odpowiada za poszczególne zadania. Role sñ zwykle przypisywane nieformalnie. W wielu dojrzaäych zespoäach stosujñcych XP nie ma jednego lidera. Czäonkowie zespoäu päynnie przekazujñ obowiñzki kierownika coraz to innej osobie. To, kto jest obecnie liderem, zaleĔy od czasu, wykonywanych zadaþ i poziomu wiedzy zaangaĔowanych osób. Jednak w trakcie budowania zespoäu praca nie przebiega tak äatwo. KtoĈ musi przypominaè grupie o regularnym i Ĉcisäym przestrzeganiu praktyk XP. Jest to waĔne przede wszystkim wĈród programistów, poniewaĔ ich praktyki sñ najtrudniejsze do opanowania. Inaczej mówiñc, zespóä potrzebuje coacha. Najlepsi z nich to naturalni liderzy, osoby, które przypominajñ innym o prawidäowym wykonywaniu zadaþ bardziej przez swojñ postawö niĔ wydawane polecenia. Coach powinien byè takĔe doĈwiadczonym programistñ, aby mógä pomagaè zespoäowi w stosowaniu technicznych praktyk XP.

CZY XP TO COĻ D A NAS?

69

Jeļli nie ma naturalnego coacha… NaleĔy wyjaĈniè zespoäowi sytuacjö i poprosiè o jednogäoĈny wybór coacha. Grupa powinna wybraè jednñ osobö, co do której wszyscy zgadzajñ siö, Ĕe bödzie dobrze peäniäa tö funkcjö.

UWAGA Przy jednogäoĈnym podejmowaniu decyzji kaĔdy ma prawo weta. Szybki sposób na przeprowadzenie gäosowania w tym trybie to proĈba o wyciñgniöcie kciuka. Kciuk skierowany w górö oznacza zgodö; skierowany w bok to stwierdzenie: „Dostosujö siö do decyzji grupy”; kciuk w dóä oznacza: „Nie zgadzam siö i chcö wyjaĈniè, dlaczego”.

JeĈli nie moĔna jednogäoĈnie wybraè coacha, moĔliwe, Ĕe zespóä jest zbyt podzielony, aby stosowaè XP. Pomóc moĔe wtedy zatrudnienie osoby, której zespóä zaufa. NaleĔy koniecznie poinformowaè jñ, Ĕe zespóä nie mógä dojĈè do konsensusu przy wyborze coacha. Osoba z doĈwiadczeniem z dziedziny XP potraktuje to jako ostrzeĔenie i powinna porozmawiaè z czäonkami grupy przed podjöciem siö zadania.

Jeļli liderzy sé niedoļwiadczeni… Dobrzy liderzy nie muszñ byè doĈwiadczonymi programistami, ale dobry coach powinien zauwaĔaè drobne oznaki, które wróĔñ nadchodzñce problemy, co wymaga praktyki. Dlatego najlepsi coachowie to programiĈci o däugim staĔu. JeĈli liderzy sñ niedoĈwiadczeni, warto wypróbowaè technikö coachingu w parach. NaleĔy wybraè dwie osoby. Jedna z nich powinna byè dobrym liderem, a druga — mieè bogate doĈwiadczenie. Osoby te muszñ dobrze wspóäpracowaè ze sobñ. NaleĔy poprosiè obu coachów o wspólnñ pracö nad przypominaniem zespoäowi o ciñgäym i Ĉcisäym stosowaniu praktyk XP.

Jeļli wyznaczono nieodpowiedniego coacha… Organizacja moĔe wyznaczyè na stanowisko coacha osobö, która nie jest dobrym liderem. JeĈli coach jest Ĉwiadom problemu, rozwiñzaniem moĔe byè coaching w parach. Z kolei jeĈli wyznaczony coach nie zauwaĔa problemu i ma negatywny wpäyw na dziaäanie zespoäu, naleĔy omówiè sytuacjö z mentorem lub zaufanym menedĔerem. Jest to delikatna sytuacja, która wymaga wskazówek specyficznych dla sytuacji.

Zalecenie numer 5: przyjazny i spójny zespóĥ XP wymaga, aby wszyscy pracowali wspólnie przy osiñganiu celów zespoäu. Nie ma tu zadaþ wykonywanych niezaleĔnie, dlatego czäonkowie grupy powinni z przyjemnoĈciñ wspóäpracowaè ze sobñ.

Jeļli czĥonkowie zespoĥu nie przepadajé za sobé… W XP czäonkowie zespoäu muszñ ze sobñ wspóäpracowaè. W poäñczeniu z presjñ cotygodniowego udostöpniania wydaþ podejĈcie to moĔe pomóc grupie nauczyè siö zaufania i wzajemnego szacunku. Jednak moĔliwe, Ĕe presja wywrze na zespóä negatywny skutek. Warto doäñczyè do grupy zrównowaĔonñ osobö, której obecnoĈè uspokaja innych.

70

ROZDZ AĤ 4

WPROWADZAN E XP

JeĈli czäonkowie zespoäu nawet nie próbujñ nawiñzaè wspóäpracy, nie warto stosowaè XP. JeĈli tylko jedna osoba ma negatywny wpäyw na zachowanie innych, moĔna rozwiñzaè problem, przenoszñc jñ do innego zespoäu.

Naprzód! Czy wszyscy sñ juĔ gotowi do wprowadzenia XP? Doskonale! Pierwszy krok to przygotowanie otwartego pomieszczenia roboczego (zobacz podrozdziaä „Wspólna praca” w rozdziale 6.). Warto zajñè siö tym od razu. Prawdopodobnie zajmie to wiöcej czasu, niĔ moĔna oczekiwaè. Nastöpnie naleĔy znaleĒè odpowiedni projekt. Powinien byè wartoĈciowy, jednak naleĔy unikaè zadaþ o znaczeniu strategicznym. Trzeba uwzglödniè moĔliwoĈè wystñpienia bäödów w trakcie nauki.

UWAGA NaleĔy unikaè projektów o niskiej wartoĈci jako „okazji do nauki”, poniewaĔ zespóä moĔe mieè trudnoĈci w zaangaĔowaniu klientów i osiñgniöciu sukcesu na poziomie organizacji. Zarzñd moĔe potraktowaè projekt jako niepowodzenie nawet wtedy, jeĈli zespóä odniesie sukces techniczny.

JednoczeĈnie trzeba ustaliè, kto bödzie wchodziä w skäad zespoäu. Podrozdziaä „Zespóä w XP” w rozdziale 3. zawiera kilka wskazówek na temat struktury grupy. NaleĔy porozmawiaè z wäaĈcicielem projektu i innymi udziaäowcami o tym, kim powinni byè przedstawiciele klientów. RóĔne moĔliwoĈci w tym obszarze opisuje podrozdziaä „ZaangaĔowanie prawdziwych klientów” w rozdziale 6. Trzeba upewniè siö, Ĕe czäonkowie zespoäu sñ gotowi do wypróbowania XP. W trakcie zbierania zespoäu warto zastanowiè siö nad zatrudnieniem doĈwiadczonego coacha z dziedziny XP, aby wspóäpracowaä z grupñ w peänym wymiarze godzin. Choè obecnoĈè coacha nie jest konieczna (ja uczyäem siö XP, czytajñc o tym podejĈciu i stosujñc je), odpowiednia osoba na tym stanowisku sprawi, Ĕe praca bödzie przebiegaè bardziej päynnie.

EKSTREMALNE ZAKUPY K edy zb Ŝa s ý data uruchom en a projektu, na eŜy zapewn ë sp zýt pot zebny w otwartym pom eszczen u roboczym Dobra sta zakupów pow nna zaw eraë pon Ŝsze e ementy Sprzýt x Stanow ska do pracy w parach (zobacz podrozdz aĥ „Programowan e w parach” w rozdz a e 5 ) x Dedykowana maszyna do obsĥug komp acj (zobacz podrozdz aĥ „C égĥa ntegracja” w rozdz a e 7 ) x DŚw ýkochĥonne przegrody do wyznaczen a przestrzen roboczej zespoĥu zapob egan a haĥasom (zobacz podrozdz aĥ „Wspó na praca” w rozdz a e 6 ) x W e e w eszanych tab c, potrzebnych do ana z ysowan a d agramów (zobacz podrozdz aĥ „ nformacyjne m ejsce pracy” w rozdz a e 5 ) Naj epsze sé tab ce magnetyczne, pon ewaŜ umoŜ w ajé p zyczep en e do n ch karteczek przy uŜyc u magnesów x Dw e duŜe tab ce magnetyczne na p any wydaħ teracj Ja ub ý uŜywaë dwustronnych praw e dwumetrowych tab c magnetycznych na kóĥkach, pon ewaŜ umoŜ w ajé przen es en e p anu do pokoju spotkaħ nne zespoĥy wo é tab ce korkowe, jednak uwaŜam, Ŝe zbyt trudno przesuwaë po n ch ka teczk NAPRZÓD

71

x DuŜy p ast kowy w eczny ka endarz (obejmujécy przynajmn ej t zy m es éce) do zaznaczan a waŜnych dat p anowanych n eobecnoļc (zobacz podrozdz aĥ „ nformacyjne m ejsce pracy” w rozdz a e 5 ) x P uszowa maskotka peĥn éca funkcjý symbo u ntegracj (zobacz podrozdz aĥ „C égĥa ntegracja” w rozdz a e 7 ) x RóŜne zabawk stymu atory konwersacj do pobudzan a do dyskusj nterakcj m ýdzy czĥonkam zespoĥu x

nne standardowe wyposaŜen e

Oprogramowanie x Narzýdz e do wykonywan a testów jednostek, na przykĥad program z rodz ny xUn t (zobacz podrozdz aĥ „Wytwa zan e sterowane testam ” w rozdz a e 9 ) x Narzýdz e do automatyzacj komp acj , na p zykĥad program z rodz ny Ant (zobacz podrozdz aĥ „Dz es ýc om nutowa komp acja” w rozdz a e 7 ) x

nne standardowe oprogramowan e

UWAGA Oprogramowanie do zarzédzania ciégĥé integracjé nie jest niezbýdne (zobacz podrozdziaĥ „Ciégĥa integracja” w rozdziale 7.).

Dodatkowe materiaĥy x Karteczk Wa to zakup ë 5000 b aĥych po 2000 w kaŜdym nnym uŜywanym ko o ze Na eŜy zadbaë o dobór ko orów, które wszyscy czĥonkow e zespoĥu potraf é rozróŜn ë (od 7 do 10% mýŜczyzn jest w mn ejszym ub w ýkszym stopn u dotkn ýtych da ton zmem) x Oĥówk do p san a po ka teczkach N e na eŜy uŜywaë dĥugop sów, pon ewaŜ czasem trzeba wprowadz ë zm any x Jedzen e (zobacz podrozdz aĥ „Energ czna praca” w rozdz a e 5 „Zaufan e” w rozdz a e 6 ) x

ab ce f p cha t na zýdz a do przyk ejan a, które jednak n e pozostaw ajé ļ adów (na p zykĥad Ŝóĥta taļma ma arska ub p nezk ) do p zyczep an a d agramów (zobacz podrozdz aĥ „ nformacyjne m ejsce pracy” w rozdz a e 5 )

x Ļc era ne f amastry do p san a po tab cy, wodne marke y do p san a po tab cach f p cha t2 zmywa ne marke y do w ecznych ka enda zy Na eŜy upewn ë s ý, Ŝe moŜna ĥatwo odróŜn ë od s eb e markery kaŜdego typu x Magnesy do przyczep an a dokumentów do tab cy Sk epy z mater aĥam b urowym sprzedajé wésk e, ĥatwe do przesuwan a magnesy, które dobrze nadajé s ý do tego ce u Na eŜy jednak upewn ë s ý, Ŝe sé na ty e mocne, Ŝ ut zymajé przy tab cy karteczký ub dw e x

nne zwyk e uŜywane mater aĥy

Wyzwania przy wprowadzaniu zmian Faktem jest, Ĕe zmiany sñ niewygodne dla ludzi. Wprowadzenie XP to prawdopodobnie duĔa zmiana dla zespoäu. JeĈli grupa uĔywaäa wczeĈniej sztywnych procesów opartych na dokumentacji, metoda XP bödzie sprawiaè wraĔenie luĒnej i nieformalnej. JeĈli zespóä nie stosowaä Ĕadnych procesów, XP bödzie wyglñdaè na podejĈcie sztywne i wymagajñce

2

NaleĔy unikaè markerów niezmywalnych. Przebijajñ one przez papier i mogñ uszkodziè tablicö, jeĈli ktoĈ przez przypadek uĔyje zäego markera.

72

ROZDZ AĤ 4

WPROWADZAN E XP

dyscypliny. W obu przypadkach naleĔy oczekiwaè, Ĕe czäonkowie grupy i udziaäowcy bödñ czuè siö nieswojo. Ten brak komfortu moĔe rozszerzyè siö na inne jednostki organizacji. Brak komfortu i poczucie nieuporzñdkowania to normalne doznania w trakcie wprowadzania zmian, jednak nie zmniejsza to trudnoĈci zwiñzanych z tym procesem. MoĔna spodziewaè siö, Ĕe wraĔenie chaosu bödzie utrzymywaè siö przez przynajmniej dwa miesiñce. Trzeba daè zespoäowi od czterech do dziewiöciu miesiöcy, aby w peäni przyzwyczaiä siö do nowych procesów. Przy stopniowym wprowadzaniu podejĈcia XP ten czas moĔe byè jeszcze däuĔszy. Aby przetrwaè zmiany, trzeba okreĈliè, dlaczego warto je wprowadziè. Jakie korzyĈci zapewniñ organizacji? Co przyniosñ zespoäowi? Co jeszcze waĔniejsze, jak skorzystajñ na nich poszczególni czäonkowie zespoäu? W czasie zmagania siö z chaosem zwiñzanym ze zmianami warto przypominaè sobie o tych korzyĈciach. WaĔne jest takĔe wspomagajñce Ĉrodowisko pracy. Czäonkowie zespoäu prawdopodobnie zareagujñ defensywnie na brak znanej struktury. NaleĔy oczekiwaè zmiennych nastrojów i niestabilnego poziomu dziaäania. Niektórzy czäonkowie zespoäu mogñ byè agresywni lub maäo skäonni do wspóäpracy. Trzeba pamiötaè o doĈwiadczanych niedogodnoĈciach i pomagaè ludziom w konstruktywnym rozäadowywaniu frustracji.

UWAGA Analiza modelu zmian Satira to jeden ze sposobów na zrozumienie reakcji zespoäu na zmiany. Na stronie http://www.stevensmith.com/my-articles/article/the-satir´change-model.html znajduje siö dobry artykuä na temat tego modelu [Smith], zawierajñcy wskazówki na temat pomocy czäonkom grupy na kaĔdym etapie.

Udziaäowcom moĔe nie odpowiadaè nowe podejĈcie zespoäu do planowania i prezentowania postöpów prac. MenedĔerowie i kierownictwo mogñ traktowaè poczñtkowy nieporzñdek w zespole jako oznakö braku skutecznoĈci XP. Aby zapewniè spokój udziaäowców, warto rozwaĔyè podjöcie poniĔszego zobowiñzania. Zobowiñzanie wobec uĔytkowników, zarzñdu i innych udziaäowców. Obiecujemy: x czyniè staäe postöpy; x tworzyè najpierw funkcje uznane za najbardziej wartoĈciowe; x demonstrowaè kaĔdego (dzieþ tygodnia) o (czas) w (lokalizacja) dziaäajñce

oprogramowanie, które odzwierciedla postöp prac dokonany w danym tygodniu; x uczciwie i otwarcie informowaè o sukcesach oraz problemach, a takĔe o tym,

co moĔemy dostarczyè. W zamian prosimy o cierpliwoĈè w stosunku do zmian w wydajnoĈci i o zrozumienie naszych bäödów w trakcie poznawania nowego sposobu pracy przez najbliĔsze póä roku.

Ostateczne przygotowania Przed uruchomieniem XP warto przedyskutowaè nieformalne ustalenia dotyczñce wspóäpracy (ang. working agreement), które opisujñ stosowane praktyki XP i róĔnice w nich wobec opisów z tej ksiñĔki. Przez kilka pierwszych miesiöcy stosowania XP zalecam jak najĈciĈlejsze trzymanie siö podanych zaleceþ. NaleĔy omówiè role poszczególnych osób i wzajemne oczekiwania. NAPRZÓD

73

Najlepiej jest prowadziè takie rozmowy w klimacie wspólnych grupowych dyskusji. Warto unikaè odgórnego przypisywania ról i wydawania poleceþ. W ostatnich tygodniach przed uruchomieniem nowego projektu XP naleĔy przejrzeè praktyki z czöĈci II. Warto wypróbowaè niektóre z nich w obecnie prowadzonym projekcie i wziñè udziaä w szkoleniach dotyczñcych tych praktyk, które sprawiajñ najwiöksze trudnoĈci. Kiedy zespóä ukoþczy przygotowania i otrzyma projekt rozwijany od podstaw, czyli wymagajñcy utworzenia caäego kodu bazowego od poczñtku, moĔe zaczynaè pracö. Warto jeszcze raz przejrzeè praktyki z czöĈci drugiej, wziñè gäöboki oddech i rozpoczñè pierwszñ iteracjö. „Chwileczkö!” — moĔe ktoĈ zawoäaè. „Czy jest jakiĈ sposób wolniejszego przechodzenia na XP?”. W zasadzie tak. MoĔna stopniowo wprowadzaè to podejĈcie, na przykäad podczas pracy nad starszymi projektami, jednak jeĈli dany projekt jest rozwijany od podstaw, äatwiej i szybciej jest od razu zastosowaè wszystkie praktyki. Wprowadzanie XP utrudniajñ chaos i niepewnoĈè w obliczu zmian, a nie same praktyki. Przy stopniowym wdraĔaniu XP kaĔda nowa praktyka zaburza równowagö, którñ zespóä stara siö osiñgnñè. Powoduje to wydäuĔenie okresu chaosu i niepewnoĈci, co znacznie utrudnia przechodzenie na XP. Wedäug moich doĈwiadczeþ zespoäy, które wprowadzajñ XP stopniowo, odnoszñ znaczne korzyĈci, jednak to grupy stosujñce od poczñtku wszystkie praktyki osiñgajñ naprawdö wyjñtkowe rezultaty. Nie trzeba siö obawiaè. W koþcu zespóä skäada siö z odpowiednich osób, ma dogodne Ĉrodowisko pracy i wolö odniesienia sukcesu. Do dzieäa!

SYNDROM DRUGIEGO UśYTKOWNIKA ZauwaŜyĥem zdum ewajécy trend wļród f rm, które wprowadzaĥy XP P erwszy zespóĥ zwyk e odnos duŜe sukcesy, co zachýca organ zacjý do zastosowan a tego podejļc a w nnych projektach, jednak czýsto w projektach rozw janych w ramach „drug ej fa ” pojaw ajé s ý spore prob emy Nazywam to zjaw sko syndromem drugiego uŜytkownika Mo m zdan em jego Śródĥem jest to, Ŝe p erwszy projekt z wykorzystan em XP toczy s ý zwyk e z peĥnym potrzebnym wsparc em Uczestn czé w n m chýtn pracown cy, organ zacja wykazuje c erp woļë, zapewn ona jest pomoc zewnýtrzna, a projekt jest wa toļc owy, a e n e ma znaczen a strateg cznego Nastýpn e organ zacja, zakĥadajéc, Ŝe pracown cy rozum ejé juŜ XP, zapewn a drug ej fa projektów mn ejsze wsparc e Uczestn czé w n ch osoby, które n e chcé stosowaë XP, pomoc zewnýt zna jest duŜo mn ejsza, a term ny — bardz ej nap ýte Aby un knéë tego syndromu, t zeba pam ýtaë, Ŝe powodzen e jednego zespoĥu n e gwarantuje sukcesów nnych grup KaŜdy zespóĥ wymaga wsparc a, k edy po raz p erwszy stosuje XP

Stosowanie XP do zupeĥnie nowych projektów (zalecane) Przy uruchamianiu caäkowicie nowego projektu z wykorzystaniem XP naleĔy oczekiwaè, Ĕe pierwsze trzy lub cztery tygodnie bödñ doĈè chaotyczne, poniewaĔ wszyscy dopiero poznajñ tö metodö. W trakcie pierwszego miesiñca przedstawiciele klientów pracujñ nad planem wydaþ, programiĈci tworzñ infrastrukturö technicznñ, a czäonkowie grupy uczñ siö wspóäpracowaè ze sobñ.

74

ROZDZ AĤ 4

WPROWADZAN E XP

UWAGA Na potrzeby przedstawianych tu analiz zakäadam, Ĕe projekt jest obciñĔony wysokim däugiem technicznym i zawiera wiele bäödów. Proponowany proces moĔna zastosowaè takĔe wtedy, kiedy sytuacja nie jest tak zäa, a praca jest wtedy duĔo äatwiejsza.

Znaczéce decyzje Najwiökszym wyzwaniem przy wprowadzaniu XP (oprócz samych zmian) jest brak testów, refaktoryzacji i uporzñdkowanej bazy danych bäödów. Najwiökszñ trudnoĈè sprawia poĈwiöcenie wystarczajñcej iloĈci czasu na späacenie däugu technicznego. W typowych odziedziczonych projektach szybkoĈè to fikcja oparta na stosowaniu sztuczek. Zespóä powiöksza däug techniczny, aby zmieĈciè siö w terminie. W celu poprawy wydajnoĈci i zmniejszenia liczby generowanych bäödów trzeba nie tylko zaprzestaè powiökszania däugu technicznego, ale takĔe uwzglödniè wiökszy zapas (zobacz podrozdziaä „Zapas” w rozdziale 8.) na späacenie zastaäych däugów. To podwójne obciñĔenie obniĔa szybkoĈè, która czasem spada w bardzo duĔym stopniu. Na szczöĈcie wraz ze späacaniem däugu technicznego szybkoĈè ponownie roĈnie, a w pewnym momencie przekracza obecne tempo pracy. MoĔe to zajñè nieco czasu. W zaleĔnoĈci od poziomu däugu technicznego i zapasu poĈwiöconego na jego späacenie, naleĔy oczekiwaè obniĔenia szybkoĈci przynajmniej przez trzy miesiñce, a czösto nawet däuĔej.

UWAGA Im wiökszy zapas zespóä poĈwiöci na späacanie däugu technicznego, tym bardziej spadnie szybkoĈè, ale jednoczeĈnie czas do jej ponownego wzrostu bödzie krótszy. Warto myĈleè o szybkoĈci jako o przepäywach pieniöĔnych: im wiöcej kapitaäu späaca däuĔnik, tym mniej pieniödzy bödzie miaä w danym tygodniu, ale tym szybciej przestanie päaciè odsetki.

Wprowadzanie zapasu to bolesna decyzja. Jednak jeĈli zespóä nie przestanie powiökszaè däugu technicznego, szybkoĈè bödzie wciñĔ spadaè, a liczba generowanych bäödów — rosnñè. W pewnym momencie koszt rozwoju nawet prostych zmian przekroczy wartoĈè, jakñ one zapewniajñ. Organizacja albo zrezygnuje wtedy z prac nad produktem, albo zdecyduje siö ponieĈè wysokie nakäady finansowe na jego przepisanie. W tym momencie menedĔer produktu moĔe temu zapobiec, podejmujñc odpowiednie decyzje. Jest to najlepsza okazja na przeksztaäcenie odziedziczonego projektu z däugiem technicznym w däugoterminowñ inwestycjö.

UWAGA MoĔna teĔ przepisaè projekt od podstaw lub poĈwiöciè kilka tygodni wyäñcznie na späacanie däugu technicznego. Choè te podejĈcia wymagajñ mniej pracy niĔ stopniowe späacanie däugu, wiñĔñ siö z pewnymi zagroĔeniami. Te rozwiñzania czösto zajmujñ wiöcej czasu, niĔ oczekiwano, a zespóä traci wtedy informacje zwrotne od udziaäowców oraz moĔliwoĈè wykorzystania pojawiajñcych siö okazji biznesowych.

NAPRZÓD

77

Wprowadzanie porzédku w chaos Pierwszym zadaniem jest nadanie projektowi struktury. W wielu odziedziczonych projektach stosowano chaotyczne podejĈcie do planowania, nawet jeĈli poczñtki byäy obiecujñce. NaleĔy rozpoczñè od wprowadzenia strukturalnych praktyk XP. Trzeba przenieĈè zespóä, wraz z klientami i testerami, do wspólnego pomieszczenia roboczego, rozpoczñè programowanie w parach, wprowadziè planowanie iteracji oraz retrospekcje, i tak dalej. NaleĔy zastosowaè: x wszystkie techniki dotyczñce „MyĈlenia” (zobacz rozdziaä 5.), x wszystkie techniki dotyczñce „Wspóäpracy” (zobacz rozdziaä 6.), x wszystkie techniki dotyczñce „Planowania” (zobacz rozdziaä 8.), x kontrolö wersji, wspóäwäasnoĈè kodu i praktykö „w peäni gotowe” (rozdziaä 7.) oraz

przeglñdy wykonywane przez klienta (zobacz podrozdziaä „Stopniowe zbieranie wymagaþ” w rozdziale 9.). Najbardziej odpowiednie mogñ byè iteracje dwu-, trzy- lub nawet czterotygodniowe. NaleĔy rozpoczñè od iteracji trwajñcych dwa tygodnie. W szczególnie niedogodnym Ĉrodowisku tworzenie opowieĈci, które sñ jednoczeĈnie krótkie i wartoĈciowe dla klientów, moĔe sprawiaè trudnoĈci (zobacz podrozdziaä „OpowieĈci” w rozdziale 8.). Warto zastanowiè siö nad wydäuĔeniem iteracji, jednak przed zrobieniem tego naleĔy porozmawiaè z mentorem (zobacz podrozdziaä „Szukanie mentora” w rozdziale 2.).

UWAGA Przy zastosowaniu tych technik omawiane podejĈcie bardzo przypomina metodö mäyna. Przydatne mogñ okazaè siö szkolenia i materiaäy z zakresu tej metody.

Najwiöksze zmiany, obok bliĔszej wspóäpracy, dotyczñ planowania. NaleĔy przeanalizowaè istniejñcy plan projektu i przeksztaäciè kaĔdñ pozycjö na kartö opowieĈci. Na razie nie jest istotne, Ĕe niektóre historie nie sñ skoncentrowane na kliencie. Kiedy zespóä przyzwyczai siö do pracy w iteracjach, klienci wraz z menedĔerem projektu powinni przystñpiè do przeglñdu opowieĈci i przeksztaäcania ich na wersje bardziej skoncentrowane na kliencie. Kiedy zespóä opanuje praktyki strukturalne, naleĔy rozpoczñè wprowadzanie praktyk technicznych.

Spĥacanie dĥugu technicznego Najwiökszy problem w odziedziczonych projektach to zwykle duĔy däug techniczny. Trzeba koniecznie wstrzymaè jego narastanie. Najpierw naleĔy przygotowaè dziesiöciominutowñ kompilacjö, a nastöpnie zapewniè ciñgäñ integracjö i wprowadziè wytwarzanie sterowane testami. W trakcie wykonywania tych zadaþ trzeba zmniejszyè istniejñcy däug techniczny, wprowadzajñc dodatkowy zapas do iteracji (zobacz podrozdziaä „Zapas” w rozdziale 8.). NaleĔy poĈwiöciè go na späacanie däugu technicznego, jak opisuje to punkt „Jak wprowadziè zapas?” (takĔe w rozdziale 8.). Na poczñtku wysiäki poĈwiöcane na porzñdkowanie mogñ wydawaè siö bezowocne, jednak z czasem zespóä zacznie dostrzegaè coraz wiöksze korzyĈci w obszarze jakoĈci i wydajnoĈci. Kiedy jakoĈè kodu siö poprawi, moĔna zaczñè wprowadzaè pozostaäe praktyki z rozdziaäów 7. i 9. 78

ROZDZ AĤ 4

WPROWADZAN E XP

Te poczñtkowe kroki umoĔliwiajñ staäe späacanie däugu technicznego przy jednoczesnym postöpie w pracach nad nowymi opowieĈciami. Kiedy liczba bäödów w nowo powstajñcym kodzie spadnie, moĔna przystñpiè do porzñdkowania zalegäych bäödów.

Porzédkowanie zalegĥoļci W standardowych zespoäach baza danych bäödów jest peäna zadaþ do wykonania, pytaþ, Ĕñdaþ funkcji i prawdziwych usterek. Klienci i testerzy powinni przejrzeè tö bazö i usunñè powtarzajñce siö wpisy oraz nieistotne pozycje. NaleĔy zamknñè Ĕñdania funkcji, przeksztaäcajñc je na opowieĈci lub anulujñc je. NaleĔy znaleĒè inny sposób na pozbycie siö zadaþ do wykonania i pytaþ. Kiedy to zostanie zrobione, jedynymi pozostaäymi pozycjami powinny byè rzeczywiste usterki.

UWAGA JeĈli uĔytkownicy zadajñ pytania za poĈrednictwem bazy danych bäödów, naleĔy rozwaĔyè pozostawienie pytaþ w tej bazie. Wymaganie od uĔytkowników, aby zaczöli korzystaè z innego mechanizmu, moĔe ich zniechöciè3.

Przy duĔym rozmiarze bazy danych bäödów wykonanie wszystkich tych zadaþ w trakcie jednej sesji moĔe okazaè siö niemoĔliwe. Wtedy naleĔy porzñdkowaè bazö w trakcie kaĔdej iteracji, podobnie jak programiĈci robiñ to z däugiem technicznym. JeĈli baza danych bäödów jest uĔywana przez udziaäowców, personel pomocniczy lub inne osoby spoza zespoäu, naleĔy znaleĒè sposób na upewnienie siö, Ĕe nowe wpisy bödñ prawidäowe. MoĔna wprowadziè nowe zasady korzystania z tej bazy, jednak prawdopodobnie najlepszym rozwiñzaniem jest codzienne przeglñdanie, porzñdkowanie i kategoryzowanie nowych wpisów.

Naprawianie waŜnych bĥýdów Kiedy baza danych z bäödami stanie siö wiarygodnym repozytorium bäödów, naleĔy w przypadku kaĔdej usterki zdecydowaè, czy naprawiaè jñ, czy jej nie naprawiaè. Prawdopodobnie decyzja ta bödzie na pewnym poziomie wymagaäa opinii menedĔera produktu. Potrzebni bödñ teĔ programiĈci do oszacowania kosztów naprawy niektórych bäödów. NaleĔy zamknñè lub odäoĔyè wszystkie bäödy, których zespóä nie bödzie naprawiaä w danym wydaniu. MoĔna wróciè do nich przy planowaniu nastöpnego wydania. W tym momencie wszystkie bäödy pozostaäe w bazie sñ przeznaczone do naprawienia. NaleĔy przeksztaäciè je na opowieĈci, poprosiè programistów o oszacowanie nakäadów pracy i wäñczyè bäödy do planu wydania.

UWAGA JeĈli bäödów jest duĔo, warto rozwaĔyè rozäoĔenie procesu ich poprawiania w czasie. Choè zwykle lepiej jest naprawiaè bäödy natychmiast, rozäoĔenie ich w czasie pozwala usprawniaè funkcje w kaĔdej iteracji, co moĔe mieè lepszy wpäyw na relacje z udziaäowcami.

3

Dziökujemy Erikowi Petersenowi za tö uwagö.

NAPRZÓD

79

Retrospekcja Czöste retrospekcje (zobacz podrozdziaä „Retrospekcje” w rozdziale 5.) to doskonaäy sposób na wprowadzenie i ulepszenie procesu. JeĈli zespóä ma uprawnienia do usprawniania stosowanego procesu, retrospekcje powinny odbywaè siö co tydzieþ lub dwa.

Dziesiýciominutowa kompilacja Szybka, automatyczna kompilacja ma duĔy wpäyw na jakoĈè pracy i umoĔliwia wprowadzanie innych usprawnieþ. Wiöcej informacji na ten temat zawiera podrozdziaä „Dziesiöciominutowa kompilacja” w rozdziale 7.

Ciégĥa integracja Ciñgäe integrowanie nie tylko zmniejsza problemy z integracjñ, ale napödza usprawnianie kompilacji i testów. Wiöcej informacji na ten temat zawiera podrozdziaä „Ciñgäa integracja” w rozdziale 7.

Wytwarzanie sterowane testami Choè wytwarzanie sterowane testami (zobacz podrozdziaä „Wytwarzanie sterowane testami” w rozdziale 9.) nie jest równie äatwe do wprowadzenia jak inne praktyki, daje bardzo duĔe moĔliwoĈci. Technika ta to podstawa do zmniejszenia liczby bäödów, przyspieszenia rozwoju, usprawnienia refaktoryzacji i ograniczenia däugu technicznego. Jej opanowanie moĔe zajñè nieco czasu, dlatego naleĔy wykazaè siö cierpliwoĈciñ.

Inne praktyki Pomocne mogñ okazaè siö teĔ inne praktyki, dlatego warto przejrzeè czöĈè II. Wiele z nich wymaga stosowania innych technik, dlatego naleĔy koniecznie zapoznaè siö z punktem „Przeciwwskazania” przy opisie kaĔdej praktyki przed jej wypróbowaniem.

Ocena zwinnoļci zespoĥu ZaäóĔmy, Ĕe zespóä stosuje XP od kilku miesiöcy. Skñd wiadomo, Ĕe robi to prawidäowo? Ostatecznñ miarñ jest sukces projektu, jednak grupa moĔe chcieè sprawdziè i oceniè takĔe poziom stosowania XP. Aby w tym pomóc, przygotowaäem zestaw pytaþ, który koncentruje siö na piöciu waĔnych aspektach programowania zwinnego. To narzödzie bada raczej efekty pracy niĔ specyficzne praktyki, dlatego moĔna uzyskaè dobry wynik nawet po dostosowaniu XP do konkretnej sytuacji. JeĈli zespóä jeszcze w ogóle nie stosuje XP, takĔe moĔe uĔyè tego zestawu do oceny obecnie uĔywanego podejĈcia. Przedstawiony zestaw pytaþ uwzglödnia typowe Ēródäa zagroĔenia. Cel to osiñgniöcie maksymalnego wyniku w kaĔdej kategorii, co jest moĔliwe dla doĈwiadczonych zespoäów stosujñcych XP. KaĔdy wynik poniĔej maksymalnego oznacza ryzyko, a jednoczeĈnie moĔliwoĈè poprawy.

OCENA ZW NNOĻC

ZESPOĤU

83

Aby uĔyè tego narzödzia, naleĔy odpowiedzieè na przedstawione poniĔej pytania i umieĈciè wyniki na pustym wykresie radarowym (rysunek 4.2). Nie naleĔy przyznawaè sobie czöĈci punktów, a jeĈli zespóä nie jest pewny odpowiedzi na pytanie, powinien wpisaè zero punktów. Wynik powinien wyglñdaè mniej wiöcej tak jak na rysunku 4.1. Liczba punktów najkrótszego promienia wyznacza zagroĔenie: x 75 punktów lub mniej: niezbödne sñ natychmiastowe usprawnienia (czerwone). x Od 75 do 96 punktów: usprawnienia sñ niezbödne (Ĕóäte). x 97, 98 lub 99 punktów: usprawnienia sñ moĔliwe (zielone). x 100 punktów: brak potrzeby usprawnieþ.

Rysunek 4.1. Przykäadowa ocena

UWAGA Liczba punktów, które moĔna uzyskaè za kaĔde pytanie, zostaäa obliczona przy uĔyciu algorytmu zapewniajñcego prawidäowñ ocenö ryzyka na podstawie äñcznego wyniku4. Prowadzi to do zróĔnicowania liczby punktów. Nie trzeba zbytnio zagäöbiaè siö w róĔnice w liczbie punktów miödzy poszczególnymi pytaniami. 4

KaĔde pytanie wiñĔe siö z zagroĔeniem na okreĈlonym poziomie. Do jego opisu säuĔñ kolory: czerwony, Ĕóäty i zielony. Zero punktów za odpowiedĒ na pytanie powoduje, Ĕe äñczny wynik nie bödzie lepszy od koloru przypisanego do danej pozycji. Pytania o liczbie punktów miödzy 25 a 75 to pytania „czerwone”, za pytania „Ĕóäte” moĔna otrzymaè od 3 do 22 punktów, a pytania za 1 lub 2 punkty sñ „zielone”. Zmiana poziomu zagroĔenia zwiñzanego z jednym pytaniem wymaga zmiany wagi pozostaäych: wszystkie czerwone pytania muszñ dawaè äñcznie 75 punktów, zielone muszñ sumowaè siö do 22 punktów, a zielone muszñ dawaè 2 punkty. JeĈli wyniki majñ byè prawidäowe, kategoria moĔe zawieraè maksymalnie 3 pytania czerwone i 7 Ĕóätych.

84

ROZDZ AĤ 4

WPROWADZAN E XP

Rysunek 4.2. Diagram do samooceny

Aby znaleĒè specyficzne dla XP rozwiñzania poszczególnych problemów, naleĔy zapoznaè siö z podrozdziaäami wymienionymi w kolumnie „Praktyki XP” w tabelach od 4.1 do 4.5.

Kwestionariusz samooceny Tabela 4.1. MyĈlenie Pytan a

Tak

Ne

Praktyk XP

Czy p og amiļci sp awdzajé caĥy kod p odukcyjny we wspóĥp acy z p zynajmniej jednym innym p og amisté?

5

0

P og amowanie w pa ach

Czy wszyscy czĥonkowie zespoĥu stale z namysĥem i ļciļle p zest zegajé uzgodnionych p aktyk?

75

0

P og amowanie w pa ach Analizy p zyczynowo skutkowe Ret ospekcje

Czy czĥonkowie zespoĥu sé ogólnie skoncent owani na p acy i zaangaŜowani w nié?

5

0

Ene giczna p aca

Czy p awie wszyscy czĥonkowie zespoĥu sé ļwiadomi postýpów na d odze do celów zespoĥu?

4

0

nfo macyjne miejsce p acy

Czy jakiekolwiek p oblemy powta zajé siý czýļciej niŜ az na kwa taĥ?

0

5

Analizy p zyczynowo skutkowe Ret ospekcje

Czy zespóĥ p zynajmniej az w miesiécu usp awnia stosowany p oces?

5

0

Ret ospekcje

OCENA ZW NNOĻC

ZESPOĤU

85

Tabela 4.2. Wspóäpraca Pytan a

Tak

Ne

Praktyk XP

Czy p og amiļci kiedykolwiek zgadujé zamiast szukaë odpowiedzi na pytania?

0

75

Zespóĥ w XP

Czy p og amiļci zwykle pot afié ozpoczéë zbie anie info macji (zamiast zgĥaszaë Ŝédanie i czekaë na eakcjý) bezpoļ ednio po wyk yciu zapot zebowania na nie?

4

0

Wspólna p aca

Czy komunikacja zwykle nie sp awia czĥonkom zespoĥu p oblemów?

4

0

Wspólna p aca Wspólny jýzyk

Czy p awie wszyscy czĥonkowie zespoĥu ufajé sobie?

4

0

Zespóĥ w XP Wspólna p aca

Czy czĥonkowie zespoĥu zwykle wiedzé nad czym p acujé pozostaĥe osoby?

1

0

K ótkie spotkania obocze

Czy zespóĥ demonst uje postýpy udziaĥowcom p zynajmniej az w miesiécu?

4

0

Demonst acja ite acji Rapo ty

Czy zespóĥ p zynajmniej az w miesiécu udostýpnia udziaĥowcom dziaĥajécé we sjý op og amowania do wyp óbowania?

1

0

Demonst acja ite acji

Czy wszyscy waŜni udziaĥowcy sé zadowoleni z postýpów zespoĥu?

3

0

Rapo ty Demonst acja ite acji ZaangaŜowanie p awdziwych klientów

Czy wszyscy waŜni udziaĥowcy wie zé Ŝe zespóĥ podoĥa ozwojowi op og amowania?

3

0

Zaufanie Rapo ty

Pytan a

Tak

Ne

Praktyk XP

Czy któ ykolwiek z p og amistów w zespole pot afi obecnie skompilowaë i p zetestowaë op og amowanie p zy uŜyciu jednego polecenia o az uzyskaë jednoznaczne info macje o powodzeniu lub po aŜce?

25

0

Dziesiýciominutowa kompilacja

Czy któ ykolwiek z p og amistów w zespole pot afi obecnie skompilowaë p zetestowane moŜliwe do instalacji wydanie p zy uŜyciu jednego polecenia?

5

0

Dziesiýciominutowa kompilacja

Czy wszyscy czĥonkowie zespoĥu uŜywajé kont oli we sji do wszystkich mate iaĥów zwiézanych z p ojektem któ e nie sé gene owane automatycznie?

25

0

Kont ola we sji

Czy któ ykolwiek z p og amistów pot afi skompilowaë i p zetestowaë op og amowanie na dowolnej stacji oboczej uŜywajéc wyĥécznie czystych plików z systemu kont oli we sji?

25

0

Kont ola we sji

Kiedy p og amista ot zymuje najnowszé we sjý kodu czy jest p awie caĥkowicie pewny Ŝe op og amowanie skompiluje siý i p zejdzie wszystkie testy?

5

0

Ciégĥa integ acja

Czy wszyscy p og amiļci p zynajmniej az dziennie integ ujé swé p acý z gĥównym kodem bazowym?

4

0

Ciégĥa integ acja

Czy kompilacja zinteg owanej we sji zajmuje obecnie mniej niŜ 10 minut?

4

0

Dziesiýciominutowa kompilacja

Czy p awie wszyscy p og amiļci fo matujé kod w ten sam sposób?

1

0

Standa dy pisania kodu

Czy p og amiļci zwykle usp awniajé kod kiedy dost zegé také moŜliwoļë niezaleŜnie od tego kto jest jego auto em?

4

0

Wspó wĥasnoļë kodu Refakto yzacja

Czy w ukoħczonej p acy zespoĥu zostaje wyk ytych mniej niŜ piýë bĥýdów na miesiéc?

1

0

B ak bĥýdów

Tabela 4.3. Udostöpnianie

86

ROZDZ AĤ 4

WPROWADZAN E XP

Tabela 4.4. Planowanie Pytan a

Tak

Ne

Praktyk XP

Czy p awie wszyscy czĥonkowie zespoĥu rozumiejé co ozwijajé dlaczego to obié i co udziaĥowcy uznajé za sukces?

25

0

Wizja

Czy wszyscy waŜni udziaĥowcy zgadzajé siý co do tego co zespóĥ ozwija dlaczego i majé wspólnie ustaloné wizjý sukcesu?

25

0

Wizja

Czy zespóĥ ma plan osiégniýcia sukcesu?

4

0

Planowanie wydaħ

Czy zespóĥ egula nie szuka nowych info macji i uŜywa ich do ulepszania planu osiégniýcia sukcesu?

2

0

Planowanie wydaħ

Czy plan zespoĥu uwzglýdnia doļwiadczenie za ówno osób zwiézanych z biznesem jak i p og amistów a p awie wszystkie osoby zgadzajé siý Ŝe ealizacja planu jest moŜliwa?

3

0

G a planistyczna

Czy p awie wszystkie elementy obocze w planie zespoĥu sé skoncent owane na kliencie zo ientowane na wyniki i niezaleŜne od poleceħ?

4

0

Opowieļci

Czy zespóĥ sp awdza postýpy z planem w ok eļlonych odstýpach czasu nie zadziej niŜ az na miesiéc i odpowiednio dostosowuje do nich plan?

4

0

te acje

Czy zespóĥ podejmuje p zed kaŜdym ok eļlonym ok esem zobowiézania dotyczéce dosta czenia ozwiézania i p awie zawsze je wypeĥnia?

4

0

te acje „W peĥni gotowe” Zapas Szacowanie

Czy czĥonkowie zespoĥu po oznaczeniu elementu oboczego w planie jako „ukoħczonego” wykonujé póŚniej nieoczekiwane dodatkowe zadania takie jak nap awianie uste ek lub dop acowywanie wydania aby dokoħczyë dany element?

0

25

„W peĥni gotowe”

Czy zespóĥ p awie zawsze udostýpnia op og amowanie zgodnie ze zobowiézaniami?

3

0

Za zédzanie yzykiem

Pytan a

Tak

Ne

Praktyk XP

Czy p og amiļci sé p awie zawsze pewni Ŝe niedawno napisany kod dziaĥa zgodnie z oczekiwaniami?

25

0

Wytwa zanie ste owane testami

Czy Ŝaden z p og amistów nie ma p oblemów z wp owadzaniem zmian w kodzie?

25

0

Wytwa zanie ste owane testami

Czy p og amiļci czýļciej niŜ az w tygodniu uczestniczé w sesji diagnostycznej t wajécej ponad 10 minut?

0

3

Wytwa zanie ste owane testami

Czy wszyscy p og amiļci zgadzajé siý Ŝe kaŜdego tygodnia kod staje siý t ochý lepszy?

25

0

Refakto yzacja Stopniowy ozwój p ojektu i a chitektu y

Czy zespóĥ w kaŜdej ite acji udostýpnia opowieļci wa toļciowe dla klienta?

3

0

te acje Stopniowy ozwój p ojektu i a chitektu y

Czy nieoczekiwane zmiany p ojektu wymagajé t udnych lub kosztownych modyfikacji w istniejécym kodzie?

0

3

P osty p ojekt

Czy p og amiļci uŜywajé dziaĥajécego kodu do zbie ania info macji o p oblemach technicznych?

1

0

Rozwiézania punktowe

Czy p og amiļci optymalizujé kod bez wczeļniejszego p zep owadzenia testów wydajnoļci?

0

3

Optymalizacja wydajnoļci

Czy p og amiļci spýdzajé ponad godziný na optymalizacji kodu bez zatwie dzenia tego p zez klientów?

0

3

Optymalizacja wydajnoļci

Tabela 4.5. Wytwarzanie

OCENA ZW NNOĻC

ZESPOĤU

87

Tabela 4.5. Wytwarzanie — ciñg dalszy Pytan a

Tak

Ne

Praktyk XP

Czy klienci wewnýt zni sé zadko zaskoczeni dziaĥaniem kodu pod koniec ite acji?

4

0

Stopniowe zbie anie wymagaħ

Czy w logice biznesowej ukoħczonych opowieļci pojawia siý wiýcej niŜ jeden bĥéd na miesiéc?

0

3

Testy klienta

Czy któ ykolwiek z czĥonków zespoĥu nie jest p zekonany o jakoļci ozwijanego op og amowania?

0

1

Testy eksplo acyjne Demonst acja ite acji ZaangaŜowanie p awdziwego klienta

88

ROZDZ AĤ 4

WPROWADZAN E XP

Czýļë II Stosowanie XP

ROZDZIAĤ 5

Myļlenie

Jaki bäñd kryje siö w poniĔszym zdaniu? Tym, czego naprawdö potrzebujemy, jest rozwijanie kodu przy uĔyciu wiökszej liczby klawiatur. To stwierdzenie menedĔera, z którym niegdyĈ pracowaäem. W pewnym sensie miaä on racjö: zespóä nigdy nie speäni oczekiwaþ klientów bez korzystania z klawiatury. Jednak to nie to stanowiäo problem. PóĒniej zdaäem sobie sprawö, Ĕe postöpy byäy blokowane w jednym wñskim gardle: przez brak dostöpnoĈci Ĉrodowiska publikacji. Wiöcej klawiatur nie daäoby poĔñdanych efektów nawet wtedy, gdyby dostöpnych byäo wiöcej programistów do ich obsäugi. GdybyĈmy wczeĈniej zdali sobie z tego sprawö, wydajnoĈè znacznie by wzrosäa. Czasem na najwiökszy wzrost wydajnoĈci pozwala przerwanie pracy i zastanowienie siö nad tym, co zespóä robi, dlaczego i czy jest to dobre podejĈcie. Praca najlepszych programistów nie polega na tym, Ĕe znajdujñ coĈ, co dziaäa, a nastöpnie stosujñ to. Takie osoby chcñ dowiedzieè siö, dlaczego coĈ dziaäa, oraz zrozumieè to, a nastöpnie usprawniè. UĔytkownicy XP nie muszñ byè ekspertami. Jednak podejĈcie to wymaga nawyku rozwaĔnego postöpowania. Ten rozdziaä opisuje piöè praktyk pomagajñcych myĈlñcym programistom osiñgaè doskonaäe wyniki. x Programowanie w parach podwaja moce umysäowe w trakcie pisania kodu i daje jednej

osobie w kaĔdej parze czas na przemyĈlenie strategicznych, däugoterminowych zagadnieþ.

x Energiczna praca opiera siö na zaäoĔeniu, Ĕe programiĈci pracujñ najlepiej i najwydajniej,

kiedy majñ duĔo energii i sñ zmotywowani. x Informacyjne miejsce pracy pomaga caäemu zespoäowi ustaliè, co dziaäa prawidäowo,

a co nie. x Analizy przyczynowo-skutkowe to przydatne narzödzie do wykrywania ukrytych przyczyn

problemów. x Retrospekcja to sposób na analizö i usprawnianie caäego procesu rozwoju.

91

MINI WPRAWKI Z „MYĻLENIA” Ce em tej wprawk jest ëw czen e rozwag Jeļ zespóĥ dop ero poznaje programowan e zw nne, moŜe uŜyë tego ëw czen a jako pomocy w zrozum en u praktyk XP, nawet jeļ grupa obecn e n e stosuje tego podejļc a Doļw adczen uŜytkown cy zw nnego podejļc a mogé przejrzeë rozdz aĥ 11 uŜyë tej wprawk do zastanow en a s ý, jak wyjļë poza praktyk omów one w tej ks éŜce Na eŜy ëw czyë tý wprawký przez póĥ godz ny kaŜdego dn a do momentu, k edy da sze wykonywan e jej p zestan e dawaë efekty Na poczétku m eszczen e s ý w term n e moŜe spraw aë prob emy Jeļ wprawka stan e s ý nudna, na eŜy zastanow ë s ý, jak wprowadz ë zm any, które jé oŜyw é Potrzebnych jest k ka kop tej ks éŜk (jeļ zespóĥ n e ma ch pod rýké, moŜna skserowaë odpow edn e praktyk na potrzeby tego ëw czen a), pap er narzýdz a do p san a Krok 1. Podz aĥ zespoĥu na zróŜn cowane pary — program sta pow n en pracowaë z k entem, k ent z testerem tak da ej KaŜdego dn a na eŜy zm en aë partnerów Krok 2. NaleŜy ograniczyë go do 15 minut. Pary wyb erajé dowo né praktyký z czýļc ks éŜk omaw ajé jeden z pon Ŝszych zestawów pytaħ Na eŜy wybraë praktyký, której Ŝadna z osób jeszcze n e omaw aĥa, nawet jeļ poprzedn ego dn a Ŝadna z n ch n e prezentowaĥa wn osków Rozmowy n e mogé trwaë dĥuŜej n Ŝ 15 m nut N c s ý n e stan e, jeļ para n e ukoħczy ëw czen a, zwĥaszcza jeļ wczeļn ej n e czytaĥa fragmentu poļw ýconego danej praktyce Zawsze moŜna zapoznaë s ý z n m póŚn ej Jeļli zespóĥ nie stosuje danej praktyki: x Jak e e ementy praktyk wydajé s ý ĥatwe? Co jest w n ej trudnego? Co wydaje s ý dz waczne ub bezsensowne? x Czym praktyka róŜn s ý od wczeļn ejszych doļw adczeħ? x Jak e warunk muszé byë speĥn one, aby moŜna byĥo zastosowaë praktyký w dokĥadn e tak ej form e, w jak ej jest op sana? Jeļli zespóĥ stosuje dané praktyký: x Które aspekty praktyk grupa wykonuje n ezgodn e z op sem w ks éŜce? Na eŜy ogran czyë s ý do obserwacj n e podawaë przyczyn x Co by s ý staĥo, gdyby grupa ļc ļ e stosowaĥa s ý do op su praktyk ? x Jak e zm any moŜna wprowadz ë, aby dow edz eë s ý czegoļ nowego o praktyce? Stosowne sé takŜe eksperymenty dowodzéce braku przydatnoļc praktyk Krok 3. NaleŜy ograniczyë go do 15 minut. Wybór trzech par, które omaw ajé wn osk Na eŜy staraë s ý wyb eraë pary w tak sposób, aby na przest zen czasu kaŜdy m aĥ moŜ woļë poprowadzen a dyskusj Poszczegó ne prezentacje t zeba ogran czyë do p ýc u m nut

92

ROZDZ AĤ 5

MYĻ EN E

Programowanie w parach Pomagamy sobie odnieĈè sukces.

Odb orcy P og amiļci ca y zespóĥ

Czy programiĈci chcñ, aby ktoĈ przez caäy dzieþ zaglñdaä im przez ramiö? Czy chcñ marnowaè póä dnia pracy, siedzñc w gäuchym milczeniu i obserwujñc, jak druga osoba pisze kod? OczywiĈcie, Ĕe nie. Nikt tego nie chce, a zwäaszcza osoby, które programujñ w parach. Programowanie w parach to jeden z pierwszych elementów zauwaĔanych w XP. Dwie osoby pracujñce przy jednej klawiaturze? To dziwaczne. Jednak jest to niezwykle skuteczne podejĈcie, a takĔe — po przyzwyczajeniu siö do niego — bardzo ciekawe. WiökszoĈè znanych mi programistów po miesiöcznej próbie programowania w parach stwierdziäa, Ĕe woli to rozwiñzanie od samodzielnej pracy.

Dlaczego pary? Ten rozdziaä nosi tytuä „MyĈlenie”, jednak jako pierwszñ praktykö opisujö programowanie w parach. Wybraäem jñ dlatego, Ĕe dotyczy przede wszystkim zwiökszania mocy umysäowych. Przy pracy w parach jedna osoba pisze kod — prowadzi. Druga osoba to pilot, którego zadaniem jest myĈlenie. Pilot czasem myĈli o tym, co pisze prowadzñcy. (Nie naleĔy jednak pochopnie wytykaè brakujñcych Ĉredników — to irytuje drugñ osobö). Czasem zastanawia siö nad nastöpnymi zadaniami lub nad tym, jak najlepiej wpasowaè wykonywane zadania w ogólny projekt. Taki ukäad umoĔliwia prowadzñcemu swobodnñ pracö nad taktycznymi wyzwaniami przy tworzeniu starannego, poprawnego skäadniowo kodu bez martwienia siö o ogólny obraz. Pilot moĔe w tym czasie zastanawiaè siö nad strategicznymi zagadnieniami bez rozpraszania uwagi na szczegóäy zwiñzane z pisaniem kodu. Prowadzñcy i pilot wspólnie tworzñ kod wyĔszej jakoĈci i w krótszym czasie niĔ kaĔdy z nich z osobna1. Praca w parach wzmacnia takĔe dobre nawyki programistyczne. Charakterystyczne dla XP poleganie na ciñgäych testach i usprawnianiu projektu wymaga duĔo samodyscypliny. W parach pojawia siö pozytywna presja wspóäpracownika na wykonywanie trudnych, ale niezbödnych zadaþ. Ponadto podejĈcie to prowadzi do rozpowszechniania w zespole wiedzy programistycznej i wskazówek. Przy programowaniu w parach programiĈci wiöcej czasu spödzajñ w stanie przepäywu, czyli w stanie wysokiej wydajnoĈci, w którym pracownicy sñ w peäni skoncentrowani na kodzie. Jest to specyficzny rodzaj przepäywu, poniewaĔ programiĈci wspóäpracujñ z partnerem, jednak jest duĔo bardziej odporny na zakäócenia. Jednym z pierwszych spostrzeĔeþ jest to, Ĕe wspóäpracownicy z pokoju duĔo rzadziej przeszkadzajñ osobom, które wspóäpracujñ z kimĈ innym. Przy takim podejĈciu jedna osoba zajmuje siö czynnikami przerywajñcymi pracö, podczas gdy druga moĔe spokojnie kontynuowaè tok myĈlenia. Ponadto kaĔdy czäonek zespoäu poĈwiöca wiöcej uwagi rozmowie z partnerem niĔ pozostaäym dĒwiökom, które rozpäywajñ siö tle.

1

W jednym z badaþ ustalono, Ĕe programowanie w parach wymaga okoäo 15% wiöcej wysiäku niĔ samodzielna praca, ale efekty sñ uzyskiwane szybciej, a liczba usterek jest niĔsza o 15% [Cockburn i Williams]. KaĔdy zespóä jest inny, dlatego naleĔy podchodziè do tych wyników z pewnym dystansem.

PROGRAMOWAN E W PARACH

93

WSKAZÓWKI DLA PRACUJèCYCH W PARACH x Na eŜy rozw jaë w parach caĥy kod, który wymaga konse wacj x Pa y pow nny two zyë s ý samodz e n e, a n e p zez odgórne p zyp sywan e pa tnerów do s eb e x Na eŜy zm en aë partnerów, k edy pot zebny jest nowy punkt w dzen a x Na eŜy un kaë pracy w pa ze z té samé osobé dĥuŜej n Ŝ p zez jeden dz eħ x Program ļc pow nn s edz eë wygodn e obok s eb e x Kod na eŜy tworzyë przez rozmowy Program ļc pow nn wspóĥpracowaë, a n e k ytykowaë x Na eŜy czýsto zm en aë ro e prowadzécego p ota

Stanowiska do pracy w parach Aby programowanie w parach sprawiaäo przyjemnoĈè, niezbödne sñ dobre stanowiska pracy. Trzeba zapewniè wystarczajñco duĔo miejsca, aby obie osoby mogäy siedzieè obok siebie. Typowe komórki, w których stacja robocza znajduje siö w rogu pomieszczenia, nie sñ dobrym rozwiñzaniem. Sñ one niewygodne, a jedna z osób musi siedzieè za drugñ, co stwarza psychologiczne i fizyczne bariery szkodzñce wspóäpracy. Dobre stanowiska do pracy w parach nie wymagajñ wymyĈlnych mebli. Najlepsze sñ proste rozkäadane stoäy, które moĔna znaleĒè w kaĔdym dobrym sklepie z meblami biurowymi. Stóä powinien mieè okoäo 1,8 metra däugoĈci, aby dwie osoby mogäy wygodnie siedzieè obok siebie, oraz przynajmniej 1,2 metra gäöbokoĈci. Na kaĔdym stole powinna znajdowaè siö wydajna stacja robocza do programowania. Lubiö podäñczaè dwie klawiatury i myszki, aby kaĔda osoba miaäa wäasny zestaw. NaleĔy zainwestowaè w duĔe monitory, aby obie osoby dobrze widziaäy zawartoĈè ekranu. W niektórych zespoäach ten sam obraz jest powielany na dwóch monitorach, co poprawia widocznoĈè, jednak moĔe siö okazaè, Ĕe programista pokazuje elementy na nieodpowiednim monitorze. Inne grupy wolñ podäñczyè dwa monitory do jednego komputera.

UWAGA

Pomysäy na rozmieszczenie stanowisk do pracy w parach zawiera podrozdziaä „Wspólna praca” w rozdziale 6.

Wyzwania Programowanie w parach moĔe poczñtkowo byè niewygodne, poniewaĔ wymaga znacznej wspóäpracy. Te odczucia sñ naturalne i zwykle mijajñ po miesiñcu lub dwóch, jednak trzeba zmierzyè siö z pewnymi wyzwaniami.

Komfort Wñtek ten wciñĔ siö powtarza: programowanie w parach nie jest przyjemne, jeĈli odbywa siö w niewygodnych warunkach. Siadajñc do pracy w parach, naleĔy dostosowaè swñ pozycjö i sprzöt pod kñtem wygody. Programista powinien uporzñdkowaè biurko i upewniè siö, Ĕe ma wystarczajñco duĔo miejsca na nogi, stopy i kolana. 96

ROZDZ AĤ 5

MYĻ EN E

Pytania Czy nie jest marnotrawstwem, Ĕe dwie osoby wykonujñ pracö jednego programisty? W programowaniu w parach partnerzy tak naprawdö nie wykonujñ pracy jednej osoby. Choè w uĔyciu jest tylko jedna klawiatura, programowanie to nie tylko pisanie kodu. Jak powiedziaä Ward Cunningham: „JeĈli siö nad tym nie zastanowisz, moĔesz sñdziè, Ĕe programowanie to tylko wpisywanie instrukcji w jözyku programowania”2. W programowaniu w parach jedna osoba pisze kod, a druga zastanawia siö nad przyszäymi zadaniami, przewiduje problemy i bmyĈla strategiö. Osoby, które oczekujñ twardych danych, mogñ zapoznaè siö z rozdziaäem o badaniach nad programowaniem w parach z ksiñĔki Williamsa [Williams]. Warto pamiötaè, Ĕe duĔa liczba zmiennych w rozwoju oprogramowania sprawia, iĔ niezwykle trudno jest przeprowadziè rozbudowane, dobrze kontrolowane badania. Czasem najlepszy sposób na sprawdzenie, czy technika nadaje siö dla zespoäu, to jej wypróbowanie. Jak moĔna przekonaè zespóä lub organizacjö do wypróbowania programowania w parach? NaleĔy zapytaè o pozwolenie wypróbowania tego podejĈcia w ramach eksperymentu. Przez miesiñc wszyscy programiĈci powinni rozwijaè caäy kod produkcyjny, pracujñc w parach. NaleĔy upewniè siö, Ĕe eksperyment bödzie trwaä przez caäy miesiñc, poniewaĔ przez pierwszych kilka tygodni programowanie w parach moĔe byè trudne i niewygodne. Nie wystarczy zapytaè o pozwolenie zarzñdu. Trzeba upewniè siö, Ĕe pozostali czäonkowie zespoäu sñ zainteresowani pracñ w parach. Jedyni znani mi programiĈci, którzy wypróbowali programowanie w parach przez miesiñc i nie polubili go, to ci zmuszeni do przetestowania tego podejĈcia. Czy naprawdö niezbödne jest programowania w parach przez caäy czas? Tö decyzjö caäy zespóä powinien podjñè wspólnie. Najpierw naleĔy przez miesiñc spróbowaè rozwijaè caäy kod produkcyjny (wszystko, co wymaga konserwacji), programujñc w parach. PrzyjemnoĈè z pracy w ten sposób moĔe przekroczyè oczekiwania zespoäu. NiezaleĔnie od podjötych decyzji, trzeba rozwijaè takĔe inny kod, który nie wymaga konserwacji. Sñ to na przykäad rozwiñzania punktowe. Przy tworzeniu takich fragmentów kodu korzystne mogñ byè indywidualne analizy. Niektóre zadania produkcyjne powtarzajñ siö w tak duĔym stopniu, Ĕe nie wymagajñ dodatkowych JeĈli programowanie w parach mocy umysäowych, jakie zapewnia praca w parach. jest nudne, warto zastanowiè siö Jednak przed zarzuceniem tego podejĈcia warto nad tym, jak zmniejszyè zastanowiè siö, dlaczego projekt wymaga tak wielu powtórzeþ. MoĔe to byè oznakñ usterek w projekcie. powtarzalnoĈè prac w projekcie. MoĔna wykorzystaè dodatkowy czas pilota na zastanowienie siö nad usprawnieniami w projekcie i rozwaĔyè omówienie tego problemu z caäym zespoäem.

2

http://wn.wikiquote.org/wiki/Ward_Cunningham

98

ROZDZ AĤ 5

MYĻ EN E

Nawet w tak komfortowych warunkach miewaäem chwile gorszego nastroju. Prawdopodobnie najwaĔniejszym pozytywnym czynnikiem byä mój partner: bardzo opanowany, äatwy we wspóäĔyciu i znoszñcy moje humory. Zostajemy pochäoniöci przez pracö i zapominamy o zmianie par. Jak moĔemy uäatwiè sobie czöstsze wymiany partnerów? Jednym z rozwiñzaþ jest pamiötanie o tym, aby tasowaè pary, kiedy programista utknie lub poczuje siö sfrustrowany. Jest to doskonaäy moment na zamianö partnerów i zyskanie nowego punktu widzenia. Niektóre zespoäy uĔywajñ stoperów i tasujñ pary w ustalonych odstöpach czasu. Belshee opisuje interesujñce skutki wymiany partnerów co 90 minut [Belshee]. Choè moĔe to byè doskonaäy sposób na wytworzenie nawyku tasowania par, naleĔy upewniè siö, Ĕe wszyscy programiĈci chcñ pracowaè w taki sposób. Jak moĔna pracowaè w parach zdalnie? Do zdalnej pracy w parach moĔna uĔyè zestawów säuchawkowych i narzödzi do wspóädzielenia pulpitu, takich jak VNC lub NetMeeting. Säyszaäem o zespoäach, które uĔywaäy odröbnych stacji roboczych i wspóädzielenia ekranu oraz aplikacji VoIP. Kiedy jednak próbowaäem tych rozwiñzaþ, byäy dla mnie tylko kiepskim substytutem rzeczywistej pracy w parach. Zespoäy stosujñce XP zwykle przebywajñ wspólnie, dlatego praca zdalna nie jest zbyt czösto potrzebna.

Efekty Przy prawidäowym programowaniu w parach programista moĔe zauwaĔyè, Ĕe mocno koncentruje siö na kodzie i wspóäpracy z partnerem. Przeszkody i czynniki rozpraszajñce stajñ siö wtedy mniej zauwaĔalne. Przy pojawieniu siö przeszkody jedna osoba zajmuje siö problemem, podczas gdy druga kontynuuje pracö. Nastöpnie moĔna bäyskawicznie wróciè do zadania. Pod koniec dnia programiĈci czujñ siö zmöczeni, ale zadowoleni. Wysoka koncentracja i bliska wspóäpraca z kolegami z zespoäu sprawia prawdziwñ przyjemnoĈè. Dla zespoäu jako caäoĈci korzyĈciñ jest kod wyĔszej jakoĈci. Däug techniczny maleje. Wiedza w zespole rozpowszechnia siö szybko, co podnosi kompetencje poszczególnych osób i pomaga bäyskawicznie wprowadziè do grupy nowych czäonków.

Przeciwwskazania Programowanie w parach wymaga wygodnego Ĉrodowiska pracy (zobacz podrozdziaä „Wspólna praca” w rozdziale 6., aby zapoznaè siö z moĔliwymi rozwiñzaniami). WiökszoĈè biur i komórek nie jest przygotowana w odpowiedni sposób. JeĈli przestrzeþ robocza nie umoĔliwia programistom wygodnego siedzenia obok siebie, naleĔy albo jñ przeksztaäciè, albo zrezygnowaè z programowania w parach. RównieĔ jeĈli zespóä nie pracuje razem, programowanie w parach jest zwykle nieodpowiednim rozwiñzaniem. Choè zdalna praca w parach jest moĔliwa, nie daje tylu korzyĈci, co przy kontakcie osobistym.

100

ROZDZ AĤ 5

MYĻ EN E

Energiczna praca Pracujemy w tempie, które pozwala nieustannie wykonywaè zadania na najwyĔszym poziomie i w wydajny sposób.

Odb orcy Coachowie caĥy zespóĥ

Programowanie sprawia mi przyjemnoĈè. Lubiö rozwiñzywaè problemy, pisaè dobry kod, obserwowaè przechodzenie testów, a zwäaszcza usuwaè kod w trakcie refaktoryzacji. Programujö w czasie wolnym, a czasem nawet myĈlö o pracy pod prysznicem. Inaczej mówiñc, uwielbiam mojñ pracö. Jednak kiedy trafiö do zespoäu o niejasno okreĈlonych celach, niskiej odpowiedzialnoĈci grupowej i skonfliktowanego, praca stanie siö udrökñ. Bödö w biurze w wyznaczonych godzinach, ale kusiè mnie bödzie spödzanie kaĔdego poranka na czytaniu poczty, a popoäudnia — na przeglñdaniu kodu na technicznych witrynach internetowych w niewielkim tylko stopniu zwiñzanych z projektem. Wszyscy programiĈci czasem znajdujñ siö w takiej sytuacji, jednak z uwagi na to, Ĕe sñ profesjonalistami, starajñ siö tworzyè kod wysokiej jakoĈci nawet wtedy, kiedy ich morale jest niskie. Warto zastanowiè siö nad okresem najwyĔszej produktywnoĈci w karierze danego programisty. Czy zauwaĔaä duĔñ róĔnicö, kiedy po przebudzeniu cieszyä siö z tego, Ĕe ma iĈè do pracy? CzyĔ nie jest duĔo bardziej przyjemne wychodzenie z pracy po oĈmiu godzinach ze ĈwiadomoĈciñ, Ĕe utworzyäo siö coĈ solidnego i uĔytecznego? Praktyka energicznej pracy opiera siö na pewnym zaäoĔeniu: choè profesjonaliĈci mogñ pracowaè dobrze nawet w trudnych warunkach, wykonujñ zadania na najwyĔszym poziomie i najwydajniej wtedy, kiedy majñ duĔo energii i sñ zmotywowani.

Jak mieë duŜo energii? Jednym z najprostszych sposobów na zapewnienie sobie energii jest dbanie o siebie. NaleĔy kaĔdego Punktualne powroty do domu. dnia punktualnie wracaè do domu. Spödzaè czas z rodzinñ i przyjacióämi oraz angaĔowaè siö w czynnoĈci, które odciñgajñ umysä od myĈlenia o pracy. NaleĔy zdrowo siö odĔywiaè, èwiczyè i spaè odpowiedniñ liczbö godzin. Kiedy czäowiek jest zajöty innymi sprawami, mózg wciñĔ przetwarza wydarzenia danego dnia. Czösto rankiem pojawiajñ siö nowe pomysäy. JeĈli wartoĈciowo spödzany wolny czas to yin energicznej pracy, koncentracja na zadaniach to yang. W trakcie pracy naleĔy poĈwiöciè jej peänñ uwagö. NaleĔy pozbyè siö przeszkód i wyäñczyè klienta pocztowego oraz komunikator. Warto wyciszyè telefon. MoĔna poprosiè menedĔera projektu o zwolnienie ze zbödnych spotkaþ i ochronö przed politycznymi rozgrywkami. Przy idealnym poäñczeniu yin i yang programista budzi siö rano wypoczöty i z radoĈciñ wita poczñtek nowego dnia. Wieczorem jest zmöczony — choè nie wykoþczony — i zadowolony z wykonanej pracy. Nie jest to proste. Energiczna praca wymaga sprzyjajñcego Ĉrodowiska w pracy i domu. Jest to takĔe wybór kaĔdej osoby: nie moĔna nikogo zmusiè, aby byä peäen energii. MoĔna jednak usunñè niektóre przeszkody.

102

ROZDZ AĤ 5

MYĻ EN E

Pracujö w nowej firmie i 40 godzin tygodniowo to za maäo. Czy mogö pracowaè däuĔej? W nowych firmach czösto panuje wysokie pobudzenie i atmosfera wspólnoty. Prowadzi to JeĈli programista rano niechötnie do wyĔszego poziomu energii, dlatego programiĈci myĈli o wyjĈciu do pracy, nieraz mogñ pracowaè däuĔej, a przy tym zachowaè oznacza to, Ĕe brakuje mu energii. koncentracjö. Jednak w nowych firmach däugie godziny pracy czösto mylone sñ z poĈwiöceniem. NaleĔy uwaĔaè, aby zaangaĔowanie nie przyèmiäo trzeĒwego osñdu. Programista musi umieè okreĈliè, kiedy jest zbyt zmöczony i jego praca przestaje przynosiè efekty. Mamy waĔny termin i nie ma innego sposobu, aby siö w nim zmieĈciè, niĔ zabraè siö do ciöĔkiej pracy. Czy na ten czas moĔemy pominñè energicznñ pracö? Sprint do linii mety moĔe podnieĈè poziom energii. Nic nie równa siö z nocnñ pracñ nad kodem, kiedy to zespóä zamawia pizzö, wszyscy ciöĔko pracujñ, wykorzystujñc wszystkie moce przerobowe, a zadanie zostaje ukoþczone dokäadnie na czas. Udany sprint scala zespóä, dajñc poczucie zwyciöstwa w obliczu przeciwnoĈci. Jest jednak pewne ale… Sprint do linii mety to jedna sprawa. Pokonywanie sprintem caäych kilometrów to coĈ zupeänie innego. Czöste nadgodziny nie rozwiñĔñ Czöste nadgodziny nie rozwiñĔñ problemów problemów z planowaniem. z planowaniem. Taki styl pracy ma negatywne skutki. DaMarco nazywa czöste nadgodziny „waĔnñ technikñ zmniejszania wydajnoĈci”. Prowadzi to do obniĔenia jakoĈci kodu, wypalenia pracowników, ich wyĔszej rotacji i niewydajnego wykorzystania czasu w godzinach pracy [DaMarco 2002, s. 64]. JeĈli zespóä pracuje w nadgodzinach przez tydzieþ (cokolwiek oznaczajñ „nadgodziny” w danej firmie), nie powinien tego robiè w nastöpnym tygodniu. Kiedy zauwaĔam, Ĕe zespóä wymaga sprintu czöĈciej niĔ raz lub dwa razy na kwartaä, zaczynam szukaè gäöbszych problemów.

Efekty Kiedy zespóä jest peäen energii, rodzi siö atmosfera zaangaĔowania i wspóäpracy. Grupa zaczyna poĈwiöcaè uwagö szczegóäom i szukaè moĔliwoĈci usprawnienia nawyków. KaĔdego tygodnia zespóä obserwuje staäe postöpy i czuje, Ĕe moĔe bez koþca utrzymywaè wysokie tempo pracy. Pracownicy ceniñ zdrowie ponad krótkoterminowe korzyĈci i czujñ, Ĕe dziaäajñ wydajnie i odnoszñ sukcesy.

Przeciwwskazania Energiczna praca to nie wymówka pozwalajñca na lenistwo. NaleĔy wzbudzaè zaufanie, uczciwie angaĔujñc siö w pracö. W niektórych organizacjach trudno o warunki do energicznej pracy. JeĈli firma ocenia zaangaĔowanie pracowników na podstawie liczby przepracowanych godzin, lepiej jest zrezygnowaè z energicznej pracy i spödzaè w organizacji wiöcej czasu. Wybór miödzy jakoĈciñ Ĕycia a karierñ to sprawa osobista, a decyzjö w tym obszarze moĔe podjñè tylko dany pracownik z pomocñ rodziny. ENERG CZNA PRACA

105

Informacyjne miejsce pracy Dobrze znamy obecny stan projektu.

Odb orcy Ca y zespóĥ

Miejsce pracy w procesie wytwarzania to odpowiednik kokpitu w samolocie. Pilot otacza siö informacjami niezbödnymi do sterowania maszynñ. Podobnie zespóä powinien umieĈciè w pomieszczeniu roboczym dane potrzebne do kierowania projektem. NaleĔy przygotowaè informacyjne miejsce pracy. Informacyjne miejsce pracy powoduje rozpowszechnianie informacji po pomieszczeniu. Kiedy pracownicy robiñ sobie przerwö, czasem chodzñ po pokoju i przeglñdajñ otaczajñce ich wiadomoĈci. Takie krótkie oderwanie myĈli od zadania moĔe doprowadziè do niespodziewanych odkryè. Informacyjne miejsce pracy umoĔliwia teĔ poznanie stanu projektu w wyniku samego chodzenia po pomieszczeniu. Przekazuje informacje o postöpach bez koniecznoĈci przerywania pracy przez czäonków zespoäu i pomaga zwiökszyè zaufanie udziaäowców.

Drobne wskazówki Istotñ informacyjnego miejsca pracy sñ informacje. Jednym z prostych Ēródeä wiadomoĈci jest ogólna Proste rozejrzenie siö po pokoju atmosfera, jaka panuje w pomieszczeniu roboczym. projektowym powinno zapewniè W prawidäowo przebiegajñcych projektach pokój informacje na temat projektu. sprawia wraĔenie peänego energii. W powietrzu unosi siö szum, przy czym nie wynika on z napiöcia, ale z aktywnoĈci. Ludzie rozmawiajñ ze sobñ, wspóäpracujñ, a czasem opowiadajñ dowcipy. Nie ma atmosfery poĈpiechu, ale panuje wraĔenie produktywnoĈci. Kiedy para potrzebuje pomocy, inne osoby to zauwaĔajñ, pomagajñ rozwiñzaè problem, a nastöpnie wracajñ do wäasnych zadaþ. Kiedy któraĈ z par sprawnie ukoþczy zadanie, wszyscy Ĉwiötujñ ten moment. W „niezdrowych” projektach panuje cisza i napiöcie. Czäonkowie zespoäu nie rozmawiajñ ze sobñ zbyt duĔo, a czasem nawet w ogóle. Nastrój jest smutny i ponury. Ludzie pracujñ wedäug zegara, odbijajñc karty, lub co gorsza obserwujñ, kto pierwszy odwaĔy siö wyjĈè. Oprócz wraĔenia, jakie sprawia pomieszczenie, sñ teĔ inne wskazówki, które przekazujñ informacje bäyskawicznie i na poziomie podĈwiadomoĈci. JeĈli symbol kompilacji nie znajduje siö przy maszynie do integracji, pobieranie kodu w tym momencie jest niewskazane. JeĈli w poäowie iteracji karteczki z ukoþczonymi zadaniami nie odpowiadajñ mniej wiöcej poäowie planu, Ĉwiadczy to o tym, Ĕe zespóä pracuje wolniej lub szybciej, niĔ oczekiwano. Informacyjne miejsce pracy umoĔliwia pracownikom komunikowanie siö ze sobñ na róĔne sposoby. Tablic nigdy za duĔo. Zwykle säuĔñ do tego liczne tablice na Ĉcianach i stosy karteczek. Grupowe szkice projektu na tablicy czösto przekazujñ pomysäy duĔo szybciej i wydajniej niĔ póägodzinna prezentacja przygotowana w programie PowerPoint. Karteczki to doskonaäe narzödzie do: przeprowadzania sesji projektowych w modelu CRC (ang. Class-Responsibility Collaboration), retrospekcji i planowania na podstawie opowieĈci uĔytkowników.

NFORMACYJNE M EJSCE PRACY

107

Diagram usprawniania procesu naleĔy utworzyè po podjöciu decyzji zespoäowej, a za jego utworzenie odpowiada caäa grupa. Kiedy zespóä zdecyduje siö na uĔycie tego narzödzia, powinien jednoczeĈnie uzgodniè, Ĕe bödzie dbaä o jego aktualizowanie. W przypadku niektórych diagramów wymaga to tylko 30 sekund na oznaczenie planszy, kiedy zmieni siö poziom badanej cechy. KaĔdy czäonek zespoäu powinien aktualizowaè wäasny poziom. Niektóre diagramy wymagajñ zbierania pewnych informacji pod koniec kaĔdego dnia. Wtedy naleĔy wspólnie zobowiñzaè jednñ osobñ do aktualizowania diagramu. Jest wiele typów diagramów usprawniania procesu. Przyjmujñ one tak wiele form jak same problemy doĈwiadczane przez zespóä. Jednak zasada ich dziaäania jest zawsze taka sama: majñ przemawiaè do wewnötrznej potrzeby doskonalenia siö. JeĈli zespóä zobaczy postöp w kierunku wspólnego celu, jego czäonkowie bödñ starali siö podnieĈè swój poziom.

UWAGA Staram siö tworzyè diagramy, na których poprawö oznacza linia idñca w górö lub zapeäniajñcy siö obszar. Jest to prosty sposób na poprawö przejrzystoĈci. Nie naleĔy jednak koniecznie stosowaè siö do tej wskazówki. WaĔniejszy jest powrót do zajöè niĔ obracanie osi, aby linia szäa do góry, a nie na dóä.

Warto zastanowiè siö nad typami problemów, jakie przytrafiajñ siö zespoäowi, oraz nad tym, jakie diagramy mogñ pomóc w ich rozwiñzaniu. Znane mi zespoäy stosujñce XP uĔywaäy diagramów miödzy innymi do usprawnienia nastöpujñcych aspektów pracy: x iloĈci pracy w parach, porównujñc czas spödzony na programowaniu w parach z czasem

poĈwiöconym na samodzielne wykonywanie zadaþ; x zmiany partnerów, rejestrujñc, ile moĔliwych par rzeczywiĈcie pracowaäo razem w trakcie

kaĔdej iteracji (rysunek 5.1);

Rysunek 5.1. Przykäadowe diagramy usprawniania procesu x wydajnoĈci kompilacji, rejestrujñc liczbö testów wykonanych na sekundö; x szybkoĈci reagowania pomocy technicznej, rejestrujñc „wiek” najdawniejszego Ĕñdania

pomocy (pierwsza wersja diagramu, która zawieraäa liczbö zalegäych Ĕñdaþ, prowadziäa do ignorowania trudnych problemów). x zbödnych przerw, rejestrujñc liczbö godzin spödzonych w trakcie kaĔdej iteracji na pracy

nad czymĈ innym niĔ opowieĈci. NFORMACYJNE M EJSCE PRACY

109

Analizy przyczynowo-skutkowe Zapobiegamy bäödom, usprawniajñc proces.

Odb orcy Ca y zespóĥ

Kiedy säyszö o powaĔnym bäödzie w projekcie, nad którym pracujö, naturalnñ reakcjñ jest zäoĈè lub frustracja. Chcö obwiniè kogoĈ za pomyäkö. Niestety, ta reakcja ignoruje rzeczywistoĈè opisanñ przez Prawo Murphy’ego. JeĈli coĈ moĔe siö nie powieĈè, na pewno tak siö stanie. Ludzie to tylko ludzie. KaĔdy popeänia bäödy — ja na pewno. Agresywne obwinianie innych moĔe spowodowaè, Ĕe pracownicy bödñ ukrywaè pomyäki lub przypisywaè je innym, jednak to nieskuteczne zachowanie na pewno nie zapobiegnie bäödom. Zamiast siö denerwowaè, przypominam sobie podstawowñ zasadö Norma Kertha: kaĔdy wykonuje swe zadania najlepiej, jak potrafi, i na ile pozwalajñ mu na to jego umiejötnoĈci i wiedza (peäny tekst podstawowej zasady znajduje siö w punkcie „Retrospekcje” w dalszej czöĈci rozdziaäu). Zamiast oskarĔaè ludzi, naleĔy zrzuciè winö na proces. Co takiego jest w sposobie pracy, Ĕe umoĔliwiäo to wystñpienie bäödu? Jak moĔna zmieniè proces, aby zapobiegaä pojawianiu siö usterek? Do tego säuĔñ analizy przyczynowo-skutkowe.

Jak wykryë podstawowé przyczyný? Klasycznym podejĈciem do analizy przyczynowo-skutkowej jest piöciokrotne zadanie pytania „dlaczego?”. PoniĔej opisana jest rzeczywista sytuacja. Problem: Kiedy zaczynamy pracö nad nowym zadaniem, mnóstwo czasu zajmuje nam doprowadzenie kodu do stanu, w którym dziaäa. Dlaczego? PoniewaĔ w kompilacji w systemie kontroli czösto znajdujñ siö bäödy. Dlaczego? PoniewaĔ programiĈci dodajñ kod bez przeprowadzenia testów. ãatwo zatrzymaè siö w tym miejscu i stwierdziè: „Aha! ZnaleĒliĈmy problem. ProgramiĈci muszñ przeprowadzaè testy przed dodaniem kodu”. Jest to prawidäowa odpowiedĒ, poniewaĔ uruchamianie testów przed dodaniem kodu to czöĈè ciñgäej integracji. Jednak jest to równieĔ fragment procesu. ProgramiĈci wiedzñ, Ĕe powinni przeprowadzaè testy, ale po prostu tego nie robiñ. NaleĔy pytaè dalej. Dlaczego programiĈci nie uruchamiajñ testów przed dodaniem kodu? PoniewaĔ czasem zajmujñ one wiöcej czasu, niĔ moĔna na nie poĈwiöciè. Dlaczego testy trwajñ tak däugo? PoniewaĔ duĔo czasu w ich trakcie zajmuje przygotowanie i usuniöcie bazy danych. Dlaczego? PoniewaĔ uĔyty projekt utrudnia testowanie logiki biznesowej bez korzystania z bazy danych. Piöciokrotne zadanie pytania „dlaczego?” daje duĔo ciekawszñ odpowiedĒ niĔ tylko: „programiĈci nie wykonujñ testów”. Pomaga to przestaè obwiniaè czäonków zespoäu i wykryè ukryty, moĔliwy do rozwiñzania problem. W tym przypadku rozwiñzanie jest oczywiste, choè nieäatwe: trzeba poprawiè projekt.

112

ROZDZ AĤ 5

MYĻ EN E

Kiedy naleĔy przeprowadziè analizy przyczynowo-skutkowe? MoĔna zastosowaè tö technikö zawsze wtedy, kiedy zespóä zauwaĔy problem — przy znalezieniu bäödu, spostrzeĔeniu pomyäki, w trakcie pilotowania lub w czasie retrospekcji. Analizy te wymagajñ tylko kilku sekund. NaleĔy zachowaè ciñgäñ czujnoĈè i nieustannie przeprowadzaè analizy przyczynowo-skutkowe. Wiemy, na czym polegajñ nasze problemy. Dlaczego mielibyĈmy siö przejmowaè analizami przyczynowo-skutkowymi? JeĈli zespóä zna ukryte przyczyny problemów i pracuje nad ich usuniöciem, przeprowadziä juĔ analizy przyczynowo-skutkowe. Jednak äatwo utknñè przy wdraĔaniu konkretnego rozwiñzania. Piöciokrotne zadanie pytania „dlaczego?” moĔe rzuciè na sprawö nowe Ĉwiatäo. Jak uniknñè obwiniania poszczególnych osób? JeĈli podstawowa przyczyna wiñĔe siö z konkretnñ osobñ, naleĔy ponownie zadaè pytanie „dlaczego?”. Dlaczego ta osoba zrobiäa to, co zrobiäa? Jak to moĔliwe, Ĕe popeäniäa bäñd? NaleĔy drñĔyè temat do momentu ustalenia sposobu na zapobieĔenie podobnym bäödom w przyszäoĈci. Warto pamiötaè, Ĕe nagany i kary zwykle nie przynoszñ pozytywnych skutków. Lepiej jest utrudniè popeänianie pomyäek niĔ oczekiwaè, Ĕe pracownicy zawsze bödñ postöpowaè bezbäödnie.

Efekty Kiedy przeprowadzanie analiz przyczynowo-skutkowych staje siö instynktowne, zespóä zaczyna ceniè raczej rozwiñzywanie problemów niĔ obwinianie. Pierwszñ reakcjö na problem powinno byè zadanie pytania o to, jak mógä on wystñpiè. Zamiast obawiaè siö problemów i staraè siö je ukrywaè, naleĔy przedstawiaè je publicznie i pracowaè nad ich rozwiñzaniem.

Przeciwwskazania Podstawowym zagroĔeniem w analizach przyczynowo-skutkowych jest to, Ĕe ostatecznie kaĔdy problem ma Ēródäo poza kontrolñ zespoäu. Nie naleĔy wykorzystywaè tego jako wymówki do rezygnacji z dziaäaþ. JeĈli podstawowa przyczyna znajduje siö poza kontrolñ zespoäu, naleĔy poprosiè o pomoc osobö z doĈwiadczeniem w koordynowaniu prac z innymi grupami (na przykäad menedĔera projektu). W miödzyczasie moĔna rozwiñzaè problemy poĈrednie. NaleĔy skoncentrowaè siö na tym, co jest pod kontrolñ grupy. Choè niewiele organizacji aktywnie zniechöca do analiz przyczynowo-skutkowych, moĔe siö okazaè, Ĕe sñ one spoäecznie nie do przyjöcia. JeĈli wysiäki osoby promujñcej to podejĈcie sñ okreĈlane jako „szkodliwe” lub „marnowanie czasu”, lepiej jest zrezygnowaè z tej techniki.

Inne moŜliwoļci Analizy przyczynowo-skutkowe moĔna zawsze przeprowadziè w zaciszu wäasnych myĈli. Prawdopodobnie doprowadzñ one do wniosku, Ĕe wiele przyczyn znajduje siö poza kontrolñ danej osoby. Warto spróbowaè przeksztaäciè frustracjö w energiö nakierowanñ na naprawienie procesów, na które ma siö wpäyw. 114

ROZDZ AĤ 5

MYĻ EN E

Retrospekcje Nieustannie poprawiamy nasze nawyki zwiñzane z pracñ.

Odb orcy Ca y zespóĥ

ēaden proces nie jest doskonaäy. KaĔdy zespóä jest wyjñtkowy, podobnie jak napotykane sytuacje, a grupy caäy czas siö zmieniajñ. Trzeba nieustannie aktualizowaè proces, aby dostosowaè go do nowych warunków. Retrospekcja to doskonaäe narzödzie, które säuĔy wäaĈnie do tego.

Rodzaje retrospekcji NajczöĈciej stosowany rodzaj retrospekcji, retrospekcja iteracji, odbywa siö na zakoþczenie kaĔdej iteracji. Oprócz retrospekcji iteracji moĔna przeprowadziè teĔ däuĔsze, bardziej rozbudowane retrospekcje w kluczowych momentach. Takie retrospekcje wydaþ, retrospekcje projektu i retrospekcje niespodzianek (przeprowadzane w momencie zmiany sytuacji przez nieoczekiwane wydarzenie) dajñ okazjö do gäöbszego przemyĈlenia doĈwiadczeþ i zebrania ich w zwiözäe wskazówki, którymi moĔna podzieliè siö z innymi dziaäami organizacji. Omawianie däuĔszych retrospekcji wykracza poza zakres tej ksiñĔki. Dziaäajñ najlepiej, kiedy przeprowadzajñ je niezaleĔne osoby, dlatego warto zaangaĔowaè w nie doĈwiadczonych moderatorów retrospekcji. Wiöksze organizacje czasem zatrudniajñ takie osoby (naleĔy najpierw zapytaè o to dziaä kadr) lub mogñ zaangaĔowaè zewnötrznego konsultanta. Dla zespoäów, które chcñ samodzielnie przeprowadziè takie retrospekcje, doskonaäymi Ēródäami informacji sñ [Derby i Larsen] oraz [Kerth].

Jak przeprowadzaë retrospekcje iteracji? JeĈli atmosfera w zespole jest dobra, retrospekcjö iteracji moĔe prowadziè dowolna osoba. Poczñtkowo najlepiej powierzyè to zadanie doĈwiadczonemu, neutralnemu moderatorowi. JeĈli retrospekcje przebiegajñ päynnie, moĔna daè szansö na ich poprowadzenie innym osobom. Wszyscy czäonkowie zespoäu powinni uczestniczyè w kaĔdej retrospekcji. Aby daè uczestnikom szansö na otwarte prezentowanie swoich opinii, nie naleĔy zapraszaè na sesje osób spoza grupy. Ja ograniczam retrospekcje, które prowadzö, do dokäadnie jednej godziny. Kilka pierwszych retrospekcji prawdopodobnie siö przeciñgnie. MoĔna wydäuĔyè je o póä godziny, jednak nie naleĔy siö obawiaè uprzejmego podsumowania sesji i przejĈcia do nastöpnego etapu. Wraz z czasem caäy zespóä zacznie funkcjonowaè lepiej, a nastöpna retrospekcja jest juĔ przecieĔ za tydzieþ. Kiedy prowadzö retrospekcjö, pamiötam o poniĔszym planie. Nie trzeba stosowaè siö do niego ĈciĈle. Wydarzenia powinny toczyè siö naturalnie.

1. Podstawowa zasada Norma Kertha. 2. Burza mózgów (30 minut). 3. Ciche kategoryzowanie (10 minut). 4. Cel retrospekcji (20 minut).

RETROSPEKCJE

115

Po przyzwyczajeniu siö do tego formatu, warto go zmieniè. Retrospekcja daje moĔliwoĈè wypróbowania nowych idei. Pozycja [Derby i Larsen] jest peäna pomysäów zwiñzanych z retrospekcjami iteracji. Retrospekcja to skuteczne narzödzie, jednak kiedy zostanie Ēle przeprowadzona, moĔe mieè negatywne skutki. Z uwagi na zwiözäoĈè pominñäem w opisie pewne istotne èwiczenia zwiökszajñce poczucie bezpieczeþstwa. Przed wypróbowaniem tej praktyki naleĔy dobrze zastanowiè siö nad przeciwwskazaniami.

Etap 1.: podstawowa zasada Frank Montagna, dowódca nowojorskiej straĔy poĔarnej, napisaä w eseju The Effective PostFire Critique: StraĔacy, jak wszyscy ludzie, popeäniajñ bäödy. Jednak kiedy straĔak pomyli siö w trakcie pracy, moĔe to zagraĔaè Ĕyciu: jego, wspóäpracowników i ludzi, którym säuĔy. Mimo to straĔacy wciñĔ bödñ popeäniaè bäödy, czasem nawet te same. KaĔdy popeänia bäödy, nawet kiedy Ĕyje na krawödzi. Retrospekcja to okazja do nauki i poprawy. Zespóä nigdy nie powinien wykorzystywaè retrospekcji do obwiniania lub atakowania poszczególnych osób. Zadaniem moderatora jest zduszenie szkodliwych zachowaþ w zalñĔku. Dlatego rozpoczynam kaĔdñ retrospekcjö od przytoczenia podstawowej zasady Norma Kertha. Zapisujö jñ na górze tablicy:

Nigdy nie naleĔy uĔywaè retrospekcji do obwiniania lub atakowania poszczególnych osób.

NiezaleĔnie od tego, co dziĈ odkryjemy, rozumiemy i szczerze wierzymy, Ĕe kaĔdy pracowaä najlepiej, jak potrafi, i na ile umoĔliwiaäy mu to jego wiedza, umiejötnoĈci i zdolnoĈci, dostöpne zasoby i sytuacja. Pytam po kolei wszystkich uczestników, czy zgadzajñ siö z podstawowñ zasadñ, i oczekujö na säowne potwierdzenie: „tak”. JeĈli nie usäyszö takiej odpowiedzi, pytam, czy dana osoba moĔe zawiesiè swój sceptycyzm choè na to jedno spotkanie. JeĈli uczestnik nie zgodzi siö na to, odwoäujö retrospekcjö.

UWAGA JeĈli ktoĈ wypowie siö jeden raz w trakcie retrospekcji, istnieje wiöksze prawdopodobieþstwo, Ĕe odezwie siö ponownie. Oczekujñc na säowne wyraĔenie zgody, moderator jednoczeĈnie zachöca do bardziej aktywnego uczestnictwa.

Etap 2.: burza mózgów JeĈli wszyscy zgodzñ siö z podstawowñ zasadñ, naleĔy wröczyè uczestnikom karteczki i oäówki, a nastöpnie zapisaè na tablicy poniĔsze nagäówki: x Przyjemne, x Frustrujñce, x Zagadkowe, x Tyle samo,

116

ROZDZ AĤ 5

MYĻ EN E

x Wiöcej, x Mniej.

NaleĔy poprosiè grupö, aby przypomniaäa sobie wydarzenia z iteracji i wygenerowaäa przy uĔyciu burzy mózgów zagadnienia pasujñce do zapisanych kategorii. Uczestnicy powinni pomyĈleè o przyjemnych, frustrujñcych i zagadkowych wydarzeniach, a takĔe zastanowiè siö, czego powinno byè wiöcej, czego mniej, a co warto zostawiè na tym samym poziomie. KaĔdy pomysä powinien zostaè zapisany na odröbnej karteczce. TakĔe moderator moĔe zapisywaè swoje pomysäy, musi jednak uwaĔaè, aby nie zdominowaè dyskusji.

UWAGA MoĔna uwzglödniè takĔe te zagadnienia, nad którymi zespóä nie ma kontroli.

Uczestnicy mogñ wygenerowaè dowolnñ liczbö pomysäów. Zwykle kaĔdy z nich wymyĈla od piöciu do dziesiöciu idei. Nie kaĔda kategoria musi zawieraè pomysäy. Nie trzeba teĔ ograniczaè liczby idei w poszczególnych grupach. Wszystkie zagadnienia sñ dozwolone: od banalnych („wiöcej ciasteczek”) po tematy tabu („frustrujñce: niewykonalne terminy”). JeĈli uczestnicy niechötnie mówiñ o tym, co naprawdö myĈlñ, warto spróbowaè anonimowego wypeäniania karteczek. NaleĔy poprosiè czäonków grupy o przeczytanie pomysäów po ich zapisaniu. Nastöpnym krokiem jest przyczepienie karteczek do tablicy pod odpowiednimi nagäówkami. JeĈli tablica magnetyczna jest niedostöpna, moĔna uĔyè karteczek samoprzylepnych zamiast zwykäych.

UWAGA NaleĔy wstrzymaè siö z grupowaniem podobnych karteczek do etapu 3. Poprawia to päynnoĈè przebiegu retrospekcji.

JeĈli uczestnicy majñ problem z rozpoczöciem pracy, naleĔy opisaè im, co wydarzyäo siö w trakcie iteracji („W Ĉrodö mieliĈmy sesjö planowania…”). To podejĈcie wymaga wiöcej czasu, ale moĔe okazaè siö skutecznym sposobem na szybkie zaktywizowanie grupy w trakcie pierwszych retrospekcji. Kiedy uczestnicy czytajñ swoje pomysäy, inne osoby wpadajñ na nowe pomysäy. Konwersacja sama siö napödza. Nie naleĔy martwiè siö zgäoszeniem tego samego pomysäu przez dwie osoby — moĔna umieĈciè je wszystkie na tablicy. Zwykle czäonkowie grupy zapisujñ przynajmniej kilkadziesiñt karteczek. W momencie, kiedy konwersacja zaczyna zanikaè, naleĔy sprawdziè czas. JeĈli zostaäo go duĔo, moĔna pozwoliè, aby cisza siö przeciñgnöäa. Czösto jedna z osób powie coĈ, z czym siö wstrzymywaäa. MoĔe to doprowadziè do nastöpnej serii pomysäów. JeĈli jednak czasu pozostaäo maäo, warto wykorzystaè przerwö do przejĈcia do nastöpnego etapu.

Etap 3.: ciche kategoryzowanie Ciche kategoryzowanie to odmiana grupowania na podstawie pokrewieþstwa, w której nikt siö nie odzywa. Jest to doskonaäy sposób na szybkie skategoryzowanie wielu pomysäów.

RETROSPEKCJE

117

Ten etap wymaga duĔo miejsca. NaleĔy poprosiè wszystkich o wstanie, podejĈcie do tablicy i przesuwanie karteczek. Obowiñzujñ przy tym trzy reguäy:

1. Powiñzane karteczki powinny znaleĒè siö blisko siebie. 2. Karteczki niepowiñzane ze sobñ naleĔy rozdzieliè. 3. Nie wolno rozmawiaè. JeĈli dwie osoby nie zgadzajñ siö co do miejsca karteczki, muszñ wypracowaè kompromis bez rozmawiania ze sobñ. To èwiczenie powinno zajñè okoäo 10 minut. Jego däugoĈè zaleĔy od wielkoĈci zespoäu. Kiedy aktywnoĈè grupy spadnie, naleĔy — podobnie jak w poprzednim kroku — sprawdziè czas i albo poczekaè na nowe pomysäy, albo przejĈè do nastöpnego zadania. Po zakoþczeniu cichego kategoryzowania na tablicy powinny znajdowaè siö wyraĒne grupy karteczek. NaleĔy poprosiè wszystkich, aby usiedli, a nastöpnie narysowaè markerem kóäko wokóä kaĔdej grupy. Nie wolno przy tym nazywaè tych grup, a jedynie je obrysowaè. JeĈli pozostaäo kilka odröbnych karteczek, naleĔy narysowaè kóäka takĔe wokóä nich. KaĔde kóäko odpowiada kategorii. Nie ma ograniczeþ co do ich liczby. Po zakreĈleniu kategorii naleĔy odczytaè kilka karteczek z kaĔdego okrögu i poprosiè zespóä o nazwanie kategorii. Nazwa nie musi byè doskonaäa, a na tym etapie nie wolno juĔ przenosiè karteczek miödzy grupami. Bödzie moĔna skategoryzowaè je inaczej w trakcie przyszäych retrospekcji. Trzeba pomóc grupie w szybkim wykonaniu tego zadania. Nazwy nie sñ specjalnie istotne, a dñĔenie do perfekcji moĔe spowodowaè przeciñgniöcie siö tego etapu. Po zakreĈleniu i nazwaniu wszystkich kategorii naleĔy wybraè drogñ gäosowania te zagadnienia, w których zespóä chce uzyskaè poprawö w czasie nastöpnej iteracji. Lubiö dawaè uczestnikom maäe magnetyczne „kropki” reprezentujñce gäosy. Dobrze sprawdzajñ siö teĔ naklejki. KaĔdej osobie naleĔy przydzieliè piöè gäosów. Uczestnicy mogñ przyznaè wszystkie punkty jednej kategorii lub rozdzieliè je miödzy róĔne grupy.

Etap 4.: cel retrospekcji Po zakoþczeniu gäosowania jedna z kategorii powinna byè zdecydowanym zwyciözcñ. JeĈli tak nie jest, nie warto marnowaè czasu na dogrywkö — wystarczy rzut monetñ lub dowolna inna prosta technika. Nastöpnie naleĔy usunñè karteczki z pozostaäych kategorii. JeĈli ktoĈ chce zachowaè karteczkö, aby popracowaè nad niñ indywidualnie, moĔe to zrobiè, jednak nie jest to konieczne. Warto pamiötaè, Ĕe za tydzieþ odbödzie siö nowa retrospekcja. WaĔne zagadnienia na pewno ponownie siö pojawiñ.

UWAGA Co majñ zrobiè osoby sfrustrowane „poraĔkñ” faworyzowanej przez nie kategorii? Poczekaè miesiñc lub dwa. JeĈli dane zagadnienie jest waĔne, wczeĈniej czy póĒniej „wygra”.

118

ROZDZ AĤ 5

MYĻ EN E

Jedna grupa osób (na przykäad testerzy) zawsze zostaje przegäosowana w trakcie retrospekcji. Czy powinniĈmy zaspokoiè takĔe ich potrzeby? Z czasem kaĔdy waĔny problem zyska odpowiedniñ uwagö. Warto stosowaè retrospekcjö przez kilka miesiöcy przed stwierdzeniem, Ĕe pewna grupa jest pokrzywdzona. W jednym ze znanych mi zespoäów kilku testerów miaäo wraĔenie, Ĕe ich problemy sñ ignorowane. Miesiñc póĒniej, po rozwiñzaniu przez grupö innych kwestii, problemy testerów znalazäy siö na czele listy wszystkich osób. JeĈli problem wraz z upäywem czasu nie rozwiñĔe siö sam — a na poczñtku trzeba wykazaè siö cierpliwoĈciñ — moĔna uĔyè wag w czasie gäosowania i przyznaè niektórym osobom wiöcej gäosów. JeĈli jest to moĔliwe bez prowokowania sporów, moĔe to byè dobry sposób na wyrównanie szans. Inne rozwiñzanie polega na wyborze przez pewnñ grupö innego, dodatkowego celu retrospekcji obok celu ogólnego. Retrospekcja zawsze siö przeciñga. Jak moĔna przyspieszyè jej przebieg? Dozwolone jest przerywanie pracy i przechodzenie do dalszych etapów. Zawsze moĔna wróciè do pominiötych kwestii za tydzieþ. JeĈli zespoäowi zbyt duĔo czasu zajmuje generowanie pomysäów w trakcie burzy mózgów lub ciche kategoryzowanie, moĔna stwierdziè: „W porzñdku, koþczy nam siö czas. Zostaäy dwie minuty na zapisanie ostatnich przemyĈleþ (lub wprowadzenie ostatecznych zmian) i przechodzimy dalej”. Jednak w trakcie pierwszego miesiñca wolö pozwoliè na przeciñgniöcie siö retrospekcji i toczenie siö jej w naturalny sposób. Pozwala to uczestnikom przyzwyczaiè siö do przebiegu retrospekcji bez zbytniego stresowania siö terminami. Retrospekcja zajmuje duĔo czasu. Czy moĔemy przeprowadzaè jñ rzadziej? To zaleĔy od tego, jak wielu usprawnieþ wymaga proces. W doĈwiadczonych zespoäach nie sñ potrzebne tak czöste retrospekcje iteracji jak w nowych grupach. Zalecam przeprowadzanie retrospekcji przynajmniej raz na dwa tygodnie. JeĈli zespóä uwaĔa, Ĕe retrospekcje nie sñ zbyt przydatne, prawdopodobnie niezbödna jest zmiana tempa pracy. Warto spróbowaè innego podejĈcia. Derby i Larsen [Derby i Larsen] przedstawiajñ wiele przydatnych pomysäów.

Efekty JeĈli zespóä prawidäowo przeprowadza retrospekcje iteracji, jego umiejötnoĈci w zakresie wytwarzania i udostöpniania oprogramowania powinny stale siö rozwijaè. Caäy zespóä staje siö bardziej spójny, a kaĔda grupa ma wiökszy szacunek do problemów nökajñcych inne osoby. Czäonkowie zespoäu szczerze i otwarcie mówiñ o sukcesach i poraĔkach oraz äatwiej przystosowujñ siö do zmian.

Przeciwwskazania Najwiökszym zagroĔeniem w retrospekcji jest to, Ĕe stanie siö w wiökszym stopniu polem do oskarĔeþ niĔ narzödziem do konstruktywnego rozwiñzywania problemów. Sprawny moderator moĔe temu zapobiec, jednak zwykle taka osoba jest niedostöpna. NaleĔy bardzo

RETROSPEKCJE

121

ostroĔnie podchodziè do retrospekcji, jeĈli w zespole znajdujñ siö osoby, które majñ tendencje do agresji, atakowania lub obwiniania innych. Opisany tu sposób prowadzenia retrospekcji wymaga, aby atmosfera w zespole byäa doĈè dobra. JeĈli jest inaczej, warto zapoznaè siö z innymi moĔliwoĈciami opisanymi w ksiñĔce Derby’ego i Larsena [Derby i Larsen] i zastanowiè siö nad zaangaĔowaniem zewnötrznego moderatora. JeĈli negatywny wpäyw ma tylko jeden czäonek zespoäu lub dwóch, a próby rozwiñzania problemu przez rozmowy z nimi nie dajñ efektów, najlepszym rozwiñzaniem moĔe byè usuniöcie ich z grupy. Antyspoäeczny wpäyw tych osób prawdopodobnie wykracza poza retrospekcjö i szkodzi pracy zespoäowej oraz wydajnoĈci.

Inne moŜliwoļci Jest wiele sposobów przeprowadzania retrospekcji. Liczne pomysäy opisujñ Derby i Larsen [Derby i Larsen]. Nie znam Ĕadnej innej techniki, która umoĔliwia usprawnienie procesu i zwiökszenie spójnoĈci zespoäu w takim stopniu jak retrospekcje. W niektórych firmach obowiñzujñ procesy stosowane w caäej organizacji. W innych odpowiedzialnoĈè za proces ponosi menedĔer projektu, kierownik techniczny lub architekt. Choè te podejĈcia mogñ prowadziè do tego, Ĕe proces bödzie poczñtkowo dobry, zwykle nie umoĔliwiajñ ciñgäego usprawniania go, a Ĕadne z tych rozwiñzaþ nie zwiöksza spójnoĈci zespoäu.

Dalsza lektura KsiñĔka Project Retrospectives [Kerth] to najlepsze Ēródäo wiedzy o retrospekcjach projektu. Derby i Larsen w ksiñĔce Agile Retrospectives [Derby i Larsen] podejmujñ wñtek tam, gdzie Kerth go koþczy [Kerth], i opisujñ techniki przeprowadzania róĔnych typów retrospekcji w zwinnych metodologiach. Esej The Effective Post-Fire Critique [Montagna] to fascynujñce spojrzenie na to, jak wyglñdajñ retrospekcje wĈród osób, od których zaleĔy Ĕycie innych.

122

ROZDZ AĤ 5

MYĻ EN E

ROZDZIAĤ 6

Wspóĥpraca

Czasem wyobraĔam sobie proces rozwoju oprogramowania jako pulsujñcñ, utkanñ ze Ĉwiatäa sieè, do której centrum päynñ wzdäuĔ nici informacje pojawiajñce siö w odlegäych punktach. Dane wödrujñ do zespoäu programistycznego, reprezentowanego przez bäyskajñce, zäoĔone skupisko wäókien, a nastöpnie wiñzka informacji trafia do jaĈniejñcego jñdra — oprogramowania — które jest zbyt oĈlepiajñce, aby móc na nie patrzeè. Moje spojrzenie jest trochö dziwaczne. Jednak w tym obrazie kryje siö prawda. Rozwój oprogramowania opiera siö na informacjach. Im skuteczniej programiĈci potrafiñ zdobyè i zrozumieè potrzebne dane, tym wydajniej bödñ pracowaè przy wytwarzaniu programu. Im lepsze informacje majñ klienci i menedĔerowie, tym sprawniej bödñ mogli zarzñdzaè harmonogramem i zapewniaè informacje zwrotne programistom. Komunikacja w rzeczywistym Ĉwiecie jest duĔo bardziej skomplikowana niĔ w mojej wizji. Nie ma jaĈniejñcych wäókien do sterylnego przekazywania informacji bezpoĈrednio z jednego mózgu do drugiego. Ludzie muszñ wspóäpracowaè ze sobñ. Muszñ zadawaè pytania, omawiaè pomysäy, a nawet polemizowaè miödzy sobñ. Ten rozdziaä opisuje osiem praktyk, które pomogñ zespoäowi i udziaäowcom w wydajnej oraz skutecznej wspóäpracy: x Zaufanie jest niezbödne do sprawnego dziaäania zespoäu. x Wspólna praca umoĔliwia szybkie i precyzyjne komunikowanie siö. x ZaangaĔowanie prawdziwych klientów pomaga zespoäowi zrozumieè to, co tworzy. x Wspólny jözyk pomaga czäonkom zespoäu zrozumieè siö nawzajem. x Krótkie spotkania robocze zapewniajñ czäonkom zespoäu potrzebne informacje. x Standardy pisania kodu zapewniajñ schemat, który umoĔliwia päynne scalanie efektów

pracy zespoäu. x Demonstracje iteracji pozwalajñ dostosowaè wysiäki zespoäu do celów udziaäowców. x Raporty pomagajñ organizacji upewniè siö, Ĕe zespóä pracuje prawidäowo.

123

MINI WPRAWKA ZE „WSPÓĤPRACY” Ce em tej wprawk jest p zyj zen e s ý p zepĥywow nformacj w projekc e Jeļ zespóĥ dop ero uczy s ý programowan a zw nnego, moŜe dz ýk n ej ep ej zrozum eë znaczen e wspóĥpracy w projekc e, nawet jeļ n e stosuje obecn e XP Doļw adczen uŜytkown cy zw nnego podejļc a pow nn zapoznaë s ý z rozdz aĥem 12 uŜyë tej wprawk jako pomocy p zy modyf kowan u procesu pod kétem usun ýc a wésk ch gardeĥ w komun kacj Na eŜy ëw czyë tý wprawký przez póĥ godz ny kaŜdego dn a do momentu, k edy da sze wykonywan e jej przestan e dawaë efekty Na poczétku zm eszczen e s ý w term n e moŜe spraw aë prob emy Jeļ wprawka stan e s ý nudna, na eŜy zastanow ë s ý, jak e zm any pomogé jé oŜyw ë Potrzebne býdé b aĥe, czerwone, Ŝóĥte z e one karteczk , pusty stóĥ ub tab ca magnetyczna na mapý przepĥywu nformacj narzýdz a do p san a d a wszystk ch Krok 1. Podz aĥ zespoĥu na zróŜn cowane pary — program sta pow n en pracowaë z k entem, k ent z testerem tak da ej KaŜdego dn a na eŜy zm en aë partnerów Krok 2. NaleŜy ograniczyë go do 10 minut. Uczestn cy w parach omaw ajé rodzaje nformacj , których pot zebujé we wĥasnej pracy ub które muszé udostýpn aë nnym osobom, aby te mogĥy wykonywaë swe zadan a Na eŜy wybraë konkretne dane, które uczestn k osob ļc e zaobse wowaĥ ub wyko zystaĥ Jeļ n e moŜna wymyļ ë n czego nowego, na eŜy wybraë jedné z stn ejécych karteczek przejļë do kroku 3 nformacje zwyk e p zepĥywajé w dwóch k erunkach Na p zykĥad w trakc e przeg édu dokonywanego p zez k enta program sta moŜe zapytaë go o to, czy oprogramowan e funkcjonuje praw dĥowo Z ko e k ent moŜe popros ë program stý, aby zademonstrowaĥ dz aĥan e programu zeba wybraë ty ko jeden k erunek Uczestn k ma za zadan e zastanow ë s ý nad wszystk m sytuacjam , w których potrzebowaĥ wybranych nformacj ub udostýpn aĥ je Jak dĥugo to trwaĥo? W przypadku potrzebnych nformacj na eŜy myļ eë w kategor ach czasu kalendarzowego od momentu okreļ en a potrzeby do chw uzyskan a danych Przy nformacjach udostýpn anych na eŜy uwzg ýdn ë ĥéczny czas potrzebny danej osob e nnym czĥonkom zespoĥu na p zygotowan e p zekazan e danych Nastýpn e na eŜy zastanow ë s ý nad standardowym czasem potrzebnym na uzyskan e okreļ onych nformacj Jeļ jest on krótszy n Ŝ 10 m nut, na eŜy wybraë zieloné ka teczký Jeļ uzyskan e danych zajmuje mn ej n Ŝ jeden dz eħ, na eŜy uŜyë ka teczk Ŝóĥtej D a nformacj , któ ych przygotowan e wymaga w ýcej n Ŝ jednego dn a, na eŜy uŜyë karteczk czerwonej Na karteczkach trzeba zap saë typ nformacj , grupý, od której uczestn k je otrzymuje ( ub której je udostýpn a), peĥn oné funkcjý czas potrzebny na przygotowan e danych Przykĥadowe karteczk p zedstaw a ysunek 6 1

Rysunek 6.1. Przykäadowe karteczki Krok 3. NaleŜy ograniczyë go do 10 minut. Uczestn cy w parach zastanaw ajé s ý na rozw ézan am , które pozwo é zespoĥow skrócië ub wyeliminowaë czas potrzebny na uzyskan e ub udostýpn en e nformacj Na eŜy wybraë jedné z moŜ woļc zap saë jé na biaĥej ka teczce Krok 4. NaleŜy ograniczyë go do 10 minut. Zespóĥ omaw a ka teczk z pomysĥam wygenerowanym przez wszystk e pary Warto zastanow ë s ý nad nastýpujécym pytan am

124

ROZDZ AĤ 6

WSPÓĤPRACA

x Gdz e wystýpujé wésk e gardĥa p zy przekazywan u nformacj ? x Które opóŚn en a sé najbardz ej szkod we w obecnym proces e? x Optyma zacja przepĥywu których nformacj jest najwaŜn ejsza w nastýpnej teracj ? x Jak e sé podstawowe przyczyny opóŚn eħ? x Co zespóĥ zrob w trakc e nastýpnej teracj , aby usprawn ë przepĥyw nformacj ? K edy wszyscy przedstaw é juŜ swoje pomysĥy, na eŜy rozĥoŜyë karteczk na sto e Ko orowe karteczk t zeba rozm eļc ë tak, aby w zua n e odzw erc ed aĥy przepĥyw nformacj Przykĥadowo, jeļ projektant nterakcj otrzymuje nformacje o uŜytkowan u od prawdz wych k entów przekazuje je zespoĥow program stów, karteczk op sujéce te procesy pow nny zna eŚë s ý obok s eb e B aĥe ka teczk na eŜy um eļc ë pod ko orowym

ZAUFAN E

125

Zaufanie

Odb orcy

Wspóäpracujemy skutecznie i bez obaw.

Caĥy zespóĥ coachowie

Kiedy grupa osób zbiera siö, aby pracowaè jako zespóä, przechodzi przez szereg faz rozwoju: „formowanie, docieranie, wytwarzanie norm i wykonanie” [Tuckman]. Zespóä potrzebuje trochö czasu, aby przejĈè przez te etapy. Jego czäonkowie mogñ robiè postöpy, mieè kryzys, sprzeczaè siö i w koþcu nawiñzaè wspóäpracö. Zespóä scala siö. WydajnoĈè roĈnie. Grupa osiñga doskonaäe wyniki. Czego wymaga uzyskanie wysokiej wydajnoĈci? Zespóä musi wspólnie wziñè odpowiedzialnoĈè za powierzone mu zadania. Czäonkowie grupy muszñ myĈleè o pozostaäych osobach „my”, a nie „oni”. JeĈli jeden czäonek zespoäu zauwaĔy, Ĕe trzeba wykonaè pewne zadanie, powinien wziñè za nie odpowiedzialnoĈè, nawet jeĈli nie jest specjalistñ z danej dziedziny. MoĔe zrobiè to sam, poprosiè kogoĈ o pomoc lub znaleĒè innñ osobö, która siö tym zajmie. Ponadto czäonkowie zespoäu muszñ na sobie polegaè i liczyè na wzajemnñ pomoc. Kiedy jedna osoba nie potrafi znaleĒè odpowiedzi na dane pytanie, nie powinna siö wahaè — naleĔy zadaè je komuĈ, kto potrafi na nie odpowiedzieè. Czasem takie krótkie pytania przeradzajñ siö w däuĔsze sesje pracy w parach. Zaufanie jest niezbödne do prawidäowego funkcjonowania zespoäu. Trzeba ufaè, Ĕe poĈwiöcenie czasu na pomaganie innym nie spowoduje, iĔ osoba udzielajñca pomocy zostanie uznana za niewydajnñ. Trzeba ufaè, Ĕe czäonek zespoäu zostanie potraktowany z szacunkiem, kiedy poprosi o pomoc lub bödzie miaä odmiennñ opiniö od innych. Ponadto organizacja musi zaufaè zespoäowi. Na poczñtku podejĈcie XP sprawia wraĔenie dziwnego i odmiennego. Grupa nie udostöpnia standardowych wskaĒników postöpu, do których menedĔerowie sñ przyzwyczajeni. Wiara w to, Ĕe zespóä odniesie sukces, takĔe wymaga zaufania. Zaufanie nie pojawia siö jak za dotkniöciem czarodziejskiej róĔdĔki, a wymaga pracy. PoniĔej opisane sñ wybrane strategie rozwoju zaufania w zespoäach stosujñcych XP.

Strategia zespoĥowa numer 1: empatia miýdzy klientem a programisté Wiele organizacji, w których pracowaäem, zmagaäo siö z nastawieniem „my kontra oni” panujñcym miödzy klientami a programistami. Klienci czösto majñ wraĔenie, Ĕe programiĈci niewystarczajñco troszczñ siö o ich potrzeby, a takĔe o terminy, których niedotrzymanie moĔe czasem kosztowaè klienta posadö. Z kolei programiĈci nieraz czujñ siö zmuszeni braè na siebie zobowiñzania, którym nie mogñ podoäaè, co ma szkodliwy wpäyw na ich zdrowie i Ĕycie osobiste. Czasem napiöcie jest tak duĔe, Ĕe kaĔda grupa zaczyna robiè to, czego obawia siö druga: programiĈci reagujñ zawyĔaniem szacunków i koncentracjñ na technicznych gadĔetach kosztem niezbödnych funkcji, a klienci ignorujñ szacunki programistów i zwiökszajñ nacisk na realizacjö planu. Czasem dzieje siö tak nawet wtedy, jeĈli miödzy obiema grupami nie ma otwartej wrogoĈci. Jest to trudna sytuacja, w której nie ma äatwych rozwiñzaþ. Odbudowa tak powaĔnie nadszarpniötego zaufania wymaga däugiego czasu. PoniewaĔ Ĕadna grupa nie moĔe zmusiè drugiej do wyciñgniöcia röki, trzeba skoncentrowaè siö na zmianie wäasnego nastawienia. UwaĔam, Ĕe tym, czego najbardziej brakuje w takiej sytuacji, jest zrozumienie stanowiska drugiej strony. ProgramiĈci powinni pamiötaè, Ĕe klienci majñ w swej firmie przeäoĔonych, 126

ROZDZ AĤ 6

WSPÓĤPRACA

Strategia zespoĥowa numer 4: ciégĥoļë zespoĥu Po zakoþczeniu projektu zespóä zwykle siö rozpada. Fantastyczne zaufanie i wysoka spójnoĈè wypracowana przez grupö zostajñ utracone. Nastöpny projekt rozpoczyna zupeänie nowy zespóä, który znów musi przejĈè przez cztery etapy budowania grupy. MoĔna uniknñè tego marnotrawstwa dziöki zachowywaniu wydajnych zespoäów. WiökszoĈè organizacji uwaĔa, Ĕe podstawowe „zasoby” firmy to ludzie. W zamian moĔna jako zasoby traktowaè zespoäy. Zamiast przypisywaè do projektów ludzi, moĔna przypisywaè zespoäy. Pracownicy powinni doäñczyè do zespoäu i pracowaè wspólnie przy kilku projektach. Niektóre grupy sñ bardziej wydajne od innych. Warto to wykorzystaè i potraktowaè najbardziej wydajne zespoäy jako Ĉrodowisko treningowe dla innych grup. NaleĔy przenosiè mäodszych pracowników miödzy zespoäami, aby mogli uczyè siö od najlepszych, a takĔe rotowaè doĈwiadczone osoby, aby kierowaäy wäasnymi zespoäami. JeĈli te zmiany nie bödñ zbyt gwaätowne, kultura zespoäu i zaufanie pozostanñ nietkniöte.

UWAGA Zapewnianie ciñgäoĈci zespoäu to zaawansowana technika. Nie dlatego, Ĕe trudno jñ stosowaè, ale z uwagi na zmiany w tradycyjnych strukturach organizacji. Choè ciñgäoĈè zespoäu jest wartoĈciowa, nie jest niezbödna do odniesienia sukcesu.

WraŜenie Znam osobö, która pracowaäa w firmie w dwóch zespoäach projektowych. Jeden z nich stosowaä XP, realizowaä zobowiñzania i regularnie dostarczaä kod. Drugi zespóä miaä powaĔne problemy: nie zmieĈciä siö w terminie i nie miaä dziaäajñcego oprogramowania do zademonstrowania. Jednak kiedy firma redukowaäa zatrudnienie, wolaäa zwolniè czäonków zespoäu stosujñcego XP niĔ osoby pracujñce w drugiej grupie! Dlaczego? Kiedy zarzñd obserwowaä zespóä z problemami, widziaä ciöĔko pracujñcych w nadgodzinach programistów i diagramy UML wiszñce na Ĉcianach. Z kolei w zespole stosujñcym XP pracownicy rozmawiali, Ĉmiali siö i wychodzili do domu o siedemnastej, a w pomieszczeniu znajdowaäy siö tylko ogólne szkice i diagramy na tablicach. MoĔe to komuĈ odpowiadaè lub nie, ale projekty nie sñ realizowane w próĔni. PodejĈcie XP moĔe wydawaè siö dziwne pracownikom organizacji, w których wczeĈniej go nie stosowano. „Czy oni naprawdö pracujñ?” — zastanawiajñ siö osoby postronne. „Panuje tam haäas i zamieszanie. Nie chcö pracowaè w taki sposób. JeĈli im siö uda, czy ja takĔe bödö musiaä stosowaè to podejĈcie?”. Na ironiö zakrawa fakt, Ĕe im wiöksze sñ sukcesy zespoäów stosujñcych XP, tym wiöksze obawy budzi to podejĈcie. Alistair Cockburn nazywa te obawy organizacyjnymi przeciwciaäami1. JeĈli nikt nie zainterweniuje, przeciwciaäa pokonajñ i rozmontujñ sprawny zespóä stosujñcy XP. Bez dobrej woli udziaäowców zespóä bödzie miaä problemy i to niezaleĔnie od skutecznoĈci w realizacji technicznych zobowiñzaþ. OczywiĈcie, wykonywanie prac w terminie i zaspokajanie technicznych oczekiwaþ pomagajñ w budowaniu zaufania, ale równie istotne mogñ tu byè zdolnoĈci pozatechniczne (interpersonalne), czyli umiejötnoĈci miökkie. 1

Informacje osobiste.

128

ROZDZ AĤ 6

WSPÓĤPRACA

Po wykryciu problemu naleĔy poinformowaè o nim udziaäowców. Doceniñ oni profesjonalizm zespoäu nawet wtedy, jeĈli problem im siö nie spodoba. Ja zwykle odkäadam omówienie samodzielnie rozwiñzanych problemów do czasu demonstracji iteracji, jednak natychmiast przedstawiam Im wiökszy problem, tym udziaäowcom wiöksze käopoty. Prawdopodobnie szybciej naleĔy go ujawniè. najlepszñ osobñ do podjöcia decyzji, z kim i kiedy naleĔy porozmawiaè, jest menedĔer produktu. Im szybciej udziaäowcy dowiedzñ siö o problemie (a kiedyĈ na pewno siö dowiedzñ), tym wiöcej czasu sami bödñ mieli na jego uwzglödnienie. Zwykle przedstawiam teĔ analizy moĔliwych rozwiñzaþ i ich techniczne koszty. Przeprowadzenie takiej rozmowy wymaga duĔo odwagi, jednak nic nie buduje zaufania lepiej niĔ udane rozwiñzanie problemu. NaleĔy jednak zachowaè ostroĔnoĈè. ãatwo jest zbytnio skoncentrowaè siö na realizacji zobowiñzaþ w sposób, który w rzeczywistoĈci negatywnie wpäywa na zaufanie. Czasem zespóä potrzebuje kilku godzin wiöcej pod koniec iteracji, aby ukoþczyè szczególnie wartoĈciowñ opowieĈè. Sporadyczna praca w nadgodzinach jest dopuszczalna. Sprint z däuĔszymi nadgodzinami moĔe w odpowiednich warunkach korzystnie wpäynñè na morale i spójnoĈè zespoäu (zobacz podrozdziaä „Energiczna praca” w rozdziale 5.). Jednak opieranie siö na nadgodzinach przy realizacji zobowiñzaþ pozbawia zespóä energii i zmniejsza zdolnoĈè do absorbowania problemów. Co ciekawe, prowadzi to do czöstszego niedopeänienia zobowiñzaþ. Zespóä poĈrednio obiecuje udziaäowcom wiöcej, niĔ moĔe dostarczyè w okreĈlonym czasie i przy dostöpnych zasobach. JeĈli zespóä czösto pracuje w nadgodzinach, Ĉwiadczy Ciñgäe nadgodziny to oznaka to o problemie. WiökszoĈè iteracji powinna przebiegaè problemów systemowych. päynnie. JeĈli pojawiñ siö käopoty, zwykle moĔna je rozwiñzaè, wykorzystujñc zapas, a nie nadgodziny. JeĈli czöĈciej niĔ raz na kwartaä nadgodziny stanowiñ wiöcej niĔ 10% däugoĈci iteracji, zaczynam szukaè problemów systemowych.

Strategia organizacyjna numer 4: szanowanie celów klientów Po utworzeniu siö zespoäu stosujñcego XP musi zwykle upäynñè trochö czasu do jego scalenia. Na poczñtku programiĈci, testerzy i klienci czösto postrzegajñ siö jako odröbne grupy. Szczególnie zestresowani sñ nowi przedstawiciele klientów. Bycie czäonkiem zespoäu programistycznego jest dla nich czymĈ niecodziennym. Zwykle woleliby pracowaè w swoim biurze ze znanymi wspóäpracownikami, którymi czösto sñ wpäywowi pracownicy firmy. JeĈli klienci sñ niezadowoleni, ich odczucia trafiajñ bezpoĈrednio do udziaäowców. Przy uruchamianiu nowego projektu opartego na XP programiĈci powinni doäoĔyè szczególnych staraþ, aby dobrze przyjñè klientów. Jednñ ze szczególnie skutecznych metod jest traktowania celów klientów z szacunkiem. MoĔe to nawet wymagaè powstrzymania siö na pewien czas od cynicznych Ĕartów na temat terminów i garniturów. Szacunek powinien byè obustronny, a klienci takĔe powinni ograniczyè naturalnñ skäonnoĈè do narzekaþ na harmonogram i spierania siö o szacunki. PodkreĈlam tu rolö programistów, poniewaĔ majñ oni bardzo duĔy wpäyw na postrzeganie zespoäu przez udziaäowców.

ZAUFAN E

131

Inny sposób na powaĔne podejĈcie do celów klientów polega na wymyĈlaniu róĔnych moĔliwoĈci ich realizacji. JeĈli klienci oczekujñ rozwiñzania, którego przygotowanie wymaga duĔo czasu i wiñĔe siö z bardzo wysokim ryzykiem technicznym, warto zaproponowaè inne moĔliwoĈci osiñgniöcia podobnych skutków niĔszym kosztem. JeĈli istnieje bardziej efektowny sposób realizacji celów, którego klienci nie uwzglödnili, warto o nim wspomnieè, zwäaszcza jeĈli nie jest zbyt skomplikowany. W trakcie podobnych rozmów miödzy programistami a klientami bariery zniknñ, a rozwinie siö zaufanie. Kiedy udziaäowcy to spostrzegñ, takĔe nabiorñ wiary w moĔliwoĈci zespoäu. MoĔna teĔ budowaè zaufanie w trakcie bezpoĈrednich kontaktów z udziaäowcami. Co siö stanie, jeĈli udziaäowiec zatrzyma programistö w korytarzu i zleci mu zadanie, a ten natychmiast i z radoĈciñ zaprowadzi udziaäowca do stosu karteczek, pomoĔe mu napisaè opowieĈè, a nastöpnie poprosi menedĔera produktu o chwilö uwagi i umieszczenie opowieĈci w harmonogramie? MoĔe to oznaczaè dla programisty dziesiöciominutowñ przerwö w pracy, jednak moĔna wyobraziè sobie wraĔenia udziaäowca. Programista zareagowaä na jego uwagi, pomógä mu je wyraziè, a nastöpnie natychmiast podjñä dziaäania, aby uwzglödniè je w planie. Takie postöpowanie jest duĔo bardziej wartoĈciowe niĔ przesäanie listu elektronicznego w czarnñ dziurö systemu zarzñdzania wymaganiami.

Strategia organizacyjna numer 5: promocja zespoĥu MoĔna takĔe zadbaè o promocjö zespoäu w bardziej bezpoĈredni sposób. Jedna ze znanych mi grup przyczepiaäa na zewnötrznej Ĉcianie przestrzeni roboczej rysunki i diagramy pokazujñce, czym zespóä siö zajmuje i jak postöpujñ prace. Inna zapraszaäa wszystkich pracowników firmy na demonstracje iteracji. Otwarte informowanie o wäasnych poczynaniach pomaga innym osobom doceniè zespóä. Pozostali pracownicy organizacji sñ czösto ciekawi i nieco siö obawiajñ nowego dziwnego podejĈcia do rozwoju oprogramowania. Ta ciekawoĈè moĔe äatwo przeksztaäciè siö w niechöè, jeĈli zespóä izoluje siö lub wywyĔsza. MoĔna byè otwartym na wiele sposobów. Warto zastanowiè siö nad opisywaniem procesu w trakcie przerwy Ĉniadaniowej, publicznym „Ĉwiötem pisania kodu” poäñczonym z demonstracjñ kodu i technicznych praktyk XP lub „dniem otwartym XP”, kiedy to zespóä zaprasza wszystkich do zobaczenia, jak pracuje, a nawet pozwala uczestniczyè przez chwilö w wykonywaniu niektórych zadaþ. JeĈli grupa lubi byè w centrum uwagi, moĔe nosiè w biurze odznaki lub czapeczki z napisem „Zapytaj mnie o XP”.

Strategia organizacyjna numer 6: uczciwoļë Przy entuzjastycznym demonstrowaniu postöpów naleĔy uwaĔaè, aby nie przekroczyè pewnej linii. Zachowania z pogranicza obejmujñ ukrywanie znanych usterek w trakcie demonstracji iteracji, zbieranie pochwaä za opowieĈci, które jeszcze nie sñ caäkowicie ukoþczone, lub przeciñganie iteracji o kilka dni, aby zakoþczyè wszystkie zaplanowane zadania. To prawda, te oszustwa sñ bardzo niewielkie. Niektórzy mogñ nawet uwaĔaè, Ĕe säowo „oszustwo” jest tu zbyt mocne. Jednak wszystkie wymienione zachowania wywoäujñ u udziaäowców wraĔenie, Ĕe zespóä zrobiä wiöcej niĔ w rzeczywistoĈci.

132

ROZDZ AĤ 6

WSPÓĤPRACA

Mog ļmy utrac ë k enta nawet wtedy, gdybyļmy pow edz e mu prawdý N e moŜna tego stw erdz ë Jednak wedĥug mo ch doļw adczeħ k enc , udz aĥowcy dyrektorzy wykonawczy docen ajé wĥéczan e ch w proces rozwoju K edy zespóĥ kaŜdego tygodn a demonstruje postýpy, rodz s ý w arygodnoļë zaufan e Dz ýk n m udz aĥowcy sé bardz ej za nteresowan wspóĥpracé z zespoĥem przy uwzg ýdn an u kosztów zysków oraz rea zacj swych ce ów N gdy w ýcej n e zam e zam ukrywaë nformacj Harmonogramy n e dochowujé sekretów N e ma cudownych zwrotów akcj Prawdz wa data dostarczen a produktu zawsze w koħcu wyjdz e na jaw Zam ast tego staram s ý przedstaw aë sytuacjý najdokĥadn ej, jak to moŜ we Jeļ bĥéd wymaga napraw en a w danym wydan u, p anujý wprowadzan e poprawk przed rozpoczýc em pracy nad nowym funkcjam Jeļ szybkoļë jest n Ŝsza od oczek wanej, m mo to przedstaw am daty wydan a oparte na uzyskanej szybkoļc aka jest rzeczyw stoļë, a ty ko szczere nformowan e o n ej pozwa a skuteczn e za zédzaë skutkam

Pytania Wyglñda na to, Ĕe nasz zespóä zatrzymaä siö w rozwoju na etapie „docierania”. Jak moĔemy przejĈè na wyĔszy poziom? NaleĔy trochö poczekaè. Zespoäy nie zawsze przechodzñ przez etapy rozwoju w uporzñdkowany sposób. Jednego dnia wszystko moĔe dziaäaè doskonale, a nastöpnego — fatalnie. Etap docierania jest niezbödny do przejĈcia zespoäu na wyĔszy poziom. Czäonkowie grupy muszñ nauczyè siö, jak wyraĔaè odmienne opinie. MoĔna im pomóc, informujñc, Ĕe brak zgody to normalne i dopuszczalne zjawisko. Warto znaleĒè sposoby na bezpieczne wyraĔanie odmiennego zdania. JeĈli zespóä nie robi Ĕadnych postöpów przez miesiñc lub dwa, naleĔy poprosiè o pomoc i porozmawiaè z mentorem (zobacz podrozdziaä „Szukanie mentora” w rozdziale 2.) lub ekspertem z dziedziny rozwoju organizacji. MoĔliwe, Ĕe taka osoba pracuje w dziale kadr. MoĔna teĔ zatrudniè zewnötrznego konsultanta. JeĈli jeden z pracowników ma wyjñtkowo negatywny wpäyw na grupö, warto zastanowiè siö, czy zespóä nie bödzie dziaäaä lepiej, jeĈli dana osoba zostanie oddelegowana do pracy nad innym projektem. Czy nie jest waĔniejsze, abyĈmy dobrze pracowali, niĔ dobrze siö prezentowali? Obie rzeczy sñ istotne. NaleĔy wykonywaè dobrñ robotö, a przy tym mieè pewnoĈè, Ĕe waĔne osoby w organizacji zdajñ sobie z tego sprawö. MyĈlaäem, Ĕe nadgodziny nie rozwiñzujñ problemów z harmonogramem. Dlaczego zalecasz pracö w nadgodzinach? Nadgodziny nie rozwiñzujñ problemów z harmonogramem, zwäaszcza systemowych, jednak mogñ pomóc, jeĈli zespóä musi poradziè sobie z drobnñ bolñczkñ. NajwaĔniejsze, aby zapamiötaè, Ĕe choè nadgodziny pozwalajñ rozwiñzaè niewielki problem, nie moĔe to byè pierwsze ani jedyne narzödzie uĔywane przez zespóä. Dlaczego naleĔy przedstawiaè udziaäowcom duĔe problemy przed mniejszymi, juĔ rozwiñzanymi usterkami? Czy nie lepiej odwróciè tö kolejnoĈè? Wraz z czasem problemy zwykle stajñ siö bardziej powaĔne. Im szybciej zespóä ujawni käopoty, tym wiöcej czasu bödzie miaä na pozbycie siö ich. Zalecane postöpowanie zapobiega teĔ panice, poniewaĔ na poczñtku projektu pracownicy sñ mniej zestresowani terminami i majñ wiöcej energii na rozwiñzywanie problemów.

134

ROZDZ AĤ 6

WSPÓĤPRACA

StwierdziäeĈ, Ĕe programiĈci powinni zachowaè Ĕarty na temat terminów dla siebie. Czy chciaäeĈ przez to powiedzieè, Ĕe programiĈci powinni milczeè i staraè siö realizowaè harmonogram nawet wtedy, jeĈli jest niewykonalny? W Ĕadnym razie. Wszystkie osoby w zespole majñ prawo gäosu i powinny szczerze mówiè o problemach, jakie dostrzegajñ. Jednak jest duĔa róĔnica miödzy omawianiem prawdziwych problemów a cynicznymi wypowiedziami. Wielu programistów ma skäonnoĈci do cynizmu. Nie jest to nic zäego, jednak trzeba pamiötaè, Ĕe od sukcesu projektu czösto zaleĔy kariera klienta. MoĔliwe, Ĕe nie bödzie on potrafiä odróĔniè prawdziwego dowcipu od skargi przedstawionej w formie Ĕartu. Nieodpowiedni dowcip moĔe zdenerwowaè klienta w takim samym stopniu jak rzeczywisty problem. Dawanie upustu frustracji jest niewydajne, jeĈli istniejñ lepsze sposoby na przedstawienie sedna problemu. Co zrobiè, jeĈli zespóä podejmie siö ukoþczenia opowieĈci, a nastöpnie zauwaĔy, Ĕe prawdopodobnie nie skoþczy jej w trakcie bieĔñcej iteracji? Pomyäki sñ nieuniknione. MoĔe programiĈci nie docenili technicznych trudnoĈci zwiñzanych z opowieĈciñ? MoĔe to klienci zapomnieli wspomnieè o waĔnym aspekcie historii? W obu przypadkach najlepsze rozwiñzanie to wczesne wykrycie problemu i zmiana planów. JeĈli jest to niemoĔliwe, naleĔy przyznaè siö do bäödu i przygotowaè lepszy plan na potrzeby nastöpnej iteracji. Wiöcej informacji o modyfikowaniu planów w odpowiedzi na niepowodzenia zawiera podrozdziaä „Planowanie iteracji” w rozdziale 8. Zmiany planów, podobnie jak nadgodziny, nie powinny zdarzaè siö zbyt czösto. JeĈli sñ one niezbödne czöĈciej niĔ raz na kwartaä, zaczynam szukaè problemów systemowych.

Efekty Kiedy osobom wchodzñcym w skäad zespoäu dobrze siö ze sobñ pracuje, wspólnie dñĔñ do osiñgniöcia celów i rozwiñzania problemów. Wspólnie decydujñ o priorytetach i rozdzielajñ zadania. W biurze panuje nastrój aktywnoĈci, a jednoczeĈnie rozluĒnienia, a pracownicy odczuwajñ prawdziwñ przyjemnoĈè ze wspóäpracy z innymi czäonkami zespoäu. Wzbudzanie zaufania w organizacji i u udziaäowców wiñĔe siö z pokazywaniem wartoĈci projektu i zespoäu. Trzeba przyznawaè siö do pomyäek, trudnoĈci i problemów oraz szukaè rozwiñzaþ, zamiast próbowaè ukrywaè käopoty do momentu, kiedy wyjdñ na jaw ze zdwojonñ siäñ. NaleĔy poszukiwaè rozwiñzaþ zamiast obwiniaè.

Przeciwwskazania Metody ustalania wynagrodzenia mogñ powaĔnie utrudniè pracö zespoäowñ. Grupy stosujñce XP osiñgajñ dobre wyniki wäaĈnie dziöki pracy zespoäowej. JeĈli ocena pracowników w organizacji opiera siö na indywidualnym przypisywaniu zadaþ, moĔe to szkodziè pracy grupowej. TakĔe ocena pracowników wedäug krzywej rozkäadu, kiedy to dokonania najsäabszego czäonka zespoäu sñ oceniane jako niezadowalajñce niezaleĔnie od jego wydajnoĈci, ma negatywny wpäyw na pracö w grupie. Te metody mogñ przeksztaäciè zespóä w grupö wspóäzawodniczñcych miödzy sobñ jednostek, co utrudnia stosowanie XP.

ZAUFAN E

135

Wspólna praca Komunikujemy siö szybko i precyzyjnie.

Odb orcy Ca y zespóĥ coachowie

Osoby, które uczestniczyäy w spotkaniach zespoäowych prowadzonych przez telefon, wiedzñ, jak znacznie róĔni siö to od rozmów twarzñ w twarz. W porównaniu z bezpoĈrednimi dyskusjami telekonferencje sñ powolne i peäne zakäóceþ. W konwersacji majñ miejsce przerwy, a czasem kilku uczestników zaczyna mówiè jednoczeĈnie. Jednak wiele osób nie zdaje sobie sprawy, jak znaczny wpäyw ma to na pracö. WyobraĒmy sobie programistö w zwykäym (niezwinnym) zespole, który musi wyjaĈniè pewne szczegóäy w wymaganiach, aby móc ukoþczyè algorytm. Wysyäa list elektroniczny do eksperta z dziedziny, Marii, a nastöpnie robi sobie przerwö na wyprostowanie nóg i napicie siö kawy. Kiedy wraca, odpowiedzi od Marii wciñĔ nie ma, dlatego przeglñda techniczne blogi, które i tak chciaä przeczytaè. Póä godziny póĒniej skrzynka odbiorcza daje sygnaä nadejĈcia wiadomoĈci — to odpowiedĒ od Marii. No cóĔ, wyglñda na to, Ĕe Maria nie zrozumiaäa listu i udzieliäa odpowiedzi na inne pytanie. Programista wysyäa nowy list, jednak nie moĔe juĔ däuĔej czekaè i po prostu zgaduje. W koþcu pracuje w firmie od dawna i zna wiökszoĈè odpowiedzi. Nastöpnie wraca do pracy. Dzieþ póĒniej, po wymianie kilku nastöpnych listów, programista uzyskuje od Marii prawidäowñ odpowiedĒ. RóĔni siö ona nieco od jego zaäoĔeþ, ale jest do nich zbliĔona. Programista cofa siö i poprawia kod. W tym momencie zauwaĔa warunek brzegowy, o którego obsäugö jak dotñd nikt nie zadbaä. Programista moĔe poprosiè Mariö o odpowiedĒ, jednak znaleziony przypadek jest bardzo dziwny. Prawdopodobnie nigdy nie wystñpi w praktyce. Poza tym Maria jest bardzo zajöta, a programista obiecaä ukoþczenie tej funkcji na poprzedni dzieþ. Tak naprawdö skoþczyä jñ tego dnia — do ukoþczenia zostaäo tylko kilka drobnych szczegóäów. Z uwagi na brak czasu programista zakäada najbardziej prawdopodobnñ odpowiedĒ i zabiera siö do pracy.

Radzenie sobie z nieskuteczné komunikacjé Kiedy odlegäoĈè miödzy dwiema osobami roĈnie, skutecznoĈè komunikacji miödzy nimi maleje. Zdarzajñ siö nieporozumienia i pojawiajñ siö bäödy. Pracownicy zaczynajñ zgadywaè odpowiedzi, aby uniknñè utrudnieþ zwiñzanych z oczekiwaniem na nie. Zaczynajñ zdarzaè siö pomyäki. Aby poradziè sobie z tym problemem, w wiökszoĈci metod rozwoju oprogramowania ograniczono potrzebö bezpoĈredniej komunikacji. To rozsñdna reakcja. JeĈli pytania prowadzñ do opóĒnieþ i bäödów, naleĔy zredukowaè koniecznoĈè ich zadawania. Podstawowym narzödziem uĔywanym do ograniczenia zaleĔnoĈci od bezpoĈredniej komunikacji sñ etapy rozwoju i dokumentacja obecnie prowadzonych prac. Na przykäad na etapie zbierania wymagaþ analitycy biznesowi rozmawiajñ z klientami, a nastöpnie przygotowujñ dokumentacjö wymagaþ. JeĈli póĒniej programista bödzie miaä wñtpliwoĈci, nie bödzie musiaä rozmawiaè z klientem — wystarczy, Ĕe poszuka odpowiedzi w dokumentacji.

WSPÓ NA PRACA

137

Jest to sensowny pomysä, ale ma pewne wady. Autorzy dokumentacji muszñ przewidzieè, jakie pytania siö pojawiñ, oraz pisaè na tyle jednoznacznie, aby uniknñè bäödnej interpretacji. Nie jest to äatwe. W praktyce niemoĔliwe jest przewidzenie wszystkich pytaþ. Ponadto dodanie wstöpnych faz rozwoju dokumentacji wydäuĔa proces rozwoju.

Lepszy sposób W XP caäy zespóä — razem z ekspertami z obszaru biznesu, projektowania, programowania i testów — pracuje wspólnie w otwartym pomieszczeniu roboczym. Kiedy jedna z osób ma pytanie, wystarczy, Ĕe obróci gäowö i je zada. Otrzyma wtedy natychmiastowñ odpowiedĒ, a jeĈli coĈ jest niejasne, moĔna omówiè to przy tablicy. Spójrzmy na wczeĈniej opisanñ historiö z nowej perspektywy. Programista potrzebuje do ukoþczenia algorytmu pewnych informacji od eksperta z dziedziny, Marii. Tym razem, zamiast przesyäaè list elektroniczny, obraca gäowö i pyta: „Mario, czy moĔesz mi coĈ wyjaĈniè?”. Maria odpowiada — „Pewnie. O co chodzi?”. Programista wyjaĈnia problem, a Maria udziela odpowiedzi. „Nie, nie” — wtrñca siö programista. „Chodzi mi o inny problem. ChodĒ, wyjaĈniö to na tablicy”. Po kilku minutach udaje siö rozwiñzaè problem, a programista moĔe wróciè do pracy. Ups! Programista zauwaĔa warunek brzegowy, którego nie rozwaĔyä. „Mario, poczekaj chwileczkö” — mówi. „Jest coĈ, czego nie zauwaĔyliĈmy. Co zrobiè z…”. Po dalszej dyskusji wszystko jest jasne. Programista jest zaskoczony, poniewaĔ odpowiedĒ Marii znacznie róĔniäa siö od jego przypuszczeþ. Dobrze, Ĕe poprosiä jñ o rozmowö. Teraz pora wracaè do pracy. Kod musi byè gotowy na dzisiaj, a wyjaĈnienie kilku drobiazgów zajöäo caäe 20 minut.

Wykorzystywanie doskonaĥej komunikacji Wspólna praca eliminuje straty zwiñzane z oczekiwaniem na odpowiedĒ, co prowadzi do wyraĒnego wzrostu wydajnoĈci. W badaniach polowych nad szeĈcioma wspólnie pracujñcymi zespoäami [Teasley i inni] odkryto, Ĕe wspólne przebywanie powoduje dwukrotny wzrost wydajnoĈci i skraca czas wprowadzenia produktu na rynek do okoäo 1/3 typowego okresu udostöpniania rozwiñzania przez firmö. Warto powtórzyè te wyniki: zespoäy udostöpniaäy oprogramowanie po upäywie 1/3 typowego terminu. Po badaniach pilotaĔowych 11 nastöpnych zespoäów osiñgnöäo podobne wyniki. Ten sukces spowodowaä, Ĕe firma zainwestowaäa duĔe kwoty w otwarte pomieszczenia robocze i zbudowaäa w Stanach Zjednoczonych nowñ siedzibö, w której moĔe pracowaè 112 zespoäów. Organizacja planuje uruchomienie podobnych jednostek w Europie. Jak wspólna praca moĔe doprowadziè do tak wyjñtkowych wyników? Dziöki komunikacji. Choè programowanie to gäówna czynnoĈè w rozwoju oprogramowania, prawdziwym kluczem do rozwoju udanych programów jest komunikacja. Jak donosi Teasley: „WczeĈniejsze badania wskazujñ, Ĕe programiĈci poĈwiöcajñ tradycyjnym zadaniom zwiñzanym z programowaniem poniĔej 30% czasu, a samo pisanie kodu zajmuje im mniej niĔ 20%. Pozostaäy czas spödzajñ 138

ROZDZ AĤ 6

WSPÓĤPRACA

na spotkaniach, rozwiñzywaniu problemów wraz z zespoäem, omawianiu róĔnych zagadnieþ z klientami, testowaniu produktów itd.” [Teasley i inni]. Wedäug moich doĈwiadczeþ programiĈci w zespoäach stosujñcych XP spödzajñ na programowaniu wiöcej czasu. Przypisujö to lepszej komunikacji, która wynika ze wspólnej pracy. Zamiast zwoäywaè godzinne zebrania, czäonkowie zespoäów prowadzñ rozmowy, które trwajñ tylko niezbödnñ iloĈè czasu, a uczestniczñ w nich wyäñcznie potrzebne osoby. Czäonkowie zespoäów, które pracujñ w jednym miejscu, nie tylko mogñ bäyskawicznie uzyskaè odpowiedzi na swe pytania, ale teĔ doĈwiadczajñ zjawiska, które Cockburn nazwaä komunikacjñ osmotycznñ [Cockburn]. Czasem zdarza siö, Ĕe w trakcie rozmowy z kimĈ w zatäoczonym pomieszczeniu czäowiek säyszy w tle swoje imiö. Choè koncentruje siö na konwersacji, mózg zwraca uwagö na wszystkie inne rozmowy toczñce siö w pokoju. Kiedy padnie imiö danej osoby, trafia do jej ĈwiadomoĈci. Czäowiek säyszy wtedy nie tylko wäasne imiö, ale takĔe fragmenty rozmowy, w której ono padäo. Zjawisko to nosi nazwö efektu cocktail party5. WyobraĒmy sobie, Ĕe zespóä pracuje w jednym miejscu. Czäonkowie grupy koncentrujñ siö na zadaniach i cicho rozmawiajñ z partnerami. Wtem ktoĈ wspomina o zarzñdzaniu poäñczeniami z bazñ danych, na co wtrñca siö inny programista: „Razem z Tomkiem zajöliĈmy siö refaktoryzacjñ puli poäñczeþ z bazñ danych w zeszäym tygodniu. Nie trzeba juĔ röcznie nimi zarzñdzaè”. Kiedy podobne rozmowy nie sprawiajñ problemów czäonkom zespoäu, majñ miejsce doĈè czösto (przynajmniej raz dziennie) i za kaĔdym razem prowadzñ do zaoszczödzenia czasu i pieniödzy. Jest teĔ jeszcze jedna ukryta korzyĈè ze wspólnej Kiedy zauwaĔam, Ĕe miödzy pracy. Ten sposób dziaäania pomaga w scalaniu zespoäu i przeäamuje nastawienie „my kontra oni” poszczególnymi grupami w stosunkach miödzy grupami. Z kolei duĔa w zespole panujñ wrogie stosunki, odlegäoĈè zdaje siö sprzyjaè wrogim stosunkom sugerujö wspólnñ pracö. i obwinianiu „tamtych”. Zawsze kiedy zauwaĔam podobnñ sytuacjö (na przykäad napiöcie miödzy programistami i testerami), sugerujö, aby zaczöli wspólnie pracowaè. Pomaga to grupie w nawiñzaniu kontaktów osobistych i rodzi wzajemny szacunek na gruncie zawodowym.

Sekrety wspólnej pracy Aby jak najlepiej wykorzystaè wspólnñ pracö, naleĔy upewniè siö, Ĕe zespóä jest kompletny (zobacz podrozdziaä „Zespóä w XP” w rozdziale 3.). WaĔne jest, aby czäonkowie grupy byli fizycznie obecni i mogli odpowiadaè na pytania. JeĈli ktoĈ jest czösto nieobecny — zwykle dzieje siö tak z menedĔerami produktu — naleĔy upewniè siö, Ĕe inny czäonek zespoäu potrafi udzieliè potrzebnych odpowiedzi. Dobrym zastöpcñ podróĔujñcego menedĔera produktu jest czösto ekspert z dziedziny. Poszczególne osoby powinny siedzieè na tyle blisko siebie, aby mogäy przeprowadziè krótkñ rozmowñ bez wstawania od biurka i bez podnoszenia gäosu. Pomaga to takĔe w komunikacji osmotycznej, która opiera siö na „podsäuchiwaniu” konwersacji prowadzonych przez innych czäonków zespoäu. 5

Najlepszy znany mi opis tego zjawiska dla laików znajduje siö w Wikipedii: http://en.wikipedia.org/wiki/ Cocktail_party_effect (po angielsku).

WSPÓ NA PRACA

139

Przykĥadowe pomieszczenie robocze Przykäadowe pomieszczenie robocze przedstawione na rysunku 6.2 zaprojektowano dla zespoäu skäadajñcego siö z 13 osób. Grupa obejmowaäa szeĈciu programistów, a w pomieszczeniu znajdowaäo siö szeĈè stanowisk do pracy w parach i szereg pojedynczych, osobistych stanowisk. NieprogramiĈci siedzieli blisko stanowisk do pracy w parach, aby mogli uczestniczyè w rozmowach takĔe wtedy, kiedy pracowali indywidualnie. Indywidualne stanowiska programistów znajdowaäy siö na samym koþcu, poniewaĔ zwykle siedzieli oni przy stanowiskach do pracy w parach. Osoby, które potrzebowaäy prywatnoĈci, mogäy przejĈè na koniec pomieszczenia roboczego lub do jednego z maäych pomieszczeþ konferencyjnych rozmieszczonych wzdäuĔ korytarza.

Rysunek 6.2. Przykäadowe pomieszczenie robocze

NiezaleĔnie od stanowisk do pracy w parach, kaĔdy czäonek zespoäu miaä laptopa do wykonywania indywidualnych zadaþ i korzystania z poczty elektronicznej. Do logowania siö na stanowiska do pracy w parach säuĔyäo hasäo wspólne dla caäej grupy, dlatego kaĔda osoba mogäa z nich korzystaè. Przed przygotowaniem pomieszczenia roboczego czäonkowie zespoäu pracowali w komórkach w tej samej czöĈci biura. Aby utworzyè nowy pokój, zmienili ukäad Ĉcian dziaäowych. To pomieszczenie robocze byäo dobre, ale nie doskonaäe. Brakowaäo w nim przestrzeni na Ĉcianach na diagramy i tablicy, a nieprogramiĈci nie mieli wystarczajñco duĔych biurek. WĈród zalet warto wspomnieè o duĔej iloĈci stanowisk do pracy w parach, co umoĔliwiaäo czöstñ pracö klientów z programistami. Korzystne byäy teĔ dodatkowe stanowiska dla osób tymczasowo wspóäpracujñcych z grupñ.

Maĥe pomieszczenie robocze Maäe pomieszczenie robocze przedstawione na rysunku 6.3 przygotowano na potrzeby rozwijajñcej siö firmy po przeniesieniu siedziby do nowego biura. Organizacja wciñĔ byäa doĈè maäa, dlatego nie mogäa sobie pozwoliè na wymyĈlne pomieszczenie robocze. Zespóä skäadaä siö z siedmiu osób: szeĈciu programistów i menedĔera produktu.

142

ROZDZ AĤ 6

WSPÓĤPRACA

Rysunek 6.3. Maäe pomieszczenie robocze

Zespóä rozmieĈciä piöè stanowisk do pracy w parach wzdäuĔ däuĔszej Ĉciany. Z boku znajdowaä siö stóä uĔywany w trakcie spotkaþ, a na Ĉcianach pomieszczenia wisiaäy diagramy i tablice. Naprzeciwko tego pomieszczenia znajdowaäo siö kilka czöĈciowo otwartych komórek dla programistów, które peäniäy funkcjö ich osobistych miejsc pracy. PrywatnoĈè zapewniaäy pobliskie maäe sale konferencyjne. Byäo to doskonaäe pomieszczenie robocze z jednñ powaĔnñ wadñ: menedĔer produktu nie znajdowaä siö w zasiögu gäosu i nie uczestniczyä w dyskusjach zespoäu. Grupa nie mogäa szybko uzyskaè odpowiedzi na pytania i czösto miaäa problemy z ustaleniem wymagaþ.

Przeprowadzka do otwartego pomieszczenia roboczego Niektórzy czäonkowie zespoäu mogñ sprzeciwiaè siö przenosinom do otwartego pomieszczenia roboczego. Obawy dotyczñ utraty indywidualnoĈci i prywatnoĈci, obniĔenia statusu zwiñzanego z utratñ prywatnego biura oraz niedostrzegania wkäadu poszczególnych osób przez menedĔerów. Czäonkowie zespoäu mogñ takĔe narzekaè na czynniki rozpraszajñce i haäas, jednak zwykle ukrywajñ siö za tym inne obawy. Podobnie jak przy programowaniu w parach, wiökszoĈè osób po pewnym czasie zaczyna doceniaè korzyĈci wspólnej pracy, jednak czasem dzieje siö tak dopiero po kilku miesiñcach. W badaniach Teasleya czäonkowie zespoäu poczñtkowo woleli komórki od otwartego pomieszczenia roboczego, jednak pod koniec eksperymentu zaczöli preferowaè otwartñ przestrzeþ [Teasley i inni]. Jednak zmuszanie ludzi do wspólnej pracy w nadziei, Ĕe to polubiñ, to zäy pomysä. Kiedy zmuszaäem do tego czäonków zespoäu, ci zawsze znajdowali sposób na opuszczenie grupy, nawet jeĈli oznaczaäo to zmianö pracy. W zamian naleĔy porozmawiaè z zespoäem o obawach, kosztach i zyskach przeprowadzki

Nie naleĔy zmuszaè pracowników do wspólnej pracy wbrew ich woli.

WSPÓ NA PRACA

143

Efekty Kiedy zespóä pracuje w jednym miejscu, komunikacja jest duĔo skuteczniejsza. Czäonkowie grupy przestajñ zgadywaè odpowiedzi i zadajñ wiöcej pytaþ. Säuchajñ teĔ rozmów innych osób i udzielajñ nieoczekiwanych podpowiedzi. Czäonkowie zespoäu spontanicznie tworzñ wielofunkcyjne grupy do rozwiñzywania problemów. Rodzi siö atmosfera koleĔeþskoĈci i wzajemnego szacunku.

Przeciwwskazania Najtrudniejszym elementem wspólnej pracy jest znalezienie przestrzeni na otwarte pomieszczenie robocze. Komórki, nawet przylegajñce do siebie, nie zapewniajñ korzyĈci, jakie daje otwarte biuro. NaleĔy zaczñè od razu pracowaè nad tym problemem, poniewaĔ jego rozwiñzanie moĔe zajñè kilka miesiöcy. Nie wolno zmuszaè zespoäu do wspólnego przebywania wbrew woli jego czäonków. Zdecydowani przeciwnicy znajdñ sposób na porzucenie zespoäu, a czasem nawet i firmy. NaleĔy ostroĔnie podchodziè do wspólnej pracy, jeĈli programiĈci nie majñ programowaè w parach. Samodzielne programowanie wymaga ciszy. Z kolei programowanie w parach umoĔliwia programistom ignorowanie haäasu.

Inne moŜliwoļci Wspólna praca to jedna z najbardziej skutecznych praktyk XP. Jest waĔna z uwagi na komunikacjö i dynamikö zespoäu. Praca w oddzielnych pomieszczeniach prowadzi do niestabilnych relacji, zwäaszcza miödzy róĔnymi grupami funkcjonalnymi, i jest niekorzystna dla zespoäu. JeĈli pracownicy znajdujñ siö w tej samej jednostce, lepiej znaleĒè sposób na wspólnñ pracö. JeĈli zespóä jest rozproszony po róĔnych jednostkach, Praca zespoäów rozproszonych warto zastanowiè siö nad utworzeniem odröbnego po róĔnych jednostkach zespoäu w kaĔdej jednostce. Na przykäad, jeĈli programiĈci pracujñ w jednym miejscu, a klienci jest trudna i kosztowna. w innym, programiĈci mogñ przydzieliè analitykom biznesowym rolö poĈredników miödzy nimi a klientami. W tym przypadku klienci i zespóä programistów bödñ pracowaè razem, twarzñ w twarz, przez kilka poczñtkowych tygodni pracy nad kaĔdym wydaniem. JeĈli zespoäów programistów jest wiöcej, warto zastanowiè siö nad podziaäem ich obowiñzków, aby kaĔda grupa pracowaäa nad zupeänie innym kodem bazowym. Evans doskonale opisuje róĔne moĔliwoĈci dokonania takiego podziaäu [Evans]. MoĔliwe jest stosowanie XP w zespoäach rozproszonych po róĔnych jednostkach, jednak wymaga to wielu podróĔy. Yap przedstawia ciekawy raport, w którym opisuje, jak jej zespóä poradziä sobie w takich warunkach, pracujñc 24 godziny na dobö w 3 strefach czasowych [Yap]. Yap skoncentrowaäa siö na maksymalizacji komunikacji. Czäonkowie zespoäu latali do poszczególnych jednostek i pracowali tam po kilka tygodni. Kiedy przebywali w róĔnych jednostkach, codziennie komunikowali siö drogñ telefonicznñ.

WSPÓ NA PRACA

145

JeĈli caäy zespóä nie moĔe wspólnie pracowaè, a mimo to chce stosowaè XP, naleĔy porozmawiaè z mentorem (zobacz podrozdziaä „Szukanie mentora” w rozdziale 2.) o dostöpnych moĔliwoĈciach i zatrudniè doĈwiadczonych coachów w kaĔdej jednostce.

JeĈli nie moĔna pracowaè w jednym miejscu, naleĔy porozmawiaè z mentorem o innych moĔliwoĈciach.

Dalsza lektura W ksiñĔce Agile Software Development [Cockburn] znajduje siö doskonaäy rozdziaä na temat komunikacji. Rozdziaä 3., „Communicating, Cooperating Teams”, omawia radiatory informacji, jakoĈè komunikacji i wiele innych zagadnieþ zwiñzanych ze wspólnñ pracñ. JeĈli zespóä nie moĔe pracowaè w jednym miejscu, warto zapoznaè siö z artykuäem Follow the Sun: Distributed Extreme Programming Development [Yap]. Autorka opisuje w nim wäasne doĈwiadczenia z pracy w jednym zespole stosujñcym XP, który byä rozproszony po trzech jednostkach w strefach czasowych przesuniötych wzglödem siebie po osiem godzin. Rozdziaä 14. ksiñĔki Domain-Driven Design [Evans], „Maintaining Model Integrity”, zawiera doskonaäe omówienie metod koordynacji kilku zespoäów programistycznych. Choè pozycja ta dotyczy przede wszystkim obiektowych modeli dziedziny, wspomniany rozdziaä ma zastosowania w wielu paradygmatach projektowych.

146

ROZDZ AĤ 6

WSPÓĤPRACA

ZaangaŜowanie prawdziwego klienta

Odb orcy Coachowie klienci

Rozumiemy cele i wñtpliwoĈci klientów oraz uĔytkowników koþcowych. Pracowaäem kiedyĈ w stosujñcym XP zespole, który obejmowaä chemika. Jego poprzednia praca wymagaäa korzystania z oprogramowania, które zespóä miaä zastñpiè. Osoba ta byäa nieocenionñ pomocñ, peänñ wiedzy o tym, co dziaäaäo w dawnym produkcie, a co nie. MieliĈmy szczöĈcie, Ĕe byäa jednym z przedstawicieli klientów. Dziöki tej osobie utworzyliĈmy bardziej wartoĈciowy produkt. W zespoäach stosujñcych XP przedstawiciele klientów odpowiadajñ za wybór funkcji i okreĈlanie, które z nich sñ priorytetowe. WartoĈè projektu leĔy w ich rökach. Jest to duĔa odpowiedzialnoĈè — skñd przedstawiciel klienta ma wiedzieè, które funkcje wybraè? CzöĈè tej wiedzy pochodzi z doĈwiadczenia w danej dziedzinie i w korzystaniu z poprzednich wersji oprogramowania. Trudno jednak pomyĈleè o wszystkim. Codzienne zaangaĔowanie w projekt, choè niezbödne, grozi zawöĔeniem pola widzenia. Przedstawiciel klienta moĔe tak bardzo skoncentrowaè siö na codziennych szczegóäach pracy nad projektem, Ĕe zapomni o tym, co jest waĔne dla prawdziwych klientów. Aby poszerzyè perspektywö, trzeba zaangaĔowaè prawdziwych klientów. Optymalne podejĈcie zaleĔy od tego, dla kogo przeznaczone jest rozwijane oprogramowanie.

Rozwój na potrzeby wĥasne Przy rozwoju na potrzeby wäasne zespóä sam jest swym klientem. Grupa rozwija oprogramowanie do wäasnego uĔytku. Nie trzeba wtedy doäñczaè do zespoäu przedstawicieli klientów, poniewaĔ grupa jest prawdziwym klientem.

UWAGA Wspominam o tym typie rozwoju gäównie z uwagi na kompletnoĈè przeglñdu. WiökszoĈè projektów rozwoju na potrzeby wäasne to maäe, jednorazowe aplikacje, które nie wymagajñ pracy peänego zespoäu XP.

Niestandardowe rozwiézania wewnýtrzne Zespóä rozwija niestandardowe rozwiñzania wewnötrzne, kiedy organizacja poprosi o utworzenie programu na uĔytek wäasny firmy. Jest to klasyczne zadanie dla dziaäu IT. MoĔe wymagaè napisania oprogramowania do usprawnienia przebiegu róĔnych operacji, automatyzacji fabryk firmy lub generowania raportów w dziale rachunkowoĈci. W takim Ĉrodowisku zespóä musi obsäuĔyè kilku klientów: wäaĈciciela projektu, päacñcego za oprogramowanie, oraz uĔytkowników koþcowych, którzy bödñ uĔywali produktu. Cele tych osób nie zawsze sñ takie same. W najgorszym przypadku trzeba zadowoliè komitet wäaĈcicieli projektu i szereg grup uĔytkowników.

ZAANGAśOWAN E PRAWDZ WEGO K

ENTA

147

UĔytkownicy koþcowi czösto myĈlñ o oprogramowaniu w kategoriach usprawnienia pracy, a nie pod kñtem znalezienia zupeänie nowych rozwiñzaþ. Jest to nastöpny powód, dla którego naleĔy wäñczyè uĔytkowników koþcowych w rozwój produktu, ale nie naleĔy dawaè im kontroli nad tym procesem. JeĈli wprowadzenie innowacji to waĔny element projektu, naleĔy zapewniè kreatywnym pomysäodawcom — na przykäad wizjonerowi peäniñcemu funkcjö menedĔera produktu lub projektanta interakcji — znaczñcñ rolö w zespole.

Inne moŜliwoļci ZaangaĔowanie prawdziwych klientów jest waĔne, ale nie niezbödne. Czasem najlepsze oprogramowanie wymyĈlajñ osoby, które majñ wyraĒnñ wizjö i aktywnie dñĔñ do jej realizacji. Powstajñ wtedy produkty, które albo sñ caäkowicie nowatorskie, albo sñ znacznym usprawnieniem istniejñcych wersji oprogramowania. Przy braku prawdziwych klientów naleĔy koniecznie zaangaĔowaè menedĔera produktu z wizjñ. Najlepiej jeĈli ta osoba dobrze rozumie danñ dziedzinö, jednak moĔna teĔ wäñczyè do zespoäu ekspertów z branĔy. Jednak informacje zwrotne od prawdziwych klientów sñ zawsze waĔne, nawet wtedy, jeĈli zespóä zdecyduje siö je zignorowaè. Sñ one szczególnie uĔyteczne, jeĈli zespóä zainstaluje rozwijane oprogramowanie i umoĔliwi uĔytkownikom korzystanie z niego. Reakcje klientów na dziaäajñcy program to bardzo wartoĈciowe informacje okreĈlajñce prawdopodobieþstwo osiñgniöcia prawdziwego sukcesu.

ZAANGAśOWAN E PRAWDZ WEGO K

ENTA

151

Wspólny jýzyk Rozumiemy siö wzajemnie.

Odb orcy P og amiļci

Warto wykonaè proste èwiczenie i spróbowaè opisaè logikö biznesowñ obecnie rozwijanego systemu ekspertowi z dziedziny, który nie jest programistñ. Czy moĔliwe jest wyjaĈnienie dziaäania systemu w säowach zrozumiaäych dla eksperta z dziedziny? Czy moĔna uniknñè Ĕargonu programistycznego, na przykäad nazw wzorców projektowych lub stylów pisania kodu? Czy ekspert z dziedziny potrafi wykryè problemy w logice biznesowej? JeĈli nie, trzeba zastosowaè wspólny jözyk.

Problem wiedzy z dziedziny Jedna z trudnoĈci w profesjonalnym rozwoju oprogramowania polega na tym, Ĕe programiĈci nie zawsze sñ ekspertami w dziedzinie, na której potrzeby rozwijajñ program. Pomagaäem miödzy innymi w pisaniu oprogramowania do kontroli robotów w fabryce, sterowania skomplikowanymi transakcjami finansowymi i analizowania danych z instrumentów naukowych. Kiedy rozpoczynaäem pracö nad tymi projektami, nic nie wiedziaäem o tych zagadnieniach. Na tym wäaĈnie polega problem. Osoby, które sñ ekspertami w dziedzinie problemowej — eksperci z dziedziny — rzadko majñ umiejötnoĈci potrzebne do rozwoju oprogramowania. Z kolei ludzie, którzy potrafiñ tworzyè oprogramowanie, czyli programiĈci, nie zawsze rozumiejñ dziedzinö problemowñ.

UWAGA Zatrudnienie programistów z wiedzñ z danej dziedziny pozwala zmniejszyè ten problem, ale nie eliminuje go. Ponadto, kiedy mam wybór miödzy doskonaäym programistñ bez wiedzy z dziedziny i säabym programistñ znajñcym danñ branĔö, wybieram lepszego programistö.

Rozwiñzanie tych trudnoĈci zaleĔy przede wszystkim od komunikacji. Eksperci z dziedziny powinni przekazywaè swñ wiedzö programistom, którzy z kolei przeksztaäcajñ jñ na oprogramowanie. Problem polega na przekazywaniu informacji jasno i precyzyjnie.

Dwa jýzyki WyobraĒmy sobie, Ĕe programista jedzie na rozmowñ o pracö. Zapomniaä mapy, dlatego wskazówek udziela mu znajomy przez telefon komórkowy (oczywiĈcie programista korzysta z zestawu gäoĈnomówiñcego!). „WäaĈnie minñäem stacjö benzynowñ po prawej” — mówi programista. „I duĔe skrzyĔowanie”. „Czekaj…” — odpowiada znajomy, przeglñdajñc mapö. „Na jakiej ulicy jesteĈ i w jakim kierunku jedziesz?”. „Nie mam pojöcia!” — krzyczy programista, wciskajñc hamulce, kiedy jasnoĔóäty sportowy samochód zajeĔdĔa mu drogö. „Uch… przepraszam. Jest duĔo zakrötów — to coĈ pomoĔe? Chwilö — wäaĈnie minñäem Mickiewicza”. „Alejö Mickiewicza czy pomnik Mickiewicza?” — pyta znajomy. 152

ROZDZ AĤ 6

WSPÓĤPRACA

Problem w tej sytuacji polega na tym, Ĕe programista i jego znajomy posäugujñ siö dwoma odmiennymi jözykami. Programista mówi o tym, co widzi na drodze, a znajomy o tym, co znajduje siö na mapie. Niezbödne jest täumaczenie z jednego jözyka na drugi, co prowadzi do opóĒnieþ i bäödów. Programista kiedyĈ dojedzie na spotkanie, jednak po drodze prawdopodobnie przegapi kilka zakrötów i moĔe siö spóĒniè. Podobny problem pojawia siö przy komunikacji miödzy programistami a ekspertami z dziedziny. ProgramiĈci programujñ w jözyku technologii: klas, metod, algorytmów i baz danych. Eksperci z dziedziny posäugujñ siö jözykiem z branĔy, dotyczñcym modeli finansowych, instalacji do produkcji ukäadów scalonych i tak dalej. MoĔna próbowaè täumaczyè pojöcia miödzy tymi jözykami, ale powoduje to opóĒnienia i bäödy. W takiej sytuacji zespóä kiedyĈ ukoþczy oprogramowanie, jednak po drodze pojawiñ siö w nim usterki. W zamian naleĔy wybraè tylko jeden jözyk, którego uĔywaè bödzie caäy zespóä — wspólny jözyk.

Jak posĥugiwaë siý tym samym jýzykiem? ProgramiĈci powinni uĔywaè jözyka ekspertów z dziedziny, a nie na odwrót. WyobraĒmy sobie, Ĕe programista tworzy fragment oprogramowania do wyĈwietlania nut. Wydawnictwo, dla którego pracuje, udostöpnia opis muzyki w formacie XML, a program ma jñ w odpowiedni sposób wyĈwietliè. Jest to trudne zadanie, zwiñzane z pozornie drobnymi wyborami stylu, które jednak sñ kluczowe dla klienta. W takiej sytuacji moĔna skoncentrowaè siö na obiektach jözyka XML: elementach, wözäach nadrzödnych, wözäach podrzödnych i atrybutach. MoĔna rozmawiaè o kontekĈcie urzñdzenia, bitmapach i glifach. Konwersacja wyglñda wtedy nastöpujñco: Programista: „Zastanawiamy siö, jak wyĈwietlaè ten klucz. Którego glifu powinniĈmy uĔyè, jeĈli pierwszym wözäem podrzödnym elementu jest G, a drugim — 2, a przy tym element zmiany oktawy ma wartoĈè –1? Czy to klucz wiolinowy?”. Ekspert z dziedziny: (MyĈli — „Nie mam pojöcia, o czym mówi ten czäowiek. Jednak jeĈli siö do tego przyznam, zacznñ mówiè jeszcze mniej zrozumiale. Lepiej bödö udawaä, Ĕe wiem, o co chodzi”). „Aha… pewnie, G, to klucz wiolinowy. Dobra robota”. W zamian naleĔy skoncentrowaè siö raczej na pojöciach z dziedziny niĔ zagadnieniach technicznych. Programista: „Zastanawiamy siö, jak wyĈwietlaè ten klucz G. Znajduje siö na drugiej linii, jednak jest obniĔony o oktawö. Czy to klucz wiolinowy?”. Ekspert z dziedziny: (MyĈli — „To proste. Dobrze”). „Czösto uĔywa siö tego w partiach tenorów w utworach na chór. Tak, to klucz wiolinowy, jednak poniewaĔ jest obniĔony o oktawö, uĔywamy dwóch symboli zamiast jednego. Zaraz pokaĔö wam przykäad”. OdpowiedĒ eksperta z dziedziny w drugim przypadku jest inna, poniewaĔ rozumie pytanie. Z kolei pierwsza rozmowa prowadzi do bäödu.

WSPÓ NY JüZYK

153

Wspólny jýzyk w kodzie Programista moĔe mieè problemy z posäugiwaniem siö jözykiem eksperta z dziedziny. Kiedy pracuje nad trudnym problemem, trudno mu w umyĈle täumaczyè zdania z jözyka kodu na jözyk dziedziny. Dobre rozwiñzanie to zaprojektowanie kodu tak, aby opieraä siö na jözyku dziedziny. MoĔna nazwaè klasy, metody i zmienne w dowolny sposób. Dlaczego nie uĔyè pojöè stosowanych przez ekspertów z dziedziny? Chodzi tu nie tylko o poznanie dziedziny w celu napisania oprogramowania. NaleĔy odzwierciedliè w kodzie sposób, w jaki uĔytkownicy oprogramowania myĈlñ i mówiñ o swej pracy. Przez odzwierciedlenie w kodzie zrozumienia dziedziny programista rozwija swñ wiedzö i — z uwagi na bezwzglödny wymóg precyzji w kodzie — uwidacznia braki w niej, które mogäyby doprowadziè do bäödów. Wróèmy do przykäadu. Program wyĈwietlajñcy nuty na podstawie danych wejĈciowych w formacie XML moĔna zaprojektowaè na podstawie pojöè z jözyka XML. Jednak lepszym podejĈciem jest zaprojektowanie go na podstawie pojöè z dziedziny. Oba sposoby przedstawia rysunek 6.4.

Rysunek 6.4. Projekt oparty na XML i dziedzinie

Jednym ze skutecznych sposobów na zaprojektowanie aplikacji tak, aby opieraäa siö na jözyku z dziedziny, jest utworzenie modelu dziedziny. Zagadnienie to zasäuguje na odröbnñ ksiñĔkö. WartoĈciowe pozycje na ten temat to miödzy innymi [Evans] i [Wirfs-Brock i McKean].

UWAGA Proces tworzenia projektu opartego na dziedzinie to projektowanie skoncentrowane na dziedzinie lub modelowanie dziedziny. Niektórzy uwaĔajñ, Ĕe jest to to samo co projektowanie obiektowe. Dlatego projektowanie skoncentrowane na dziedzinie jest czasem nazywane „prawdziwym” projektowaniem obiektowym, aby odróĔniè je od projektowania obiektowego, w którym nie käadzie siö nacisku na pojöcia z dziedziny.

154

ROZDZ AĤ 6

WSPÓĤPRACA

Precyzowanie wspólnego jýzyka Wspólny jözyk zapewnia informacje programistom; z kolei potrzeba Ĉcisäej formalizacji specyficzna dla programistów zapewnia informacje pozostaäym czäonkom zespoäu. Czösto spotykam siö z sytuacjami, kiedy programiĈci zadajñ pytanie zwiñzane z problemami z kodem, a to z kolei powoduje zmianö niektórych zaäoĔeþ przyjmowanych przez ekspertów z dziedziny. Dlatego wspólny jözyk jest Ĕywy. Jest tylko na tyle dobry, na ile potrafi odzwierciedliè rzeczywistoĈè. Wraz ze wzbogacaniem wiedzy naleĔy rozwijaè teĔ sam jözyk. Trzeba jednak pamiötaè przy tym o trzech puäapkach. Po pierwsze, trzeba siö upewniè, Ĕe wszyscy czäonkowie zespoäu, a przede wszystkim eksperci z dziedziny, rozumiejñ proponowane zmiany i zgadzajñ siö na nie. Zwykle wymaga to wielu rozmów w celu rozwiñzania wszelkich konfliktów. Nie naleĔy siö tego obawiaè! Po drugie, naleĔy ustaliè, czy zmiany poprawiajñ zrozumienie wymagaþ biznesowych. Zmiana moĔe na pozór wyjaĈniaè pewne rzeczy, jednak jözyk musi odzwierciedlaè to, co uĔytkownik chce osiñgnñè dziöki oprogramowaniu. NaleĔy zrezygnowaè z Ĕargonu programistycznego. MoĔna pomóc ekspertom z dziedziny lepiej zrozumieè skomplikowane warunki brzegowe, jednak nie naleĔy zastöpowaè ich jözyka wäasnym. Po trzecie, naleĔy zaktualizowaè projekt oprogramowania z uwzglödnieniem zmian. Niezbödna jest ciñgäa synchronizacja miödzy modelem a wspólnym jözykiem. Zmiana w jözyku wymaga zmodyfikowania modelu. Tak, oznacza to, Ĕe programiĈci powinni poddaè kod refaktoryzacji, kiedy zmieni siö ich sposób rozumienia dziedziny. Odkäadanie zmian na póĒniej prowadzi do powstania ukrytego däugu technicznego zwiñzanego z niedopasowaniem miödzy projektem a rzeczywistoĈciñ, co moĔe doprowadziè do bäödów i nieeleganckich obejĈè problemów.

Pytania Czy naleĔy unikaè stosowania jakichkolwiek terminów technicznych? W dziedzinie biznesowej, nad którñ pracujemy, nie ma nic o kontrolkach GUI ani bazach danych. Dozwolone jest uĔywanie jözyka technicznego w obszarach niepowiñzanych z dziedzinñ. Prawdopodobnie najlepszñ nazwñ na poäñczenie z bazñ danych jest „poäñczenie”, a na przycisk — „przycisk”. Jednak zwykle naleĔy ukrywaè techniczne szczegóäy za warstwñ zwiñzanñ z dziedzinñ.

Efekty Wspólny jözyk klientów i programistów zmniejsza ryzyko wystöpowania bäödów w komunikacji. ProgramiĈci dziöki stosowaniu takiego jözyka przy projektowaniu i implementowaniu oprogramowania tworzñ kod, który äatwiej zrozumieè i zmodyfikowaè. Kiedy caäy zespóä uĔywa wspólnego jözyka w trakcie wspólnej pracy, kaĔdy moĔe usäyszeè dyskusje na temat dziedziny (zwäaszcza w czasie pracy w parach). Czäonkowie zespoäu podsäuchujñ rozmowy z obszaru dziedziny i implementacji oraz mogñ doäñczyè do konwersacji, aby odpowiedzieè na pytania i ujawniè ukryte zaäoĔenia.

WSPÓ NY JüZYK

155

Zwiýzĥoļë Celem krótkich spotkaþ roboczych jest ogólne poinformowanie wszystkich osób o tym, na jakim etapie pracy zespóä siö znajduje. Nie oznacza to kompletnego przeglñdu wszystkiego, co dzieje siö w projekcie. Podstawowñ zaletñ krótkich spotkaþ roboczych jest zwiözäoĈè. Dlatego grupa stoi — zmöczone stopy przypominajñ uczestnikom o tym, aby nie przeciñgaè spotkania. KaĔda osoba zazwyczaj musi powiedzieè tylko kilka zadaþ o wykonywanym zadaniu. Zwykle wystarcza na to 30 sekund. Bardziej szczegóäowe dyskusje powinny odbywaè siö w trakcie mniejszych spotkaþ, w których uczestniczñ tylko zainteresowane osoby. PoniĔej przedstawiam kilka przykäadowych wypowiedzi:

Zwykle wystarcza 30 sekund na osobö.

Programista: Wczoraj wraz z Robertem przeprowadziliĈmy refaktoryzacjö logiki tworzenia puli poäñczeþ z bazñ danych. Warto do tego zajrzeè — wprowadziliĈmy kilka ciekawych uproszczeþ w sposobie äñczenia siö z bazñ. Na dziĈ jestem wolny i chötnie zajmö siö czymĈ zwiñzanym z GUI. MenedĔer produktu: Jak wiecie, w zeszäym tygodniu nie byäo mnie w biurze, bo braäem udziaä w pokazie handlowym. Uzyskaäem bardzo ciekawe informacje zwrotne na temat interfejsu uĔytkownika i kierunku rozwoju produktu. Musimy wprowadziè kilka zmian w planie wydania. Dzisiaj wraz z pozostaäymi klientami bödö pracowaä nad opracowaniem szczegóäów. Za dzieþ lub dwa mogö przedstawiè wyniki tych prac w trakcie wspólnego obiadu, jeĈli ktoĈ bödzie chciaä dowiedzieè siö czegoĈ wiöcej. [Kilku czäonków zespoäu wyraĔa zainteresowanie]. Ekspert z dziedziny: Po tym, jak zapytaliĈcie mnie wczoraj [ekspert wskazuje na programistów] o tö reguäö finansowñ, porozmawiaäem z KrzyĈkiem. Reguäa obejmuje wiöcej szczegóäów, niĔ poczñtkowo sñdziliĈmy. Mam kilka poprawek do testów klienta, które chciaäbym z kimĈ omówiè. OdpowiedĒ programisty: Ja siö tym zajmujö. MoĔemy popracowaè razem, kiedy tylko zechcesz. JeĈli krótkie spotkanie robocze trwa däuĔej niĔ dziesiöè (maksymalnie 15) minut, jest zbyt däugie. JeĈli kaĔda osoba mówi przez 30 sekund, dziesiöcioosobowemu zespoäowi spotkanie powinno zajñè zwykle okoäo piöciu minut. ZwiözäoĈè to sztuka trudna do opanowania. W ramach praktyki warto spróbowaè zapisaè wczeĈniej swñ wypowiedĒ na karteczce, a nastöpnie odczytaè jñ w trakcie spotkania. Inne rozwiñzanie polega na ograniczeniu däugoĈci spotkania. W zaleĔnoĈci od wielkoĈci zespoäu, moĔna ustawiè stoper na piöè lub dziesiöè minut. Kiedy czas upäynie, spotkanie jest skoþczone, nawet jeĈli niektóre osoby nie zdñĔyäy siö jeszcze wypowiedzieè. Na poczñtku moĔe siö okazaè, Ĕe spotkania koþczñ siö przedwczeĈnie, jednak w ciñgu tygodnia lub dwóch uczestnicy powinni nauczyè siö bardziej zwiözäego omawiania swych zadaþ.

158

ROZDZ AĤ 6

WSPÓĤPRACA

Przeciwwskazania Nie naleĔy pozwoliè, aby codzienne spotkania robocze zastöpowaäy komunikacjö. Czäonkowie niektórych zespoäów oczekujñ na takie spotkanie, zamiast od razu porozmawiaè z innñ osobñ, kiedy jest to potrzebne. JeĈli tak siö stanie, tymczasowa rezygnacja z krótkich spotkaþ roboczych moĔe usprawniè komunikacjö.

NaleĔy informowaè o problemach bezpoĈrednio po ich pojawieniu siö.

NaleĔy uwaĔaè na liderów, którzy dominujñ spotkania. Jak säusznie zauwaĔyä Jonathan Clarke (jeden z recenzentów), wzorcowy lider to „charyzmatyczny, ale niecierpliwy wspóäpracownik, który pogania prelegentów i przerywa ich wypowiedzi”. Krótkie spotkanie robocze to zebranie równych sobie wspóäpracowników. ēadna osoba nie powinna dominowaè.

Inne moŜliwoļci JeĈli nie moĔna przeprowadziè krótkiego spotkania roboczego, trzeba zachowaè kontakt w inny sposób. JeĈli zespóä pracuje wspólnie, wystarczajñca moĔe byè nawet naturalna komunikacja. NaleĔy zwracaè uwagö na nieprzyjemne niespodzianki, którym bardziej intensywna komunikacja moĔe zapobiec. Inna moĔliwoĈè to tradycyjne cotygodniowe spotkania na temat stanu projektu. Moim zdaniem sñ one bardziej skuteczne, kiedy czäonkowie zespoäu przekazujñ informacje jednemu moderatorowi, który nastöpnie moĔe w ciñgu 10 – 15 minut przedstawiè podsumowanie informacji. Jednak widziaäem teĔ, jak czäonkowie zespoäu szybko przestali przestrzegaè tego podejĈcia.

Dalsza lektura Artykuä It’s Not Just Standing Up: Patterns for Daily Stand-up Meetings [Yip], dostöpny pod adresem http://www.martinfowler.com/articles/itsNotJustStandingUp.html, zawiera ciekawy przeglñd metod prowadzenia krótkich spotkaþ roboczych. Autor artykuäu Stand-Up Meeting Antipatterns [Miller], dostöpnego pod adresem http://fishbow.pastiche.org/2003/11/19/standup_meeting_antipatterns, przyjmuje podejĈcie odmienne od tego zastosowanego w tym podrozdziale i opisuje szkodliwe wzorce oraz metody przeciwdziaäania im.

160

ROZDZ AĤ 6

WSPÓĤPRACA

Standardy pisania kodu Formatujemy kod w taki sam sposób.

Odb orcy P og amiļci

Podobno w czasach telegrafów ich operatorzy potrafili rozpoznawaè siö po sposobie wystukiwania kropek i kresek. KaĔdy telegrafista ma wyjñtkowy styl, inaczej rökö, którñ eksperci potrafiñ äatwo rozpoznaè. TakĔe programiĈci majñ swój styl. KaĔdy z nas pisze kod w specyficzny sposób. Przez lata dopracowujemy styl, aby kod byä jak najbardziej czytelny, zwiözäy i przekazywaä jak najwiöcej informacji. Indywidualny styl jest wartoĈciowy, kiedy programista pracuje samodzielnie. Jednak w zespoäach programistycznych celem jest wspólne dzieäo, lepsze od tego, które kaĔdy z programistów potrafiäby utworzyè samodzielnie. Przeszkadzajñ w tym spory dotyczñce tego, czyj styl jest najlepszy. ãatwiej jest pracowaè wspólnie, stosujñc jeden standard pisania kodu. W XP warto utworzyè standardy pisania kodu, czyli wytyczne, które wszyscy programiĈci akceptujñ i do których stosujñ siö w trakcie programowania.

Poza formatowanie Kierowaäem kiedyĈ zespoäem czterech programistów, którzy mieli zupeänie odmienne podejĈcie do formatowania kodu. Kiedy omawialiĈmy standardy pisania kodu, odkryäem trzy róĔne sposoby stosowania nawiasów i odstöpów. KaĔde z tych podejĈè miaäo Ĕarliwego zwolennika. Nie chciaäem, aby zespóä pogrñĔyä siö w sporach, dlatego zdecydowaäem, Ĕe kaĔdy programista moĔe uĔywaè dowolnego stylu. Skutki äatwo przewidzieè: kod byä formatowany na trzy odmienne sposoby. ZauwaĔyäem nawet dwie róĔne wersje wciöè w jednej, krótkiej metodzie. Co byäo w tym najbardziej zaskakujñce? Zastosowane rozwiñzanie nie okazaäo siö zäe. OczywiĈcie, ukäad kodu byä okropny i wolaäbym zachowaè spójnoĈè, ale kod byä czytelny. DuĔo waĔniejsze okazaäy siö pozostaäe standardy pisania kodu, a nie formatowanie. Wszyscy zgodziliĈmy siö, Ĕe zrozumiaäe nazwy zmiennych i krótkie metody to waĔne cechy. ZgodziliĈmy siö stosowaè asercje w celu szybkiego wykrywania bäödów, nie optymalizowaè kodu bez wczeĈniejszych pomiarów i nigdy nie przekazywaè pustych referencji miödzy obiektami. UzgodniliĈmy sposoby obsäugi wyjñtków, postöpowanie przy diagnozowaniu kodu i czas oraz sposób rejestrowania zdarzeþ. Te standardy okazaäy siö duĔo bardziej pomocne niĔ spójny styl formatowania, poniewaĔ kaĔda z wymienionych technik dawaäa konkretne korzyĈci. Prawdopodobnie dlatego mogliĈmy osiñgnñè zgodö w ich obszarze, a nie mogliĈmy uzgodniè stylu formatowania. Nie naleĔy wyciñgaè z tego pochopnych wniosków. Spójny standard formatowania jest korzystny. JeĈli moĔna go uzgodniè, naleĔy to zrobiè. Jednak przy ustalaniu standardów pisania kodu nie naleĔy wpaĈè w puäapkö sporów na temat formatowania. Sñ waĔniejsze zagadnienia, które trzeba uzgodniè.

STANDARDY P SAN A KODU

161

Jak ustalië standardy pisania kodu? Uzgadnianie standardów pisania kodu to èwiczenie z budowania konsensusu. MoĔe to byè pierwsze zadanie, które programiĈci wykonajñ jako zespóä. Z czasem zespóä koryguje i ulepsza standardy. NajwaĔniejsze, czego moĔna siö nauczyè w trakcie ustalania standardów pisania kodu, to konstruktywne wyraĔanie odmiennych opinii.

NajwaĔniejsze, czego moĔna siö nauczyè, to wyraĔanie odmiennych opinii.

W tym obszarze zalecam stosowanie siö do dwóch wskazówek:

1. NaleĔy utworzyè minimalny zbiór standardów, który umoĔliwia pracö. 2. Trzeba skoncentrowaè siö na spójnoĈci i powszechnej zgodzie, a nie na perfekcji. Poczñtkowe rozmowy na temat standardów pisania kodu naleĔy przeprowadziè w czasie pierwszej iteracji. Projekt zwykle rozpoczyna siö od analiz dotyczñcych opowieĈci i wizji, po czym nastöpuje planowanie wydaþ i iteracji (zobacz podrozdziaä „Naprzód!” w rozdziale 4.). Po zakoþczeniu planowania iteracji klienci i testerzy nadal pracujñ nad planem wydania. Dla programistów to doskonaäa okazja na omówienie standardów pisania kodu. Najlepszy punkt wyjĈcia do utworzenia standardów pisania kodu to ogólnie obowiñzujñcy standard dla danego jözyka. Pozwala to odpowiedzieè na pytania dotyczñce formatowania i skoncentrowaè siö na zagadnieniach zwiñzanych z projektem. JeĈli zespóä ma wñtpliwoĈci, co uwzglödniè w standardach, moĔe zaczñè od takich elementów, jak: x praktyki z obszaru wytwarzania (naleĔy zaczñè od praktyk z rozdziaäów 9. i 7.); x narzödzia, skróty klawiaturowe i Ĉrodowisko IDE; x ukäad plików i katalogów; x konwencje kompilacji; x obsäuga bäödów i asercje; x podejĈcie do zdarzeþ i rejestrowania; x konwencje projektowe (na przykäad sposób postöpowania z pustymi referencjami).

NaleĔy ograniczyè pierwszñ dyskusjö do okoäo jednej godziny i zapisaè elementy uzgodnione przez grupö. JeĈli programiĈci nie zgadzajñ siö w jakimĈ obszarze, powinni przejĈè do nastöpnych zagadnieþ. Zawsze mogñ wróciè do spornych kwestii kiedy indziej.

Koncentracja na uzgodnionych elementach.

UWAGA Lubiö zapisywaè wszystkie uzgodnione elementy na tablicy flip chart, dziöki czemu moĔna przykleiè arkusz na Ĉcianie otwartego pomieszczenia roboczego. Najlepiej poprosiè o zapisywanie neutralnego obserwatora (na przykäad menedĔera projektu).

162

ROZDZ AĤ 6

WSPÓĤPRACA

NaleĔy zaäoĔyè, Ĕe wspóäpracownicy to profesjonaliĈci i majñ dobre zamiary. JeĈli ktoĈ nie stosuje siö do standardów, warto uznaè — nawet jeĈli wszystkie dowody Ĉwiadczñ inaczej — Ĕe ma ku temu dobry powód. Zadaniem lidera jest ustalenie tej przyczyny i jej uwzglödnienie. To podejĈcie dowodzi powaĔania innych i zwiökszy szacunek pozostaäych programistów do lidera.

UWAGA Przed podjöciem jakichkolwiek dziaäaþ naleĔy ustaliè, czy standardy pisania kodu zostaäy naprawdö ustalone przez caäy zespóä. JeĈli wszyscy uzgodnili je wspólnie, nie powinni mieè problemów z ich przestrzeganiem.

NaleĔy rozpoczñè od rozmów ze wspóäpracownikami, aby okreĈliè, czy sñ zgodni. Trzeba podejĈè do tego z nastawieniem na wspólne rozwiñzywanie problemów. Zamiast mówiè: „Dlaczego nie przekazujesz wyjñtków w ustalony sposób?”, naleĔy zadaè pytanie: „Co myĈlisz o standardzie przekazywania wyjñtków, który ustaliliĈmy? Czy powinniĈmy go zachowaè?”. Trzeba poĈwiöciè wñtpliwoĈciom peänñ uwagö, przedstawiè je pozostaäym czäonkom zespoäu i zastanowiè siö nad zmianñ standardów. JeĈli oponent zgodziä siö na wprowadzenie standardu, ale go nie przestrzega, moĔliwe, Ĕe dany standard nie jest odpowiedni w kaĔdej sytuacji. NaleĔy zapytaè o konkretne zauwaĔone przypadki naruszenia go. TakĔe w tym przypadku lider powinien koncentrowaè siö na wspóäpracy, a nie na konfrontacji. MoĔe stwierdziè: „UwaĔam, Ĕe mamy podobne podejĈcie do znaczenia przekazywania wyjñtków. MoĔesz mi wyjaĈniè, co staäo siö w tej metodzie? Nie rozumiem, dlaczego ten kod nie przekazuje wyjñtków”. W trakcie dyskusji moĔe siö okazaè, Ĕe oponent nie rozumie danego standardu. Jest to dobra okazja na omówienie go i jego znaczenia. JeĈli oponent to mäodszy programista, który potrzebuje dodatkowej pomocy, naleĔy skoordynowaè jego pracö z pozostaäymi czäonkami zespoäu, aby upewniè siö, Ĕe bödzie czösto pracowaä w parze z doĈwiadczonymi programistami. W zespoäach, które dopiero poznajñ XP, nieprzestrzeganie standardów moĔe wynikaè z czegoĈ innego. Wprowadzenie XP to duĔa zmiana, a programiĈci mogñ mieè poczucie utraty kontroli. Czasem reagujñ na to, rezygnujñc ze zmian w wybranych drobnych aspektach pracy. Uporczywa potrzeba pozostania przy konkretnym standardzie pisania kodu niezaleĔnie od zdania reszty zespoäu moĔe byè tego symptomem. W takim przypadku najlepszym rozwiñzaniem moĔe byè odäoĔenie na kilka miesiöcy omawiania spornych punktów. Z czasem czäonkowie zespoäu przyzwyczajñ siö do zmian w Ĉrodowisku, rozluĒniñ siö i bödñ bardziej skäonni do kompromisu.

Pytania Pracujemy nad odziedziczonym kodem, który nie pasuje do naszych standardów. Czy powinniĈmy go modyfikowaè? JeĈli starszy kod dziaäa i nie trzeba go czytaè ani modyfikowaè, moĔna pozostawiè go w jego wyjĈciowej postaci. PoĈwiöcanie däugiego czasu na wstöpne poprawianie odziedziczonego kodu jest kosztowne i ryzykowne. Zamiast tego w trakcie modyfikowania i refaktoryzacji poszczególnych sekcji kodu warto dostosowaè je do nowych standardów. W czasie naprawiania bäödów, dodawania funkcji lub poprawiania modelu i sposobu podziaäu kodu naleĔy wprowadzaè nowe standardy we wszelkich modyfikowanych fragmentach. STANDARDY P SAN A KODU

165

MoĔna teĔ uĔyè automatycznych narzödzi do wprowadzania szeroko zakrojonych zmian w formatowaniu. Nie naleĔy poĈwiöcaè na to zadanie zbyt wiele czasu, jednak jeĈli moĔna to äatwo zrobiè, dlaczego nie? Ja lubiö bezpoĈrednio przed takimi operacjami i po nich integrowaè kod, poniewaĔ zmiany w formatowaniu czasem prowadzñ do innych modyfikacji. NaleĔy pamiötaè, Ĕe wprowadzanie takich rozbudowanych poprawek moĔe znacznie zmniejszyè czytelnoĈè historii zmian w systemie kontroli wersji.

Efekty Wspólne standardy i konwencje pisania kodu zwiökszajñ äatwoĈè konserwacji i czytelnoĈè kodu. Dziöki temu moĔna äatwiej wykonywaè zadania zwiñzane z róĔnymi podsystemami. Programowanie w parach przebiega bardziej päynnie, a w czasie pisania programiĈci poszukujñ sposobów na poprawö wyrazistoĈci i solidnoĈci kodu.

Przeciwwskazania NaleĔy uwaĔaè, aby standardy pisania kodu nie doprowadziäy do podziaäów w zespole.

Inne moŜliwoļci Wspóäpraca w niektórych zespoäach jest tak dobra, Ĕe nie potrzebujñ one zapisywaè standardów pisania kodu. Standardy w takich grupach obowiñzujñ niejawnie. Jednak w nowych zespoäach warto odnotowaè standardy, nawet jeĈli wszyscy sñ zgodni w tym obszarze. Nowe grupy czösto przechodzñ na poczñtku przez „miesiñc miodowy”, w którym to okresie czäonkowie zespoäu niechötnie wyraĔajñ odmienne opinie. W pewnym momencie pojawiñ siö spory. DuĔo lepiej jest ustaliè standardy przed eskalacjñ problemów.

166

ROZDZ AĤ 6

WSPÓĤPRACA

Demonstracje iteracji Trzymamy siö rzeczywistoĈci.

Odb orcy MenedŜe p oduktu caĥy zespóĥ

Zespoäy stosujñce XP juĔ od pierwszego tygodnia co tydzieþ wytwarzajñ dziaäajñce oprogramowanie. Wydaje siö to niemoĔliwe? Nie, to po prostu trudne. Utrzymanie takiego tempa wymaga duĔo dyscypliny. ProgramiĈci potrzebujñ jej, aby zachowaè porzñdek w kodzie, dziöki czemu moĔliwe sñ staäe postöpy. Klienci muszñ przestrzegaè dyscypliny, aby w peäni zrozumieè i omówiè jeden zestaw funkcji przed rozpoczöciem pracy nad nastöpnym. Testerzy potrzebujñ dyscypliny, aby pracowaè nad codziennie zmieniajñcym siö oprogramowaniem. Nagrodñ za tö ciöĔkñ pracö jest znaczne obniĔenie ryzyka, duĔo energii i przyjemnoĈci oraz satysfakcja z dobrego wykonywania zadaþ i obserwacji postöpów. Najwiökszñ trudnoĈè sprawia utrzymanie tempa pracy. Demonstracja iteracji to doskonaäy sposób na zapewnienie ciñgäych postöpów. Po pierwsze, jest to prezentacja konkretnych postöpów. Zespóä jest z nich dumny i chötnie pokazuje efekty pracy, a udziaäowcy sñ zadowoleni, poniewaĔ mogñ je obserwowaè. Po drugie, demonstracje pomagajñ zespoäowi zachowaè uczciwoĈè przy prezentowaniu postöpów. Demonstracje iteracji zapewniajñ Pokazy te sñ otwarte dla wszystkich udziaäowców, uczciwoĈè zespoäu. a niektóre firmy zapraszajñ do uczestnictwa w nich nawet klientów zewnötrznych. Trudniej jest poddaè siö pokucie przesuniöcia terminu zakoþczenia iteracji „tylko o jeden dzieþ”, kiedy udziaäowcy oczekujñ prezentacji. Po trzecie, demonstracja to okazja do regularnego uzyskiwania informacji zwrotnych od klientów. Nic nie przemawia do udziaäowców lepiej niĔ dziaäajñce, uĔyteczne oprogramowanie. Demonstracja projektu sprawia, Ĕe postöpy sñ widoczne natychmiast i w konkretnej postaci. Daje to udziaäowcom moĔliwoĈè zrozumienia, co uzyskajñ, i wpäyniöcia na zmianö kierunku prac, jeĈli jest to konieczne. Regularne udostöpnianie jest kluczowe, aby stosowanie XP byäo skuteczne. Demonstracja iteracji to konkretny wskaĒnik postöpów. Kiedy pojawiñ siö problemy z realizacjñ harmonogramu (a zawsze tak siö dzieje), demonstracja iteracji utrudnia unikanie rzeczywistoĈci, a zmierzenie siö z niñ daje okazjö do zarzñdzania problemami.

Jak przeprowadzië demonstracjý iteracji? KaĔdy czäonek zespoäu moĔe przeprowadziè demonstracjö iteracji, jednak zalecam, aby zajmowaä siö tym menedĔer produktu. Osoba ta najlepiej rozumie punkt widzenia udziaäowców i posäuguje siö ich jözykiem. Ponadto prowadzenie prezentacji przez menedĔera produktu podkreĈla jego rolö w wyznaczaniu drogi rozwoju oprogramowania. NaleĔy zaprosiè wszystkie zainteresowane osoby. Caäy zespóä, kluczowi udziaäowcy i wäaĈciciele projektu powinni uczestniczyè w nich tak czösto, jak to moĔliwe. JeĈli to potrzebne, warto zaprosiè takĔe prawdziwych klientów. Mile widziane sñ teĔ inne zespoäy pracujñce w pobliĔu i osoby ciekawe dziaäania XP. JeĈli nie wszyscy mieszczñ siö w pomieszczeniu, moĔna przeprowadziè telekonferencjö lub uĔyè oprogramowania do wspóädzielenia pulpitu. DEMONSTRACJE

TERACJ

167

Demonstrator: Nastöpna opowieĈè dotyczyäa planu podróĔy. Jak juĔ wspomniaäem, musieliĈmy zmieniè tö historiö. MoĔe pamiötacie, Ĕe poczñtkowa wersja miaäa pokazywaè fragmenty trasy przelotu na animowanej kuli ziemskiej. ProgramiĈci mieli pewne wñtpliwoĈci dotyczñce wydajnoĈci, dlatego przeprowadziliĈmy testy i okazaäo siö, Ĕe wyĈwietlanie kuli ziemskiej podwajaäo koszt przygotowania centrum danych. Uczestnik spotkania: Dlaczego byäo to tak drogie? Programista: Wiele animacji jest niepowtarzalnych, dlatego do ich wyĈwietlania potrzebny jest serwer. Wymaga to generowania niestandardowych animowanych obrazów .GIF dla kaĔdego uĔytkownika. PoniewaĔ obraz jest wyĈwietlany w trzech wymiarach, wymaga to duĔo czasu procesora, co oznacza, Ĕe trzeba zakupiè duĔo lepszy sprzöt na potrzeby centrum danych. MoĔna umieĈciè niektóre obrazy .GIF w pamiöci podröcznej, jednak musimy starannie przyjrzeè siö statystykom uĔytkowania, zanim ustalimy, czy takie rozwiñzanie bödzie dziaäaè. Demonstrator: Nie chcieliĈmy poĈwiöcaè zbyt wiele czasu na optymalizacjö wydajnoĈci, a efekt nie byä wart ponoszenia wyĔszych kosztów w obszarze sprzötu. ēaden z konkurentów w ogóle nie ma mapy fragmentów przelotów, dlatego zdecydowaliĈmy, Ĕe prostsza, dwuwymiarowa mapa bödzie wystarczajñco dobra. Jednak poĈwiöciliĈmy juĔ tej opowieĈci sporo pracy i nie mieliĈmy wystarczajñco duĔo czasu na przygotowanie animowanej mapy. Po obejrzeniu efektów [demonstruje] zdecydowaliĈmy, Ĕe na razie sñ one wystarczajñce. Zamierzamy przejĈè do nastöpnych funkcji, zamiast spödzaè wiöcej czasu nad planem podróĔy. Po zakoþczeniu demonstracji naleĔy poinformowaè udziaäowców, Ĕe mogñ sami uruchomiè oprogramowanie. Trzeba umieĈciè pliki instalacyjne w sieci, udostöpniè udziaäowcom serwer lub zastosowaè podobne rozwiñzanie. MoĔna teĔ ukróciè nieistotne dyskusje, kierujñc ludzi do instalacji.

Dwa kluczowe pytania Na zakoþczenie demonstracji naleĔy zadaè wäaĈcicielowi projektu dwa kluczowe pytania7:

1. Czy jest zadowolony z dotychczasowych postöpów? 2. Czy zespóä moĔe kontynuowaè pracö? Te pytania pomagajñ utrzymaè projekt na prawidäowej drodze i przypominajñ wäaĈcicielowi projektu o wyraĔeniu ewentualnych wñtpliwoĈci. Komunikacja z wäaĈcicielem projektu powinna byè na tyle sprawna, Ĕe jego odpowiedzi nigdy nie powinny zaskakiwaè zespoäu.

UWAGA WäaĈciciel projektu zwykle nie uczestniczy we wszystkich demonstracjach, choè jest to wskazane. MoĔna zwiökszyè prawdopodobieþstwo jego uczestnictwa, dbajñc o to, aby demonstracje byäy krótkie. JeĈli wäaĈciciel projektu w ogóle nie bierze w nich udziaäu, menedĔer produktu powinien przynajmniej raz w miesiñcu przeprowadziè prywatnñ demonstracjö i zadaè dwa wspomniane wczeĈniej kluczowe pytania.

7

Dziökujö Joshui Keriewskiemu z organizacji Industrial Logic za przedstawienie mi tej techniki.

DEMONSTRACJE

TERACJ

169

WäaĈciciel projektu moĔe odpowiedzieè na pierwsze pytanie „nie” lub powiedzieè „tak”, ale z wyraĒnym wahaniem. Jest to wyraĒny wskaĒnik informujñcy o wystñpieniu problemów. Po demonstracji trzeba porozmawiaè z wäaĈcicielem projektu i dowiedzieè siö, z czego jest niezadowolony, a nastöpnie natychmiast podjñè dziaäania naprawcze.

UWAGA Czasem wäaĈciciel projektu jest niezadowolony, poniewaĔ chce, aby zespóä pracowaä szybciej. W podrozdziale „Szacowanie” w rozdziale 8. znajdujñ siö wskazówki dotyczñce podnoszenia szybkoĈci. Podrozdziaä „Zarzñdzanie ryzykiem” w tym samym rozdziale zawiera porady dotyczñce postöpowania w sytuacji, kiedy zespóä nie moĔe speäniè oczekiwaþ wäaĈciciela projektu.

Czasem, choè bardzo rzadko, wäaĈciciel projektu odpowie „nie” na drugie pytanie. Taka odpowiedĒ nigdy nie powinna paĈè — oznacza to bardzo powaĔny problem w komunikacji. JeĈli zespóä usäyszy takñ odpowiedĒ, zwykle oznacza to koniec projektu. NaleĔy spotkaè siö z wäaĈcicielem projektu po demonstracji i upewniè siö, Ĕe chce zaprzestania prac. Trzeba go poinformowaè, Ĕe zespóä jest gotów udostöpniè prezentowane w danym dniu rozwiñzanie i potrzebuje ostatniego tygodnia na uporzñdkowanie spraw. NaleĔy spróbowaè ustaliè, co poszäo nie tak, a jeĈli to moĔliwe, zaangaĔowaè wäaĈciciela w retrospekcjö projektu.

Cotygodniowa instalacja jest niezbýdna Demonstracja iteracji to nie tylko zwykäy pokaz. Jest to sposób na udowodnienie, Ĕe zespóä w kaĔdej iteracji robi prawdziwe postöpy. Zawsze naleĔy udostöpniaè obecne wydanie, aby udziaäowcy mogli sami wypróbowaè je po demonstracji. Warto przygotowaè wydanie demonstracyjne nawet wtedy, jeĈli udziaäowcy nie sñ zainteresowani jego przetestowaniem. Dziöki sprawnej automatycznej kompilacji przygotowanie wydania powinno zajñè tylko chwilö. JeĈli zespóä nie potrafi tego zrobiè, moĔe to byè oznakñ problemów w projekcie. Jednym z najwiökszych zagroĔeþ w planowaniu rozwoju oprogramowania jest pomijanie czasu miödzy „skoþczyliĈmy” a „udostöpniliĈmy”. Zespoäy czösto potrzebujñ po upäyniöciu terminu kilku dodatkowych tygodni (lub miesiöcy), aby dopracowaè kompilacjö produktu i umoĔliwiè jego rozpowszechnianie. Udostöpnianie dziaäajñcej wersji demonstracyjnej w kaĔdej iteracji zmniejsza to ryzyko. JeĈli zespóä tworzy nowy kod bazowy, powinien upewniè siö, Ĕe moĔna go zainstalowaè w trakcie kaĔdej iteracji. Pomaga to zapobiegaè powstawaniu däugu technicznego. Tygodniowy rytm demonstracji iteracji i przygotowywania wydaþ dla udziaäowców doskonale nadaje siö do utrzymania kodu w stanie umoĔliwiajñcym jego udostöpnianie. Rozdziaä 7. opisuje, jak stosowaè te praktyki. JeĈli grupa musi pracowaè nad odziedziczonym kodem bazowym, na poczñtku cotygodniowa instalacja moĔe byè niemoĔliwa. System kompilacji jest zwykle niekompletny, a zespóä czösto nie ma odpowiedniego Ĉrodowiska demonstracyjnego lub nie przygotowaä jeszcze instalatora. Takie problemy oznaczajñ wysoki däug techniczny. Podrozdziaä „Stosowanie XP do istniejñcych projektów” w rozdziale 4. zawiera wskazówki pomocne w rozwiñzaniu tego problemu przy jednoczesnym zapewnieniu zadowolenia udziaäowców.

170

ROZDZ AĤ 6

WSPÓĤPRACA

Inne moŜliwoļci Demonstracja iteracji to wyraĒny wskaĒnik zdolnoĈci zespoäu do udostöpniania oprogramowania. Grupa albo potrafi zademonstrowaè nowe funkcje kaĔdego tygodnia, albo tego nie potrafi. WäaĈciciel projektu albo daje zezwolenie na kontynuacjö prac, albo nie. Nie znam Ĕadnych innych rozwiñzaþ, które zapewniajñ tak wartoĈciowe informacje zwrotne. Niektóre zespoäy udostöpniajñ pod koniec kaĔdej iteracji peäne wydanie, a nie demonstracjö. JeĈli grupa potrafi to zrobiè, jest to doskonaäy dodatek do omawianej praktyki.

DEMONSTRACJE

TERACJ

173

Raporty

Odb orcy

Wzbudzamy zaufanie do decyzji zespoäu.

Coachowie wyŜsza kad a za zédzajéca

KaĔda osoba to czöĈè caäego zespoäu. Wszyscy pracujñ wspólnie. Informacyjne miejsce pracy pozwala Ĉledziè postöpy. Wszystkie potrzebne dane sñ na wyciñgniöcie röki. Po co w takim razie uĔywaè raportów? Tak naprawdö zespóä ich nie potrzebuje. Sñ one przeznaczone dla osób, które nie wchodzñ w skäad grupy, przede wszystkim dla wyĔszej kadry zarzñdzajñcej i udziaäowców. Ci ludzie duĔo zainwestowali w zespóä i w projekt, dlatego chcñ wiedzieè, jak przebiegajñ prace.

Rodzaje raportów Raporty o postöpach sñ dokäadnie tym, na co wskazuje nazwa: informujñ o postöpach zespoäu. Sñ to na przykäad demonstracje iteracji i plany wydaþ. Choè moĔe siö wydawaè, Ĕe raporty o postöpach säuĔñ temu, aby udziaäowcy mogli Ĉledziè i zmieniaè kierunek pracy zespoäu, nie takie jest ich przeznaczenie. Dobre raporty tego typu pozwalajñ udziaäowcom zaufaè decyzjom zespoäu. Raporty dla zarzñdu sñ przeznaczone dla wyĔszej kadry zarzñdzajñcej. Udostöpniajñ informacje wysokiego poziomu, które umoĔliwiajñ zarzñdowi analizö trendów i wyznaczanie celów. Nie sñ to dane, które moĔna uzyskaè, spacerujñc po otwartym pomieszczeniu roboczym przez godzinö lub dwie kaĔdego miesiñca. Obejmujñ one trendy w wydajnoĈci i liczbie bäödów. Które raporty sñ niezbödne do zbudowania zaufania i zaspokojenia strategicznych potrzeb? To zaleĔy od udziaäowców. Niektórzy nie angaĔujñ siö w pracö zespoäu i chcñ jedynie ujrzeè postöpy na drodze w kierunku celu. Inni chcñ poznaè wiöcej szczegóäów, aby poszerzyè wiedzö. MoĔliwe, Ĕe potrzebne bödzie przygotowanie kilku raportów dla róĔnych odbiorców. NaleĔy jednak zachowaè ostroĔnoĈè. Tworzenie raportów zabiera czas i energiö potrzebne na wytwarzanie, dlatego nie warto tworzyè wszelkich moĔliwych raportów. Wystarczy przygotowaè ich tyle, aby zaspokoiè potrzeby kluczowych udziaäowców. MenedĔer projektu i menedĔer produktu powinni poäñczyè swe informacje na temat udziaäowców i ustaliè odpowiedni poziom raportów. Najlepszy sposób, aby go poznaè, to — oczywiĈcie — zapytaè. Spektrum moĔliwych raportów ogranicza tylko wyobraĒnia zespoäu. PoniĔszy punkt zawiera opis szczególnie przydatnych raportów, a takĔe narzödzi z drugiego kraþca skali, czyli raportów czösto uĔywanych, ale — moim zdaniem — maäo wartoĈciowych. Pierwszy zestaw obejmuje standardowe efekty uboczne pracy zespoäu. Za pozostaäe zwykle odpowiada menedĔer projektu, choè niezbödny jest wkäad takĔe innych czäonków zespoäu.

Podstawowe raporty o postýpach Zespoäy w XP majñ znacznñ przewagö w obszarze tworzenia raportów o postöpach, poniewaĔ co tydzieþ czyniñ obserwowalne postöpy, dziöki czemu nie trzeba zgadywaè ich poziomu. Ponadto w zespoäach stosujñcych XP niektóre raporty o postöpach to standardowe efekty uboczne codziennej pracy. Przydatne oraz za darmo? Cztery poniĔsze raporty majñ same zalety.

174

ROZDZ AĤ 6

WSPÓĤPRACA

Listy elektroniczne z opisem stanu Cotygodniowe listy elektroniczne z opisem stanu projektu mogñ uzupeäniaè demonstracje iteracji. Lubiö zamieszczaè w nich listö opowieĈci ukoþczonych w kaĔdej iteracji i ich wartoĈè. Ponadto doäñczam obecne szacunki prawdopodobnego zakresu funkcji i daty ukoþczenia oraz wyjaĈniam wszelkie zmiany, jakie zaszäy od czasu ostatniego raportu. JeĈli zespóä dodaä opowieĈci do harmonogramu lub usunñä je z niego, takĔe powinien wyjaĈniè, dlaczego tak siö staäo. Uczciwa ocena wäasnej pracy to jeden z aspektów precyzyjnego raportu o stanie.

Dodatkowe raporty dla zarzédu Podczas gdy raporty o postöpach pokazujñ, Ĕe zespóä realizuje cele, raporty dla zarzñdu demonstrujñ dobrñ pracö grupy. Te raporty, podobnie jak raporty o postöpach, naleĔy przygotowywaè tylko wtedy, kiedy sñ potrzebne.

Wydajnoļë WydajnoĈè procesu rozwoju oprogramowania jest trudna w pomiarze [Fowler 2003]. Wydaje siö, Ĕe powinno to byè proste — wydajnoĈè to iloĈè wyprodukowanych dóbr podzielona przez czas — jednak w przypadku oprogramowania nie ma obiektywnego sposobu na pomiar poziomu produkcji. Jaki jest rozmiar funkcji?

UWAGA MoĔna zmierzyè wielkoĈè oprogramowania, liczñc punkty funkcyjne lub wiersze kodu, jednak przypomina to pomiar funkcjonalnoĈci telefonów komórkowych w centymetrach szeĈciennych.

Zamiast próbowaè zmierzyè funkcje, naleĔy ustaliè wpäyw zespoäu na organizacjö. MoĔna uĔyè do tego obiektywnych miar wartoĈci, na przykäad zwrotu z inwestycji. MoĔna posäuĔyè siö przy tym przychodami, oszczödnoĈciami lub innymi wartoĈciowymi wynikami. Ustalenie obiektywnej miary wartoĈci to najtrudniejsza rzeczy przy tworzeniu raportów o wydajnoĈci. Nie potrafiö podaè konkretnych wskazówek w tym obszarze, poniewaĔ wskaĒniki zaleĔñ od tego, co jest waĔne dla danej organizacji. Pomóc w utworzeniu miar mogñ menedĔer produktu i wyĔsza kadra zarzñdzajñca. Po wyborze miary naleĔy Ĉledziè jej wartoĈè w kaĔdej iteracji. Do momentu wypuszczenia oprogramowania w wersji produkcyjnej poziom bödzie spadaè coraz bardziej poniĔej zera. Poczñtkowo zespóä generuje koszty, a nie daje zysków. Po udostöpnieniu programu trend powinien siö zmieniè. Czösto säyszö narzekania, Ĕe miara ta znajduje siö czöĈciowo poza kontrolñ zespoäu. Co siö stanie, jeĈli dziaä sprzedaĔy nie sprzeda oprogramowania lub uĔytkownicy biznesowi nie bödñ zainteresowani korzystaniem z niego? Sñ to säuszne obawy, jednak nie uwzglödniajñ tego, czym tak naprawdö jest sukces organizacji. Aby zespóä osiñgnñä powodzenie w tym obszarze, a nie tylko sukces techniczny, oprogramowanie musi mieè wartoĈè biznesowñ. Opisana miara wydajnoĈci to uwzglödnia.

176

ROZDZ AĤ 6

WSPÓĤPRACA

Rysunek 6.5. Przykäadowy arkusz kontroli czasu

Nastöpnie naleĔy nanieĈè na wykres äñczny czas spödzony na zadaniach z kaĔdej kategorii. „Wytwarzanie” powinno znaleĒè siö na dole diagramu, a „Nieznane” — u góry. Pierwszñ kategoriö oznaczam na biaäo, drugñ na Ĕóäto, a trzy ostatnie — na zielono (rysunek 6.6).

Rysunek 6.6. Raport na temat wykorzystania czasu

Po przygotowaniu raportu udziaäowcy wciñĔ mogñ siö zastanawiaè, dlaczego szybkoĈè nie odpowiada potrzebnym nakäadom pracy. NaleĔy wyjaĈniè, Ĕe szybkoĈè jest skalowana z uwagi na bäödy w szacunkach i koszty ogólne. Wiöcej informacji na ten temat zawiera punkt „ObjaĈnianie szacunków” w rozdziale 8.

Raporty, których naleŜy unikaë Niektóre raporty, choè czösto uĔywane, nie udostöpniajñ wartoĈciowych informacji. Podrozdziaä „Szacowanie” w rozdziale 8. zawiera wskazówki zwiñzane z objaĈnianiem szacunków i szybkoĈci.

178

ROZDZ AĤ 6

WSPÓĤPRACA

UWAGA JeĈli udziaäowcy poproszñ o jeden z tych raportów, nie naleĔy od razu odmawiaè. Warto dowiedzieè siö, do czego potrzebujñ danego raportu, i ustaliè, czy nie moĔna zaspokoiè ich potrzeb w lepszy sposób.

Liczba wierszy kodu Śródĥowego (SLOC) i punkty funkcyjne Liczba wierszy kodu Ēródäowego (ang. source lines of code — SLOC) i zbliĔony wskaĒnik niezaleĔny od jözyka, punkty funkcyjne, to czösto stosowane miary wielkoĈci oprogramowania. Niestety, nieraz säuĔñ takĔe do pomiaru wydajnoĈci. Jednak podobnie jak w wymyĈlnych telefonach komórkowych, wielkoĈè oprogramowania nie zawsze odpowiada jego funkcjonalnoĈci lub wartoĈci. Dobrze zaprojektowany kod skäada siö z moduäów. Uäatwia to doäñczanie wielu funkcji bez powielania kodu. Im lepszy projekt, tym mniej powtórzeþ, a co za tym idzie — mniej wierszy kodu. Staranne przygotowanie projektu wymaga czasu i wysiäku, jednak prowadzi do mniejszej liczby bäödów i äatwiejszej konserwacji. Informowanie o SLOC (lub o punktach funkcyjnych) zachöca zespóä do wytwarzania kaĔdego dnia Informowanie o SLOC sprzyja wiökszej liczby wierszy kodu. Zamiast zwiökszaè powstawaniu usterek wydajnoĈè, zespóä prawdopodobnie bödzie spödzaä i wzrostowi kosztów. mniej czasu na projektowaniu pod kñtem jakoĈci. WskaĒnik SLOC wzroĈnie, to prawda, jednak jednoczeĈnie spadnie jakoĈè projektu. Badania pokazujñ, Ĕe im wiöcej wierszy kodu ma program, tym prawdopodobnie wiöcej bäödów bödzie zawieraä, a koszt jego rozwoju bödzie wyĔszy. SLOC i punkty funkcyjne nie sñ dobrymi wskaĒnikami wydajnoĈci. Mogñ byè przydatne do koþcowego porównania projektu ze Ĉrednimi branĔowymi, jednak naleĔy unikaè podawania ich w cotygodniowych raportach.

Liczba opowieļci Niektórzy uwaĔajñ, Ĕe miarñ wydajnoĈci moĔe byè liczba opowieĈci udostöpnionych w kaĔdej iteracji. Nie naleĔy stosowaè tego rozwiñzania. OpowieĈci nie majñ nic wspólnego z produktywnoĈciñ. Zespóä o standardowej wielkoĈci zwykle w kaĔdej iteracji rozwija od 4 do 10 opowieĈci. Aby osiñgnñè ten cel, trzeba czasem äñczyè opowieĈci lub dzieliè je na mniejsze fragmenty. Dobrze pracujñcy zespóä niezaleĔnie od wydajnoĈci rozwija staäñ liczbö opowieĈci na iteracjö.

Szybkoļë JeĈli zespóä z góry szacuje liczbö opowieĈci, poprawa szybkoĈci moĔe wynikaè ze wzrostu wydajnoĈci. Nigdy nie naleĔy porównywaè Niestety, nie ma sposobu na odróĔnienie zmian szybkoĈci róĔnych zespoäów. w produktywnoĈci od niespójnych szacunków. MoĔna teĔ sztucznie zawyĔyè szybkoĈè, zaciñgajñc däug techniczny, dlatego gorñco zalecam, aby nie stosowaè szybkoĈci jako miary wydajnoĈci.

RAPORTY

179

Przede wszystkim jednak nigdy nie naleĔy porównywaè szybkoĈci róĔnych zespoäów. Poszczególne grupy stosujñ odmienne sposoby szacowania. WartoĈci szybkoĈci w róĔnych zespoäach nie majñ ze sobñ nic wspólnego.

UWAGA Pomiar zmiennoĈci szybkoĈci moĔe dawaè ciekawe informacje, które warto omówiè w czasie retrospekcji (zobacz podrozdziaä „Retrospekcje” w rozdziale 5.), jednak dane te sñ zbyt wieloznaczne, aby uĔywaè ich w zewnötrznych raportach.

Jakoļë kodu Przy ocenie jakoĈci kodu nie da siö zastñpiè doĈwiadczenia programistów. Stosowane miary jakoĈci kodu, na przykäad zäoĔonoĈè cyklomatyczna, wymagajñ interpretacji przez eksperta. Nie ma zestawu miar, które jednoznacznie okreĈlajñ jakoĈè projektu lub kodu. Te wskaĒniki jedynie wskazujñ obszary, które wymagajñ wiöcej uwagi. NaleĔy unikaè umieszczania w raportach miar jakoĈci. Sñ one uĔytecznym narzödziem dla programistów, jednak sñ zbyt wieloznaczne, aby informowaè o nich udziaäowców.

Pytania Co oznacza stwierdzenie, Ĕe „Raporty o postöpach säuĔñ wzbudzaniu zaufania u udziaäowców”? Czy nie powinniĈmy informowaè w nich takĔe o tym, Ĕe potrzebujemy pomocy w pewnych aspektach? OczywiĈcie. Jednak raporty o postöpach dotyczñ stanu projektu. Nie naleĔy zakäadaè, Ĕe ktokolwiek je czyta. Czasem sama ich obecnoĈè wystarcza, aby udziaäowcy byli pewni, Ĕe zespóä jest na dobrej drodze. Kiedy zespóä potrzebuje pomocy udziaäowców, na przykäad chce lepiej poznaè priorytety biznesowe lub przezwyciöĔyè przeszkody, powinien o niñ poprosiè. Nie naleĔy liczyè na to, Ĕe udziaäowcy wykryjñ potrzeby grupy w trakcie lektury raportu.

JeĈli potrzebna jest pomoc, naleĔy bezpoĈrednio porozmawiaè z udziaäowcami.

Co zrobiè, jeĈli niektórzy udziaäowcy chcñ bezpoĈrednio zarzñdzaè zespoäem? MenedĔer produktu i menedĔer projektu powinni poradziè sobie z udziaäowcami. Zadaniem tych menedĔerów jest udostöpnianie udziaäowcom wszelkich potrzebnych materiaäów, a jednoczeĈnie ochrona zespoäu przed wtrñcaniem siö w ich pracö. Muszñ byè taktowni, ale zdecydowani. Czy nie jest to po prostu marnowanie czasu? Mamy informacyjne miejsce pracy, krótkie spotkania robocze i demonstracje iteracji. Udziaäowcy i menedĔerowie mogñ zawsze w nich uczestniczyè. Dlaczego wymagajñ dodatkowych raportów? JeĈli udziaäowcy uczestniczñ w spotkaniach oraz sñ one dla nich wystarczajñco wartoĈciowe, prawdopodobnie raporty nie sñ konieczne. W takiej sytuacji menedĔer projektu moĔe porozmawiaè z udziaäowcami o rezygnacji ze zbödnych raportów.

180

ROZDZ AĤ 6

WSPÓĤPRACA

Jednak do tego momentu nie naleĔy zakäadaè, Ĕe pisanie solidnego kodu, udostöpnianie dziaäajñcego oprogramowania i speänianie prawdziwych potrzeb biznesowych sprawi, iĔ wszyscy doceniñ wartoĈè zespoäu. Czasem wystarczy doäñczyè stronö tytuäowñ do raportu TPS, aby zadowoliè udziaäowców. Co zrobiè, jeĈli programiĈci nie chcñ kontrolowaè czasu wykonywania zadaþ na potrzeby raportów o wykorzystaniu czasu? Mówiñ, Ĕe majñ waĔniejsze zadania do wykonania. Majñ racjö — kontrola czasu to zbödna czynnoĈè. Jednak zespóä musi znaleĒè równowagö miödzy zapewnieniem zadowolenia udziaäowców a dobrym wykorzystaniem czasu. MoĔna uäatwiè programistom akceptacjö tej czynnoĈci. Po pierwsze, nie naleĔy odgórnie narzucaè im tego zadania. W zamian warto omówiè powody przygotowywania raportów przez zespóä i wspólnie uzgodniè, które sprawozdania grupa bödzie udostöpniaè. NaleĔy pamiötaè, Ĕe niektórzy czäonkowie zespoäu majñ wiöksze praktyczne doĈwiadczenie od innych i potrafiñ lepiej przewidzieè skutki udostöpniania pewnych raportów lub rezygnacji z nich. Po drugie, trzeba zrobiè wszystko, co moĔliwe, aby kontrola czasu nie byäa zbyt duĔym obciñĔeniem. Kiedy przychodzi pora na przygotowanie raportu, menedĔer projektu powinien sam poäñczyè dane, zamiast prosiè o to programistów. Dlaczego to menedĔer projektu ma wykonywaè caäñ ciöĔkñ pracö zwiñzanñ z raportami? Nie moĔe zleciè tego zadania komuĈ innemu? Zadaniem menedĔera projektu jest pomaganie zespoäowi w päynnej pracy. Nigdy nie powinien zwiökszaè obciñĔenia osób zajmujñcych siö kluczowymi zadaniami. Powinien natomiast usuwaè przeszkody, a raporty to jedna z nich. Nasza organizacja ocenia pracowników indywidualnie na podstawie treĈci pewnych raportów. Co robiè? Zespoäy w XP wykonujñ zadania grupowo, a nie indywidualnie, dlatego jest to trudna sytuacja. Przede wszystkim menedĔer projektu powinien omówiè zasady oceny z dziaäem kadr i wyĔszñ kadrñ zarzñdzajñcñ. JeĈli proces oceny jest elastyczny, naleĔy to wykorzystaè. JeĈli brakuje elastycznoĈci, trzeba jak najlepiej wykorzystaè moĔliwoĈci, jakie daje proces przeglñdu. NaleĔy na kaĔdym kroku podkreĈlaè pracö zespoäowñ. Kiedy grupa rozwija szczególnie wartoĈciowñ funkcjö, trzeba pamiötaè o tym, aby wspomnieè o wkäadzie kaĔdego czäonka zespoäu.

Efekty Dziöki odpowiednim raportom udziaäowcy zaczynajñ ufaè, Ĕe zespóä dobrze pracuje. Z czasem raporty stanñ siö mniej potrzebne, a zespóä bödzie mógä przekazywaè mniej informacji i rzadziej.

Przeciwwskazania Czas spödzany nad rozwojem raportów to czas, którego nie moĔna poĈwiöciè na wytwarzanie. Z technicznego punktu widzenia sprawozdania to strata czasu, poniewaĔ nie przyczyniajñ siö do postöpów w rozwoju. Dlatego dñĔö do przygotowywania jak najmniejszej liczby raportów.

RAPORTY

181

Skomputeryzowane planowanie na pozór uäatwia przygotowywanie raportów. Niestety, dzieje siö to kosztem grupowego, dynamicznego planowania (zobacz podrozdziaä „Gra planistyczna” w rozdziale 8.) i informacyjnego miejsca pracy. Jest to niekorzystne podejĈcie, poniewaĔ optymalizuje zbödne zadania kosztem produktywnych czynnoĈci.

Nie naleĔy pozwoliè, aby raporty zniweczyäy korzyĈci z planowania opartego na karteczkach.

Aby uniknñè röcznego przygotowywania raportów, wykorzystujö demonstracjö iteracji, plansze z planami oraz wykresy wykonanych zadaþ i kiedy tylko to moĔliwe, uĔywam ich jako jedynych sprawozdaþ. Sñ to standardowe produkty procesu, a ich przygotowanie nie wymaga dodatkowej pracy. JeĈli to konieczne, uĔywam kamer internetowych i aparatów cyfrowych do rozpowszechniania plansz. Nie lubiö raportów o wykorzystaniu czasu, poniewaĔ ich przygotowanie jest czasochäonne, a programiĈci nie przepadajñ za zbieraniem danych, jednak zwykle jestem zmuszony do ich udostöpniania. Choè tworzö je tylko wtedy, kiedy wyczuwam u waĔnych udziaäowców obawy dotyczñce szybkoĈci zespoäu, sñ one powszechne w organizacjach, które nie znajñ XP. Warto mniej wiöcej raz na miesiñc ponownie oceniè tö potrzebö i zakoþczyè przygotowywanie raportów na temat wykorzystania czasu, kiedy tylko przestanñ byè niezbödne.

Inne moŜliwoļci Czösto komunikowanie siö moĔe zastñpiè formalne raporty. Jest to lepsze rozwiñzanie i warto je stosowaè, jeĈli wystñpi taka moĔliwoĈè.

Dalsza lektura KsiñĔka Why Does Software Cost So Much? [DeMarco 1995] zawiera esej zatytuäowany „Mad About Measurement”, który opisuje trudnoĈci w pomiarze wydajnoĈci oraz obejmuje krótkie omówienie wyników informowania o cyklomatycznej zäoĔonoĈci kodu. Artykuä Cannot Measure Productivity [Fowler 2003] zawiera bardziej szczegóäowe niĔ przedstawione w tym rozdziale omówienie trudnoĈci w pomiarze wydajnoĈci rozwoju oprogramowania (http://www.martinfowler.com/bliki/CannotMeasureProductivity.html).

182

ROZDZ AĤ 6

WSPÓĤPRACA

ROZDZIAĤ 7

Udostýpnianie

Jaka jest wartoĈè kodu? ProgramiĈci stosujñcy zwinne podejĈcie ceniñ „dziaäajñce oprogramowanie bardziej niĔ wyczerpujñcñ dokumentacjö”1. Czy to oznacza, Ĕe dokumentacja wymagaþ jest bezwartoĈciowa? Czy wynika z tego, Ĕe nieukoþczony kod nie jest cenny? Kod, podobnie jak skaäa na wierzchoäku wzgórza, ma potencjaä. W przypadku skaäy jest to potencjalna energia, a w przypadku kodu — potencjalna wartoĈè. Wykorzystanie tego potencjaäu wymaga impulsu. Skaäö trzeba spuĈciè po stoku, aby zyskaäa energiö kinetycznñ. Oprogramowanie trzeba udostöpniè w Ĉrodowisku produkcyjnym, aby zyskaäo wartoĈè. ãatwo ustaliè iloĈè energii potrzebnñ do poruszenia skaäy. JeĈli kamieþ jest duĔy, trzeba pchnñè go mocno. JeĈli maäy — lĔej. Rozwój oprogramowania jest bardziej skomplikowany. Program czösto wyglñda na gotowy na däugo przed jego faktycznym ukoþczeniem. Wedäug moich doĈwiadczeþ zespoäy nie doceniajñ trudnoĈci zwiñzanych z udostöpnieniem oprogramowania w Ĉrodowisku produkcyjnym. Dodatkowñ komplikacjñ jest zmienna potencjalna wartoĈè oprogramowania. JeĈli nic nie poruszy skaäy, ta na zawsze pozostanie na wierzchoäku wzgórza, a jej potencjalna energia nie zmieni siö. Z kolei oprogramowanie znajduje siö na pagórku, którego uksztaätowanie caäy czas siö zmienia. Zwykle moĔna stwierdziè, kiedy wzgórze przechodzi w dolinö, jednak jeĈli udostöpnienie oprogramowania wymaga tygodni lub miesiöcy, w momencie uruchomienia programu moĔe siö on znajdowaè we wgäöbieniu. Aby zrealizowaè zobowiñzania i wykorzystaè nadarzajñce siö okazje, niezbödna jest moĔliwoĈè udostöpnienia oprogramowania w wersji produkcyjnej w przeciñgu kilku minut. Ten rozdziaä zawiera szeĈè praktyk, dziöki którym wydania wymagajñce mocnego pchniöcia moĔna udostöpniaè przy uĔyciu dziesiöciominutowego klepniöcia: x „Peäna gotowoĈè” zapewnia, Ĕe ukoþczony kod jest gotowy do udostöpnienia. x Brak bäödów umoĔliwia udostöpnianie oprogramowania bez odröbnego etapu testów. x Kontrola wersji pozwala czäonkom zespoäu na wspólnñ pracö bez przeszkadzania sobie

nawzajem. 1

Manifest zwinnoĈci, http://www.agilemanifesto.org/ (wersja angielska).

183

x Dziesiöciominutowa kompilacja umoĔliwia przygotowanie przetestowanego wydania

w mniej niĔ dziesiöè minut. x Ciñgäa integracja zapobiega däugiej, ryzykownej fazie integracji. x WspóäwäasnoĈè kodu pozwala zespoäowi rozwiñzywaè problemy niezaleĔnie od miejsca

ich wystöpowania. x Rozwój dokumentacji po ukoþczeniu zadania zmniejsza koszty jej przygotowania i zwiöksza

dokäadnoĈè.

MINI WPRAWKA Z „UDOSTüPNIANIA” Ce em tej wprawk jest poznan e procesu udostýpn an a oprogramowan a w wersj produkcyjnej Jeļ zespóĥ dop ero poznaje zw nne wytwa zan e oprogramowan a, moŜe uŜyë tego ëw czen a do utworzen a mapy wszystk ch kroków pot zebnych do udostýpn en a oprogramowan a, nawet jeļ obecn e n e stosuje XP Doļw adczen uŜytkown cy zw nnego podejļc a mogé p zej zeë rozdz aĥ 13 uŜyë tej wprawk jako na zýdz a pomocn czego przy modyf kowan u procesu pod kétem usun ýc a wésk ch gardeĥ w komun kacj Na eŜy ëw czyë tý wprawký p zez póĥ godz ny kaŜdego dn a do momentu, k edy da sze jej wykonywan e p zestan e dawaë efekty Na poczétku zm eszczen e s ý w term n e moŜe spraw aë prob emy Jeļ wprawka stan e s ý nudna, na eŜy zastanow ë s ý, jak wprowadz ë zm any, które jé oŜyw é Potrzebne býdé cze wone z e one karteczk , pusty stóĥ ub tab ca magnetyczna na mapý strumienia wartoļci2 narzýdz a do p san a d a wszystk ch Krok 1. Podz aĥ zespoĥu na zróŜn cowane pary — program sta pow n en pracowaë z k entem, k ent z testerem tak da ej KaŜdego dn a na eŜy zm en aë partnerów Krok 2. NaleŜy ograniczyë go do 10 minut. W parach na eŜy zastanow ë s ý nad wszystk m czynnoļc am , które t zeba wykonaë m ýdzy wymyļ en em pomysĥu a zrea zowan em go udostýpn en em koħcowym uŜytkown kom ub k entom Na eŜy czyë teracjý jako jedné czynnoļë zgrupowaë razem wszystk e zadan a, które zajmujé mn ej n Ŝ dz eħ Czynnoļc é jest teŜ czas spýdzony na oczek wan u Jeļ para n e moŜe wymyļ ë n c nowego, moŜe wybraë jedné z stn ejécych karteczek p zejļë do kroku 3 Na eŜy wybraë przynajmn ej jedno zadan e zap saë je na czerwonej karteczce Uczestn cy pow nn przypomn eë sob e wszystk e momenty, w któ ych wykonywa dané czynnoļë Jeļ udostýpn a oprogramowan e, pow nn op eraë s ý na doļw adczen u, a n e domn eman ach e czasu zajýĥo wykonan e zadan a? Na eŜy myļ eë w kategor ach czasu ka enda zowego, a n e godz n pracy Uczestn cy pow nn zap saë na karteczkach t zy wa toļc najkrótszy zapam ýtany czas wykonan a zadan a, czas najdĥuŜszy typowy ( ysunek 7 1)

Rysunek 7.1. Przykäadowa karteczka

2

Inspiracjñ do utworzenia mapy strumienia wartoĈci byäa ksiñĔka [Poppendieck i Poppendieck].

184

ROZDZ AĤ 7

UDOSTüPN AN E

Krok 3. NaleŜy ograniczyë go do 10 minut. Omaw an e sposobów, których zespóĥ moŜe uŜyë do skrócenia czasu pot zebnego na dané czynnoļë ub caĥkow tego jej wyeliminowania Na eŜy wybraë jeden pomysĥ zap saë go na zielonej karteczce Krok 4. NaleŜy ograniczyë go do 15 minut. Zespoĥowe omaw an e ka teczek um eszczan e ch na sto e ub tab cy na map e strum en a wartoļc Na eŜy um eļc ë poczétkowe czynnoļc (cze wone ka teczk ) przed tym , które sé wykonywane póŚn ej ( ysunek 7 2) Jeļ zespóĥ uŜywa tab cy, moŜe narysowaë strzaĥk m ýdzy karteczkam , aby p zepĥyw prac byĥ bardz ej wyraŚny Z e one ka teczk na eŜy um eļc ë pod cze wonym

Rysunek 7.2. Przykäadowa mapa strumienia wartoĈci Warto p zedyskutowaë odpow edz na nastýpujéce pytan a x W którym kroku wystýpuje sp ýtrzen e prac? x Które wyn k zaskakujé zespóĥ? x Kto jest ogran czen em w caĥym system e? Jak moŜna usprawn ë funkcjonowan e caĥego systemu? x Czy na z e onych karteczkach znajdujé s ý pomysĥy, które moŜna zrea zowaë od razu?

„W PEĤN

GOTOWE”

185

„W peĥni gotowe” SkoþczyliĈmy, kiedy gotowy jest kod w wersji produkcyjnej.

Odb orcy Ca y zespóĥ

„Hej, Eliza!” — Rebeka wetknöäa gäowö do biura Elizy. „Czy skoþczyäaĈ juĔ tö nowñ funkcjö?”. Eliza skinöäa gäowñ. „Poczekaj sekundkö” — powiedziaäa, nie przerywajñc pisania. Rytm wciĈniöè klawiszy przyspieszyä, a nastöpnie nagle siö urwaä. „Gotowe!” — Eliza obróciäa siö, aby spojrzeè na Rebekö. „Zajöäo mi to tylko póä dnia”. „NieĒle, to robi wraĔenie” — stwierdziäa Rebeka. „ZakäadaliĈmy, Ĕe zajmie to przynajmniej dzieþ, a moĔe nawet dwa. Mogö rzuciè okiem na program?”. „Raczej nie” — odpowiedziaäa Eliza. „Jeszcze nie zintegrowaäam nowego kodu”. „W porzñdku” — powiedziaäa Rebeka. „Jednak kiedy to zrobisz, pozwolisz mi na to spojrzeè, prawda? Nie mogö siö doczekaè, kiedy pokaĔö rozwiñzanie naszym nowym klientom. Wybrali nas przede wszystkim z uwagi na tö funkcjö. Zainstalujö nowñ wersjö w ich Ĉrodowisku testowym, aby mogli jñ wypróbowaè”. Eliza zmarszczyäa brwi. „Na razie lepiej nie pokazywaè nikomu tego rozwiñzania. Jeszcze go nie przetestowaäam. Ponadto nie moĔna go zainstalowaè — nie zaktualizowaäam do tej pory instalatora ani skryptu generujñcego schemat bazy danych”. „Nie rozumiem” — zdziwiäa siö Rebeka. „PowiedziaäaĈ, Ĕe juĔ skoþczyäaĈ”. „Bo tak jest” — z uporem stwierdziäa Eliza. „Skoþczyäam pisaè kod, kiedy przyszäaĈ. ChodĒ, pokaĔö ci”. „Nie, nie — nie muszö oglñdaè kodu” — odpowiedziaäa Rebeka. „Chcö móc pokazaè program klientom. Potrzebujö skoþczonego rozwiñzania. Naprawdö skoþczonego”. „Dlaczego od razu nie powiedziaäaĈ?” — zdziwiäa siö Eliza. „Funkcja jest gotowa — napisaäam caäy kod. Po prostu rozwiñzanie nie jest jeszcze w peäni gotowe. Daj mi kilka dni”.

Oprogramowanie w wersji produkcyjnej Czy nie byäoby wygodnie, gdyby zespóä po ukoþczeniu opowieĈci nigdy nie musiaä do niej wracaè? Na takiej wizji opiera siö praktyka „w peäni gotowe”. Kompletna opowieĈè to nie zbiór niezintegrowanego i nieprzetestowanego kodu, ale rozwiñzanie gotowe do zainstalowania.

Pod koniec kaĔdej iteracji powinna byè moĔliwa instalacja oprogramowania.

CzöĈciowo ukoþczone opowieĈci prowadzñ do wzrostu ukrytych kosztów. Kiedy przychodzi pora na udostöpnienie rozwiñzania, zespóä musi wykonaè trudnñ do oszacowania pracö. Zakäóca to wysiäki zwiñzane z planowaniem wydaþ i utrudnia realizacjö zobowiñzaþ. Aby uniknñè tych problemów, trzeba siö upewniè, Ĕe wszystkie planowane opowieĈci sñ „w peäni gotowe” pod koniec kaĔdej iteracji. W tym momencie powinno byè moĔliwe zainstalowanie oprogramowania, choè zwykle zespóä czeka z tym do rozwiniöcia wiökszego zestawu funkcji.

186

ROZDZ AĤ 7

UDOSTüPN AN E

Brak bĥýdów Bez obaw udostöpniamy oprogramowanie, nie stosujñc przy tym odröbnej fazy testowania.

Odb orcy Ca y zespóĥ

Jak wyglñda przepis na ciasto z bäödami? Najpierw naleĔy wybraè äadny, trudny jözyk, na przykäad C, i przyprawiè go szczyptñ assemblera. Nastöpnie trzeba dodaè nastöpne bäödy, wprowadzajñc programowanie wielowñtkowe. Starzy przyjaciele Bezpieczeþstwo i ēywotnoĈè przeĈcigajñ siö w zwiökszaniu liczby usterek. Przez lata zapewniali bäödy w bibliotekach jözyka Java przeznaczonych do obsäugi wielowñtkowoĈci. Teraz potrzebna jest naprawdö wymagajñca dziedzina problemowa. MoĔe systemy wbudowane dziaäajñce w czasie rzeczywistym? W przepisie na katastrofö nie moĔe zabraknñè programistów odpowiedniego typu. Zobaczmy, co tu mamy. Eksperci? Nie. Starsi programiĈci? Nie. O, jest — nowicjusze! To wäaĈnie jest potrzebne. NaleĔy zebraè wszystkie skäadniki — jözyk C, systemy wbudowane dziaäajñce w czasie rzeczywistym, wielowñtkowoĈè i poczñtkujñcych programistów — dodaè nieco assemblera, dobrze wymieszaè i gotowaè przez trzy lata (uwielbiam ciasto z bäödami). A oto skutki zastosowania tego przepisu: Zespóä z firmy GMS udostöpniä produkt po trzech latach rozwoju [60638 wierszy kodu], a w tym czasie pojawiäo siö w sumie 51 usterek. Lista nienaprawionych bäödów nigdy nie miaäa wiöcej niĔ dwie pozycje. WydajnoĈè oszacowano na trzy razy wyĔszñ niĔ w porównywalnych zespoäach rozwijajñcych systemy wbudowane. Pierwsze jednostki przeznaczone do testów polowych byäy dostöpne po mniej wiöcej szeĈciu miesiñcach pracy. PóĒniej zespóä programistyczny byä pomocny przy innych zadaniach inĔynieryjnych, a jednoczeĈnie wciñĔ rozwijaä oprogramowanie3. Wszystkie okolicznoĈci, w jakich pracowaä ten zespóä, byäy niesprzyjajñce — oprócz coacha i jego podejĈcia do rozwoju oprogramowania. JeĈli tej grupie siö udaäo, sukces moĔe odnieĈè kaĔdy.

Jak to moŜliwe? JeĈli programista pracuje w zespole, w którym bäödy liczy siö w setkach, hasäo „brak bäödów” moĔe mu siö wydawaè niedorzeczne. Przyznajö — „brak bäödów” to ideaä, do którego naleĔy dñĔyè, a zespoäom nieczösto udaje siö osiñgnñè ten cel. Jednak w zespoäach stosujñcych XP moĔna w bardzo znacznym stopniu obniĔyè liczbö bäödów. W zespole opisanym przez Van Schooenderwoert Ĉrednia liczba bäödów na miesiñc wyniosäa 1,5 i to w bardzo trudnej dziedzinie. NiezaleĔne badania przeprowadzone przez organizacjö QSM Associates w firmie stosujñcej jednñ z wersji XP pokazaäy, Ĕe po wprowadzeniu tego podejĈcia Ĉrednia liczba usterek spadäa z 2270 do 381 [Mah]. Wiele osób moĔe podejrzewaè, Ĕe uzyskanie tak wysokiej poprawy jest niezwykle kosztowne. To nieprawda. Zespoäy stosujñce zwinne podejĈcie zwykle majñ ponadprzeciötnñ wydajnoĈè4. 3

Embedded Agile Project by the Numbers with Newbies [Van Schooenderwoert].

4

Zobacz na przykäad [Van Schooenderwoert], [Mah] i [Anderson 2006].

BRAK BĤüDÓW

191

Jak dotñd brak jednak mocnych dowodów na potwierdzenie tych wyników. Badania naukowe dotyczñce kompletnych metodologii rozwoju oprogramowania sñ rzadkie z uwagi na duĔñ liczbö zmiennych. Choè sñ organizacje, które wyciñgajñ wnioski na temat wydajnoĈci na podstawie analiz setek projektów, Ĕadne ze znanych mi badaþ nie obejmuje wystarczajñcej iloĈci danych, aby móc rzetelnie oceniè projekty zwinne w ogóle, nie mówiñc juĔ o samym XP. QSM to dobry przykäad organizacji, która próbuje wyciñgaè wnioski na podstawie niewielu informacji. W czerwcu 2006 firma ta dysponowaäa danymi z tylko kilku projektów zwinnych5. W obliczu braku przekonujñcych dowodów, skñd moĔna wiedzieè, czy zespóä osiñgnie oczekiwane wyniki? Jest tylko jeden sposób, aby siö o tym przekonaè: spróbowaè. Nie wymaga to nadzwyczajnych umiejötnoĈci. Udawaäo siö to zespoäom nowicjuszy kierowanym przez doĈwiadczonych programistów. Potrzebne jest wyäñcznie zaangaĔowanie w Ĉcisäe przestrzeganie praktyk XP i wsparcie organizacji w tym obszarze.

Jak dojļë do prawie zerowego poziomu bĥýdów? Wiele podejĈè do poprawy jakoĈci oprogramowania dotyczy wykrywania i usuwania wiökszej liczby usterek6 przez tradycyjne testy, inspekcje i automatyczne analizy. W zwinnym programowaniu celem jest generowanie mniejszej liczby bäödów. Nie chodzi przy tym o wczesne wykrywanie usterek, ale niedopuszczanie do ich powstawania. Van Schooenderwoert opisuje, Ĕe jej zespóä „przepuĈciä” do klienta 21 bäödów [Van Schooenderwoert]. Na podstawie danych Capersa Jonesa Van Schooenderwoert stwierdziäa, Ĕe „najlepszy w swej klasie” zespóä programistyczny wygenerowaäby 460 usterek, wykryä 95% z nich, przez co do klientów trafiäyby 23 bäödy7. Z kolei zespóä Van Schooenderwoert spowodowaä 51 bäödów, wykryä 59% z nich, a do klientów dotaräo 21 usterek. Wynik 0,22 bäödu na punkt funkcyjny jest znacznie lepszy od oczekiwaþ dla „najlepszego w swej klasie” zespoäu z danych Capersa Jonesa, wynoszñcych dwie usterki na punkt funkcyjny. Aby osiñgnñè te wyniki, naleĔy zastosowaè skuteczny zestaw technik XP.

1. Mniej bäödów w trakcie pisania kodu, co jest moĔliwe dziöki wielu róĔnorodnym praktykom technicznym i organizacyjnym.

2. Eliminacja miejsc sprzyjajñcych powstawaniu bäödów przez refaktoryzacjö Ēle zaprojektowanego kodu.

3. Szybkie naprawianie bäödów w celu zmniejszenia ich skutków, przygotowywanie testów zapobiegajñcych ponownemu wystñpieniu usterek i naprawianie powiñzanych z nimi niedoskonaäoĈci projektowych, które mogñ prowadziè do powstawania nastöpnych problemów.

4. Testowanie procesu przez stosowanie testów eksploracyjnych w celu ujawnienia problemów systemowych i ukrytych zaäoĔeþ.

5. Naprawianie procesu przez wykrywanie kategorii pomyäek i zapobieganie im.

5

Informacje prywatne, uzyskane od Michaela Maha z QSM Associates.

6

UĔywam wymiennie pojöè „usterka” i „bäñd”.

7

„Przeciötny” zespóä wygenerowaäby 1035 bäödów i wykryä 80% z nich, a do klienta trafiäoby 207 usterek.

192

ROZDZ AĤ 7

UDOSTüPN AN E

Nastöpnie naleĔy zadaè pytanie, czy podstawowa przyczyna tego bäödu moĔe prowadziè do innych niewykrytych jeszcze usterek. Testerzy powinni zastanowiè siö, czy pomyäki danego rodzaju nie wskazujñ na martwy punkt w myĈleniu zespoäu. NaleĔy przeprowadziè dodatkowe testy, aby odpowiedzieè na te pytania.

Gruntowna zmiana oczekiwaħ JeĈli zespóä zastosuje siö do przedstawionych praktyk, bäödy stanñ siö rzadkoĈciñ. Nastöpny krok polega na traktowaniu ich w ten sposób — jak czegoĈ wyjñtkowego. Zamiast wzruszaè ramionami w odpowiedzi na wykrycie bäödu: „No tak, nastöpny bäñd — normalna rzecz w oprogramowaniu”, zespóä powinien byè zaskoczony i przeraĔony: „To juĔ czwarty bäñd w tym miesiñcu! Dlaczego pojawia siö aĔ tyle bäödów?”. Nie jestem na tyle naiwny, aby twierdziè, Ĕe pozytywne myĈlenie pozwoli pozbyè siö bäödów, jednak jeĈli zespóä juĔ osiñga dobre wyniki, zmiana nastawienia pomoĔe zmieniè redukcjö bäödów w prawie caäkowitñ eliminacjö ich. Zespóä bödzie poĈwiöcaä wiöcej energii na wykrywanie i rozwiñzywanie podstawowych problemów. Dlatego zachöcam zespoäy, które dopiero zaczynajñ stosowaè XP, aby nie instalowaäy bazy danych bäödów. JeĈli grupa w ciñgu miesiñca generuje tylko jednñ lub dwie usterki, nie potrzebuje bazy danych do ich Ĉledzenia. MoĔliwe jest rozwiñzywanie bäödów w momencie ich wykrycia. Otwarta rezygnacja z bazy danych bäödów pomaga w wytworzeniu przekonania, Ĕe usterki to coĈ nienormalnego. Ponadto zespóä chroni siö w ten sposób przed pokusñ, aby uĔywaè bazy danych jako substytutu bezpoĈredniej, osobistej komunikacji. W niektórych branĔach potrzebny jest formalny mechanizm Ĉledzenia defektów, dlatego baza danych moĔe byè przydatna. Jednak nigdy nie zakäadam, Ĕe jest ona niezbödna, jeĈli wymagania sytuacji tego nie potwierdzñ. Nawet wtedy staram siö wykorzystaè istniejñcy proces, aby zastosowaè siö do regulacji lub speäniè wymagania organizacji. Choè niektórzy mogñ obruszyè siö na nieformalne rozwiñzania, czasem wystarczy uĔyè przechowywanych w szufladzie czerwonych karteczek z opisami bäödów. Po rezygnacji z bazy danych bäödów zespóä nadal musi mieè moĔliwoĈè odtworzenia problemu. Przydatne sñ do tego zrzuty ekranu, zrzuty rdzenia i tak dalej. JeĈli zespóä naprawia bäödy bezpoĈrednio po ich wykryciu, programiĈci mogñ korzystaè przy pracy bezpoĈrednio ze skrzynki odbiorczej. W przeciwnym razie moĔna zapisaè potrzebne informacje w tym samym miejscu, w którym zespóä przechowuje inne szczegóäy dotyczñce wymagaþ (zobacz podrozdziaä „Stopniowe zbieranie wymagaþ” w rozdziale 9.).

Pytania Skoro nowicjusze mogñ to zrobiè, co powstrzymuje zarzñd od zwolnienia wszystkich pracowników i zatrudnienia poczñtkujñcych programistów? JeĈli wszystkie inne warunki pozostanñ staäe, doĈwiadczeni programiĈci zawsze utworzñ lepszy kod od nowicjuszy i zrobiñ to szybciej. JeĈli moĔliwe jest wäñczenie w skäad zespoäu doĈwiadczonych osób, naleĔy to zrobiè. WaĔne jest, Ĕe omówione praktyki moĔe zastosowaè kaĔdy przeciötny zespóä, nawet grupa skäadajñca siö z nowicjuszy, pod warunkiem jednak, Ĕe majñ doĈwiadczonego coacha. Nie

198

ROZDZ AĤ 7

UDOSTüPN AN E

Efekty Kiedy liczba generowanych bäödów spada niemal do zera, zespóä nabiera pewnoĈci co do jakoĈci oprogramowania. Bez obaw wdraĔa oprogramowanie w Ĉrodowisku produkcyjnym, nie przeprowadzajñc pod koniec iteracji Ĕadnych dodatkowych testów. Udziaäowcy, klienci i rzadko natrafiajñ na nieprzyjemne niespodzianki, a grupa moĔe pracowaè nad rozwojem doskonaäego oprogramowania zamiast zajmowaè siö alarmami.

Przeciwwskazania „Brak bäödów” zaleĔy od wspomagania ze strony wszystkich technik wchodzñcych w skäad XP i ich struktury. Aby uzyskaè ten efekt, trzeba ĈciĈle przestrzegaè niemal kaĔdej praktyki: x Niezbödne sñ wszystkie praktyki z kategorii „MyĈlenie” (Programowanie w parach,

Energiczna praca, Informacyjne miejsce pracy, Analizy przyczynowo-skutkowe i Retrospekcje). Pomagajñ one usprawniè proces i uäatwiajñ programistom zauwaĔanie pomyäek w trakcie pisania kodu. x Konieczne sñ wszystkie praktyki z kategorii „Wspóäpraca” z wyjñtkiem praktyki Raporty

(Zaufanie, Wspólna praca, ZaangaĔowanie prawdziwych klientów, Wspólny jözyk, Krótkie spotkania robocze, Standardy pisania kodu i Demonstracje iteracji). WiökszoĈè z nich pomaga zapobiegaè bäödom w wymaganiach, a pozostaäe uäatwiajñ koordynacjö pracy programistów. x Niezbödne sñ wszystkie praktyki z kategorii „Udostöpnianie” oprócz praktyki

Dokumentacja („W peäni gotowe”, Brak bäödów, Kontrola wersji, Dziesiöciominutowa kompilacja, Ciñgäa integracja i WspóäwäasnoĈè kodu). WiökszoĈè pomaga zachowaè porzñdek i przejrzystoĈè kodu. Praktyka „W peäni gotowe” pomaga zapobiegaè przypadkowemu pominiöciu niektórych zadaþ. x Konieczne sñ wszystkie praktyki z kategorii „Planowanie” oprócz praktyki Zarzñdzanie

ryzykiem (Wizja, Planowanie wydania, Gra planistyczna, Planowanie iteracji, Zapas, OpowieĈci i Szacowanie). Zapewniajñ one strukturö dla pozostaäych praktyk i wspomagajñ je. x Niezbödne sñ wszystkie praktyki z kategorii „Wytwarzanie” z wyjñtkiem praktyki

Rozwiñzania punktowe (Wytwarzanie sterowane testami, Refaktoryzacja, Prosty projekt, Stopniowy rozwój projektu i architektury, Optymalizacja wydajnoĈci, Przeglñdy z udziaäem klienta, Testy klienta i Testy eksploracyjne). Poprawiajñ one jakoĈè projektu, zmniejszajñ liczbö bäödów w wymaganiach i umoĔliwiajñ testerom pracö zarówno przy zapobieganiu bäödom, jak i wykrywaniu usterek.

JeĈli zespóä nie stosuje wszystkich potrzebnych praktyk, nie moĔe oczekiwaè znacznego obniĔenia liczby usterek. JeĈli jednak pracuje nad projektem dobrze dostosowanym do XP (zobacz punkt „Czy XP to coĈ dla nas?” w rozdziale 4.) i przestrzega powyĔszych praktyk, wystñpienie wiöcej niĔ kilku bäödów na miesiñc moĔe byè oznakñ problemów w podejĈciu do XP. Zespóä oczywiĈcie potrzebuje czasu na poznanie praktyk, jednak jeĈli po upäywie kilku miesiöcy wciñĔ nie widaè poprawy w liczbie usterek, warto poprosiè o pomoc (zobacz punkt „Szukanie mentora” w rozdziale 2.).

200 ROZDZ AĤ 7

UDOSTüPN AN E

Inne moŜliwoļci Liczbö bäödów moĔna zmniejszyè takĔe przez zastosowanie dodatkowych testów (wäñcznie z inspekcjñ i automatycznymi analizami) o wyĔszej jakoĈci. Pozwala to wykryè i naprawiè wiöcej usterek. Jednak testerzy potrzebujñ czasu na przeglñd i przetestowanie kodu, przez co zespóä nie jest „w peäni gotowy” pod koniec kaĔdej iteracji i nie zawsze moĔe udostöpniè rozwiñzanie.

Dalsza lektura Artykuä Embedded Agile Project by the Numbers with Newbies [Van Schooenderwoert] to peäniejsze omówienie wbudowanego projektu w jözyku C opisanego we wprowadzeniu do podrozdziaäu.

BRAK BĤüDÓW

201

Caĥy projekt Powinno byè zrozumiaäe, Ĕe w systemie kontroli wersji naleĔy przechowywaè kod Ēródäowy. Mniej oczywiste jest, Ĕe moĔna umieĈciè tam takĔe wszelkie inne materiaäy. Choè wiökszoĈè systemów kontroli wersji umoĔliwia cofniöcie siö w czasie, nie daje to korzyĈci, jeĈli nie moĔna skompilowaè dokäadnie takiej wersji, jak w danym momencie. Zapisywanie w systemie kontroli wersji caäego projektu, wäñcznie z systemem kompilacji, umoĔliwia kompletne odtworzenie starszej wersji projektu. JeĈli to moĔliwe, naleĔy przechowywaè w systemie kontroli wersji wszystkie narzödzia, biblioteki, dokumentacjö i inne materiaäy zwiñzane z projektem. Szczególnie istotne sñ narzödzia i biblioteki. JeĈli zespóä nie umieĈci ich w systemie i w pewnym momencie zaktualizuje jeden z tych elementów, nie bödzie mógä wróciè do momentu sprzed aktualizacji. A jeĈli juĔ bödzie to moĔliwe, niezbödne bödzie przypomnienie sobie, której wersji narzödzia zespóä uĔywaä, i röczne przywrócenie jej. Z podobnych przyczyn warto przechowywaè caäy projekt w pojedynczym repozytorium. Choè na pozór naturalny jest podziaä projektu na kilka repozytoriów — na przykäad na materiaäy róĔnego typu lub na kod Ēródäowy i dokumentacjö — zwiöksza to prawdopodobieþstwo braku synchronizacji. NaleĔy aktualizowaè materiaäy i zatwierdzaè operacje w caäym drzewie. Zwykle oznacza to aktualizacjö lub zatwierdzanie w katalogu najwyĔszego poziomu. Czösto kuszñce jest zatwierdzanie tylko uĔywanego katalogu, jednak trudno wtedy uchroniè siö przed podziaäem kopii roboczej na dwie odröbne wersje. Jedyne materiaäy zwiñzane z projektem, których nie przechowujö w systemie kontroli wersji, to wygenerowany kod. Automatyczna kompilacja powinna prowadziè do automatycznego odtworzenia takiego kodu.

Wygenerowany kod powinien znajdowaè siö poza repozytorium.

Jest jeszcze jeden wyjñtek: naleĔy zaplanowaè porzñdkowanie. Nie trzeba integrowaè rozwiñzaþ punktowych (zobacz podrozdziaä „Rozwiñzania punktowe” w rozdziale 9.), eksperymentów i projektów badawczych, chyba Ĕe prowadzñ do powstania konkretnej dokumentacji lub innych materiaäów przydatnych w dalszej czöĈci projektu. NaleĔy przesyäaè tylko przydatne czöĈci eksperymentów i usuwaè pozostaäe.

Klienci i kontrola wersji W repozytorium powinny znaleĒè siö takĔe dane klientów. Obejmuje to dokumentacjö, uwagi dotyczñce wymagaþ (zobacz podrozdziaä „Stopniowe zbieranie wymagaþ” w rozdziale 9.), teksty techniczne, na przykäad podröczniki, oraz testy klienta (zobacz podrozdziaä „Testy klienta” w rozdziale 9.). Kiedy wspominam o tym programistom, zwykle martwiñ siö, Ĕe korzystanie z systemu kontroli wersji bödzie zbyt skomplikowane dla klientów. Nie naleĔy zbyt nisko ich oceniaè. Choè niektóre systemy kontroli wersji sñ bardzo zäoĔone, wiökszoĈè ma interfejsy przyjazne dla uĔytkownika. Wyjñtkowo wygodny jest na przykäad TortoiseSvn, windowsowy klient otwartego systemu kontroli wersji Subversion.

KONTRO A WERSJ

205

Nawet jeĈli uĔywany system kontroli wersji jest doĈè skomplikowany, zawsze moĔna przygotowaè dwa proste skrypty powäoki lub pliki wsadowe — jeden do aktualizacji, drugi do przesyäania — i nauczyè klientów korzystania z nich. JeĈli zespóä pracuje w jednym miejscu, programiĈci zawsze mogñ pomóc klientom w wykonaniu bardziej zäoĔonych zadaþ, na przykäad podróĔy w czasie lub scalania.

Utrzymywanie porzédku Jednym z najwaĔniejszych przesäaþ XP jest utrzymywanie porzñdku w kodzie i ciñgäa gotowoĈè Zawsze naleĔy przesyäaè kod, do jego udostöpnienia. Porzñdkowanie rozpoczyna który kompiluje siö siö juĔ od kopii roboczej. Choè postöpy wymagajñ i przechodzi wszystkie testy. naruszenia kompilacji w tej kopii, naleĔy ograniczyè problemy wyäñcznie do niej. Nigdy nie wolno przesyäaè kodu, który narusza kompilacjö. Dziöki temu kaĔdy moĔe w dowolnym momencie zaktualizowaè pliki bez obaw o naruszenie uĔywanej kompilacji. To z kolei pozwala wszystkim pracowaè päynnie i äatwo wspóädzieliè zmiany.

UWAGA MoĔna zminimalizowaè naruszanie kompilacji nawet w obröbie kopii roboczej. Dziöki poprawnie stosowanemu wytwarzaniu sterowanemu testami programista nigdy nie jest dalej niĔ piöè minut od dziaäajñcej kompilacji.

PoniewaĔ kompilacja automatycznie tworzy wydanie, kaĔdy kod, który moĔna skompilowaè, jest teoretycznie gotowy do udostöpnienia. W praktyce kod moĔe byè uporzñdkowany, podczas gdy samo oprogramowanie nie jest jeszcze w peäni gotowe. OpowieĈci mogñ byè ukoþczone w poäowie, czasem brakuje niektórych elementów interfejsu uĔytkownika, a funkcjonalnoĈè pewnych mechanizmów jest niepeäna. Pod koniec kaĔdej iteracji wszystkie poprawki powinny byè juĔ dokoþczone. KaĔda opowieĈè musi byè „w peäni gotowa”, a zespóä moĔe zainstalowaè oprogramowanie dla udziaäowców w ramach demonstracji iteracji. Program reprezentuje wiökszñ wartoĈè dla organizacji. NaleĔy oznaczyè wierzchoäek repozytorium, aby upewniè siö, Ĕe moĔna w kaĔdym momencie wróciè do danej wersji oprogramowania. Ja zwykle nazywam taki wierzchoäek „Iteracja X”, gdzie X to numer przeprowadzonej iteracji. Nie kaĔde przeznaczone dla udziaäowców wydanie z koþca iteracji jest udostöpniane klientom. Choè taki kod zawiera gotowe funkcje z opowieĈci, moĔe nie byè na tyle rozbudowany, aby uznaè go za wydanie. Kiedy zespóä je udostöpnia, powinien dodaè nastöpny znacznik do kompilacji z koþca iteracji, aby oznaczyè konkretne wydanie. Ja zwykle nazywam taki wierzchoäek „Wydanie Y”, gdzie Y to numer udostöpnionego wydania.

UWAGA

Choè teoretycznie moĔna skompilowaè kod z poziomu dowolnej kopii roboczej, lepiej unikaè problemów i kompilowaè wydania z poziomu nowej, czystej kopii roboczej. Kiedy programista choè jeden raz spödzi godzinö na wykrywaniu, Ĕe zepsuä kompilacjö wydania przez przypadkowe doäñczenie starszego pliku, nigdy nie powtórzy tego bäödu.

206 ROZDZ AĤ 7

UDOSTüPN AN E

Kod przechodzi przez cztery poziomy ukoþczenia:

1. Zepsuty. To moĔe zdarzyè siö tylko w kopii roboczej. 2. Kompiluje siö i przechodzi wszystkie testy. Wszystkie wersje w repozytorium sñ przynajmniej na tym poziomie.

3. Gotowy do zademonstrowania udziaäowcom. Wszystkie wersje oznaczone etykietñ „Iteracja X” sñ gotowe do wypróbowania przez udziaäowców.

4. Gotowy do udostöpnienia prawdziwym uĔytkownikom i klientom. KaĔda wersja oznaczona etykietñ „Wydanie Y” jest gotowa do wdroĔenia w Ĉrodowisku produkcyjnym.

Jeden kod bazowy Jednym z najwiökszych bäödów, jakie moĔe popeäniè zespóä, jest powielenie kodu bazowego. MoĔe to siö äatwo przydarzyè. Najpierw klient niewinnie prosi o dostosowanñ do jego potrzeb wersjö oprogramowania. ãatwo jñ szybko przygotowaè, powielajñc kod bazowy, wprowadzajñc w nim zmiany i udostöpniajñc go. Jednak dostosowywanie metodñ kopiuj i wklej podwaja liczbö wierszy kodu, które wymagajñ konserwacji. Widziaäem, jak takie postöpowanie utrudniäo dostarczenie dziaäajñcego oprogramowania Powielanie kodu bazowego ma w terminie. Niemal niemoĔliwe jest ponowne negatywny wpäyw na moĔliwoĈè scalenie powielonego kodu bazowego bez znacznego dostarczenia rozwiñzania. poĈwiöcenia i natychmiastowych dziaäaþ. To jedno klikniöcie prowadzi nie tylko do technicznego däugu, ale teĔ do dobrowolnego „zniewolenia” zespoäu. Niestety, system kontroli wersji sprzyja popeänianiu tego bäödu. WiökszoĈè systemów tego typu umoĔliwia rozgaäözianie kodu, czyli podziaä repozytorium na dwie odröbne ĈcieĔki rozwoju. Ma to takie same skutki, jak powielenie kodu bazowego. Gaäözie majñ pewne zastosowania, jednak uĔywanie ich do tworzenia wielu wersji oprogramowania dostosowanych do potrzeb klientów jest ryzykowne. Choè systemy kontroli wersji majñ mechanizmy do utrzymania synchronizacji miödzy wieloma gaäöziami, zapewnianie jej to Ĕmudna praca, która z czasem staje siö coraz trudniejsza. W zamian lepiej jest zaprojektowaè kod tak, aby obsäugiwaä wiele konfiguracji. MoĔna uĔyè architektury opartej na wtyczkach, plików konfiguracyjnych lub wydzieliè wspólnñ bibliotekö albo szablon. NaleĔy doäoĔyè do tego proces kompilacji i udostöpniania, który prowadzi do utworzenia wielu wersji.

Prawidĥowe wykorzystanie gaĥýzi Gaäözie dziaäajñ najlepiej, kiedy sñ szybko usuwane lub kiedy säuĔñ do wprowadzania maäej liczby zmian. JeĈli zespóä zapewnia pomoc technicznñ w zakresie starszych wersji oprogramowania, gaäözie poszczególnych wersji to najlepsze miejsce na umieszczenie specyficznych dla nich poprawek bäödów i mniejszych usprawnieþ. Niektóre zespoäy tworzñ gaäñĒ na potrzeby przygotowania wydania. Poäowa czäonków grupy kontynuuje pracö nad nowymi zadaniami, a druga poäowa stara siö zapewniè stabilnoĈè starszej wersji. W XP kod nie powinien wymagaè stabilizacji, dlatego lepiej utworzyè takñ gaäñĒ w momencie udostöpniania wydania, a nie jego przygotowywania.

KONTRO A WERSJ

207

UWAGA Aby caäkowicie wyeliminowaè potrzebö stosowania gaäözi, moĔna przeprowadzaè automatycznñ migracjö u klientów i uĔytkowników do kaĔdej najnowszej wersji w momencie jej udostöpnienia.

Gaäözie mogñ byè przydatne takĔe do ciñgäej integracji i innych zadaþ zwiñzanych z zarzñdzaniem kodem. Takie gaäözie prywatne zwykle sñ usuwane w przeciñgu jednego dnia. Nie sñ one potrzebne do skutecznego stosowania praktyk XP, jednak jeĈli zespóä zna tö technikö, moĔe z niej korzystaè bez obaw.

Pytania Którego systemu kontroli wersji powinniĈmy uĔywaè? Jest wiele moĔliwoĈci. W Ĉwiecie oprogramowania o otwartym dostöpie do kodu Ēródäowego popularny jest system Subversion, który dziaäa szczególnie dobrze w poäñczeniu z interfejsem TortoiseSvn. WĈród komercyjnych produktów dobrñ opiniñ cieszy siö Perforce, choè sam nie korzystaäem z tego systemu. NaleĔy unikaè aplikacji Visual SourceSafe (VSS). VSS to popularne narzödzie uĔywane przez zespoäy Microsoftu, jednak ma wiele wad i problemów zwiñzanych z uszkodzeniem repozytorium. Dla systemu kontroli wersji defekty tego typu sñ niedopuszczalne. MoĔliwe, Ĕe dana organizacja udostöpnia zalecany system kontroli wersji. JeĈli speänia on potrzeby zespoäu, moĔna go uĔyè. W przeciwnym razie zarzñdzanie wäasnym systemem kontroli wersji nie zajmuje zbyt wiele czasu i wymaga tylko nieco miejsca na dysku oraz mocy serwera. Czy naprawdö powinniĈmy przechowywaè wszystkie narzödzia i biblioteki w systemie kontroli wersji? Wszystkie, które to umoĔliwiajñ. Röczne instalowanie narzödzi i bibliotek moĔe mieè dwa niekorzystne nastöpstwa. Po pierwsze, przy kaĔdej aktualizacji wszystkie osoby muszñ röcznie aktualizowaè swe komputery. Po drugie, w pewnym momencie programista bödzie chciaä skompilowaè starsze wydanie i spödzi kilka godzin na próbie przypomnienia sobie, które wersje poszczególnych narzödzi musi zainstalowaè. Niektóre zespoäy rozwiñzujñ te problemy, tworzñc dokumentacjö „narzödzi i bibliotek” oraz uwieszajñc jñ w systemie kontroli kodu Ēródäowego, jednak aktualizowanie takiej dokumentacji jest käopotliwe. ãatwiejsze i bardziej wydajne jest przechowywanie w takim systemie samych narzödzi i bibliotek. Niektóre narzödzia i biblioteki wymagajñ specjalnej instalacji (zwäaszcza w systemie Windows), co utrudnia stosowanie zalecanego podejĈcia. Jednak nie wszystkie aplikacje wymagajñ instalacji. Niektóre majñ instalator tylko z uwagi na oczekiwania uĔytkowników. Warto sprawdziè, czy moĔna korzystaè z takich aplikacji bez ich instalowania, oraz staraè siö unikaè tych, których nie moĔna uĔywaè bez wczeĈniejszego skonfigurowania. JeĈli uĔywam narzödzi, które wymagajñ instalacji, umieszczam w systemie kontroli wersji pakiet instalacyjny, jednak nie instalujö programów automatycznie przy uĔyciu skryptu kompilacji. To samo dotyczy narzödzi, które sñ przydatne, ale nie sñ niezbödne do kompilacji, na przykäad Ĉrodowisk IDE lub narzödzi diagnostycznych.

208 ROZDZ AĤ 7

UDOSTüPN AN E

Dziesiýciominutowa kompilacja Eliminujemy problemy zwiñzane z kompilacjñ i konfiguracjñ.

Odb orcy P og amiļci

Oto ideaä, do którego naleĔy dñĔyè. WyobraĒmy sobie, Ĕe zespóä wäaĈnie zatrudniä nowego programistö. Lider prowadzi go do lĈniñcego nowego komputera, który wäaĈnie dodano do otwartego pomieszczenia roboczego. „OdkryliĈmy, Ĕe przechowywanie caäego kodu w systemie kontroli wersji i uĔywanie wysokiej jakoĈci automatycznej kompilacji znacznie przyspiesza naszñ pracö” — mówi lider. „ChodĒ, pokaĔö ci to. Ten komputer jest nowy, dlatego na razie nie ma na nim Ĕadnych naszych narzödzi”. Lider z nowym programistñ siedzñ obok siebie. „W porzñdku, pobierzmy drzewo kodu Ēródäowego”. Lider przeprowadza programistö przez proces i rozpoczyna siö pobieranie drzewa kodu Ēródäowego. „Zajmie to trochö czasu, poniewaĔ w systemie kontroli wersji przechowujemy takĔe narzödzia do kompilacji i biblioteki. Nie obawiaj siö — podobnie jak kaĔdy dobry system kontroli wersji, ten pobiera tylko zmodyfikowane materiaäy, dlatego dziaäa powoli tylko za pierwszym razem. ChodĒ, zanim system Ĉciñgnie kod, oprowadzö ciö po biurze”. Po „wycieczce” obaj wracajñ do komputera. „ćwietnie, skoþczone” — mówi lider. „Teraz popatrz — to moja ulubiona funkcja. PrzejdĒ do korzenia drzewa kodu Ēródäowego i wpisz komendö build”. Nowy programista wykonuje polecenie, a nastöpnie obserwuje pojawiajñce siö informacje o kompilacji. „To nie tylko kompilacja kodu Ēródäowego” — wyjaĈnia lider. „Pracujemy nad zäoĔonñ aplikacjñ, która wymaga serwera sieciowego, kilku usäug sieciowych oraz szeregu baz danych. W przeszäoĈci nowo zatrudniony programista musiaä spödziè kilka pierwszych tygodni na konfigurowaniu stacji roboczej. Jeszcze gorzej byäo ze Ĉrodowiskiem testowym. Naprawa problemów w tym Ĉrodowisku sprawiaäa czasem, Ĕe caäy zespóä przez kilka dni nie mógä kontynuowaè pracy. Nawet kiedy Ĉrodowisko dziaäaäo, musieliĈmy dzieliè je miödzy sobñ, dlatego dwie osoby nie mogäy równoczeĈnie przeprowadzaè testów”. „Teraz wszystko wyglñda inaczej. ZautomatyzowaliĈmy caäñ konfiguracjö. KaĔdy moĔe w dowolnym momencie kompilowaè kod i uruchamiaè testy na wäasnej maszynie. Mogö nawet odäñczyè komputer od sieci, a kompilacja nie zatrzyma siö. Skrypt kompilacji odpowiada za wszystko: konfiguruje lokalny serwer sieciowy, inicjuje lokalnñ bazö danych — dba o kaĔdy szczegóä”. „No, prawie gotowe. Skrypt zakoþczyä kompilacjö aplikacji i konfigurowanie usäug. Teraz przeprowadza testy. To zadanie trwaäo naprawdö däugo, jednak znacznie przyspieszyliĈmy je dziöki usprawnieniu testów jednostek, co pozwoliäo zrezygnowaè z testów kompleksowych”. Nagle wszystko siö zatrzymuje. Kursor mruga spokojnie. Na dole konsoli pojawia siö komunikat: „KOMPILACJA ZAKOýCZONA SUKCESEM”. „I to juĔ wszystko” — lider mówi z dumñ w gäosie. „Wszystko dziaäa. Mam tak duĔe zaufanie do kompilacji i testów, Ĕe mogö choèby teraz wziñè kod i zainstalowaè go na serwerach produkcyjnych. MoĔemy to zrobiè choèby zaraz, wydajñc skryptowi kompilacji inne polecenie”. „Spodoba ci siö praca u nas” — ciñgnie lider, posyäajñc nowemu programiĈcie przyjazny uĈmiech. „WczeĈniej wykonanie nawet najprostszych zadaþ byäo drogñ przez mökö. Teraz praca idzie jak po maĈle. Wszystko po prostu dziaäa”.

DZ ES üC OM NUTOWA KOMP

ACJA

211

Automatyzacja kompilacji Jak by to byäo, gdyby moĔna skompilowaè i przetestowaè caäy produkt — lub przygotowaè pakiet instalacyjny — w dowolnym momencie, po prostu wciskajñc przycisk? O ile äatwiejsza staäaby siö praca? Przygotowanie kompilacji to czösto frustrujñce i däugie zadanie. Irytacja moĔe przenieĈè siö na inne aspekty pracy. „Czy moĔemy udostöpniè oprogramowanie?”. „Za kilka dni”. „Czy oprogramowanie dziaäa?”. „Moja czöĈè tak, ale nie potrafiö skompilowaè wszystkiego”. „Czy demonstracja jest gotowa?”. „NatrafiliĈmy na problemy z kompilacjñ — powiedz wszystkim, aby wrócili za godzinö”. Niestety, czösto äatwo zapomnieè o automatyzacji kompilacji w poĈpiechu zwiñzanym z koþczeniem funkcji. JeĈli automatyczna kompilacja nie jest jeszcze gotowa, naleĔy od razu zaczñè nad niñ pracö. Jest to jeden z najäatwiejszych sposobów na uäatwienie pracy.

Automatyzacja kompilacji to jeden z najäatwiejszych sposobów na poprawö morale i zwiökszenie produktywnoĈci.

Jak automatyzowaë? Dostöpnych jest wiele przydatnych narzödzi do kompilacji przeznaczonych dla róĔnych platform i jözyków. ProgramiĈci uĔywajñcy jözyka Java powinni zwróciè uwagö na Anta. WĈród uĔytkowników .NET popularne sñ narzödzia NAnt i MSBuild. ProgramiĈci uĔywajñcy jözyków C i C++ od dawna uĔywajñ programu make. Dostöpne sñ teĔ narzödzia do kompilacji kodu w jözykach Perl, Python i Ruby. Kompilacja powinna byè kompleksowa, ale nie zäoĔona. Obok kompilowania kodu Ēródäowego i uruchamiania testów powinna konfigurowaè wpisy rejestru, inicjowaè schematy bazy danych, konfigurowaè serwery sieciowe i uruchamiaè procesy, czyli wykonywaè wszystkie operacje potrzebne do skompilowania i przetestowania oprogramowania od podstaw bez interwencji czäowieka. Kiedy podstawowe elementy zacznñ dziaäaè, naleĔy dodaè moĔliwoĈè utworzenia wydania produkcyjnego albo w postaci pliku instalacyjnego, albo przez zainstalowanie rozwiñzania na serwerach.

UWAGA NaleĔy utworzyè kompilacjö tak, aby zwracaäa pojedynczy, jednoznaczny wynik, na przykäad „UDANA” albo „NIEUDANA”. Zespoäy uruchamiajñ kompilacjö po kilkadziesiñt razy dziennie. Röczne sprawdzanie jest wolne, naraĔone na bäödy i — po wielokrotnym wykonaniu — bardzo irytujñce.

Kluczowym elementem udanej automatycznej kompilacji jest kompilacja lokalna. UmoĔliwia ona skompilowanie i przetestowanie rozwiñzania w dowolnym momencie bez wzglödu na czynnoĈci wykonywane przez inne osoby. W XP odbywa siö to co kilka minut, dlatego niezaleĔnoĈè jest istotna. Ponadto znacznie przyspiesza to przebieg kompilacji.

212

ROZDZ AĤ 7

UDOSTüPN AN E

MoĔliwe powinno byè skompilowanie rozwiñzania nawet wtedy, kiedy komputer zostanie odäñczony od sieci.

Najlepsze rozwiñzanie, podobnie jak w kaĔdym zwinnym planie, polega na podziale pracy na maäe etapy, których efekty bödñ szybko odczuwalne. JeĈli zespóä pracuje nad wyjñtkowo zäoĔonym systemem obejmujñcym wiele komponentów, powinien rozwijaè kaĔdy z nich po kolei, rozpoczynajñc od tych najbardziej naraĔonych na bäödy lub irytujñcych przy röcznej kompilacji. Po wyborze odpowiedniego komponentu do automatyzacji naleĔy najpierw umoĔliwiè jego kompilacjö. Zwykle jest to proste zadanie, a po jego wykonaniu moĔna szybko przejĈè do dalszych czynnoĈci. Nastöpnie naleĔy dodaè moĔliwoĈè uruchomienia testów jednostek i upewniè siö, Ĕe kod je przechodzi. Prawdopodobnie zespóä juĔ wczeĈniej kompilowaä i uruchamiaä testy jednostek w Ĉrodowisku IDE, dlatego pozornie nie jest to duĔy postöp. NaleĔy jednak trzymaè siö tego rozwiñzania. Przygotowanie skryptu kompilacji, który informuje o efektach dziaäania, to waĔny krok. Dziöki temu nie trzeba bödzie juĔ wiöcej sprawdzaè wyników röcznie. Nastöpne zadanie zaleĔy od tego, co sprawia zespoäowi najwiöcej problemów. Co jest najbardziej irytujñce w obecnym procesie kompilacji? Jakie problemy z konfiguracjñ wymagajñ zmarnowania kilku godzin kaĔdego tygodnia? NaleĔy zautomatyzowaè käopotliwe operacje, a nastöpnie ponawiaè wybór najbardziej irytujñcej funkcji do momentu zautomatyzowania wszystkich zadaþ. JeĈli zespóä ukoþczyä ten proces, moĔe sobie pogratulowaè, poniewaĔ wyeliminowaä wszystkie dokuczliwoĈci zwiñzane z kompilacjñ. Jest to wiöcej, niĔ udaje siö uzyskaè wiökszoĈci grup: zespóä utworzyä dobry skrypt kompilacji. Teraz pora na utworzenie skryptu doskonaäego. Zespóä powinien przyjrzeè siö procesowi wdraĔania. Czy tworzy pakiet wydania, na przykäad instalator, czy wdraĔa oprogramowanie bezpoĈrednio na serwerach produkcyjnych? W obu przypadkach naleĔy zaczñè od automatyzacji najwiökszych bolñczek, jedna po drugiej. Podobnie jak wczeĈniej, zespóä powinien po kolei zajmowaè siö najwiökszymi problemami do momentu ich wyeliminowania. Nie stanie siö to od razu, ale postöp bödzie widoczny kaĔdego tygodnia. JeĈli co tydzieþ zespóä usunie jednñ dokuczliwoĈè, niewaĔne jak maäñ, w ciñgu miesiñca zauwaĔy wyraĒny postöp. W trakcie pracy nad innymi zadaniami warto uwaĔaè, aby nie powiökszaè däugu. Wszystkie nowe funkcje naleĔy od poczñtku umieszczaè w skrypcie kompilacji.

Dziesiýë minut lub mniej Doskonaäy skrypt kompilacji daje zespoäowi duĔñ przewagö nad wiökszoĈciñ innych grup programistycznych. Kiedy minie radoĈè z tego, Ĕe moĔna w dowolnym momencie skompilowaè caäy system, zespóä prawdopodobnie zauwaĔy coĈ nowego: kompilacja trwa däugo. Przy ciñgäej integracji integrowanie kodu odbywa siö co kilka godzin. Za kaĔdym razem niezbödne sñ dwie kompilacje: jedna na komputerze programisty i druga na maszynie do integracji. Programista musi czekaè na ukoþczenie ich obu, poniewaĔ w XP nie moĔna dopuĈciè do naruszenia kompilacji. JeĈli wystñpi problem, trzeba anulowaè wprowadzone zmiany. Dziesiöciominutowa kompilacja prowadzi do dwudziestominutowego cyklu integracji. To doĈè duĔe opóĒnienie. Ja dñĔö do dziesiöcio- lub piötnastominutowych cykli. Ten czas umoĔliwia mi rozprostowanie nóg, zrobienie sobie kawy i rozmowö z partnerem z pary.

214

ROZDZ AĤ 7

UDOSTüPN AN E

Najäatwiejszy sposób na utrzymanie czasu kompilacji poniĔej piöciu minut (przy czym nie naleĔy przekraczaè dziesiöciu minut) polega na zapewnianiu od samego poczñtku krótkiego czasu kompilacji. Jeden z zespoäów, z którymi wspóäpracowaäem, szukaä moĔliwoĈci przyspieszenia kompilacji za kaĔdym razem, kiedy wydäuĔaäa siö do ponad 100 sekund. Wiele zespoäów poznajñcych dopiero XP popeänia bäñd i pozwala na zbyt däugñ kompilacjö. JeĈli grupie przydarzy siö coĈ takiego, nie naleĔy siö martwiè. MoĔna skróciè czas kompilacji w ten sam zwinny sposób, który säuĔy do späacania däugu technicznego: fragment po fragmencie i koncentrujñc siö na robieniu na kaĔdym etapie wartoĈciowych postöpów. W wiökszoĈci zespoäów Ēródäem wolnej kompilacji sñ testy. Zwykle dzieje siö tak, poniewaĔ sñ one zbyt Wolne testy to najczöstsza ogólne. Warto zwróciè uwagö na czösto spotykany przyczyna däugiej kompilacji. problem: czy zespóä nie pisze przypadkiem testów kompleksowych, podczas gdy powinien tworzyè testy jednostek i testy integracji? Czy testy jednostek komunikujñ siö z bazñ danych, sieciñ lub systemem plików? SzybkoĈè dziaäania testów jednostek powinna wynosiè okoäo 100 testów na sekundö. Powinny one stanowiè wiökszoĈè wszystkich testów. Niewielkñ czöĈè (mniej niĔ 10%) powinny stanowiè testy integracji, które sprawdzajñ, czy dwa komponenty dobrze ze sobñ wspóädziaäajñ. JeĈli te testy zapewniajñ dobre pokrycie, potrzebnych jest tylko kilka testów kompleksowych, a czasem w ogóle nie sñ one potrzebne. Wiöcej informacji na ten temat zawiera punkt „Przyspieszanie dziaäania” w rozdziale 9. Choè testy to najczöstsza przyczyna wolnej kompilacji, to jeĈli problemem jest wolna kompilacja kodu Ēródäowego, warto zastanowiè siö nad optymalizacjñ struktury kodu, uĔyciem pamiöci podröcznej dla kompilacji kodu Ēródäowego lub jego stopniowñ kompilacjñ. MoĔna teĔ uĔyè rozproszonego systemu kompilacji kodu Ēródäowego lub wykorzystaè najlepszy dostöpny komputer jako gäównñ maszynö do kompilacji. Nie naleĔy zapominaè o wykorzystaniu zalet funkcji sprawdzania zaleĔnoĈci uĔywanego narzödzia do kompilacji, dziöki której nie trzeba ponownie kompilowaè niezmodyfikowanych elementów. W najgorszym przypadku trzeba podzieliè kompilacjö na „szybkñ”, którñ zespóä uruchamia czösto, i „wolnñ”, uĔywanñ na serwerze do integracji przy przesyäaniu kodu (zobacz podrozdziaä „Ciñgäa integracja” w dalszej czöĈci rozdziaäu). NaleĔy jednak zachowaè ostroĔnoĈè. To podejĈcie prowadzi do wiökszej liczby nieudanych kompilacji niĔ pojedyncza, szybka kompilacja. Warto poĈwiöciè trochö wysiäku na przyspieszenie dziaäania kompilacji.

Pytania Kto odpowiada za konserwacjö skryptu kompilacji? Za konserwacjö skryptu odpowiadajñ wszyscy programiĈci. Wraz z ewolucjñ kodu bazowego zmieniaè powinien siö teĔ skrypt kompilacji. Na poczñtku prawdopodobnie jedna osoba bödzie wiedziaäa o skrypcie wiöcej od innych. W momencie, kiedy programista zechce zaktualizowaè skrypt, powinien rozpoczñè pracö w parze z tñ osobñ i uczyè siö od niej.

DZ ES üC OM NUTOWA KOMP

ACJA

215

przez niego czöĈè oprogramowania. W przeciwnym razie w momencie udostöpnienia systemu pojawi siö mnóstwo zadaþ zwiñzanych z integracjñ i naprawianiem bäödów. Standardowe rozwiñzanie polega tu na zbudowaniu symulatora brakujñcego systemu, co pozwala przygotowaè testy integracji. Kiedy brakujñcy system zostanie udostöpniony, testy integracji pomogñ stwierdziè, czy zaäoĔenia wbudowane przez zespóä w symulator byäy prawidäowe. Brak komponentów zwiöksza ryzyko projektu, dlatego warto jak najszybciej uzyskaè dostöp do systemu testowego. Jak czösto powinniĈmy kompilowaè caäe rozwiñzanie od podstaw? Przynajmniej raz w trakcie kaĔdej iteracji. Kompilacja od podstaw jest duĔo wolniejsza niĔ stopniowa, dlatego czöstotliwoĈè jej uruchamiania zaleĔy od tego, jak szybko dziaäa i jak dobry jest uĔywany system kompilacji. JeĈli zespóä nie ufa temu systemowi, powinien czöĈciej kompilowaè rozwiñzanie od podstaw. MoĔna teĔ przygotowaè system do testów wstöpnych, który bödzie kompilowaä projekt od podstaw przy kaĔdym przesäaniu kodu. Rozwiñzania, które preferujö, polegajñ na zmniejszaniu czasu kompilacji do momentu, kiedy stopniowa kompilacja staje siö zbödna, albo na naprawianiu bäödów w systemie kompilacji, dziöki czemu mogö zaufaè stopniowej kompilacji. Jednak nawet wtedy wolö kompilowaè projekt od podstaw przed udostöpnieniem oprogramowania klientom.

Efekty Dziöki dobrej automatycznej kompilacji moĔna skompilowaè wydanie w dowolnym momencie. Kiedy nowa osoba doäñcza do zespoäu lub kiedy trzeba usunñè dane z komputera i skonfigurowaè go od nowa, wystarczy pobraè najnowszy kod z repozytorium i uruchomiè kompilacjö. Kiedy kompilacja jest szybka i dobrze zautomatyzowana, zespóä powinien czöĈciej kompilowaè i testowaè caäy system. Pozwala to na wczeĈniejsze wykrywanie bäödów i — co za tym idzie — skrócenia czasu potrzebnego na debugowanie. MoĔna teĔ czösto integrowaè oprogramowanie bez koniecznoĈci polegania na zäoĔonych wbudowanych systemach kompilacji, co zmniejsza problemy z integracjñ.

Przeciwwskazania W kaĔdym projekcie potrzebna jest dobra zautomatyzowana kompilacja. JeĈli kompilacja systemu jest skomplikowana, warto od razu zaczñè rozwiñzywanie problemu. Niektóre projekty sñ zbyt rozbudowane, aby moĔna zastosowaè w nich reguäö dziesiöciu minut. Przed zaäoĔeniem, Ĕe jest to prawdñ dla danego projektu, naleĔy dobrze przyjrzeè siö procedurom kompilacji. Czösto moĔna skróciè jej czas w nieoczekiwanie duĔym stopniu.

Inne moŜliwoļci JeĈli projekt rzeczywiĈcie jest za duĔy, aby moĔna skompilowaè go w dziesiöè minut, prawdopodobnie jego rozwojem zajmuje siö kilka zespoäów lub podgrup. Warto zastanowiè siö nad podziaäem projektu na niezaleĔne fragmenty, które moĔna kompilowaè i testowaè osobno. DZ ES üC OM NUTOWA KOMP

ACJA

217

JeĈli kompilacja systemu w czasie krótszym niĔ dziesiöè minut nie jest (na razie) moĔliwa, warto ustaliè maksymalny akceptowalny czas trwania i przestrzegaè tego limitu. Ustalenie tego poziomu pomaga okreĈliè punkt, powyĔej którego zespóä nie moĔe pozwoliè sobie na dalszy wzrost däugu technicznego. Przekroczenie tego limitu, podobnie jak zlew peäen naczyþ na dwie godziny przed imprezñ, to dobra motywacja do rozpoczöcia porzñdków.

218

ROZDZ AĤ 7

UDOSTüPN AN E

Ciégĥa integracja Nasz kod jest zawsze gotowy do udostöpnienia.

Odb orcy P og amiļci

W wiökszoĈci projektów rozwoju oprogramowania wystöpuje ukryte opóĒnienie miödzy momentem, kiedy zespóä stwierdza, Ĕe „jest gotowy”, a chwilñ, kiedy oprogramowanie rzeczywiĈcie moĔna udostöpniè. Czasem ten okres moĔe przeciñgaè siö do wielu miesiöcy. Przyczynñ sñ drobiazgi: scalanie kodu napisanego przez poszczególne osoby, przygotowywanie instalatora, wstöpne zapeänianie bazy danych, pisanie podröcznika i tak dalej. W tym czasie zespóä pracuje pod presjñ czasu, poniewaĔ jego czäonkowie zapomnieli, jak däugo trwa wykonanie takich zadaþ. Wszyscy spieszñ siö i zapominajñ o pomocnej automatyzacji kompilacji, co prowadzi do nastöpnych bäödów i opóĒnieþ. Lepszym rozwiñzaniem jest ciñgäa integracja. To podejĈcie sprawia, Ĕe caäy kod jest zawsze zintegrowany, a infrastruktura wydania rozwija siö wraz z pozostaäymi czöĈciami aplikacji. Ostateczny cel ciñgäej integracji to umoĔliwienie zainstalowania w dowolnym momencie caäego oprogramowania oprócz kilku ostatnich godzin pracy.

Ostateczny cel to moĔliwoĈè instalacji w dowolnym momencie.

W praktyce zespóä nie udostöpnia oprogramowania w poäowie iteracji. OpowieĈci sñ ukoþczone tylko w czöĈci, a funkcje — niekompletne. WaĔne jednak, aby zachowaè gotowoĈè technologicznñ do udostöpnienia kodu, nawet jeĈli pod wzglödem funkcjonalnym rozwiñzanie nie jest jeszcze gotowe.

Dlaczego to dziaĥa? JeĈli zespóä kiedykolwiek doĈwiadczyä wielodniowej (lub wielotygodniowej) integracji, integrowanie caäego projektu co kilka godzin moĔe wydawaè siö bez sensu. Po co przechodziè przez te möki tak czösto? W rzeczywistoĈci krótsze cykle sprawiajñ, Ĕe integracja staje siö mniej käopotliwa. Krótsze cykle wiñĔñ siö z mniejszymi zmianami, co oznacza mniej moĔliwoĈci wystñpienia konfliktów miödzy modyfikacjami wprowadzonymi przez róĔne osoby. Nie chcö przez to powiedzieè, Ĕe takie problemy siö nie zdarzajñ — czasem siö pojawiajñ. Jednak sñ rzadsze, poniewaĔ zakres zmian wprowadzanych przez poszczególnych programistów jest niewielki.

UWAGA Konflikty sñ najbardziej prawdopodobne, kiedy programista wprowadza szeroko zakrojone zmiany. Powinien wtedy z góry poinformowaè o tym pozostaäych czäonków zespoäu, aby mogli zintegrowaè zmiany i byli gotowi na uwzglödnienie duĔych modyfikacji.

C èGĤA

NTEGRACJA

219

Zmniejszenie zakresu moĔliwych bäödów to klucz do szybkiego rozwoju. JeĈli programista ma caäkowitñ pewnoĈè, Ĕe oprogramowanie dziaäaäo piöè minut wczeĈniej, oznacza to, Ĕe jedynie zmiany wprowadzone w tym czasie mogäy spowodowaè usterki. Ogranicza to zakres problemu w tak duĔym stopniu, Ĕe czösto moĔna go wykryè, przeglñdajñc komunikat o bäödzie — debugowanie jest w ogóle niepotrzebne. Aby to osiñgnñè, zespóä musi uzgodniè, Ĕe bödzie zawsze zachowywaä poprawnoĈè kompilacji. Jest to tylko na pozór trudne. MoĔna zagwarantowaè, Ĕe kompilacja nigdy (lub prawie nigdy) nie zawiedzie, stosujñc prosty proces.

Zespóä powinien uzgodniè, Ĕe bödzie zawsze zachowywaä poprawnoĈè kompilacji.

Proces ciégĥej integracji Aby zagwarantowaè, Ĕe kompilacja zawsze dziaäa, trzeba rozwiñzaè dwa problemy. Po pierwsze, trzeba siö upewniè, Ĕe kod, który dziaäa na komputerze danego programisty, bödzie dziaäaä na kaĔdej maszynie. Niezwykle czösto moĔna usäyszeè stwierdzenie: „PrzecieĔ u mnie wszystko dziaäaäo!”. Po drugie, trzeba zagwarantowaè, Ĕe wszyscy pobierajñ kod, który poprawnie siö kompiluje. Niezbödny jest do tego dodatkowy komputer, który peäni funkcjö centralnej maszyny do integracji. Potrzebny jest teĔ dowolny fizyczny obiekt, którego zespóä bödzie uĔywaä jako symbolu integracji. Ja uĔywam gumowego kurczaka. Dobrze nadajñ siö do tego takĔe pluszowe zabawki. Po przygotowaniu maszyny do integracji i symbolu integracji moĔna zagwarantowaè zawsze dziaäajñcñ kompilacjö w kilku prostych krokach.

Aktualizacja przy uŜyciu kodu z repozytorium 1. NaleĔy sprawdziè, czy symbol integracji jest dostöpny. JeĈli nie, oznacza to, Ĕe inna para przesyäa nieprzetestowany kod i trzeba poczekaè, aĔ skoþczñ to robiè.

2. Nastöpnie moĔna pobraè najnowsze zmiany z repozytorium. Inne pary mogñ w tym czasie pobieraè zmiany, jednak nie naleĔy udostöpniaè im symbolu integracji do momentu zakoþczenia pracy.

Po pobraniu kodu trzeba uruchomiè peänñ kompilacjö, aby upewniè siö, Ĕe caäe rozwiñzanie kompiluje siö i przechodzi testy. JeĈli nie, wystñpiä problem. NajczöĈciej wynika on z nieodpowiedniej konfiguracji danego komputera. Warto spróbowaè uruchomiè kompilacjö na maszynie do integracji. JeĈli siö powiedzie, trzeba wykryè i rozwiñzaè problem na danym komputerze. W przeciwnym razie naleĔy znaleĒè parö, która jako ostatnia przeprowadziäa integracjö, i „zmyè im gäowö”, choèby tylko w przenoĈni.

Integracja 1. Najpierw naleĔy zaktualizowaè projekt przy uĔyciu kodu z repozytorium (stosujñc

poprzedni proces). Trzeba rozwiñzaè wszelkie konflikty i uruchomiè kompilacjö (wäñcznie z testami), aby upewniè siö, Ĕe obecny kod dziaäa.

2. Nastöpnie naleĔy wziñè symbol integracji i przesäaè kod.

C èGĤA

NTEGRACJA

221

3. Przy maszynie do integracji naleĔy pobraè zmiany i uruchomiè kompilacjö (wäñcznie z testami).

4. Na koþcu naleĔy odstawiè symbol integracji. JeĈli kompilacja na maszynie do integracji zakoþczy siö niepowodzeniem, trzeba naprawiè problem przed odäoĔeniem symbolu integracji. Najszybszy sposób to anulowanie wprowadzonych zmian. Jednak jeĈli nikt nie czeka na symbol, moĔna naprawiè bäñd na wäasnej maszynie i ponownie przesäaè kod. NaleĔy unikaè röcznego rozwiñzywania problemów przy maszynie do integracji. JeĈli kompilacja dziaäaäa na komputerze programisty, prawdopodobnie zapomniaä dodaè plik lub nowñ konfiguracjö do skryptu kompilacji. W obu przypadkach röczne rozwiñzanie problemu sprawi, Ĕe nastöpna osoba, która pobierze kod, nie bödzie mogäa go skompilowaè.

SERWERY DO CIèGĤEJ INTEGRACJI Jest w e e róŜnych serwerów do ciégĥej integracji o otwartym dostýp e do kodu Śródĥowego Praprzodk em ch wszystk ch jest Cru seContro , wymyļ ony przez pracown ków f rmy houghtWorks Serwe y do c égĥej ntegracj automatyczn e urucham ajé komp acjý po przesĥan u kodu Jeļ komp acja s ý n e pow edz e, serwer nformuje o tym zespóĥ N ektóre osoby próbujé uŜywaë se werów do c égĥej ntegracj zam ast wczeļn ej op sanego procesu c égĥej ntegracj N e jest to naj epsze rozw ézan e, pon ewaŜ bez symbo u ntegracj czĥonkow e zespoĥu mogé przypadkowo pobraë kod, którego poprawnoļë n e zostaĥa jeszcze sprawdzona Nastýpny czýsto popeĥn any bĥéd to wykorzystywan e serwerów do c égĥej ntegracj do wymuszan a na czĥonkach zespoĥu poprawy stosowanych praktyk komp acj Choë moŜ woļc tak ch serwerów mogé czasem skĥan aë do tego, podejļc e to býdz e skuteczne ty ko wtedy, k edy czĥonkow e zespoĥu naprawdý chcé przesyĥaë dob y kod Sĥyszaĥem w e e don es eħ od osób, które próbowaĥy uŜyë serwerów do c égĥej ntegracj do wymuszen a zgodnoļc , a nastýpn e mus aĥy samodz e n e napraw aë wszystk e bĥýdy komp acj , podczas gdy pozosta czĥonkow e zespoĥu gnorowa ch nakazy Jeļ zespóĥ pracuje wspó n e uŜywa szybk ej komp acj , n e pot zebuje dodatkowej zĥoŜonoļc zw ézanej z serweram do c égĥej ntegracj Wystarczy przy p zesyĥan u kodu podejļë do maszyny do ntegracj uruchom ë komp acjý Zajmuje to ty ko k ka sekund — dĥuŜszego czasu se we y do c égĥej ntegracj pot zebujé na zauwaŜen e p zesĥanego kodu — daje pretekst do rozprostowan a nóg Jeļ zespóĥ za nsta uje se wer do c égĥej ntegracj , pow n en uwaŜaë, aby s ý n e rozpraszaë zeba skoncentrowaë s ý na praktyce c égĥej ntegracj , a n e na narzýdziu Na eŜy czýsto ntegrowaë rozw ézan e, zachowywaë poprawnoļë komp acj aktua zowaë nfrastrukturý do udostýpn an a oprogramowan a

Wprowadzanie ciégĥej integracji NajwaĔniejszym aspektem wprowadzania ciñgäej integracji jest zachöcenie programistów do wyraĔenia zgody na czöste integrowanie (co kilka godzin) i bezwzglödne zachowywanie poprawnoĈci kompilacji. Zgoda zespoäu jest niezbödna, poniewaĔ nie moĔna zmusiè programistów, aby nie naruszali kompilacji.

222 ROZDZ AĤ 7

UDOSTüPN AN E

NaleĔy sprawiè, aby zespóä zgodziä siö na ciñgäñ integracjö, zamiast jñ narzucaè.

Czy integracja asynchroniczna nie jest bardziej wydajna od integracji synchronicznej? Choè na pozór moĔe siö wydawaè, Ĕe integracja asynchroniczna pozwala bardziej skutecznie Integracja synchroniczna wykorzystaè czas, w praktyce zwykle zakäóca zmniejsza problemy z integracjñ. przebieg pracy i prowadzi do naruszenia poprawnoĈci kompilacji. JeĈli kompilacja siö nie powiedzie, trzeba przerwaè nowe zadanie, aby anulowaè i poprawiè poprzednie zmiany. Oznacza to, Ĕe trzeba porzuciè pracö w poäowie, zmieniè kontekst (a czasem i partnera) w celu rozwiñzania problemu, a nastöpnie powróciè do obecnych zadaþ. Powoduje to marnowanie czasu i jest irytujñce. Zamiast przeskakiwaè miödzy zadaniami, wiele zespoäów pozwala, aby kompilacja nie dziaäaäa przez kilka najbliĔszych godzin, do momentu ukoþczenia obecnie wykonywanej pracy. JeĈli w tym czasie inna osoba zintegruje kod, nowe bäödy zostanñ ukryte przez istniejñce usterki. Problemy zacznñ siö nawarstwiaè i spowodujñ, Ĕe zespóä znajdzie siö w bäödnym kole: käopotliwe integracje prowadzñ do däuĔszych niedziaäajñcych kompilacji, co powoduje wiöcej problemów z integracjñ, a to dodatkowo utrudnia integrowanie. Widziaäem, jak w zespoäach stosujñcych integracjö asynchronicznñ kompilacja nie dziaäaäa przez caäe dnie. Warto takĔe pamiötaè, Ĕe kompilacja nie powinna zajmowaè däuĔej niĔ dziesiöè minut. Dziöki szybkiej kompilacji zakäadany brak wydajnoĈci integracji synchronicznej jest maäo istotny, zwäaszcza jeĈli moĔna wykorzystaè ten czas na przemyĈlenie pracy i porozmawianie o bardziej ogólnych aspektach projektu. Czy uwaĔasz, Ĕe integracja asynchroniczna nigdy nie jest dobrym rozwiñzaniem? MoĔna z powodzeniem stosowaè integracjö asynchronicznñ, jeĈli programiĈci bödñ w zdyscyplinowany sposób dbali o szybkie dziaäanie kompilacji, czösto przesyäali kod, uruchamiali kompilacjö lokalnie przed przesäaniem kodu i rozwiñzywali problemy bezpoĈrednio po ich wykryciu. Inaczej mówiñc, muszñ przestrzegaè wszystkich dobrych zasad ciñgäej integracji. Integracja synchroniczna sprawia, Ĕe programiĈci muszñ od razu poradziè sobie z wszelkimi problemami. To jest Ēródäo jej skutecznoĈci. Integracja asynchroniczna — niestety — zbytnio uäatwia ignorowanie wolnej lub niedziaäajñcej kompilacji. OczywiĈcie nie zawsze tak siö dzieje, jednak z moich doĈwiadczeþ wynika, Ĕe w zespoäach stosujñcych integracjö asynchronicznñ kompilacja dziaäa powoli lub jej poprawnoĈè jest naruszana duĔo czöĈciej niĔ w grupach uĔywajñcych integracji synchronicznej. Najlepiej wyraziä to Ron Jeffries11: Kiedy odwiedzam klientów stosujñcych kompilacjö asynchronicznñ, widzö, jak to dziaäa. Mogö uczciwie stwierdziè, Ĕe za kaĔdym razem:

1. „nocna” kompilacja przestaje dziaäaè przynajmniej raz w trakcie wizyty; 2. czerwona lampka kompilacji zapala siö przynajmniej raz w trakcie wizyty i Ĉwieci siö däuĔej niĔ godzinö.

11

Na liĈcie dyskusyjnej dotyczñcej sztuki zwinnego programowania: http://tech.groups.yahoo.com/group/ ´art-of-agile/message/365.

C èGĤA

NTEGRACJA 225

Fizyczny symbol integracji dziaäa tylko wtedy, jeĈli wszyscy programiĈci pracujñ w jednym miejscu. Zamiast tego symbolu moĔna uĔyè serwera do ciñgäej integracji lub elektronicznego symbolu integracji, jednak warto zadbaè o to, aby byä równie äatwy w uĔyciu i zauwaĔalny jak symbol fizyczny. Symbole integracji nie sprawdzajñ siö zbyt dobrze w bardzo duĔych zespoäach. Programistom zbyt wiele czasu zajmuje wtedy oczekiwanie na integracjö. W zamian moĔna uĔyè gaäözi prywatnych w systemie kontroli wersji. ProgramiĈci powinni przesyäaè kod do gaäözi prywatnej, kompilowaè tö gaäñĒ na maszynie do integracji (moĔe ich byè kilka), a nastöpnie przeksztaäcaè danñ gaäñĒ w gäównñ liniö, jeĈli kompilacja siö powiedzie.

Inne moŜliwoļci JeĈli nie moĔna stosowaè synchronicznej ciñgäej integracji, warto wypróbowaè serwer do ciñgäej integracji i integracjö asynchronicznñ. Prawdopodobnie spowoduje to wiöcej problemów niĔ integracja synchroniczna, jednak jest to najlepsze spoĈród innych rozwiñzaþ. W zespoäach, które nie korzystajñ z automatycznej kompilacji, stosowanie ciñgäej integracji jest niemoĔliwe. OpóĒnianie integracji to bardzo ryzykowne rozwiñzanie. NaleĔy jak najszybciej utworzyè automatycznñ kompilacjö i zaczñè stosowaè jednñ z odmian ciñgäej integracji. Niektóre zespoäy stosujñ codziennñ kompilacjö i testy wstöpne. Ciñgäa integracja to bardziej zaawansowana wersja tego rozwiñzania. JeĈli programiĈci uĔywajñ codziennej kompilacji i testów wstöpnych, mogñ zastñpiè je ciñgäñ integracjñ. NaleĔy zaczñè od integracji asynchronicznej i stopniowo usprawniaè kompilacjö i testy do momentu, kiedy moĔliwe bödzie wprowadzenie integracji synchronicznej.

228 ROZDZ AĤ 7

UDOSTüPN AN E

Wspóĥwĥasnoļë kodu Wszyscy odpowiadamy za rozwój kodu wysokiej jakoĈci.

Odb orcy P og amiļci

Istnieje miara ryzyka zwiñzanego z koncentracjñ wiedzy w umysäach maäej grupy osób. Jest to tak zwana „liczba ofiar”. Ile osób musi zostaè przejechanych przez ciöĔarówkö, zanim szkody w projekcie stanñ siö nie do naprawienia? To ponura wizja, jednak dotyczy realnego zagroĔenia. Co siö stanie, kiedy kluczowa osoba wyjedzie na wakacje, zostanie w domu z chorym dzieckiem, zmieni pracö lub nagle odejdzie na emeryturö? Ile czasu zajmie przeszkolenie nastöpcy? WspóäwäasnoĈè kodu pozwala przenieĈè odpowiedzialnoĈè za konserwacjö kodu na wszystkich programistów. WspóäwäasnoĈè kodu polega na tym, na co wskazuje nazwa: wszyscy odpowiadajñ za jakoĈè kodu. ēadna osoba nie moĔe ogäosiè siö wäaĈcicielem czöĈci systemu, a kaĔdy moĔe wprowadzaè potrzebne zmiany we wszystkich fragmentach kodu. WyĔsza jakoĈè kodu jest byè moĔe najwaĔniejszym aspektem wspóäwäasnoĈci kodu. PodejĈcie to NaleĔy rozwiñzywaè problemy pozwala, a nawet wiöcej: wymaga, aby wszyscy niezaleĔnie od miejsca rozwiñzywali wykryte problemy. JeĈli programista ich wykrycia. natrafi na powtórzenia, niejasne nazwy, a nawet Ēle zaprojektowany kod, nie powinien zwracaè uwagi na to, kto jest autorem danego fragmentu. To kod programisty i naleĔy go naprawiè.

Jak zapewnië wspóĥwĥasnoļë kodu? WspóäwäasnoĈè kodu wymaga pewnego rozluĒnienia wäasnego ego. Zamiast odczuwaè dumö z wäasnego kodu, programiĈci powinni byè dumni z kodu swego zespoäu. Programista zamiast narzekaè, kiedy inna osoba modyfikuje jego kod, powinien cieszyè siö, Ĕe kod staje siö lepszy, choè dany programista nad nim nie pracuje. Zamiast forsowaè wäasnñ wizjö projektu, naleĔy omówiè moĔliwoĈci z innymi programistami i uzgodniè wspólne rozwiñzanie. WspóäwäasnoĈè kodu wymaga od czäonków zespoäu wspólnego zaangaĔowania w rozwój kodu wysokiej Zawsze naleĔy choè trochö jakoĈci. Kiedy ktoĈ dostrzeĔe problem, powinien go ulepszyè zastany kod. rozwiñzaè. Nie naleĔy pisaè nowego kodu bez zaangaĔowania, z zaäoĔeniem, Ĕe inny programista poprawi bäödy. KaĔdy powinien tworzyè jak najlepszy kod. Z drugiej strony wspóäwäasnoĈè kodu oznacza, Ĕe nie zawsze trzeba dbaè o perfekcjö. JeĈli programista utworzyä kod, który dziaäa i ma doĈè wysokñ jakoĈè, ale nie wie, jak moĔe go ulepszyè, moĔe bez obaw pozostawiè go w obecnym stanie. W przyszäoĈci usprawni go ktoĈ inny, jeĈli (i kiedy) bödzie to potrzebne.

Praca nad nieznanym kodem JeĈli programista pracuje nad projektem, w którym wystöpujñ silosy wiedzy (ang. knowledge silo), czyli maäe fragmenty kodu zrozumiaäe tylko dla jednej lub dwóch osób, wspóäwäasnoĈè kodu moĔe rodziè obawy. Jak moĔna wziñè odpowiedzialnoĈè za kod, którego programista nie rozumie? WSPÓĤWĤASNOĻê KODU 229

Dokumentacja Skutecznie przekazujemy potrzebne informacje.

Odb orcy Ca y zespóĥ

Säowo dokumentacja ma wiele znaczeþ. MoĔe dotyczyè tekstu z instrukcjami dla uĔytkowników koþcowych, szczegóäowej specyfikacji lub objaĈnieþ interfejsu API i jego uĔytkowania. Zawsze jednak jest to pewna forma komunikacji, a cecha ta to wspólny element róĔnych materiaäów okreĈlanych mianem dokumentacji. Zespóä komunikuje siö przez caäy czas trwania projektu. Czasem komunikacja pomaga w wykonaniu zadania. Programista zadaje konkretne pytanie, otrzymuje odpowiedĒ, a nastöpnie uĔywa jej do rozwiñzania specyficznego problemu. Do tego säuĔy dokumentacja obecnych prac, na przykäad dokumentacja wymagaþ lub projektu. Inne rodzaje komunikacji mogñ zapewniaè wartoĈè biznesowñ. SäuĔy do tego na przykäad dokumentacja produktu, która obejmuje podröcznik uĔytkownika i dokumentacjö interfejsu API. Trzeci typ — dokumentacja zdawcza — sprzyja däugowiecznoĈci projektu, poniewaĔ gwarantuje, Ĕe osoby zajmujñce siö projektem w przyszäoĈci bödñ miaäy dostöp do potrzebnych informacji.

Dokumentacja obecnych prac W XP caäy zespóä pracuje wspólnie, aby uäatwiè komunikacjö pierwszego rodzaju. Bliski kontakt z ekspertami z dziedziny i uĔywanie wspólnego jözyka zapewniajñ skuteczny ustny przekaz, który pozwala uzyskaè informacje, kiedy sñ potrzebne. Komunikacji twarzñ w twarz nie da siö zastñpiè. Nawet rozmowy telefoniczne powodujñ utratö waĔnych niuansów w konwersacji. Zespoäy stosujñce XP uĔywajñ wytwarzania sterowanego testami do tworzenia kompleksowych zestawów testów. JeĈli prawidäowo stosujñ tö technikö, pozwala ona uchwyciè i przekazaè szczegóäy dotyczñce decyzji z obszaru implementacji w postaci jednoznacznych, wykonalnych specyfikacji projektu, które sñ czytelne i moĔliwe do realizacji, a inni programiĈci mogñ je modyfikowaè. Z kolei testy klienta säuĔñ do przekazywania informacji o trudnych do zrozumienia szczegóäach z dziedziny. Wspólny jözyk pomaga jeszcze lepiej pokazaè przeznaczenie i cel kodu. Zespóä dokumentuje pewne aspekty projektu, na przykäad uĔywa deklaracji wizji i karteczek z opowieĈciami, jednak säuĔñ one raczej do przypominania o zadaniach, niĔ stanowiñ formalnñ dokumentacjö. Zespóä moĔe (i powinien) w dowolnym momencie robiè pomocne w dalszej pracy notatki, na przykäad szkicowaè projekt na tablicy, dodawaè szczegóäy na karteczkach opowieĈci lub zapisywaè trudne do zapamiötania wymagania w wiki lub arkuszu kalkulacyjnym. Zespoäy stosujñce XP nie potrzebujñ tradycyjnej, pisanej dokumentacji, aby wykonywaè swe zadania. Praktyki XP wspomagajñ komunikacjö w obszarze obecnych prac w inny sposób, który jest bardziej skuteczny od tradycyjnej dokumentacji.

Dokumentacja produktu W niektórych projektach zespóä musi przygotowaè specyficznñ dokumentacjö, aby zapewniè wartoĈè biznesowñ produktu. Sñ to na przykäad podröczniki uĔytkownika, kompleksowe dokumentacje interfejsów API i raporty. Jeden z zespoäów, z którymi wspóäpracowaäem, musiaä przygotowaè miary pokrycia kodu, ale nie dlatego, Ĕe ich potrzebowaä. Po prostu

234 ROZDZ AĤ 7

UDOSTüPN AN E

tekstowej moĔe zmniejszyè zwinnoĈè, podczas gdy preferowanie komunikacji ustnej moĔe wymagaè wiöcej pracy zwiñzanej z rozpowszechnianiem informacji wĈród osób, które ich potrzebujñ.

Efekty JeĈli zespóä komunikuje siö w odpowiedni sposób, potrafi skutecznie przekazywaè potrzebne informacje, a koszty tego procesu sñ niskie. Ryzyko spada, poniewaĔ czäonkowie grupy przedstawiajñ tylko niezbödne dane.

Przeciwwskazania Alistair Cockburn opisuje odmianö programowania ekstremalnego, nazwanñ przez niego „Ĉmiaäym programowaniem”12: Programista stosujñcy Ĉmiaäe programowanie mówi: „NieĒle! AleĔ to programowanie ekstremalne jest uporzñdkowane! My teĔ prawie stosujemy to podejĈcie! Zobaczmy… Programowanie ekstremalne wymaga: x programowania w parach, x udostöpniania nowego kodu co trzy

13

tygodnie,

x ciñgäego przebywania uĔytkowników z zespoäem, x kaĔdorazowego przechodzenia przez kod jednostkowych testów regresji, x uĔywania automatycznych testów akceptacji, które okreĈlajñ dziaäanie systemu.

W zamian za to: x nie trzeba umieszczaè komentarzy w kodzie, x nie trzeba pisaè dokumentacji wymagaþ ani projektu.

W obecnym projekcie zbliĔyliĈmy siö do tego modelu: x Kilka osób pracuje w suterenie, niektórzy piszñ kod na piñtym piötrze, a jeszcze inni

— o dwie godziny jazdy stñd, dlatego nie stosujemy programowania w parach, x ponadto udostöpniamy nowy kod co 4 – 6 miesiöcy, x nie mamy uĔytkowników w zasiögu wzroku, x a takĔe nie uĔywamy Ĕadnych testów jednostek,

ale przynajmniej nie mamy Ĕadnej dokumentacji projektu14 i nie uĔywamy zbyt wielu komentarzy w kodzie! Dlatego pod tym wzglödem masz racjö, blisko nam do programowania ekstremalnego!”.

12

http://c2.com/cgi/wiki?PrettyAdventuresomeProgramming.

13

Obecnie wiökszoĈè zespoäów uĔywa jedno- lub dwutygodniowych iteracji. Grupom, które dopiero wprowadzajñ XP, zalecam iteracje jednotygodniowe. Zobacz podrozdziaä „Planowanie iteracji” w rozdziale 8.

14

WyróĔnienie za oryginaäem.

236 ROZDZ AĤ 7

UDOSTüPN AN E

238 ROZDZ AĤ 7

UDOSTüPN AN E

ROZDZIAĤ 8

Planowanie

W czasie pisania tego rozdziaäu rozmawiaäem ze znajomym, który chciaä siö dowiedzieè, jak organizujö projekty programistyczne. Jego zespóä szybko siö rozrósä, a próby przygotowania szczegóäowych planów i ich realizacji koþczyäy siö niepowodzeniem. „To siö po prostu nie skaluje” — westchnñä. Im wiökszy projekt, tym trudniej wszystko z góry zaplanowaè. Im bardziej chaotyczne Ĉrodowisko, tym wiöksze prawdopodobieþstwo, Ĕe w realizacji planów przeszkodzñ nieoczekiwane wydarzenia. Jednak w tym chaosie kryjñ siö moĔliwoĈci. Zamiast próbowaè uwzglödniè kaĔdñ okolicznoĈè, naleĔy skupiè siö na moĔliwoĈciach, jakie dajñ zmiany. To nastawienie znacznie róĔni siö od zaciskania szczök i piöĈci w obliczu nowych warunków. Dziöki proponowanemu nastawieniu zespóä z radoĈciñ wita niespodzianki. Zdumiewa siö moĔliwoĈciami w zakresie wykrywania i wykorzystywania nowych okazji. Rozciñga siö przed nim otwarta przestrzeþ. Wie, w którym kierunku zmierza, a przy tym jego plany sñ na tyle elastyczne, Ĕe moĔe wybraè najlepszñ drogö do celu. Kiedy zespóä znajdzie takñ drogö, bödzie o tym wiedziaä. MoĔe siö wydawaè, Ĕe w tym podejĈciu jest za maäo kontroli. RzeczywiĈcie, istnieje takie zagroĔenie, jeĈli zespóä nie przestrzega oĈmiu poniĔszych praktyk, które pozwalajñ kontrolowaè chaos zwiñzany z nieskoþczonñ iloĈciñ moĔliwoĈci. x Wizja pokazuje, jaki jest cel projektu i dlaczego zespóä chce go osiñgnñè. x Planowanie wydania prowadzi do utworzenia mapy wiodñcej do celu. x Gra planistyczna äñczy wiedzö caäego zespoäu w celu utworzenia wykonalnych planów. x Zarzñdzanie ryzykiem umoĔliwia zespoäowi podejmowanie i realizowanie

däugoterminowych zobowiñzaþ. x Planowanie iteracji zapewnia strukturö codziennych zadaþ zespoäu. x Zapas umoĔliwia grupie stabilne dokonywanie postöpów w kaĔdej iteracji. x OpowieĈci to elementy robocze w planach zespoäu. x Szacowanie pozwala zespoäowi przewidzieè czas wykonywania zadaþ.

239

MINI WPRAWKA Z „PLANOWANIA” a wprawka sĥuŜy do omów en a wpĥywu zm an na wartoļë Zespoĥy poznajéce dop ero wytwarzan e zw nne mogé uŜyë jej do epszego zrozum en a ce u projektu wa toļc , jaké dodaje kaŜda opow eļë Doļw adczen uŜytkown cy zw nnego podejļc a mogé przejrzeë rozdz aĥ 14 uŜyë tej wprawk jako narzýdz a pomocn czego p zy adaptacj p anów Na eŜy ëw czyë tý wprawký p zez póĥ godz ny kaŜdego dn a do momentu, k edy da sze wykonywan e jej p zestan e dawaë efekty Na poczétku zm eszczen e s ý w term n e moŜe spraw aë prob emy Jeļ wprawka stan e s ý nudna, na eŜy zastanow ë s ý, jak wprowadz ë zm any, które jé oŜyw é Potrzebne sé ka teczk w trzech róŜnych ko orach, pusty stóĥ ub tab ca na zýdz a do p san a Krok 1 Podz aĥ zespoĥu na pary, naj ep ej zróŜn cowane Krok 2. NaleŜy ograniczyë go do piýciu minut. KaŜda para wyb era n eopracowané jeszcze opow eļë stara s ý usta ë, d aczego jest wartoļc owa d a k enta Na eŜy zap saë gĥówny powód na karteczce Krok 3. NaleŜy ograniczyë go do piýciu minut. KaŜda para wymyļ a pomysĥy, które mogé doprowadz ë do zw ýkszen a wartoļc MoŜna je oprzeë na stn ejécej opow eļc ub utworzyë zupeĥn e nowé Na eŜy zap saë jeden pomysĥ na karteczce w nnym ko o ze Krok 4. NaleŜy ograniczyë go do piýciu minut. Pa y projektujé eksperyment, któ y bez wypróbowywania samej idei pozwo sprawdz ë, czy býdz e dz aĥaĥa w praktyce Co moŜna zrob ë, aby przetestowaë pomysĥ? Na eŜy op saë eksperyment na karteczce w t zec m ko orze Krok 5. NaleŜy ograniczyë go do 15 minut. Wszyscy znów pracujé razem Na eŜy wybraë trzy pary KaŜda z n ch pow nna p zez p ýë m nut poprowadz ë dyskusjý na temat swojego pomysĥu Na czas wykonywan a tej wprawk na eŜy um eļc ë karteczk z czwa tego kroku na sto e ub przyp éë je do tab cy W trakc e dyskusj moŜna omów ë nastýpujéce zagadn en a x Jak e aspekty wartoļc pojaw ĥy s ý na karteczkach? x Które pomysĥy sé trudne do zrea zowan a, a które ĥatwe? x W jak m stopn u wykonywana praca w éŜe s ý z potencja né wa toļc é projektu? x Które eksperymenty wa to p zeprowadz ë w trakc e nastýpnej teracj ?

240 ROZDZ AĤ 8

P ANOWAN E

Wizja Wiemy, dlaczego nasza praca jest waĔna i jak odnieĈè sukces.

Odb orcy MenedŜe p oduktu klienci

Wizja. SpoĈród pojöè ze säownictwa korporacyjnego chyba Ĕadne inne säowo nie jest tak czöstym przedmiotem Ĕartów. Przywodzi ono na myĈl przemowy, w których przedstawiciel korporacji chce siö wszystkim przypodobaè: „Naszñ wizjñ jest säuĔba klientom przy jednoczesnej maksymalizacji zysków udziaäowców i pielögnacji wartoĈci rodzinnych wĈród naszych pracowników”. Bla, bla, bla. Pozbawione treĈci nonsensy. Bez obaw — nie tym zajmujñ siö zespoäy w XP.

Wizja produktu Przed uruchomieniem projektu ktoĈ w firmie musi wpaĈè na pomysä. ZaäóĔmy, Ĕe jest to osoba z firmy Wizel-Frobic1. „Hej!” — mówi ta osoba, zrywajñc siö z äóĔka. „MoglibyĈmy frobicowaè wizle znacznie lepiej, gdybyĈmy mieli oprogramowanie do sortowania wizli!”. Zwykle nie odbywa siö to w tak spektakularny sposób. WaĔne jest to, Ĕe projekty rozpoczynajñ siö od pomysäów skoncentrowanych na efektach. Sprzedaè wiöcej sprzötu, przygotowaè pakiet lepszego oprogramowania, przyciñgnñè zamoĔniejszych klientów dziöki skuteczniejszemu skalowaniu rozwiñzania lub wejĈè na nowy rynek, oferujñc nowe usäugi. Pomysä jest tak przekonujñcy, Ĕe firma przyznaje fundusze i uruchamia projekt. Czösto po drodze miödzy pomysäem a projektem ten przekonujñcy element — wizja lepszej przyszäoĈci — zostaje zagubiony. Uwagö zaczynajñ przyciñgaè szczegóäy. Trzeba zatrudniè programistów, ekspertów z dziedziny i projektantów interakcji. Trzeba utworzyè opowieĈci, zaplanowaè iteracje i informowaè o postöpach. Szybciej, ludzie, szybciej! To Ēle, poniewaĔ nic nie jest waĔniejsze od realizacji wizji. Celem caäego projektu jest umoĔliwienie lepszego frobicowania wizli. JeĈli szczegóäy sñ w peäni dopracowane (program sortuje wizle precyzyjnie i w elegancki sposób), ale zapomniano o wizji (sortownica wizli nie wspóäpracuje z frobicerem), oprogramowanie prawdopodobnie nie bödzie przydatne. Z kolei jeĈli zespóä udostöpni mechanizm, który pomaga frobicowaè wizle lepiej niĔ jakiekolwiek inne oprogramowanie, czy bödzie miaäo znaczenie, jak to zrobiä?

Skéd pochodzi wizja? Czasem wizja projektu pojawia siö w formie pojedynczej, przekonujñcej idei. Jedna osoba wpada na doskonaäy pomysä, przekonuje do niego innych i otrzymuje zezwolenie na jego realizacjö. Ta osoba to wizjoner. Jednak czöĈciej wizja nie jest tak jasna. Jest wielu wizjonerów, a kaĔdy z nich ma wäasne wyobraĔenie na temat korzyĈci, jakie powinien przynieĈè projekt. W obu przypadkach potrzebna jest jedna wizja produktu. KtoĈ musi ujednoliciè wizjö oraz przekazaè jñ i promowaè wĈród zespoäu oraz udziaäowców. Tñ osobñ jest menedĔer produktu. 1

Nie jest to nazwa prawdziwej firmy.

W ZJA

241

Ustalanie wizji Podobnie jak w dzieciöcej grze w telefon, kaĔdy etap poĈredni miödzy wizjonerami a menedĔerem produktu utrudnia temu ostatniemu prawidäowe przekazywanie wizji i jej efektywnñ promocjö. JeĈli w zespole znajduje siö tylko jeden wizjoner, jest on najlepszym kandydatem na menedĔera produktu. Zmniejsza to prawdopodobieþstwo pomyäek zwiñzanych z „grñ w telefon”. JeĈli wizja jest zarówno wartoĈciowa, jak i osiñgalna, codzienne zaangaĔowanie wizjonera jako menedĔera produktu znacznie zwiöksza szanse na to, Ĕe projekt doprowadzi do powstania doskonaäego produktu. JeĈli wizjoner nie moĔe w peäni uczestniczyè w pracach zespoäu, co zdarza siö doĈè czösto, ktoĈ inny musi peäniè funkcjö menedĔera produktu. NaleĔy poprosiè wizjonera, aby poleciä zaufanego pomocnika lub podwäadnego. Musi to byè osoba, która regularnie spotyka siö z wizjonerem i rozumie sposób jego myĈlenia. Czösto w projekcie uczestniczy wielu wizjonerów. Dzieje siö tak przede wszystkim przy rozwoju niestandardowego oprogramowania. W takich sytuacjach potrzebna jest pomoc wizjonerów w poäñczeniu ich pomysäów w jednñ, spójnñ wizjö. Jednak zanim zespóä posunie siö za daleko, naleĔy zadaè sobie pytanie, czy nie lepiej bödzie uruchomiè kilka projektów. Czy poszczególne wizje znacznie róĔniñ siö od siebie? Czy moĔna realizowaè je po kolei, po jednej wizji jednoczeĈnie, jako odröbne projekty rozwijane przez ten sam zespóä na podstawie pojedynczego kodu bazowego? JeĈli tak, najlepszym rozwiñzaniem moĔe okazaè siö uruchomienie kilku projektów. JeĈli nie moĔna rozdzieliè wizji (a warto to zrobiè), zespóä czeka trudne zadanie. MenedĔer produktu ma wtedy inne zadania. Zamiast samemu peäniè funkcjö wizjonera, powinien moderowaè dyskusje miödzy wieloma wizjonerami. Najlepszym kandydatem na to stanowisko jest osoba, która dobrze rozumie zagadnienia biznesowe, zna juĔ wszystkich wizjonerów, ma zdolnoĈci polityczne i jest dobrym moderatorem. Trafniejszym okreĈleniem menedĔera produktu w takich projektach jest moderator produktu lub coach klientów, jednak z uwagi na spójnoĈè pozostanö przy nazwie menedĔer produktu.

Dokumentowanie wizji Po utworzeniu spójnej wizji w wyniku wspóäpracy z wizjonerami, naleĔy udokumentowaè jñ w deklaracji wizji. Najlepiej zrobiè to w grupie, poniewaĔ pozwala to ujawniè niezrozumiaäe i sporne obszary. Bez deklaracji wizji zbyt äatwo jest pominñè odmienne opinie i utworzyè niezadowalajñcy produkt. Gotowa wizja produktu pomaga w jej utrzymywaniu i promowaniu. Peäni funkcjö narzödzia pomocnego przy omawianiu wizji i punktu odniesienia przypominajñcego udziaäowcom o tym, dlaczego projekt jest wartoĈciowy. Nie naleĔy zapominaè o tym, Ĕe deklaracja wizji powinna byè elastycznym dokumentem. MenedĔer produktu powinien regularnie go przeglñdaè i wprowadzaè poprawki. Jednak jest to podstawowa deklaracja celu projektu, dlatego zmiany nie powinny byè zbyt duĔe.

242 ROZDZ AĤ 8

P ANOWAN E

Efekty Kiedy projekt ma jasnñ i przekonujñcñ wizjö, ustalanie priorytetów opowieĈci jest proste. Zespóä potrafi äatwo okreĈliè, które opowieĈci warto zrealizowaè, a które moĔna pominñè. ProgramiĈci majñ wkäad w analizy planistyczne, sugerujñc rozwiñzania, które umoĔliwiajñ maksymalizacjö wartoĈci przy jednoczesnej minimalizacji kosztów rozwoju. Plan wydania obejmuje mniejsze fragmenty, które zapewniajñ wartoĈè. Kiedy wizjoner dobrze promuje wizjö, wszyscy rozumiejñ, dlaczego projekt jest waĔny dla firmy. Czäonkowie zespoäu majñ wysokie morale, udziaäowcy bardziej ufajñ grupie, a organizacja wspomaga rozwój projektu.

Przeciwwskazania W projekcie zawsze naleĔy dñĔyè do ustalenia jednolitej wizji, nawet jeĈli zespóä ryzykuje odkrycie, Ĕe nie moĔna jej uzgodniè. JeĈli projekt nie jest wart realizacji, lepiej anulowaè go na poczñtku niĔ po poniesieniu wysokich kosztów.

Inne moŜliwoļci Niektóre spoäecznoĈci projektowe sñ tak maäe i ĈciĈle powiñzane, Ĕe wszyscy dobrze znajñ wizjö. Jednak nawet w takich grupach korzystne bywa przygotowanie jednostronicowej deklaracji wizji. Jedynñ alternatywñ dla jasnej wizji jest wizja niezrozumiaäa lub jej caäkowity brak.

Dalsza lektura Inspiracjñ dla niektórych pomysäów w tym podrozdziale byäy warsztaty Mastering Projects prowadzone przez firmö True North pgs, Inc. JeĈli Czytelnik ma moĔliwoĈè wziñè w nich udziaä, gorñco do tego zachöcam.

246 ROZDZ AĤ 8

P ANOWAN E

Planowanie wydania Planujemy, aby osiñgnñè sukces.

Odb orcy MenedŜe p oduktu klienci

WyobraĒmy sobie zespóä, który zostaä uwolniony z pöt terminów. „Zapewnijcie maksymalny zwrot z inwestycji” — mówi dyrektor. „RozmawialiĈmy juĔ o wizji projektu. Liczö na to, Ĕe sami dopracujecie szczegóäy. Przygotujcie wäasne plany i ustalcie daty wydania. Pamiötajcie jednak o wysokim zwrocie z inwestycji”. Co dalej?

Jeden projekt w danym momencie Przede wszystkim naleĔy rozwijaè w kaĔdym momencie tylko jeden projekt. Wiele zespoäów pracuje równolegle nad kilkoma projektami, co nie jest dobrym rozwiñzaniem. Przeäñczanie siö miödzy zadaniami wiñĔe siö z wysokimi kosztami: „Minimalne koszty to 15% […]. Pracownicy o fragmentarycznej wiedzy mogñ wyglñdaè na bardzo zajötych, jednak ich praca to w duĔym stopniu po prostu chaotyczne przeskakiwanie miödzy zadaniami” [DeMarco 2002]. Koncentracja na jednym projekcie umoĔliwia udostöpnienie go bezpoĈrednio po ukoþczeniu, co zwiöksza äñcznñ wartoĈè pracy zespoäu. WyobraĒmy sobie zespóä pracujñcy nad dwoma projektami. W tym uproszczonym przykäadzie kaĔdy z nich ma równñ wartoĈè. Po ukoþczeniu projekt zapewnia co miesiñc $$ zysku. Ukoþczenie kaĔdego projektu wymaga trzech miesiöcy.

UWAGA Choè do przedstawiania wartoĈci uĔywam symboli dolara, pieniñdze nie sñ jedynym Ēródäem zysku. WartoĈè moĔe równie dobrze byè nieuchwytna.

W scenariuszu A (rysunek 8.1) zespóä pracuje nad oboma projektami równolegle. Aby uniknñè kosztów zwiñzanych z czöstym przeäñczaniem siö miödzy zadaniami, grupa zmienia projekt co miesiñc. Zespóä ukoþczy projekt 1 po piöciu miesiñcach, a projekt 2 — po szeĈciu. Pod koniec siódmego miesiñca zyski wyniosñ $$$$$$. W scenariuszu B zespóä pracuje nad projektami po kolei. Projekt 1 jest gotowy pod koniec trzeciego miesiñca. Zaczyna wtedy zarabiaè pieniñdze, podczas gdy zespóä pracuje nad projektem 2, który — podobnie jak w poprzednim scenariuszu — jest gotowy pod koniec szóstego miesiñca. Choè wydajnoĈè zespoäu jest taka sama (ukoþczenie projektów w obu przypadkach zajmuje szeĈè miesiöcy), w drugim scenariuszu zespóä zarobiä wiöcej pieniödzy na projekcie 1. Pod koniec siódmego miesiñca przychód wyniósä $$$$$$$$$$. To niemal dwa razy wyĔszy zarobek bez ponoszenia dodatkowych nakäadów. Jest to tak äatwe, Ĕe powinni tego zabroniè. Jednak naprawdö zdumiewajñce jest, jak wiele zespoäów mimo to pracuje jednoczeĈnie nad kilkoma projektami.

Wczesne i czýste udostýpnianie Wczesne udostöpnianie to jeszcze lepsze rozwiñzanie przy pracy nad jednym projektem. JeĈli zespóä poäñczy najbardziej wartoĈciowe funkcje i udostöpni najpierw wäaĈnie je, moĔe uzyskaè zaskakujñcy wzrost wartoĈci. P ANOWAN E WYDAN A 247

Rysunek 8.1. Wpäyw równolegäego wykonywania zadaþ na wartoĈè

Zastanówmy siö nad nastöpnym przykäadem. Zespóä pracuje nad tylko jednym projektem. W scenariuszu A (rysunek 8.2) grupa kompiluje i udostöpnia oprogramowanie po szeĈciu miesiñcach. Projekt jest wart $$$$$ na miesiñc, dlatego pod koniec siódmego miesiñca zysk wyniesie $$$$$.

Rysunek 8.2. Wpäyw czöstych wydaþ na wartoĈè

W scenariuszu B zespóä äñczy najbardziej wartoĈciowe funkcje, opracowuje je jako pierwsze, a nastöpnie udostöpnia po trzech miesiñcach. Pierwsze wydanie zaczyna przynosiè zysk w wysokoĈci $$$ na miesiñc. Nastöpnie zespóä zaczyna pracö nad pozostaäymi funkcjami i udostöpnia je pod koniec szóstego miesiñca. TakĔe w tym przypadku w obu scenariuszach grupa pracuje równie wydajnie. RóĔnica polega wyäñcznie na planie udostöpniania. Jednak

248 ROZDZ AĤ 8

P ANOWAN E

dziöki dochodom z pierwszego wydania zespóä pod koniec siódmego miesiñca wygenerowaä äñczne zyski w wysokoĈci $$$$$$$$$$$$$$, czyli prawie trzykrotnoĈè tego, co zespóä w scenariuszu A, który udostöpniä tylko jednñ wersjö. Te scenariusze sñ z koniecznoĈci uproszczone. KsiñĔka Software by Numbers [Denne i ClelandHuang] zawiera bardziej zäoĔony przykäad, oparty na liczbach. Autorzy obliczyli wartoĈè caäego cyklu Ĕycia produktu (tabela 8.1) i przeksztaäcili piöcioletni projekt z dwoma wydaniami pod koniec projektu (scenariusz A) na piöè corocznych wydaþ uporzñdkowanych wedäug wartoĈci (scenariusz B). Podobnie jak w poprzednich przykäadach, wydajnoĈè pozostaäa na staäym poziomie. Tabela 8.1. Realistyczny przykäad skutków czöstych wydaþ

Ĥéczne koszty

Scenar usz A

Scenar usz B

4 3 miliona dola ów

4 712 miliona dola ów

P zychody

5 6 miliona dola ów

7 8 miliona dola ów

nwestycje

2 76 miliona dola ów

1 64 miliona dola ów

Zysk

1 288 miliona dola ów

3 088 miliona dola ów

Wa toļë bieŜéca netto p zy 10%

194 000 dola ów

1 594 miliona dola ów

Wewnýt zna stopa zw otu

12 8%

36 3%

Scenariusz A to maäo korzystna inwestycja, odpowiadajñca uzyskaniu stopy procentowej na poziomie 12,8%. Organizacja musi ponieĈè nakäady w wysokoĈci 2,76 miliona dolarów, a zyski to 1,288 miliona dolarów. Uwzglödniajñc ryzyko zwiñzane z wytwarzaniem oprogramowania, inwestorzy mogñ lepiej spoĔytkowaè swe zasoby. Nie naleĔy angaĔowaè siö w takie projekty. Scenariusz B — czyli ten sam projekt, jednak z czöstszymi wydaniami — to doskonaäa inwestycja, odpowiadajñca uzyskaniu stopy procentowej na poziomie 36,3%. Choè scenariusz B wymaga wiökszych nakäadów, poniewaĔ obejmuje wiöcej wydaþ, te wersje umoĔliwiajñ samofinansowanie projektu. Dlatego potrzebne inwestycje to tylko 1,64 miliona dolarów, a zyski wynoszñ 3,088 miliona dolarów. Warto zainwestowaè w taki projekt. NaleĔy jeszcze raz przyjrzeè siö wynikom. KaĔdy z tych przykäadów demonstruje znaczny wzrost wartoĈci. Jednak oprócz sposobu udostöpniania funkcji przez zespóä nic siö nie zmienia.

KORZYĻCI DLA PROGRAMISTÓW Czýste wydan a sé korzystne d a organ zacj Czy majé wa toļë d a program stów? Wydan a sé kĥopot we Wypadajé wo ne dn , repozytor um n e chce dz aĥaë, a term ny nag é Na eŜy uspoko ë s ý wz éë gĥýbok oddech Czýste wydan a tak naprawdý mogé uĥatw ë program stom pracý Regu arn e udostýpn ajéc przetestowane, dz aĥajéce wa toļc owe oprogramowan e udz aĥowcom, zespóĥ wzbudza zaufan e Udz aĥowcy Ŝédajé funkcj wkrótce w dzé efekty Szybko otrzymujé nformacje dz ýk krótk m odstýpom m ýdzy p anowan em wydan a a uzyskan em oprogramowan a akŜe zespóĥ szybko uzyskuje nformacje zwrotne od udz aĥowców UmoŜ w a to uczen e s ý przystosowywan e Sé teŜ techn czne korzyļc Jeden z sekretów XP po ega na tym, Ŝe wykonywan e trudnych zadaħ czýsto w maĥych fragmentach pozwa a usunéë w ýkszoļë zagroŜeħ praw e wszystk e prob emy Jeļ zespóĥ jest wystarczajéco zdyscyp nowany utrzymuje nfrastrukturý pot zebné do udostýpn an a wydan a w dowo nym momenc e (dz ýk c égĥej ntegracj dz es ýc om nutowej komp acj ), p zy udostýpn an u rozw ézan a wystarczy zwyk e przesĥaë kod uruchom ë komp etny zestaw testów P ANOWAN E WYDAN A 249

WyobraŚmy sob e wye m nowan e stresu zw ézanego ze ļ edzen em zm an wprowadzanych w k kunastu gaĥýz ach próbé jednoczesnego sca en a w e u nowych funkcj w ce u p zygotowan a demonstracj na potrzeby p zyszĥotygodn owego pokazu hand owego, o któ ym zespóĥ dow edz aĥ s ý w czwa tkowe popoĥudn e N e t zeba s ý tym martw ë, pon ewaŜ moŜna udostýpn ë rozw ézan e w dowo nym momenc e śyc e jest wtedy duŜo prostsze

Jak umoŜliwië czýste udostýpnianie kodu? Czöste udostöpnianie nie wymaga stosowania wymagajñcych terminów. Takie terminy zwykle wydäuĔajñ czas pracy, a nie skracajñ go [McConnell 1996, s. 220]. Z zamian naleĔy zwiökszyè czöstotliwoĈè udostöpniania kodu, ograniczajñc zakres kaĔdego wydania. Minimalny zestaw funkcji rynkowych [Danne i Cleland-Huang] to idealny mechanizm, który to umoĔliwia. Minimalny zestaw funkcji rynkowych (ang. minimal marketable feature — MMF) to najmniejszy zbiór funkcjonalnoĈci, który zapewnia wartoĈè na danym rynku. Nie jest przy tym istotne, czy ten rynek to wewnötrzni uĔytkownicy (jak w przypadku niestandardowego oprogramowania), czy klienci zewnötrzni (jak w przypadku oprogramowania komercyjnego). MMF jest wartoĈciowy w wielu aspektach, miödzy innymi ze wzglödu na odróĔnienie siö od konkurencji, generowanie zysków i oszczödnoĈci w kosztach. W trakcie tworzenia planu wydania warto myĈleè o wartoĈci, jakñ daje ono udziaäowcom. Czasem dobrze jest zastanowiè siö nad opowieĈciami i tym, jak wspólnie tworzñ pojedynczy MMF. W innych sytuacjach lepiej pomyĈleè o MMF, który moĔna póĒniej podzieliè na opowieĈci. Nie naleĔy zapominaè o minimalnym aspekcie funkcji rynkowych. KaĔda z nich powinna byè tak ograniczona, jak to moĔliwe. Po ustaleniu minimalnego zbioru funkcji naleĔy podzieliè je na moĔliwe wydania. Jest to èwiczenie nastawione na generowanie pomysäów, a nie ostatecznego planu, dlatego warto przygotowaè kilka sposobów pogrupowania. Warto zastanowiè siö nad sposobami na jak najwiöksze ograniczenie liczby funkcji w kaĔdym wydaniu. Najtrudniejsza czöĈè tego èwiczenia polega na ustaleniu, jak przygotowaè maäe wydania. Jednñ rzeczñ jest rynkowa wartoĈè funkcji, a innñ — wydania. Jest to szczególnie trudne, kiedy firma wprowadza nowy produkt. Aby odnieĈè sukces, naleĔy skoncentrowaè siö na tym, co wyróĔnia produkt, a nie na funkcjach niezbödnych do dorównania konkurencji.

Przykĥad WyobraĒmy sobie menedĔera produktu z zespoäu, który rozwija nowy edytor tekstu. Rynek takich edytorów jest doĈè dojrzaäy, dlatego przygotowanie maäego pierwszego wydania wydaje siö niemoĔliwe. Potrzeba tak wielu funkcji, aby tylko dorównaè konkurencji, a co dopiero udostöpniè coĈ nowego i fascynujñcego. Niezbödne jest proste formatowanie, sprawdzanie pisowni, sprawdzanie poprawnoĈci gramatycznej, tabele, obrazy, obsäuga drukowania — tö listö moĔna ciñgnñè w nieskoþczonoĈè. PodejĈcie do projektu rozwoju edytora tekstu w ten sposób jest tak przytäaczajñce, Ĕe äatwo zwñtpiè w sens podejmowania siö tego zadania. Zamiast próbowaè dorównaè konkurencji, naleĔy skoncentrowaè siö na funkcjach, które sprawiñ, Ĕe nowy edytor tekstu bödzie wyjñtkowy. Te funkcje naleĔy udostöpniè jako pierwsze, poniewaĔ prawdopodobnie majñ najwiökszñ wartoĈè.

250 ROZDZ AĤ 8

P ANOWAN E

WyróĔnikiem konkurencyjnym nowego edytora mogñ byè: bogata funkcjonalnoĈè w obszarze wspóäpracy i przechowywanie dokumentów w sieci. Pierwsze wydanie moĔe mieè cztery funkcje: podstawowe formatowanie, drukowanie, zapisywanie dokumentów w sieci i mechanizmy do obsäugi wspóäpracy. Zespóä moĔe udostöpniè to pierwsze wydanie jako technicznñ wersjö zapoznawczñ, aby zaczñè promocjö produktu. W póĒniejszych wersjach naleĔy usprawniè podstawowe funkcje i dodaè funkcjonalnoĈè usprawiedliwiajñcñ wprowadzenie opäat: tabele, obrazy i listy w jednym wydaniu, sprawdzanie pisowni i sprawdzanie poprawnoĈci gramatycznej w drugim i tak dalej. MoĔe wydawaè siö to nierozsñdnym podejĈciem, jednak w podobny sposób rozwijano Writely, internetowñ aplikacjö do edycji tekstu. Nie ma ona tak bogatych funkcji jak Microsoft Word i prawdopodobnie nie zmieni siö to przez wiele lat. Jednak jej autorzy skoncentrowali siö na elementach, które wyróĔniajñ tö aplikacjö na tle konkurencji: na wspóäpracy, zdalnej edycji dokumentów, bezpiecznym przechowywaniu w sieci i äatwoĈci uĔytkowania2. Wedäug inwestora Petera Ripa programiĈci udostöpnili pierwszñ wersjö alfa dwa tygodnie po podjöciu decyzji o rozwoju tej aplikacji3. Ile warte jest wczesne udostöpnianie? Warto spytaè o to wäaĈcicieli korporacji Google. Po dziesiöciu miesiñcach kupili oni Writely4, choè aplikacja ta wciñĔ nie miaäa funkcjonalnoĈci zbliĔonej do programu Microsoft Word5. Obecna nazwa Writely to Google Docs.

KLIENCI I CZüSTE WYDANIA „Nas k enc n e chcé aŜ tak czýstych wydaħ ” MoŜe to byë prawdé Czasem k entom n e odpow ada wysoka czýstot woļë udostýpn an a wydaħ p zez zespóĥ MoŜ we, Ŝe regu acje wymagajé ļc sĥych testów uzyskan a ce tyf katów przed nsta acjé nowych wersj Czasem sprzec w wobec czýstych wydaħ wyn ka z uk ytych kosztów aktua zacj MoŜ we, Ŝe aktua zacja wymaga trudnego ub drog ego procesu nsta acj MoŜ we teŜ, Ŝe w h stor f rmy zda zaĥo s ý, Ŝ n ezbýdna byĥa ser a poprawek, zan m nowe wydan e staĥo s ý stab ne N eza eŜn e od p zyczyn sprzec wu, k uczem do czýstych wydaħ jest zmn ejszen e rzeczyw stych ub post zeganych kosztów aktua zacj Warto dodaë funkcjý aktua zacj , która pow adam a uŜytkown ków o nowych wersjach nsta uje je automatyczn e MoŜna teŜ udostýpn ë dob ze przetestowane narzýdz a do aktua zacj , które automatyczn e przeksztaĥcajé dane uŜytkown ków Oprogramowan e przechowywane na serwerach, na p zykĥad ap kacje s ec owe, zapewn a maksyma né e astycznoļë w obsza ze udostýpn an a o podejļc e umoŜ w a udostýpn en e oprogramowan a w dowo nym momenc e, czýsto w sposób n ezauwaŜa ny d a uŜytkown ków N ektóre zespoĥy stosujéce XP, które rozw jajé oprogramowan e p zechowywane na serwerach majé dojrzaĥy zestaw gotowych funkcj , udostýpn ajé wydan a codziennie

2

http://www.writely.com/.

3

Writely is the seed of a Big idea, http://earlystagevc.typepad.com/earlystagevc/2005/09/writely_is_the_.html.

4

Writely — The Back Story, http://earlystagevc.typepad.com/earlystagevc/2006/03/sam_steve_and_j.html.

5

Only in a bubble is Google’s web WP an Office-killer, http://www.theregister.co.uk/2006/03/10/google_writely_analysis/.

P ANOWAN E WYDAN A

251

Przystosowywanie planów JeĈli samo czöste udostöpnianie umoĔliwia uzyskanie tak dobrych wyników, moĔna sobie wyobraziè, co zespóä osiñgnie, dodatkowo zwiökszajñc wartoĈè kaĔdego wydania. Jest to doĈè proste. Po kaĔdym udostöpnieniu naleĔy zebraè informacje zwrotne od udziaäowców, przerwaè pracö nad funkcjami, które okazaäy siö nieistotne, i skoncentrowaè wysiäki na zagadnieniach uznanych przez udziaäowców za najbardziej wartoĈciowe. W XP moĔna zmieniaè plany czöĈciej niĔ raz na wydanie. PodejĈcie to umoĔliwia dostosowywanie planów co kaĔdñ iteracjö. Dlaczego? Aby moĔna szybko reagowaè na nieoczekiwane wyzwania. Co jednak waĔniejsze, pozwala to wykorzystaè nadarzajñce siö okazje. Jakie jest ich Ēródäo? Zespóä sam je tworzy. Na poczñtku kaĔdego projektu rozwoju oprogramowania zespóä ma najmniejszñ wiedzö na temat tego, co zapewnia wartoĈè produktu. JeĈli nawet wie duĔo o jego wartoĈci, zawsze bödzie wiedziaä wiöcej, kiedy porozmawia z udziaäowcami, pokaĔe im demonstracjö i udostöpni wydanie. Wraz z czasem okaĔe siö, Ĕe niektóre poczñtkowe zaäoĔenia dotyczñce wartoĈci byäy nieprawdziwe. ēaden plan nie jest doskonaäy, jednak jeĈli zespóä zmienia plan z uwagi na uzyskane informacje, czyli jeĈli przystosowuje siö do sytuacji, powiöksza wartoĈè produktu. Aby zwiökszyè wartoĈè oprogramowania, naleĔy tworzyè okazje do nauki. Trzeba myĈleè o planach nie tylko w kategoriach implementacji, ale i uczenia siö. NaleĔy skoncentrowaè siö na elementach nieznanych zespoäowi. Czego grupa nie jest pewna? Co moĔe okazaè siö dobrym pomysäem? Które ciekawe idee moĔna sprawdziè w praktyce? Nie wystarczñ spekulacje — niezbödne sñ eksperymenty. NaleĔy przygotowaè sposób testowania elementów, których dziaäania zespóä nie jest pewien. Na przykäad zespóä tworzñcy sieciowy edytor tekstu z opcjñ wspóäpracy moĔe nie mieè pewnoĈci, jak bogate powinny byè opcje w obszarze importowania dokumentów programu Microsoft Word. Obsäuga tej czynnoĈci jest niezbödna, ale w jakim stopniu? Implementacja moĔliwoĈci importowania wszystkich dokumentów edytora Word wymaga zbyt duĔo czasu i uniemoĔliwia dodanie innych, prawdopodobnie bardziej wartoĈciowych funkcji. Z kolei zbyt ograniczona obsäuga moĔe zmniejszyè wiarygodnoĈè i zniechöciè klientów. Aby to sprawdziè, moĔna dodaè do oprogramowania prostñ funkcjö importu (wyraĒnie oznaczonñ jako „eksperymentalna”) i udostöpniè jñ. Funkcja ta powinna generowaè raporty dotyczñce typów dokumentów, które prawdziwi uĔytkownicy próbujñ importowaè. Te informacje pomogñ przystosowaè plany i zwiökszyè wartoĈè produktu.

UWAGA UĔytkownicy internetu sñ przyzwyczajeni do wersji „beta” aplikacji sieciowych, dlatego udostöpnienie funkcji eksperymentalnej jest w tym kontekĈcie dopuszczalne. Projekt skierowany do bardziej wymagajñcych uĔytkowników moĔe wymagaè przygotowania wstöpnej wersji programu, sesji z udziaäem grupy fokusowej lub innych mechanizmów uzyskiwania informacji zwrotnych.

252 ROZDZ AĤ 8

P ANOWAN E

Zachowanie elastycznoļci Aby jak najlepiej wykorzystaè tworzone okazje, naleĔy przygotowaè plan, który umoĔliwia udostöpnienie oprogramowania w dowolnym momencie. Nie chcö przez to powiedzieè, Ĕe naleĔy rzeczywiĈcie przez caäy czas udostöpniaè rozwiñzanie, a jedynie, Ĕe powinno to byè moĔliwe. Do czego to säuĔy? Pozwala to zespoäowi zachowaè elastycznoĈè. JeĈli pojawi siö waĔna, ale caäkowicie W dowolnym momencie zespóä nowa okazja, moĔna udostöpniè przygotowany powinien mieè moĔliwoĈè fragment i natychmiast zmieniè kierunek, aby udostöpniania produktu wykorzystaè nowe moĔliwoĈci. TakĔe jeĈli zdarzy o wartoĈci proporcjonalnej siö katastrofa, na przykäad projekt zostanie do poniesionych nakäadów. nieoczekiwanie anulowany, moĔna mimo to udostöpniè oprogramowanie w jego obecnej postaci. W kaĔdym momencie zespóä powinien mieè moĔliwoĈè udostöpniania produktu o wartoĈci proporcjonalnej do poniesionych nakäadów. Aby moĔna byäo udostöpniè rozwiñzanie w kaĔdym momencie, naleĔy zbudowaè plan w taki sposób, by kaĔda opowieĈè byäa niezaleĔna. Nastöpne opowieĈci mogñ byè oparte na poprzednich, ale kaĔda nowa powinna byè niezaleĔna od przyszäych. Na przykäad jednñ z pozycji planu moĔe byè „Udostöpnienie ekranu logowania”, a nastöpnñ — „Specyficzny dla klienta symbol na ekranie logowania”. Druga pozycja wzbogaca pierwszñ, ale mimo to pierwszñ moĔna udostöpniè niezaleĔnie. ZaäóĔmy, Ĕe zespóä tworzy system, który pobiera dane od uĔytkownika, sprawdza ich poprawnoĈè i zapisuje je w bazie danych. Poczñtkowo moĔna utworzyè opowieĈè dla wszystkich etapów: „Pobieranie danych”, „Sprawdzanie poprawnoĈci danych” i „Zapisywanie danych w bazie”. Czasem nazywa siö taki model porcjami poziomymi. Jest to äatwy sposób tworzenia opowieĈci, ale uniemoĔliwia udostöpnianie, a nawet skutecznñ ocenö oprogramowania, do momentu ukoþczenia wszystkich trzech historii. Zmniejsza to teĔ elastycznoĈè planowania, poniewaĔ trzy wymienione opowieĈci skäadajñ siö w planie na pakiet typu „wszystko albo nic”. Lepsze rozwiñzanie polega na utworzeniu opowieĈci, która obejmuje wszystkie trzy zadania, ale w mniej rozbudowanej wersji. Przykäadowo zespóä moĔe utworzyè opowieĈci „Przetwarzanie danych klienta”, „Przetwarzanie adresu wysyäki” i „Przetwarzanie informacji o päatnoĈci”. Sñ to tak zwane porcje pionowe (rysunek 8.3). Nie naleĔy zbytnio przejmowaè siö tym, Ĕe funkcjonalnoĈè opisana w opowieĈciach nie w peäni nadaje siö do udostöpnienia. Tworzenie w peäni niezaleĔnych historii wymaga praktyki. OpowieĈci gotowe do udostöpnienia zwiökszajñ elastycznoĈè planów, jednak nieliczne grupy funkcjonalne obejmujñce po kilka historii nie sñ specjalnie szkodliwe. Wraz z doĈwiadczeniem zespóä nauczy siö tworzyè bardziej eleganckie plany.

Jak przygotowaë plan wydania? Sñ dwa podstawowe typy planów: ograniczone w zakresie i ograniczone w czasie. Plany ograniczone w zakresie obejmujñ funkcje, które zespóä ma zbudowaè, ale nie zawierajñ terminów ich realizacji. W planach ograniczonych w czasie ustalona jest data wydania, ale nie ma w nich specyficznych funkcji, które ma ono zawieraè.

P ANOWAN E WYDAN A 253

KaŜda funkcja mus byë „w peĥn gotowa” p zed rozpoczýc em prac nad nastýpné Oznacza to, Ŝe trzeba zap anowaë opow eļc dotyczéce rapo tów, nterfejsu adm n stracyjnego, zabezp eczeħ, wydajnoļc , ska owa noļc , dopracowywan a nterfejsu uŜytkown ka nsta atorów Przede wszystk m trzeba zap anowaë opow eļc obejmujéce napraw an e bĥýdów na jak najb Ŝszy term n, chyba Ŝe zespóĥ uzna, Ŝ n e wa to ch napraw aë w danym wydan u

Planowanie w ostatnim momencie na podjýcie zobowiézaħ WymyĈlanie opowieĈci, szacowanie nakäadów pracy i okreĈlanie priorytetów zajmujñ wiele czasu. JeĈli zespóä na bieĔñco przystosowuje plan, niektóre wysiäki zmarnujñ siö. Aby ograniczyè ten problem, naleĔy planowaè w ostatnim momencie na podjöcie zobowiñzaþ. Ostatni moment na podjöcie zobowiñzaþ to ostatnia chwila, kiedy zespóä moĔe w odpowiedzialny sposób podjñè decyzjö (zobacz podrozdziaä „Pojöcia zwiñzane z XP” w rozdziale 3.). W praktyce oznacza to, Ĕe im wiöcej czasu pozostaäo do konkretnego wydarzenia, tym mniej szczegóäów plan musi zawieraè. MoĔna spojrzeè na to zagadnienie takĔe pod kñtem horyzontu planowania. OkreĈla on, jak daleko w przyszäoĈè zespóä patrzy. W wielu projektach grupy próbujñ okreĈliè z góry kaĔde wymaganie, dlatego ich horyzont planowania wykracza poza zakoþczenie projektu. Aby planowaè w ostatnim momencie na podjöcie zobowiñzaþ, naleĔy uĔyè zbioru warstw takich horyzontów. DäuĔsze horyzonty säuĔñ do ogólnych planów, a krótsze sñ odpowiednie dla planów konkretnych i szczegóäowych, jak przedstawia to rysunek 8.5.

Rysunek 8.5. Horyzonty planowania

256 ROZDZ AĤ 8

P ANOWAN E

Pytania Sñdziäem, Ĕe mamy udostöpniaè oprogramowanie co tydzieþ. Czy jest inaczej? Niektórzy mylñ iteracje z wydaniami. Choè zespóä powinien udostöpniaè oprogramowanie udziaäowcom kaĔdego tygodnia w ramach demonstracji iteracji, moĔe nie tworzyè wydaþ dla uĔytkowników koþcowych lub prawdziwych klientów równie czösto. Codzienne wydania to doskonaäy wybór, jeĈli moĔliwe jest ich udostöpnianie (zaleĔy to od potrzeb biznesowych). JeĈli nie zaplanujemy szczegóäowo caäego projektu, co powinniĈmy powiedzieè udziaäowcom o planach? Choè zespóä nie musi z góry planowaè wszystkich szczegóäów zwiñzanych z projektem, powinien mieè wystarczajñco duĔo informacji, aby móc przekazaè je udziaäowcom. NaleĔy zawsze pamiötaè o ogólnej wizji projektu. Wprawdzie to, jakie materiaäy sñ dostöpne, zaleĔy od horyzontów planowania, ale zespóä zwykle ma listö funkcji nastöpnego wydania oraz datö jej planowanego udostöpnienia. Dostöpne sñ teĔ konkretne, oszacowane opowieĈci na potrzeby najbliĔszych zadaþ. JeĈli udziaäowcy domagajñ siö wiöcej informacji lub wyĔszej przewidywalnoĈci, moĔliwe, Ĕe trzeba uwzglödniè däuĔszy horyzont planowania. W kaĔdym przypadku naleĔy poinformowaè udziaäowców o tym, Ĕe zespóä przedstawia obecny plan, który moĔe siö zmieniè, jeĈli grupa znajdzie lepsze sposoby na realizacjö wizji projektu. Planowanie w ostatnim momencie na podjöcie zobowiñzaþ oznacza, Ĕe nie potrafimy dokäadnie okreĈliè, co udostöpnimy. Czy nie wymaga to zbyt duĔego zaufania od udziaäowców? Wszelkie wysiäki programistyczne wymagajñ od organizacji wiary w to, Ĕe zespóä wykona powierzone zadania. JeĈli udziaäowcy wymagajñ szczegóäowego planu, aby móc zaufaè zespoäowi, naleĔy wydäuĔyè horyzont planowania, co umoĔliwi przedstawienie poĔñdanych planów. JeĈli uĔywamy krótkich horyzontów planowania, skñd moĔemy mieè pewnoĈè, Ĕe rozwiñzanie bödzie zgodne z wizjñ projektu? JeĈli zespóä nie jest pewien, czy realizuje wizjö projektu, powinien skoncentrowaè siö nad niñ w trakcie planowania. MoĔliwe, Ĕe trzeba wydäuĔyè horyzont planowania lub przygotowaè maäe wydanie o ograniczonej dostöpnoĈci w celu przetestowania kluczowych zaäoĔeþ. Szczegóäowe rozwiñzanie zaleĔy od sytuacji, dlatego jeĈli zespóä nie jest pewien, co zrobiè, powinien poprosiè o radö mentora. NiezaleĔnie od podjötej decyzji, naleĔy wyraĒnie przedstawiè swe obawy udziaäowcom i poinformowaè ich, jak zespóä zamierza poradziè sobie z niepewnoĈciñ.

Efekty Dziöki utworzeniu, utrzymywaniu i przekazywaniu dobrego planu wydania zespóä i udziaäowcy wiedzñ, dokñd zmierzajñ prace nad projektem. Plan pokazuje, w jaki sposób zespóä zamierza zrealizowaè wizjö projektu, a czäonkowie zespoäu majñ pewnoĈè, Ĕe stojñce przed nimi zadania sñ wykonalne. Grupa koþczy funkcje i udostöpnia wysokiej jakoĈci oprogramowanie regularnie i stabilnie.

P ANOWAN E WYDAN A 259

Pokazuje ona, jak okreĈlaè priorytety infrastruktury technicznej pod kñtem funkcji. Jednak charakterystyczny dla XP stopniowy rozwój projektu sprawia, Ĕe nie jest to konieczne. Zespoäy pracujñce nad dojrzaäym produktem, które nie muszñ wprowadzaè wielu zmian i usprawnieþ, nie zawsze potrzebujñ planu wydania. Zamiast myĈleè w kategoriach funkcji lub wydaþ, mogñ opieraè siö na maäym dzienniku niedokoþczonych opowieĈci i w kaĔdej iteracji udostöpniaè drobne poprawki. W niektórych przypadkach oprogramowanie jest instalowane codziennie. MoĔna myĈleè o tym podejĈciu jak o planowaniu przystosowawczym o bardzo krótkim horyzoncie planowania.

Dalsza lektura KsiñĔka Software by Numbers [Denne i Cleland-Huang] przedstawia przekonujñcy i szczegóäowy przypadek dowodzñcy wartoĈci czöstego udostöpniania wydaþ. Rozdziaä 15. ksiñĔki Agile Software Development Ecosystems [Highsmith] zawiera doskonaäe omówienie planowania przystosowawczego. W rozdziale 3. ksiñĔki Lean Software Development [Poppendieck i Poppendieck] autorzy omawiajñ odkäadanie decyzji i zachowywanie elastycznoĈci.

P ANOWAN E WYDAN A

261

Jak wygraë? Kiedy klienci i programiĈci wspóäpracujñ w trakcie gry, dzieje siö coĈ zdumiewajñcego. Nazywam to cudem wspóäpracy. To naprawdö cud, poniewaĔ znikñd pojawia siö dodatkowy czas. Ten cud, podobnie jak wszystkie inne, nie jest äatwy do osiñgniöcia. Kiedy programiĈci przedstawiajñ szacunki, klienci czösto zadajñ pytanie, które irytuje kaĔdego programistö: „Dlaczego to tak duĔo kosztuje?”. Instynktowna reakcja na takie pytanie to obrona: „Kosztuje tak duĔo, poniewaĔ rozwój oprogramowania jest trudny! Dlaczego zadajesz mi takie pytania!?”. Sñ lepsze sposoby reagowania. Warto przeksztaäciè pytanie klienta w prostñ proĈbö o informacje: „Dlaczego jest to drogie?”, a nastöpnie omówiè, co jest äatwe, a co trudne. WyobraĒmy sobie, Ĕe menedĔer produktu chce, aby toster automatycznie wyrzucaä tosty, kiedy sñ gotowe. Programista odpowiada, Ĕe taka funkcja jest bardzo kosztowna, a kiedy menedĔer produktu pyta, dlaczego, programista spokojnie odpowiada: „Samo wyrzucanie tostów jest äatwe — wystarczy uruchomiè spröĔynö. Jednak wykrycie, kiedy tost jest gotowy, to coĈ nowego. Potrzebny bödzie czujnik optyczny i niestandardowe oprogramowanie do wykrywania poziomu zarumienienia”. Daje to menedĔerowi produktu okazjö do zadania nastöpnego pytania: „A jak dziaäajñ tostery dostöpne na rynku? Na jakiej podstawie oceniajñ, Ĕe tost jest gotowy?”. Programista odpowiada: „UĔywajñ stopera, który tak naprawdö nie pozwala ustaliè, kiedy tost jest gotowy. To tylko obejĈcie problemu”. MenedĔer produktu moĔe wtedy odpowiedzieè: „To wystarczy. Nasi klienci nie oczekujñ super tostera. Chcñ zwykäego sprzötu. MoĔemy uĔyè stopera, jak robiñ to wszyscy inni producenci”. „W porzñdku. W takim razie koszty nie bödñ wysokie”. Dziöki szczerej i otwartej komunikacji miödzy klientami a programistami moĔe zdarzyè siö cud wspóäpracy, a dodatkowy czas pojawi siö znikñd. Bez dialogu klienci zwykle nie bödñ wiedzieè, co jest äatwe, a co nie, dlatego zaplanujñ opowieĈci trudne w implementacji. TakĔe programiĈci przewaĔnie nie wiedzñ, co jest waĔne dla klientów, dlatego implementujñ opowieĈci o niskiej wartoĈci. Dziöki wspóäpracy moĔna uzgodniè sprzeczne oczekiwania. Na przykäad klient moĔe poprosiè o maäo istotnñ, ale trudnñ funkcjö, a programista wskaĔe na koszty i zaproponuje äatwiejsze rozwiñzania. MenedĔer produktu moĔe dziöki temu zmieniè kierunek prac i zaoszczödziè czas, który nagle pojawia siö znikñd. To wäaĈnie jest cud wspóäpracy.

Pytania Czy programiĈci nie bödñ zawyĔaè szacunków, jeĈli majñ tak duĔñ kontrolö nad planem? Zgodnie z moim doĈwiadczeniem programiĈci to dobrze wyksztaäceni profesjonaliĈci z wysokñ motywacjñ do speäniania oczekiwaþ klientów. McConnell potwierdza moje przepuszczenia: „Twórcy oprogramowania lubiñ pracowaè. Najlepszy sposób na zmotywowanie programistów to udostöpnienie im Ĉrodowiska, które uäatwia koncentracjö na ulubionym zadaniu, czyli tworzeniu oprogramowania. […] ProgramiĈci majñ wysokñ motywacjö osiñgniöè. Bödñ

264 ROZDZ AĤ 8

P ANOWAN E

pracowaè w celu osiñgniöcia okreĈlonych celów, jednak trzeba poinformowaè ich o tym, czym sñ te cele” [McConnell 1996, s. 255 – 256]. Choè szacunki programistów mogñ wydawaè siö za wysokie, prawdopodobnie wynika to z tego, Ĕe nie chcñ wzbudzaè nierealistycznych oczekiwaþ. JeĈli okaĔe siö, Ĕe szacunki rzeczywiĈcie byäy za wysokie, szybkoĈè zespoäu wzroĈnie i automatycznie nastöpne iteracje bödñ obejmowaäy wiöcej zadaþ. Czy klienci nie pominñ waĔnych kwestii technicznych, jeĈli majñ tak duĔñ kontrolö nad planem? Klienci chcñ doprowadziè do powstania solidnego, przydatnego produktu. Muszñ zrównowaĔyè tö potrzebö z koniecznoĈciñ udostöpnienia produktu w odpowiednim momencie rynkowym. Dlatego czasem proszñ o dodanie opcji, które naruszajñ waĔne mechanizmy techniczne. Robiñ to, poniewaĔ nie znajñ technicznych niuansów równie dobrze jak programiĈci. Programista jest najbardziej wykwalifikowany do podejmowania decyzji technicznych, podobnie jak klienci to najlepsze osoby do decydowania o kwestiach biznesowych. Kiedy klient prosi o wyjaĈnienie szacunków, nie naleĔy opisywaè opcji technicznych. W zamian trzeba przetäumaczyè technologiö i opisaè dostöpne moĔliwoĈci w kategoriach wpäywu na biznes. Nie naleĔy opisywaè moĔliwych rozwiñzaþ w poniĔszy sposób: MyĈlimy o zastosowaniu w tym miejscu czujnika optycznego Mark 4 firmy Wizel-Frobic w celu optymalnego wykrywania gotowych tostów. MoglibyĈmy uĔyè takĔe spröĔynowego czasomierza Mark 1. Do obsäugi czujnika Mark 4 musimy napisaè niestandardowe oprogramowanie. Jest to bardzo skomplikowane i nowatorskie rozwiñzanie, jednak umoĔliwia dokäadne ustalenie poziomu zarumienienia chleba. Mark 1 to starsza technologia bez funkcji dynamicznego wykrywania gotowych tostów, jednak jej zastosowanie nie wymaga dodatkowego czasu. Które rozwiñzanie wolicie? Lepiej spróbowaè innego podejĈcia: Sñ dwa mechanizmy, których moĔemy uĔyè do wyrzucania tostów: czujnik optyczny lub czasomierz. Czujnik optyczny umoĔliwia przypieczenie chleba zgodnie z wymaganiami uĔytkowników, jednak jego zastosowanie wydäuĔa szacowany czas pracy o trzy dni. Czasomierz nie wymaga dodatkowych nakäadów pracy, ale wystöpuje wiöksze zagroĔenie wyrzucania niedopieczonych lub przypalonych tostów. Które rozwiñzanie wolicie? JeĈli dana opcja techniczna nie zostaäa uwzglödniona w opowieĈciach, nie naleĔy o niej wspominaè lub informowaè o niej przy okazji omawiania kosztów wykonywania zadaþ: PoniewaĔ jest to pierwsza instalacja, musimy zainstalowaè system kontroli wersji. WäñczyliĈmy jego koszty w szacunki dotyczñce pierwszej opowieĈci. MenedĔer produktu nie chce okreĈlaè priorytetów. Twierdzi, Ĕe wszystko jest waĔne. Co moĔemy zrobiè? NaleĔy postöpowaè stanowczo. Tak, wszystko jest istotne, jednak najpierw trzeba rozwinñè niektóre funkcje, a póĒniej inne. KtoĈ musi podjñè trudne decyzje dotyczñce harmonogramu. To zadanie menedĔera produktu.

GRA P AN STYCZNA 265

Koncentracja na efektach (a nie zadaniach) oraz moĔliwoĈè zrównowaĔonego uwzglödnienia wiedzy klientów i programistów sprawiajñ, Ĕe jest to najbardziej skuteczny ze znanych mi sposobów planowania rozwoju oprogramowania. Jednak jeĈli zespóä chce uĔyè innego podejĈcia, moĔe to zrobiè. Warto porozmawiaè z mentorem o tym, jak umoĔliwiè wspóädziaäanie preferowanego podejĈcia do planowania pracy z innymi praktykami XP.

GRA P AN STYCZNA 267

Zarzédzanie ryzykiem Podejmujemy däugoterminowe zobowiñzania i realizujemy je.

Odb orcy MenedŜe p ojektu caĥy zespóĥ

PoniĔszy akapit jest prawie prawdziwy: Nasz zespóä pracuje w przewidywalnym tempie w kaĔdej iteracji. PoniewaĔ w poprzednim tygodniu nasza szybkoĈè wyniosäa 14 punktów opowieĈci, w tym tygodniu zrealizujemy 14 punktów opowieĈci, podobnie jak w nastöpnym i jeszcze kolejnym. Dziöki poäñczeniu szybkoĈci i planu wydania moĔemy podjñè siö realizacji konkretnego harmonogramu wydania. Dobre zespoäy stosujñce XP potrafiñ utrzymaè staäñ szybkoĈè. Niestety, odzwierciedla ona wyäñcznie standardowe zagadnienia, z jakimi styka siö grupa. ēycie zawsze stawia na drodze zespoäu dodatkowe problemy. Czäonkowie grupy mogñ siö rozchorowaè lub wyjechaè na urlop. Dyski twarde psujñ siö, a choè kopie zapasowe sñ sprawne, przywracanie nie dziaäa. Udziaäowcy mogñ nagle stwierdziè, Ĕe oprogramowanie, które zespóä prezentowaä im przez ostatnie dwa miesiñce, wymaga powaĔnych poprawek, zanim bödzie gotowe do uĔytku. Mimo tych nieprzewidywalnych zdarzeþ udziaäowcy potrzebujñ planów i zobowiñzaþ, na których mogñ polegaè. Zarzñdzanie ryzykiem umoĔliwia podejmowanie i realizowanie takich zobowiñzaþ.

Ogólny plan zarzédzania ryzykiem W kaĔdym projekcie pojawiajñ siö standardowe zagroĔenia: fluktuacja kadr, nowe wymagania, zakäócenia w pracy i tak dalej. Te zagroĔenia zwielokrotniajñ szacunki, czasem podwajajñc lub potrajajñc iloĈè czasu potrzebnego na zakoþczenie pracy. W jakim stopniu te zagroĔenia mogñ wydäuĔyè pracö? ZaleĔy to od organizacji. W doskonaäym Ĉwiecie firma powinna mieè bazö danych z informacjami podobnymi do tych opisanych na rysunku 8.68. Pokazuje on szansö ukoþczenia zadania przy róĔnych mnoĔnikach zarzñdzania ryzykiem.

Rysunek 8.6. Przykäad danych historycznych dotyczñcych projektów 8

Przedruk z [Little].

268 ROZDZ AĤ 8

P ANOWAN E

MoĔliwe, Ĕe grupa od razu odrzuci niektóre zagroĔenia jako nieistotne. Ja ignorujö maäo prawdopodobne problemy o niskim wpäywie i wszystkie zagroĔenia o maäo znaczñcych konsekwencjach. Ogólny mnoĔnik zarzñdzania ryzykiem uwzglödnia juĔ takie moĔliwoĈci. Przy pozostaäych naleĔy okreĈliè, czy moĔna uniknñè ryzyka, rezygnujñc z ryzykownych dziaäaþ, uwzglödniè je, zapewniajñc dodatkowe nakäady i czas (podobnie jak przy zastosowaniu mnoĔnika zarzñdzania ryzykiem), lub zäagodziè, podejmujñc dziaäania w celu zmniejszenia wpäywu problemu. MoĔna teĔ poäñczyè dziaäania z róĔnych kategorii. MoĔliwe jest teĔ zignorowanie ryzyka, jednak skoro grupa uznaäa je za istotne, takie postöpowanie byäoby nieodpowiedzialne. Dla zagroĔeþ, którymi grupa zdecydowaäa siö zajñè, naleĔy ustaliè wskaĒniki ostrzegawcze, czynnoĈci äagodzñce i naprawcze oraz wagö ryzyka. x WskaĒniki ostrzegawcze okreĈlajñ pojawienie siö zagroĔenia. W naturze wiökszoĈci ludzi leĔy

bagatelizowanie ryzyka, dlatego naleĔy wybraè wskaĒniki obiektywne, a nie subiektywne. Na przykäad, jeĈli zagroĔenie to „nieoczekiwana popularnoĈè powoduje przedäuĔajñcy siö przestój”, wskaĒnikiem ostrzegawczym moĔe byè „trend wykorzystania mocy serwera wskazuje, Ĕe moĔna siö spodziewaè wykorzystania na poziomie ponad 80%”. x Dziaäania äagodzñce zmniejszajñ wpäyw zagroĔenia. Te czynnoĈci trzeba wykonaè z góry,

niezaleĔnie od wystñpienia problemu. NaleĔy przygotowaè opowieĈci opisujñce potrzebne dziaäania i wäñczyè je w plan wydania. MoĔliwe opowieĈci to na przykäad „obsäuga skalowania poziomego” i „przygotowanie mechanizmu równowaĔenia obciñĔenia”. x Dziaäania naprawcze takĔe zmniejszajñ wpäyw zagroĔenia, jednak sñ niezbödne tylko po

wystñpieniu problemu. Czösto zaleĔñ od wczeĈniej wykonanych czynnoĈci äagodzñcych. Na przykäad „zakup wiökszej przepustowoĈci od dostawcy”, „instalacja mechanizmu równowaĔenia obciñĔenia” i „zakup i przygotowanie dodatkowych serwerów czoäowych”. x Waga ryzyka okreĈla, ile czasu i pieniödzy trzeba zapewniè, aby uwzglödniè zagroĔenie.

Aby obliczyè te wartoĈci, naleĔy najpierw oszacowaè liczbowe prawdopodobieþstwo zagroĔenia, a nastöpnie pomnoĔyè je przez wpäyw problemu. Przy jego okreĈlaniu trzeba pamiötaè o tym, Ĕe zespóä poniósä juĔ koszty dziaäaþ äagodzñcych, jednak trzeba jeszcze dodaè nakäady na czynnoĈci naprawcze. Na przykäad grupa moĔe uwaĔaè, Ĕe prawdopodobieþstwo przestoju z uwagi na popularnoĈè wynosi 35%, a wpäyw tego problemu to trzy dodatkowe dni pracy programisty i 20000 dolarów opäaty za przepustowoĈè, kolokacjö i nowy sprzöt. ãñczna waga ryzyka to w takich warunkach 7000 dolarów i jeden dzieþ pracy. Niektóre zagroĔenia majñ 100-procentowe prawdopodobieþstwo wystñpienia. Nie sñ to juĔ zagroĔenia — to rzeczywistoĈè. NaleĔy poprawiè plan wydania i uwzglödniè w nim te problemy. Wystñpienie niektórych zagroĔeþ moĔe doprowadziè do zakoþczenia projektu. Przykäadowo reorganizacja firmy moĔe doprowadziè do rozwiñzania zespoäu. NaleĔy poinformowaè o tych zagroĔeniach wäaĈciciela projektu i podaè je jako zaäoĔenia lub wymagania („Zakäadamy, Ĕe w przypadku reorganizacji zespóä nie zmieni skäadu i wciñĔ bödzie pracowaä nad tym projektem”). Takimi problemami nie trzeba zarzñdzaè. Wystarczy udokumentowaè ich uwzglödnienie i ewentualnie zaplanowaè opowieĈci dotyczñce äagodzenia skutków. W przypadku pozostaäych zagroĔeþ naleĔy zaktualizowaè plan wydania i uwzglödniè je w nim. Konieczne bödñ opowieĈci obejmujñce dziaäania äagodzñce. MoĔliwe, Ĕe zespóä bödzie teĔ potrzebowaä opowieĈci pomocnych do kontrolowania wskaĒników ostrzegawczych. Na

ZARZèDZAN E RYZYK EM

271

W momencie wydania zespóä z 90-procentowym prawdopodobieþstwem ukoþczy nastöpne 86 punktów, z 50-procentowym — 110 punktów, a ma tylko 10% szans na ukoþczenie 154 dalszych punktów. MoĔna przedstawiè to graficznie na diagramie wykonanych zadaþ, przedstawionym na rysunku 8.710. KaĔdego tygodnia naleĔy odnotowaè, ile punktów opowieĈci zespóä ukoþczyä, ile äñcznie punktów obejmuje nastöpne wydanie (suma opowieĈci ukoþczonych i pozostaäych do opracowania) i zakres dostöpnych punktów z uwzglödnieniem ryzyka. NaleĔy umieĈciè te wartoĈci na diagramie wykonanych zadaþ, jak przedstawia to poniĔszy rysunek.

Rysunek 8.7. Diagram wykonanych zadaþ

NaleĔy uĔyè diagramu wykonanych zadaþ i planu wydania, aby przedstawiè udziaäowcom listö funkcji, które zespóä zobowiñzuje siö udostöpniè w dniu wydania. Ja zobowiñzujö siö do udostöpnienia funkcjonalnoĈci, którñ grupa przygotuje z 90-procentowym prawdopodobieþstwem, a funkcje z zakresu pomiödzy 50% a 90% przedstawiam jako ambitny cel. Nie wspominam o mechanizmach, których ukoþczenie jest prawdopodobne w mniej niĔ w 50%.

10

Wedäug Johna Brewera (http://tech.groups.yahoo.com/group/extremeprogramming/message/81856) diagram wykonanych zadaþ (ang. burn-up chart) zostaä wymyĈlony przez Phila Goodwina jako odmiana diagramów zadaþ do wykonania (ang. burn-down chart) z podejĈcia mäyn. Zmodyfikowaäem go dodatkowo, doäñczajñc zobowiñzania z uwzglödnieniem ryzyka.

ZARZèDZAN E RYZYK EM 273

za zaäoĔenia projektowe, czyli te zagroĔenia, których pojawienie siö moĔe zakoþczyè prace nad projektem. ZaäoĔenia zespoäu to zagroĔenia kierownictwa. Przedstawione mnoĔniki zarzñdzania ryzykiem sñ za wysokie. Czy moĔemy uĔyè niĔszych? Czy zastöpcze mnoĔniki sñ oparte na obiektywnych danych? Czy te dane sñ reprezentatywne dla typu prowadzonego projektu? JeĈli tak, moĔna ich uĔyè. W przeciwnym razie naleĔy zachowaè ostroĔnoĈè. MoĔna obniĔyè mnoĔniki, jednak zmiana zaplanowanego harmonogramu nie zmieni rzeczywistych efektów. UĔywamy planu z ograniczeniem zakresu prac, a udziaäowcy domagajñ siö konkretnej daty wydania, a nie zakresu opartego na ryzyku. Co powinniĈmy zrobiè? MenedĔer projektu lub menedĔer produktu powinni potrafiè przekonaè organizacjö do zaakceptowania zakresu dat opartego na ryzyku. NaleĔy porozmawiaè z tymi menedĔerami i ustaliè najlepszy sposób przedstawienia uwag zespoäu. JeĈli konkretna data jest niezbödna, naleĔy zdecydowaè siö na jeden mnoĔnik zarzñdzania ryzykiem. To, który z nich wybraè, zaleĔy od organizacji. WyĔszy mnoĔnik zarzñdzania ryzykiem zwiöksza szanse powodzenia, ale pogarsza wyglñd harmonogramu. Niski mnoĔnik sprawia, Ĕe plany wyglñdajñ zachöcajñco, ale zmniejsza prawdopodobieþstwo ich realizacji. Wiele organizacji przyzwyczaiäo siö do przekäadania daty udostöpnienia. MenedĔerowie w tych firmach intuicyjnie stosujñ nieformalne mnoĔniki zarzñdzania ryzykiem, kiedy säyszñ proponowane terminy. W organizacjach tego typu stosowanie wysokich mnoĔników zarzñdzania ryzykiem powoduje, Ĕe plany wyglñdajñ na niezwykle däugie. Warto przyjrzeè siö innym projektom realizowanym w organizacji. Czy zwykle sñ koþczone w terminie? Co siö dzieje, kiedy moment wydania siö opóĒnia? NaleĔy porozmawiaè z menedĔerem projektu i menedĔerem produktu o oczekiwaniach kierownictwa i udziaäowców. Takie dyskusje powinny pomóc w dostosowaniu mnoĔników zarzñdzania ryzykiem do organizacji. Warto jednak pamiötaè, Ĕe stosowanie przedziaäu dat opartego na ryzyku jest lepszym rozwiñzaniem, a harmonogram z ograniczeniem czasu to lepsze podejĈcie niĔ harmonogram z ograniczeniem zakresu prac.

Efekty Dziöki dobremu zarzñdzaniu ryzykiem zespóä realizuje zobowiñzania nawet w obliczu przeciwieþstw. Udziaäowcy ufajñ grupie i polegajñ na niej, poniewaĔ wiedzñ, Ĕe kiedy potrzebujñ czegoĈ trudnego i wartoĈciowego, zespóä nie zawiedzie ich oczekiwaþ i dostarczy taki produkt.

Przeciwwskazania Zarzñdzanie ryzykiem säuĔy wyäñcznie do podejmowania zewnötrznych zobowiñzaþ. W zespole naleĔy skoncentrowaè wysiäki na realizacji wyjĈciowego planu wydania zgodnie z harmonogramem. W przeciwnym razie prace prawdopodobnie przeciñgnñ siö poza wyznaczony termin. Rysunek 8.811 pokazuje, jak zwyczaj podwajania szacunków w pewnej firmie doprowadziä do tego, Ĕe wiökszoĈè projektów i tak nie byäa realizowana przed terminem, a liczba opóĒnionych projektów nie zmieniäa siö. 11

Przedruk z [Little].

276 ROZDZ AĤ 8

P ANOWAN E

Rysunek 8.8. Samo podwojenie szacunków

NaleĔy ostroĔnie uĔywaè zarzñdzania ryzykiem w organizacjach o nastawieniu typu „niepowodzenia sñ niedopuszczalne”. Zespóä moĔe spotkaè siö z krytykñ za wyszukiwanie zagroĔeþ. Grupa moĔe wtedy przedstawiè przygotowany z uwzglödnieniem ryzyka harmonogram jako zobowiñzanie lub ambitny cel, ale prezentacja spisu zagroĔeþ moĔe byè ryzykowna.

Inne moŜliwoļci Decyzja o stosowaniu zarzñdzania ryzykiem naleĔy przede wszystkim do organizacji, a nie do poszczególnych zespoäów. JeĈli firma ma juĔ formalne mechanizmy do zarzñdzania ryzykiem, mogñ one sugerowaè inne podejĈcie. Jedyny problem moĔe polegaè na integracji go z równoczesnymi fazami charakterystycznymi dla XP. W takiej sytuacji moĔna uĔyè informacji z tego podrozdziaäu jako punktu wyjĈcia i poprosiè mentora (zobacz podrozdziaä „Szukanie mentora” w rozdziale 2.) o wskazówki dostosowane do sytuacji. Niektóre organizacje dodajñ bufor ryzyka do poszczególnych szacunków, a nie do ogólnego harmonogramu projektu. Jak ilustruje to rysunek 8.8, zwykle prowadzi to do marnotrawstwa.

Dalsza lektura Autorzy ksiñĔki Waltzing with Bears: Managing Risk on Software Projects [DeMarco i Lister 2003] przedstawiajñ wiöcej szczegóäów na temat zarzñdzania ryzykiem i omawiajñ to zagadnienie z perspektywy organizacji. Mój ulubiony cytat pochodzi z okäadki ksiñĔki: „JeĈli w waszym nastöpnym projekcie nie ma ryzyka, nie warto go rozpoczynaè”.

ZARZèDZAN E RYZYK EM

277

Programista: [Liczy opowieĈci]. 14, czyli jak zwykle. MenedĔer produktu: [Pisze „SzybkoĈè = 14” na tablicy]. W porzñdku, przenieĈmy tablicö z planem wydania. [Pomaga przeciñgnñè tablicö do planowania, a nastöpnie wskazuje na niñ]. Wraz z innymi klientami musieliĈmy podjñè trudne decyzje po ostatnim wydaniu. UĔytkownikom bardzo siö podoba nasza praca. To dobrze. Przedstawiajñ teĔ wiele propozycji, co samo w sobie teĔ jest korzystne, jednak niektóre idee mogñ utrudniè realizacjö planów, czego powinniĈmy unikaè. Jednak nie musicie siö tym martwiè. W ostatecznoĈci zdecydowaliĈmy siö przynajmniej jeszcze w tej iteracji realizowaè stary plan. Zobaczmy, 14 punktów [rozpoczyna wybieranie opowieĈci z tablicy do planowania] 3, 5, 6, 7, 10, 12 i 14. [MenedĔer umieszcza opowieĈci na stole]. Uwaga, to nasza iteracja. Powodzenia. Muszö iĈè porozmawiaè z wicedyrektorem dziaäu. Maria bödzie w pobliĔu, aby odpowiadaè na wszelkie pytania dotyczñce tych opowieĈci. JeĈli ktoĈ bödzie mnie potrzebowaä, wrócö po poäudniu. Maria: Powodzenia, Borys. [MenedĔer produktu wychodzi]. OmawialiĈmy juĔ te opowieĈci, dlatego tylko pokrótce przypomnö… Po wybraniu opowieĈci rozwijanych w danej iteracji wszyscy oprócz programistów mogñ opuĈciè spotkanie, choè jeĈli ktoĈ chce na nim zostaè, jest mile widziany. W pobliĔu powinien pozostaè przynajmniej jeden klient, aby mógä odpowiedzieè na pytania programistów i zwróciè uwagö na zäe zrozumienie pewnych aspektów.

UWAGA Grupa bödñca ograniczeniem zespoäu okreĈla, ile pracy zespóä moĔe wykonaè w trakcie kaĔdej iteracji (wiöcej informacji na temat teorii ograniczeþ zawiera podrozdziaä „Pojöcia zwiñzane z XP” w rozdziale 3.). Zakäadam, Ĕe ograniczeniem sñ programiĈci, dlatego plan iteracji jest oparty wyäñcznie na ich zadaniach i szacunkach. Inni czäonkowie zespoäu mogñ przeprowadziè wäasne sesje planowania iteracji, jednak nie jest to konieczne.

W tym momencie rozpoczyna siö prawdziwa praca nad planowaniem iteracji. NaleĔy rozpoczñè od podziaäu opowieĈci na zadania inĔynieryjne. Zadania inĔynieryjne to konkretne prace do wykonania przez programistów. Takie zadania, w odróĔnieniu od opowieĈci, nie muszñ byè skoncentrowane na kliencie. NajwaĔniejszñ postaciñ jest tu programista. Typowe zadania inĔynieryjne to miödzy innymi: x aktualizowanie skryptów kompilacji, x implementacja logiki z dziedziny, x dodawanie tabel bazy danych i powiñzanych z nimi obiektów ORM, x tworzenie nowych formularzy interfejsu uĔytkownika.

NaleĔy wygenerowaè zadania potrzebne do ukoþczenia wszystkich opowieĈci wchodzñcych w skäad iteracji. Niektóre zadania bödñ specyficzne dla pojedynczej opowieĈci, inne — przydatne w wielu. NaleĔy skoncentrowaè siö na zadaniach niezbödnych do ukoþczenia opowieĈci z danej iteracji. Nie trzeba przejmowaè siö spotkaniami caäego zespoäu, urlopami lub innymi przeszkodami.

280 ROZDZ AĤ 8

P ANOWAN E

UWAGA Niektórych opowieĈci nieprogramistycznych, na przykäad dotyczñcych szacowania kosztów innych opowieĈci, nie moĔna podzieliè na zadania. NaleĔy oszacowaè je w kategoriach idealnych godzin (zobacz podrozdziaä „Szacowanie” w dalszej czöĈci rozdziaäu) i pozostawiè je w takiej postaci.

Generowanie zadaþ to czynnoĈè projektowa. JeĈli wszyscy majñ podobne zdanie na temat sposobu rozwoju oprogramowania, praca powinna toczyè siö doĈè szybko. JeĈli uczestnicy majñ odmienne opinie, jest to doskonaäa okazja do przeprowadzenia dyskusji przed rozpoczöciem pisania kodu. Nie trzeba poruszaè przy tym zbyt wielu szczegóäów. Ukoþczenie kaĔdego zadania inĔynieryjnego powinno zajñè parze od godziny do trzech. Odpowiada to okresowi od okoäo dwóch do szeĈciu godzin szacowanych nakäadów pracy. Pary same powinny ustaliè szczegóäy wykonania kaĔdego zadania, kiedy do niego dojdñ. Kiedy czäonek zespoäu ma pomysä na wykonanie zadania, powinien zapisaè go na karteczce, przeczytaè na gäos i umieĈciè na stole. Wszyscy mogñ pracowaè jednoczeĈnie. Powtarzajñce siö lub niewykorzystane pomysäy zawsze moĔna póĒniej usunñè. W trakcie pracy warto wykorzystaè obecnoĈè przedstawicieli klientów i zadaè im pytania na temat szczegóäowych wymagaþ dotyczñcych opowieĈci. Czego klienci spodziewajñ siö od danej opowieĈci? Amelia, Janek, Kasia, Franek, Bogusia i Jarek kontynuujñ pracö. Maria, jedna z przedstawicielek klienta, siedzi w pobliĔu i pisze list elektroniczny. „W porzñdku, znów siö spotykamy” — z kamiennñ minñ mówi Janek, naĈladujñc menedĔera produktu. Amelia chichocze. „Te opowieĈci wyglñdajñ na doĈè proste. Musimy zaimplementowaè nowñ logikö z dziedziny dla kaĔdej z nich. Wyglñda na to, Ĕe opowieĈè dotyczñca zatowarowania magazynu wpäynie na magazyn i klasy SKU”. Amelia bierze karteczkö i zapisuje: „Zaktualizowaè magazyn i klasy SKU pod kñtem zatowarowania magazynu”. „Skoro juĔ jesteĈmy przy produktach, jeĈli mamy przechowywaè wagö kaĔdego SKU, musimy zaktualizowaè klasö SKU takĔe pod tym kñtem” — wtrñca Bogusia. Bierze nastöpnñ karteczkö i pisze: „Zaktualizowaè klasö SKU i doäñczyè wagö”. Przerywa i zamyĈla siö na chwilö. „MoĔe to za maäo, aby robiè z tego zadanie”. Odzywa siö Jarek — „OpowieĈè dotyczñca wagi wiñĔe siö gäównie ze zmianñ interfejsu uĔytkownika. Musimy zaktualizowaè ekran konfiguracyjny SKU i ekran administracyjny. MoĔemy doäñczyè wagö do klasy SKU przy okazji tych zadaþ”. Jarek bierze nastöpnñ karteczkö i zaczyna pisaè. „Zaczekaj, Jarku” — Maria podnosi wzrok znad listu elektronicznego. „Czy powiedziaäeĈ, Ĕe waga wymaga tylko zmian w interfejsie uĔytkownika?”. „Tak” — potwierdziä Jarek. „To nie do koþca prawda” — stwierdziäa Maria. „Choè potrzebujemy moĔliwoĈci wpisania wagi do systemu przede wszystkim w celu póĒniejszego wykorzystania tych danych, chcemy teĔ, aby byäa widoczna w raporcie o stanie magazynu”. „Dobrze wiedzieè” — odpowiada Jarek, a nastöpnie zapisuje na karcie zadania: „Zaktualizowaè raport o stanie magazynu o wagö SKU”.

P ANOWAN E

TERACJ

281

Ponadto moĔna zastöpowaè tylko te historie, których opracowywania zespóä jeszcze nie rozpoczñä. Dwupunktowa opowieĈè ukoþczona w poäowie nie jest juĔ warta dwóch punktów, jednak nie jest to teĔ opowieĈè jednopunktowa. Trudno oceniè, ile pracy pozostaäo do momentu, kiedy bödzie „w peäni gotowa”, a jej zastñpienie spowoduje powstanie däugu technicznego w postaci nieukoþczonego kodu. Jednak przed wprowadzeniem jakichkolwiek zmian warto przypomnieè sobie, Ĕe nastöpne spotkanie poĈwiöcone planowaniu odbödzie siö juĔ za niecaäy tydzieþ. Zamiast wprowadzaè chaos w prace zespoäu, naleĔy odpowiedzieè sobie na pytanie, jak bardzo krytyczna jest sytuacja. Czösto takñ dodatkowñ opowieĈè moĔna dodaè w trakcie nastöpnego spotkania poĈwiöconego planowaniu. W koþcu odbödzie siö ono juĔ za kilka dni.

Batman Realizacja krytycznych Ĕñdaþ jest dopuszczalna, jeĈli nie zdarza siö to zbyt czösto. Jest to doskonaäy sposób na zwiökszenie szybkoĈci reakcji. Z kolei stan wyjñtkowy w kaĔdej iteracji oznacza problemy. Po drugiej lub trzeciej z rzödu iteracji, w której zgäoszono krytyczne Ĕñdanie, naleĔy zastanowiè siö nad sposobem pracy. MoĔe przedstawiciele klientów muszñ zachowaè wiökszñ dyscyplinö w trakcie planowania wydania? MoĔe trzeba stanowczo przypomnieè udziaäowcom, Ĕe Ĕñdania mogñ poczekaè do nastöpnej iteracji? Czösto nagäe wymagania przestajñ siö pojawiaè w momencie, kiedy organizacja przyzwyczai siö do rytmu iteracji. Jednak w niektórych przypadkach zespóä ma uzasadnionñ potrzebö zapewnienia ciñgäej obsäugi doraĒnych Ĕñdaþ. Jeden z programistów musi wtedy objñè stanowisko batmana.

UWAGA Niektóre zespoäy majñ odröbny telefon przeznaczony do zgäaszania krytycznych Ĕñdaþ. Jest to — oczywiĈcie — battelefon.

W jözyku angielskim „Batman” to pojöcie z obszaru wojskowoĈci, a takĔe imiö postaci z komiksu. Termin ten oznacza Ĕoänierza, który zajmuje siö codziennymi zadaniami, dziöki czemu oficerowie mogñ skupiè siö na dowodzeniu. W zespoäach w XP batman zarzñdza sytuacjami alarmowymi w organizacji i obsäuguje Ĕñdania, co pozwala innym programistom skoncentrowaè siö na programowaniu. Batman nie ma innych obowiñzków i nie pracuje nad opowieĈciami ani planem iteracji. NaleĔy co iteracjö zmieniaè programistö peäniñcego funkcjö batmana, aby zapobiec wypaleniu siö. JeĈli obciñĔenie jest wyjñtkowo duĔe, moĔliwe, Ĕe jednoczeĈnie potrzebnych bödzie kilku batmanów. W niektórych sytuacjach lepsze jest zastosowanie dziennych iteracji zamiast batmana. Dzienna iteracja umoĔliwia przeäoĔenie wszystkich krytycznych Ĕñdaþ na nastöpny poranek, co uäatwia zespoäowi koncentracjö (zobacz ramkö „Dzienne iteracje”). Dopuszczalne jest, aby zespóä zajmowaä siö przede wszystkim maäymi, doraĒnymi zadaniami, na przykäad naprawianiem bäödów i drobnymi usprawnieniami, a nie miaä przy tym däugoterminowego planu wydania.

288 ROZDZ AĤ 8

P ANOWAN E

Czas na nauký ProgramiĈci muszñ wciñĔ wzbogacaè swe umiejötnoĈci, aby nadñĔyè za nieustannym rozwojem dziedziny, w której siö specjalizujñ. W trakcie nauki czösto nabywajñ wiedzö, która zwiöksza ich wkäad w projekt. Specjalny czas na naukö to doskonaäy sposób na zachöcenie programistów do rozwoju i wprowadzenie dodatkowego zapasu do iteracji. NaleĔy przyznaè kaĔdemu programiĈcie póä dnia na prowadzenie samodzielnych badaþ nad wybranym zagadnieniem. Nikt nie powinien niczego narzucaè. Zalecam przestrzeganie tylko dwóch reguä: programista nie moĔe poĈwiöcaè tego czasu na pracö nad opowieĈciami ani zadaniami i nie moĔe modyfikowaè kodu projektu.

UWAGA JeĈli lider obawia siö, Ĕe programiĈci zmarnujñ ten czas, powinien zaprosiè ich na obiad nastöpnego dnia i poprosiè o podzielenie siö z zdobytymi informacjami w trakcie nieformalnej rozmowy. Jest to takĔe dobry sposób na rozpowszechnianie wiedzy.

Wprowadziäem tö technikö w kilku zespoäach i za kaĔdym razem daäa wartoĈciowe efekty. W jednej organizacji dwa tygodnie po wprowadzeniu czasu na naukö menedĔer produktu poinformowaä mnie, Ĕe byä to najbardziej wartoĈciowy okres spödzony przez zespóä i zasugerowaä podwojenie go. Czas na naukö jest wartoĈciowy, poniewaĔ programiĈci zwykle majñ motywacjö do dobrej pracy, a juĔ zwäaszcza wtedy, kiedy sami sobñ kierujñ. WiökszoĈè programistów w naturalny sposób dñĔy do uäatwienia sobie Ĕycia i zrobienia wraĔenia na wspóäpracownikach. Dziöki temu praca wykonana w czasie na naukö ma czösto zaskakujñco pozytywny wpäyw na projekt. Czas na naukö jest szczególnie wartoĈciowy w zespoäach stosujñcych XP. Ciñgäa bliskoĈè terminów kolejnych iteracji doskonale nadaje siö do zmniejszania ryzyka i motywowania zespoäu do lepszej pracy, ale moĔe teĔ prowadziè do ograniczenia perspektywy. Specjalny czas na naukö daje programistom moĔliwoĈè poszerzenia punktu widzenia, co czösto prowadzi do pomysäów na bardziej skuteczne rozwiñzania.

UWAGA Zwykle planujö czas na naukö na poranek przedostatniego dnia iteracji. Jest to wystarczajñco póĒno, aby moĔna byäo wykorzystaè ten czas jako zapas, jeĈli jest to konieczne, a jednoczeĈnie programiĈci nie rozpraszajñ siö myĈleniem o bliskim terminie. Poranki sñ lepsze od popoäudni, poniewaĔ trudniej zaczñè naukö w momencie, kiedy uwagö przykuwa kod produkcyjny.

Aby czas na naukö byä przydatny, programiĈci muszñ siö skoncentrowaè. Póä dnia moĔe minñè bardzo szybko. ãatwo wykorzystaè ten czas na przeäoĔone spotkanie. NaleĔy jednak stanowczo unikaè przeszkód i poprosiè o pomoc menedĔera projektu. ProgramiĈci powinni ignorowaè pocztö elektronicznñ, wyäñczyè komunikator i uĔywaè przeglñdarki internetowej wyäñcznie do prowadzenia konkretnych badaþ. Po wprowadzeniu czasu na naukö programiĈci mogñ mieè problem z wyborem tematu badaþ. Warto przypomnieè sobie zagadnienie, który ostatnio sprawiäo duĔe problemy. MoĔe programista chciaäby siö dowiedzieè czegoĈ wiöcej o szczegóäach uĔywanej platformy interfejsu uĔytkownika? ZAPAS 295

Rezygnacja z czasu na nauký Niektóre problemy sñ zbyt powaĔne, aby moĔne je byäo rozwiñzaè w nadgodzinach. Wtedy warto rozwaĔyè rezygnacjö z czasu na naukö i zajöcie siö w zamian problemem. Najpierw jednak naleĔy siö jeszcze raz zastanowiè, czy nie trzeba zmieniè planu iteracji (zobacz podrozdziaä „Planowanie iteracji” we wczeĈniejszej czöĈci rozdziaäu). JeĈli problemy sñ duĔe, nawet rezygnacja z czasu na naukö moĔe nie pozwoliè na ich rozwiñzanie.

Umiar Zapas to doskonaäe narzödzie. Pomaga realizowaè zobowiñzania i daje czas na wykonywanie waĔnych, ale nie pilnych zadaþ, które poprawiajñ wydajnoĈè. NaleĔy jednak zachowaè ostroĔnoĈè. Choè zapas to doskonaäy sposób na radzenie sobie z przejĈciowymi käopotami, moĔe takĔe ukrywaè problemy systemowe. JeĈli zapas jest potrzebny do ukoþczenia opowieĈci w kaĔdej iteracji, dodatkowy czas nie stanowi tak naprawdö zapasu, ale jest niezbödny. Wróèmy na chwilö do przykäadu z kablem elektrycznym. ZaäóĔmy, Ĕe komputer znajduje siö na niestabilnym biurku. Za kaĔdym razem, kiedy programista pisze na klawiaturze, biurko chwieje siö, co prowadzi do wyrwania wtyczki z gniazdka. MoĔna dodaè do kabla zapas, który zapobiegnie wyrywaniu wtyczki, jednak tak naprawdö nie jest to zapas. Dodatkowe centymetry sñ potrzebne, aby programista mógä w ogóle uĔywaè komputera. JeĈli w trakcie pisania zdarzy siö coĈ niespodziewanego — na przykäad Robert z dziaäu marketingu przyjacielsko poklepie programistö po plecach — wtyczka zostanie wyrwana z gniazdka. JeĈli zespóä pracuje w nadgodzinach, rezygnuje z czasu na naukö i nie späaca däugu technicznego przez dwie lub trzy iteracje z rzödu, oznacza to, Ĕe podejmuje za wysokie zobowiñzania i nie ma zapasu. Warto pogratulowaè jego czäonkom, Ĕe mimo to realizujñ zobowiñzania, a nastöpnie dodaè zapas, zmniejszajñc wskaĒnik szybkoĈci.

JeĈli zespóä nieustannie wykorzystuje wiökszoĈè zapasu, podejmuje za wysokie zobowiñzania.

Wygospodarowanie wystarczajñcej iloĈci czasu na zadania, które nie sñ pilne, jest trudne. Kiedy terminy zbliĔajñ siö nieubäaganie, nieäatwo wyobraziè sobie poĈwiöcanie czasu na czynnoĈci, które nie prowadzñ bezpoĈrednio do ukoþczenia opowieĈci. Szczególnñ trudnoĈè sprawia to zespoäom, które dopiero poznajñ XP. Jednak nie naleĔy rezygnowaè. Zapas jest niezbödny do realizacji zobowiñzaþ, a to z kolei klucz do udanego stosowania XP.

Skracanie zapasu Wedäug moich doĈwiadczeþ sñ dwa gäówne Ēródäa losowoĈci w zespoäach stosujñcych XP: niedostöpnoĈè klientów i däug techniczny. Oba sprawiajñ, Ĕe Ĉrodowisko jest nieprzewidywalne, szacowanie — trudne, a zespóä potrzebuje wiökszego zapasu, aby zrealizowaè zobowiñzania. JeĈli programiĈci muszñ w trakcie pracy czekaè na odpowiedzi od klientów, moĔna äatwo ograniczyè potrzebny zapas. Wystarczy sprawiè, aby klienci byli bardziej dostöpni. MoĔe to wzbudziè ich protesty — klienci czösto sñ zaskoczeni, jak duĔo pracy wymaga od nich udziaä

ZAPAS 297

Jednak wiele firm w ogóle nie uwzglödnia zapasu w planach. Nieprzypadkowo wäaĈnie te organizacje najczöĈciej majñ problemy z realizacjñ zobowiñzaþ. Marnujñ takĔe duĔo czasu na chaotycznych próbach osiñgniöcia nieosiñgalnego.

Grupy wspólnej nauki Niektóre zespoäy tworzñ grupy wspólnej nauki zamiast wydzielania czasu na naukö. Jest to doskonaäa alternatywa, wartoĈciowa przede wszystkich dla tych zespoäów, których czäonkowie wolñ omawiaè podstawowe zasady niĔ poznawaè nowe technologie. Jednym ze sposobów stosowania tej techniki jest czytanie na gäos fragmentów ksiñĔek lub artykuäów i omawianie ich. Zaletñ takiego rozwiñzania jest to, Ĕe czäonkowie grupy nie muszñ siö przygotowywaè do sesji. Uäatwia to aktywne uczestniczenie w spotkaniu. Jedna osoba powinna peäniè funkcjö moderatora i zachöcaè do dyskusji, zadajñc pytania na temat poszczególnych fragmentów. Grupy wspólnej nauki mogñ poĈwiöciè póä dnia w ciñgu tygodnia na produktywne rozmowy. W przypadku tej ksiñĔki powinno to wystarczyè na omówienie jednej lub dwóch praktyk w trakcie sesji.

Srebrne opowieļci Inne zespoäy planujñ opracowanie w zapasowym czasie srebrnych opowieĈci. Sñ to mniej istotne opowieĈci, które zespóä moĔe pominñè, jeĈli zabraknie mu czasu. Ja wolö w zamian späacaè däug techniczny, poniewaĔ zespoäy czösto lekcewaĔñ to kluczowe zadanie. TrudnoĈè w uĔywaniu techniki srebrnych opowieĈci polega na tym, Ĕe zespoäy muszñ rezygnowaè z zadaþ wykonywanych w zapasowym czasie w momencie zauwaĔenia problemu. JeĈli stanie siö to w przypadku srebrnych opowieĈci, powstanie däug techniczny w postaci nieukoþczonego kodu. Zespoäy korzystajñce z tej techniki powinny bezwzglödnie pamiötaè o usuniöciu caäego kodu zwiñzanego z opowieĈciami, z których realizacji zrezygnowano. Zaobserwowaäem takĔe, Ĕe srebrne opowieĈci szkodzñ morale programistów. JeĈli zespóä musi wykorzystaè zapas, nie ukoþczy wszystkich zaplanowanych opowieĈci. Choè srebrne opowieĈci to zadania dodatkowe, w praktyce grupy czösto nie zwracajñ na to uwagi. Z kolei jakakolwiek iloĈè czasu poĈwiöcona na späacanie däugu technicznego bezpoĈrednio poprawia komfort pracy programistów. To duĔa zaleta.

Dalsza lektura DeMarco w ksiñĔce Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency [DeMarco 2002] przedstawia przekonujñce dowody na rzecz stosowania zapasu. The Goal i Critical Chain [Goldratt 1992 i 1997] to dwie biznesowe pozycje, w których autor proponuje uĔywanie zapasu (inaczej „buforów”) zamiast zawyĔania szacunków do zabezpieczenia zobowiñzaþ i zwiökszania wydajnoĈci. Silicon Valley Patterns Study of Domain-Driven Design (http://domaindrivendesign.org/discussion/siliconvalleypatterns/index.html) to ciekawy zapis spotkaþ dojrzaäej i odnoszñcej duĔe sukcesy grupy wspólnej nauki.

300 ROZDZ AĤ 8

P ANOWAN E

JeĈli iteracja obejmuje tylko kilka opowieĈci, trudniej jest obserwowaè postöpy. Zwiöksza to ryzyko, Ĕe zespóä nie zauwaĔy problemów wystarczajñco wczeĈnie, aby je rozwiñzaè. Ponadto, jeĈli coĈ siö nie powiedzie i grupa nie ukoþczy opowieĈci, bödzie ona stanowiäa znacznñ czöĈè zaplanowanej pracy. Z kolei zbyt duĔa liczba opowieĈci zwiöksza koszty zwiñzane z planowaniem i szacowaniem. KaĔda opowieĈè staje siö mniejsza, co utrudnia uzyskanie ogólnego obrazu prac. ćrednia na poziomie szeĈciu opowieĈci na iteracjö prowadzi do trzymiesiöcznego planu wydania (to proponowane przeze mnie maksimum) skäadajñcego siö z 78 opowieĈci. To dobra wartoĈè. Zapewnia elastycznoĈè w planowaniu bez przytäaczania zespoäu szczegóäami. Nasi klienci znajñ siö na programowaniu. Czy moĔemy przygotowaè opowieĈci techniczne skoncentrowane na programistach? Trudniej tworzyè opowieĈci skoncentrowane na klientach niĔ programistach, dlatego zespoäy czasem szukajñ wymówek, aby uniknñè tych pierwszych. Jedna z nich to: „Naszym klientom nie przeszkadzajñ opowieĈci skoncentrowane na programistach”. NaleĔy unikaè takiego podejĈcia. Nawet jeĈli klienci naprawdö potrafiñ okreĈliè priorytety opowieĈci skoncentrowanych na programistach, opowieĈci skoncentrowane na klientach prowadzñ do lepszych planów. Trzeba pamiötaè, Ĕe cel to utworzenie historii, które umoĔliwiñ udostöpnienie oprogramowania w dowolnym momencie. OpowieĈci skoncentrowane na programistach zwykle nie majñ tej cechy. JeĈli klienci sñ programistami, a zespóä rozwija oprogramowanie przeznaczone dla programistów, na przykäad bibliotekö lub platformö, wtedy w opowieĈciach naleĔy uĔyè jözyka skoncentrowanego na programistach (zobacz podrozdziaä „Wspólny jözyk” w rozdziale 6.). Jednak nawet wtedy opowieĈci powinny odzwierciedlaè punkt widzenia klientów i dotyczyè ich potrzeb, a nie planów ich realizacji przez zespóä. Jak moĔemy zachöciè udziaäowców, aby uĔywali opowieĈci do opisu funkcji, o które proszñ? Kiedy udziaäowiec zaĔñda funkcji, naleĔy wröczyè mu karteczkö i poprosiè o zapisanie opowieĈci, aby moĔna jñ umieĈciè w planie. Obsäuga Ĕñdaþ elektronicznych to zadanie dla przedstawiciela klienta, który powinien albo porozmawiaè z osobñ zgäaszajñcñ proĈbö, albo samodzielnie utworzyè opowieĈè. JeĈli udziaäowcy nie chcñ uĔywaè opowieĈci, menedĔer produktu moĔe podtrzymaè relacje, udostöpniajñc udziaäowcom to, co chcñ zobaczyè, oraz przeksztaäcajñc ich oczekiwania na opowieĈci potrzebne zespoäowi.

Efekty Kiedy zespóä prawidäowo uĔywa opowieĈci, przedstawiciele klientów rozumiejñ wszystkie zadania, które zatwierdzñ i zaplanujñ. ProgramiĈci pracujñ nad maäymi, wykonalnymi, niezaleĔnymi fragmentami i mogñ czösto udostöpniaè kompletne funkcje. Projekt w kaĔdym momencie zapewnia klientom maksymalnñ wartoĈè.

OPOW EĻC

307

Szacowanie Przedstawiamy wiarygodne szacunki.

Odb orcy P og amiļci

ProgramiĈci czösto uwaĔajñ szacowanie za czarnñ magiö, za jedno z najtrudniejszych zadaþ, jakie majñ do wykonania. Wielu zauwaĔa, Ĕe szacunki stale sñ za niskie. Aby przeciwdziaäaè temu problemowi, dodajñ do nich bufor (powszechnym rozwiñzaniem jest mnoĔenie szacunków przez trzy), jednak czasem nawet takie zgrubne prognozy okazujñ siö zbyt niskie. Czy moĔliwe jest uzyskanie dobrych szacunków? OczywiĈcie! ProgramiĈci muszñ jedynie skoncentrowaè siö na swych mocnych stronach.

Dobre i zĥe metody szacowania Jednym z aspektów, które sprawiajñ, Ĕe szacowanie jest tak trudne, jest to, Ĕe programiĈci rzadko wiedzñ, czym bödñ siö zajmowaè. Zadanie, które wymaga oĈmiu godzin pracy w peänym skupieniu, moĔe przeciñgnñè siö na dwa lub trzy dni, jeĈli programiĈcie nieustannie ktoĈ przeszkadza. Czas ten moĔe wydäuĔyè siö jeszcze bardziej, jeĈli programista pracuje jednoczeĈnie nad innym zadaniem. Sekret dobrego szacowania po czöĈci kryje siö w tym, aby przewidywaè nakäady pracy niezbödne do wykonania zadania, a nie czas kalendarzowy. NaleĔy szacowaè w kategoriach idealnych dni (nazywanych teĔ punktami opowieĈci), czyli liczby dni, które trzeba poĈwiöciè na wykonanie zadania przy peänej koncentracji i bez przeszkód.

W szacunkach naleĔy uwzglödniaè czas w idealnych warunkach.

Samo uwzglödnianie czasu w idealnych warunkach nie doprowadzi do precyzyjnych szacunków. Poprosiäem kilka zespoäów, z którymi wspóäpracowaäem, aby dokäadnie zmierzyäy czas, jaki zajmuje im wykonanie róĔnych zadaþ (jedna z grup udostöpniäa mi dane z 18 miesiöcy). Choè zespoäy te przedstawiaäy szacunki w idealnych dniach, nigdy nie byäy one dokäadne. WaĔne jednak, Ĕe byäy stabilne. Jeden z zespoäów zawsze podawaä w szacunkach okoäo 60% potrzebnego czasu. Na pozór nie wydaje siö to korzystne. Do czego przydatne mogñ byè nieprecyzyjne szacunki, zwäaszcza jeĈli nie sñ powiñzane z czasem kalendarzowym? Istotna jest tu szybkoĈè.

Szybkoļë Choè szacunki prawie nigdy nie sñ dokäadne, odbiegajñ od rzeczywistoĈci w stabilny sposób. Choè precyzja poszczególnych szacunków jest przewaĔnie bardzo róĔna — czasem moĔe to byè poäowa rzeczywistego czasu, innym razem 20% wiöcej — ogólnie szacunki sñ stabilne. Ponadto, choè w kaĔdej iteracji pojawiajñ siö inne przeszkody, iloĈè czasu potrzebna na poradzenie sobie z nimi takĔe jest doĈè podobna. Dziöki temu moĔna w rzetelny sposób przeksztaäciè szacunki na czas kalendarzowy po poäñczeniu wszystkich opowieĈci wchodzñcych w skäad iteracji. Potrzebny jest tylko jeden czynnik do skalowania.

SZACOWAN E 309

Wszyscy programiĈci powinni uczestniczyè w szacowaniu. Obecny powinien byè teĔ przynajmniej jeden klient, a jego zadaniem jest odpowiadanie na pytania. Kiedy programiĈci uzyskajñ wszystkie potrzebne informacje, jeden z nich moĔe zasugerowaè szacunkowe koszty. Jako pierwsze powinny odzywaè siö osoby najbardziej pewne swych prognoz. Czösto to wäaĈnie ci programiĈci majñ najwiöksze doĈwiadczenie.

UWAGA Zakäadam, Ĕe ograniczeniem sñ programiĈci (zobacz punkt „Teoria ograniczeþ” w rozdziale 3.), dlatego tylko oni powinni szacowaè koszty opowieĈci. Ograniczenie systemu determinuje, jak szybko zespóä dostarczy gotowy produkt, dlatego waĔne sñ szacunki tylko tej grupy, która jest ograniczeniem. JeĈli nie sñ to programiĈci, naleĔy porozmawiaè z mentorem o tym, jak dostosowaè XP do konkretnej sytuacji.

JeĈli podane szacunki wydajñ siö klientom nieprawidäowe lub któryĈ z nich nie rozumie, na czym siö opierajñ, naleĔy poprosiè o omówienie szczegóäów. Z kolei programiĈci powinni przedstawiè szacunki i opisaè sposób ich uzyskania. Ewentualne dyskusje pozwolñ wyjaĈniè prognozy. Kiedy wszyscy programiĈci potwierdzñ szacunki, naleĔy zapisaè je na karteczce.

UWAGA JeĈli programista nie zna dobrze danej czöĈci systemu, powinien obliczaè szacunkowe koszty jej rozwoju w myĈlach, a nastöpnie porównywaè je z prognozami ekspertów. JeĈli te wartoĈci róĔniñ siö od siebie, warto poprosiè o wyjaĈnienia.

Na poczñtku poszczególni czäonkowie zespoäu bödñ mieli odmienne opinie na temat czasu wykonywania róĔnych zadaþ. Prowadzi to do niestabilnych szacunków. JeĈli zespóä tworzy je wspólnie, po kilku iteracjach programiĈci powinni zsynchronizowaè prognozy ze sobñ. Porównywanie szacunków z czasem, który rzeczywiĈcie byä potrzebny na opowieĈci lub zadania, takĔe moĔe daè informacje zwrotne pomocne w ustabilizowaniu prognoz. W tym celu naleĔy Ĉledziè czas poĈwiöcany róĔnym czynnoĈciom, jak opisuje to punkt „Wykorzystanie czasu” w rozdziale 6.

Jak szacowaë koszty opowieļci? Szacunki dotyczñce opowieĈci naleĔy wyraĔaè w punktach opowieĈci. Jeden punkt opowieĈci to odpowiednik jednego idealnego dnia.

UWAGA MoĔna uĔywaè w szacunkach poäówek punktów, jednak èwiartki nie powinny byè potrzebne.

Na poczñtku szacowania kosztów opowieĈci naleĔy wyobraziè sobie zadania inĔynieryjne potrzebne do jej realizacji. Trzeba zapytaè przedstawicieli klientów o ich oczekiwania i skoncentrowaè siö na kwestiach, które mogñ mieè wpäyw na szacunki. JeĈli programista wykryje zadanie, które moĔe byè kosztowne, powinien zaproponowaè klientom bardziej oszczödne rozwiñzania.

312

ROZDZ AĤ 8

P ANOWAN E

Wraz z nabywaniem doĈwiadczenia w obszarze projektu programiĈci zacznñ dokonywaè szacunków bardziej intuicyjnie i nie bödñ musieli dzieliè ich na zadania inĔynieryjne. Czösto myĈlñ wtedy w kategoriach podobnych opowieĈci, a nie idealnych dni. Na przykäad programista moĔe uznaè, Ĕe konkretna opowieĈè dotyczy typowego raportu, a typowy raport odpowiada jednemu punktowi. MoĔe teĔ stwierdziè, Ĕe opowieĈè opisuje skomplikowany raport, który jednak nie jest aĔ dwa razy trudniejszy od standardowego, i wyceni jñ na póätora punktu. Czasem dokäadne szacunki wymagajñ wiökszej iloĈci informacji. Wtedy trzeba zamieĈciè odpowiedniñ uwagö na karteczce. JeĈli programista potrzebuje dodatkowych danych od klientów, powinien wpisaè „??” (co oznacza „pytania bez odpowiedzi”) zamiast szacunków. JeĈli musi przeprowadziè dodatkowe badania na temat konkretnej technologii, powinien wpisaè „Rozwiñzanie punktowe” i przygotowaè opowieĈè dotyczñcñ tego zagadnienia (zobacz podrozdziaä „Rozwiñzania punktowe” w rozdziale 9.). Zespóä zebraä siö, aby oszacowaè opowieĈci. Maria, jedna z przedstawicielek klientów, rozpoczyna dyskusjö. Amelia, Jarek i Kasia to programiĈci. Maria: A oto nastöpna opowieĈè. [Odczytuje na gäos treĈè opowieĈci z karteczki, a nastöpnie umieszcza jñ na stole]. „Raport ze spisem czöĈci z magazynu”. Amelia: PrzygotowaliĈmy juĔ tyle raportów, Ĕe jeszcze jeden nie powinien sprawiè nam problemów. Zwykle trzeba na nie poĈwiöciè jeden punkt. Mamy juĔ spis czöĈci, dlatego raport nie wymaga obsäugi nowych danych. Czy jest w nim coĈ nietypowego? Maria: Raczej nie. PrzygotowaliĈmy makietö. [Wyciñga wydruk i wröcza go Amelii]. Amelia: Wyglñda na doĈè prosty. [Käadzie kartkö na stole. Inni programiĈci przeglñdajñ wydruk]. Jarek: Mario, czego dotyczy kolumna „wiek”? Maria: To liczba dni roboczych od momentu przywiezienia czöĈci do magazynu. Jarek: Chodzi o dni robocze, a nie kalendarzowe? Maria: Tak. Jarek: A co ze Ĉwiötami? Maria: Chcemy liczyè tylko dni, w których firma dziaäa. Nie wliczamy w to weekendów, Ĉwiñt ani zaplanowanych przerw. Kasia: Jarku, rozumiem, do czego zmierzasz. Mario, spowoduje to wzrost szacunków, poniewaĔ obecnie nie Ĉledzimy zaplanowanych przerw. Potrzebujemy nowego interfejsu uĔytkownika lub Ēródäa danych, aby uzyskaè te informacje. MoĔe to zwiökszyè zäoĔonoĈè ekranów administracyjnych, a stwierdziliĈcie z Borysem, Ĕe äatwoĈè administracji jest dla was istotna. Czy „wiek” naprawdö musi byè tak dokäadny? Maria: Hmm. Dokäadna wartoĈè nie jest aĔ tak waĔna, jednak jeĈli informacje majñ byè dostöpne, chciaäabym, aby byäy dokäadne. A co ze Ĉwiötami — moĔemy je uwzglödniè? Kasia: MoĔemy zaäoĔyè, Ĕe kaĔdego roku uwzglödniane Ĉwiöta bödñ takie same? Maria: Nie bardzo, jednak nie bödñ zmieniaè siö zbyt czösto. Kasia: To dobrze, bödziemy mogli umieĈciè je w pliku konfiguracyjnym zamiast tworzyè dla nich interfejs uĔytkownika. Zmniejszy to koszty tej opowieĈci. Maria: Bödö jeszcze musiaäa siö nad tym zastanowiè. To zagadnienie nie jest specjalnie istotne i chyba nie warto dodawaè obciñĔeþ administracyjnych. Na razie zamiast dni SZACOWAN E

313

W praktyce wymiana opinii jest wskazana. Pomaga to zespoäowi skoncentrowaè wysiäki na tych pomysäach klientów, które majñ wysokñ wartoĈè, a nie sñ przy tym kosztowne (zobacz punkt „Jak wygraè?” we wczeĈniejszej czöĈci rozdziaäu). Jedno z czösto zadawanych przez klientów pytaþ to: „Dlaczego to tak duĔo kosztuje?”. NaleĔy powstrzymaè siö przed chöciñ obrony siebie i wäasnego honoru, zrobiè przerwö na uporzñdkowanie myĈli, a nastöpnie wymieniè punkty uwzglödnione w czasie szacowania kosztów. MoĔna zaproponowaè rozwiñzania zmniejszajñce koszt opowieĈci przez ograniczenie jej zakresu. WyjaĈnienia programistów zwykle zadowalajñ klientów. W niektórych przypadkach poproszñ oni o dalsze informacje. TakĔe te pytania naleĔy traktowaè jak zwykäe Ĕñdania. JeĈli programiĈci czegoĈ nie wiedzñ, powinni to przyznaè i wyjaĈniè, dlaczego mimo to oszacowali opowieĈè. JeĈli pytanie doprowadzi do ujawnienia nieuwzglödnionych wczeĈniej informacji, naleĔy zmieniè szacunki. NaleĔy jednak zachowaè ostroĔnoĈè. Pytania mogñ NaleĔy uprzejmie, ale stanowczo spowodowaè, Ĕe programiĈci zacznñ wñtpiè w swe odmówiè zmiany szacunków szacunki. Poczñtkowe, intuicyjne prognozy sñ zazwyczaj prawidäowe. NaleĔy je zmieniaè tylko w odpowiedzi na naciski. w obliczu naprawdö nowych informacji, a nie z uwagi na wywieranñ presjö. To przecieĔ programiĈci bödñ implementowaè opowieĈci i to oni majñ najwiöksze kwalifikacje do dokonania szacunków. NaleĔy byè uprzejmym, ale stanowczym: Przykro mi, Ĕe te szacunki paþstwu nie odpowiadajñ. UwaĔamy, Ĕe sñ prawidäowe, jednak jeĈli okaĔñ siö zbyt pesymistyczne, szybkoĈè automatycznie wzroĈnie i to zrekompensuje. Naszym obowiñzkiem wobec paþstwa i firmy jest przedstawienie szacunków uzyskanych na podstawie naszej wiedzy nawet wtedy, jeĈli sñ one rozczarowujñce, i tak wäaĈnie postöpujemy. JeĈli klient reaguje z niedowierzaniem lub marszczy brwi, moĔliwe, Ĕe nie zdaje sobie sprawy, jak nieuprzejme jest takie zachowanie. Czasem warto mu to uĈwiadomiè: Z jözyka ciaäa i usäyszanego przed chwilñ parskniöcia wnioskujö, Ĕe nie szanuje pan naszego profesjonalizmu lub nie wierzy w niego. Czy to chciaä pan powiedzieè? Klienci i udziaäowcy mogñ teĔ nie rozumieè metody opartej na punktach opowieĈci. Rozpoczynam od uproszczonego wyjaĈnienia tej kwestii: Punkty opowieĈci to technika szacowania, która automatycznie uwzglödnia koszty ogólne i bäödy w szacunkach. Nasza szybkoĈè wynosi 10, co oznacza, Ĕe moĔemy zrealizowaè 10 punktów na tydzieþ. JeĈli pytajñcy nalega na podanie dalszych informacji, wyjaĈniam wszystkie szczegóäy dotyczñce idealnych dni i szybkoĈci. Czösto prowadzi to do pytania: „JeĈli szybkoĈè to 10 idealnych dni, a zespóä skäada siö z 6 programistów, to czy szybkoĈè nie powinna wynosiè 30?”. MoĔna spróbowaè wyjaĈniè, Ĕe idealne dni to nie to samo co dni robocze programisty, jednak moich rozmówców nigdy to nie zadowalaäo. Dlatego po prostu przedstawiam szczegóäowe informacje:

316

ROZDZ AĤ 8

P ANOWAN E

JeĈli zespóä obejmuje niewielu programistów — czterech lub mniej — moĔe siö okazaè, Ĕe nawet jednodniowa nieobecnoĈè bödzie miaäa wpäyw na szybkoĈè. W takim przypadku moĔna zastosowaè iteracje dwutygodniowe. Omówienie zalet i wad takiego rozwiñzania znajduje siö w koþcowej czöĈci podrozdziaäu „Planowanie iteracji” we wczeĈniejszej czöĈci rozdziaäu. Na jakim poziomie powinniĈmy ustaliè szybkoĈè na poczñtku projektu? W pierwszej iteracji trzeba po prostu zgadywaè. SzybkoĈè nastöpnej naleĔy ustaliè na podstawie iloĈci zadaþ ukoþczonych w czasie pierwszej. Stabilizacji szybkoĈci moĔna spodziewaè siö po upäywie trzech lub czterech iteracji. Organizacja moĔe oczekiwaè podjöcia zobowiñzaþ przed ustabilizowaniem szybkoĈci. Najlepsze rozwiñzanie polega na stwierdzeniu: „Nie mamy jeszcze szacunków dotyczñcych harmonogramu, ale pracujemy nad tym. Mogö obiecaè udostöpnienie prognoz w przeciñgu trzech lub czterech tygodni. Potrzebujemy czasu, aby dostosowaè szacunki programistów do rzeczywistych postöpów prac”. Czy wspólne szacowanie kosztów opowieĈci nie powoduje marnotrawienia czasu programistów? Wspólne szacowanie wymaga wielu roboczogodzin programistów, jednak nie jest to zmarnowany czas. Sesje poĈwiöcone szacowaniu säuĔñ nie tylko ustalaniu prognoz. Jest to jednoczeĈnie pierwszy niezbödny krok w przekazywaniu i wyjaĈnianiu wymagaþ. ProgramiĈci zadajñ pytania i doprecyzowujñ szczegóäy, co czösto prowadzi do pomysäów, których klienci wczeĈniej nie rozwaĔali. Czasem ta wspóäpraca obniĔa ogólny koszt projektu (zobacz podrozdziaä „Gra planistyczna” we wczeĈniejszej czöĈci rozdziaäu). W trakcie szacowania obecni muszñ byè wszyscy programiĈci. Pozwala to upewniè siö, Ĕe rozumiejñ, co majñ utworzyè. Wspólna praca programistów zwiöksza takĔe dokäadnoĈè szacunków. Co siö stanie, jeĈli nie zadamy klientom odpowiednich pytaþ i pominiemy jeden z istotnych aspektów? Czasem zespoäy pomijajñ coĈ naprawdö waĔnego. Gdyby Jarek nie zapytaä Marii o kolumnö „wiek”, zespóä pominñäby powaĔny problem, a szacunki byäyby nieprawidäowe. Takie pomyäki siö zdarzajñ. Informacje oczywiste dla klientów nie zawsze sñ takie dla programistów. Choè nie moĔna zapobiec takim pomyäkom, moĔna ograniczyè ich liczbö. JeĈli wszyscy programiĈci wspólnie szacujñ koszty opowieĈci, jest bardziej prawdopodobne, Ĕe zadadzñ odpowiednie pytania. Ponadto liczba pomyäek zmniejszy siö, kiedy zespóä nabierze doĈwiadczenia w szacowaniu. Klienci nauczñ siö, które szczegóäy naleĔy podaè, a programiĈci zrozumiejñ, jakie pytania trzeba zadaè. Do czasu nabrania przez zespóä doĈwiadczenia nie trzeba siö martwiè pomyäkami, chyba Ĕe niespodzianki zdarzajñ siö czösto. NaleĔy uwzglödniaè nieoczekiwane szczegóäy w momencie, kiedy zostanñ ujawnione (zobacz podrozdziaä „Planowanie iteracji” we wczeĈniejszej czöĈci rozdziaäu). JeĈli nieoczekiwane drobiazgi czösto zaskakujñ zespóä i nie zmienia siö to wraz z nabywaniem doĈwiadczenia, naleĔy poprosiè o pomoc mentora.

SZACOWAN E

319

322 ROZDZ AĤ 8

P ANOWAN E

ROZDZIAĤ 9

Wytwarzanie

WyobraĒmy sobie, Ĕe programista rzuca Ĉwiat rozwoju oprogramowania, aby zostaè kucharzem. Po latach nauki i praktyki osiñga szczyty w nowej profesji. Pewnego dnia otrzymuje powaĔne zamówienie: ma przygotowaè imprezö na 500 osób, na którñ wstöp ma kosztowaè 10 000 zäotych, a zyski zostanñ przeznaczone na cele charytatywne. Limuzyna zawozi kucharza z wyczarterowanego samolotu na miejsce imprezy, a mistrz — wraz z pomocnikami — wchodzi z pewnoĈciñ siebie do kuchni, gdzie nagle przeraĔony staje. Panuje tam straszny nieporzñdek: gnijñce jedzenie, sterty nieumytych naczyþ, woda stojñca w zlewach. A to juĔ poranek dnia, w którym ma odbyè siö impreza. Kucharz ma 12 godzin. Co ma zrobiè? Podwija rökawy i zabiera siö do sprzñtania. Kiedy pierwszy fragment kuchni jest juĔ czysty, kilku kucharzy przystöpuje do pracy nad najdäuĔszym w przygotowaniu i najbardziej skomplikowanym daniem. Inni kierujñ siö do sklepu, aby zdobyè ĈwieĔe skäadniki. Pozostaäe osoby wciñĔ porzñdkujñ. Praca w panujñcym rozgardiaszu trwaäaby zbyt däugo. To lekcja, której kucharz dobrze nauczyä siö w trakcie rozwoju oprogramowania. Rozwój oprogramowania wymaga wspóäpracy wszystkich czäonków zespoäu. W jözyku angielskim programiĈci sñ czösto nazywani „producentami” (ang. developers), jednak w rzeczywistoĈci wszystkie osoby pracujñ przy wytwarzaniu. Przy podziale pracy klienci wykrywajñ nastöpne wymagania, podczas gdy programiĈci pracujñ nad juĔ ustalonymi. Testerzy pomagajñ ustaliè, jak zapobiegaè pojawianiu siö bäödów. ProgramiĈci rozkäadajñ koszt utworzenia infrastruktury technicznej na caäy projekt. Przede wszystkim jednak wszyscy pomagajñ w zachowaniu porzñdku. Najlepszy znany mi sposób na zmniejszenie kosztów tworzenia oprogramowania polega na poprawie wewnötrznej jakoĈci kodu i projektu. Nigdy nie widziaäem, aby dobrze zarzñdzany projekt o wysokiej jakoĈci nie doprowadziä do zwrotu poniesionych nakäadów. W udanym projekcie z wykorzystaniem XP pracownicy majñ zdumiewajñce wraĔenie zwiñzane z poczuciem caäkowitej swobody wprowadzenia bez obaw dowolnych zmian. Dziewiöè wymienionych poniĔej praktyk pozwala zachowaè porzñdek w kodzie i umoĔliwia caäemu zespoäowi wniesienie wkäadu w wytwarzanie: x Stopniowe zbieranie wymagaþ umoĔliwia zespoäowi rozpoczöcie pracy juĔ w czasie

opracowywania szczegóäów wymagaþ przez klientów.

x Testy klienta pomagajñ przekazywaè informacje o skomplikowanych reguäach z dziedziny.

323

x Wytwarzanie sterowane testami sprawia, Ĕe programiĈci majñ pewnoĈè, iĔ kod dziaäa tak,

jak tego oczekujñ. x Refaktoryzacja umoĔliwia poprawö jakoĈci kodu bez zmieniania sposobu jego dziaäania. x Prosty projekt umoĔliwia modyfikowanie projektu w celu speänienia nawet najbardziej

zaskakujñcych Ĕñdaþ dotyczñcych funkcjonalnoĈci. x Stopniowy rozwój projektu i architektury umoĔliwia programistom równolegäñ pracö

nad funkcjonalnoĈciñ i infrastrukturñ technicznñ. x Rozwiñzania punktowe to kontrolowane eksperymenty säuĔñce zbieraniu informacji. x Optymalizacja wydajnoĈci wymaga wykorzystania przy optymalizowaniu twardych danych. x Testy eksploracyjne umoĔliwiajñ testerom wykrywanie luk w procesach myĈlowych zespoäu.

MINI WPRAWKA Z „WYTWARZANIA” Ce em tej wprawk jest przeëw czen e ref eksyjnego projektowan a Zespoĥy rozpoczynajéce stosowan e wytwarzan a zw nnego mogé uŜyë jej do zrozum en a kodu bazowego wykryc a moŜ wych usprawn eħ w projekc e, nawet jeļ n e stosujé obecn e XP Doļw adczen uŜytkown cy zw nnego podejļc a pow nn zapoznaë s ý z rozdz aĥem 15 uŜyë tej wprawk do usta en a zm an w proces e, które pomogé zespoĥow u epszyë stosowane metody projektowan a Na eŜy ëw czyë tý wprawký p zez póĥ godz ny kaŜdego dn a do momentu, k edy da sze jej wykonywan e p zestan e dawaë efekty Na poczétku zm eszczen e s ý w term n e moŜe spraw aë prob emy Jeļ wprawka stan e s ý nudna, na eŜy zastanow ë s ý, jak wprowadz ë zm any, które jé oŜyw é a wprawka jest p zeznaczona ty ko d a program stów Potrzebne sé stanow ska do pracy w parach, pap er narzýdz a do p san a Etap 1. Tworzenie par. Na eŜy spróbowaë utworzyë pary skĥadajéce s ý z osób, które ostatn o n e pracowaĥy ze sobé Etap 2. NaleŜy ograniczyë go do 15 minut. Przeg édan e kodu wybór n eza eŜnej jednostk do ana zy Na eŜy wybraë fragment kodu, którego jeszcze n e omaw ano w w ýkszej grup e MoŜna to byë metoda, k asa ub caĥy podsystem N e na eŜy poļw ýcaë na to zadan e zbyt duŜo czasu Jeļ para ma prob em z podjýc em decyzj , moŜe osowo wybraë dowo ny fragment kodu Nastýpn e, w trakc e ektury kodu, na eŜy zastosowaë do projektu nŜyn er ý wsteczné KaŜda para pow nna utwo zyë mode projektu za pomocé d agramu przepĥywu, jýzyka UML, ka t CRC ub dowo nej nnej preferowanej techn k Zadan e po ega na wyk yc u wsze k ch n edoskonaĥoļc w kodz e projekc e oraz omów en u moŜ woļc ch naprawy Na eŜy utworzyë nowy mode , który p zedstaw a projekt po wprowadzen u poprawek Jeļ para ma jeszcze czas, moŜe omów ë konkretne etapy refakto yzacj , które umoŜ w é przejļc e od obecnego projektu do jego epszej wersj w maĥych, kontro owanych fazach Etap 3. NaleŜy ograniczyë go do 15 minut. Wybór spoļród wszystk ch program stów trzech par, które poprowadzé dyskusjý na podstaw e swych odkryë KaŜda para ma na to p ýë m nut Wa to zastanow ë s ý nad pon Ŝszym pytan am x Które fragmenty kodu pary wybraĥy? x Jaka byĥa poczétkowa reakcja na kod? x Jak e sé za ety wady p zedstaw onych propozycj ? x Jak e refaktoryzacje moŜna przeprowadz ë na podstaw e dokonanych odk yë?

324 ROZDZ AĤ 9

WYTWARZAN E

W XP moĔna stosowaè wstöpnñ fazö analiz, jednak dziöki odpowiednim przedstawicielom klientów czösto jest ona zbödna.

Dalsza lektura KsiñĔka Software Requirements [Wieger 1999] to dobre Ēródäo wiedzy na temat tradycyjnych metod okreĈlania wymagaþ.

330 ROZDZ AĤ 9

WYTWARZAN E

Rozmowa na temat usuwania faktur moĔe przebiegaè w nastöpujñcy sposób: Klient: Jedna z opowieĈci w tej iteracji dotyczy funkcji usuwania faktur. UznaliĈmy, Ĕe oprócz przedstawionych przez nas makiet ekranu przydatne mogñ byè teĔ pewne testy klienta. Usuwanie faktur nie jest tak proste, jak siö wydaje, poniewaĔ trzeba zachowaè dane na potrzeby kontroli. Z zagadnieniem tym wiñĔe siö kilka reguä. Za chwilö omówiö szczegóäy, jednak wedäug podstawowej zasady dozwolone jest usuwanie tych faktur, które nie zostaäy przesäane do klienta. Takie faktury to zwykle efekt pomyäki. JeĈli faktura zostaäa przesäana do klienta, usunñè jñ moĔe tylko menedĔer. Jednak nawet wtedy trzeba zachowaè kopiö na potrzeby kontroli. Programista: Czy jeĈli faktura nie zostaäa przesäana i zostaje usuniöta, teĔ naleĔy jñ zachowaè na potrzeby kontroli? Klient: Nie, wtedy moĔna jñ po prostu usunñè. Za chwilö przedstawiö kilka przykäadów.

Demonstracja Po krótkim omówieniu reguä naleĔy przedstawiè konkretne przykäady, które ilustrujñ dany scenariusz. Czösto najbardziej naturalny sposób opisu informacji to tabele, jednak nie naleĔy przejmowaè siö ich formatowaniem. Wystarczy przedstawiè przykäady na tablicy. Dalsza rozmowa moĔe przebiegaè nastöpujñco: Klient (kontynuuje): Na przykäad ta faktura nie zostaäa przesäana do klienta, dlatego pracownik dziaäu rachunkowoĈci moĔe jñ usunñè. Wysĥano

UŜytkown k

MoŜna usunéë?

N

P acownik dziaĥu achunkowoļci

T

KaĔda osoba moĔe usunñè takñ fakturö: pracownik dziaäu obsäugi klienta, menedĔerowie i administratorzy. Wysĥano

UŜytkown k

MoŜna usunéë?

N

P acownik dziaĥu obsĥugi klienta

T

N

MenedŜe

T

N

Administ ato

T

Jednak po wysäaniu faktury tylko menedĔerowie i administratorzy mogñ jñ usunñè, a nawet wtedy trzeba jñ zachowaè na potrzeby kontroli. Wysĥano

UŜytkown k

T

P acownik dziaĥu achunkowoļci

N

T

P acownik dziaĥu obsĥugi klienta

N

T

MenedŜe

Zachowaë do kont oli

T

Administ ato

Zachowaë do kont oli

332 ROZDZ AĤ 9

WYTWARZAN E

MoŜna usunéë?

Ponadto nie tak prosto jest ustaliè, czy faktura zostaäa wysäana. „Wysäana” oznacza jednñ z kilku moĔliwoĈci. JeĈli uĔytkownik zrobiä cokolwiek, co mogäo doprowadziè do tego, Ĕe klient zobaczyä fakturö, naleĔy jñ uznaè za „Wysäanñ”. Wtedy moĔe jñ usunñè tylko administrator lub menedĔer. Wysĥano

UŜytkown k

MoŜna usunéë?

Wyd ukowano

P acownik dziaĥu achunkowoļci

N

Wyekspo towano

P acownik dziaĥu achunkowoļci

N

Umieszczono w inte necie

P acownik dziaĥu achunkowoļci

N

P zesĥano listem elekt onicznym

P acownik dziaĥu achunkowoļci

N

UWAGA Podawane przykäady muszñ byè jak najbardziej konkretne. Prostsze jest tworzenie przykäadów ogólnych, na przykäad: „Ta faktura nie zostaäa wysäana do klientów, dlatego kaĔdy moĔe jñ usunñè”, jednak äatwo wtedy o pomyäki, a programiĈci nie mogñ automatyzowaè podobnych przykäadów. Trzeba podawaè konkretne informacje: „Ta faktura nie zostaäa wysäana do klientów, dlatego pracownik dziaäu rachunkowoĈci moĔe jñ usunñè”. Wymaga to przygotowania wiökszej liczby przykäadów, co jest korzystne.

Rozmowy zwykle nie sñ tak päynne i uporzñdkowane jak ta przedstawiona wczeĈniej. W trakcie omawiania reguä biznesowych klienci przeskakujñ miödzy opisywaniem zasad a przedstawianiem ich na przykäadach. Prawdopodobnie pojawiñ siö wyjñtkowe przypadki, których klient wczeĈniej nie rozwaĔyä. Czasem nawet odkryte zostajñ zupeänie nowe kategorie reguä, dla których trzeba przygotowaè testy klienta. Jednym ze szczególnie skutecznych sposobów pracy jest analiza tematu. NaleĔy zaczñè od omówienia najbardziej podstawowych przypadków i przedstawienia kilku przykäadów. Nastöpnie trzeba opisaè wyjñtkowy przypadek lub dodatkowe szczegóäy i na ich podstawie przedstawiè dalsze przykäady. Klient powinien kontynuowaè analizy w podobny sposób, przechodzñc od najprostszych do najbardziej skomplikowanych zagadnieþ, do momentu opisania wszystkich aspektów reguäy. Nie trzeba przedstawiaè wszystkich moĔliwych przykäadów. Trzeba pamiötaè, Ĕe celem jest komunikacja, a nie wyczerpujñce przetestowanie aplikacji. Potrzebnych jest tylko tyle przykäadów, aby pokazaè róĔnice, których dotyczñ reguäy. Zwykle wystarcza kilka przykäadów na przypadek, a czasem nawet jeden lub dwa.

Wytwarzanie Po wystarczajñco kompletnym omówieniu reguä naleĔy udokumentowaè analizy, aby programiĈci mogli rozpoczñè implementowanie zasad. Jest to dobry moment na dokonanie oceny, czy przykäady majñ format odpowiedni do przygotowania na ich podstawie testów automatycznych. JeĈli nie, naleĔy omówiè z programistami moĔliwe rozwiñzania. Rozmowa moĔe przebiegaè nastöpujñco:

TESTY K

ENTA 333

Wysĥano

UŜytkown k

MoŜna usunéë?

Wysĥano listem elekt onicznym

P acownik dziaĥu achunkowoļci

N

Dobre przykäady koncentrujñ siö na istocie reguäy. Zamiast wyobraĔaè sobie, jak reguäy bödñ dziaäaè w aplikacji, wystarczy zastanowiè siö nad tym, czego dotyczñ. Jak klient opisaäby reguäö wspóäpracownikowi, gdyby aplikacji w ogóle nie byäo? NaleĔy mówiè o rzeczach, a nie dziaäaniach. Czasem pomaga myĈlenie w kategoriach schematu: „JeĈli (scenariusz X), to (scenariusz Y)”. Nauczenie siö myĈlenia w ten sposób wymaga trochö praktyki, jednak efekty sñ tego warte. Testy stajñ siö wtedy bardziej zwiözäe, äatwiejsze w konserwacji i — jeĈli zostanñ prawidäowo napisane — dziaäajñ szybciej.

Kierowanie przez klientów Czäonkowie zespoäu powinni wystrzegaè siö czösto popeänianego przy testach klienta bäödu, czyli pomijania klientów. W niektórych zespoäach programiĈci i testerzy wykonujñ wszystkie zadania zwiñzane z testami klienta, a czöĈè grup w ogóle nie obejmuje uĔytkowników. W innych klienci sñ obecni tylko jako niemi obserwatorzy. Nie wolno zapominaè o „klientach” Trzeba pamiötaè o „klientach” przy „testach klienta”. Celem tych dziaäaþ jest przy „testach klienta”. wäñczenie wiedzy i punktu widzenia klienta w prace zespoäu. JeĈli programiĈci i testerzy bödñ chcieli wszystko zrobiè samodzielnie, zespóä utraci te korzyĈci, a testy klienta nie doprowadzñ do oczekiwanych rezultatów. W niektórych przypadkach klienci mogñ wzbraniaè siö przed kierowaniem. ProgramiĈci i testerzy mogñ poradziè sobie z rozwiñzaniem tego problemu, proszñc klientów o pomoc. Kiedy programiĈci potrzebujñ wiedzy z dziedziny, mogñ poprosiè klientów o doäñczenie do zespoäu w trakcie omawiania przykäadów. Szczególnie skuteczne jest poproszenie klienta o wyjaĈnienie reguäy biznesowej, udanie zdziwienia, a nastöpnie wröczenie mu markera i poproszenie o przedstawienie przykäadu na tablicy.

UWAGA JeĈli klienci w ogóle nie uczestniczñ w testach klienta, moĔe to oznaczaè käopoty w kontaktach z nimi. NaleĔy poprosiè mentora (zobacz podrozdziaä „Szukanie mentora” w rozdziale 2.) o pomoc w rozwiñzaniu problemu.

ROLA TESTERÓW esterzy odg ywajé waŜné ro ý pomocn czé w testach k enta Choë k enc pow nn k erowaë pracam , op erajé s ý na w edzy techn cznej testerów ch um ejýtnoļc ach w wyobraŜan u sob e róŜnych scenar uszy Choë to k enc wymyļ ajé poczétkowe przykĥady, czýsto n e uwzg ýdn ajé wszystk ch scenar uszy Za ch zaproponowan e odpow adajé teste zy Z ko e tester pow n en uwaŜaë, aby n e próbowaë uwzg ýdn ë wszystk ch moŜ wych scenar uszy Ce em tego ëw czen a jest pomoc zespoĥow w zrozum en u perspektywy k entów, a n e wyczerpujéce przetestowan e ap kacj

TESTY K

ENTA 335

Wytwarzanie sterowane testami

Odb orcy

Przygotowujemy dobrze zaprojektowany, przetestowany i uporzñdkowany kod w maäych, äatwych do sprawdzenia fragmentach.

P og amiļci

Jak mówi Ĕart: „Jözyki programistyczne tak naprawdö potrzebujñ instrukcji RTOCM — rób to, o czym myĈlö, a nie to, co mówiö”. Programowanie jest trudne. Wymaga ciñgäej perfekcji przez miesiñce i lata pracy. W najlepszym przypadku pomyäki prowadzñ do powstania kodu, który siö nie kompiluje. W najgorszym — do bäödów czekajñcych w ukryciu, by ujawniè siö w momencie, w którym spowodujñ najwiöksze szkody. Ludzie rzadko pracujñ perfekcyjnie. Nie dziwi wiöc, Ĕe oprogramowanie zwykle ma bäödy. CzyĔ nie byäoby przydatne narzödzie, które informowaäoby o pomyäkach programistycznych bezpoĈrednio po ich popeänieniu; narzödzie tak skuteczne, Ĕe debugowanie staäoby siö niemal niepotrzebne? Jest takie narzödzie, a raczej technika. To wytwarzanie sterowane testami. Technika ta zapewnia opisane powyĔej efekty. Wytwarzanie sterowane testami (ang. test-driven development — TDD) to krótki cykl testowania, pisania i refaktoryzowania kodu. W czasie dodawania funkcji para moĔe przeprowadziè dziesiñtki takich cykli, implementujñc i dopracowujñc oprogramowanie w maäych kroczkach do momentu, kiedy nie pozostanie nic do dodania lub usuniöcia. Badania pokazujñ, Ĕe TDD znacznie zmniejsza liczbö defektów [Janzen i Saiedian]. Technika ta, jeĈli jest uĔywana poprawnie, pomaga teĔ ulepszyè projekt, zapewnia dokumentacjö interfejsu publicznego i chroni przed dalszymi pomyäkami. Technika TDD oczywiĈcie nie jest doskonaäa (czy cokolwiek takie jest?). Trudno stosowaè jñ przy pracy nad odziedziczonym kodem bazowym. Nawet w nowych systemach trzeba jej uĔywaè przez kilka miesiöcy, aby dobrze jñ opanowaè. Warto jednak podjñè takñ próbö. Choè praktyki XP majñ pozytywny wpäyw na technikö TDD, nie sñ niezbödne do jej uĔywania. MoĔna jñ stosowaè w niemal kaĔdym projekcie.

Dlaczego technika TDD jest skuteczna? W czasach kart perforowanych programiĈci Ĕmudnie sprawdzali kod röcznie, aby siö upewniè, Ĕe moĔna go skompilowaè. Bäñd kompilacji mógä doprowadziè do niewykonania zadaþ wsadowych i däugich sesji diagnostycznych w poszukiwaniu literówek. Obecnie zapewnienie kompilacji kodu nie sprawia juĔ wiökszych problemów. WiökszoĈè Ĉrodowisk IDE sprawdza skäadniö w trakcie pisania, a niektóre nawet kompilujñ rozwiñzanie w momencie zapisywania go. Pötla z informacjami zwrotnymi jest tak krótka, Ĕe bäödy sñ äatwe do wykrycia i naprawienia. JeĈli dany fragment siö nie kompiluje, trzeba sprawdziè tylko niewielkñ iloĈè kodu. W wytwarzaniu sterowanym testami ta sama zasada dotyczy zamiarów programistów. Podobnie jak wspóäczesne kompilatory udostöpniajñ wiöcej informacji zwrotnych na temat skäadni kodu, tak TDD zapewnia informacje o jego dziaäaniu. W podejĈciu tym programiĈci co kilka minut — a nawet co 20 lub 30 sekund — sprawdzajñ, czy kod dziaäa zgodnie z ich oczekiwaniami. WYTWARZAN E STEROWANE TESTAM

339

JeĈli oprogramowanie dziaäa nieprawidäowo, trzeba sprawdziè tylko kilka wierszy kodu. Wyszukiwanie i naprawianie pomyäek jest äatwe. TDD opiera siö na podejĈciu podobnym do podwójnej ksiögowoĈci. ProgramiĈci realizujñ swe zamiary dwukrotnie, przedstawiajñc ten sam pomysä na dwa sposoby: najpierw jako test, a nastöpnie w postaci kodu produkcyjnego. JeĈli oba elementy pasujñ do siebie, prawdopodobnie zostaäy napisane prawidäowo. W przeciwnym razie musiaä pojawiè siö bäñd.

UWAGA Teoretycznie moĔliwe jest, Ĕe testy i kod zawierajñ dokäadnie ten sam bäñd. Wtedy wszystko na pozór dziaäa prawidäowo, choè kod jest niepoprawny. Jednak jeĈli programista nie przekleja fragmentów z testów do kodu produkcyjnego lub w drugñ stronö, jest to tak maäo prawdopodobne, Ĕe nie trzeba siö obawiaè wystñpienia tego problemu.

W TDD testy sñ pisane pod kñtem publicznego interfejsu klasy. Dotyczñ one gäównie dziaäania klasy, a nie jej implementacji. ProgramiĈci piszñ kaĔdy test przed rozpoczöciem pracy nad kodem produkcyjnym. Dziöki temu koncentrujñ uwagö na tworzeniu interfejsów äatwych raczej w uĔyciu niĔ implementacji, co ulepsza projekt interfejsu. Po zakoþczeniu wytwarzania testy pozostajñ. Sñ przesyäane do repozytorium wraz z pozostaäym kodem i peäniñ funkcjö „Ĕywej” dokumentacji. Co jednak waĔniejsze, programiĈci uruchamiajñ wszystkie testy przy (niemal) kaĔdej kompilacji, co gwarantuje, Ĕe kod wciñĔ dziaäa w sposób zgodny z oczekiwaniami. JeĈli ktoĈ przypadkowo zmieni funkcjonowanie kodu, na przykäad w trakcie nieprawidäowo przeprowadzonej refaktoryzacji, test nie powiedzie siö, co zasygnalizuje pomyäkö.

Jak stosowaë TDD? MoĔna zaczñè stosowanie TDD natychmiast. Jest to jedna z technik, której nauka trwa moment, a zgäöbianie — caäe Ĕycie.

UWAGA ãatwo nauczyè siö podstaw TDD, jednak przyjöcie nastawienia specyficznego dla tej metody wymaga trochö czasu. Do tego momentu technika ta moĔe wydawaè siö nieporöczna, powolna i dziwna. Aby siö do niej przyzwyczaiè, trzeba jej regularnie uĔywaè przez dwa lub trzy miesiñce.

TDD moĔna wyobraziè sobie jako maäy silnik o wysokich obrotach. Technika ta dziaäa w bardzo krótkich i nieustannie powtarzanych cyklach. Co kilka minut cykl ten posuwa prace nad rozwiñzaniem o maäy krok naprzód, co prowadzi do utworzenia fragmentu, który wprawdzie nie zawsze jest ukoþczony, ale zostaä przetestowany, zaprojektowany i napisany, a programista moĔe go przesäaè do repozytorium.

340 ROZDZ AĤ 9

WYTWARZAN E

Dziöki TDD co kilka minut udostöpniany jest sprawdzony fragment rozwiñzania, który zostaä przetestowany, zaprojektowany i napisany.

Etap 2. — czerwony pasek Teraz moĔna napisaè test. NaleĔy przygotowaè tylko tyle kodu, ile potrzeba na zaplanowane rozbudowanie dziaäania. Zwykle jest to mniej niĔ piöè wierszy kodu. Pisanie däuĔszych fragmentów jest dozwolone, jednak programista powinien staraè siö nastöpnym razem zaplanowaè krótsze zadanie. NaleĔy pisaè kod pod kñtem dziaäania klasy i interfejsu publicznego, a nie implementacji wewnötrznych mechanizmów klasy. NaleĔy przestrzegaè hermetyzacji. Oznacza to, Ĕe kilka pierwszych testów bödzie zawieraè nazwy metod i klas, które jeszcze nie istniejñ. Jest to celowe. Wymusza to na programiĈcie zaprojektowanie interfejsu klasy z perspektywy jej uĔytkownika, a nie autora. Po napisaniu kodu testu naleĔy uruchomiè caäy zestaw testu i upewniè siö, Ĕe nowy test koþczy siö niepowodzeniem. W wiökszoĈci narzödzi testowych uĔywanych w TDD prowadzi to do wyĈwietlenia czerwonego paska postöpu. Jest to pierwsza moĔliwoĈè porównania zamiarów z dziaäaniem kodu. JeĈli rozwiñzanie przejdzie test lub nie przejdzie go w sposób niezgodny z oczekiwaniami, musiaä pojawiè siö bäñd. MoĔliwe, Ĕe testy sñ nieprawidäowe lub nie sprawdzajñ tego, co — zdaniem programisty — powinny. NaleĔy rozwiñzaè problem. Programista powinien zawsze umieè przewidzieè, jak kod bödzie dziaäaä.

UWAGA Rozwiñzywanie problemów jest równie istotne w przypadku nieoczekiwanego powodzenia, jak i niespodziewanego niepowodzenia. Celem jest nie tylko przygotowanie dziaäajñcych testów, ale teĔ zachowanie kontroli nad kodem. Programista powinien zawsze wiedzieè, jak kod dziaäa i dlaczego.

Etap 3. — zielony pasek Nastöpnie trzeba napisaè dokäadnie tyle kodu produkcyjnego, aby testy zakoþczyäy siö powodzeniem. TakĔe tu kod nie powinien byè däuĔszy niĔ piöè wierszy. Nie naleĔy martwiè siö o czystoĈè projektu lub elegancjö, a jedynie sprawiè, aby kod przeszedä test. Czasem moĔna po prostu zapisaè na staäe odpowiedĒ w kodzie. Jest to dozwolone, poniewaĔ za chwilö programista przystñpi do refaktoryzacji. NaleĔy ponownie uruchomiè testy i upewniè siö, Ĕe wszystkie koþczñ siö powodzeniem. PomyĈlny wynik spowoduje wyĈwietlenie zielonego paska postöpu.

JeĈli testy zakoþczñ siö niepowodzeniem, a programista nie wie, dlaczego tak siö staäo, naleĔy przywróciè kod o sprawdzonej poprawnoĈci.

Jest to druga moĔliwoĈè porównania zamiarów z rzeczywistoĈciñ. JeĈli testy zakoþczñ siö niepowodzeniem, naleĔy jak najszybciej przywróciè kod o sprawdzonej poprawnoĈci. Czösto programista lub jego partner potrafiñ dostrzec problem, po raz wtóry przyglñdajñc siö ĈwieĔo napisanemu kodowi. JeĈli nie potrafiñ znaleĒè bäödu, powinni usunñè nowy kod i napisaè go od nowa. Czasem najlepiej jest usunñè nowy test (to w koþcu tylko kilka wierszy kodu) i rozpoczñè cykl od nowa, pracujñc nad mniejszym fragmentem.

342 ROZDZ AĤ 9

WYTWARZAN E

Przykĥad wykorzystania TDD Niedawno zapisaäem, w jaki sposób uĔyäem TDD do rozwiñzania przykäadowego problemu. Przyrosty sñ tu bardzo niewielkie (mogñ wydawaè siö nadmiernie maäe), jednak dziöki temu äatwiej zauwaĔyè pomyäki i pracowaè szybciej.

UWAGA ProgramiĈci, którzy dopiero zaczynajñ stosowaè TDD, czösto sñ zdziwieni niewielkimi rozmiarami kaĔdego przyrostu. Choè moĔe siö wydawaè, Ĕe tylko poczñtkujñcy muszñ w trakcie pracy robiè maäe kroki, wedäug moich doĈwiadczeþ jest inaczej: im wiöksze doĈwiadczenie programista ma w korzystaniu z TDD, tym mniejsze przyrosty tworzy i tym szybciej pracuje.

W trakcie lektury warto pamiötaè, Ĕe objaĈnianie powstawania przykäadowego kodu trwa znacznie däuĔej niĔ jego pisanie. Czas wykonania kaĔdego kroku moĔna mierzyè w sekundach.

Zadanie Moim zadaniem byäo napisanie klasy w jözyku Java do przetwarzania ciñgów znaków z zapytaniami HTTP4. Zdecydowaäem siö uĔyè do jej utworzenia techniki TDD.

Jedna para nazwa-wartoļë Etap 1. MyĈlenie. Pierwszy etap wymaga wyobraĔenia sobie poĔñdanej funkcjonalnoĈci kodu. Mojñ pierwszñ myĈlñ byäo: „Klasa powinna umieszczaè pary nazwa-wartoĈè w strukturze HashMap”. Niestety, wymagaäo to wiöcej niĔ kilku wierszy kodu, dlatego musiaäem zastanowiè siö nad mniejszym przyrostem. Czösto najlepszy sposób na zmniejszenie przyrostu to rozpoczöcie od pozornie banalnych przypadków. „Klasa musi umieszczaè jednñ parö nazwa-wartoĈè w strukturze HashMap”, pomyĈlaäem, co wydawaäo siö byè dobrym rozwiñzaniem. Etap 2. Czerwony pasek. Nastöpny etap to pisanie testów. Trzeba pamiötaè, Ĕe pod niektórymi wzglödami jest to èwiczenie z projektowania interfejsu. W tym przypadku na poczñtku chciaäem nazwaè klasö QueryStringParser, jednak nie jest ona wystarczajñco obiektowa. Zdecydowaäem siö na QueryString. Kiedy napisaäem test, zdaäem sobie sprawö, Ĕe klasa QueryString nie powinna zwracaè obiektu typu HashMap, ale hermetyzowaè go. W takiej klasie powinna znaleĒè siö metoda, na przykäad valueFor(name), zapewniajñca dostöp do par nazwa-wartoĈè.

UWAGA Warto zwróciè uwagö na to, Ĕe zastanawianie siö nad testem zmusiäo mnie do ustalenia projektu kodu.

4

Zakäadam, Ĕe Ĕyjö w alternatywnym Ĉwiecie, w którym nie ma miliardów bibliotek o takiej funkcjonalnoĈci.

344 ROZDZ AĤ 9

WYTWARZAN E

Utworzenie takiej metody wymagaäoby zbyt duĔo kodu, aby moĔna zaplanowaè to na jeden przyrost, dlatego zdecydowaäem siö utworzyè w zamian test metody count(). Uznaäem, Ĕe metoda ta powinna zwracaè äñcznñ liczbö par nazwa-wartoĈè. Test sprawdzaä, czy metoda ta dziaäa, jeĈli dostöpna jest tylko jedna wartoĈè: public void testOneNameValuePair() { QueryString qs = new QueryString("name=value"); assertEquals(1, qs.count()); }

Kod nie skompilowaä siö, dlatego napisaäem klasö QueryString i metodö count(), które nie wykonywaäy Ĕadnych operacji. public class QueryString { public QueryString(String queryString) {} public int count() { return 0; } }

Zgodnie z oczekiwaniami doprowadziäo to do wyĈwietlenia czerwonego paska. Etap 3. Zielony pasek. Aby kod przeszedä ten test, zapisaäem na staäe prawidäowñ odpowiedĒ. Mógäbym zaprogramowaè lepsze rozwiñzanie, ale nie byäem pewien, jak kod ma dziaäaè. Czy powinien zliczaè liczbö znaków równoĈci? Nie wszystkie äaþcuchy znaków z zapytaniem zawierajñ takie znaki. Zdecydowaäem siö zaryzykowaè. public int count() { return 1; }

Pasek byä zielony.

UWAGA Warto zauwaĔyè, Ĕe choè miaäem pomysäy na ukoþczenie klasy, nie chciaäem z góry ustalaè kierunku prac. Zachowaäem otwartoĈè na nowe moĔliwoĈci.

Etap 4. Refaktoryzacja. Nie podobaäa mi siö nazwa QueryString, ale wymyĈliäem nastöpny test i chciaäem zaczñè pracö nad nim. Zapisaäem na karteczce komentarz dotyczñcy poprawienia nazwy. MoĔliwe, Ĕe lepsza bödzie HttpQuery. MyĈlaäem, Ĕe moĔe zajmö siö tym w nastöpnym cyklu.

Etap 5. Powtórzenie. OczywiĈcie.

Pusty ĥaħcuch znaków MyĈlenie. Chciaäem zmusiè siö do usuniöcia zapisanej na staäe wartoĈci z instrukcji return 1, ale na razie nie miaäem zamiaru obsäugiwaè wielu äaþcuchów znaków. Nastöpny przyrost miaä dotyczyè metody valueFor() i chciaäem uniknñè zäoĔonoĈci zwiñzanej z obsäugñ wielu WYTWARZAN E STEROWANE TESTAM

345

äaþcuchów. Zdecydowaäem, Ĕe sprawdzenie warunku wystñpienia pustego äaþcucha znaków bödzie wymagaè ode mnie napisania poprawnej wersji metody count() bez zbytniego utrudniania nastöpnych przyrostów. Czerwony pasek. A oto nowy test. public void testNoNameValuePairs() { QueryString qs = new QueryString(„”); assertEquals(0, qs.count()); }

Na tym etapie test ten powoduje wyĈwietlenie czerwonego paska. Expected: <0> but was: <1>. Nie jest to zaskoczeniem. Test ten naprowadziä mnie na dwa pomysäy. Po pierwsze, powinienem sprawdzaè przypadek przekazywania argumentu null do konstruktora klasy QueryString. Po drugie, z uwagi na to, Ĕe w testach zaczöäy pojawiaè siö powtórzenia, powinienem je zrefaktoryzowaè. Dodaäem obie uwagi do karteczki.

Zielony pasek. W tym momencie musiaäem siö zatrzymaè i zastanowiè. Jaki jest najszybszy sposób na ponowne uzyskanie zielonego paska? Zdecydowaäem siö dodaè kod sprawdzajñcy, czy äaþcuch znaków zapytania jest pusty. public class QueryString { private String _query public QueryString(string queryString) { _query = queryString; } public int count() { if ("".equals(_query)) return 0; else return 1; } }

Refaktoryzacja. Dokäadnie przyjrzaäem siö liĈcie zadaþ do wykonania. Musiaäem zrefaktoryzowaè testy, jednak zdecydowaäem siö najpierw dodaè jeszcze jeden, aby ta potrzeba staäa siö bardziej widoczna. „Trzy uderzenia i refaktoryzacja”, jak mówi powiedzenie. Nadeszäa pora na nastöpne powtórzenie cyklu.

testNull() MyĈlenie. Lista obejmowaäa pozycjö „testNull()”, co oznaczaäo, Ĕe musiaäem sprawdziè przypadek wystñpienia pustego äaþcucha znaków zapytania. Zdecydowaäem siö zajñè tym zadaniem.

346 ROZDZ AĤ 9

WYTWARZAN E

Czerwony pasek. Ten test zmusiä mnie do zastanowienia siö nad dziaäaniem programu w sytuacji, kiedy podana wartoĈè to null. Zawsze lubiäem kod, który szybko zgäasza bäödy, dlatego zdecydowaäem, Ĕe wartoĈè null jest niedozwolona. Oznaczaäo to, Ĕe kod powinien zgäaszaè wyjñtek informujñcy jednostki wywoäujñce o tym, Ĕe nie moĔna uĔywaè takich wartoĈci. Podrozdziaä „Prosty projekt” w dalszej czöĈci rozdziaäu zawiera bardziej szczegóäowe omówienie szybkiego zgäaszania bäödów. public void testNull() { try { QueryString qs = new QueryString(null) fail("Powinien zgĨosiî wyjìtek"); } catch (NullPointerException e) { // Oczekiwane } }

Zielony pasek. Nic trudnego. public QueryString(String queryString) { if (queryString == null) throw new NullPointerException(); _query = queryString; }

Refaktoryzacja. Miaäem jeszcze poddaè testy refaktoryzacji, jednak nowy test nie miaä wystarczajñco duĔo wspólnego ze starszymi, abym czuä, Ĕe jest to niezbödne. TakĔe kod produkcyjny wyglñdaä dobrze, a na karteczce nie byäo Ĕadnych istotnych uwag. TakĔe tym razem zrezygnowaäem z refaktoryzacji.

UWAGA Choè nie w kaĔdym cyklu przeprowadzam refaktoryzacjö, zawsze zatrzymujö siö i powaĔnie zastanawiam nad tym, czy projekt jej potrzebuje.

valueFor()

MyĈlenie. Co dalej? ãatwe testy juĔ utworzyäem. Zdecydowaäem siö rozpoczñè rozwój klasy i zaimplementowaè metodö valueFor(). Ta metoda miaäa przyjmowaè nazwö z pary nazwawartoĈè z äaþcucha znaków zapytania i zwracaè odpowiedniñ wartoĈè. Kiedy zastanawiaäem siö nad testem dla tej metody, zdaäem sobie sprawö, Ĕe muszö teĔ sprawdziè, co siö stanie, jeĈli nazwa nie istnieje. Zapisaäem to na karteczce.

WYTWARZAN E STEROWANE TESTAM

347

Czerwony pasek. Aby test zakoþczyä siö niepowodzeniem, dodaäem nowñ asercjö na koniec istniejñcego testu testOneNameValuePair(). public void testOneNameValuePair() { QueryString qs = new QueryString("name=value"); assertEquals(1, qs.count()); assertEquals("value", qs.valueFor("name")); }

Zielony pasek. Ten test zmusiä mnie do chwili zastanowienia. Czy rozwiñzaniem bödzie metoda split()? Uznaäem, Ĕe tak. public String valueFor(String name) { String[] nameAndValue = _query.split("="); return nameAndValue[1]; }

Ten kod przeszedä testy, jednak byä niekompletny. Co siö stanie, jeĈli äaþcuch znaków zawiera wiöcej niĔ jeden znak równoĈci lub w ogóle nie obejmuje takich znaków? Wymagaäo to odpowiedniej obsäugi bäödów. Dodaäem uwagö na temat dodania testów dla tych scenariuszy. Refaktoryzacja. Martwiäy mnie nazwy. Uznaäem, Ĕe nazwa QueryString jest poprawna, ale nie doskonaäa. TakĔe nazwa qs w testach byäa nieelegancka, dlatego zmieniäem jñ na query.

Wiele par nazwa-wartoļë

MyĈlenie. Zapisaäem, Ĕe mam dodaè obsäugö bäödów w metodzie valueFor(), jednak chciaäem zmierzyè siö z czymĈ bardziej konkretnym. Zdecydowaäem siö dodaè test dla wielu par nazwa-wartoĈè. Czerwony pasek. Przy zmiennej liczbie elementów zwykle sprawdzam trzy przypadki: kiedy nie ma Ĕadnych obiektów, kiedy jest tylko jeden i kiedy sñ trzy elementy. Miaäem juĔ test dla zera obiektów i jednego, dlatego teraz dodaäem sprawdzanie trzech. public void testMultipleNameValuePairs() { QueryString query = new QueryString("name1=value1&name2=value2&name3=value3"); assertEquals("value1", query.valueFor("name1")); assertEquals("value2", query.valueFor("name2")); assertEquals("value3", query.valueFor("name3")); }

Mogäem napisaè asercjö dla metody count() zamiast valueFor(), jednak naprawdö kluczowa byäa ta ostatnia metoda. Dodaäem komentarz na temat póĒniejszego przetestowania metody count().

348 ROZDZ AĤ 9

WYTWARZAN E

Zielony pasek. Na poczñtku uznaäem, Ĕe takĔe w tym przypadku dobrym rozwiñzaniem bödzie metoda split(). public String valueFor(String name) { String[] pairs = _query.split("&"); for (String pair : pairs) { String[] nameAndValue = pair.split(" = "); if (nameAndValue[0].equals(name)) return nameAndValue[1]; } throw new RuntimeException(name + " nie znaleziono"); }

OkropnoĈè. Kod nie wyglñdaä elegancko. Jednak test zakoþczyä siö powodzeniem!

UWAGA Lepiej jest szybko uzyskaè zielony pasek, niĔ staraè siö doprowadziè kod do perfekcji. Zielony pasek zapewnia zachowanie kontroli nad kodem i umoĔliwia wypróbowanie refaktoryzacji majñcych poprawiè nieeleganckie rozwiñzanie.

Refaktoryzacja. Nowe fragmenty metody valueFor() byäy nieeleganckie. Przyjrzaäem siö im baczniej. Najbardziej martwiäy mnie dwa zagadnienia: tablica nameAndValue i wyjñtek RuntimeException. Próba refaktoryzacji tej tablicy doprowadziäa do obniĔenia jakoĈci kodu, dlatego zdecydowaäem siö pozostawiè jñ w obecnej formie do nastöpnej refaktoryzacji. Wyjñtek RuntimeException stanowiä wiökszy problem. Lepiej jest zgäaszaè wyjñtki niestandardowe. Jednak w tym przypadku konwencje jözyka Java zalecajñ zwracanie wartoĈci null, a nie zgäaszanie wyjñtku. Zapisaäem juĔ uwagö dotyczñcñ testowania sytuacji, w której nie moĔna znaleĒè danej nazwy. Zmieniäem ten komentarz tak, aby stwierdzaä, Ĕe poprawnym dziaäaniem jest zwracanie wartoĈci null. Po dalszej analizie zauwaĔyäem, Ĕe w powielonej logice testów znajdujñ siö juĔ trzy powtórzenia. PomyĈlaäem, Ĕe nadeszäa pora na refaktoryzacjö. Jednak po zastanowieniu uznaäem, Ĕe jedyne powtórzenie polega na trzykrotnym tworzeniu obiektu klasy QueryString. Wszystkie pozostaäe elementy byäy odmienne, wäñcznie z parametrami konstruktora tej klasy. Okazaäo siö wiöc, Ĕe testy nie wymagaäy refaktoryzacji. Usunñäem odpowiedni komentarz z listy. W rzeczywistoĈci kod wyglñdaä caäkiem dobrze, a przynajmniej lepiej, niĔ poczñtkowo sñdziäem. Chyba jestem dla siebie zbyt surowy.

Metoda count() dla wielu elementów

WYTWARZAN E STEROWANE TESTAM

349

MyĈlenie. Po przejrzeniu notatek stwierdziäem, Ĕe prawdopodobnie powinienem sprawdziè niepoprawne zastosowanie ampersandów, na przykäad umieszczenie dwóch takich znaków obok siebie. Zapisaäem uwagö dotyczñcñ dodania odpowiedniego testu. Najpierw jednak chciaäem sprawiè, aby metoda count() dziaäaäa prawidäowo dla wielu par nazwa-wartoĈè. Czerwony pasek. Dodaäem do testu asercjö dla metody count(). Zgodnie z oczekiwaniami test zakoþczyä siö niepowodzeniem. public void testMultipleNameValuePairs() { QueryString query = new QueryString("name1=value1&name2=value2&name3=value3"); assertEquals(3, query.count()); assertEquals("value1", query.valueFor("name1")); assertEquals("value2", query.valueFor("name2")); assertEquals("value3", query.valueFor("name3")); }

Zielony pasek. Aby zapewniè powodzenie tego testu, uĔyäem kodu z metody valueFor() i zmodyfikowaäem go. Byäo to oczywiste powielenie kodu, jednak planowaäem przeprowadziè refaktoryzacjö, kiedy uzyskam zielony pasek. public int count() { String[] pairs = _query.split("&"); return pairs.length; }

Udaäo mi siö usunñè wiöcej skopiowanego kodu, niĔ przypuszczaäem. Jednak, ku memu zaskoczeniu, testy zakoþczyäy siö niepowodzeniem. Problem pojawiaä siö przy pustym äaþcuchu znaków zapytania: expected: <0> but was: <1>. Zapomniaäem, Ĕe metoda split() zwraca wyjĈciowy äaþcuch znaków, jeĈli nie znajdzie znaku rozdzielajñcego. Testy zakäadaäy zwracanie w takim scenariuszu pustej tablicy. Dodaäem warunek zabezpieczajñcy, który rozwiñzaä problem. Wyglñdaäo to nieelegancko, dlatego planowaäem bliĔej przyjrzeè siö temu rozwiñzaniu po udanym zakoþczeniu testów. public int count() { if ("".equals(_query)) return 0; String[] pairs = _query.split("&"); return pairs.length; }

Refaktoryzacja. Tym razem refaktoryzacja byäa niezbödna. Powtórzenie w metodach count() i valueFor() nie byäo däugie (tylko jeden wiersz), jednak obie metody przetwarzaäy äaþcuch znaków zapytania, co byäo powieleniem funkcji, choè nie kodu. Zdecydowaäem siö to poprawiè. Na poczñtku nie byäem pewien, jak rozwiñzaè problem. Zdecydowaäem siö spróbowaè umieĈciè äaþcuch znaków w strukturze HashMap, jak planowaäem to zrobiè na samym poczñtku pracy. Aby refaktoryzacja nie byäa rozbudowana, na poczñtku nie zmieniaäem metody count() i wprowadziäem poprawki tylko w metodzie valueFor(). Wymagaäo to jedynie drobnych modyfikacji. public String valueFor(String name) { HashMap map = new HashMap(); String[] pairs = _query.split("&"); for (String pair : pairs) { String[] nameAndValue = pair.split("="); map.put(nameAndValue[0], nameAndValue[1]); } return map.get(name); }

350 ROZDZ AĤ 9

WYTWARZAN E

UWAGA Ta refaktoryzacja wyeliminowaäa wyjñtek zgäaszany w sytuacji, kiedy nie znaleziono danej nazwy. Technicznie zmieniäo to dziaäanie programu. Jednak z uwagi na to, Ĕe nie napisaäem jeszcze testów dla tego scenariusza, nie byäo to problemem. Upewniäem siö, Ĕe zapisaäem komentarz dotyczñcy póĒniejszego przetestowania tego przypadku, i przystñpiäem do wykonywania nastöpnych zadaþ.

PowyĔszy kod przetwarzaä äaþcuch znaków przy kaĔdym wywoäaniu metody valueFor(), co nie byäo najlepszym rozwiñzaniem. Zachowaäem kod metody valueFor(), aby refaktoryzacja byäa prosta. Teraz chciaäem przenieĈè kod z tej metody do konstruktora. Wymagaäo to serii refaktoryzacji, które opisujö w podrozdziale „Refaktoryzacja” w dalszej czöĈci rozdziaäu. Po kaĔdej refaktoryzacji ponownie uruchamiaäem testy, aby sprawdziè, czy nie naruszyäem poprawnoĈci programu. Okazaäo siö, Ĕe po jednej z refaktoryzacji testy zakoþczyäy siö niepowodzeniem. Kiedy kod wywoäywaä parser z poziomu konstruktora, znów nie powiódä siö test pustego äaþcucha znaków zapytania, testNoNameValuePairs(), poniewaĔ doprowadziä do zgäoszenia wyjñtku w parserze. Podobnie jak wczeĈniej, dodaäem warunek zabezpieczajñcy, co rozwiñzaäo problem. Po wszystkich refaktoryzacjach testy i kod produkcyjny byäy eleganckie i przejrzyste. public class QueryStringTest extends TestCase { public void testOneNameValuePair() { QueryString query = new QueryString("name=value"); assertEquals(1, query.count()); assertEquals("value", query.valueFor("name")); } public void testMultipleNameValuePairs() { QueryString query = new QueryString("name1=value1&name2=value2&name3=value3"); assertEquals(3, query.count()); assertEquals("value1", query.valueFor("name1")); assertEquals("value2", query.valueFor("name2")); assertEquals("value3", query.valueFor("name3")); } public void testNoNameValuePairs() { QueryString query = new QueryString(""); assertEquals(0, query.count()); } public void testNull() { try { QueryString query = new QueryString(null); fail("Nalešy zgĪosið wyjîtek"); } catch (NullPointerException e) { // Oczekiwane } } } public class QueryString { private HashMap _map = new HashMap(); public QueryString(String queryString) { if (queryString == null) throw new NullPointerException(); parseQueryString(queryString);

WYTWARZAN E STEROWANE TESTAM

351

} public int count() { return _map.size(); } public String valueFor(String name) { return _map.get(name); } private void parseQueryString(String query) { if ("".equals(query)) return; String[] pairs = query.split("&"); for (String pair : pairs) { String[] nameAndValue = pair.split("="); _map.put(nameAndValue[0], nameAndValue[1]); } } }

Kolej na Czytelnika

Klasa nie byäa jeszcze gotowa. Trzeba byäo dodaè obsäugö nieprawidäowego uĔycia znaków równoĈci i ampersandów, a ponadto implementacja specyfikacji äaþcuchów znaków zapytania byäa niepeäna5. Jednak z uwagi na oszczödnoĈè miejsca pozostawiam dodanie pozostaäych funkcji jako zadanie dla Czytelnika. W trakcie jego wykonywania warto pamiötaè o pracy w bardzo maäych etapach i zastanawianiu siö nad refaktoryzacjñ w kaĔdym cyklu.

Narzýdzia do testowania Do stosowania TDD niezbödna jest platforma testowa. Najbardziej popularne sñ narzödzia z rodziny xUnit, na przykäad JUnit (dla jözyka Java) i NUnit (dla jözyków z grupy .NET). Jest to oprogramowanie o otwartym dostöpie do kodu Ēródäowego. Choè autorami poszczególnych narzödzi sñ róĔne osoby, zwykle stosujñ podstawowe podejĈcie charakterystyczne dla pionierskiej platformy SUnit Kenta Becka.

5

Na przykäad Ĉrednik w äaþcuchach znaków dziaäa jak ampersand.

352 ROZDZ AĤ 9

WYTWARZAN E

UWAGA Instrukcje korzystania z konkretnych narzödzi wykraczajñ poza zakres tej ksiñĔki. W internecie znajduje siö wiele samouczków dla poczñtkujñcych.

JeĈli zespóä uĔywa platformy, dla której nie ma narzödzia z rodziny xUnit, powinien sam je utworzyè. Choè dostöpne programy majñ graficzne interfejsy uĔytkownika i inne wymyĈlne funkcje, nie jest to niezbödne. Wystarczy zapewniè moĔliwoĈè uruchomienia wszystkich metod testowych w ramach jednego pakietu, kilka rodzajów asercji i jednoznaczny wynik po przeprowadzeniu wszystkich testów.

Znaczenie szybkoļci W TDD, podobnie jak w samym programowaniu, trzeba poznaè wiele niuansów. Jednak juĔ same podstawowe etapy — czerwony, zielony, refaktoryzacja — pozwalajñ uzyskaè bardzo dobre efekty. Z czasem programista dopracuje uĔywane podejĈcie. Jednym z niuansów w TDD jest szybkoĈè testów. Nie chodzi przy tym o czöstotliwoĈè dodawania poszczególnych przyrostów, co takĔe jest istotne, ale o to, ile czasu zajmuje przeprowadzenie wszystkich testów. W TDD testy sñ uruchamiane raz lub dwa razy na minutö, dlatego muszñ dziaäaè szybko. W przeciwnym razie bödñ bardziej przeszkadzaè, niĔ pomagaè. Programista nie bödzie uruchamiaä ich równie czösto, co zmniejszy podstawowñ korzyĈè päynñcñ ze stosowania TDD: tworzenie drobnych, sprawdzonych przyrostów. Nielsen donosi, Ĕe uĔytkownicy tracñ zainteresowanie zadaniem i przechodzñ do nastöpnego, jeĈli muszñ czekaè na jego ukoþczenie däuĔej niĔ 10 sekund [Nielsen]. Komputery wydajñ siö „szybkie” tylko wtedy, kiedy uĔytkownicy muszñ czekaè krócej niĔ sekundö. Choè badania Nielsena dotyczñ obszaru projektowania interfejsu uĔytkownika, zauwaĔyäem, Ĕe jego wnioski NaleĔy upewniè siö, sñ prawdziwe takĔe przy przeprowadzaniu testów. Ĕe przeprowadzenie testów JeĈli trwajñ one däuĔej niĔ 10 sekund, mam ochotö zajmuje mniej niĔ 10 sekund. sprawdziè pocztö, poprzeglñdaè strony w internecie lub zajñè siö jeszcze innym zadaniem. Powrót do pracy zajmuje mi wtedy kilka minut. Aby uniknñè podobnych opóĒnieþ, naleĔy upewniè siö, Ĕe przeprowadzenie testów zajmuje mniej niĔ 10 sekund. Jeszcze lepiej, jeĈli trwajñ one mniej niĔ sekundö. ãatwy sposób na ograniczenie czasu testowania polega na uruchamianiu podzbioru testów w cyklach TDD. Co pewien czas programista powinien uruchomiè wtedy caäy zestaw testów, aby upewniè siö, Ĕe przypadkowo nie naruszyä poprawnoĈci kodu. Jest to waĔne zwäaszcza przed integracjñ i w czasie refaktoryzacji, które dotykajñ wiele klas. Uruchamianie podzbioru testów grozi niewykryciem pomyäki, co moĔe doprowadziè do irytujñcych problemów w trakcie debugowania. Zaawansowani uĔytkownicy projektujñ testy tak, aby wykonywaäy siö szybko. Wymaga to uwzglödnienia wad i zalet trzech podstawowych typów testów automatycznych: x testów jednostek, które dziaäajñ z czöstotliwoĈciñ kilkuset na sekundö; x wyspecjalizowanych testów integracji, których w ciñgu sekundy moĔna uruchomiè kilka; x testów kompleksowych, których wykonanie czösto zajmuje kilka sekund.

WYTWARZAN E STEROWANE TESTAM

353

Zdecydowanñ wiökszoĈè testów powinny stanowiè testy jednostek, niewielkñ czöĈè — testy integracji, a testów kompleksowych nie powinno byè wiöcej niĔ kilka.

Testy jednostek Testy jednostek dotyczñ tylko danej klasy lub metody. Sñ uruchamiane w caäoĈci w pamiöci, dziöki czemu dziaäajñ bardzo szybko. Na niektórych platformach narzödzia do testowania mogñ uruchomiè ponad 100 takich testów na sekundö. Feathers przedstawia doskonaäñ definicjö testów jednostek [Feathers]: Testy jednostek dziaäajñ szybko. JeĈli sñ powolne, nie sñ testami jednostek. Czösto mianem tym okreĈla siö inne testy. Test nie jest testem jednostki, jeĈli:

1. komunikuje siö z bazñ danych; 2. uĔywa sieci do komunikacji; 3. korzysta z systemu plików; 4. programista musi wykonaè pewne operacje w Ĉrodowisku (na przykäad zmodyfikowaè pliki konfiguracyjne), aby go uruchomiè.

Testy majñce te cechy sñ testami integracji, a nie jednostek. Tworzenie testów jednostek wymaga dobrego projektu. Wysoce powiñzany system — bäotna bryäa lub oprogramowanie z kodem spaghetti — utrudnia pisanie takich testów. JeĈli programista ma problemy z ich tworzeniem lub uwaĔa definicjö Feathersa za zanadto wyidealizowanñ, jest to oznakñ bäödów w projekcie. NaleĔy zastanowiè siö nad moĔliwoĈciñ zmniejszenia powiñzaþ w kodzie, aby moĔna byäo przetestowaè kaĔdñ klasö (lub zbiór powiñzanych klas) niezaleĔnie od reszty kodu. Wskazówki na ten temat zawiera podrozdziaä „Prosty projekt” w dalszej czöĈci rozdziaäu. Warto teĔ poprosiè o pomoc mentora.

OBIEKTY ZASTüPCZE Obiekty zastýpcze (ang mock objects) to popu arne na zýdz e do zo owan a k as na potrzeby testów jednostek Podejļc e to po ega na zastýpowan u w testach ob ektów, które komun kujé s ý z jednostkam zewnýt znym , nowym ob ektam („ob ektam zastýpczym ”) Ob ekt zastýpczy sprawdza, czy zostaĥ praw dĥowo wywoĥany, przekazuje usta oné odpow edŚ Pozwa a to un knéë czasochĥonnej komun kacj z bazé danych, gn azdam s ec owym nnym jednostkam zewnýtrznym Na eŜy jednak wyst zegaë s ý ob ektów zastýpczych Powodujé one wzrost zĥoŜonoļc w éŜé testy z mp ementacjé kodu K edy program sta zechce uŜyë ob ektu zastýpczego, pow n en zastanow ë s ý, czy n e moŜe usprawn ë projektu kodu, aby moŜna byĥo zrezygnowaë z tak ego rozw ézan a Czy moŜna usunéë z kodu za eŜnoļc od zewnýtrznych jednostek? Czy moŜna udostýpn ë pot zebne dane (na przykĥad w konstrukto ze), zam ast je pob eraë? Ob ekty zastýpcze to p zydatna techn ka, a uŜyc e jej to czasem naj epszy sposób na przetestowan e kodu Zan m jednak program sta uzna, Ŝe warto zastosowaë to podejļc e, pow n en dokĥadn ej przyjrzeë s ý projektow MoŜ we, Ŝe uda s ý go u epszyë

354 ROZDZ AĤ 9

WYTWARZAN E

Wyspecjalizowane testy integracji Testy jednostek nie wystarczñ. W pewnym momencie kod musi nawiñzaè komunikacjö ze Ĉwiatem zewnötrznym. MoĔna uĔyè TDD takĔe do rozwoju takiego kodu. Test, w którym kod musi wywoäaè bazö danych, komunikowaè siö przez sieè, korzystaè z systemu plików lub w inny sposób wyjĈè poza granice procesu, to test integracji. Najlepsze testy tego typu to wyspecjalizowane testy integracji (ang. focused integration test), w których badany jest tylko jeden typ interakcji ze Ĉwiatem zewnötrznym.

UWAGA Testy integracji nie sprawdzajñ tego, czy elementy caäego systemu dobrze ze sobñ wspóädziaäajñ. Do tego säuĔñ testy kompleksowe.

Jednñ z trudnoĈci w uĔywaniu testów integracji jest koniecznoĈè przygotowania pod kñtem testów zewnötrznych jednostek, od których zaleĔy kod. Testy naleĔy uruchamiaè za kaĔdym razem w dokäadnie taki sam sposób, niezaleĔnie od kolejnoĈci ich uruchamiania lub stanu maszyny przed ich przeprowadzeniem. Przy testach jednostek jest to äatwe, jednak przy testach integracji mogñ wystñpiè trudnoĈci. JeĈli programista sprawdza moĔliwoĈè pobierania danych z tabeli bazy danych, dane te muszñ byè w niej dostöpne. NaleĔy upewniè siö, Ĕe kaĔdy test integracji moĔna uruchomiè niezaleĔnie od pozostaäych. Takie testy NaleĔy upewniè siö, Ĕe kaĔdy powinny konfigurowaè potrzebne Ĉrodowisko, test jest odröbny od pozostaäych. a nastöpnie przywracaè wyjĈciowy stan. Przywrócenie stanu jest konieczne nawet wtedy, kiedy test siö nie powiedzie lub zostanie zgäoszony wyjñtek. Nie ma nic bardziej frustrujñcego od pakietu testów, który od czasu do czasu dziaäa nieprawidäowo. Czösto przyczynñ takiego stanu rzeczy sñ testy integracji, które nie konfigurujñ i nie przywracajñ w prawidäowy sposób Ĉrodowiska testowego.

UWAGA JeĈli testy od czasu do czasu dziaäajñ nieprawidäowo, nie naleĔy ignorowaè problemu, nawet jeĈli programista potrafi go „rozwiñzaè”, ponownie uruchamiajñc testy. Nieregularnie wystöpujñce bäödy to jeden z aspektów däugu technicznego. Utrudniajñ przeprowadzanie testów i ukrywajñ prawdziwe problemy.

Zwykle nie jest potrzebna duĔa liczba testów integracji. Najlepsze testy tego typu sñ wysoce wyspecjalizowane. KaĔdy z nich sprawdza tylko jeden aspekt moĔliwoĈci komunikowania siö programu ze Ĉwiatem zewnötrznym. Liczba takich testów w pakiecie zaleĔy od typów interakcji programu z jednostkami zewnötrznymi, a nie od ogólnej wielkoĈci oprogramowania. Inaczej jest w przypadku testów jednostek, których liczba jest proporcjonalna do ogólnego rozmiaru programu. DuĔa liczba potrzebnych testów integracji wskazuje na problemy z projektem. MoĔe to oznaczaè, Ĕe kod komunikujñcy siö z jednostkami zewnötrznymi jest niespójny. Na przykäad, jeĈli wszystkie obiekty biznesowe komunikujñ siö z bazñ danych bezpoĈrednio, potrzebny jest test integracji dla kaĔdego z nich. W lepszym projekcie z bazñ danych komunikuje siö tylko jedna

WYTWARZAN E STEROWANE TESTAM

355

Problemy z odziedziczonym kodem polegajñ na tym, Ĕe z uwagi na to, iĔ zostaäy utworzone bez testów, zwykle nie sñ projektowane pod kñtem äatwoĈci testowania. Aby dodaè testy, trzeba zmodyfikowaè kod. Aby zmieniè kod i mieè pewnoĈè, Ĕe jest poprawny, trzeba wprowadziè testy. To wäaĈnie to bäödne koäo sprawia, Ĕe tak trudno jest pracowaè nad odziedziczonym kodem. Ponadto odziedziczony kod czösto wiñĔe siö z obecnoĈciñ wysokiego däugu technicznego, który jeszcze bardziej utrudnia pracö. Trudno jest usunñè taki däug, jeĈli programiĈci bojñ siö zmieniaè istniejñcy kod. Czasem trudno zrozumieè, jak poszczególne elementy wspóädziaäajñ ze sobñ, poniewaĔ metody i funkcje powodujñ niezauwaĔalne efekty uboczne. Jednym z rozwiñzaþ tego problemu jest wprowadzenie kompleksowych testów wstöpnych (ang. smoke test). Te testy sprawdzajñ standardowe scenariusze uĔytkowania obejmujñce komponenty, które zespóä chce zmodyfikowaè. Testy tego typu nie zapewniajñ caäkowitej pewnoĈci co do poprawnoĈci kodu, jednak przynajmniej informujñ o popeänieniu duĔej pomyäki. Po przygotowaniu testów wstöpnych moĔna rozpoczñè dodawanie testów jednostek. TrudnoĈè polega tu na znalezieniu odröbnych komponentów do przetestowania, poniewaĔ odziedziczony kod jest czösto mocno powiñzany. W zamian moĔna zastanowiè siö na sposobami strategicznego przerywania wykonania programu przez testy. Feathers nazywa te strategiczne miejsca szwami (ang. seam) [Feathers]. Na przykäad, jeĈli metoda w kodzie napisanym w jözyku obiektowym ma zaleĔnoĈci, których programista chce uniknñè, test moĔe wywoäywaè specyficznñ dla testu klasö pochodnñ. W klasie tej moĔna przesäoniè käopotliwñ metodö i umieĈciè zamiast niej namiastkö. Wyszukiwanie i wykorzystywanie szwów czösto prowadzi do tworzenia nieeleganckiego kodu. Jest to sytuacja, w której tymczasowe obniĔenie jakoĈci kodu moĔe doprowadziè do jego ulepszenia. Po wprowadzeniu testów naleĔy przeprowadziè refaktoryzacjö kodu pod kñtem äatwoĈci testowania, a nastöpnie poprawiè testy. Wtedy moĔna kontynuowaè prace, stosujñc TDD w standardowy sposób. Dodawanie testów do odziedziczonego kodu to skomplikowane zagadnienie, które zasäuguje na odröbnñ ksiñĔkö. Na szczöĈcie dostöpna jest doskonaäa pozycja na ten temat: Working Effectively with Legacy Code [Feathers].

Pytania Co trzeba testowaè, stosujñc TDD? Zgodnie z praktycznñ reguäñ naleĔy „testowaè wszystko, co moĔe dziaäaè nieprawidäowo”. Aby ustaliè, czy dany fragment moĔe zawieraè bäödy, zastanawiam siö: „Czy mam caäkowitñ pewnoĈè, Ĕe robiö to poprawnie, a nikt w przyszäoĈci nie naruszy przypadkowo poprawnoĈci tego kodu?”. Bolesne doĈwiadczenia nauczyäy mnie, Ĕe prawie wszystko moĔe dziaäaè nieprawidäowo, dlatego testujö niemal caäy kod. Jedyny wyjñtek to kod pozbawiony logiki, na przykäad proste akcesory lub mutatory (metody do pobierania i ustawiania wartoĈci) oraz te metody, których jedynym zadaniem jest wywoäywanie innych metod. Nie trzeba testowaè kodu napisanego przez innych programistów, chyba Ĕe istniejñ powody ku temu, aby im nie ufaè.

WYTWARZAN E STEROWANE TESTAM

357

Jak naleĔy testowaè metody prywatne? NaleĔy rozpoczñè od przetestowania metod publicznych, jak zrobiäem to w rozbudowanym przykäadzie dotyczñcym klasy QueryString. Po refaktoryzacji czöĈè kodu znajdzie siö w metodach prywatnych, ale istniejñce testy nadal powinny dokäadnie sprawdzaè ich dziaäanie. JeĈli kod jest tak skomplikowany, Ĕe trzeba bezpoĈrednio przetestowaè metodö prywatnñ, moĔe to wskazywaè na potrzebö refaktoryzacji. Czasem korzystne jest przeniesienie metod prywatnych do odröbnej klasy i udostöpnienie interfejsu publicznego. Pomocna moĔe okazaè siö refaktoryzacja „wydzielenie metody do odröbnej klasy” [Fowler 1999, s. 135]. Jak mam uĔywaè TDD przy tworzeniu interfejsu uĔytkownika? Korzystanie z TDD jest szczególnie trudne przy rozwoju interfejsu uĔytkownika, poniewaĔ wiökszoĈè platform do tworzenia interfejsów nie jest zaprojektowana pod kñtem äatwoĈci testowania. Wiele osób decyduje siö na ustöpstwa i pisze bardzo prostñ, nieprzetestowanñ warstwö poĈredniñ, która jedynie przekazuje wywoäania interfejsu uĔytkownika do warstwy prezentacji. Tacy programiĈci przechowujñ caäñ logikö interfejsu uĔytkownika w warstwie prezentacji i w standardowy sposób uĔywajñ TDD do rozwoju kodu tej warstwy. Dostöpne sñ narzödzia, które umoĔliwiajñ bezpoĈrednie testowanie interfejsu uĔytkownika, na przykäad przez wywoäania HTTP (dla oprogramowania sieciowego) lub wciĈniöcie przycisków oraz symulowanie zdarzeþ zwiñzanych z oknami (dla oprogramowania klienckiego). Sñ to w swej istocie testy integracji i prowadzñ do podobnych trudnoĈci w obszarze szybkoĈci i konserwacji, co inne testy tego typu. Jednak mimo to te narzödzia mogñ byè pomocne. MówiäeĈ o refaktoryzacji kodu testów. Czy ktokolwiek naprawdö to robi? Tak. Ja tak postöpujö i wszyscy powinni. Testy to zwykäy kod. Stosujñ siö do nich standardowe dobre praktyki programistyczne: naleĔy unikaè powtórzeþ, wybieraè dobre nazwy i prawidäowo faktoryzowaè oraz projektowaè je. Widziaäem, jak w ogólnie poprawnie prowadzonych projektach pojawiaäy siö problemy z uwagi na wraĔliwe na bäödy pakiety testów. Zastosowanie TDD jako podstawowej techniki rozwoju zobowiñzuje zespóä do konserwacji testów w równym stopniu jak pozostaäego kodu. NaleĔy traktowaè je tak samo starannie.

Efekty Dziöki prawidäowemu stosowaniu TDD nie trzeba spödzaè wiele czasu na debugowaniu. Choè programiĈci wciñĔ popeäniajñ bäödy, moĔna je bardzo szybko znaleĒè i äatwo naprawiè. Zespóä ma teĔ pewnoĈè, Ĕe caäy kod bazowy jest dobrze przetestowany, co umoĔliwia aktywnñ refaktoryzacjö przy kaĔdej nadarzajñcej siö okazji, poniewaĔ testy wychwycñ wszelkie pomyäki.

Przeciwwskazania Choè TDD to bardzo wartoĈciowe narzödzie, na jego opanowanie trzeba poĈwiöciè od dwóch do trzech miesiöcy. ãatwo stosowaè tö metodö do maäych problemów, takich jak napisanie klasy QueryString, jednak wykorzystanie jej przy tworzeniu wiökszych systemów wymaga praktyki. Szczególnie trudne sñ: rozwój odziedziczonego kodu, prawidäowe wyodröbnianie

358 ROZDZ AĤ 9

WYTWARZAN E

testów jednostek i testy integracji. Jednak im wczeĈniej zespóä zacznie stosowaè TDD, tym szybciej opanuje tö metodö, dlatego nie naleĔy rezygnowaè z niej w obawie przed trudnoĈciami. NaleĔy zachowaè ostroĔnoĈè przy stosowaniu TDD bez zezwolenia. W trakcie poznawania tego narzödzia wydajnoĈè czasem na pewien czas maleje. MoĔe to mieè negatywne skutki i doprowadziè do odrzucenia TDD przez organizacjö bez starannego rozwaĔenia wad i zalet tej techniki. ZauwaĔyäem, Ĕe w zmniejszeniu przeszkód pomaga äñczenie w szacunkach czasu poĈwiöcanego na testowanie i wytwarzanie. Programista powinien takĔe uwaĔaè, jeĈli stosuje TDD jako jedyny czäonek zespoäu. MoĔliwe, Ĕe wspóäpracownicy naruszñ poprawnoĈè testów i nie naprawiñ ich. Caäy zespóä powinien zdecydowaè siö na wspólne wypróbowanie tej techniki.

Inne moŜliwoļci TDD to istota praktyk programistycznych XP. Bez tej techniki duĔo trudniej stosowaè wszystkie pozostaäe praktyki techniczne. Czösto za TDD mylnie uznaje siö podejĈcie polegajñce na zaprojektowaniu najpierw caäej klasy, napisaniu póĒniej wszystkich metod testowych, a kodu — na samym koþcu. Takie postöpowanie jest frustrujñce i powolne oraz nie umoĔliwia ciñgäego rozwoju wiedzy w trakcie pracy. Inne bäödne podejĈcie polega na tworzeniu testów po napisaniu kodu produkcyjnego. Jest to bardzo trudne rozwiñzanie. Kod produkcyjny trzeba zaprojektowaè pod kñtem äatwoĈci testowania, co nie jest äatwe, jeĈli testy nie sñ jeszcze gotowe. Dodatkowo utrudnia to podejĈcie fakt, Ĕe tworzenie testów po napisaniu kodu jest nudne. W praktyce pokusa przejĈcia do nastöpnego zadania zwykle przezwyciöĔa dñĔenie do utworzenia dobrze przetestowanego kodu. Choè moĔna zastosowaè powyĔsze techniki przygotowywania testów, TDD to nie tylko testy. Technika ta polega na uĔywaniu bardzo maäych przyrostów w celu utworzenia kodu o wysokiej jakoĈci i potwierdzonej poprawnoĈci. Nie znam Ĕadnych innych metod, które pozwalajñ równie szybko jak TDD wykrywaè i naprawiaè bäödy.

Dalsza lektura Wytwarzanie sterowane testami to jeden z najlepiej poznanych aspektów programowania ekstremalnego. Dostöpnych jest wiele doskonaäych ksiñĔek na temat róĔnych aspektów TDD. WiökszoĈè z nich koncentruje siö na jözyku Java i platformie JUnit, jednak omówione w tych pracach zagadnienia dotyczñ takĔe innych jözyków. KsiñĔka Test-Driven Development: By Example [Beck 2002] to dobre wprowadzenie do TDD. Osoby, którym spodobaä siö przykäad dotyczñcy klasy QueryString, zainteresujñ siö bogatymi przykäadami z tej ksiñĔki. Szczególnie ciekawe sñ wzorce TDD, omówione w czöĈci III. Astels w ksiñĔce Test-Driven Development: A Practical Guide [Astels] przedstawia bardziej rozbudowany przykäad, obejmujñcy caäy projekt. Recenzenci wysoko ocenili uwzglödnienie w tej pracy testów interfejsu uĔytkownika. JUnit Recipes [Rainsberger] to kompletna ksiñĔka zawierajñca omówienie róĔnorodnych problemów zwiñzanych z testowaniem, wäñcznie z dogäöbnñ analizñ testów w J2EE. Working Effectively with Legacy Code [Feathers] to lektura obowiñzkowa dla wszystkich programistów pracujñcych nad odziedziczonym kodem. WYTWARZAN E STEROWANE TESTAM

359

Refaktoryzacja KaĔdego dnia kod jest nieco lepszy niĔ dzieþ wczeĈniej.

Odb orcy P og amiļci

Entropia zawsze zwyciöĔa. W koþcu chaos przeksztaäci wspaniale zaplanowany i dobrze zaprojektowany kod w kod spaghetti. Przynajmniej kiedyĈ tak siö dziaäo, przed erñ refaktoryzacji. Refaktoryzacja to proces modyfikowania projektu kodu bez zmieniania jego dziaäania. Nie zmienia siö to, co kod robi, ale jak siö to dzieje. Refaktoryzacja jest odwracalna. Czasem jedna wersja kodu jest lepsza, a w innych sytuacjach — druga. Podobnie jak moĔna przeksztaäciè wyraĔenie x2 – 1 na (x + 1)(x – 1) i z powrotem, tak moĔna modyfikowaè projekt kodu, a robiñc to, moĔna powstrzymaè entropiö.

Projektowanie refleksyjne Refaktoryzacja umoĔliwia stosowanie podejĈcia, które nazwaäem projektowaniem refleksyjnym. Programista moĔe nie tylko utworzyè projekt i napisaè kod na jego podstawie, ale teĔ przeanalizowaè projekt istniejñcego kodu i poprawiè go. Jednym z najlepszych sposobów na wykrycie moĔliwoĈci usprawnienia kodu sñ zapachy kodu, czyli skondensowane porcje wiedzy, które pomagajñ dostrzec standardowe problemy w projekcie. Zapach kodu nie zawsze oznacza problemy projektowe. Jest to raczej jak dziwny zapach unoszñcy siö w kuchni. Czasem oznacza to, Ĕe pora wynieĈè Ĉmieci, ale moĔliwe teĔ, iĔ to po prostu wujek Gabriel uĔyä przy gotowaniu wyjñtkowo ostrego sera. W obu przypadkach wyczucie dziwnego zapachu wymaga bliĔszego przyjrzenia siö sytuacji. Doskonaäym omówieniem zapachów kodu jest praca Fowlera [Fowler 1999], napisana wraz z Kentem Beckiem. To naprawdö wartoĈciowa lektura. PoniĔej przedstawiam krótki opis najczöĈciej spotykanych zapachów, wäñcznie z kilkoma, o których Fowler i Beck nie wspominajñ7.

ZróŜnicowane zmiany i Chirurgia odpryskowa Te dwa zapachy pomagajñ wykryè problemy ze spójnoĈciñ. ZróĔnicowane zmiany (ang. divergent change) pojawiajñ siö, kiedy niepowiñzane ze sobñ poprawki majñ wpäyw na tö samñ klasö. Jest to oznaka tego, Ĕe klasa obejmuje zbyt wiele pojöè. NaleĔy jñ podzieliè i znaleĒè odröbne miejsce dla poszczególnych elementów. Chirurgia odpryskowa (ang. shotgun surgery) dotyczy zupeänie odwrotnego problemu i wiñĔe siö z sytuacjñ, kiedy programista musi zmodyfikowaè wiele klas, zmieniajñc jedno zagadnienie. Oznacza to, Ĕe dany element jest uwzglödniany w wielu miejscach kodu. NaleĔy znaleĒè lub utworzyè pojedyncze miejsce dla tego zagadnienia.

Obsesja na punkcie typów prostych i Zbitki danych Czasem pojöcia projektowe z wysokiego poziomu sñ reprezentowane przy uĔyciu typów prostych. Na przykäad typ decimal moĔe reprezentowaè zäotówki. Jest to zapach kodu 7

Prawie jak statyczna, ZaleĔnoĈè w czasie, Niepeäne obiekty i Bawienie siö z wartoĈciñ null po raz pierwszy zostaäy opisane w tej ksiñĔce.

360 ROZDZ AĤ 9

WYTWARZAN E

o nazwie Obsesja na punkcie typów prostych (ang. primitive obsession). NaleĔy rozwiñzaè problem, hermetyzujñc zagadnienie w klasie. Zbitki danych (ang. data clumps) to podobny zapach. Wystöpuje, kiedy kilka typów prostych reprezentuje razem dane pojöcie. Na przykäad kilka äaþcuchów znaków moĔe przedstawiaè adres. Jednak zamiast ukryè dane w pojedynczej klasie, programista po prostu utworzyä ich zbitek. Kiedy w kodzie wystöpujñ grupy zmiennych przekazywanych wspólnie, prawdopodobnie sñ to Zbitki danych. Tak jak przy Obsesji na punkcie typów prostych, rozwiñzaniem jest tu hermetyzacja pojöcia w odröbnej klasie.

Klasy danych i Klasy prawie jak statyczne Jednym z najczöstszych bäödów, które spotykam w programowaniu projektowym, jest umieszczanie danych i kodu do ich obsäugi w odröbnych klasach. Czösto prowadzi to do powielania kodu do manipulowania danymi. JeĈli klasa zawiera prawie wyäñcznie zmienne egzemplarza oraz akcesory i mutatory (metody do pobierania i ustawiania wartoĈci), jest to Klasa danych (ang. data class). Z kolei jeĈli klasa zawiera metody, ale jej obiekty nie majñ znaczñcego stanu, jest to Klasa prawie jak statyczna (ang. wannabee static class).

UWAGA Jednym ze sposobów na wykrycie klasy prawie jak statycznej jest ustalenie, czy moĔna przeksztaäciè wszystkie metody i zmienne egzemplarza na skäadowe statyczne (nazywane takĔe metodami i zmiennymi klasy) bez naruszania poprawnoĈci kodu.

Co ciekawe, jednñ z najwiökszych zalet programowania obiektowego jest moĔliwoĈè äñczenia danych z kodem, który nimi operuje. Klasy danych i Klasa prawie jak statyczna to bliĒniaki rozdzielone przy urodzeniu. NaleĔy doprowadziè do ich spotkania, äñczñc zmienne egzemplarza z metodami säuĔñcymi do manipulowania nimi.

Bawienie siý z wartoļcié null Puste referencje to szczególny problem dla programistów. Czasem sñ uĔyteczne, jednak zazwyczaj oznaczajñ bäödny stan lub inne warunki wystñpienia bäödu. ProgramiĈci czösto nie wiedzñ, co zrobiè po otrzymaniu pustej referencji. Dlatego metody nieraz sprawdzajñ, czy referencja nie jest pusta, a jeĈli jest, same przekazujñ wartoĈè null. Bawienie siö z wartoĈciñ null (ang. coddling nulls) w ten sposób prowadzi do zäoĔonych metod i oprogramowania naraĔonego na bäödy. Problemy ukryte za wartoĈciñ null sñ przekazywane na dalsze poziomy aplikacji, co prowadzi do nieprzewidywalnych bäödów w dziaäaniu oprogramowania. Czasem wartoĈè null trafia do bazy danych, co powoduje powtarzajñce siö problemy z aplikacjñ. Zamiast bawiè siö z wartoĈciñ null, naleĔy przyjñè strategiö szybkiego zgäaszania bäödów (zobacz podrozdziaä „Prosty projekt” w dalszej czöĈci rozdziaäu). Nie naleĔy przekazywaè wartoĈci null jako parametru do Ĕadnej metody, konstruktora lub wäaĈciwoĈci, chyba Ĕe wartoĈè ta ma okreĈlone znaczenie. Do informowania o bäödach powinny säuĔyè wyjñtki, a nie wartoĈè null. Trzeba upewniè siö, Ĕe nieoczekiwane puste referencje spowodujñ zgäoszenie wyjñtku (albo przy próbie dereferencji, albo w wyniku natrafienia na bezpoĈredniñ asercjö).

REFAKTORYZACJA

361

ZaleŜnoļë w czasie i Niepeĥne obiekty ZaleĔnoĈè w czasie (ang. time dependency) wystöpuje, kiedy metody klasy trzeba wywoäaè w odpowiedniej kolejnoĈci. Niepeäne obiekty (half-baked object) to specjalny przypadek ZaleĔnoĈci w czasie. Takie obiekty trzeba najpierw utworzyè, nastöpnie zainicjowaè, wywoäujñc metodö, a dopiero potem moĔna ich uĔywaè. ZaleĔnoĈè w czasie czösto wskazuje na problem z hermetyzacjñ. Klasa, zamiast niezaleĔnie zarzñdzaè swym stanem, oczekuje jego zmiany przez jednostki wywoäujñce. Prowadzi to do bäödów i powielania kodu w takich jednostkach. Trzeba zastanowiè siö nad metodami bardziej efektywnej hermetyzacji stanu klasy. Czasem okazuje siö, Ĕe klasa ma zbyt rozbudowanñ funkcjonalnoĈè i warto podzieliè jñ na mniejsze klasy.

Analiza istniejécego kodu Projektowanie refleksyjne wymaga od programisty zrozumienia projektu istniejñcego kodu. Najäatwiej zapytaè o to inne osoby z zespoäu. Rozmowy przy szkicach projektu widocznych na tablicy do doskonaäy sposób na naukö. Czasem Ĕaden czäonek zespoäu nie rozumie projektu lub programista chce samodzielnie zmierzyè siö z kodem. NaleĔy wtedy skoncentrowaè siö na zadaniach i interakcjach kaĔdego gäównego komponentu. Jaki jest cel dziaäania danego pakietu lub przestrzeni nazw? Co klasa reprezentuje? Jak wchodzi w interakcje z innymi pakietami, przestrzeniami nazw i klasami? NUnitAsp to narzödzie do testów jednostek logiki kodu ukrytego aplikacji napisanych w jözyku ASP.NET. Jedna z klas tego jözyka to HttpClient. MoĔna siö domyĈliè, Ĕe kieruje ona wywoäania do serwera HTTP (sieciowego), prawdopodobnie serwera sieciowego ASP.NET. Aby potwierdziè to zaäoĔenie, naleĔy przyjrzeè siö nazwom metod i zmiennych egzemplarza klasy. Klasa HttpClient zawiera metody GetPage, FollowLink, SubmitForm i HasCookie, a takĔe kilka staäych USER_AGENT i powiñzanych metod oraz wäaĈciwoĈci. DoĈè oczywiste jest, Ĕe klasa HttpClient emuluje serwer sieciowy. Teraz naleĔy rozciñgnñè ten poziom zrozumienia na powiñzane elementy. Od których klas zaleĔy klasa HttpClient? Które klasy zaleĔñ od niej? Jakie sñ ich zadania? W trakcie poznawania tych elementów naleĔy dodawaè nowñ wiedzö do diagramu na tablicy. Do zrozumienia interakcji poszczególnych metod z resztñ systemu pomocne mogñ byè diagramy sekwencji8 z jözyka UML. NaleĔy zaczñè od metody, którñ programista chce zrozumieè, i przejĈè po kolei przez wszystkie jej wiersze, rekurencyjnie dodajñc do diagramu kaĔdñ wywoäanñ metodö. Jest to doĈè czasochäonne podejĈcie, dlatego zalecam stosowanie go tylko wtedy, kiedy programista nie wie, jak lub dlaczego dziaäa dana metoda.

UWAGA Narzödzia do inĔynierii w obie strony automatycznie generujñ diagramy UML na podstawie analizy kodu Ēródäowego. Ja wolö rysowaè schematy röcznie na tablicy. Celem jest nie tylko utworzenie diagramu, ale teĔ zrozumienie projektu. Utworzenie schematu röcznie wymaga bardziej starannego zbadania kodu i prowadzi do peäniejszego nauczenia siö i zrozumienia go. 8

Dobrym Ēródäem informacji o UML jest ksiñĔka Fowlera i Scotta [Fowler i Scott].

362 ROZDZ AĤ 9

WYTWARZAN E

Aby zilustrowaè omawiane podejĈcie, przedstawiö wszystkie kroki prostej refaktoryzacji z przykäadu stosowania TDD (przykäad ten opisany jest w podrozdziale „Wytwarzanie sterowane testami” we wczeĈniejszej czöĈci rozdziaäu). Warto zwróciè uwagö na to, jak maäe sñ poszczególne etapy. Praca w niewielkich krokach pozwala zachowaè kontrolö nad kodem, zapobiega powstawaniu poczucia niepewnoĈci i umoĔliwia bardzo szybkie osiñganie postöpów.

UWAGA Przedstawiony przykäad jest bardzo prosty, jednak naleĔy pamiötaè o gäównej idei, czyli wprowadzaniu zmian w serii maäych, kontrolowanych kroków. Bardziej rozbudowane przykäady zawierajñ pozycje wymienione w punkcie „Dalsza lektura” w koþcowej czöĈci tego podrozdziaäu.

Celem wspomnianego przykäadu byäo utworzenie parsera äaþcuchów znaków zapytaþ HTTP. W tym momencie miaäem juĔ dziaäajñcy, bardzo prosty parser (zobacz punkt „Przykäad zastosowania TDD” we wczeĈniejszej czöĈci rozdziaäu). Testy wyglñdaäy nastöpujñco: public class QueryStringTest extends TestCase { public void testOneNameValuePair() { QueryString query = new QueryString("name=value"); assertEquals(1, query.count()); assertEquals("value", query.valueFor("name")); } public void testMultipleNameValuePairs() { QueryString query = new QueryString("name1=value1&name2=value2&name3=value3"); assertEquals(3, query.count()); assertEquals("value1", query.valueFor("name1")); assertEquals("value2", query.valueFor("name2")); assertEquals("value3", query.valueFor("name3")); } public void testNoNameValuePairs() { QueryString query = new QueryString(""); assertEquals(0, query.count()); } public void testNull() { try { QueryString query = new QueryString(null); fail("Nalešy zgĪosið wyjîtek"); } catch (NullPointerException e) { // Oczekiwane } } }

PoniĔszy kod dziaäaä (przeszedä wszystkie testy), ale byä nieelegancki. W metodach count() i valueFor() znajdowaäy siö powtórzenia kodu obsäugujñcego przetwarzanie. Chciaäem wyeliminowaè ten problem i umieĈciè ten kod w jednym miejscu. public class QueryString { private String _query; public QueryString(String queryString) { if (queryString == null) throw new NullPointerException(); _query = queryString; }

364 ROZDZ AĤ 9

WYTWARZAN E

public int count() { if ("".equals(_query)) return 0; String[] pairs = _query.split("&"); return pair.lenght; } public String valueFor(String name) { String[] pairs = _query.split("&"); for (String pair : pairs) { String[] nameAndValue = pair.split("="); if (nameAndValue[0].equals(name)) return nameAndValue[1]; } throw new RuntimeException(name + " nie znaleziono"); } }

Aby wyeliminowaè powtórzenia, potrzebowaäem jednej metody do obsäugi przetwarzania. Pozostaäe metody powinny korzystaè z efektów przetwarzania, zamiast samodzielnie wykonywaè tö operacjö. Zdecydowaäem, Ĕe ten parser, wywoäywany z poziomu konstruktora, bödzie umieszczaä dane w strukturze HashMap. Choè mogäem wykonaè jeden duĔy krok, przenoszñc ciaäo metody valueFor() do metody parseQueryString(), a nastöpnie wprowadzaè zmiany do momentu zakoþczenia testów powodzeniem, z wäasnego doĈwiadczenia wiedziaäem, Ĕe praca w maäych krokach jest szybsza. Pierwszy krok polegaä na wywoäaniu metody HashMap() w metodzie valueFor(). Dziöki temu metoda valueFor() miaäa wyglñdaè dokäadnie tak, jak potrzebna mi metoda parseQueryString(). Po wykonaniu tego kroku mogäem äatwo wyodröbniè metodö parseQueryString(). public String valueFor(String name) { HashMap map = new HashMap(); String[] pairs = _query.split("&"); for (String pair : pairs) { String[] nameAndValue = pair.split("="); map.put(nameAndValue[0], nameAndValue[1]); } return map.get(name); }

Po wprowadzeniu tej refaktoryzacji uruchomiäem testy. Zakoþczyäy siö one powodzeniem.

UWAGA Usuwajñc wyjñtek RuntimeException, zmieniäem dziaäanie kodu w sytuacji, kiedy nie moĔna znaleĒè danej nazwy. Nie byäo to bäödem, poniewaĔ wyjñtek RuntimeException peäniä tylko funkcjö asercji dotyczñcej niezaimplementowanego mechanizmu. Nie napisaäem jeszcze testów zwiñzanych z tym wyjñtkiem. Gdybym je przygotowaä, przy zmianie kodu musiaäbym zachowaè wczeĈniejsze dziaäanie.

Teraz mogäem przenieĈè logikö przetwarzania do odröbnej metody. UĔyäem do tego refaktoryzacji Extract Method (czyli „wyodröbnij metodö”) wbudowanej w uĔywane przeze mnie Ĉrodowisko IDE. public String valueFor(String name) { HashMap map = parseQueryString(); return map.get(name); }

REFAKTORYZACJA 365

private HashMap parseQueryString() { HashMap map = new HashMap();

}

String[] pairs = _query.split("&"); for (String pair : pairs) { String[] nameAndValue = pair.split("="); map.put(nameAndValue[0], nameAndValue[1]); } return map;

OczywiĈcie i tym razem testy zakoþczyäy siö powodzeniem. Przy tak maäych zmianach byäbym zaskoczony, gdyby tak siö nie staäo. To wäaĈnie jest istota tej techniki: dziöki maäym krokom programista moĔe zachowaè peänñ kontrolö nad zmianami, co zmniejsza liczbö niespodzianek. Utworzyäem metodö parseQueryString(), jednak byäa ona dostöpna tylko dla metody valueFor(). Nastöpny krok polegaä na udostöpnieniu tej pierwszej metody wszystkim, które jej potrzebujñ. W tym celu utworzyäem zmiennñ egzemplarza _map i uĔyäem jej w metodzie parseQueryString(). public class QueryString { private String _query; private HashMap _map = new HashMap(); ... public String valueFor(String name) { HashMap map = parseQueryString(); return map.get(name); }

}

private HashMap parseQueryString() { String[] pairs = _query.split(„&”); for (String pair : pairs) { String[] nameAndValue = pair.split(„=”); _map.put(nameAndValue[0], nameAndValue[1]); } return _map; }

Jest to bardziej skomplikowana refaktoryzacja, niĔ moĔe siö wydawaè. Za kaĔdym razem, kiedy programista przeksztaäca zmiennñ lokalnñ na zmiennñ egzemplarza, moĔe pomyliè kolejnoĈè operacji. Dlatego uznaäem, Ĕe metoda parseQueryString() nadal bödzie zwracaè zmiennñ _map, choè jest ona dostöpna jako zmienna egzemplarza. Chciaäem upewniè siö, Ĕe ten pierwszy krok pozwala przejĈè testy. Dopiero potem chciaäem przejĈè do nastöpnego etapu, który polegaä na pozbyciu siö zbödnej instrukcji return. public class QueryString { private String _query; private HashMap _map = new HashMap(); ... public String valueFor(String name) { parseQueryString(); return _map.get(name); } private void parseQueryString() { String[] pairs = _query.split("&"); for (String pair : pairs) {

366 ROZDZ AĤ 9

WYTWARZAN E

String[] nameAndValue = pair.split("="); _map.put(nameAndValue[0], nameAndValue[1]); } } }

Testy ponownie zakoþczyäy siö powodzeniem. PoniewaĔ w tym momencie metoda parserQueryString() byäa juĔ caäkowicie samodzielna, jej jedyny zwiñzek z metodñ valueFor() polegaä na tym, Ĕe trzeba jñ byäo wywoäywaè przed instrukcjñ return metody valueFor(). Wreszcie mogäem osiñgnñè swój cel i wywoäywaè metodö parseQueryString() z poziomu konstruktora. public class QueryString { private String _query; private HashMap _map = new HashMap(); public QueryString(String queryString) { if (queryString == null) throw new NullPointerException(); _query = queryString; parseQueryString(); } ... public String valueFor(String name) { return _map.get(name); } ... }

Wyglñdaäo to na prostñ refaktoryzacjö. W koþcu przeniosäem tylko jeden wiersz kodu. Jednak kiedy uruchomiäem testy, zakoþczyäy siö niepowodzeniem. Metoda obsäugujñca przetwarzanie nie dziaäaäa dla pustych äaþcuchów znaków. Byä to przypadek bäödnego uĔycia, którego obsäugi nie dodaäem jeszcze do metody valueFor(). Nie byäo to problemem, kiedy metodö parseQueryString() wywoäywaäa tylko metoda valueFor(), jednak usterka ta ujawniäa siö przy wywoäywaniu metody parseQueryString() w konstruktorze.

UWAGA To pokazuje, dlaczego praca w maäych krokach to tak dobry pomysä. PoniewaĔ zmieniäem tylko jeden wiersz kodu, dobrze wiedziaäem, gdzie popeäniäem bäñd.

ãatwo byäo rozwiñzaè ten problem, dodajñc warunek zabezpieczajñcy. private void parseQueryString(String query) { if ("".equals(query)) return; String[] pairs = query.split("&"); for (String pair : pairs) { String[] nameAndValue = pair.split("="); _map.put(nameAndValue[0], nameAndValue[1]); } }

W tym momencie rozwiñzanie byäo prawie gotowe. Przyczynñ nieporzñdku byä powtarzajñcy siö kod do obsäugi przetwarzania z metody count(), a teraz mogäem dokonaè jego refaktoryzacji, aby metoda uĔywaäa zmiennej _map, zamiast samodzielnie przetwarzaè dane. Zmodyfikowaäem kod z:

REFAKTORYZACJA 367

Dalsza lektura Artykuä Clean Code: Args — A Command-line Argument Parser [Martin 2005] to prawdziwy rarytas, zawierajñcy szczegóäowe omówienie rozbudowanej refaktoryzacji. JeĈli komuĈ spodobaä siö przedstawiony przeze mnie przykäad opisujñcy refaktoryzacjö, powinien zapoznaè siö z tñ pracñ. Artykuä dostöpny jest pod adresem http://www.objectmentor.com/resources/articles/ ´Clean_Code_Args.pdf. KsiñĔka Refactoring: Improving the Design of Existing Code [Fowler 1999] to podstawowe Ēródäo wiedzy na temat refaktoryzacji. Jest to takĔe ciekawa lektura. Warto kupiè tö ksiñĔkö. Autor ksiñĔki Refactoring to Patterns [Kerievsky] rozwija prace Fowlera i pokazuje, jak äñczyè refaktoryzacje w celu wprowadzenia istotnych zmian w projekcie. To dobry sposób na nauczenie siö uĔywania pojedynczych refaktoryzacji do uzyskiwania znaczñcych efektów. KsiñĔka Refactoring Databases: Evolutionary Database Design [Ambler i Sadalage] opisuje, jak refaktoryzowaè schematy baz danych.

REFAKTORYZACJA

371

Prosty projekt Tworzymy projekty, które äatwo modyfikowaè i konserwowaè.

Odb orcy P og amiļci

Perfekcjö osiñgamy nie wtedy, kiedy nie moĔna juĔ niczego dodaè, ale wtedy, kiedy nie moĔna niczego usunñè. — Antoine de Saint-Exupéry, autor ksiñĔki Maäy ksiñĔö KaĔdy bystry gäupiec moĔe sprawiè, Ĕe rzeczy bödñ wiöksze, bardziej zäoĔone i potöĔniejsze. Dziaäanie w przeciwnym kierunku wymaga odrobiny geniuszu i wielkiej odwagi. — Albert Einstein W czasie pisania kodu programiĈci uĔywajñcy zwinnego podejĈcie czösto zatrzymujñ siö i zastanawiajñ: „Jakie jest najprostsze rozwiñzanie?”. Czasem wydajñ siö ogarniöci obsesjñ na punkcie prostoty. Zamiast przewidywaè zmiany i zapewniaè miejsca umoĔliwiajñce rozszerzanie oraz punkty wspóädziaäania z wtyczkami, tworzñ prosty projekt, który jest w jak najmniejszym stopniu zwiñzany z przyszäymi wymaganiami i jak najbardziej przejrzysty. Wbrew intuicji prowadzi to do projektu, który jest przystosowany do wszelkich zmian, przewidzianych bñdĒ nie. MoĔe siö to wydawaè nierozsñdne. Jak projekt moĔe byè przystosowany do wszelkich zmian? Czy zadaniem dobrego projektanta lub programisty nie jest przewidywanie przyszäych zmian i rozwijanie projektu pod ich kñtem? Czy autor ksiñĔki Design Patterns: Elements of Reusable Software nie pisze, Ĕe kluczem do maksymalizacji powtórnego wykorzystania kodu jest przewidywanie zmian i uwzglödnianie ich w projekcie? Pozwolö odpowiedzieè na te pytania Erikowi Gammie, wspóäautorowi ksiñĔki Design Patterns. PoniĔszy fragment to czöĈè wywiadu z Gammñ przeprowadzonego przez Billa Vennersa10. Venners: W ksiñĔce Bandy Czworga [Design Patterns] piszesz: „Klucz do maksymalizacji powtórnego wykorzystania kodu to przewidywanie nowych wymagaþ i ich zmian oraz projektowanie systemów tak, aby mogäy ewoluowaè w odpowiedzi na te modyfikacje. Aby zaprojektowaè system, który jest przystosowany do takich zmian, trzeba zastanowiè siö, jakich modyfikacji moĔe wymagaè w cyklu Ĕycia. Nieuwzglödnienie zmian w projekcie grozi koniecznoĈciñ powaĔnych modyfikacji projektu w przyszäoĈci”. Zdaje siö to staè w sprzecznoĈci z filozofiñ XP. Gamma: Jest to caäkowicie sprzeczne z XP. Przytoczony fragment oznacza, Ĕe trzeba wybiegaè myĈlñ naprzód i spekulowaè. Trzeba spekulowaè na temat elastycznoĈci. Ja takĔe dojrzaäem, a podejĈcie XP przypomina nam, Ĕe spekulowanie w obszarze elastycznoĈci jest kosztowne, dlatego obecnie prawdopodobnie nie napisaäbym tego w dokäadnie taki sposób. Aby zwiökszyè elastycznoĈè, trzeba móc usprawiedliwiè to na podstawie wymagaþ. JeĈli te wymagania nie sñ gotowe, nie dodaäbym z góry do systemu mechanizmów zapewniajñcych takñ elastycznoĈè. Jednak nie uwaĔam, Ĕe XP i wzorce [projektowe] sñ ze sobñ sprzeczne. WaĔne jest, jak programista uĔywa wzorców. UĔytkownicy XP korzystajñ z nich, ale refaktoryzujñ rozwiñzanie pod ich kñtem dopiero wtedy, kiedy potrzebujñ wykorzystaè elastycznoĈè. Z kolei my stwierdziliĈmy w ksiñĔce dziesiöè lat temu, Ĕe nie trzeba tak postöpowaè, 10

Erich Gamma on Flexibility and Reuse: A Conversation with Eric Gamma, Part II, http://www.atrima.com/ ´lejava/articles/reuse.html.

372 ROZDZ AĤ 9

WYTWARZAN E

Ĕe moĔna przewidywaè zmiany. Programista moĔe rozpoczñè tworzenie projektu i uĔywaè wzorców od poczñtku. MoĔe uĔywaè wzorców w rozwijanym z góry projekcie, podczas gdy uĔytkownicy XP tego nie robiñ. Venners: W takim razie co uĔytkownicy XP robiñ na poczñtku, jeĈli nie stosujñ wzorców? Od razu piszñ kod? Gamma: Najpierw piszñ testy. Venners: Tak, najpierw piszñ kod testów. A nastöpnie po prostu piszñ kod, aby przeszedä przygotowane testy. Wtedy patrzñ na rozwiñzanie, refaktoryzujñ je i wtedy stosujñ wzorce, prawda? Gamma: A takĔe wtedy, kiedy pojawiñ siö nowe wymagania. Naprawdö ceniö elastycznoĈè opartñ na wymaganiach. W taki sposób pracujemy nad Eclipse. Kiedy mamy udostöpniè dodatkowe funkcje interfejsu API, robimy to na Ĕñdanie. Udostöpniamy API stopniowo. Kiedy klienci informujñ nas: „Musiaäem wykorzystaè lub powieliè wszystkie klasy wewnötrzne. Naprawdö nie chcö tego robiè”, kiedy dostrzegamy potrzebö, wtedy stwierdzamy, Ĕe zainwestujemy w udostöpnienie danych funkcji w API i zobowiñzujemy siö do tego. Dlatego myĈlimy o rozwoju w mniejszych etapach i nie chcemy zobowiñzywaè siö do udostöpniania fragmentów API, jeĈli nie sñ potrzebne.

BECK O PROSTOCIE W p e wszym wydan u ks éŜk Extreme Programming Explained Kent Beck op saĥ proste projekty jako kod, który przechodz testy jest zgodny z czterema wytycznym , p zy czym kaŜdy nastýpny punkt jest mn ej stotny od wczeļn ejszych e czte y wytyczne to 1 System (kod testy) mus p zekazywaë wszystko, co program sta chce p zekazaë 2 System n e moŜe zaw eraë powtórzeħ w kodz e (Wytyczne 1 2 skĥadajé s ý na reguĥý „Raz ty ko raz”) 3 L czba k as w system e mus byë jak najmn ejsza 4 L czba metod w system e mus byë jak najmn ejsza W drug m wydan u Beck zm en ĥ formý wskazówek 1 Dostosowany do odbiorców. N e jest waŜne, jak wspan aĥy e eganck jest dany fragment projektu Jeļ osoby, które muszé nad n m pracowaë, n e rozum ejé go, n e jest d a n ch prosty 2 Komunikatywny. KaŜda dea, któré autor chce przekazaë, mus byë reprezentowana w system e Podobn e jak sĥowa w sĥown ku, tak e ementy systemu sé nformacjé d a przyszĥych czyte n ków 3 Uporzédkowany. Powtó zen a w og ce ub strukturze utrudn ajé zrozum en e kodu jego modyf kowan e 4 Minimalny. System pow n en m eë jak najmn ej e ementów przy uwzg ýdn en u t zech wczeļn ejszych ogran czeħ Prowadz to do mn ejszej czby czýļc do przetestowan a, udokumentowan a op san a

Prosty to nie to samo co uproszczony. Nie naleĔy podejmowaè pochopnych decyzji projektowych w celu zmniejszenia liczby klas i metod. Prosty projekt jest przejrzysty i elegancki. Nie jest to zlepek funkcji poäñczonych jak najmniejszym nakäadem siä. PoniĔej opisane sñ zagadnienia, Prosty, a nie uproszczony. o których warto pamiötaè, dñĔñc do prostoty.

PROSTY PROJEKT 373

Izolowanie niezaleŜnych komponentów Wywoäania niezaleĔnych komponentów to ukryte Ēródäo powtórzeþ. JeĈli te wywoäania sñ rozproszone w kodzie, zastñpienie lub rozbudowanie danego komponentu moĔe byè trudne. JeĈli programista stwierdzi, Ĕe dany komponent nie wystarcza do realizacji potrzeb, pojawiñ siö problemy. Aby temu zapobiec, naleĔy odizolowaè niezaleĔne komponenty i ukryè je za kontrolowanym przez programistö interfejsem. NaleĔy zastanowiè siö: „Kiedy bödzie potrzebna aktualizacja lub zmiana tego komponentu, jak trudno bödzie to zrobiè?”. W jözykach obiektowych moĔna uĔyè wzorca adaptera [Gamma i inni], zamiast bezpoĈrednio tworzyè egzemplarze niezaleĔnych klas. W platformach, których klasy trzeba rozszerzaè, moĔna utworzyè wäasne klasy bazowe oparte na klasach platformy, zamiast bezpoĈrednio rozszerzaè te ostatnie.

UWAGA Izolowanie niezaleĔnych komponentów umoĔliwia ponadto rozbudowö ich funkcjonalnoĈci i zapewnia wygodny interfejs do pisania testów, jeĈli bödñ potrzebne.

Adaptery naleĔy rozwijaè stopniowo. Zamiast obsäugiwaè w nich wszystkie funkcje komponentu, naleĔy uwzglödniè tylko te, które sñ potrzebne w danym momencie. Interfejs adaptera powinien odpowiadaè potrzebom programisty, a nie interfejsowi komponentu. Uäatwia to uĔywanie komponentu i zastñpienie go w momencie, kiedy bödzie to potrzebne. Izolowanie niezaleĔnych komponentów zmniejsza liczbö powtórzeþ w kodzie kosztem niewielkiego wzrostu zäoĔonoĈci. Niektóre komponenty, na przykäad w J2SE jözyka Java lub platformie .NET, sñ tak powszechnie stosowane, Ĕe izolowanie ich jest czösto nieuzasadnione. Przy podejmowaniu decyzji o izolowaniu czösto uĔywanych komponentów naleĔy zastanowiè siö, czy konieczne bödzie ich zastñpienie lub rozbudowanie. Na przykäad klasy String jözyka Java lub platformy .NET moĔna uĔywaè bezpoĈrednio, bez adaptera, jednak warto zastanowiè siö nad odizolowaniem bibliotek kryptograficznych platformy .NET lub elementów platformy J2EE.

Ograniczanie liczby interfejsów udostýpnianych Interfejsy udostöpniane utrudniajñ wprowadzanie zmian. Kiedy interfejs publiczny klasy lub innego moduäu jest udostöpniony i mogñ uĔywaè go osoby spoza zespoäu, wprowadzenie zmian wymaga wysokich nakäadów i duĔego wysiäku. PoniewaĔ inni programiĈci korzystajñ z interfejsu, jego zmiana moĔe zniweczyè ich pracö. Niektóre zespoäy tworzñ projekt w taki sposób, jakby kaĔdy interfejs publiczny byä zarazem interfejsem udostöpnianym. Taka wewnötrzna publikacja opiera siö na zaäoĔeniu, Ĕe po zdefiniowaniu interfejsu publicznego nigdy nie naleĔy go zmieniaè. Jest to zäe rozwiñzanie, które uniemoĔliwia poprawö projektu w przyszäoĈci. Lepsze podejĈcie polega na wprowadzaniu zmian w nieudostöpnianych interfejsach zawsze, kiedy jest to potrzebne, i aktualizowaniu w odpowiedni sposób jednostek wywoäujñcych. JeĈli kod jest uĔywany przez osoby spoza zespoäu, interfejsy udostöpniane sñ niezbödne. Jednak kaĔdy z nich oznacza zobowiñzanie w obszarze decyzji projektowych, które zespóä moĔe chcieè w przyszäoĈci zmieniè. NaleĔy jak najbardziej ograniczaè liczbö interfejsów

376 ROZDZ AĤ 9

WYTWARZAN E

udostöpnianych osobom spoza zespoäu i zastanowiè siö, czy korzyĈci zwiñzane z uĔywaniem kodu przez inne grupy sñ warte ponoszonych kosztów13. Czasem tak jest, jednak nie naleĔy tego z góry zakäadaè. Warto odraczaè udostöpnianie interfejsów tak däugo, jak to moĔliwe, aby umoĔliwiè usprawnienie i stabilizacjö projektu. Czasem, na przykäad kiedy zespoäy tworzñ biblioteki dla niezaleĔnych uĔytkowników, projekt jest nastawiony wyäñcznie na utworzenie interfejsu udostöpnianego. Wtedy produktem jest interfejs API. Jednak nawet wtedy im mniejszy interfejs, tym lepiej. Znacznie äatwiej dodaè do API nowe elementy, niĔ usunñè lub zmieniè nieprawidäowe. NaleĔy tworzyè tak maäe interfejsy, jak to moĔliwe. Jak stwierdziä Erich Gamma w wywiadzie: „Kiedy mamy udostöpniè dodatkowe funkcje interfejsu API [w Eclipse, Ĉrodowisku IDE o otwartym dostöpie do kodu Ēródäowego dla jözyka Java], robimy to na Ĕñdanie. Udostöpniamy API stopniowo […], kiedy dostrzegamy potrzebö, wtedy stwierdzamy, Ĕe zainwestujemy w udostöpnienie danych funkcji w API i zobowiñzujemy siö do tego. Dlatego myĈlimy o rozwoju w mniejszych etapach i nie chcemy zobowiñzywaè siö do udostöpniania fragmentów API, jeĈli nie sñ potrzebne”.

UWAGA Przy tworzeniu biblioteki moĔna rozwijaè interfejs stopniowo, a koþczyè prace nad nim dopiero po jej udostöpnieniu. Jednak zwykle warto uwzglödniè przyszäe zmiany i zastanowiè siö, czy któreĈ elementy udostöpnianego API nie utrudniñ ich wprowadzania.

Szybkie zgĥaszanie bĥýdów Jedna z trudnoĈci w tworzeniu prostego projektu polega na tym, Ĕe projekt czösto jest niekompletny. Niektóre elementy nie dziaäajñ, poniewaĔ wczeĈniej nie byäy potrzebne. Aby te luki nie doprowadziäy do problemów, trzeba rozwijaè kod, który szybko zgäasza bäödy. NaleĔy uĔywaè asercji do sygnalizowania ograniczeþ projektu. JeĈli programista spróbuje uĔyè niezaimplementowanego elementu, asercja sprawi, Ĕe kod nie przejdzie testów.

UWAGA JeĈli programista napisze wäasne asercje, zamiast korzystaè z wbudowanych mechanizmów jözyka, kod moĔe przekazywaè dodatkowe informacje. Ja czösto tworzö klasö o nazwie Assert (jeĈli nie moĔna uĔyè tej nazwy, dobre synonimy to Assume i Require) i implementujö metody statyczne, na przykäad notNull(object), unreachableCode() i impossibleException(exception).

13

Brooks oszacowaä, Ĕe udostöpnianie kodu do wielokrotnego wykorzystania przez zewnötrznych programistów prowadzi do trzykrotnego wzrostu kosztów [Brooks]. Te szacunki prawdopodobnie nie dotyczñ wspóäczesnych metod rozwoju, jednak tworzenie komponentów do wielokrotnego uĔytku wiñĔe siö z wysokimi kosztami. „Obiektowe” nie oznacza „automatycznie nadajñce siö do wielokrotnego uĔytku”, choè poczñtkowo zwolennicy tego podejĈcia twierdzili inaczej.

PROSTY PROJEKT

377

Inne moŜliwoļci Do niedawna przyjöte rozwiñzanie w obszarze projektowania byäo zgodne z radñ, której Erich Gamma obecnie siö wyrzeka: „Klucz do maksymalizacji powtórnego wykorzystania kodu to przewidywanie nowych wymagaþ i zmian w nich oraz projektowanie systemów tak, aby mogäy ewoluowaè w odpowiedzi na te modyfikacje”. Zespóä moĔe odnieĈè sukces, stosujñc to podejĈcie, jednak zaleĔy to od tego, jak dobrze przewiduje nowe wymagania. JeĈli oczekiwania zespoäu okaĔñ siö zanadto oddalone od rzeczywistoĈci, moĔe zajĈè potrzeba przepisywania duĔych iloĈci kodu opartego na bäödnych zaäoĔeniach. Niektóre zmiany mogñ mieè wpäyw na tak znaczne fragmenty rozwiñzania, Ĕe ich wprowadzenie bödzie niemoĔliwe. JeĈli zespóä stosuje to podejĈcie, powinien zatrudniè projektantów z duĔym doĈwiadczeniem w danej branĔy. Takie osoby czöĈciej potrafiñ prawidäowo przewidywaè zmiany.

Dalsza lektura Na stronie http://www.martinfowler.com/articles.html#IDAOPDBC znajduje siö zbiór doskonaäych artykuäów Martina Fowlera opublikowanych w magazynie IEEE Design. Wiele z nich dotyczy podstawowych zagadnieþ, które pomagajñ w tworzeniu prostego projektu. KsiñĔka The Pragmatic Programmer: From Journeyman to Master [Hunt i Thomas] zawiera bogate informacje o projektowaniu, które pomogñ w tworzeniu prostych, elastycznych projektów. Praca Practices of an Agile Developer [Subramaniam i Hunt] to „duchowy nastöpca” powyĔszej ksiñĔki i przedstawia podobnie treĈciwe wskazówki, choè autorzy poäoĔyli w niej mniejszy nacisk na projektowanie i pisanie kodu. TakĔe ksiñĔka Prefactoring [Pugh] zawiera ciekawe porady dotyczñce tworzenia prostych, elastycznych projektów. Artykuä Fail Fast [Shore 2004b] zawiera szczegóäowe omówienie szybkiego zgäaszania bäödów. MoĔna go pobraè pod adresem http://www.martinfowler.com/ieeeSoftware/failFast.pdf.

PROSTY PROJEKT 379

Rysunek 9.3. UĔywanie ryzyka do sterowania refaktoryzacjñ

NaleĔy ograniczyè prace do usprawniania istniejñcego projektu. Nie naleĔy zapewniaè obsäugi specyficznych formatów, dopóki klienci o to nie poproszñ. Po wyeliminowaniu powtórzeþ z obszaru pojöcia — na przykäad kiedy w caäym systemie jest tylko jedna metoda, która wyĈwietla liczby jako äaþcuchy znaków — zmiana jej implementacji bödzie w przyszäoĈci równie prosta jak obecnie.

UWAGA Zespóä, w którym kiedyĈ pracowaäem, zastñpiä caäñ bibliotekö do obsäugi puli poäñczeþ z bazñ danych w póä roboczodnia pary programistów. Choè nie przewidywaliĈmy tej potrzeby, wprowadzenie zmian byäo proste, poniewaĔ wczeĈniej usunöliĈmy wszelkie powtórzenia zwiñzane z zarzñdzaniem poäñczeniami z bazñ danych. W caäym systemie byäa tylko jedna metoda, która tworzyäa, otwieraäa i zamykaäa poäñczenia, dziöki czemu napisanie wäasnego menedĔera do zarzñdzania pulñ poäñczeþ byäo niemal banalnie proste15.

UśYWANIE OPOWIEĻCI DO ZMNIEJSZANIA RYZYKA nny doskonaĥy sposób na zmn ejszen e ryzyka techn cznego po ega na poproszen u k entów o zap anowan e opow eļc , które umoŜ w é pracý nad ryzykownym obszarem Na przykĥad, aby uwzg ýdn ë yzyko zw ézane z oka zacjé czb, moŜna utworzyë opow eļë „Loka zacja ap kacj d a H szpan ” ( ub dowo nego nnego europejsk ego kraju) aka opow eļë ma wartoļë d a k enta, a jednoczeļn e dotyczy yzyka zw ézanego z nternacjona zacjé Jednak to k enc majé ostateczne sĥowo p zy usta an u pr orytetów opow eļc , a ch ocena ryzyka wartoļc moŜe byë odm enna od op n program stów N e na eŜy s ý tym martw ë akŜe wtedy zespóĥ moŜe zrefakto yzowaë kod pod kétem zmn ejszen a ryzyka

15

MusieliĈmy zapewniè bezpieczeþstwo rozwiñzania ze wzglödu na wñtki, dlatego nie byäo to caäkowicie banalne.

386 ROZDZ AĤ 9

WYTWARZAN E

Inne moŜliwoļci JeĈli zespoäowi nie odpowiada stopniowy rozwój projektu charakterystyczny dla XP, moĔe zabezpieczyè siö, äñczñc to podejĈcie z tworzeniem projektu z góry. NaleĔy rozpoczñè od wstöpnego etapu tworzenia projektu, a nastöpnie przejĈè caäkowicie na rozwój stopniowy w stylu XP. Choè opóĒnia to pierwszñ iteracjö (i moĔe wymagaè teĔ wstöpnej pracy nad wymaganiami), zaletñ tej metody jest moĔliwoĈè dodania zabezpieczenia bez ponoszenia istotnego ryzyka.

UWAGA OdwaĔne zespoäy mogñ od razu uĔyè iteracyjnego rozwoju projektu w stylu XP i zrezygnowaè z zabezpieczeþ. Stopniowy rozwój projektu daje wiele moĔliwoĈci, jest efektywny i oszczödny. Dodatkowe nakäady zwiñzane ze wstöpnym etapem projektowania nie sñ konieczne.

Sñ teĔ inne moĔliwoĈci, jednak moim zdaniem nie wspóädziaäajñ one dobrze z XP. Jedna z nich to inna odmiana stopniowego rozwoju projektu, która bardziej przypomina przygotowywanie projektu z góry. To podejĈcie opiera siö na wykonywaniu projektu z góry na poczñtku kaĔdej iteracji. Prosty projekt i refaktoryzacje sñ wtedy nieco mniej istotne niĔ w XP. Nie próbowaäem uĔywaè w XP innych podejĈè do stopniowego rozwoju projektu, poniewaĔ nie wspóädziaäajñ dobrze z krótkimi iteracjami, charakterystycznymi dla tej metody. Sesje poĈwiöcone projektowaniu sñ czösto zbyt krótkie i ograniczone, aby moĔna byäo utworzyè spójnñ architekturö. Bez specyficznej dla XP koncentracji na prostym projekcie i bezwzglödnej refaktoryzacji takie rozwiñzanie moĔe nie doprowadziè od wyewoluowania spójnego projektu. Inna moĔliwoĈè to zaprojektowanie wszystkich elementów z góry. To podejĈcie moĔe byè skuteczne w Ĉrodowisku, w którym zmiany wymagaþ sñ bardzo rzadkie (lub przy zatrudnieniu przewidujñcego projektanta), jednak prawdopodobnie zawiedzie przy planach przystosowawczych i warstwowych horyzontach planowania uĔywanych w XP (zobacz podrozdziaä „Planowanie wydania” w rozdziale 8.).

Dalsza lektura Artykuä Is Design Dead? [Fowler 2000], dostöpny w internecie pod adresem http://www.martin ´fowler.com/articles/designDead.html, opisuje projektowanie ewolucyjne z nieco sceptycznej perspektywy. W artykule Continuous Design [Shore 2004a] opisujö moje doĈwiadczenia w rozwiñzywaniu trudnych problemów (na przykäad zwiñzanych z internacjonalizacjñ i zabezpieczeniami) przy uĔyciu stopniowego rozwoju projektu. Tekst ten jest dostöpny pod adresem http://www.martin ´fowler.com/ieeeSoftware/continuousDesign.pdf.

390 ROZDZ AĤ 9

WYTWARZAN E

Rozwiézania punktowe Kiedy potrzebujemy dodatkowych informacji, przeprowadzamy maäe, odizolowane eksperymenty.

Odb orcy P og amiļci

WczeĈniejsze czöĈci ksiñĔki powinny przekonaè Czytelników, Ĕe w XP konkretne dane sñ cenione bardziej niĔ spekulacje. Kiedy programista natrafia na pytanie, nie powinien domyĈlaè siö odpowiedzi, ale przeprowadziè eksperyment. NaleĔy ustaliè, jak uĔyè rzeczywistych danych, aby osiñgnñè postöpy. SäuĔñ do tego rozwiñzania punktowe.

O rozwiézaniach punktowych Rozwiñzanie punktowe zwiñzane jest z badaniami technicznymi. Jest to maäy eksperyment, który ma rozwiaè wñtpliwoĈci. Programista moĔe nie wiedzieè, czy jözyk Java zgäasza wyjñtki przy przepeänieniu arytmetycznym. Krótkie, dziesiöciominutowe rozwiñzanie punktowe pozwala odpowiedzieè na to pytanie. public class ArithmeticOverflowSpike { public static void main(String[] args) { try { int a = Integer.MAX_VALUE + 1; System.out.println("Brak wyjîtku: a = " + a); } catch (Throwable e) { System.out.println("Wyjîtek: " + e); } } } Brak wyjîtku: a = -2147483648

UWAGA

Choè ten przykäad to samodzielny program, maäe rozwiñzania punktowe tego typu moĔna pisaè takĔe w ramach platformy testowej. Choè rozwiñzania punktowe tak naprawdö nie wywoäujñ kodu produkcyjnego, platforma testowa pozwala w wygodny sposób szybko uruchamiaè takie rozwiñzania i otrzymywaè informacje o wynikach.

Przeprowadzanie eksperymentów Rozwiñzania punktowe zwykle najäatwiej tworzyè jako maäe programy lub testy, które demonstrujñ danñ funkcjö. MoĔna przeczytaè caäe mnóstwo ksiñĔek i samouczków, jednak moim zdaniem nic nie pomaga lepiej zrozumieè problemu niĔ napisanie dziaäajñcego kodu. WaĔne jest, aby pracowaè z uwzglödnieniem perspektywy praktycznej, a nie tylko teoretycznej. Jednak napisanie kodu czösto trwa däuĔej niĔ przeczytanie samouczka. NaleĔy ograniczyè ten czas, piszñc maäe, niezaleĔne programy. MoĔna zignorowaè przy tym zäoĔonoĈè nieuniknionñ przy tworzeniu kodu produkcyjnego. Wystarczy skoncentrowaè siö na tym, aby rozwiñzanie dziaäaäo. MoĔna uruchomiè je z wiersza poleceþ lub z poziomu platformy testowej. Dozwolone jest zapisywanie wartoĈci na staäe w kodzie. NaleĔy ignorowaè dane wejĈciowe uĔytkownika,

ROZW èZAN A PUNKTOWE

391

Pytania Przykäadowe rozwiñzanie punktowe, które przedstawiäeĈ, jest straszne! Czy nie wiesz, Ĕe nigdy nie naleĔy przechwytywaè wyjñtków Throwable? To prawda. W kodzie produkcyjnym nigdy nie naleĔy przechwytywaè wyjñtków Throwable, jednak rozwiñzanie punktowe to nie kod produkcyjny. Przy tworzeniu takich rozwiñzaþ moĔna zapomnieè na chwilö o pisaniu dobrego kodu i skoncentrowaè siö na efektach krótkoterminowych. Mimo to przy tworzeniu wiökszych rozwiñzaþ punktowych moĔe siö okazaè, Ĕe niektóre fragmenty kodu sñ zbyt niedbaäe, aby moĔna z nich korzystaè, i wydäuĔajñ pracö programisty. Czy rozwiñzania punktowe powinniĈmy tworzyè w parach? To zaleĔy od zespoäu. PoniewaĔ rozwiñzania punktowe nie sñ kodem produkcyjnym, nawet w zespoäach przestrzegajñcych Ĉcisäych reguä dotyczñcych programowania w parach moĔna rozwijaè je samodzielnie. Bardzo skutecznym sposobem pracy w parach nad rozwiñzaniami punktowymi jest badanie technologii przez jednñ osobö w czasie, kiedy druga pisze kod. Inna moĔliwoĈè to równolegäe opracowywanie róĔnych rozwiñzaþ, przy czym kaĔdy programista sam prowadzi badania i pisze kod, a nastöpnie obaj oceniajñ swe postöpy i dzielñ siö uwagami. Czy naprawdö powinniĈmy usuwaè kod rozwiñzaþ punktowych? JeĈli programista sñdzi, Ĕe w przyszäoĈci nikt nie bödzie korzystaä z danego rozwiñzania, moĔe je usunñè. NaleĔy pamiötaè, Ĕe rozwiñzanie punktowe ma zapewniaè informacje i doĈwiadczenia dotyczñce tego, jak rozwiñzaè problem, a nie prowadziè do utworzenia kodu rozwiñzania. Jak czösto powinniĈmy tworzyè rozwiñzania punktowe? ProgramiĈci powinni rozwijaè je za kaĔdym razem, kiedy nie sñ pewni, czy i jak okreĈlony element technologii bödzie dziaäaä. Co zrobiè, jeĈli rozwiñzanie punktowe pokaĔe, Ĕe problem jest trudniejszy, niĔ oczekiwano? To korzystna sytuacja, poniewaĔ zapewnia dodatkowe informacje. MoĔliwe, Ĕe klient zmieni ocenö wartoĈci danej funkcji lub programiĈci bödñ musieli wymyĈliè inny sposób na osiñgniöcie celu. KiedyĈ klient poprosiä mnie o pewnñ funkcjö. Sñdziäem, Ĕe bödö mógä jñ przygotowaè w okreĈlony sposób, jednak rozwiñzanie punktowe wykazaäo, Ĕe uĔywany standard internetowy uniemoĔliwia poĔñdane dziaäanie. WymyĈliliĈmy wtedy inny projekt implementacji bardziej rozbudowanej funkcji.

Efekty Kiedy programiĈci wyjaĈniajñ wñtpliwoĈci techniczne przy uĔyciu dobrze ukierunkowanych i specyficznych eksperymentów, spödzajñ mniej czasu na domyĈlaniu siö, jak program bödzie dziaäaä. W trakcie programowania w celu uzyskania diagnozy i wyjaĈnieþ naleĔy skoncentrowaè siö na bieĔñcym problemie, a nie na sposobach wspóädziaäania kodu produkcyjnego z eksperymentem.

ROZW èZAN A PUNKTOWE 393

Optymalizacja wydajnoļci Optymalizujemy, kiedy upewnimy siö, Ĕe jest to potrzebne.

Odb orcy P og amiļci teste zy

W organizacji, w której pracowaäem, wystñpiä problem16. KaĔda transakcja przetwarzana przez oprogramowanie miaäa trzysekundowe opóĒnienie. W czasie biznesowych godzin szczytu transakcje nawarstwiaäy siö, a przy niedawnym wzroĈcie sprzedaĔy opóĒnienie dochodziäo do kilku godzin. WzdrygaliĈmy siö na kaĔdy dzwonek telefonu. Nasi klienci byli zirytowani. WiedzieliĈmy, gdzie leĔy przyczyna problemu. Niedawno zmieniliĈmy kod do wstöpnego przetwarzania zamówieþ. Pamiötam, Ĕe zastanawiaäem siö nad umieszczaniem w pamiöci podröcznej poĈrednich wyników kosztownych zapytaþ do bazy danych. Nawet poprosiäem klientów o zaplanowanie opowieĈci dotyczñcej wydajnoĈci. WczeĈniej bardziej istotne byäy inne historie, jednak obecnie wydajnoĈè staäa siö priorytetowa. Pobraäem najnowszy kod i skompilowaäem go. Jak zwykle wszystkie testy zakoþczyäy siö powodzeniem. Carlann zasugerowaäa przygotowanie kompleksowego testu wydajnoĈci w celu zademonstrowania problemu. UtworzyliĈmy test, który skäadaä jednoczeĈnie 100 zamówieþ, a nastöpnie uruchomiliĈmy go przy uĔyciu programu profilujñcego. Wyniki potwierdziäy me obawy. Transakcje zajmowaäy Ĉrednio 3,2 sekundy, a odchylenie standardowe byäo zbyt maäe, aby miaäo jakikolwiek wpäyw na wyniki. Przez niemal caäy ten czas program wykonywaä jednñ metodö: verify_order_id(). RozpoczöliĈmy analizy od tej metody. Byäem prawie pewien, Ĕe pamiöè podröczna to dobre rozwiñzanie, jednak program profilujñcy wskazaä inne moĔliwoĈci. Metoda pobieraäa przy kaĔdym wywoäaniu listö aktywnych identyfikatorów zamówieþ niezaleĔnie od poprawnoĈci podanego identyfikatora. Carlann zasugerowaäa odrzucanie niepoprawnych w oczywisty sposób identyfikatorów przed sprawdzaniem potencjalnie prawidäowych, dlatego wprowadziäem zmiany i ponownie uruchomiäem testy. Wszystkie zakoþczyäy siö powodzeniem, ale — niestety — nie miaäo to wpäywu na wydajnoĈè. AnulowaliĈmy zmiany. Nastöpnie uzgodniliĈmy implementacjö pamiöci podröcznej. Carlann napisaäa kod naiwnej odmiany tego mechanizmu. Zaczñäem martwiè siö o spójnoĈè pamiöci podröcznej, dlatego dodaäem test sprawdzajñcy, co siö stanie w momencie uaktywnienia zamówienia z tej pamiöci. Test ten zakoþczyä siö niepowodzeniem. Carlann naprawiäa bäñd w kodzie do obsäugi pamiöci podröcznej, a rozwiñzanie przeszäo wszystkie testy.

UWAGA SpójnoĈè pamiöci podröcznej wymaga zmiany danych w pamiöci podröcznej przy modyfikacji danych z uĔywanego magazynu i w drugñ stronö. ãatwo popeäniè tu bäñd.

Niestety, caäa ta praca poszäa na marne. WydajnoĈè okazaäa siö nieco niĔsza niĔ wczeĈniej, a kod do obsäugi pamiöci podröcznej wprowadziä chaos we wczeĈniej eleganckiej metodzie. SiedzieliĈmy w milczeniu przez minutö. Co jeszcze moĔe byè przyczynñ? MoĔe to bäñd procesora? Czy musimy znaleĒè sposób na zrzut kodu JIT, aby uzyskaè diagram potoków wykonania kodu asemblerowego przez 16

Jest to fabularyzowana wersja prawdziwych wydarzeþ.

OPTYMA

ZACJA WYDAJNOĻC

395

procesor? Czy problem leĔy w stronach pamiöci lub wynika z bäödu mechanizmu przywracania nieuĔytków? Statystyki programu profilujñcego byäy jednoznaczne. Naszym zdaniem wszystko zrobiliĈmy poprawnie. Anulowaäem wszelkie zmiany i ponownie uruchomiäem program profilujñcy: 3,2 sekundy na transakcjö. Co pominöliĈmy? W trakcie przerwy obiadowej przedstawiliĈmy z Carlann nasze problemy z wydajnoĈciñ pozostaäym czäonkom zespoäu. „MoĔe ja mógäbym siö temu przyjrzeè?” — zaproponowaä Nate. „MoĔliwe, Ĕe pomoĔe ĈwieĔa para oczu”. WyraziliĈmy z Carlann zgodö, zadowoleni, Ĕe ktoĈ inny zajmie siö tym problemem. UtworzyliĈmy nowe pary i przez resztö dnia pracowaliĈmy nad prostymi zagadnieniami. Nastöpnego ranka, w trakcie krótkiego spotkania roboczego, Janice poinformowaäa nas, Ĕe Nate znalazä rozwiñzanie. Okazaäo siö, Ĕe moje bäödne wstöpne zaäoĔenia uniemoĔliwiäy nam dostrzeĔenie oczywistego problemu. Metoda verify_order_id() zawieraäa metodö wewnötrznñ, której program profilujñcy nie uwzglödniä. Nie zwróciliĈmy na niñ uwagi, poniewaĔ byäem pewien, Ĕe rozumiem kod. Jednak Janice i Nate przeszli przez kod w trybie kroczenia. ZnaleĒli metodö, która przy kaĔdej transakcji próbowaäa nawiñzaè niepotrzebne poäñczenie sieciowe. Naprawienie bäödu pozwoliäo skróciè czas transakcji o peäne trzy sekundy. Janice i Nate rozwiñzali problem w niespeäna póä godziny. A co z pamiöciñ podröcznñ, która moim zdaniem byäa niezbödna? Na razie jej nie potrzebowaliĈmy.

Jak optymalizowaë? Wspóäczesne komputery sñ skomplikowane. Odczyt jednego wiersza z pliku wymaga koordynacji procesora, jñdra, wirtualnego systemu plików, magistrali systemowej, kontrolera dysku twardego, pamiöci podröcznej dysku twardego, buforów systemu operacyjnego, pamiöci systemowej i potoków szeregowania. KaĔdy komponent istnieje w celu rozwiñzania problemu. Z kaĔdym teĔ zwiñzane sñ pewne sztuczki, które umoĔliwiajñ poprawö wydajnoĈci. Czy dane znajdujñ siö w pamiöci podröcznej? W której pamiöci podröcznej? Jaka jest struktura pamiöci? Czy odczyt odbywa siö asynchronicznie, czy blokami? Jest tak wiele zmiennych czynników, Ĕe przewidzenie ogólnej wydajnoĈci pojedynczych metod jest niemal niemoĔliwe. Czasy, kiedy programiĈci mogli dokäadnie oszacowaè wydajnoĈè, liczñc instrukcje w cyklach Czasy, w których programiĈci zegara, dawno odeszäy w przeszäoĈè, jednak mimo mogli przewidzieè wydajnoĈè to niektórzy wciñĔ oceniajñ wydajnoĈè przy uĔyciu na podstawie liczby instrukcji, uproszczonego, prymitywnego podejĈcia. Próbujñ oni dawno odeszäy w przeszäoĈè. odgadnñè wydajnoĈè na podstawie 20-wierszowych programów testowych, nie zachowujñ starannoĈci w trakcie pisania kodu po raz pierwszy, zostawiajñ nieporzñdek w prawdziwym programie, a nastöpnie robiñ sobie däugñ przerwö obiadowñ. Czasem to podejĈcie dziaäa. CzöĈciej jednak prowadzi do komplikacji i baäaganu, co nie wpäywa korzystnie na ogólnñ wydajnoĈè. Czasem moĔe nawet doprowadziè do wolniejszego dziaäania kodu.

396 ROZDZ AĤ 9

WYTWARZAN E

OczywiĈcie, klienci nie zawsze majñ ĈwiadomoĈè, Ĕe potrzebne sñ opowieĈci dotyczñce wydajnoĈci, co jest widoczne zwäaszcza wtedy, kiedy istotne sñ wymagania wysoce techniczne. JeĈli programista obawia siö wystñpienia problemów z wydajnoĈciñ w okreĈlonej czöĈci systemu, powinien przedstawiè uwagi w kategoriach biznesowych zysków i strat oraz ryzyka. Klienci mimo to mogñ nie wyraziè zgody na realizacjö takich opowieĈci. Nie ma w tym nic zäego. W koþcu to klienci sñ ekspertami w dziedzinie wartoĈci i priorytetów biznesowych. To klienci majñ obowiñzek ich okreĈlania i podejmowania decyzji. Z kolei zadaniem programistów jest konserwacja wydajnego Ĉrodowiska programistycznego. JeĈli testy zaczynajñ zanadto siö przedäuĔaè, naleĔy zoptymalizowaè je w celu osiñgniöcia konkretnego celu, na przykäad skrócenia do piöciu lub dziesiöciu minut. Warto pamiötaè, Ĕe najczöstsza przyczyna wolnej kompilacji to zbytni nacisk na testy kompleksowe, a nie wolno dziaäajñcy kod.

TESTERZY I WYDAJNOĻê K edy wspóĥpracujý z peĥnym zaangaŜowan a testeram , czýsto peĥn é on funkcjý badaczy zagadn eħ techn cznych Jednym z ch zadaħ jest wtedy badan e wymagaħ pozafunkcjonalnych na p zykĥad wydajnoļc esterzy pow nn pomagaë k entom w wyraŜen u wymagaħ pozafunkcjona nych, a nastýpn e utwo zyë konserwowaë pak et testów, który ocen a zdo noļë oprogramowan a do rea zacj tych wymagaħ ak e pak ety testów mogé sprawdzaë stab noļë, a takŜe wydajnoļë ska owa noļë

Pisanie opowieļci dotyczécych wydajnoļci OpowieĈci dotyczñce wydajnoĈci, podobnie jak inne historie, wymagajñ konkretnego, wartoĈciowego dla klienta celu. W typowej opowieĈci ten cel jest wyraĔony w poniĔszych kategoriach: PrzepustowoĈè Jak wiele operacji oprogramowanie ma ukoþczyè w danym czasie? OpóĒnienie Jak duĔy odstöp miödzy rozpoczöciem a zakoþczeniem operacji jest dozwolony? SzybkoĈè reagowania Jak duĔe opóĒnienie miödzy rozpoczöciem operacji a uzyskaniem informacji zwrotnych jest dozwolone? Jakie informacje zwrotne sñ potrzebne? Warto pamiötaè, Ĕe opóĒnienie i szybkoĈè reagowania to powiñzane ze sobñ, ale odröbne cechy. Choè niskie opóĒnienie prowadzi do wysokiej szybkoĈci reagowania, czasem oprogramowanie szybko reaguje takĔe przy wysokim opóĒnieniu. W czasie pisania opowieĈci dotyczñcych wydajnoĈci naleĔy uwzglödniè wydajnoĈè akceptowalnñ (czyli minimum niezbödne do osiñgniöcia zadowalajñcych wyników) oraz optymalnñ (czyli poziom, powyĔej którego dalsza optymalizacja nie daje znaczñcych efektów). Do czego säuĔñ dwa poziomy wydajnoĈci? Optymalizacja wydajnoĈci moĔe trwaè nieskoþczenie däugo. Czasem programista szybko dochodzi do „najlepszego” poziomu, co informuje go, Ĕe moĔe przejĈè do nastöpnych zadaþ. W innych sytuacjach trudno osiñgnñè nawet poziom „akceptowalny”. Wtedy programista wie, Ĕe powinien poĈwiöciè na optymalizacjö wiöcej czasu.

398 ROZDZ AĤ 9

WYTWARZAN E

kilka testów, aby ustaliè, czy sñ powody do obaw. JeĈli tak, naleĔy porozmawiaè z klientami o przygotowaniu i zaplanowaniu potrzebnych opowieĈci. Jak napisaè test wydajnoĈci dla scenariuszy, które obejmujñ tysiñce transakcji przeprowadzanych przez wielu klientów? Dostöpne sñ dobre narzödzia do przeprowadzania testów obciñĔenia dla wielu protokoäów sieciowych. Sñ to zarówno proste skrypty powäoki uruchamiajñce sesje telnet i netcat, jak i profesjonalne aplikacje do testów porównawczych. Testerzy i dziaä zarzñdzania jakoĈciñ powinni poleciè konkretne narzödzia. Nasze testy wydajnoĈci trwajñ zbyt däugo. Jak moĔemy zachowaè dziesiöciominutowñ kompilacjö? Dobre testy wydajnoĈci czösto sñ czasochäonne i mogñ doprowadziè do nadmiernego wydäuĔenia siö kompilacji. Jest to jeden z nielicznych scenariuszy, kiedy wskazana jest kompilacja wieloetapowa (omówiona w podrozdziale „Ciñgäa integracja” w rozdziale 7.). Przy integracji naleĔy uruchamiaè testy wydajnoĈci asynchronicznie, odröbnie od standardowej dziesiöciominutowej kompilacji (zobacz podrozdziaä „Dziesiöciominutowa kompilacja” w rozdziale 7.). Nasi klienci nie chcñ tworzyè opowieĈci dotyczñcych wydajnoĈci. Twierdzñ, Ĕe powinniĈmy od samego poczñtku pisaè szybkie oprogramowanie. Co mamy zrobiè? „Szybkie” to abstrakcyjna ocena. Czy majñ na myĈli to, Ĕe opóĒnienie powinno byè niskie? A moĔe przepustowoĈè powinna byè wysoka? Czy przy wzroĈcie aktywnoĈci aplikacja powinna skalowaè siö lepiej niĔ liniowo? Czy jest poziom, na którym wydajnoĈè moĔe przestaè rosnñè, obniĔyè siö lub powaĔnie ucierpieè? Czy szybkoĈè reagowania interfejsu uĔytkownika jest waĔniejsza od szybkoĈci przetwarzania danych na zapleczu? Te cele wymagajñ wyraĔenia w kategoriach iloĈciowych, a ich realizacja wymaga czasu programistów. MoĔna uwzglödniè te zagadnienia w istniejñcych opowieĈciach, jednak umieszczenie ich w odröbnych historiach daje przedstawicielom klientów wiöcej elastycznoĈci w planowaniu i powiökszaniu wartoĈci biznesowej.

Efekty JeĈli programiĈci optymalizujñ kod wtedy, kiedy jest to konieczne, poĈwiöcajñ czas na czynnoĈci, które klienci ocenili jako wartoĈciowe. Poprawa wydajnoĈci jest wyraĔona iloĈciowo, a potrzebne informacje moĔna uchwyciè w trakcie wykonywalnych testów. ProgramiĈci dokonujñ pomiarów, przeprowadzajñ testy i zbierajñ informacje zwrotne, co prowadzi do utworzenia rozwiñzaþ akceptowalnych z uwagi na nakäady pracy i pieniödzy. Kod jest äatwiejszy w konserwacji, a programiĈci bardziej ceniñ kod prosty niĔ wysoce zoptymalizowany.

Przeciwwskazania Oprogramowanie to zäoĔony system oparty na relacjach miödzy wieloma elementami. Przy ocenie wydajnoĈci äatwo popeäniè bäñd.

Przy ocenie wydajnoĈci äatwo o pomyäkö.

Dlatego nie naleĔy optymalizowaè kodu bez konkretnych kryteriów wydajnoĈci i obiektywnych dowodów, na przykäad testów wydajnoĈci, które pokazujñ, Ĕe te kryteria nie sñ jeszcze osiñgniöte. Trzeba usuwaè optymalizacje, które nie wiñĔñ siö z obiektywnñ poprawñ wydajnoĈci. 400 ROZDZ AĤ 9

WYTWARZAN E

NaleĔy zachowaè ostroĔnoĈè przy optymalizowaniu kodu bez testów. Optymalizacja czösto zwiöksza zäoĔonoĈè rozwiñzania i ryzyko wystñpienia usterek.

Inne moŜliwoļci Nie ma dobrej alternatywy dla optymalizacji opartej na pomiarach. Wielu programistów w trakcie pisania dñĔy do optymalizacji caäego kodu, czösto opierajñc optymalizacje na potocznym rozumieniu pojöcia „szybkie”. Czasem ich przekonania opierajñ siö na prostych programach, które wykonujñ dany algorytm 1000 razy. Czösto spotykany przykäad takiego postöpowania to program porównujñcy szybkoĈè dziaäania klasy StringBuffer z äñczeniem äaþcuchów znaków w jözyku Java lub na platformie .NET. Niestety, to podejĈcie do optymalizacji koncentruje siö na prostych sztuczkach algorytmicznych. We wspóäczesnych systemach sieè i opóĒnienie w dziaäaniu dysku twardego to duĔo istotniejsze wñskie gardäa niĔ wydajnoĈè procesora. Dlatego jeĈli komputer komunikuje siö przez sieè lub zapisuje dane na dysku twardym — a przy wiökszoĈci aktualizacji baz danych potrzebne sñ obie te operacje — prawdopodobnie nie jest istotne, jak szybko oprogramowanie äñczy äaþcuchy znaków. Z drugiej strony, niektóre programy sñ zaleĔne od procesora. CzöĈè zapytaþ do baz danych äatwo zapisaè w pamiöci podröcznej, dlatego nie wpäywajñ na wydajnoĈè. Jedyny sposób na upewnienie siö, Ĕe wñskie gardäo nie sprawia problemów, to pomiar wydajnoĈci.

Dalsza lektura Artykuä Yet Another Optimization Article [Fowler 2002b] zawiera omówienie znaczenia optymalizacji opartej na pomiarach. Tekst ten jest dostöpny w internecie pod adresem http://www.martinfowler.com/ieeeSoftware/yetOptimization.pdf.

OPTYMA

ZACJA WYDAJNOĻC

401

UWAGA Sesja eksploracyjna trwa zwykle od godziny do dwóch.

Deklaracja danej sesji testów eksploracyjnych moĔe opieraè siö na wäaĈnie ukoþczonej opowieĈci (na przykäad „Zbadanie obsäugi kuponów rabatowych”). MoĔe teĔ dotyczyè interakcji miödzy zbiorem opowieĈci (na przykäad „Zbadanie interakcji miödzy obsäugñ kuponów rabatowych a ogólnej obniĔki”). MoĔe obejmowaè aspekty jakoĈci, na przykäad stabilnoĈè, niezawodnoĈè i wydajnoĈè („ZnaleĒè dowód na to, Ĕe obsäuga kuponów rabatowych ma wpäyw na wydajnoĈè”). Deklaracje naleĔy tworzyè we wspóäpracy z zespoäem, aby ustaliè, które informacje w najwiökszym stopniu przyczyniñ siö do postöpów w pracach nad projektem. Deklaracje to odpowiedniki opowieĈci w obszarze testów. Podobnie jak historie, najlepiej je zapisaè. Mogñ byè bardzo nieformalne i mieè postaè wiersza tekstu na tablicy lub karteczce, ale zapisana deklaracja to punkt odniesienia, do którego tester moĔe zajrzeè, aby upewniè siö, Ĕe prace postöpujñ w dobrym kierunku.

Narzýdzie numer 2: obserwacja Testy automatyczne sprawdzajñ tylko te funkcje, pod których kñtem programiĈci je napisali, jednak ludzie potrafiñ zauwaĔaè drobne poszlaki, sugerujñce, Ĕe nie wszystko dziaäa prawidäowo. Testerzy w trakcie testów eksploracyjnych nieustannie zwracajñ uwagö na wszelkie niezwykäe wydarzenia. MoĔe to byè modyfikowalne pole formularza, które powinno dziaäaè w trybie tylko do odczytu, dysk twardy dziaäajñcy w momencie, kiedy oprogramowanie nie powinno z niego korzystaè, lub nieoczekiwana wartoĈè w raporcie. Takie obserwacje prowadzñ testerów do dalszych pytaþ, nastöpnych testów i badania nowych kierunków. Na przykäad tester moĔe zauwaĔyè, Ĕe system sieciowy przekazuje parametry w adresach URL. „Aha!” — myĈli tester. „Mogö äatwo zmieniè adres”. Nastöpnie tester zmienia adres http://stage.example.com/edit?id=42 na http://stage.example.com/edit?id=9999999.

Narzýdzie numer 3: notatki W czasie eksplorowania zbyt äatwo zapomnieè o juĔ wykonanych i zaplanowanych zadaniach. Testerzy prowadzñ badania z notatnikiem i co pewien czas zapisujñ wykonywane operacje. Do ich Ĉledzenia moĔna teĔ uĔyè rejestratorów ekranu, na przykäad programu Camtasia. DoĈè irytujñce jest wykrycie bäödu, kiedy nie wiadomo, jakie operacje doprowadziäy oprogramowanie do danej reakcji. Notatki i zapisy informujñ testera nie tylko o operacjach wykonywanych w momencie wystñpienia zaskakujñcego dziaäania, ale takĔe o czynnoĈciach sprzed kilku minut lub godzin. Szczególnie istotne jest zapisywanie informacji o elementach, które wymagajñ dalszych badaþ. JeĈli tester nie moĔe przeprowadziè pewnych testów w trakcie bieĔñcej sesji, powinien pamiötaè o bardziej szczegóäowym zbadaniu danego obszaru w przyszäoĈci. Sñ to zagadnienia do analizy w trakcie póĒniejszych testów eksploracyjnych.

404 ROZDZ AĤ 9

WYTWARZAN E

Narzýdzie numer 4: heurystyki Trzeba pamiötaè o tym, Ĕe testy eksploracyjne obejmujñ jednoczesne projektowanie i wykonywanie testów. Niektóre techniki projektowania testów, na przykäad testowanie graniczne, sñ dobrze znane. JeĈli w programie znajduje siö pole, które ma przyjmowaè wartoĈci z przedziaäu od 0 do 100, tester prawdopodobnie sprawdzi wartoĈci 0 i 100, liczbö ze Ĉrodka przedziaäu, a takĔe nieprawidäowe wartoĈci, na przykäad –1 i 101. Nawet jeĈli tester nigdy nie säyszaä o testach granicznych, prawdopodobnie je przeprowadzi. Heurystyka to wskazówka: technika, która pomaga w badaniach. Testy graniczne to przykäadowa heurystyka testowa. DoĈwiadczeni testerzy uĔywajñ wielu heurystyk, opartych na zrozumieniu dziaäania systemów oprogramowania, a takĔe na doĈwiadczeniu i intuicji w wykrywaniu przyczyn awarii programów. MoĔna ulepszyè testy eksploracyjne, tworzñc i przechowujñc katalog wartych zapamiötania heurystyk badania oprogramowania. OczywiĈcie, ten sam katalog moĔe byè wartoĈciowym Ēródäem wiedzy dla programistów implementujñcych oprogramowanie. Niektóre heurystyki sñ specyficzne dla dziedziny. Na przykäad, jeĈli zespóä rozwija oprogramowanie sieciowe, musi uĔywaè adresów IP. Prawdopodobnie tester zbada, jak program obsäuguje nieprawidäowe adresy IP („999.999.999.999”), specjalne adresy IP („127.0.0.1”) i adresy w stylu IPv6 („::1/128”). Innych heurystyk moĔna uĔywaè w niemal wszystkich projektach. PoniĔej opisujö kilka przykäadowych heurystyk, od których moĔna zaczñè badania.

śadne, kilka, wszystkie Na przykäad, jeĈli uĔytkownikom przyznawane sñ uprawnienia, tester powinien utworzyè uĔytkownika bez uprawnieþ, z kilkoma uprawnieniami i z wszystkimi. W jednym z testowanych przeze mnie systemów program traktowaä uĔytkowników bez uprawnieþ jak administratorów. Nieprzyznanie uĔytkownikowi Ĕadnych uprawnieþ prowadziäo do tego, Ĕe miaä on dostöp do caäego systemu.

Zĥotowĥosa: za duŜe, za maĥe, w sam raz Opisane wczeĈniej testy graniczne pola liczbowego to przykäadowe testy Zäotowäosej. Inny przykäad to przesyäanie na serwer pliku obrazu. Tester powinien spróbowaè przesäaè rysunek o wielkoĈci 3 megabajtów (za duĔy), pusty plik (za maäy) i obraz o odpowiednim rozmiarze (50 kilobajtów).

Pozycja: poczétek, ļrodek, koniec Pozycja moĔe dotyczyè modyfikowalnych kontrolek. Tester powinien zmieniè poczñtek wiersza, jego Ĉrodek i koniec. Ta heurystyka dotyczy teĔ lokalizacji danych w przetwarzanych plikach lub elementów wybieranych z listy i dodawanych do niej.

Liczba: zero, jeden, wiele Tester moĔe utworzyè faktury pozbawione elementów, z jednñ pozycjñ i z wieloma obiektami. MoĔe teĔ wykonaè wyszukiwanie dla zera elementów, jednego obiektu lub wiökszej ich liczby. W licznych systemach pojawia siö drobny bäñd tekstowy zwiñzany z liczbñ mnogñ. Strony wyĈwietlajñ informacjö „Znaleziono 1 elementów” zamiast „Znaleziono 1 element”.

TESTY EKSP ORACYJNE 405

Heurystyka oparta na liczbach dotyczy wielu scenariuszy: liczby zaleĔnych rekordów danych (klient bez adresu, z jednym adresem i wieloma adresami albo grupa bez czäonków, z jednym czäonkiem i z wieloma), liczby zdarzeþ (zero transakcji, jedna transakcja lub wiele równolegäych transakcji) i wszelkich innych sytuacji obejmujñcych obiekty, które moĔna policzyè.

CRUD: tworzenie, odczyt, aktualizacja, usuwanie Dla kaĔdego typu jednostek i kaĔdego pola danych naleĔy spróbowaè utworzyè, odczytaè, zaktualizowaè i usunñè dany element. Nastöpnie tester powinien spróbowaè wykonaè operacje CRUD, naruszajñc przy tym ograniczenia systemowe, na przykäad przekraczajñc uprawnienia. Metody tej moĔna uĔywaè w poäñczeniu z innymi heurystykami, takimi jak Zäotowäosa, Pozycja, Liczba i Wybór. Tester moĔe usunñè ostatni element faktury, a nastöpnie wczytaè go; zaktualizowaè pierwszy element; usunñè klienta majñcego zero faktur, jednñ lub wiele, i tak dalej.

Wstrzykniýcie polecenia JeĈli oprogramowanie przetwarza tekst pochodzñcy z zewnötrznych Ēródeä (na przykäad z interfejsu uĔytkownika lub interfejsu usäugi sieciowej), naleĔy upewniè siö, Ĕe nie interpretuje przychodzñcego tekstu jako polecenia (w jözyku SQL, JavaScript lub polecenia powäoki albo wiersza poleceþ). Na przykäad apostrof w polu tekstowym wywoäuje czasem wyjñtki jözyka SQL. W niektórych aplikacjach wpisanie säowa „tester’s” spowoduje bäñd jözyka SQL.

Ataki zwiézane z typami danych Przy danych wejĈciowych kaĔdego typu naleĔy wypróbowaè wartoĈci, które wykraczajñ poza standardowe granice i naruszajñ wiözy integralnoĈci. Na przykäad w polu z datñ moĔna wpisaè 29 lub 30 lutego albo daty sprzed 100 lat. MoĔna teĔ wpisaè niepoprawnñ godzinö, na przykäad 13:75. W przypadku liczb moĔna podaè bardzo duĔe (4294967297 = 2^32 + 1) i bardzo maäe wartoĈci (0,0000000000000001). Warto wypróbowaè notacjö matematycznñ (1E-16) i wpisaè liczby ujemne, zwäaszcza jeĈli sñ niedozwolone, na przykäad w polu z cenñ. W przypadku äaþcuchów znaków moĔna wpisaè däugie äaþcuchy (ponad 5000 znaków), pozostawiè puste pole lub wpisaè jeden odstöp. Tester powinien wypróbowaè róĔne znaki, wäñcznie z popularnymi ogranicznikami pól (` | / \ ; : & < > ^ * ? Tab). Listö tö moĔna ciñgnñè, ale podane przykäady obrazujñ podstawowñ ideö.

Przykĥad „Ustalmy deklaracjö tej sesji” — powiedziaäa Julia, siadajñc obok Michaäa. Julia byäa jednym z testerów w zespole, a Michaä byä programistñ. „Na czym powinniĈmy siö skoncentrowaè?”. „Znasz nas” — odpowiedziaä Michaä. „W naszym kodzie nie ma Ĕadnych bäödów”. UĈmiechnñä siö, wiedzñc, czego moĔe siö spodziewaè. „Drogo za to zapäacisz” — uĈmiechnöäa siö Julia. „Choè muszö powiedzieè, Ĕe w Ĕadnym zespole, w którym pracowaäam, jakoĈè kodu nie byäa tak wysoka. Ile bäödów znaleĒliĈmy w zeszäym miesiñcu?”. „To byä akurat doĈè ciöĔki miesiñc”. Michaä zaczñä liczyè na palcach. „Wystñpiä problem z instalatorem i z sieciñ”. Michaä przerwaä na chwilö. „Cztery bäödy”.

406 ROZDZ AĤ 9

WYTWARZAN E

„Zobaczmy, jak poradziliĈcie sobie tym razem. Co nowego pojawiäo siö w kodzie?”. „DoĈè standardowe rzeczy” — odpowiedziaä Michaä. „Zupeänñ nowoĈciñ jest obsäuga danych wejĈciowych w wielu jözykach. Jednak nic tu nie znajdziesz — dokäadnie przetestowaliĈmy tö funkcjö”. „Uwielbiam wyzwania” — powiedziaäa Julia z figlarnym uĈmiechem. „Ponadto zagadnienia zwiñzane z systemem kodowania znaków to bogate Ēródäo bäödów. Przyjrzyjmy siö temu”. „Pewnie” — Michaä zapisaä na karteczce punkt „Badanie internacjonalizacji”, a nastöpnie przypiñä jñ do monitora, aby przypominaäa o kierunku eksploracji. Julia jako pierwsza wziöäa klawiaturö. „Zacznijmy od podstaw. PomoĔe to nam ustaliè Ēródäo problemów, jeĈli natrafimy póĒniej na coĈ dziwnego”. W czasie kiedy Julia przechodziäa do ekranu do wpisywania danych, Michaä zapisaä w notatniku datö i godzinö na poczñtku nowej strony i przygotowaä siö do robienia notatek. Julia otworzyäa przeglñdarkö czcionek i wkleiäa äaþcuch przypadkowych niemieckich, hebrajskich, greckich, japoþskich i arabskich znaków. „UĔyjmy heurystyki CRUD, aby upewniè siö, Ĕe te dane moĔna poprawnie zapisaè w bazie danych i pobraè je”. Julia szybko zapisaäa tekst, otworzyäa przeglñdarkö bazy danych, aby upewniè siö, Ĕe znaki sñ w niej obecne, a nastöpnie zamknöäa aplikacjö i ponownie jñ uruchomiäa. Wszystkie dane byäy na miejscu. Julia zmodyfikowaäa äaþcuch znaków, ponownie go zapisaäa i powtórzyäa test, a na zakoþczenie usunöäa wpis. „Wyglñda dobrze”. „Poczekaj” — powiedziaä Michaä. „Mam pomysä. UĔytkownicy nie powinni móc zapisywaè pustych äaþcuchów znaków. Co siö stanie, jeĈli uĔyjemy odstöpu z zestawu Unicode zamiast zwykäego?”. „Zaraz sprawdzö” — Julia wróciäa do pracy. Wszystkie próby zostaäy z powodzeniem udaremnione. „Do tej pory wszystko wyglñda prawidäowo, jednak znam specjalnñ sztuczkö”. Julia uĈmiechnöäa siö, wpisujñc „#FEFF” w przeglñdarce czcionek. „To znak, który oznaczaä kiedyĈ „odstöp o zerowej däugoĈci, który nie powoduje przejĈcia do nastöpnego wiersza”. Obecnie to jedynie znacznik kolejnoĈci bajtów. Jednak jest to najbardziej käopotliwy znak, który mogö przesäaè do procedur obsäugujñcych dane wejĈciowe”. Julia kliknöäa przycisk Zapisz. Nic siö nie staäo. „Punkt dla dobrych chäopców” — mruknöäa Julia. „Kontrolki do wpisywania danych wyglñdajñ solidnie. Z doĈwiadczenia wiem, Ĕe uĔywacie wspólnej bazy dla kontrolek, dlatego jeĈli jedna dziaäa prawidäowo, dotyczy to prawdopodobnie wszystkich”. Michaä potwierdziä, a Julia dodaäa — „MoĔliwe, Ĕe póĒniej sprawdzö jeszcze kilka kontrolek, jednak na razie moĔemy lepiej spoĔytkowaè czas”. „W porzñdku, czym siö teraz zajmiemy?” — zapytaä Michaä. „Przychodzi mi do gäowy kilka pomysäów: porównywanie danych, sortowanie i przeksztaäcanie danych na inny format. Znaki diakrytyczne z zestawu Unicode moĔna zakodowaè na kilka sposobów, dlatego dwa äaþcuchy znaków, które technicznie sñ identyczne, mogñ mieè róĔnñ liczbö bajtów. Sortowanie sprawia problemy, poniewaĔ znaki z zestawu Unicode nie sñ sortowane w takiej samej kolejnoĈci jak w formie binarnej…” „…a przeksztaäcanie danych na inny format jest naraĔone na bäödy z uwagi na róĔne strony kodowe i problemy z systemami kodowania znaków” — dokoþczyä Michaä, a nastöpnie zapisaä w notatniku wszystkie trzy zagadnienia: porównywanie danych, sortowanie i przeksztaäcanie.

TESTY EKSP ORACYJNE 407

(ang. Workshop on Heuristics and Exploratory Techniques), a James Lyndsay prowadzi warsztaty LEWT (ang. London Exploratory Workshop in Testing). Oba te warsztaty to miejsca spotkaþ, w których czasie testerzy dzielñ siö anegdotami i doĈwiadczeniami.

Efekty Kiedy tester stosuje testy eksploracyjne, odkrywa informacje zarówno o oprogramowaniu, jak i o procesie jego rozwoju. Czasem zauwaĔa, Ĕe brakuje scenariuszy testowych, opowieĈè jest niepeäna lub niepoprawnie sformuäowana, a niezbödne rozmowy nie zostaäy przeprowadzone. Wszelkie niespodzianki umoĔliwiajñ usprawnienie oprogramowania i praktyk programistycznych. Zespóä powinien wykorzystaè informacje do ulepszenia procesu i zmniejszenia liczby popeänianych bäödów.

Przeciwwskazania Nie naleĔy uĔywaè testów eksploracyjnych do przeprowadzania testów regresji. Te ostatnie testy powinny byè zautomatyzowane. Testy eksploracyjne naleĔy przeprowadzaè tylko wtedy, kiedy jest duĔe prawdopodobieþstwo, Ĕe doprowadzñ do uzyskania nowych informacji, a zespóä moĔe je wykorzystaè. JeĈli jest juĔ dostöpna lista bäödów w danej opowieĈci, dodatkowe testy eksploracyjne to marnowanie czasu na ponowne wykrywanie znanych problemów. Najpierw naleĔy naprawiè usterki.

Inne moŜliwoļci MoĔna wykorzystaè testy eksploracyjne jako mechanizm do wykrywania bäödów w oprogramowaniu, zwäaszcza odziedziczonym, jeĈli zespóä podejrzewa, Ĕe jest w nim wiele usterek. Jednak nie naleĔy stosowaè tej metody do upewnienia siö, Ĕe wykryto wszelkie bäödy, poniewaĔ nie pozwala ona znaleĒè wszystkich usterek. Niektóre zespoäy stosujñce XP nie wykonujñ Ĕadnych testów röcznych ani kompleksowych. Te grupy uĔywajñ innych mechanizmów (zwykle informacji zwrotnych od uĔytkowników) do upewniania siö, Ĕe nie generujñ bäödów. Jest to dopuszczalne, jeĈli w kodzie zespoäu nie ma usterek, co oczywiĈcie jest moĔliwe, jednak lepiej upewniè siö o tym przed udostöpnieniem oprogramowania uĔytkownikom. Mimo to zespóä moĔe uniknñè negatywnych skutków takiego postöpowania, jeĈli oprogramowanie nie ma kluczowego znaczenia, a uĔytkownicy nie sñ surowi. W innych zespoäach testerzy peäniñ bardziej tradycyjnñ funkcjö i koncentrujñ siö raczej na wykrywaniu usterek niĔ tworzeniu kodu wolnego od bäödów. Wedäug moich doĈwiadczeþ takie grupy tworzñ kod o niĔszej jakoĈci i z wiökszñ liczbñ bäödów. MoĔliwe, Ĕe wynika to z efektu „lepsze testy, niĔsza jakoĈè”.

Dalsza lektura Artykuä General Functionality and Stability Test Procedure for Microsoft Windows Logo, Desktop Applications Edition [Bach 1999] to pierwsze powszechnie dostöpne Ēródäo wiedzy na temat testów eksploracyjnych. Certyfikat WinLogo zapewnia klientów o prawidäowym dziaäaniu oprogramowania w Ĉrodowisku Windows. Jednak jak moĔna utworzyè systematyczny proces 410

ROZDZ AĤ 9

WYTWARZAN E

spójnej oceny moĔliwoĈci i ograniczeþ dowolnej aplikacji? Microsoft zwróciä siö z tym do Jamesa Bacha, dobrze znanego ze swych prac w dziedzinie testów eksploracyjnych. Zaprojektowana przez niego procedura testowa zostaäa udostöpniona niezaleĔnym producentom oprogramowania i uĔywajñ jej firmy przyznajñce certyfikaty, na przykäad Veritest. Artykuä ten jest dostöpny w internecie pod adresem http://www.testingcraft.com/bachexploratory-procedure.pdf. Praca Session-Based Test Management [Bach 2000] to pierwszy opublikowany artykuä ze szczegóäowym opisem zarzñdzania testami opartego na sesji. Metodö tö opracowaä James Bach we wspóäpracy ze swym bratem, Jonathanem, a ja opisaäam jñ jako Deklaracje i Sesje we wczeĈniejszej czöĈci rozdziaäu. Jednñ z trudnoĈci w testach eksploracyjnych jest zarzñdzanie procesem. Trzeba zachowaè koncentracjö, Ĉledziè postöpy i upewniaè siö, Ĕe efekty pracy sñ wartoĈciowe. Na tym polega rozwiñzanie. Tekst ten moĔna znaleĒè na stronie http://www.satisfice.com/articles/sbtm.pdf. Did I Remember To [Hunter] to doskonaäa lista heurystyk opisanych jako punkty, o których przetestowaniu trzeba pamiötaè. Ta lista jest szczególnie przydatna przy testach aplikacji dla systemu Windows, jednak obejmuje pomysäy dostosowane takĔe do innych technologii. Praca ta jest dostöpna w internecie pod adresem http://blogs.msdn.com/micahel/articles/175571.aspx. Autor artykuäu Rigorous Exploratory Testing [Hendrickson] obala przekonanie, Ĕe testy eksploracyjne to tylko stukanie w klawiaturö. Pokazuje teĔ, Ĕe testy eksploracyjne mogñ byè rygorystyczne, a przy tym nieformalne. Artykuä ten jest dostöpny w internecie pod adresem http://www.testobsessed.com/2006/04/19/rigorous-exploratory-testing/. Autorzy artykuäu User Profiles and Exploratory Testing [Kohl 2005a] w ciekawy sposób przypominajñ, Ĕe róĔni uĔytkownicy majñ odmienne wraĔenia z korzystania z oprogramowania, a ponadto dajñ wskazówki na temat okreĈlania zachowaþ uĔytkowników, pomocnego przy testach eksploracyjnych. Tekst ten znajduje siö na stronie http://www.kohl.ca/blog/archives/000104.html. Artykuä Exploratory Testing on Agile Teams [Kolh 2005b] zawiera studium przypadku dotyczñce wykorzystania póäautomatycznych testów eksploracyjnych do wykrycia usterki w zwinnym projekcie. Obala to przekonanie, Ĕe testy eksploracyjne to wyäñcznie röczna czynnoĈè. Jest to dobre uzupeänienie tego rozdziaäu. Tekst ten moĔna znaleĒè na stronie http://www.informit.com/ ´articles/article.asp?p=405514&rl=1. Strona A Survey of Exploratory Testing [Marick] zawiera ciekawy zbiór tekstów dotyczñcych testów eksploracyjnych, w tym artykuä General Functionality and Stability Test Procedure for Microsoft Windows Logo [Bach 1999]. Adres tej strony to http://www.testingcraft.com/exploratory.html. Artykuä Exploring Exploratory Testing [Tinkham i Kaner] to szczegóäowa analiza przeprowadzania testów eksploracyjnych, wäñcznie ze strategiami, miödzy innymi zadawaniem pytaþ i uĔywaniem heurystyk. Praca ta oparta jest na badaniach opäaconych czöĈciowo z grantu fundacji NSF i opisuje praktyki prowadzenia testów eksploracyjnych nieobecne w aktualnej wówczas wersji dokumentu Software Engineering Body of Knowledge (SWEBOK) organizacji IEEE. Artykuä ten jest dostöpny pod adresem http://www.testingeducation.org/a/explore.pdf.

TESTY EKSP ORACYJNE

411

412

ROZDZ AĤ 9

WYTWARZAN E

Czýļë III Mistrzostwo w dziedzinie programowania zwinnego

ROZDZIAĤ 10

Wartoļci i zasady

Do tego miejsca pisaäem o bardzo specyficznym podejĈciu do programowania zwinnego, o jednym, konkretnym stylu stosowania praktyk XP. To dopiero poczñtek. ēaden proces nie jest doskonaäy. W kaĔdym podejĈciu do programowania moĔna wprowadziè usprawnienia. Ostatecznym celem jest usuniöcie wszelkich barier miödzy zespoäem a powodzeniem projektu i päynne przystosowywanie podejĈcia do zmieniajñcych siö warunków. Na tym wäaĈnie polega zwinne programowanie. Aby opanowaè sztukö zwinnego wytwarzania oprogramowania, potrzebne jest doĈwiadczenie i rozwaga. DoĈwiadczenie pomaga zobaczyè, jak metody programowania zwinnego dziaäajñ. Rozwaga pomaga w zrozumieniu tych doĈwiadczeþ. DoĈwiadczenie umoĔliwia eksperymentowanie ze zmianami. Rozwaga — ustalenie, dlaczego te eksperymenty w praktyce dziaäaäy lub nie sprawdziäy siö. DoĈwiadczenie i rozwaga, nierozerwalnie poäñczone, to ĈcieĔka do mistrzostwa. Do tej pory koncentrowaäem siö na doĈwiadczeniu. Przed rozpoczöciem rozwaĔaþ na temat dziaäania metod zwinnych trzeba zobaczyè, jak funkcjonujñ. W tej ksiñĔce opisaäem przede wszystkim metody stosowania XP, dlatego jej lektura to umoĔliwia. Jednak uĔywanie XP nie wystarczy. Potrzebna jest teĔ rozwaga. Trzeba zwracaè uwagö na zachodzñce wokóä wydarzenia. Trzeba myĈleè o tym, jakie zjawiska wystöpujñ, a takĔe — co jeszcze waĔniejsze — dlaczego tak siö dzieje. Trzeba zadawaè pytania, wprowadzaè drobne zmiany i obserwowaè efekty. Nie mogö nauczyè nikogo rozwagi. KaĔdy musi zrobiè to sam. Mogö jednak przedstawiè pewne zagadnienia warte przemyĈlenia w trakcie nauki. Praktyki XP to ucieleĈnienie bardziej ogólnych wartoĈci i zasad programowania zwinnego. Warto o nich pamiötaè w trakcie stosowania tego podejĈcia. Kiedy warunki siö zmieniajñ, naleĔy wykorzystaè wartoĈci i zasady jako wskazówki pomocne przy modyfikowaniu praktyk.

Wspólne elementy Czy na programowanie zwinne naprawdö skäada siö dowolny zestaw reguä? W koþcu zwinne podejĈcie to tylko ogólna nazwa dla róĔnych metod, z których wiökszoĈè jest w uĔytku znacznie däuĔej niĔ pojöcie „programowanie zwinne”. 415

Tak, metody zwinne majñ wspólne wartoĈci i zasady. W badaniach przeprowadzonych na potrzeby tej czöĈci ksiñĔki zebraäem ponad sto róĔnych wartoĈci i zasad z wielu Ēródeä informacji na temat zwinnego podejĈcia1. Te reguäy moĔna podzieliè na piöè kategorii: Usprawnianie procesu, Poleganie na ludziach, Eliminowanie marnotrawstwa, Zapewnianie wartoĈci i DñĔenie do doskonaäoĈci technicznej. KaĔdy z tych obszarów jest zgodny z dowolnñ specyficznñ metodñ programowania zwinnego. W nastöpnych rozdziaäach opisujö te kategorie pod kñtem zasad i praktyk. KaĔdy rozdziaä zawiera anegdoty dotyczñce stosowania reguä w warunkach niestandardowych dla XP. Tam, gdzie to moĔliwe, uĔywam dla konkretnych zasad przyjötych nazw.

O wartoļciach, zasadach i praktykach WartoĈci to ideaäy. Sñ abstrakcyjne, a przy tym wykrywalne i specyficzne. WartoĈci w XP to: Odwaga Do podejmowania prawidäowych decyzji, nawet trudnych, i mówienia udziaäowcom prawdy, kiedy muszñ jñ usäyszeè. Komunikacja Aby przekazywaè odpowiednim osobom odpowiednie informacje wtedy, kiedy mogñ wykorzystaè je do uzyskania jak najwiökszych korzyĈci. Prostota Aby rezygnowaè z elementów, które zespóä chciaäby utworzyè, ale które nie sñ potrzebne. Informacje zwrotne W celu wyciñgania odpowiednich wniosków przy kaĔdej nadarzajñcej siö okazji. Szacunek Aby traktowaè siebie i innych z godnoĈciñ oraz szanowaè wiedzö i wspólne dñĔenie do sukcesu. Zasady wiñĔñ siö z realizacjñ tych ideaäów w przemyĈle. Na przykäad wartoĈè „prostota” prowadzi do koncentracji na najbardziej istotnych aspektach wytwarzania. Jak pisze Beck, ta zasada polega na „unikaniu obciñĔeþ” [Beck 2004]. Cockburn stwierdza, Ĕe „nadmiernie rozbudowana metodologia jest kosztowna”, a „dyscyplinö, umiejötnoĈci i zrozumienie naleĔy przeciwstawiè procesowi, formalizacji i dokumentacji” [Cockburn]. Praktyki to zasady stosowane w projektach konkretnego typu. Na przykäad praktyki XP wymagajñ pracujñcych wspólnie zespoäów skäadajñcych siö z nie wiöcej niĔ 20 osób. Podrozdziaäy „Wspólna praca” w rozdziale 6. i „Caäy zespóä” w rozdziale 3. opisujñ realizacjö zasady „prostota”, poniewaĔ dziöki bezpoĈredniej komunikacji formalna dokumentacja wymagaþ jest mniej istotna.

1

[Beck i inni], [Beck 1999], [Beck 2004], [Cockburn], [Highsmith], [Poppendieck i Poppendieck], [Schwaber i Beedle], [Subramaniam i Hunt], [Shore 2005b] i [Stapleton].

416

ROZDZ AĤ 10

WARTOĻC

ZASADY

Dalsza lektura Wymienione poniĔej ksiñĔki to doskonaäe Ēródäa informacji, które zawierajñ duĔo wiöcej szczegóäów, niĔ mogäem przedstawiè w tym miejscu. KaĔda z nich dotyczy nieco innego zagadnienia, dlatego dobrze siö uzupeäniajñ. KsiñĔka Agile Software Development [Cockburn] dotyczy gäównie aspektu „jednostek i interakcji” w programowaniu zwinnym. WiökszoĈè przemyĈleþ z tej pracy odpowiada zasadom, które przedstawiam w rozdziale 12. Autorzy ksiñĔki Lean Software Development: An Agile Toolkit for Software Development Managers [Poppendieck i Poppendieck] stosujñ techniki wytwarzania szczupäego do programowania zwinnego, käadñc nacisk na zasady opisane przeze mnie w rozdziaäach 13. i 14. KsiñĔka Agile Management for Software Engineering [Anderson 2003] jest napisana doĈè technicznym jözykiem, jednak zawiera szczegóäowe omówienie teorii ograniczeþ, którñ opisujö w podrozdziale „DñĔenie do wysokiej przepustowoĈci” w rozdziale 13. Practices of an Agile Developer [Subramaniam i Hunt] to äatwy w lekturze zbiór wskazówek i porad dla uĔytkowników zwinnego podejĈcia, zbliĔony treĈciowo do materiaäu przedstawionego w rozdziale 15. KsiñĔka Agile Software Development Ecosystems [Highsmith] to spojrzenie na kilka metod zwinnych pod kñtem ludzi i zasad. JeĈli ktoĈ chce dobrze zrozumieè zwinne wytwarzanie oprogramowania, powinien zapoznaè siö z tym tekstem. Autor ksiñĔki Extreme Programming Explained [Beck 1999, Beck 2004] opisuje proces myĈlowy, na którym opiera siö XP. Lektura tej pozycji pozwala lepiej zrozumieè zwiñzki miödzy zasadami programowania zwinnego a praktykami XP. Warto zapoznaè siö z oboma wydaniami tej ksiñĔki, poniewaĔ opisujñ ten sam podstawowy proces z zupeänie innej perspektywy. Analiza obu wydaþ pod kñtem cech wspólnych pozwala dobrze poznaè wartoĈci i zasady zwinnego wytwarzania.

DA SZA

EKTURA

417

418 ROZDZ AĤ 10

WARTOĻC

ZASADY

ROZDZIAĤ 11

Usprawnianie procesu

Zwinne metody to coĈ wiöcej niĔ lista praktyk. Kiedy zespóä nauczy siö ich skutecznego stosowania, moĔe osiñgnñè doskonaäe wyniki, stosujñc te praktyki do zmiany procesu pracy. Na kartach tej ksiñĔki zwracaäem uwagö na warunki, w których sposób stosowania XP moĔe róĔniè siö od przedstawionych tu objaĈnieþ. KaĔdy zespóä jest specyficzny. Grupy wykonujñ niektóre zadania inaczej, poniewaĔ skäadajñ siö z róĔnych osób i majñ odmienne potrzeby. Opanowanie sztuki zwinnego wytwarzania oprogramowania wymaga zrozumienia, jak i kiedy naleĔy modyfikowaè proces, aby wykorzystaè konkretne warunki i okazje.

Zrozumienie projektu Aby usprawniè proces, trzeba zrozumieè, jaki wpäyw ma na projekt. Trzeba skorzystaè z informacji zwrotnych (pochodzñcych z kodu, od zespoäu, od klientów i udziaäowców), aby stwierdziè, które techniki dziaäajñ dobrze, a które siö nie sprawdzajñ. Zawsze trzeba zwracaè uwagö na to, co siö dzieje. NaleĔy zadawaè pytanie „dlaczego?”. Dlaczego stosujemy tö praktykö? Dlaczego ona dziaäa? Dlaczego dana praktyka nie dziaäa? NaleĔy zapytaè czäonków zespoäu o ich przemyĈlenia. W kaĔdej skardze kryje siö ziarno prawdy, dlatego trzeba zachöcaè grupö do otwartej dyskusji. Zespóä powinien zastanawiaè siö nad nabytñ wiedzñ. Kiedy ktoĈ wykryje nowinkö, powinien peäniè funkcjö mentora. Kiedy ktoĈ ma pytanie, powinien zadaè je mentorowi. Czäonkowie zespoäu powinni pomagaè sobie w zrozumieniu, co robiñ i dlaczego.

Praktyki W XP wystöpuje wiele pötli informacji zwrotnych. Sñ to wielkie kanaäy informacyjne, których zespóä powinien uĔywaè do usprawnienia pracy. Analizy przyczynowo-skutkowe i retrospekcje poprawiajñ poziom zrozumienia procesu przez zespóä, a inne praktyki wspomagajñ zasady w bardziej poĈredni sposób. Na przykäad wspólna praca caäego zespoäu daje jego czäonkom moĔliwoĈè obserwacji innych i zdobywania informacji. Sñ to taktyczne informacje zwrotne, a technika ta pozwala odkryè 419

strategiczne problemy, kiedy stanie siö coĈ niespodziewanego. Krótkie spotkania robocze i informacyjne miejsce pracy teĔ przyczyniajñ siö do rozwoju Ĉrodowiska bogatego w informacje. MoĔe jest to nieintuicyjne, ale takĔe energiczna praca, zapas i programowanie w parach powodujñ rozpowszechnianie uĔytecznych informacji. Kiedy czäonkowie zespoäu pracujñ pod presjñ, trudno im myĈleè o sposobach usprawnienia pracy. Energiczna praca i zapas zmniejszajñ stres. Programowanie w parach daje jednej osobie w parze czas na przemyĈlenie strategii. Wytwarzanie sterowane testami, testy eksploracyjne, zaangaĔowanie prawdziwego klienta, demonstracje iteracji i czöste wydania równieĔ udostöpniajñ informacje o projekcie: od kodu po reakcje uĔytkowników.

Poza praktyki W duĔych i udanych projektach rozwoju oprogramowania bezpäatnego i o otwartym dostöpie do kodu Ēródäowego rotacja pracowników jest czösto wysoka. Od piöciu lat pracujö przy projekcie tego typu. W tym czasie dziesiñtki osób przyszäy do zespoäu i opuĈciäy go. Jest to normalne, zwäaszcza w przypadku ochotników. Zarzñdzanie tak czöstymi zmianami w zespole wymaga czasu i wysiäku. Ostatnio kierownik projektu, a zarazem jeden z najbardziej aktywnych programistów, musiaä ograniczyè swe zaangaĔowanie. Dopiero po kilku miesiñcach zauwaĔyliĈmy, Ĕe mamy problemy. Wynikaäo to z tego, Ĕe nikt nie przejñä obowiñzków lidera projektu w obszarze przygotowywania terminowych wydaþ. Wszystkie inne osoby przeglñdaäy zmiany i implementowaäy funkcje, a zgodnie z procesem za wydania wciñĔ odpowiadaä lider. To doĈwiadczenie pomogäo nam stwierdziè, Ĕe wiñzanie tak waĔnego zadania z jednñ osobñ to bäñd. Aby go naprawiè, zgodziliĈmy siö wspólnie przejñè ten obowiñzek. KaĔdego miesiñca jedna osoba odpowiadaäa za przygotowania wydania. Tworzyäa ona ostateczny, przetestowany pakiet, pisaäa informacje i przesyäaäa utworzonñ wersjö na gäównñ witrynö projektu, säuĔñcñ do rozpowszechniania oprogramowania. Przy szeĈciu osobach i planowaniu wydania na dany dzieþ udaäo nam siö pracowaè w duĔo bardziej stabilnym rytmie i regularnie udostöpniaè wydania. JeĈli ktoĈ byä niedostöpny, inne osoby mogäy wykonaè jego zadania. To rozwiñzanie dziaäaäo. OdzyskaliĈmy szybkoĈè i ponownie zaczöliĈmy przyciñgaè nowych programistów.

Dopracowywanie i adaptacja Po dostrzeĔeniu potrzeby wprowadzenia zmian naleĔy zmodyfikowaè proces. Zmiany powinny byè dostosowane do danego zespoäu. Choè moĔe on byè jednñ grupñ z wielu podobnych, dozwolone jest wykonywanie zadaþ w inny sposób. KaĔdy zespóä ma odmienne potrzeby. Zmiany wymagajñ dopracowania. MoĔna traktowaè je jak eksperymenty. Zespóä powinien wprowadzaè maäe, odizolowane modyfikacje, aby zrozumieè ich skutki. NaleĔy ustaliè konkretne oczekiwania i miary do oceny powodzenia. Wprowadzane zmiany to Ēródäo informacji zwrotnych i nauki. NaleĔy wykorzystaè wyniki eksperymentów do przygotowania dalszych modyfikacji, a nastöpnie powtarzaè ten proces do uzyskania zadowalajñcych efektów. Niektóre eksperymenty koþczñ siö poraĔkñ, a inne mogñ mieè negatywny wpäyw na proces. Czäonkowie zespoäu muszñ byè elastyczni i äatwo siö dostosowywaè. Grupa musi mieè odwagö do eksperymentowania i byè gotowa na sporadyczne poraĔki.

420 ROZDZ AĤ 11

USPRAWN AN E PROCESU

Zmiana procesu wymaga ogólnego spojrzenia na to, co zespóä robi i dlaczego. Zespoäy dopiero uczñce siö XP powinny zachowaè ostroĔnoĈè przy modyfikowaniu procesu, poniewaĔ nie majñ doĈwiadczenia potrzebnego do wytworzenia caäoĈciowej perspektywy. Po jego nabraniu naleĔy wykorzystaè zwiñzane ze zmianami informacje zwrotne do usprawnienia procesu i lepszego zrozumienia zwinnego podejĈcia.

Praktyki Dopracowywanie i adaptacja w XP sñ ukryte. Zespoäy powinny wprowadzaè zmiany zawsze, kiedy jest ku temu powód. Wiele zespoäów stosujñcych XP uĔywa retrospekcji jako bardziej bezpoĈredniego narzödzia do rozwaĔania zmian. TakĔe w tej ksiñĔce opisaäem retrospekcjö jako peänoprawnñ praktykö. Odwaga do adaptacji to waĔna zasada, jednak Ĕadna praktyka XP nie jest z niñ bezpoĈrednio zwiñzana. Jest to raczej aspekt wartoĈci Odwaga w podejĈciu XP. Wielokrotnie w tej ksiñĔce zwracaäem uwagö takĔe na perspektywö caäoĈciowñ, jednak Ĕadna praktyka jej nie odzwierciedla. Zagadnienie to zwiñzane jest z wartoĈciñ Informacje zwrotne w podejĈciu XP.

Poza praktyki Przytoczona tu anegdota o modyfikacji procesu udostöpniania moĔe prowadziè do wniosków, Ĕe zmiany przebiegaäy bardziej päynnie niĔ w rzeczywistoĈci. Kiedy lider projektu opuĈciä zespóä, zabraä ze sobñ rozlegäñ wiedzö na temat tworzenia wydaþ, wiedzö, która byäa dostöpna tylko w jego gäowie i nie byäa trwale udokumentowana w innym miejscu. WiedzieliĈmy o tym, a mimo to zdecydowaliĈmy siö przejñè proces udostöpniania. Dlaczego? Po pierwsze, choè wystñpiäy problemy w procesie, nie mieliĈmy innego wyjĈcia, jeĈli chcieliĈmy powróciè do comiesiöcznych wydaþ. Co jednak waĔniejsze, uznaliĈmy, Ĕe jest to najlepszy sposób na wykrycie problemów w opisie procesu. JeĈli osoba mogäa posäuĔyè siö instrukcjami do udostöpnienia peänego wydania, mimo Ĕe nigdy wczeĈniej tego nie robiäa, oznaczaäo to, Ĕe instrukcje byäy prawidäowe. W przeciwnym razie osoba przygotowujñca wydanie miaäa zrobiè listö problemów, a zespóä — wspólnie je rozwiñzaè. Wystñpiäa ta druga sytuacja. WykryliĈmy kilka problemów. System rozpowszechniania nie przesyäaä wydania na serwery lustrzane i niepoprawnie indeksowaä pliki, a automatyczny instalator caäkowicie zawodziä przy konfigurowaniu kodu Ēródäowego na potrzeby niestandardowych kompilacji. Naprawienie kaĔdego problemu wymagaäo usprawnienia procesu. PopeäniliĈmy kilka bäödów, jednak warto byäo zmierzyè siö z tym wyzwaniem. Do momentu wydania ksiñĔki udostöpniliĈmy szereg comiesiöcznych wydaþ. Choè pierwsze próby byäy trudne, z czasem jakoĈè wydaþ siö poprawiäa. Obecnie udostöpnianie oprogramowania znów jest äatwe.

Ĥamanie reguĥ Reguäy sñ waĔne i obowiñzujñ nie bez przyczyny. Jednak twórcy zasad nie mogñ przewidzieè wszystkich okolicznoĈci. Kiedy ustalone konwencje utrudniajñ odniesienie sukcesu, naleĔy zäamaè reguäy. ĤAMAN E REGUĤ

421

Skñd wiadomo, kiedy moĔna zäamaè zasady? Najpierw trzeba je zrozumieè, a takĔe poznaè przyczyny ich powstania. Wymaga to doĈwiadczenia. Po zrozumieniu reguä moĔna zastosowaè pragmatyczny idealizm i na podstawie praktycznych efektów ustaliè zestaw ideaäów (takich jak zasady programowania zwinnego). NaleĔy dñĔyè do ideaäów, jednak trzeba podchodziè do nich pragmatycznie. Na przykäad „Chcemy uniknñè problemów z integracjñ” to pragmatyczny efekt, który wiñĔe siö z ideaäem „Nigdy nie bödziemy przesyäaè kodu, który nie kompiluje siö lub nie przechodzi testów”. Na podstawie utworzonych zasad moĔna zakwestionowaè obowiñzujñce konwencje. Warto zastanowiè siö: „Dlaczego przestrzegamy tej zasady? Czy naprawdö jej potrzebujemy?”. NaleĔy zmodyfikowaè, obejĈè lub zäamaè reguäy, które uniemoĔliwiajñ osiñgniöcie sukcesu. Trzeba jednak pamiötaè, Ĕe powodzenie wymaga wsparcia ze strony organizacji. JeĈli zespóä naruszy reguäö, moĔe naraziè siö na nieprzyjemnoĈci. NaleĔy zachowaè gotowoĈè do objaĈnienia eksperymentów. Zespoäom äatwiej bez konsekwencji naruszaè reguäy, jeĈli dowiodäy swej wiarygodnoĈci i skutecznoĈci.

Praktyki Naruszanie reguä jest bardziej charakterystyczne dla folkloru zwiñzanego z XP niĔ dla praktyk. Na przykäad czäonkowie pierwszych zespoäów stosujñcych XP opowiadali, Ĕe w weekendy przychodzili do pracy, aby usunñè Ĉcianki komórek roboczych, zakäadajñc, Ĕe äatwiej bödzie uzyskaè przebaczenie za ten czyn niĔ pozwolenie na takie rozwiñzanie. Ron Jeffries, jeden z pierwszych zwolenników XP, jest znany ze swego stwierdzenia na temat praktyk XP: „To tylko reguäy”1. PóĒniej wyjaĈniä tö wypowiedĒ: To nie reguäy, ale techniki. To uĔywane narzödzia, nawyki, praktyki — rzeczy, które praktykujemy […]. Jednak warto wiedzieè, jak je stosowaè, i robiè to skutecznie2.

Poza praktyki Jednñ z na pozór nienaruszalnych reguä XP jest staäe utrzymywanie wysokiej jakoĈci kodu. Jest to nawet zasada programowania zwinnego (zobacz punkt „Späacanie däugu technicznego” w rozdziale 15.). Jednak nawet ta reguäa to tylko reguäa. Jako wspóäzaäoĔyciel nowej firmy miaäem okazjö przedstawiaè oprogramowanie na konferencji branĔowej. PrzygotowaliĈmy rozwiñzanie punktowe (zobacz podrozdziaä „Rozwiñzania punktowe” w rozdziale 9.), które przedstawiaäo pewne aspekty oprogramowania, jednak nie mieliĈmy dla niego testów. MusieliĈmy utworzyè przekonujñcñ wersjö demonstracyjnñ w ciñgu czterech tygodni. Prawidäowym rozwiñzaniem byäo utworzenie kodu od nowa przy uĔyciu wytwarzania sterowanego testami. W innej sytuacji zastosowaäbym to podejĈcie. Jednak mój partner nie znaä TDD tak dobrze jak ja. Miaäem teĔ inne zobowiñzania i nie mogäem poĈwiöciè zbyt wiele czasu na programowanie. Mogäem albo przeäoĔyè inne zobowiñzania i zastosowaè TDD, albo zaciñgnñè däug techniczny, rozwijajñc rozwiñzanie punktowe, albo zrezygnowaè z przedstawienia wersji demonstracyjnej na konferencji. 1

They’re just rules!, http://www.xprogramming.com/Practices/justrule.htm.

2

I was wrong. They’re not rules!, http://www.xprogramming.com/xpmag/jatNotRules.htm.

422 ROZDZ AĤ 11

USPRAWN AN E PROCESU

ZdecydowaliĈmy siö na rozwój rozwiñzania punktowego. Zäamanie reguä nie martwiäo nas tak bardzo jak to, Ĕe rozwiñzanie punktowe doprowadzi do wysokiego däugu technicznego, jednak zyski wydawaäy siö przewyĔszaè koszty. PrzygotowaliĈmy doskonaäñ wersjö demonstracyjnñ, a produkt okazaä siö przebojem konferencji. Nastöpnie wróciliĈmy do pracy i odczuliĈmy negatywne skutki podjötej decyzji. Cztery tygodnie narastajñcego däugu technicznego zablokowaäy rozwój naszej maäej, poczñtkujñcej firmy na niemal trzy miesiñce. To duĔo czasu. Jednak w tym scenariuszu zäamanie reguä byäo prawidäowñ decyzjñ. Reklama, jakñ zrobiliĈmy produktowi, byäa warta poniesienia kosztów obsäugi däugu technicznego. Kluczem do sukcesu byäo to, Ĕe zäamaliĈmy reguäö ostroĔnie i Ĉwiadomie, aby osiñgnñè konkretny cel. MieliĈmy teĔ trochö szczöĈcia. W ciñgu kilku miesiöcy späacania däugu technicznego Ĕaden z naszych konkurentów nie przygotowaä podobnej funkcji.

ĤAMAN E REGUĤ 423

424 ROZDZ AĤ 11

USPRAWN AN E PROCESU

ROZDZIAĤ 12

Poleganie na ludziach

Alistair Cockburn w pracy z 1999 roku, Characterizing people as non-linear, first-order components in software development, dowodzi, Ĕe osoby zaangaĔowane w rozwój oprogramowania majñ równie duĔy wpäyw na projekt jak uĔyte metody i praktyki. Choè Cockburn stwierdza, Ĕe jest to „caäkowicie oczywiste”, säusznie podkreĈla fakt, iĔ wielu ludzi o tym zapomina. Niemal kaĔde wyzwanie na drodze do doskonaäego oprogramowania jest pod pewnym wzglödem problemem zwiñzanym z ludĒmi. Wyzwania mogñ wiñzaè siö z efektywnñ komunikacjñ, radzeniem sobie z nieprzewidywalnoĈciñ nastrojów i poziomu motywacji lub ustalaniem, jak wykorzystaè skäonnoĈè pracowników do dobrej pracy w sposób korzystny dla zespoäu i projektu. Tylko nieliczne problemy sñ czysto techniczne. W metodach zwinnych ludzie i interakcje miödzy nimi sñ kluczowe przy podejmowaniu wszelkich decyzji. Jak zoptymalizowaè wspóäpracö? Jak skutecznie siö komunikowaè? JeĈli projekt rozwoju oprogramowania ma zakoþczyè siö sukcesem, trzeba odpowiedzieè na te pytania.

Budowanie efektywnych zwiézków JeĈli programista nie pisze oprogramowania sam i dla siebie, musi w trakcie rozwoju zetknñè siö z przynajmniej jednñ innñ osobñ. Brak wrogoĈci nie wystarczy. Niezbödna jest efektywna wspóäpraca. Wymaga to zbudowania wartoĈciowych zwiñzków opartych na szczeroĈci, zaufaniu, wspóäpracy, otwartoĈci i wzajemnym szacunku. Nie moĔna zmusiè pracowników do wspóäpracy. Metody zwinne mogñ co najwyĔej wspomagaè rozwój opisanych relacji. Na przykäad jednym ze sposobów na wytworzenie dobrej komunikacji jest praca w jednym miejscu i wspóädziaäanie w dñĔeniu do wspólnego celu. Niestety, duĔo äatwiej jest zaprojektowaè metodö w taki sposób, aby utrudniaäa budowö zdrowych zwiñzków. Kraþcowy przypadek (niestety, technika ta jest stosowana doĈè czösto) polega na poĈrednictwie analityków biznesowych w komunikacji miödzy programistami a udziaäowcami. Inne rozwiñzanie, które prowadzi do pogorszenia relacji miödzy programistami a testerami, wymaga komunikowania siö tych grup wyäñcznie za poĈrednictwem systemu Ĉledzenia bäödów. 425

TakĔe kultury nastawione na obwinianie szkodzñ relacjom. NaleĔy zapobiegaè obwinianiu, wprowadzajñc wspóäpracö i unikajñc praktyk, które sugerujñ brak zaufania. Zamiast zmuszaè udziaäowców do podpisania dokumentacji wymagaþ, naleĔy wspóäpracowaè przy wykrywaniu i objaĈnianiu wymagaþ oraz iteracyjnie oceniaè postöpy. Zamiast mówiè programistom, Ĕe nie mogñ generowaè Ĕadnych bäödów, a testerom, Ĕe muszñ wykryè wszystkie usterki, naleĔy poprosiè obie te grupy, aby wspóäpracowaäy ze sobñ w celu zapobieĔenia dotarciu bäödów do klientów. Ludzie — zwäaszcza o nastawieniu technicznym — äatwo zagäöbiajñ siö w szczegóäy konkretnego rozwiñzania. NaleĔy zachöcaè pracowników do wspóäpracy i eksperymentów przy jednoczesnym zachowaniu rozróĔnienia miödzy pomysäami a ludĒmi. Uznanie jest nieistotne, podobnie jak racja. Istotne sñ: traktowanie czäonków zespoäu z szacunkiem i wspóäpraca przy rozwoju doskonaäego oprogramowania.

Praktyki Choè Ĕaden proces nie moĔe wymusiè efektywnych zwiñzków, XP skutecznie umoĔliwia ich powstawanie. Najbardziej oczywisty przykäad to budowanie wielofunkcyjnych zespoäów pracujñcych we wspólnym pomieszczeniu roboczym. Dziöki cotygodniowym demonstracjom iteracji zespoäy obejmujñ teĔ udziaäowców. W XP waĔne jest równieĔ wäñczanie w proces prawdziwych klientów. Codzienne praktyki, na przykäad krótkie spotkania robocze, wspóäwäasnoĈè kodu, wspólny jözyk, gra planistyczna i programowanie w parach, pokazujñ, Ĕe czäonkowie zespoäu powinni wspóäpracowaè w dñĔeniu do osiñgniöcia wspólnego celu.

Poza praktyki W XP nie bez przyczyny zalecana jest wspólna praca zespoäu. DuĔo äatwiej komunikowaè siö i tworzyè relacje o solidnych podstawach, kiedy wszyscy znajdujñ siö w jednym pomieszczeniu. Jednak niektóre zespoäy nie mogñ lub nie chcñ wspólnie pracowaè. Jak poradziè sobie z takim problemem? Jednym z moich hobby jest praca przy däugim projekcie rozwoju bezpäatnego oprogramowania. Wspóäpracuje przy nim gäówna grupa programistów rozproszonych po caäym Ĉwiecie. Komunikujemy siö przez sieè, co prowadzi do pewnych trudnoĈci. Na przykäad jeden z programistów — nazwö go „Bob” — komunikuje siö w doĈè szorstki sposób. Czasem prowadzi to do tarè z osobami, które nie znajñ Boba zbyt dobrze i uwaĔajñ, Ĕe jest nieuprzejmy. Angielski nie jest pierwszym jözykiem Boba, dlatego naturalne jest, Ĕe wyraĔa siö w nim doĈè zwiöĒle. Problemy tego typu pojawiajñ siö we wszystkich rozproszonych zespoäach. ãatwo przypisaè komuĈ zäe motywy, kiedy nie moĔna z nim porozmawiaè bezpoĈrednio. Aby zapobiec eskalacji problemów, zdecydowaliĈmy siö na jak najczöstsze spotkania osobiste — zwykle trzy lub cztery razy w roku. Bob uczestniczyä w ostatnim spotkaniu, po którym czäonkowie zespoäu stwierdzili, Ĕe zrozumieli jego styl komunikacji. Zdali sobie sprawö, Ĕe sposób wyraĔania siö Boba nie miaä nikogo uraziè, ale byä wynikiem kultury, z jakiej pochodziä.

426 ROZDZ AĤ 12

PO EGAN E NA

UDZ ACH

WprowadziliĈmy teĔ cotygodniowe spotkania. Sñ one prowadzone wirtualnie, ale pomagajñ zrozumieè, nad czym pracujñ poszczególne osoby. Te spotkania majñ wpäyw na spójnoĈè zespoäu i kierunek prac oraz pomagajñ ograniczaè niepotrzebne napiöcia. Zespoäy rozproszone — zwäaszcza takie jak mój, czyli skäadajñce siö z ochotników pracujñcych w niepeänym wymiarze godzin — zawsze zmagajñ siö z trudnoĈciami w obszarze komunikacji, dlatego trzeba je uwzglödniè i wprowadziè zmiany, które umoĔliwiñ pracowanie i komunikowanie siö w bardziej wydajny sposób.

Odpowiednie osoby do odpowiednich zadaħ Dziaäajñcy zespóä to nie wszystko. Potrzebne sñ odpowiednie osoby, które dobrze ze sobñ wspóäpracujñ. Niezbödna jest zróĔnicowana wiedza. Po znalezieniu odpowiednich pracowników naleĔy uwierzyè, Ĕe dobrze wykonajñ powierzone im zadania. Zamiast tworzyè proces, który chroni firmö przed pracownikami, naleĔy zaprojektowaè go tak, aby umoĔliwiaä czäonkom zespoäu osiñganie wyjñtkowych wyników. Zespóä powinien mieè kontrolö nad swñ pracñ. Czäonkowie grupy to eksperci — w koþcu dlatego weszli w skäad zespoäu. NaleĔy im zaufaè i poprzeè to przyznaniem uprawnieþ potrzebnych do zakoþczenia projektu sukcesem. JeĈli nie moĔna zawierzyè grupie, nie skäada siö ona z odpowiednich osób. Nikt nie jest doskonaäy, jednak potrzebny jest zespóä, któremu moĔna zaufaè jako caäoĈci.

UWAGA Uprawnienia do podejmowania codziennych decyzji dotyczñ takĔe procesu programowania zwinnego. NaleĔy uĔyè zasad zwinnego podejĈcia do modyfikacji wäasnego procesu, zamiast pozwalaè narzucaè sobie zmiany.

W zespole kaĔdy moĔe byè liderem. NaleĔy zachöciè czäonków zespoäu do tego, aby zwracali siö z pytaniami do osób o najwyĔszych kwalifikacjach do podjöcia konkretnej decyzji. Na przykäad, kiedy niezbödne sñ decyzje dotyczñce projektu, naleĔy poprosiè o pomoc starszych programistów. Kiedy decyzje majñ dotyczyè kwestii biznesowych, warto poprosiè o dokonanie wyboru osobö z najwiökszym doĈwiadczeniem biznesowym. Przywództwo nie oznacza walenia piöĈciñ w stóä i krzyczenia: „Ja jestem tu najstarszy, dlatego zrobimy to po mojemu!”. Przywództwo wynika z kierowania innymi. JeĈli zespóä uwaĔa, Ĕe dana osoba ma najwiöksze kwalifikacje do podjöcia decyzji, bödzie kierowaè siö jej wskazówkami. JeĈli ta osoba nie jest uznawana za autorytet, nie powinna zachowywaè siö tak, jakby miaäa wäadzö nad zespoäem, nawet jeĈli rzeczywiĈcie uwaĔa, Ĕe jñ ma. MenedĔerowie nie powinni mówiè czäonkom zespoäu, co majñ robiè, ale raczej dowiadywaè siö, jakiej pomocy w odniesieniu sukcesu zespóä oczekuje od menedĔera.

Praktyki Ta zasada ma dwa aspekty. Najpierw naleĔy zaangaĔowaè odpowiednie osoby, a nastöpnie daè im uprawnienia do odpowiedniego wykonywania zadaþ. W XP zespoäy obejmujñ klientów i testerów oraz — jeĈli to uzasadnione — prawdziwych klientów, co wiñĔe siö z pierwszym aspektem.

ODPOW EDN E OSOBY DO ODPOW EDN CH ZADAĦ 427

Drugi aspekt — nadawanie czäonkom zespoäu uprawnieþ do prawidäowego wykonywania swych zadaþ — jest wspomagany przez wiele praktyk XP. Zespóä obejmuje nie kierownika, a coacha, który pomaga czäonkom zespoäu, a nie kieruje nimi. Gra planistyczna pomaga zespoäowi dzieliè przywództwo, poniewaĔ uwzglödnia wiedzö zarówno programistów, jak i ekspertów biznesowych. Dojrzaäe zespoäy stosujñce XP praktykujñ samoorganizowanie siö. Czäonkowie zespoäu zapominajñ o tym, kto odpowiada za dane zadanie, a w zamian kieruje nim jego naturalny lider.

Poza praktyki Adrian Howard przytacza anegdotö o zespole, który wziñä odpowiedzialnoĈè za odniesienie sukcesu, dziöki czemu organizacja przyznaäa mu potrzebne uprawnienia1: Kilka lat temu pracowaäem przy (tradycyjnym) projekcie, w którym uĔywaliĈmy duĔej tablicy korkowej. Znajdowaäy siö na niej karteczki z opisem zadaþ wykonywanych przez poszczególne osoby. Zadania te byäy podzielone na trzy kategorie:

1. Do zrobienia. 2. W toku (podzielone wedäug programistów). 3. Gotowe. Z czasem karteczki przechodziäy z grupy 1. do 2. i do 3. PracowaliĈmy w duĔym, otwartym biurze, aby kaĔdy mógä widzieè tablicö. Poczñtkowo zmagaliĈmy siö z przerwami. PrzyciñgnöliĈmy uwagö kierownictwa z powodu przekroczenia terminu i bardzo säabych efektów. Zespóä programistyczny nieustannie byä krytykowany za brak realizacji harmonogramu. Wszyscy chodziliĈmy smutni, pracowaliĈmy w nadgodzinach i byliĈmy rozĔaleni. Po dyskusji zespóä programistyczny utworzyä nowñ zasadö opartñ na karteczkach: kiedy ktoĈ zostanie poproszony o wykonanie czynnoĈci niezwiñzanych z obecnym zadaniem, powinien wstaè, podejĈè wraz z przeszkadzajñcñ osobñ do tablicy i przenieĈè karteczkö z opisem bieĔñcego zadania do obszaru „Do zrobienia”. Dopiero wtedy moĔe przystñpiè do rozwiñzywania nowego zadania. Po kilku tygodniach obszar „Do zrobienia” zostaä przeksztaäcony w sekcjö „Wstrzymane”, a my pokazywaliĈmy przeszkadzajñcym osobom poszczególne karteczki w momencie ich przenoszenia. To w duĔym stopniu zakoþczyäo przerywanie nam pracy z nieistotnych powodów. Byä to takĔe koniec panujñcej wczeĈniej kultury przypisywania zespoäowi winy za przekraczanie terminów. Ludzie zaczöli przepraszaè nas, kiedy realizacja harmonogramu byäa niemoĔliwa. Nie musieliĈmy zbieraè Ĕadnych nowych informacji. Zawsze przechowywaliĈmy wyczerpujñce arkusze czasu i mogliĈmy pokazaè, czym siö zajmowaliĈmy. Zmieniäo siö tylko to, Ĕe w momencie, kiedy ktoĈ nam przeszkodziä, publicznie demonstrowaliĈmy cofanie siö prac. Za kaĔdym razem caäa firma widziaäa, Ĕe tak siö dzieje (i kto jest tego przyczynñ).

1

Po raz pierwszy historia ta pojawiäa siö na liĈcie dyskusyjnej na temat XP: http://tech.groups.yahoo.com/group/ ´extremeprogramming/message/88438. Wykorzystaäem jñ za pozwoleniem.

428 ROZDZ AĤ 12

PO EGAN E NA

UDZ ACH

Budowanie procesu dla ludzi W metodach zwinnych uwzglödniana jest podstawowa rola czäowieka w rozwoju oprogramowania. Metody te zbudowane sñ pod kñtem ludzi, a nie maszyn. Efektywna praca wymaga gäöbszego zrozumienia wspóäpracy, a nie tylko okreĈlenia powierzchownej dynamiki interakcji lub osoby podejmujñcej decyzjö. OmylnoĈè jest jednñ z cech ludzkich. Popeäniamy pomyäki, zapominamy o waĔnych praktykach i uparcie odmawiamy robienia rzeczy, które sñ dla nas korzystne — zwäaszcza kiedy jesteĈmy zmöczeni lub zestresowani. Jednak ludzie majñ teĔ zalety. Sñ twórczy, zabawni i — w odpowiednich warunkach — pracujñ z pasjñ i dñĔñ do sukcesu. ēadna maszyna nie ma takich cech. W trakcie modyfikowania metod zwinnych naleĔy opieraè siö na tych podstawowych wadach i zaletach. Nie trzeba wymagaè perfekcji. W zamian naleĔy zaprojektowaè proces tak, aby moĔna byäo szybko wykryè i naprawiè bäödy. NaleĔy wykorzystaè kreatywnoĈè zespoäu. JeĈli zadanie jest nudne i powtarzalne, warto je zautomatyzowaè. Nie wolno teĔ zapominaè o przyjemnoĈciach. Rozwój oprogramowania to wielki biznes, jednak najlepsi programiĈci, jakich znam, uwielbiajñ swñ pracö. Z pasjñ podchodzñ do projektów oraz Ĕartujñ i bawiñ siö w ich trakcie. Znane mi Ĉwietne zespoäy spotykajñ siö takĔe po pracy. ēadna metoda zwinna nie moĔe tego wymusiè, jednak moĔna stworzyè ku temu warunki, wykrywajñc i eliminujñc bariery przeszkadzajñce w naturalnych interakcjach miödzyludzkich.

Praktyki Charakterystyczna dla XP koniecznoĈè zachowania samodyscypliny jest na pozór niezgodna z zasadñ zrozumienia ludzkich säaboĈci. Ludzie nie radzñ sobie dobrze ze staäym zachowywaniem samodyscypliny, jak wiöc majñ z powodzeniem stosowaè XP? W XP problem z samodyscyplinñ jest rozwiñzywany na kilka sposobów. Po pierwsze, programiĈci oprogramowania uwielbiajñ tworzyè kod wysokiej jakoĈci. Kiedy widzñ, jakñ jakoĈè kodu zapewnia XP, zwykle stajñ siö gorñcymi zwolennikami tego podejĈcia. MoĔliwe, Ĕe nie zawsze bödñ w zdyscyplinowany sposób przestrzegaè praktyk, jednak zwykle bödñ chcieli je stosowaè. Danie ludziom odpowiedzialnoĈci za jakoĈè zachöca ich do wykorzystania w pracy wszystkich umiejötnoĈci. Po drugie, energiczna praca i programowanie w parach zapewniajñ programistom wsparcie, kiedy muszñ zachowaè dyscyplinö. ProgramiĈci, którzy chcñ przestrzegaè praktyk, zwykle äamiñ je wtedy, kiedy czujñ siö zmöczeni lub sfrustrowani. Energiczna praca zmniejsza prawdopodobieþstwo wystñpienia takiej sytuacji. Programowanie w parach prowadzi do pozytywnej presji ze strony wspóäpracownika i zapewnia dodatkowe wsparcie. JeĈli jeden z partnerów ma ochotö na zastosowanie nieeleganckiego skrótu, drugi zwykle skieruje go w odpowiednim kierunku. Po trzecie, choè XP wymaga, aby zespóä byä ogólnie zdyscyplinowany, perfekcja nie jest konieczna. JeĈli para podejmie zäñ decyzjö, dziöki wspóäwäasnoĈci kodu inna para póĒniej to zauwaĔy i naprawi bäñd. XP opiera siö na zaäoĔeniu, Ĕe projekt jest päynny. Refaktoryzacja i stopniowy rozwój projektu znacznie uäatwiajñ poprawianie pomyäek, a iteracyjne projektowanie i planowanie przystosowawcze sprawiajñ, Ĕe najwartoĈciowsze funkcje sñ nieustannie przeglñdane. BUDOWAN E PROCESU D A

UDZ

429

W XP uwzglödniono czäowieczeþstwo zespoäu takĔe w innych aspektach. Automatyczna kompilacja pozwala zastñpiè Ĕmudne zadania automatycznymi skryptami, a wytwarzanie sterowane testami, oparte na maäych zadaniach i ciñgäym napäywie informacji zwrotnych, pomaga programistom zauwaĔaè i poprawiaè pomyäki bezpoĈrednio po ich popeänieniu.

Poza praktyki Znajomy — „Mel” — pracowaä kiedyĈ dla maäej firmy doradczej. Placówka miaäa zawsze od trzech do piöciu programistów i dwa razy tyle klientów, dlatego zwykle pracowano w ciñgu tygodnia nad kilkoma projektami. Aby uproĈciè wystawianie rachunków, firma uĔywaäa niestandardowej aplikacji do Ĉledzenia czasu pracy, która dziaäaäa w tle w systemie Windows i wymagaäa od programistów wpisania nowego kodu rachunku przy zmianie zadania. Ta jedna aplikacja byäa jedynym powodem, dla którego programiĈci potrzebowali Windowsa, poniewaĔ wdraĔali rozwiñzania niemal wyäñcznie na platformach linuksowych. Brak dostöpu do natywnych narzödzi od czasu do czasu powodowaä problemy. Regularne przeäñczanie siö miödzy zadaniami — powód uĔywania aplikacji do Ĉledzenia czasu — czösto byäo dla programistów wiökszym problemem niĔ przygotowanie precyzyjnych statystyk. Rozwiñzanie wymyĈlone przez Mela skäadaäo siö z dwóch czöĈci. Po pierwsze, poĈwiöcaä poranki na drobne zadania, takie jak odpowiadanie na raporty o bäödach, wprowadzanie drobnych poprawek lub obsäugö Ĕñdaþ klientów. Minimalnñ jednostkñ rozrachunkowñ byäo 15 minut, co w sam raz wystarczaäo na wejĈcie w stan przepäywu przy pracy nad projektem. Dziöki temu Mel mógä poĈwiöciè popoäudnia (czas, kiedy pracowaä najbardziej produktywnie) na däuĔsze zadania, wymagajñce od dwóch do czterech godzin pracy. Bardzo nieliczne Ĕñdania klientów wymagaäy natychmiastowego rozwiñzania, a wiökszoĈè odbiorców znajdowaäa siö na Wschodnim WybrzeĔu, czyli w strefie czasowej przesuniötej o trzy godziny. Kiedy Mel wracaä o 13 z przerwy obiadowej, jego klienci przygotowywali siö do zakoþczenia pracy. Druga czöĈè rozwiñzania polegaäa na wykorzystaniu karteczek do rejestrowania czasu wykonywania zadaþ. Czösto zapisanie czasu trwaäo krócej niĔ znalezienie odpowiedniego kodu rachunku w aplikacji. Oznaczaäo to równieĔ, Ĕe Mel mógä uruchomiè Linuksa i nie musiaä zmieniaè systemu. Nastöpnie tuĔ przed wyjĈciem z pracy mógä wpisaè statystyki w aplikacji uruchomionej na innym komputerze. Inni programiĈci zauwaĔyli, Ĕe wydajnoĈè Mela wzrosäa, a on chötnie podzieliä siö swym rozwiñzaniem. Kiedy menedĔer zauwaĔyä, Ĕe wszyscy zmienili system pracy, efekty byäy jednoznaczne. ProgramiĈci byli bardziej zadowoleni oraz wydajniejsi.

430 ROZDZ AĤ 12

PO EGAN E NA

UDZ ACH

ROZDZIAĤ 13

Eliminowanie marnotrawstwa

Trudno zmieniè kurs ciöĔkiego statku wycieczkowego, podczas gdy kajak „taþczy” w nurcie rzeki przy najlĔejszym poruszeniu wiosäem. Choè statki wycieczkowe sñ przydatne, kajak jest duĔo bardziej zwinny. ZwinnoĈè wymaga elastycznoĈci i lekkiego procesu, ograniczonego do najistotniejszych elementów. Wszystko ponad to jest marnotrawstwem i naleĔy z tego zrezygnowaè. Im mniej rzeczy zespóä musi robiè, tym mniej czasu zajmuje praca, tym niĔsze sñ koszty i tym szybciej rozwiñzanie jest gotowe. Nie moĔna jednak tak po prostu zrezygnowaè z praktyk. Co jest naprawdö potrzebne? Jak moĔna stwierdziè, czy coĈ pomaga, czy przeszkadza w pracy? Co pozwala udostöpniè dobre oprogramowanie osobom, które go potrzebujñ? Udzielenie odpowiedzi na te pytania pomaga wyeliminowaè marnotrawstwo z procesu i zwiöksza zwinnoĈè.

Praca w maĥych, odwracalnych etapach Najäatwiejszy sposób na ograniczenie marnotrawstwa to zmniejszenie iloĈci materiaäów, które trzeba potem usunñè. Wymaga to podziaäu zadaþ na jak najmniejsze fragmenty i sprawdzania ich poprawnoĈci. Czasem w trakcie diagnozowania od razu dostrzegam wiele problemów i ich rozwiñzania. Debugowanie masowe to kuszñca moĔliwoĈè, jednak jeĈli wprowadzö kilka rozwiñzaþ jednoczeĈnie i naprawiö bäñd, mogö nie wiedzieè, które rozwiñzanie naprawdö zadziaäaäo. Ponadto zwykle prowadzi to do powstania baäaganu. Stopniowe wprowadzanie zmian to lepsze podejĈcie. Wprowadzam jednñ, dobrze uzasadnionñ zmianö, obserwujö i sprawdzam jej efekty, a nastöpnie decydujö, czy zatwierdziè jñ, czy anulowaè. W ten sposób lepiej poznajö kod i tworzö lepsze — oraz przejrzystsze — rozwiñzania. MoĔe siö wydawaè, Ĕe pracujö w maäych kroczkach, i rzeczywiĈcie tak jest. Choè mogö pracowaè nad funkcjñ 10 – 15 minut i nie popeäniè przy tym bäödów, jakoĈè kodu znacznie siö poprawia, kiedy koncentrujö siö na bardzo maäych fragmentach i poĈwiöcam czas na ich dopracowanie przed przejĈciem do dalszych zadaþ. Te maäe, krótkie kroki opierajñ siö na poprzednich. Rzadko muszö anulowaè jakiekolwiek zmiany. 431

JeĈli kod z danego kroku nie dziaäa, poĈwiöciäem minutö lub dwie na nauczenie siö czegoĈ nowego i mogö cofnñè siö o kilka minut do miejsca, od którego mogö zaczñè robiè dalsze postöpy. Te czöste poprawki kursu pomagajñ mi dotrzeè do poĔñdanego celu. Maäe kroczki zmniejszajñ zasiög bäödów do ostatnio wprowadzonych zmian, które sñ drobne i wciñĔ obecne w pamiöci.

Praktyki ProgramiĈci czösto chcñ rozwiñzywaè duĔe, skomplikowane problemy. Programowanie w parach pomaga programistom wzajemnie zachöcaè siö do wykonywania maäych kroków w celu unikniöcia zbödnych dodatków. Ponadto pilot koncentruje siö na bardziej ogólnym obrazie, dziöki czemu obaj programiĈci mogñ spojrzeè na system caäoĈciowo. Wytwarzanie sterowane testami zapewnia naturalny rytm pracy dziöki cyklowi myĈlenietesty-projektowanie-pisanie kodu-refaktoryzacja. Udane zakoþczenie kaĔdego cyklu prowadzi do utworzenia stabilnego punktu kontrolnego, w którym caäy system dziaäa zgodnie z oczekiwaniami. Jest to mocny punkt podparcia, od którego moĔna kontynuowaè pracö. JeĈli programista popeäni bäñd, moĔe szybko przywróciè wczeĈniejszy stan o sprawdzonej poprawnoĈci. Na wyĔszym poziomie to opowieĈci ograniczajñ iloĈè pracy wykonywanej w czasie jednej sesji pracy w parach. Maksymalna däugoĈè kroku nie moĔe przekraczaè kilku dni. Ciñgäa integracja pozwala rozpowszechniaè dziaäajñcy kod w caäym zespole. Grupa w stabilnym tempie czyni nieustanne postöpy, a kod jest zawsze gotowy do udostöpnienia. Refaktoryzacja umoĔliwia stopniowy rozwój projektu. Projektowanie systemu odbywa siö w maäych kroczkach, kiedy jest to potrzebne. Kiedy programiĈci dodajñ funkcje, zmienia siö ich podejĈcie do tego, jaki projekt jest wystarczajñcy i niezbödny. Refaktoryzacja umoĔliwia dostosowanie systemu do projektu optymalnego w danym momencie.

Poza praktyki Zeszäego lata nauczyäem znajomñ programowania w parach. Chciaäa zautomatyzowaè projekt oprogramowania do zarzñdzania historiñ rodziny i uzgodniliĈmy, Ĕe napiszemy mechanizm do przetwarzania przykäadowych danych genealogicznych. Format pliku byä skomplikowany i zawieraä ciekawe reguäy oraz pola, których Ĕadne z nas nie rozumiaäo, jednak znajoma wiedziaäa, które dane program ma przetwarzaè, a które moĔna pominñè. ZaczöliĈmy od napisania prostego szkieletu opartego na testach. Czy moĔna wczytywaè pliki wedäug nazw? Czy program informuje o bäödach w wyjñtkowych warunkach? Nastöpnie zaczöäa siö zabawa. Skopiowaäem kilka pierwszych rekordów z przykäadowego pliku, aby uĔyè ich jako danych testowych, i napisaäem pojedynczy test: czy parser potrafi wykryè typ pierwszego rekordu? Nastöpnie przekazaäem znajomej klawiaturö i powiedziaäem: „Spraw, aby kod przeszedä test”. „Jakñ wartoĈè ma moĔliwoĈè odczytu jednego rekordu i okreĈlenie jego typu?” — zdziwiäa siö, ale napisaäa dwa wiersze kodu, a test zakoþczyä siö powodzeniem. Poprosiäem jñ o przygotowanie nastöpnego testu. Znajoma napisaäa wiersz sprawdzajñcy, czy moĔna pobraè z rekordu imiö i nazwisko osoby, a nastöpnie przekazaäa mi klawiaturö.

432 ROZDZ AĤ 13

E

M NOWAN E MARNOTRAWSTWA

Napisaäem trzy wiersze kodu, a testy zakoþczyäy siö powodzeniem. Nastöpnie przygotowaäem test sprawdzania nastöpnego typu rekordu. OczywiĈcie zakoþczyä siö niepowodzeniem. Kiedy przekazywaäem klawiaturö znajomej, omawialiĈmy rozwiñzania, który umoĔliwiñ udane ukoþczenie testów. Zasugerowaäem zapisanie na staäe drugiego typu w metodzie przetwarzajñcej. Znajoma spojrzaäa na mnie niepewnie, ale zrobiäa to, a testy zakoþczyäy siö powodzeniem. „Pora na refaktoryzacjö” — stwierdziäem, po czym uogólniliĈmy metodö, skracajñc jej kod. Aby kod przeszedä nastöpny test przygotowany przez partnerkö, musiaäem sprawiè, aby przetwarzaä dalsze dane z obu typów rekordów. Wymagaäo to jednego wiersza kodu. KontynuowaliĈmy pracö przez dwie godziny, dodajñc coraz wiökszñ czöĈè przykäadowego pliku do danych testowych, kiedy rozwiñzanie przechodziäo nastöpne testy. Za kaĔdym razem, kiedy natrafiliĈmy na nowe aspekty formatu plików, opracowywaliĈmy je w maäych fragmentach przy uĔyciu drobnych testów. Nie przygotowaliĈmy caäego rozwiñzania, jednak mieliĈmy niewielkñ iloĈè kodu i rozbudowany pakiet testów, który byä pomocny przy dalszym rozwoju.

Szybkie wykrywanie niepowodzeħ MoĔe siö to wydawaè oczywiste, ale warto przypomnieè, Ĕe niepowodzenie to nastöpne Ēródäo marnotrawstwa. Niestety, jedyny sposób na caäkowite unikniöcie bäödów to powstrzymanie siö od rozwoju czegokolwiek wartoĈciowego. Nie jest to sposób na uzyskanie wyjñtkowych efektów. DeMarco i Lister piszñ: „Projekty bez prawdziwego ryzyka sñ skazane na poraĔkö. Niemal zawsze sñ one pozbawione korzyĈci, dlatego nie przeprowadzono ich juĔ wiele lat wczeĈniej” [DeMarco i Lister 2003]. Zamiast próbowaè unikaè niepowodzeþ, naleĔy zmierzyè siö z nimi: „JeĈli projekt ma zakoþczyè siö niepowodzeniem, chcö siö o tym dowiedzieè jak najszybciej”. NaleĔy szukaè sposobów na uzyskanie informacji, które okreĈlajñ prawdopodobieþstwo poraĔki. NaleĔy przeprowadzaè eksperymenty w ryzykownych obszarach, aby zobaczyè, czy rozwiñzanie nie zawiedzie w praktyce. Im szybciej organizacja anuluje nieudany projekt, tym mniej czasu, pracy i pieniödzy na niego zmarnuje. Szybkie wykrywanie bäödów dotyczy wszystkich aspektów pracy, nawet tak drobnych, jak kupowanie jednej porcji kawy nowego typu zamiast caäej paczki. Dziöki temu nie trzeba nadmiernie martwiè siö tym, czy podejmowane decyzje sñ dobre, czy zäe. JeĈli programista nie ma pewnoĈci, powinien tak zaplanowaè pracö, aby moĔna byäo dostrzec bäödy natychmiast po tym, jak siö pojawiñ. JeĈli rozwiñzanie ma zawieĈè, niech bäñd zostanie wykryty szybko, zamiast pozostawaè w ukryciu. Zawsze naleĔy poĈwiöciè tylko tyle czasu i zasobów, aby uzyskaè pewnoĈè co do wyników. Przy stosowaniu tych zasad programiĈci nie muszñ obawiaè siö niepowodzeþ przy podejmowaniu decyzji. JeĈli bäödy nie prowadzñ do duĔych szkód, sñ dozwolone. ProgramiĈci mogñ dziöki temu swobodnie eksperymentowaè i podejmowaè ryzyko. NaleĔy wykorzystaè tö moĔliwoĈè. JeĈli programista ma pomysä, nie powinien siö zastanawiaè, czy jest dobry, ale moĔe od razu go wypróbowaè. NaleĔy przygotowaè eksperyment, który pozwoli szybko wykryè bäödy, i zobaczyè, co siö stanie.

SZYBK E WYKRYWAN E N EPOWODZEĦ 433

Praktyki Jednñ z trudnoĈci przy wprowadzaniu XP jest ujawnianie problemów. Na przykäad iteracje, szybkoĈè i gra planistyczna uwidaczniajñ rozbieĔnoĈci miödzy rzeczywistoĈciñ a aspiracjami zespoäu w obszarze harmonogramu. Jest to celowe. To jeden ze sposobów szybkiego ujawniania bäödów w XP. JeĈli przygotowany harmonogram jest nierealistyczny, zespóä powinien o tym wiedzieè. JeĈli mimo to projekt warto kontynuowaè, naleĔy albo ograniczyè zakres prac, albo zmieniè harmonogram. W przeciwnym razie trzeba anulowaè prace. MoĔe siö wydawaè, Ĕe to skrajne rozwiñzanie, jednak w rzeczywistoĈci odzwierciedla jedynie nastawienie na „szybkie wykrywanie usterek”. To nastawienie moĔe byè obce organizacjom, które dopiero poznajñ XP. Jest szczególnie käopotliwe w firmach, w których powszechne jest tworzenie nierealistycznych harmonogramów. Kiedy w takiej organizacji XP doprowadzi do szybkiego wykrycia niepowodzenia, czösto uĔytkowników podejĈcia XP obwinia siö o to, zamiast chwaliè. Jednak w zespoäach stosujñcych XP wczesne anulowanie projektu nie Ĉwiadczy o niepowodzeniu, ale o sukcesie. Zespóä zapobiegä zmarnowaniu setek tysiöcy zäotych na rozwój projektu skazanego na poraĔkö. Warto siö z tego cieszyè.

Poza praktyki Kierowaäem kiedyĈ zespoäem programistycznym w czasie projektu z „agresywnym harmonogramem”. Dla doĈwiadczonych programistów ta nazwa to oznaka bliskiej katastrofy. Harmonogram poĈrednio wymagaä od zespoäu poĈwiöcenia Ĕycia osobistego w próbie osiñgniöcia nieosiñgalnego. Jeszcze przed rozpoczöciem prac wiedziaäem, Ĕe mamy niewielkie szanse na odniesienie sukcesu. Jednak mimo to podjñäem siö zadania, wiedzñc, Ĕe moĔemy przynajmniej szybko wykryè niepowodzenie. To byä bäñd. Nie powinienem byä zakäadaè takiej moĔliwoĈci. PoniewaĔ oznaki zagroĔenia projektu byäy wyraĒne, pierwszym zadaniem byäo zebranie dodatkowych informacji. PrzeprowadziliĈmy trzy dwutygodniowe iteracje i przygotowaliĈmy plan wydaþ. SzeĈè tygodni po rozpoczöciu projektu ustaliliĈmy wiarygodnñ datö wydania. Pokazywaäa, Ĕe bödziemy bardzo spóĒnieni. MyĈlaäem, Ĕe to dobra wiadomoĈè — podröcznikowy przykäad szybkiego wykrycia niepowodzenia. PrzeprowadziliĈmy eksperyment, który potwierdziä nasze obawy, dlatego przyszäa pora na podjöcie dziaäaþ: zmianö zakresu projektu, zmianö daty wydania lub anulowanie prac. MieliĈmy doskonaäñ okazjö do przeksztaäcenia potencjalnego niepowodzenia w sukces, co wymagaäo albo zmiany planów, albo ograniczenia strat. Niestety, nie przygotowaäem siö na rozwój wypadków. Organizacja nie chciaäa zaakceptowaè moĔliwoĈci poraĔki. Zamiast rozwiñzaè problem, kierownictwo próbowaäo zmusiè zespóä do realizacji wyjĈciowego harmonogramu. Po stwierdzeniu, Ĕe przeäoĔeni nie chcñ zapewniè wsparcia potrzebnego do odniesienia sukcesu, zrezygnowaäem. Kierownictwo naciskaäo na pozostaäych czäonków zespoäu, aby pracowali w nocy i w weekendy (przerodziäo siö to w typowy projekt w stylu „marszów Ĉmierci”), co jednak nie wystarczyäo. Projekt zostaä zrealizowany ze znacznym opóĒnieniem, kilka tygodni wczeĈniej niĔ wedäug prognoz opartych na szybkoĈci, a firma straciäa klienta. PoniewaĔ kultura organizacyjna uniemoĔliwiaäa szybkie wykrywanie niepowodzeþ, projekt byä skazany na powolnñ poraĔkö. 434 ROZDZ AĤ 13

E

M NOWAN E MARNOTRAWSTWA

W jaki sposób zespóä ten mógä odnieĈè sukces? Pod pewnym wzglödem byäo to niemoĔliwe. Nie byäo moĔliwoĈci, aby zrealizowaè projekt zgodnie z wyjĈciowym harmonogramem, zakresem prac i budĔetem. Nie zaskakuje przy tym fakt, Ĕe plany nie byäy powiñzane z szacunkami programistów. Najlepszym rozwiñzaniem byäo szybkie przyznanie siö do poraĔki, a nastöpnym — zmiana planów. Co mogäem zrobiè inaczej? Bäödem byäo przede wszystkim przystñpienie do projektu. Wiedziaäem, Ĕe harmonogram byä nierealistyczny, i zakäadaäem, Ĕe obiektywny dowód wystarczy do przekonania o tym wszystkich. Powinienem byä sprawdziè to zaäoĔenie i — gdyby okazaäo siö nieprawidäowe — zrezygnowaè z prowadzenia projektu. Co mogäa zrobiè inaczej organizacja? Wiele rzeczy. Mogäa przyjñè strategiö stopniowego udostöpniania. Zespóä udostöpniaäby wtedy oprogramowanie po kaĔdej iteracji w nadziei, Ĕe szybciej zapewni wartoĈè klientom. Mogäa ograniczyè zakres pierwszego wydania do moĔliwego do realizacji zestawu funkcji. Mogäa teĔ zwiökszyè dostöpne zasoby (do pewnego poziomu), aby umoĔliwiè wzrost szybkoĈci. Niestety, organizacja ta nie potrafiäa pogodziè siö z niepowodzeniem, co uniemoĔliwiäo zmianö planów. Organizacje, które potrafiñ przyznaè siö do poraĔki, mogñ wprowadziè zmiany w projektach. Paradoksalnie przyznanie siö do niepowodzenia umoĔliwia przeksztaäcenie potencjalnej poraĔki w sukces.

Maksymalizacja liczby zadaħ, których nie trzeba wykonywaë UĔytkownicy zwinnego podejĈcia twierdzñ, Ĕe „prostota to sztuka maksymalizacji liczby zadaþ, których nie trzeba wykonywaè”. To zagadnienie jest kluczowe w eliminowaniu marnotrawstwa. Aby proces byä bardziej zwinny, naleĔy wykonywaè mniej zadaþ. Jednak nie moĔna zanadto uszczupliè procesu, aby nie przestaä funkcjonowaè. Jak powiedziaä Albert Einstein: „Wszystko powinno byè tak proste, jak to moĔliwe, ale nie bardziej”. Czösto oznacza to podejĈcie do pracy w nowy sposób. Upraszczanie procesu czasem oznacza rezygnacjö z formalnych struktur przy jednoczesnym zwiökszeniu rygoru. Na przykäad elegancki dowód matematyczny zapisany na odwrocie serwetki moĔe byè rygorystyczny, ale jest nieformalny. TakĔe wspólna praca z klientami zmniejsza iloĈè formalnej dokumentacji wymagaþ, a przy tym znaczñco zwiöksza moĔliwoĈè ich zrozumienia. Rozwiñzania opierajñ siö na informacjach zwrotnych, komunikacji, samodyscyplinie i zaufaniu. Informacje zwrotne i bezpoĈrednia komunikacja zmniejszajñ potrzebö tworzenia poĈrednich materiaäów. Samodyscyplina pozwala czäonkom zespoäu pracowaè bez ograniczeþ formalnymi strukturami. Dziöki zaufaniu nie trzeba czekaè caäych dni — lub jeszcze däuĔej — na formalne zatwierdzenie. Ograniczanie praktyk do rzetelnego minimum i usuwanie wñskich gardeä pozwala pracowaè bez obciñĔeþ. Dziöki temu moĔna zmaksymalizowaè czas poĈwiöcany na rozwój oprogramowania gotowego do udostöpnienia i lepiej skoncentrowaè siö na tym, co naprawdö waĔne.

MAKSYMA

ZACJA

CZBY ZADAĦ

KTÓRYCH N E TRZEBA WYKONYWAê 435

Praktyki XP dynamicznie eliminuje marnotrawstwo w wiökszym stopniu, niĔ jakakolwiek inna znana mi metoda. To wäaĈnie sprawia, Ĕe podejĈcie XP jest ekstremalne. PoniewaĔ zespoäy stosujñce XP pracujñ wspólnie i komunikujñ siö bezpoĈrednio, poĈrednie dokumenty z wymaganiami nie sñ im potrzebne. W XP, dziöki Ĉcisäej wspóäpracy miödzy programistami i stopniowemu rozwojowi projektu, moĔna zrezygnowaè z pisanych dokumentów przedstawiajñcych projekt. Ponadto XP eliminuje marnotrawstwo, poniewaĔ niektóre praktyki majñ liczne funkcje. Na przykäad oczywistñ korzyĈciñ programowania w parach jest nieustanny przeglñd kodu, jednak praktyka ta rozpowszechnia takĔe wiedzö wĈród czäonków zespoäu, sprzyja samodyscyplinie i zmniejsza wpäyw czynników rozpraszajñcych. WspóäwäasnoĈè kodu nie tylko umoĔliwia stopniowy rozwój projektu i architektury, ale teĔ sprawia, Ĕe nie trzeba marnowaè czasu w oczekiwaniu na wprowadzenie niezbödnych zmian w interfejsie API przez inne osoby.

Poza praktyki W niektórych organizacjach niezbödnym wymogiem konkurencyjnym jest uzyskanie certyfikatu ISO 9001. Pomagaäem jednej z takich firm w rozwoju oprogramowania do sterowania nowoczesnym sprzötem. Byä to pierwszy projekt rozwijany w tej firmie z wykorzystaniem XP, dlatego musieliĈmy ustaliè, jak dopasowaè do tej metody standard ISO 9001. TrudnoĈè stanowiäo wprowadzenie XP bez marnowania czasu na zbödne procedury zwiñzane z dokumentacjñ. W zespole nie byäo eksperta od standardu ISO 9001, dlatego najpierw poprosiliĈmy o pomoc jednego z wewnötrznych audytorów firmy (byä to przykäad zastosowania zasady „Odpowiednie osoby do odpowiednich zadaþ” opisanej w rozdziale 12.). DowiedzieliĈmy siö od niego, Ĕe ISO 9001 nie wymaga zastosowania Ĕadnego konkretnego procesu. WaĔne jest, aby prowadziä do osiñgniöcia okreĈlonych celów, Ĕeby zespóä mógä udowodniè, iĔ stosuje dany proces i przestrzega go. Zapewniäo to nam niezbödnñ elastycznoĈè. Aby nie komplikowaè procesu, wykorzystaliĈmy istniejñce praktyki i dostosowaliĈmy je do zasad standardu ISO 9001. Zamiast tworzyè däugñ dokumentacjö wymagaþ i plany testów w celu udowodnienia, Ĕe starannie przetestowaliĈmy produkt, zmodyfikowaliĈmy pod tym kñtem uĔywanñ praktykö testów klienta. Testy te nie tylko jednoznacznie demonstrowaäy, Ĕe oprogramowanie wykonuje niezbödne funkcje, ale teĔ pokazywaäy, iĔ przestrzegaliĈmy wewnötrznych procesów.

DéŜenie do wysokiej przepustowoļci Ostatnie Ēródäo marnotrawstwa nie jest oczywiste. Przemysä wytwórczy nazywa je magazynem. W rozwoju oprogramowania jest to nieudostöpnione oprogramowanie. W obu przypadkach sñ to czöĈciowo gotowe produkty, których przygotowanie pochäonöäo pewne koszty, ale które nie przyniosäy jeszcze Ĕadnych zysków.

436 ROZDZ AĤ 13

E

M NOWAN E MARNOTRAWSTWA

CzöĈciowo wykonane produkty to niezrealizowane inwestycje. Jest to marnotrawstwo w postaci kosztów niewykorzystania moĔliwoĈci, poniewaĔ inwestycja nie zapewniäa jeszcze zysków, a poĈwiöconych na niñ zasobów nie moĔna spoĔytkowaè gdzie indziej. CzöĈciowo ukoþczone produkty obniĔajñ teĔ przepustowoĈè, czyli iloĈè czasu miödzy powstaniem pomysäu a przeksztaäceniem go na uĔyteczne oprogramowanie. Niska przepustowoĈè prowadzi do wyĔszego marnotrawstwa. Im däuĔej trwa realizacja pomysäu, tym wiöksze prawdopodobieþstwo, Ĕe zmiana planów doprowadzi do dezaktualizacji niektórych juĔ przygotowanych funkcji. Aby ograniczyè iloĈè czöĈciowo wykonanych produktów i marnotrawstwo zasobów, naleĔy zmaksymalizowaè przepustowoĈè. Trzeba znaleĒè etapy w procesie, na których najwiöcej zadaþ czeka na ukoþczenie. Te etapy to ograniczenia, czyli fragmenty procesu, które okreĈlajñ ogólnñ przepustowoĈè. Wedäug moich doĈwiadczeþ ograniczeniem w projektach rozwoju oprogramowania sñ czösto programiĈci. SzybkoĈè implementacji opowieĈci wyznacza zakres prac pozostaäych czäonków zespoäu. Aby zmaksymalizowaè przepustowoĈè, ograniczenie musi pracowaè z jak najwyĔszñ wydajnoĈciñ, podczas gdy nie jest to niezbödne przy pozostaäych elementach procesu. Aby zminimalizowaè zakres nieukoþczonych prac, czynniki, które nie sñ ograniczeniem, powinny produkowaè tylko tyle materiaäów, ile jest potrzebne czynnikom ograniczajñcym. WyĔsza produkcja prowadzi do wzrostu zalegäoĈci, co z kolei zwiöksza koszty niewykorzystania moĔliwoĈci i prawdopodobieþstwo obniĔenia wydajnoĈci z uwagi na zmiany. Minimalizacja zakresu ukoþczonych prac oznacza, Ĕe wszystkie elementy oprócz czynnika ograniczajñcego muszñ pracowaè poniĔej maksymalnej wydajnoĈci. To dopuszczalne. WydajnoĈè moĔna przenieĈè na inne zadania. Co wiöcej, istotne jest, aby osoby, które nie sñ ograniczeniem, miaäy wolny czas i mogäy reagowaè na potrzeby grupy ograniczajñcej, przyczyniajñc siö do maksymalizacji jej wydajnoĈci.

UWAGA Te pomysäy pochodzñ z ksiñĔki The Theory of Constraints [Goldratt 1997]. Jest to doskonaäe i przystöpne wprowadzenie, w którym moĔna znaleĒè wiöcej informacji na ten temat. Analizy specyficzne dla rozwoju oprogramowania zawiera [Anderson 2003].

Praktyki Planowanie w XP koncentruje siö na wzroĈcie przepustowoĈci i minimalizowaniu zakresu nieukoþczonych prac. Jest to podstawowa cecha struktury iteracji. W kaĔdej z nich idea — opowieĈè — jest realizowana od poczñtku do koþca. Pod koniec iteracji wszystkie opowieĈci muszñ byè „w peäni gotowe”. Charakterystyczny dla XP nacisk na wydajnoĈè programistów — czösto kosztem produktywnoĈci innych czäonków zespoäu — to nastöpny przykäad stosowania tej zasady. Choè przebywanie klientów z zespoäem w peänym wymiarze godzin moĔe prowadziè do niewydajnego wykorzystania ich czasu, zwiöksza wydajnoĈè programistów. JeĈli to programiĈci sñ ograniczeniem (na tym zaäoĔeniu opiera siö XP), takie rozwiñzanie poprawia ogólnñ przepustowoĈè i produktywnoĈè zespoäu.

DèśEN E DO WYSOK EJ PRZEPUSTOWOĻC

437

Poza praktyki W projekcie, przy którym pracowaäem, trudno byäo zrealizowaè termin wydania, dlatego próbowaliĈmy przyspieszyè pracö, zatrudniajñc dodatkowe osoby. W przeciñgu miesiñca zwiökszyliĈmy rozmiar zespoäu z siedmiu do 14, a nastöpnie do 18 programistów. WiökszoĈci nowych pracowników brakowaäo doĈwiadczenia. Jest to bäñd tak stary jak samo oprogramowanie. Fred Brooks w ksiñĔce Brooks’ Law z 1975 roku stwierdziä: „Doäñczenie nowych osób do spóĒnionego projektu rozwoju oprogramowania dodatkowo go opóĒni” [Brooks, s. 25]. We wspomnianym projekcie kierownictwo zignorowaäo protesty przeciw zatrudnianiu nowych osób, dlatego zdecydowaliĈmy siö wytöĔyè wszystkie siäy. Zamiast zachöcaè wszystkich do pracy z jak najwiökszñ wydajnoĈciñ, skoncentrowaliĈmy siö na maksymalizacji przepustowoĈci. ZaczöliĈmy od zwiökszenia poczñtkowego zespoäu programistycznego — „grupy gäównej” — w niewielkim stopniu, o tylko jednñ osobö. Pozostaäych szeĈciu nowych programistów stanowiäo „siäy szybkiego reagowania”. Ich zadaniem nie byäa praca nad oprogramowaniem produkcyjnym, ale usuwanie przeszkód na drodze „grupy gäównej”. Co kilka tygodni zamienialiĈmy jednñ lub dwie osoby w skäadzie obu grup w celu wymiany informacji. To rozwiñzanie dziaäaäo dobrze. PracowaliĈmy nad odziedziczonym projektem, dlatego rozwój byä utrudniany przez wiele przeszkód. Jednym z pierwszych problemów rozwiñzanych przez „siäy szybkiego reagowania” byäo naprawienie skryptu kompilacji, który czösto zawodziä z powodu problemów z rejestrem systemu Windows lub blokowaniem bibliotek DLL. Naprawiajñc ten problem, „siäy szybkiego reagowania” umoĔliwiäy bardziej päynnñ pracö „grupie gäównej”. PóĒniej musieliĈmy doäñczyè do zespoäu czterech niedoĈwiadczonych programistów. W tym momencie w pomieszczeniu brakowaäo juĔ miejsca. Z braku lepszych rozwiñzaþ umieĈciliĈmy nowych programistów w wolnym pokoju dwa piötra od nas. Nadal koncentrowaliĈmy siö na utrzymaniu wysokiej przepustowoĈci. PoniewaĔ nie chcieliĈmy przeszkadzaè w pracy doĈwiadczonym programistom, zostawiliĈmy ich w „grupie gäównej”, a poniewaĔ „siäy szybkiego reagowania” dziaäaäy dobrze, zdecydowaliĈmy siö utrzymywaè nowy zespóä z dala od gäównej areny wydarzeþ. Celowo zlecaliĈmy im mniej istotne zadania, aby nie zakäócali pracy reszty zespoäu. PodejĈcie to okazaäo siö doĈè skuteczne. Dziöki koncentracji na przepustowoĈci, a nie na wydajnoĈci poszczególnych osób, udaäo nam siö przetrwaè zmiany. Zespóä rozrósä siö ponad dwukrotnie i to przede wszystkim o niedoĈwiadczonych programistów, a mimo to produktywnoĈè nie spadäa. Choè wydajnoĈè nie podniosäa siö, taki napäyw nowych osób zwykle prowadzi do caäkowitego zastoju. W tym rozwiñzaniu dñĔenie do maksymalizacji przepustowoĈci umoĔliwiäo utrzymanie szybkoĈci pracy. W bardziej korzystnych warunkach — przy mniejszej liczbie nowych programistów lub przy programistach z wiökszym doĈwiadczeniem — produktywnoĈè prawdopodobnie wzrosäaby.

438 ROZDZ AĤ 13

E

M NOWAN E MARNOTRAWSTWA

ROZDZIAĤ 14

Zapewnianie wartoļci

Oprogramowanie zaczyna mieè prawdziwñ wartoĈè dopiero wtedy, kiedy trafia do uĔytkowników. Dopiero od tego momentu zespóä zaczyna wzbudzaè zaufanie, otrzymuje informacje zwrotne najwaĔniejszego typu i zapewnia godziwy zwrot z inwestycji. Dlatego w udanych projektach prowadzonych zwinnymi metodami oprogramowanie udostöpniane jest wczeĈnie, czösto i wielokrotnie.

Wykorzystanie zwinnoļci Prostota kodu i procesu sñ atrakcyjne estetycznie. Jednak jest waĔniejszy powód, który pomaga tworzyè doskonaäe oprogramowanie przy uĔyciu zwinnego podejĈcia: pozwala ono dostrzegaè i wykorzystywaè nowe moĔliwoĈci. Gdyby zespóä potrafiä okreĈliè co do godziny czas trwania projektu, przewidzieè zagroĔenia i caäkowicie wyeliminowaè wszelkie niespodzianki, zwinnoĈè nie byäaby potrzebna. Sukces byäby wtedy moĔliwy przy uĔyciu dowolnej metody rozwoju. Jednak to, co niewiadome, ekscytuje. Nowy kryzys lub szczöĈliwe odkrycie mogñ caäkowicie zmieniè warunki rozwoju. MoĔliwe, Ĕe zespóä wykryje doskonaäñ nowñ technikö, która uproĈci kod, a klient rozwinie nowe praktyki biznesowe, oszczödzajñce czas i pieniñdze. Co ma zrobiè firma, kiedy chce udostöpniè prawdziwie wartoĈciowy produkt? Wykorzystaè to, czego siö nauczyäa, i na tej podstawie zmieniè kierunek prac. Zmiana nastawienia na pozytywny odbiór zmian w wymaganiach daje wielkie moĔliwoĈci. Zapewnianie klientom wartoĈci to najwaĔniejsze zadanie. Dynamiczne uwzglödnianie informacji zwrotnych od klientów, prawdziwych uĔytkowników, czäonków zespoäu i z samego kodu tak wczeĈnie i czösto, jak to moĔliwe, umoĔliwia ciñgäñ naukö i coraz lepsze zrozumienie projektu. Pozwala to takĔe odkryè nowe moĔliwoĈci, kiedy siö pojawiñ. ZwinnoĈè wymaga pracy w maäych krokach, a nie wielkich skokach. Prawidäowo wykorzystane niskie poczñtkowe nakäady w czasie i zasobach zaczynajñ natychmiast dawaè mierzalnñ wartoĈè. Ponadto wprowadzanie drobnych zmian sprawia, Ĕe sñ one äatwiejsze. Jest to najbardziej oczywiste, kiedy klienci opisujñ wymagania na bardzo wysokim poziomie ogólnoĈci, za pomocñ opowieĈci, które wymagajñ doprecyzowania w trakcie rozwoju. 439

Dynamiczne poszukiwanie informacji zwrotnych i praca w maäych krokach umoĔliwiajñ odroczenie inwestycji do ostatniego momentu na podjöcie zobowiñzaþ. WartoĈè fragmentu produktu jest wtedy widoczna od poczñtku, a producent nie musi tylko Ĕywiè nadziei na korzyĈci w odlegäej przyszäoĈci.

Praktyki W XP zwinnoĈè säuĔy do skracania czasu miödzy podjöciem dziaäaþ a zaobserwowaniem ich efektów. Uäatwia to naukö na podstawie informacji zwrotnych. Jest to szczególnie widoczne, kiedy caäy zespóä pracuje wspólnie. Rozwój funkcji w bezpoĈredniej bliskoĈci przedstawicieli klientów pozwala wyjaĈniè nieporozumienia i zapewnia niemal natychmiastowe odpowiedzi na zadane pytania. Wäñczenie prawdziwych klientów w proces obejmujñcy czöste udostöpnianie oprogramowania pozwala zademonstrowaè im jego wartoĈè. W XP, dziöki krótkim cyklom pracy, moĔliwe sñ czöste zmiany przedmiotu koncentracji. Równolegäe etapy umoĔliwiajñ niemal natychmiastowe wykorzystanie nowej wiedzy w praktyce, bez koniecznoĈci oczekiwania na nastöpnñ fazö zbierania wymagaþ, testowania lub rozwoju zaplanowanñ w harmonogramie. Krótkie jednostki pracy — obejmujñce iteracje, czöste demonstracje i wydania — tworzñ stabilny rytm, umoĔliwiajñcy precyzyjne dopracowanie procesu. Zapas w iteracji zapewnia wolny czas na wprowadzanie drobnych, ale niezbödnych zmian bez koniecznoĈci dokonywania trudnych wyborów dotyczñcych rezygnacji z podstawowych zadaþ.

Poza praktyki Pracowaäem kiedyĈ w maäej, poczñtkujñcej firmie, której gäównym produktem byä system zarzñdzania magazynem przeznaczony dla konkretnej gaäözi handlu. Zakupem tego oprogramowania zainteresowani byli czoäowi handlowcy i producenci. Brakowaäo nam kilku miesiöcy do zakoþczenia prac, kiedy najwiökszy klient popadä w problemy. Wygasäa licencja na ich obecny system do obsäugi punktów sprzedaĔy. To oprogramowanie obejmowaäo system kontrolny, który przed uruchomieniem aplikacji komunikowaä siö z producentem. PlanowaliĈmy utworzyè wäasny system do obsäugi punktów sprzedaĔy, który jednak miaä byè gotowy najwczeĈniej za kilka miesiöcy. Obecny system säuĔyä do zarzñdzania magazynem, jednak nie przeprowadziliĈmy analiz dotyczñcych obsäugi terminali róĔnego typu, skanerów kart kredytowych i drukarek rachunków. Byä to nasz najwiökszy klient, a jego bankructwo oznaczaäo naszñ poraĔkö. Po omówieniu z klientem moĔliwoĈci i wymagaþ projektowych zdecydowaliĈmy, Ĕe w ciñgu szeĈciu tygodni ukoþczymy czöĈè systemu wystarczajñcñ do obsäugi punktów sprzedaĔy, dziöki czemu klient bödzie mógä wdroĔyè nasze oprogramowanie i uniknñè päacenia 30 000 dolarów innemu producentowi. MieliĈmy duĔo szczöĈcia, poniewaĔ nasi inni klienci nie wymagali od nas w tym okresie intensywnej pracy. Dwie trzecie zespoäu zajöäo siö rozwojem systemu do obsäugi punktów sprzedaĔy. Choè zaczöliĈmy od gotowego projektu o otwartym dostöpie do kodu Ēródäowego, musieliĈmy znacznie go zmodyfikowaè.

440 ROZDZ AĤ 14

ZAPEWN AN E WARTOĻC

Po dwóch tygodniach pracy udostöpniliĈmy efekty pierwszej iteracji na nowej maszynie, którñ przygotowaliĈmy dla klienta na potrzeby testów. Tydzieþ póĒniej udostöpniliĈmy oprogramowanie. Choè wymagaäo to ciöĔkiej pracy, stopniowo dodawaliĈmy nowe funkcje dostosowane do sposobu dziaäania odbiorcy. Na koþcu jedynym zadaniem byäa zmiana kilku wierszy w konfiguracji graficznego interfejsu uĔytkownika, aby dostosowaè kolory do wystroju sklepów. ZaoszczödziliĈmy klientom wiele pieniödzy, a takĔe uratowaliĈmy stan naszego konta.

Wartoļë ma tylko kod gotowy do udostýpnienia Utworzenie najlepszego, najpiökniejszego kodu na Ĉwiecie jest maäo istotne, jeĈli nie wykonuje on operacji oczekiwanych przez klienta. Prawdñ jest teĔ, Ĕe kod w peäni speäniajñcy potrzeby uĔytkownika jest maäo wartoĈciowy, jeĈli klient nie moĔe go uĔyè. Dopóki oprogramowanie nie trafi do osób, które go potrzebujñ, ma tylko potencjalnñ wartoĈè. Zapewnienie wartoĈci wymaga udostöpnienia prawdziwego oprogramowania. Kod, którego nie moĔna udostöpniè, nie ma wartoĈci. Dziaäajñce oprogramowanie to podstawowa miara postöpów. W kaĔdym momencie powinno byè moĔliwe zatrzymanie projektu i uzyskanie wartoĈci proporcjonalnej do inwestycji poniesionych na rozwój danego oprogramowania. KaĔdy zespóä moĔe zmieniè obiekt koncentracji w ciñgu tygodnia lub miesiñca, jednak czy potrafi zrobiè to, zachowujñc moĔliwoĈè regularnego udostöpniania oprogramowania? Czy naprawdö koþczy kod — czy „gotowe” oznacza „w peäni gotowe” — czy raczej tworzy coraz wiökszñ iloĈè czöĈciowo ukoþczonego kodu? Czy projekt jest gotowy do udostöpnienia w kaĔdym momencie? ZwinnoĈè i elastycznoĈè to wspaniaäe cechy, zwäaszcza kiedy poäñczyè je z iteracyjnym, stopniowym rozwojem. DuĔe znaczenie ma tu przepustowoĈè. Nie tylko zmniejsza iloĈè usuwanego kodu i marnotrawstwo, ale teĔ zapewnia duĔo lepsze informacje zwrotne i to nie tylko w obszarze jakoĈci kodu. Wyäñcznie kod, który moĔna udostöpniè klientom, pozwala uzyskaè informacji zwrotne na temat tego, w jakim stopniu rozwiñzanie zapewnia klientom wartoĈè. Takie informacje zwrotne sñ nieocenione.

Praktyki NajwaĔniejsza praktyka zwiñzana z tym zagadnieniem to „w peäni gotowe”, zgodnie z którñ kod jest albo kompletny, albo niekompletny. Ta jednoznaczna miara postöpów bäyskawicznie informuje zespóä o stanie prac. Wytwarzanie sterowane testami zapewnia „siatkö bezpieczeþstwa”, która wychwytuje regresjö i odstöpstwa od wymagaþ klientów. Dobrze przygotowany pakiet testów pozwala szybko wykryè wszelkie usterki, które mogäyby zmniejszyè wartoĈè oprogramowania. Z kolei ciñgäa integracja umoĔliwia upewnienie siö kilka razy w ciñgu dnia, Ĕe projekt dziaäa jako caäoĈè. Dziöki temu zespóä wykrywa wszelkie pomyäki lub wypadki szybko, bezpoĈrednio po ich wystñpieniu, kiedy najäatwiej je naprawiè. Dziesiöciominutowa kompilacja usuwa wñskie gardäa w tym procesie, dziöki czemu cykle sñ czöstsze.

WARTOĻê MA TY KO KOD GOTOWY DO UDOSTüPN EN A 441

Praktyka „brak bäödów” skutecznie przypomina, Ĕe odkäadanie waĔnych i konkretnych decyzji zmniejsza wartoĈè projektu. Jest to istotne przede wszystkim przy decyzjach opartych bezpoĈrednio na informacjach zwrotnych od prawdziwych klientów.

Poza praktyki Pracowaäem kiedyĈ przy projekcie, który trwaä juĔ od czterech miesiöcy, a do zakoþczenia prac brakowaäo tylko kilku tygodni, kiedy nagle zostaä przerwany. „Znacznie przekroczyliĈmy budĔet, ale nie zauwaĔyliĈmy tego” — powiedziaä menedĔer. „Jutro wszyscy majñ wróciè do domów”. Wszyscy pracowaliĈmy na kontrakcie, jednak tak nagäe anulowanie projektu zaskoczyäo nas. Zostaäem w firmie jeszcze przez tydzieþ, aby przeszkoliè jednego z pracowników — „Joego” — na wypadek, gdyby organizacja w przyszäoĈci miaäa moĔliwoĈè ponownej pracy nad kodem. Choè nie byä to projekt rozwijany z wykorzystaniem XP, dzieliliĈmy pracö na iteracje. Nie instalowaliĈmy Ĕadnych wydaþ iteracji (teraz wiem, Ĕe byäby to dobry pomysä), jednak efekty ostatniej iteracji byäy gotowe do wdroĔenia. Zrobiäem to wraz z Joe’em, a nastöpnie poĈwiöciäem resztö tygodnia na naprawö kilku znanych bäödów. Byäby to podröcznikowy przykäad dobrego zarzñdzania projektem, gdyby nie jeden problem: wydanie nie nadawaäo siö do uĔytku. PracowaliĈmy nad funkcjami wedäug ich priorytetów, ale klienci okreĈlili je nieprawidäowo! Funkcja, którñ opisali jako najmniej istotnñ w pierwszym wydaniu, byäa tak naprawdö krytyczna. Byäy to zabezpieczenia. Jednak znajdowaäy siö ona na koþcu listy, dlatego nie zaimplementowaliĈmy odpowiednich mechanizmów. GdybyĈmy zainstalowali wydanie poĈrednie, wykrylibyĈmy ten problem. Jednak nie pomyĈleliĈmy o tym, a firma otrzymaäa bezwartoĈciowy produkt. Na szczöĈcie kilka miesiöcy póĒniej organizacja ponownie nas zatrudniäa i dokoþczyliĈmy aplikacjö.

Zapewnianie wyników biznesowych Co by siö staäo, gdyby zespóä mógä najlepiej speäniè potrzeby klienta bez pisania oprogramowania? Czy zdecydowaäby siö na to? Czy byäoby to moĔliwe? KtóregoĈ dnia moĔe siö to przytrafiè kaĔdemu zespoäowi. MoĔe nie bödzie to tak trudne jak poinformowanie staäego klienta o tym, Ĕe uzyska lepsze efekty bez oprogramowania, jednak grupa moĔe stanñè przed wyborem udostöpnienia kodu lub zapewnienia wyników biznesowych. WartoĈè nie wynika tylko z oprogramowania. Celem jest zapewnienie wartoĈci klientowi, a oprogramowanie to tylko Ĉrodek. NajwaĔniejszym kryterium powodzenia jest dostosowanie projektu do celów biznesowych. Wszystko inne jest drugorzödne — oczywiĈcie nie bezuĔyteczne, ale mniej istotne. Na przykäad zwinne zespoäy ceniñ dziaäajñce oprogramowanie bardziej niĔ wyczerpujñcñ dokumentacjö. Dokumentacja jest wartoĈciowa, poniewaĔ przekazywanie informacji o tym, co oprogramowanie ma robiè i jak, jest cenne, jednak gäównym priorytetem jest speänianie potrzeb klientów. Czasem wymaga to przygotowania dobrej dokumentacji, a zwykle udostöpnienia dobrego oprogramowania, jednak nie zawsze tak siö dzieje. Podstawowym celem zawsze jest zapewnianie jak najlepszych wyników biznesowych. 442 ROZDZ AĤ 14

ZAPEWN AN E WARTOĻC

Praktyki XP zachöca do Ĉcisäej wspóäpracy z prawdziwymi klientami i wäñczania ich do zespoäu, dziöki czemu mogñ kaĔdego dnia oceniaè postöpy i podejmowaè decyzje na podstawie wartoĈci dla firmy. ZaangaĔowanie prawdziwych klientów umoĔliwia przedstawicielom klientów przeglñd tych wartoĈci z uĔytkownikami koþcowymi i utrzymanie odpowiedniego kierunku prac. Wizja klientów daje odpowiedzi na najwaĔniejsze pytania dotyczñce projektu. W XP harmonogram jest przygotowywany z perspektywy wartoĈci dla klientów. Zespóä pracuje nad opowieĈciami utworzonymi z punktu widzenia klienta i moĔliwymi do sprawdzenia przez testy klienta. Po kaĔdej iteracji zespóä przeprowadza jej demonstracjö, aby przedstawiè postöpy udziaäowcom, którzy mogñ oceniè, czy wyniki sñ wartoĈciowe, oraz zdecydowaè o kontynuacji prac.

Poza praktyki Znajomy — „Aaron” — niedawno poĈwiöciä miesiñc roboczy na napisanie 1500 wierszy kodu prototypu, który w wyniku pierwszej demonstracji zapewniä mu przychód w wysokoĈci 7,8 miliona dolarów. Na ostatnim roku studiów Aaron braä udziaä w praktykach w firmie technologicznej, gdzie prowadziä badania nad rozpoznawaniem pisma röcznego przy uĔyciu piór cyfrowych wyposaĔonych w sensory i rejestratory. Klient wspomniaä o tym, Ĕe bardzo przydatna byäaby moĔliwoĈè uĔywania takich specjalnych piór do obsäugi drukowanych map. Wtedy Aaron otrzymaä zadanie badawcze. Najwiökszy potencjalny klient uĔywaä istniejñcego pakietu oprogramowania do przesyäania danych z mapy do agentów w celu wyznaczania drogi podróĔy i punktów orientacyjnych. Aaron zmodyfikowaä oprogramowanie pióra, aby przesyäaäo informacje o wspóärzödnych widocznych na mapie. Nastöpnie znalazä sposób na zakodowanie na wydrukach z kolorowej drukarki laserowej danych niezbödnych do kalibracji pióra. Ostatni etap polegaä na wykorzystaniu interfejsu API oprogramowania klienta do przekazywania informacji o specjalnych zdarzeniach wykonywanych przy uĔyciu pióra: oznaczaniu punktów orientacyjnych, okreĈlaniu drogi podróĔy itd. Kod ten umoĔliwiaä zastñpienie niewygodnego interfejsu uĔytkownika opartego na myszy czynnoĈciñ rysowania po mapie na niestandardowym wydruku. Nastöpnie wystarczyäo umieĈciè pióro w stacji dokujñcej. Po kilku minutach od rozpoczöcia demonstracji klient poprosiä przedstawiciela handlowego o pokazanie testów polowych w centrali. Po zainstalowaniu oprogramowania i podäñczeniu stacji dokujñcej przedstawiciel wröczyä pióro i wydrukowanñ mapö jednemu z techników. Pracownik ten nigdy wczeĈniej nie widziaä tego produktu i nie przeszedä szkoleþ, jednak bäyskawicznie zakreĈliä cel na mapie i umieĈciä pióro w stacji dokujñcej. Po kilku sekundach cel pojawiä siö na wyĈwietlaczach pojazdów, a takĔe na palmtopach przedstawicieli. Klient zamówiä licencjö i sprzöt dla wszystkich pracowników placówki. To wäaĈnie sñ wyniki biznesowe.

ZAPEWN AN E WYN KÓW B ZNESOWYCH 443

Czýste udostýpnianie JeĈli zespóä ma problem biznesowy, duĔo cenniejsze jest udostöpnienie rozwiñzania dziĈ niĔ za szeĈè miesiöcy, zwäaszcza gdy bödzie to to samo rozwiñzanie. WartoĈè nie opiera siö tylko na przygotowaniu produktu przydatnego klientowi. Trzeba to zrobiè wtedy, kiedy klient tego potrzebuje. Czöste udostöpnianie dziaäajñcego, wartoĈciowego oprogramowania podnosi jego wartoĈè. Jest to szczególnie widoczne, kiedy prawdziwy klient od poczñtku prac nad projektem dñĔy do realizacji najbardziej wartoĈciowych opowieĈci. Wczesne udostöpnienie dziaäajñcego oprogramowania umoĔliwia wykorzystanie dwóch istotnych pötli informacji zwrotnych. Jedne päynñ od prawdziwych klientów do programistów. Klienci uĔywajñ oprogramowania i informujñ, jak dobrze speänia ich potrzeby. Drugie päynñ od zespoäu do klientów. Komunikaty zespoäu majñ pokazaè jego wiarygodnoĈè i moĔliwoĈci. Czöste udostöpnianie zacieĈnia te pötle. Klienci widzñ, Ĕe ich zaangaĔowanie w proces jest naprawdö waĔne. ProgramiĈci zauwaĔajñ, Ĕe pomagajñ prawdziwym ludziom rozwiñzywaè rzeczywiste problemy. NajwyĔszy priorytet w rozwoju oprogramowania ma czöste i ciñgäe dostarczanie wartoĈci oraz zapewnianie tym samym satysfakcji klienta. Takie postöpowanie prowadzi do sukcesów.

Praktyki Po wykryciu prawdziwych potrzeb klienta i czynników, które zapewniajñ wartoĈè oprogramowania, naleĔy wykorzystaè techniczne praktyki umoĔliwiajñce szybkie i czöste udostöpnianie rozwiñzania. Dziöki krótkim iteracjom harmonogram zawiera maäo pozycji i jest wykonalny. Wynika to z podziaäu caäego projektu na jednotygodniowe cykle, wieþczone udostöpnianym projektem, który zespóä przedstawia w czasie demonstracji iteracji. UmoĔliwia to udostöpnianie oprogramowania raz w tygodniu, a czasem nawet czöĈciej. Zdyscyplinowane przestrzeganie zasady „w peäni gotowe” pozwala zachowaè odpowiedni kierunek prac, poniewaĔ pomaga ustaliè, ile pracy zespóä ukoþczyä i ile moĔe jeszcze wykonaè, a przy tym przypomina o dñĔeniu do wysokiej przepustowoĈci. Konserwacja dziesiöciominutowej kompilacji prowadzi do ograniczania lub usuwania zbödnych technicznych wñskich gardeä przy tworzeniu wydania. Im mniej pracy i frustracji, a im wiöcej automatyzacji, tym äatwiej udostöpniè ĈwieĔo przetestowanñ i dziaäajñcñ nowñ kompilacjö.

Poza praktyki Cal Henderson1, twórca Flickra, witryny internetowej do wspóädzielenia zdjöè, poinformowaä mnie, Ĕe od samego poczñtku prac nad tñ aplikacjñ stosowano czöste udostöpnianie. Nikt nie podjñä takiej decyzji, a wynikaäo to po prostu ze sposobu pracy twórców tej witryny. Zamiast tworzyè pakiety nowych funkcji, udostöpniali mechanizmy uĔytkownikom tak szybko, jak byäo to moĔliwe. Pomogäo to uproĈciè rozwój i zmniejszyäo koszty naprawiania bäödów. Poczñtkowo rozwój witryny Flickr odbywaä siö doĈè nieformalnie. Kiedy tylko trzy osoby pracowaäy nad projektem, ustalenie, czy äñcze jest gotowe do rozpoczöcia instalacji, wymagaäo 1

Informacje prywatne.

444 ROZDZ AĤ 14

ZAPEWN AN E WARTOĻC

zapytania o to tylko dwóch innych osób. Obecnie zespóä zakäada, Ĕe äñcze zawsze umoĔliwia wdroĔenie kodu na dziaäajñcej witrynie. NajwaĔniejszy element procesu to grupa solidnych i odpowiedzialnych programistów, którzy doceniajñ moĔliwoĈè zarzñdzania, pisania kodu, testowania, tworzenia pokazów i wdraĔania funkcji. Pozostaäe elementy pracy opierajñ siö na standardowym zwinnym podejĈciu — pracy w krótkich cyklach, rygorystycznych testach, natychmiastowej naprawie bäödów i czöstym podejmowaniu niewielkiego ryzyka. Daje to doskonaäe efekty. Kiedy uĔytkownik umieĈci na forum informacje o bäödzie, zespóä czösto potrafi rozwiñzaè problem i zainstalowaè nowy kod na dziaäajñcej witrynie w przeciñgu kilku minut. Nie trzeba czekaè na ukoþczenie nowych funkcji przez inne osoby. Jest to teĔ zaskakujñco maäo ryzykowne. Jak stwierdziä Henderson: „Liczba powaĔnych poprawek w kodzie bazowym witryny Flickr wciñĔ wynosi zero”.

CZüSTE UDOSTüPN AN E 445

446 ROZDZ AĤ 14

ZAPEWN AN E WARTOĻC

ROZDZIAĤ 15

DéŜenie do doskonaĥoļci technicznej

Lubiö logiczne schematy i struktury. Kiedy zastanawiam siö nad doskonaäoĈciñ technicznñ, nie mogö powstrzymaè siö od myĈli: „Jakie sñ intelektualne podstawy projektu? Co to znaczy, Ĕe projekt jest dobry?”. Niestety, wiele analiz na temat „dobrych” projektów dotyczy specyficznych technik. Czösto analizy te opierajñ siö na zaäoĔeniu, Ĕe dana technologia jest lepsza od innych lub Ĕe bogate obiektowe modele dziedziny, procedury skäadowane albo architektury oparte na usäugach sñ bezwzglödnie korzystne. Przy tak wielu sprzecznych opiniach na temat tego, co jest w oczywisty sposób dobre, jedna rzecz jest pewna: nie jest to wcale takie oczywiste. Niektóre osoby uwaĔajñ, Ĕe dobry projekt jest elegancki lub äadny. UwaĔajñ, Ĕe ma Nienazwanñ cechö (ang. Quality Without a Name — QWAN), która wiñĔe siö z nieokreĈlonym poczuciem prawidäowoĈci projektu. To pojöcie zostaäo wymyĈlone przez Christophera Alexandra, architekta z dziedziny budownictwa, którego przemyĈlenia na temat wzorców doprowadziäy do prac nad wzorcami w oprogramowaniu. Podchodzö z sympatiñ do QWAN. W dobrym projekcie jest Prawda i Piökno. Jest jednak pewien problem. QWAN z mojej perspektywy jest czymĈ zupeänie innym niĔ z punktu widzenia innej osoby. Moje Prawda i Piökno dla kogoĈ innego mogñ byè Faäszem i OkropnoĈciñ. Moje cudowne modele dziedziny sñ brzydsze od procedur skäadowanych innego programisty lub na odwrót. QWAN jest po prostu zbyt nieokreĈlona. Potrzebna jest lepsza definicja dobrego projektu.

Oprogramowanie nie istnieje Pozwolö sobie na maäñ dygresjö: oprogramowanie nie istnieje. MoĔe przesadzam, ale tylko trochö. Kiedy uĔytkownik uruchamia program, komputer wczytuje däugi szereg pól magnetycznych z dysku twardego i przeksztaäca je na pojemnoĈè w pamiöci RAM. Tranzystory w procesorze

447

interpretujñ te äadunki, a nastöpnie przesyäajñ wyniki do urzñdzeþ peryferyjnych, na przykäad do karty graficznej. Nastöpne tranzystory, w monitorze, wybiórczo przepuszczajñ Ĉwiatäo przez kolorowe punkty na ekranie. Jednak Ĕaden z tych elementów to nie oprogramowanie. Oprogramowanie to nawet nie jedynki i zera, ale pola magnetyczne, elektrycznoĈè i Ĉwiatäo. Jedyny sposób na utworzenie oprogramowania to przeäñczanie elektrycznych przeäñczników lub uĔycie istniejñcego oprogramowania, aby zrobiäo to za czäowieka. Jednak programiĈci piszñ oprogramowanie, prawda? Tak naprawdö programista pisze bardzo szczegóäowñ specyfikacjö dla programu, który tworzy oprogramowanie dla czäowieka. Ten specjalny program przeksztaäca specyfikacjö na instrukcje maszynowe, a nastöpnie nakazuje systemowi operacyjnemu komputera zapisanie tych instrukcji jako pól magnetycznych na dysku twardym. Kiedy juĔ siö tam znajdñ, moĔna uruchomiè program, skopiowaè go lub udostöpniè. Nietrudno domyĈliè siö puenty. Opisana specyfikacja to kod Ēródäowy. Program, który przeksztaäca tö specyfikacjö na oprogramowanie, to kompilator. Jack Reeves analizuje päynñce z tego wnioski w znanym eseju What is Software Design?1.

Projekt to narzýdzie uĥatwiajéce zrozumienie JeĈli kod Ēródäowy jest projektem, czym jest projekt? Do czego programistom potrzebne sñ diagramy UML, karty CRC i dyskusje przy tablicy? Wszystkie te elementy, nawet kod Ēródäowy, to abstrakcje. Rzeczywiste dziaäanie miliardów ulotnych äadunków elektrycznych jest niewyobraĔalnie skomplikowane, dlatego ludzie muszñ tworzyè uproszczone, zrozumiaäe modele. Niektóre z nich, na przykäad kod Ēródäowy, moĔna przeksztaäciè na jözyk maszynowy. Inne, na przykäad diagramy UML, tego nie umoĔliwiajñ (przynajmniej na razie). KiedyĈ kod Ēródäowy pisano w jözyku asemblerowym. Byäa to bardzo cienka warstwa abstrakcji sprzötu. Programy byäy wtedy duĔo prostsze, jednak jözyk asemblerowy byä trudny do zrozumienia. ProgramiĈci rysowali diagramy przepäywu, aby wizualizowaè projekt. Dlaczego obecnie programiĈci nie uĔywajñ juĔ diagramów przepäywu? PoniewaĔ jözyki programowania sñ duĔo bardziej wyraziste i takie schematy nie sñ potrzebne. MoĔna przeczytaè kod metody i zobaczyè przepäyw sterowania. Przed wprowadzeniem programowania strukturalnego: 1000 1010 1020 1030 1040 1050 1060 1070

1

NS% = (80 - LEN(T$)) / 2 S$ = "" IF NS% = 0 GOTO 1060 S$ = S$ + " " NS% = NS% - 1 GOTO 1020 PRINT S$ + T$ RETURN

http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm.

448 ROZDZ AĤ 15

DèśEN E DO DOSKONAĤOĻC

TECHN CZNEJ

Po wprowadzeniu programowania strukturalnego: public void PrintCenteredString(string text) { int center = (LINE_LENGTH - text.length) / 2; string spaces = ""; for (int i = 0; i < center; i++) { spaces += " "; } Print(spaces + text); }

Przyznajö, nie jest do koþca prawdñ, Ĕe we wspóäczesnych jözykach programowania przepäyw sterowania jest oczywisty. WciñĔ zdarzajñ siö olbrzymie, 1000-wierszowe metody, których nie moĔna zrozumieè bez pomocy szkicu projektu. Jednak jest to zäy projekt, prawda?

Równowaga w projektach Kiedy inĔynierowie z korporacji Boeing projektujñ samolot pasaĔerski, nieustannie muszñ dbaè o zachowanie równowagi miödzy bezpieczeþstwem, poziomem zuĔycia paliwa, liczbñ miejsc i kosztami produkcji. WspóäczeĈni programiĈci rzadko muszñ podejmowaè podobne decyzje. ProgramiĈci z dawnych lat uĔywajñcy jözyka asemblerowego musieli dokonaè trudnego wyboru miödzy wykorzystaniem duĔej iloĈci pamiöci (miejscem) a szybszym dziaäaniem oprogramowania (szybkoĈciñ). Obecnie prawie nigdy nie trzeba przejmowaè siö zachowaniem równowagi miödzy szybkoĈciñ a miejscem. Komputery sñ tak szybkie i majñ tak duĔo pamiöci RAM, Ĕe röczna optymalizacja — niegdyĈ wysoce ceniona — rzadko ma znaczenie. Co wiöcej, komputery sñ obecnie tak szybkie, Ĕe wspóäczesne jözyki programowania marnujñ zasoby uĔywane przy przetwarzaniu. Przy zastosowaniu kompilatora z optymalizacjñ jözyk C jest równie wydajny jak jözyk asemblerowy. W jözyku C++ dodano wyszukiwanie metod wirtualnych, co wymaga czterech bajtów na metodö i dodatkowego poziomu poĈredniego. Java i C# to kompletne jözyki poĈrednie, uruchamiane w maszynie wirtualnej dziaäajñcej w systemie komputera. Jözyk Ruby2 wymaga interpretacji caäego programu przy kaĔdym uruchomieniu! Jest to ogromne marnotrawstwo. Z czego wynika wiöc popularnoĈè platformy Ruby on Rails? Jak moĔliwy byä sukces jözyków Java i C#? Jakie dajñ korzyĈci, Ĕe warto zdecydowaè siö na marnowanie zasobów? Czy wszyscy programiĈci nie powinni uĔywaè jözyka C?

Nienazwana cecha W dobrym projekcie samolotu panuje równowaga miödzy bezpieczeþstwem, liczbñ miejsc, zuĔyciem paliwa a kosztami produkcji. Doskonaäy projekt zapewnia wiöksze bezpieczeþstwo, wiöcej miejsc oraz mniejsze zuĔycie paliwa, i to taniej niĔ projekt konkurencji. Jak wyglñda to przy rozwoju oprogramowania? JeĈli programiĈci nie zapewniajñ równowagi miödzy szybkoĈciñ a miejscem, co robiñ?

2

W wersjach starszych niĔ Ruby 2.

N ENAZWANA CECHA 449

W rzeczywistoĈci jest pewna równowagñ, o którñ trzeba zadbaè. PopularnoĈè jözyków Java, C# i Ruby pokazuje, Ĕe programiĈci czösto wolñ poĈwiöciè zasoby komputera, aby zaoszczödziè sobie czasu i pracy. Niektórzy programiĈci wzdrygajñ siö na myĈl o marnowaniu czasu komputera i pisaniu „powolnych” programów. Jednak poĈwiöcanie tanich zasobów komputera kosztem czasu programistów to mñdra decyzja projektowa. ProgramiĈci to czösto najkosztowniejszy element w rozwoju oprogramowania. JeĈli dobre projektowanie polega na maksymalizacji korzyĈci przy równowaĔeniu kosztów i zysków, a w oprogramowaniu trzeba uwzglödniè przy tym tylko wydajnoĈè maszyny i czas programistów, wtedy definicja „dobrego projektu oprogramowania” staje siö jasna: Dobry projekt oprogramowania minimalizuje czas potrzebny na tworzenie, modyfikowanie i konserwacjö oprogramowania przy zapewnieniu akceptowalnej wydajnoĈci programu. Ponadto aplikacja musi dziaäaè — to nie podlega dyskusji. JeĈli samolot Boeinga nie potrafi lataè, poziom zuĔycia paliwa jest nieistotny. TakĔe projekt oprogramowania musi prowadziè do dziaäajñcej aplikacji.

Doskonaĥy projekt UzaleĔnianie jakoĈci projektu od äatwoĈci konserwacji nie jest nowym pomysäem, jednak ujöcie go w formie powyĔszej definicji prowadzi do ciekawych wniosków:

1. JakoĈè projektu jest zaleĔna od ludzi. ProgramiĈci, nawet o podobnych umiejötnoĈciach, sñ

ekspertami w odmiennych dziedzinach. Projekt wymagajñcy znajomoĈci idiomów jözyka Java moĔe byè niezrozumiaäy dla programisty znajñcego tylko jözyk Perl i na odwrót. PoniewaĔ jakoĈè projektu w tak znacznym stopniu zaleĔy od czasu pracy programistów, jest wysoce zaleĔna od tego, kto zajmuje siö jego realizacjñ. W dobrym projekcie trzeba to uwzglödniè.

2. JakoĈè projektu jest specyficzna z uwagi na zmiany. Oprogramowanie jest czösto projektowane

w taki sposób, aby moĔna byäo wprowadziè specyficzne zmiany. Projekt, który uäatwia pewne modyfikacje, moĔe utrudniaè inne. W naprawdö dobrym projekcie trzeba poprawnie przewidzieè zmiany, które mogñ rzeczywiĈcie siö pojawiè.

3. Czas modyfikowania i konserwowania jest waĔniejszy niĔ czas rozwoju. Powszechnie

wiadomo, Ĕe w wiökszoĈci programów wiöcej czasu pochäania konserwacja niĔ poczñtkowy rozwój. Kiedy uwzglödni siö to, Ĕe nawet w nieudostöpnionym oprogramowaniu czösto trzeba wprowadzaè zmiany w projekcie, znaczenie czasu rozwoju jeszcze bardziej siö zmniejsza. W dobrym projekcie minimalizacja czasu modyfikowania i konserwowania jest waĔniejsza niĔ skracanie czasu rozwoju.

4. JakoĈè projektu jest nieprzewidywalna. Skoro dobry projekt minimalizuje czas pracy

programistów, a to zaleĔy od zatrudnionych osób i potrzebnych zmian, przewidzenie jakoĈci projektu jest niemoĔliwe. MoĔna podaè uzasadnione prognozy, jednak ostatecznym dowodem jakoĈci projektu jest jego uĔytecznoĈè w obliczu zmian.

450 ROZDZ AĤ 15

DèśEN E DO DOSKONAĤOĻC

TECHN CZNEJ

Ponadto doskonaäy projekt: x jest äatwy do modyfikowania przez osoby, które najczöĈciej przy nim pracujñ; x umoĔliwia äatwe wprowadzanie nieoczekiwanych zmian; x jest äatwy w konserwacji; x dowodzi swej wartoĈci, nieustannie uäatwiajñc modyfikowanie kodu przez lata

wprowadzania zmian i poprawek.

Ogólne zasady projektowania Z uwagi na brak miar jakoĈci projektu nie ma obiektywnego sposobu na udowodnienie, Ĕe dany projekt jest lepszy od innego. Jest jednak kilka ogólnych, wyznaczajñcych kierunek zasad, które wydajñ siö dotyczyè dowolnego jözyka programowania lub platformy. Nie jestem autorem Ĕadnego z tych pomysäów i nie moĔe byè inaczej. Sñ to stare, wielokrotnie uĔywane i powaĔane reguäy. Sñ tak dawne, Ĕe äatwo zapomnieè o nich przy nieustajñcych zachwytach nad nowinkami. PoniĔej przedstawiam krótkie przypomnienie tych zasad.

Kod Śródĥowy to (ostateczny) projekt MoĔna szkicowaè diagramy w jözyku UML. MoĔna omawiaè projekty oparte na kartach CRC. MoĔna tworzyè zgrabne diagramy Ĉcienne przy uĔyciu drukarek wielkoformatowych. Podobne abstrakcje to narzödzia niezbödne przy objaĈnianiu projektu. Nie naleĔy jednak myliè takich materiaäów z gotowym projektem. Trzeba pamiötaè, Ĕe projekt musi dziaäaè. Nie podlega to dyskusji. KaĔdy projekt, którego nie moĔna przeksztaäciè na oprogramowanie, jest automatycznie niekompletny. Architekci i projektanci nie tworzñ kodu. To programiĈci koþczñ za nich przygotowane projekty. Wypeäniajñ nieuniknione luki oraz natrafiajñ na nieprzewidziane problemy i rozwiñzujñ je. JeĈli doĈwiadczeni pracownicy zlecñ te zadania mäodszym programistom, jakoĈè ostatecznego projektu moĔe nie speäniaè oczekiwaþ. Warto samemu podjñè siö tej pracy i rozwijaè projekt do poziomu utworzenia kodu.

Nie powtarzaj siý (NPS) Ta nazwa dobrze znanej zasady zostaäa wymyĈlona przez Dave’a Thomasa i Andy’ego Hunta. Reguäa ta oznacza coĈ wiöcej niĔ samo unikanie przeklejania kodu. Dotyczy spójnej lokalizacji i kanonicznej reprezentacji w ostatecznym projekcie kaĔdego pojöcia: od „sposobu komunikacji z bazñ danych” po „reguäy biznesowe obsäugi weekendów i Ĉwiñt”. Eliminacja powtórzeþ skraca czas potrzebny na wprowadzanie zmian, poniewaĔ umoĔliwia modyfikacjö tylko jednego fragmentu kodu. Zmniejsza to takĔe ryzyko spowodowania usterki przez wprowadzenie zmiany w jednym miejscu, ale juĔ nie w innych.

OGÓ NE ZASADY PROJEKTOWAN A

451

Zachowaj spójnoļë To stare powiedzenie nie staäo siö z wiekiem mniej istotne3. W spójnym projekcie blisko powiñzane pojöcia sñ umieszczone blisko siebie. Klasyczny przykäad to pojöcie daty i operacji okreĈlajñcej nastöpny dzieþ roboczy. MoĔliwoĈè umieszczania danych i powiñzanych z nimi metod w jednej klasie to dobrze znana zaleta programowania obiektowego. SpójnoĈè wykracza jednak poza pojedyncze klasy. MoĔna jñ zwiökszyè, grupujñc powiñzane pliki w jednym katalogu lub umieszczajñc dokumentacjö bliĔej opisywanych przez niñ fragmentów projektu. SpójnoĈè poprawia jakoĈè projektu, poniewaĔ uäatwia jego zrozumienie. Powiñzane pojöcia zgrupowane sñ razem, dziöki czemu czytelnik moĔe zobaczyè, jak wspólnie wpasowujñ siö w ogólny obraz. SpójnoĈè zmniejsza liczbö bäödów, poniewaĔ programista moĔe szybko dostrzec, jak zmiana jednego pojöcia wpäywa na inne. Ponadto w spójnym projekcie powtórzenia sñ bardziej widoczne.

LuŚne powiézanie RóĔne czöĈci projektu sñ powiñzane, jeĈli zmiana w jednej wymaga zmodyfikowania takĔe drugiej. Powiñzanie nie zawsze jest czymĈ zäym. Na przykäad zmiana formatu daty moĔe wymagaè modyfikacji procedury obliczajñcej nastöpny dzieþ roboczy. Problemy pojawiajñ siö, kiedy zmiana w jednej czöĈci projektu wymaga modyfikacji niezwiñzanego z niñ fragmentu. Wtedy albo programista poĈwiöci dodatkowy czas na wyszukiwanie potrzebnych zmian, albo zapomni o nich, co doprowadzi do usterek. Im bardziej odlegäe zwiñzki miödzy dwoma pojöciami, tym luĒniej powinny byè one powiñzane. Z kolei im bliĔsze sobie sñ dane pojöcia, tym powiñzanie miödzy nimi moĔe byè ĈciĈlejsze. Wszystkie te techniki (eliminacja powtórzeþ oraz zapewnienie spójnoĈci projektu i luĒnego powiñzania) dotyczñ tego samego problemu, choè w odmienny sposób. Wspólnie poprawiajñ jakoĈè projektu, poniewaĔ zmniejszajñ wpäyw zmian. Pozwalajñ programistom skoncentrowaè wysiäki na konkretnym fragmencie i dajñ im pewnoĈè, Ĕe nie trzeba przeszukiwaè caäego projektu pod kñtem moĔliwych zmian. Zmniejszajñ teĔ liczbö defektów, poniewaĔ nie trzeba jednoczeĈnie modyfikowaè niezaleĔnych czöĈci projektu.

Wyjaļnianie, upraszczanie i dopracowywanie Skoro dobre projekty to takie, które sñ äatwe do modyfikowania i konserwowania, jeden ze sposobów na ich tworzenie polega na zapewnieniu czytelnoĈci. Kiedy piszö kod, robiö to z myĈlñ o przyszäoĈci. Zakäadam, Ĕe projekt czytaè i oceniaè bödñ osoby, których nigdy nie spotkaäem. Dlatego poĈwiöcam duĔo czasu na uäatwianie zrozumienia kodu. Alistair Cockburn opisuje to jako pisanie raĔñco oczywistego kodu4: 3

Zagadnienia powiñzania i spójnoĈci pochodzñ z pracy Constantine’a z 1968 roku dotyczñcej programowania strukturalnego, Segmentation and Design Strategies for Modular Programming [Constantine]. W tym artykule Constantine przedstawia sposoby oceny powiñzania i spójnoĈci na podstawie analizy statycznego kodu. Ja przedstawiam jego idee w bardziej ogólny sposób.

4

http://c2.com/cgi/wiki?ScreechinglyObviousCode.

452 ROZDZ AĤ 15

DèśEN E DO DOSKONAĤOĻC

TECHN CZNEJ

W dawnych czasach Ĉwiatli ludzie pisali Bardzo Przejrzysty Kod. Inni, obserwujñc ich, uwaĔali, Ĕe marnujñ czas. Pewnego dnia bardzo siö zdumiaäem, kiedy stwierdziäem, Ĕe Bardzo Przejrzysty Kod to za maäo. […] Dotaräo do mnie, Ĕe jest to droga donikñd, poniewaĔ zawartoĈè metody nie odpowiadaäa jej nazwie. ProgramiĈci w istocie szukali w przeglñdarce nazwy, która informowaäaby: „Wpisz kod w tym miejscu”. Wtedy stwierdziäem, Ĕe potrzebowali RaĔñco Oczywistego Kodu. W tym czasie [1995 rok] za dopuszczalne uwaĔano tworzenie metod obsäugi zdarzeþ o nazwie doubleClicked lub podobnych i wykonywanie w nich wszelkich potrzebnych operacji. Takie rozwiñzanie byäo poprawne przy pisaniu Bardzo Przejrzystego Kodu. Jednak w RaĔñco Oczywistym Kodzie jest to niedopuszczalne, poniewaĔ nazwa doubleClicked informowaäa tylko o tym, Ĕe coĈ zostaäo dwukrotnie klikniöte, a nie o tym, co powinno siö staè. ZaäóĔmy, Ĕe metoda ta miaäa odĈwieĔaè panel lub inny element. Potrzebna byäa do tego metoda o nazwie refreshPane, a metoda doubleClick powinna byäa zawieraè tylko jeden wiersz: self refreshPane. Osoby naprawiajñce usterkö wiedziaäy, Ĕe problem dotyczyä odĈwieĔania panelu, jednak musiaäy däugo przeglñdaè kod, aby stwierdziè, Ĕe zadanie to wykonuje metoda doubleClick. ProgramiĈci mieliby duĔo mniej pracy, gdyby na liĈcie metod przeglñdarki [jözyka Smalltalk] znajdowaäa siö metoda refreshPane, poniewaĔ mogliby przejĈè bezpoĈrednio do niej […]. Wtedy moĔna odczytaè kod w prosty sposób: „Kiedy zajdzie zdarzenie doubleClicked, program odĈwieĔa panel”, zamiast: „Kiedy zajdzie zdarzenie doubleClicked, program wykonuje caäy jej kod. Przy okazji, jeĈli dobrze siö wczytasz, zauwaĔysz, Ĕe kod ten odĈwieĔa panel”. RaĔñco oczywisty kod äatwiej tworzyè przy iteracyjnym upraszczaniu i dopracowywaniu. Bob Martin przedstawia doskonaäy przykäad zastosowania tego podejĈcia w artykule Clean Code: Args — A Command-Line Argument Parser5.

Szybkie wykrywanie niepowodzeħ W projekcie, który pozwala szybko wykryè niepowodzenie (zobacz rozdziaä 13.), moĔna äatwo dostrzec usterki. Jeden ze sposobów na szybkie znajdowanie bäödów opiera siö na zaawansowanym pakiecie testów wchodzñcym w skäad projektu. W ten sposób dziaäa wytwarzanie sterowane testami. Inna moĔliwoĈè to uĔycie narzödzi (na przykäad asercji) do wykrywania nieprawidäowych wyników i koþczenia wtedy dziaäania programu. W projektowaniu opartym na kontraktach [Mayer] projekty szybko koþczñ dziaäanie dziöki sprawdzaniu niezmienników klasy oraz warunków poczñtkowych i koþcowych metod. Szybkie wykrywanie niepowodzeþ usprawnia projekt, poniewaĔ bäödy sñ wtedy widoczne szybciej, kiedy jeszcze ich naprawa wymaga niewielkich kosztów.

5

http://www.objectmentor.com/resources/articles/Clean_Code_Args.pdf.

OGÓ NE ZASADY PROJEKTOWAN A 453

Optymalizacja na podstawie pomiarów Wiele osób chötnie przytacza powiedzenie Tony’ego Hoare’a na temat przedwczesnej optymalizacji6, przynajmniej do momentu, kiedy zacznñ wprowadzaè wäasne ulubione optymalizacje. Zoptymalizowany kod jest czösto nieczytelny. Zwykle jest skomplikowany i naraĔony na bäödy. JeĈli dobry projekt prowadzi do skrócenia czasu pracy programisty, optymalizacja prowadzi do caäkowitego przeciwieþstwa takiego projektu. OczywiĈcie, dobry projekt nie tylko ogranicza czas pracy programistów. Wedäug mojej definicji „minimalizuje czas potrzebny na tworzenie, modyfikowanie i konserwacjö oprogramowania przy zapewnieniu akceptowalnej wydajnoĈci programu”. Choè dobrze zaprojektowany kod czösto dziaäa szybko, nie zawsze tak jest. Optymalizacja (zobacz podrozdziaä „Optymalizacja wydajnoĈci” w rozdziale 9.) jest czasem niezbödna. Odraczanie jej pozwala przeprowadziè jñ w najbardziej skuteczny sposób: po dopracowaniu kodu, kiedy wprowadzanie zmian jest najäatwiejsze, a profilowanie wydajnoĈci pomaga skoncentrowaè wysiäki na tych usprawnieniach, które dadzñ najlepsze efekty. OpóĒnianie optymalizacji moĔe budziè obawy. Pozostawianie wyraĒnie powolnego projektu sprawia wraĔenie braku profesjonalizmu. Jednak zwykle jest to najlepsze rozwiñzanie.

Spĥacanie dĥugu technicznego Rzadko kto ma tyle szczöĈcia, aby pracowaè nad projektem, w którym wszystkie wymienione zasady sñ przestrzegane (ja nieczösto uczestniczö w takich projektach). Nawet jeĈli ktoĈ jest takim szczöĈliwcem, prawdopodobnie od czasu do czasu popeäni jakieĈ pomyäki (mnie na pewno siö przytrafiajñ). Mimo najlepszych intencji programistów, w systemie pojawia siö däug techniczny. DuĔa jego czöĈè — prawdopodobnie wiökszoĈè — kryje siö w projekcie. Takie starzenie siö powoli obniĔa jakoĈè nawet najlepszych projektów. Späacanie däugu technicznego przy uĔyciu ciñgäej konserwacji kodu i refaktoryzacji dopiero niedawno uznano za zasadö projektowñ, a niektóre osoby wciñĔ nie sñ do niej przekonane. Jednak te wñtpliwoĈci nie powodujñ, Ĕe reguäa ta jest mniej waĔna. MoĔliwe, Ĕe jest ona najwaĔniejsza spoĈród wszystkich zasad projektowania. Przez koncentracjö na späacaniu däugu technicznego zespóä moĔe naprawiè wszelkie bäödne decyzje projektowe.

Zasady w praktyce Opisane ogólne zasady projektowe to dobre wskazówki, jednak nie pomagajñ w stosowaniu konkretnych jözyków lub platform. Dlatego ponadto potrzebne sñ reguäy dotyczñce uĔywanego jözyka, takie jak lista zasad projektowania klas w jözykach obiektowych [Martin]7. Niestety, przeksztaäcenie ogólnych zasad projektowych na specyficzne wskazówki powoduje utratö waĔnej cechy: kontekstu. W praktyce kaĔda decyzja projektowa jest podejmowana w kontekĈcie 6

„Przedwczesna optymalizacja to Ēródäo wszelkiego zäa”.

7

Zasada pojedynczej odpowiedzialnoĈci, zasada otwarte-zamkniöte, zasada podstawiania Liskowa, zasada odwracania zaleĔnoĈci i zasada segregacji interfejsów.

454 ROZDZ AĤ 15

DèśEN E DO DOSKONAĤOĻC

TECHN CZNEJ

caäego projektu — dziedziny problemu, innych decyzji projektowych, harmonogramu, moĔliwoĈci innych czäonków zespoäu itd. Kontekst sprawia, Ĕe kaĔda konkretna wskazówka budzi wñtpliwoĈci. Tak, naleĔy ich przestrzegaè — jest w nich duĔo wiedzy — jednak trzeba podchodziè do nich ze zdrowym sceptycyzmem. Warto zadaè sobie pytania: „Kiedy dana reguäa nie jest prawdziwa?” i „Jakie zaäoĔenia poczyniä autor?”. Zastanówmy siö nad prostñ i popularnñ reguäñ „Zmienne egzemplarza muszñ byè prywatne”. PoniewaĔ jest to jedna z najczöĈciej powtarzanych zasad projektowych, programiĈci nieraz przestrzegajñ jej bez zastanowienia. To Ēle, poniewaĔ bez kontekstu reguäa ta nie ma wartoĈci i äatwo bäödnie jñ zastosowaè. To prawda, zmienne egzemplarza czösto powinny byè prywatne, jednak jeĈli programista chce zrozumieè reguäö i wiedzieè, kiedy moĔna jñ zäamaè, musi zastanowiè siö, dlaczego ona obowiñzuje. Dlaczego tworzyè zmienne egzemplarza jako prywatne? Jednym z powodów jest to, Ĕe zmienne prywatne wymuszajñ hermetyzacjö. Dlaczego jednak wszyscy muszñ o to dbaè? Prawdziwñ przyczynñ stosowania zmiennych prywatnych (i hermetyzacji) jest to, Ĕe pomagajñ w tworzeniu luĒno powiñzanego kodu. LuĒne powiñzanie jest korzystne, prawda? Nie zawsze. Odpowiednio luĒno powiñzany kod jest dobry, jednak dopuszczalne jest, aby bliskie sobie pojöcia byäy ĈciĈle powiñzane. Jednak bliskie sobie pojöcia powinny teĔ byè spójne. Powinny znajdowaè siö niedaleko siebie w kodzie. W jözykach obiektowych bliskie sobie pojöcia czösto znajdujñ siö w jednej klasie. Z tego wynika reguäa „zmienne egzemplarza muszñ byè prywatne”. Kiedy programista chce utworzyè publicznñ zmiennñ egzemplarza, oznacza to, Ĕe ma problemy zarówno ze spójnoĈciñ, jak i z powiñzaniem. Problem w obszarze spójnoĈci wynika z tego, Ĕe bliskie sobie pojöcia znajdujñ siö w róĔnych klasach. Z kolei problem z powiñzaniem dotyczy tego, Ĕe trzeba modyfikowaè równoczeĈnie pojöcia, które sñ oddalone od siebie w strukturze kodu. Prawdziwy problem polega na tym, Ĕe programiĈci przestrzegajñ zasady bez uwzglödniania kontekstu. Zamiast poĈwiöciè czas na zastanowienie siö nad powiñzaniem i spójnoĈciñ, wielu programistów po prostu dodaje publiczne akcesory i mutatory (metody do pobierania i ustawiania wartoĈci) do zmiennych prywatnych. Jakie korzyĈci to daje? public class MySillyClass { private string _myFakeEncapsulatedVariable; public string getMyFakeEncapsulatedVariable() { return _myFakeEncapsulatedVariable; } public void setMyFakeEncapsulatedVariable(string var) { _myFakeEncapsulatedVariable = var; } }

Z uwagi na powiñzanie nie ma duĔej róĔnicy miödzy tym kodem a kodem zawierajñcym zmiennñ publicznñ. PowyĔszy kod jest zgody z literñ zasady, ale nie uwzglödniono w nim jej ducha, czyli nieudostöpniania szczegóäów implementacji innym klasom. Z perspektywy projektowej zmienna publiczna jest równowaĔna temu fragmentowi, a z pewnoĈciñ niedoskonaäoĈè projektu byäaby wtedy bardziej oczywista. ZASADY W PRAKTYCE 455

DéŜenie do mistrzostwa Dobry projekt oprogramowania minimalizuje czas potrzebny na tworzenie, modyfikowanie i konserwacjö oprogramowania przy zapewnieniu akceptowalnej wydajnoĈci programu. Ta definicja i wnioski, do których prowadzi, to najwaĔniejsze elementy, na jakie zwracam uwagö w trakcie tworzenia projektu. Przestrzegam kilku podstawowych zasad projektowych i stosujö techniki, które sñ przydatne w uĔywanych przeze mnie jözykach. Jednak jestem gotów do odrzucenia nawet reguä projektowych, jeĈli wydäuĔajñ czas pracy programisty i, co jeszcze waĔniejsze, utrudniajñ rozwiñzanie problemów klientów. To samo dotyczy zwinnego wytwarzania oprogramowania. Ostatecznie waĔny jest sukces, niezaleĔnie od tego, jak go zdefiniowaè. Praktyki, zasady i wartoĈci to jedynie wskazówki na drodze do jego osiñgniöcia. NaleĔy zaczñè od Ĉcisäego przestrzegania praktyk i zrozumieè znaczenie zasad. Potem moĔna äamaè reguäy, eksperymentowaè, sprawdzaè, co dziaäa, a takĔe rozwijaè swñ wiedzö. NaleĔy dzieliè siö przemyĈleniami i pasjñ oraz nieustannie uczyè czegoĈ nowego. Z czasem, dziöki dyscyplinie i sukcesom, nawet zasady zacznñ wydawaè siö mniej istotne. Kiedy w wyniku bogatego doĈwiadczenia prawidäowe wykonywanie zadaþ staje siö instynktowne i intuicyjne, przychodzi pora na porzucenie reguä i zasad. Kiedy programista tworzy doskonaäe i wartoĈciowe oprogramowanie oraz wykorzystuje swñ wiedzö do rozwoju projektów nastöpnej generacji, oznacza to, Ĕe opanowaä sztukö udanego wytwarzania oprogramowania.

456 ROZDZ AĤ 15

DèśEN E DO DOSKONAĤOĻC

TECHN CZNEJ

Literatura cytowana

[Ambler i Sadalage] Ambler Scott i Sadalage Pramodkumar, Refactoring Databases: Evolutionary Database Design, Boston, Addison-Wesley Professional, 2006. [Anderson 2003] Anderson David, Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results, Upper Saddle River, NJ, Prentice Hall, 2003. [Anderson 2006] Anderson David, HP gets 3.4x productivity gain from Agile Management techniques (zamieszczono 15 marca 2006), blog Agile Management. http://www.agilemanagement.net/Articles/Weblog/HPgets3.4xproductivitygai.html. [Astels] Astels David, Test Driven Development: A Practical Guide, Upper Saddle River, NJ, Prentice Hall, 2003. [Bach 1999] Bach James, General Functionality and Stability Test Procedure for Microsoft Windows Logo, Desktop Applications Edition, 1999. http://www.testingcraft.com/bach-exploratory-procedure.pdf. [Bach 2000] Bach Jonathan, Session-Based Test Management, 2000. http://www.satisfice.com/articles/sbtm.pdf. [Beck 1999] Beck Kent, Extreme Programming Explained, wydanie pierwsze, Boston, Addison-Wesley Professional, 1999. [Beck 2002] Beck Kent, Test Driven Development: By Example, Boston, Addison-Wesley Professional, 2002. [Beck 2004] Beck Kent, Extreme Programming Explained, wydanie drugie, Boston, Addison-Wesley Professional, 2004. [Beck i Fowler] Beck Kent i Fowler Martin, Planning Extreme Programming, Boston, Addison-Wesley Professional, 2000. [Beck i inni] Beck Kent i inni, Manifesto for Agile Software Development, 2001. http://agilemanifesto.org.

457

[Belshee] Belshee Arlo, Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience, „Proceedings of the Agile Development Conference (July 24-29)”, Waszyngton, DC, IEEE Computer Society, 125 – 131, 2005. http://dx.doi.org/10.1109/ADC.2005.37. [Berczuk i Appleton] Berczuk Stephen P. i Appleton Brad, Software Configuration Management Patterns: Effective Teamwork, Practical Integration, Boston, Addison-Wesley Professional, 2002. [Boehm] Boehm Barry, Industrial Software Metrics Top 10 List, „IEEE Software”, 4(9), 84 – 85, 1987. [Brooks] Brooks Frederick P., The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition, Boston, Addison-Wesley Professional, 1995. [Cockburn 2001] Cockburn Alistair, Agile Software Development, Boston, Addison-Wesley Professional, 2001. [Cockburn i Williams] Cockburn Alistair i Laurie Williams, „The Costs and Benefits of Pair Programming”, Extreme Programming Examined, Succi G. i Marchesi M. (red.), 223 – 247, Boston, Addison-Wesley Professional, 2001. http://www.cs.utah.edu/~lwilliam/Papers/XPSardinia.PDF. [Coffin] Coffin Rod, A Tale of Two Projects, „The Conference on AGILE 2006 (July 23 – 28)”, Waszyngton, DC, IEEE Computer Society, 155 – 164. http://dx.doi.org/10.1109/AGILE.2006.3. [Cohn] Cohn Mike, Agile Estimating and Planning, Upper Saddle River, NJ, Prentice Hall, 2005. [Constantine] Constantine Larry, „Segmentation and Design Strategies for Modular Programming”, Modular Programming: Proceedings of a National Symposium, Barnett T. O. i Constantine L. L. (red.), Cambridge, MA, Information & Systems Press, 1968. [Cunningham] Cunningham Ward, The CHECKS Pattern Language of Information Integrity, 1994. http://c2.com/ppr/checks.html. [DeMarco 1995] DeMarco Tom, Why Does Software Cost So Much?: And Other Puzzles of the Information Age, Nowy Jork, Dorset House Publishing Co., 1995. [DeMarco 2002] DeMarco Tom, Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency, Nowy Jork, Broadway Books, 2002. [DeMarco i Lister 1999] DeMarco Tom i Lister Timothy, Peopleware: Productive Projects and Teams, Nowy Jork, Dorset House Publishing Co., 1999. [DeMarco i Lister 2003] DeMarco Tom i Lister Timothy, Waltzing With Bears: Managing Risk on Software Projects, Nowy Jork, Dorset House Publishing Co., 2003. [Denne i Cleland-Huang] Denne Mark i Cleland-Huang Jane, Software by Numbers: Low-Risk, High-Return Development, Upper Saddle River, NJ, Prentice Hall, 2003. [Derby i Larsen] Derby Esther i Larsen Diana, Agile Retrospectives: Making Good Teams Great, Raleigh and Dallas, Pragmatic Bookshelf, 2006. [Evans] Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software, Boston, Addison-Wesley Professional, 2003. [Feathers] Feathers Michael, Working Effectively with Legacy Code, Upper Saddle River, NJ, Prentice Hall, 2004.

458

TERATURA CYTOWANA

[Fowler 1999] Fowler Martin, Refactoring: Improving the Design of Existing Code, Boston, Addison-Wesley Professional, 1999. [Fowler 2000] Fowler Martin, Is Design Dead?, 2000. http://www.martinfowler.com/articles/designDead.html. [Fowler 2002a] Fowler Martin, Patterns of Enterprise Application Architecture, Boston, Addison-Wesley Professional, 20021. [Fowler 2002b] Fowler Martin, Yet Another Optimization Article, 2002 [2002b]. http://www.martinfowler.com/ieeeSoftware/yetOptimization.pdf. [Fowler 2003] Fowler Martin, Cannot Measure Productivity, 2003. http://www.martinfowler.com/bliki/ CannotMeasureProductivity.html. [Fowler i Scott] Fowler Martin i Scott Kendall, UML Distilled: A Brief Guide to the Standard Object Modeling Language, wydanie drugie, Boston, Addison-Wesley Professional, 1999. [Gamma i inni] Gamma Erich, Helm Richard, Johnson Ralph i Vlisside John [„Banda czworga”], Design Patterns: Elements of Reusable Object-Oriented Software, Boston, Addison-Wesley Professional, 19952. [Goldratt 1992] Goldratt Eliyahu M., The Goal: A Process of Ongoing Improvement, Great Barrington, MA, North River Press, 1992. [Goldratt 1997] Goldratt Eliyahu M., Critical Chain: A Business Novel, Great Barrington, MA, North River Press, 1997. [Hendrickson] Hendrickson Elisabeth, Rigorous Exploratory Testing (zamieszczono 19 kwietnia 2006). http://www.testobsessed.com/2006/04/19/rigorous-exploratory-testing/. [Highsmith] Highsmith Jim, Agile Software Development Ecosystems, Boston, Addison-Wesley Professional, 2002. [Hunt i Thomas] Hunt Andrew i Thomas David, The Pragmatic Programmer: From Journeyman to Master, Boston, Addison-Wesley Professional, 1999. [Hunter] Hunter Michael [„The Braidy Tester”], Did I Remember To (zamieszczono 7 lipca 2004). http://blogs.msdn.com/micaheVarticles/175571.aspx. [Janzen i Saiedian] Janzen David i Saiedian Hossein, Test-Driven Development: Concepts, Taxonomy, and Future Direction, „IEEE Computer”, 38(9), 43 – 50, 2005. [Jeffries i inni] Jeffries Ron, Anderson Ann i Hendrickson Chet, Extreme Programming Installed, Boston, Addison-Wesley Professional, 2000. [Kaner] Kaner Cem, Testing Computer Software, Blue Ridge Summit, PA, TAB Books, 1987. [Katzenbach i Smith] Katzenbach Jon R. i Smith K. Douglas, The Wisdom of Teams: Creating the High-Performance Organization, Nowy Jork, HarperBusiness, 1994.

1

Wydanie polskie: Architektura systemów zarzñdzania przedsiöbiorstwem. Wzorce projektowe, Helion, 2005 — przyp. täum.

2

Wydanie polskie: Wzorce projektowe, WNT, 2005 — przyp. täum.

TERATURA CYTOWANA 459

[Kerievsky] Kerievsky Joshua, Refactoring to Patterns, Boston, Addison-Wesley Professional, 20043. [Kerth] Kerth Norman, Project Retrospectives: A Handbook for Team Reviews, Nowy Jork, Dorset House Publishing Co., 2001. [Kohl 2005a] Kohl Jonathan, User Profiles and Exploratory Testing (zamieszczono 12 czerwca 2005). http://www.kohl.ca/blog/archives/000104.html. [Kohl 2005b] Kohl Jonathan, Exploratory Testing on Agile Teams, „InformIT”, 18 paĒdziernika 2005. http://www.informit.com/articles/article.aspx?p=405514. [Kohn] Kohn Alfie, Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A’s, Praise, and Other Bribes, Boston, Mariner Books, 1999. [Lacey] Lacey Mitch, Adventures in Promiscous Pairing: Seeking Begginer’s Mind, „Proceedings of the Conference on AGILE 2006 (July 23 – 28)”, Waszyngton, DC, IEEE Computer Society, 263 – 269, 2006. http://dx.doi.org/10.1109/AGILE.2006.7. [Little] Little Todd, Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty, „IEEE Software”, 23(3), 48 – 54, 2006. http://www.toddlittleweb.com/Papers/Little%20Cone%20of%20Uncertainty.pdf. [Mah] Mah Michael, Agile Productivity Metrics, otwarcie „Better Software Conference & EXPO”, Las Vegas, czerwiec 2006. http://www.sqe.com/Events/Archive/bsc2006/keynotes.html. [Maister i inni] Maister David, Green Charles, Galford Robert, The Trusted Advisor, Nowy Jork, Free Press, 2000. [Manns i Rising] Manns Mary Lynn i Rising Linda, Fearless Change: Patterns for Introducing New Ideas, Boston, Addison-Wesley Professional, 2004. [Marick] Marick Brian, A Survey of Exploratory Testing. http://www.testingcraft.com/exploratory.html. [Martin 2002] Martin Robert C., Agile Software Development, Principles, Patterns, and Practices, Upper Saddle River, NJ, Prentice Hall, 2002. [Martin 2005] Martin Robert C., Clean Code: Args — A Command-line Argument Parser, opublikowano na witrynie internetowej Object Mentor Inc., (26 paĒdziernika 2005). http://www.objectmentor.com/resources/articles/Clean_Code_Args.pdf. [Mason] Mason Mike, Pragmatic Version Control: Using Subversion (The Pragmatic Starter Kit Series), wydanie drugie, Raleigh and Dallas, Pragmatic Bookshelf, 2006. [McConnell 1996] McConnell Steve, Rapid Development: Taming Wild Software Schedules, Redmond, WA, Microsoft Press, 1996. [McConnell 2005] McConnell Steve, Software Estimation: Demystifying the Black Art, Redmond, WA, Microsoft Press, 2005. [Mayer] Meyer Bertrand, Object-Oriented Software Construction, wydanie drugie, Upper Saddle River, NJ, Prentice Hall, 20004. 3

Wydanie polskie: Refaktoryzacja do wzorców projektowych, Helion, 2005 — przyp. täum.

4

Wydanie polskie: Programowanie zorientowane obiektowo, Helion, 2005 — przyp. täum.

460

TERATURA CYTOWANA

[Miller] Miller Charles, Stand-Up Meeting Antipatterns (zamieszczono 19 paĒdziernika 2003), blog Fishbowl. http://fishbowl.pastiche.org/2003/11/19/standup_meeting_antipatterns. [Montagna] Montagna Frank C., The Effective Postfire Critique, „Fire Engineering”, 1 lipca 1996. http://www.chiefmontagna.com/Articles/pdf/critique.pdf. [Mugridge i Cunningham] Mugridge Rick i Cunningham Ward, Fit for Developing Software: Framework for Integrated Tests, Upper Saddle River, NJ, Prentice Hall, 2005. [Nielsen] Nielsen Jakob, Designing Web Usability: The Practice of Simplicity, Berkeley, CA, Peachpit Press, 19995. [Overby] Overby Stephanie, The Hidden Costs of Offshore Outsourcing, „CIO”, 1 sierpnia 2003. http://www.cio.com/archive/090103/money.html. [Poppendieck i Poppendieck] Poppendieck Mary i Poppendieck Tom, Lean Software Development: An Agile Toolkit for Software Development Managers, Boston, Addison-Wesley Professional, 2003. [Pugh] Pugh Ken, Prefactoring, Sebastopol, CA, O’Reilly Media, Inc., 2005. [Rainsberger] Rainsberger J. B., Junit Recipes: Practical Methods for Programmer Testing, Greenwich, CT, Manning Publications, Co., 2004. [Rooney] Rooney Dave, The Disengaged Customer (zamieszczono 20 stycznia 2006), blog The Agile Artisan. http://agileartisan.blogspot.com/2006/01/disengaged-customer-introduction.html. [Schwaber i Beedle] Schwaber Ken i Beedle Mike, Agile Software Development with SCRUM, Upper Saddle River, NJ, Prentice Hall, 2001. [Shore 2004a] Shore Jim, Continuous Design, „IEEE Software”, 21(1), 20 – 22, 2004. http://www.martinflower.com/ieeeSoftware/continuousDesign.pdf. [Shore 2004b] Shore Jim, Fail Fast, „IEEE Software”, 21(5), 21 – 25, 2004. http://www.martinflower.com/ieeeSoftware/failFast.pdf. [Shore 2005a] Shore Jim, Agile Requirements, (zamieszczono 30 listopada 2005). http://www.jamesshore.com/Blog/Agile-Requirements.html. [Shore 2005b] Shore Jim, materiaäy na temat zwinnego wytwarzania oprogramowania, 2005. http://c2.com/cgi/wiki?JimShore. [Sink] Sink Eric, Source Control HOWTO (zamieszczono 27 sierpnia 2004), blog Erica. http://www.ericsink.com/scm/source_control.html. [Smith] Smith Steven M., The Satir Change Model (zamieszczono 4 paĒdziernika 1997), Steven M. Smith & Associates, LLC. http://www.stevensmith.com/my-articles/article/the-satir-changemodel.html. [Standish] Standish Group, The CHAOS Report, Standish Group International, Inc., 1994. http://www.standishgroup.com/sample_research/chaos_1994_1.php. [Stapleton] Stapleton Jennifer, DSDM: A Framework for Business Centered Development, Boston, Addison-Wesley Professional, 1997. 5

Wydanie polskie: Projektowanie funkcjonalnych serwisów internetowych, Helion, 2003 — przyp. täum.

TERATURA CYTOWANA

461

[Subramaniam i Hunt] Subramaniam Venkat i Hunt Andy, Practices of an Agile Developer: Working in the Real World, Raleigh and Dallas, Pragmatic Bookshelf, 2006. [Teasley i inni] Teasley Stephanie, Covi Lisa, Krishnan M. S., Olson Judith, Rapid Software Development Through Team Collocation, „IEEE Transactions on Software Engineering”, 28(7), 671 – 683, 2002. http://dx.doi.org/10.1109/TSE.2002.1019481. [Tinkham i Kaner] Tinkham Andy i Kaner Cem, Exploring Exploratory Testing, prezentacja na „SQE’s Software Testing, Analysis & Review Conference”, Orlando, FL, Lipiec 2003. http://www.testingeducation.org/a/explore.pdf. [Tuckman] Tuckman B. W., Developmental sequences in small groups, „Psychological Bulletin”, 63, 384 – 399, 1965. http://dennislearningcenter.osu.edu/references/GROUP%20DEV%20ARTICLE.doc. [Ury] Ury William, The Power of a Positive No: How to Say No and Still Get to Yes, Nowy Jork, Bantam Books, 2007. [Van Schooenderwoert] Van Schooenderwoert Nancy, Embedded Agile Project by the Numbers with Newbies, „The Conference on AGILE 2006 (July 23 – 28)”, Waszyngton, DC, IEEE Computer Society, 351 – 366, 2006. http://dx.doi.org/10.1109/AGILE.2006.24. [Wiegers 1999] Wiegers Karl E., Software Requirements, Redmond, WA, Microsoft Press, 1999. [Wiegers 2001] Wiegers Karl E., Peer Reviews in Software: A Practical Guide, Boston, Addison-Wesley Professional, 2001. [Williams] Williams Laurie, Pair Programming Illuminated, Boston, Addison-Wesley Professional, 2001. [Wirfs-Brock i McKean] Wirfs-Brock Rebecca i McKean Alan, Object Design: Roles, Responsibilities, and Collaborations, Boston, Addison-Wesley Professional, 20026. [Yap] Yap Monica, Follow the Sun: Distributed Extreme Programming Development, „The Conference on AGILE 2006 (July 23 – 28)”, Waszyngton, DC, IEEE Computer Society, 218 – 224, 2005. http://dx.doi.org/10.1109/ ADC.2005.26. [Yip] Yip Jason, It’s Not Just Standing Up: Patterns of Daily Stand-up Meetings, 2006. http://www.martinfowler.com/articles/itsNotJustStandingUp.html. [Yourdon] Yourdon Edward, Death March: The Complete Software Developer’s Guide to Surviving ‘Mission Impossible’ Projects, Upper Saddle River, NJ, Prentice Hall, 1999.

6

Wydanie polskie: Projektowanie obiektowe. Role, odpowiedzialnoĈè i wspóäpraca, Helion, 2005 — przyp. täum.

462

TERATURA CYTOWANA

Skorowidz

A adaptacja, 420 agile development, 9, 19 Agile Manifesto, 25 aktualizacja, 202 aktywnoĈè, 129 ambitny cel, 273 analitycy biznesowi, 48 analiza, 34 analiza istniejñcego kodu, 362 analizy przyczynowo-skutkowe, 91, 112 efekty, 114 obwinianie poszczególnych osób, 114 przeciwwskazania, 114 uczestnicy, 113 usuwanie podstawowej przyczyny, 113 wykrywanie podstawowej przyczyny, 112 anulowanie, 203 zmiany, 226 architekci, 49, 51 architektura, 384 n-warstwowa, 384 oparta na ryzyku, 385 sterowana ryzykiem, 385 trójwarstwowa, 384 arkusz kontroli czasu, 178 ataki zwiñzane z typami danych, 406 automatyczne testy akceptacji, 39 automatyzacja kompilacja, 212 odziedziczone projekty, 213 przykäady, 336

B badania techniczne, 50 batman, 288, 290 bawienie siö z wartoĈciñ null, 361 bezwzglödna refaktoryzacja, 389 blokada, 203 bäödy, 50, 191, 196 bäotna bryäa, 354 brak bäödów, 191 efekty, 200 eliminacja miejsc sprzyjajñcych powstawaniu bäödów, 193 generowanie mniejszej liczby bäödów, 192 gruntowna zmiana oczekiwaþ, 198 naprawianie bäödów od razu, 194 odziedziczony kod, 199 przeciwwskazania, 200 TDD, 193 testowanie procesu, 196 uniemoĔliwianie pomyäek, 197 usprawnianie procesu, 197 wytwarzanie sterowane testami, 193 zestaw technik XP, 192 branch, 203 budowanie efektywne zwiñzki, 425 proces dla ludzi, 429 build, 213 burn-up charts, 175 burza mózgów, 116 bycie zwinnym, 25

463

C cele retrospekcji, 118 ceremonia podejmowania zobowiñzaþ, 283 check in, 203 check out, 202 chirurgia odpryskowa, 360 ciñgäa integracja, 83, 202, 219 aktualizacja przy uĔyciu kodu z repozytorium, 221 anulowanie zmian, 226 däuga kompilacja, 223 efekty, 227 integracja, 221 integracja asynchroniczna, 223, 225 integracja synchroniczna, 223 integracja wieloetapowa, 224 kompilacja w integracji wieloetapowej, 224 maszyna do integracji, 226 oczekiwanie na ukoþczenie kompilacji zintegrowanego kodu, 224 proces, 221 przeciwwskazania, 227 serwer do ciñgäej integracji, 222 stosowanie, 220 system kontroli wersji, 226 wprowadzanie ciñgäej integracji, 222 zachowywanie poprawnoĈci kompilacji, 220 ciñgäe projektowanie, 381 ciñgäoĈè zespoäu, 128 ciche kategoryzowanie, 117 coachowie, 50 klientów, 242 programista, 51 cocktail party, 139 coddling nulls, 361 codzienny mäyn, 157 cotygodniowa instalacja, 170 count(), 349 CRC, 107, 387 CRUD, 406 CruiseControl, 222 cud wspóäpracy, 264 cykl Ĕycia, 30 XP, 32 czas na naukö, 295 czerwony pasek, 342 czöste udostöpnianie, 247, 250, 444 czöste wydania, 249 czöĈciowe przypisywanie, 55 czöĈciowo ukoþczona praca, 287

464 SKOROW DZ

ê èwiczenie rozwagi, 92

D data class, 361 data clumps, 361 daty wydaþ, 254 dñĔenie do doskonaäoĈci technicznej, 447 dñĔenie do mistrzostwa, 456 doskonaäy projekt, 450 Nienazwana cecha, 449 ogólne zasady projektowania, 451 oprogramowanie nie istnieje, 447 optymalizacja na podstawie pomiarów, 454 projekt, 448 równowaga w projektach, 449 späacanie däugu technicznego, 454 szybkie wykrywanie niepowodzeþ, 453 dñĔenie do mistrzostwa, 456 dñĔenie do wysokiej przepustowoĈci, 436 DBMS, 209 debugowanie masowe, 431 róĔnicowe, 204 deklaracja, 403 deklaracja wizji, 243 demonstracja, 332 demonstracje iteracji, 167 cotygodniowa instalacja, 170 efekty, 172 kluczowe pytania, 169 krytyka, 171 przeciwwskazania, 172 przeprowadzanie, 167 developers, 323 diagramy, 108 sekwencja, 362 usprawnianie procesu, 108 wykonane zadania, 273 divergent change, 360 däug techniczny, 56, 77, 294 däuga kompilacja, 223 däugie sesje planowania, 284 däugoĈè iteracji, 291 däugoterminowe zobowiñzania, 268 dobre cele retrospekcji, 120 dobre nawyki programistyczne, 93 dodatkowe raporty dla zarzñdu, 176 dodatkowe raporty o postöpach, 175 dokäadne szacowanie, 311

dokumentacja, 234 efekty, 236 obecne prace, 234 produkt, 234 przeciwwskazania, 236 zdawcza, 234, 235 zmniejszanie iloĈci, 235 dokumentowanie wizji, 242 dopracowywanie, 420, 452 doskonaäa komunikacja, 138 doskonaäoĈè techniczna, 21, 447 doskonaäy projekt, 450 doskonaäy skrypt kompilacji, 214 dostosowywanie metodñ kopiuj i wklej, 207 doĈwiadczenie, 415 doĈwiadczony coach programista, 69 dynamiczne poszukiwanie informacji zwrotnych, 440 dzielenie opowieĈci, 304 dzienne iteracje, 289 dziesiöciominutowa kompilacja, 83, 211 automatyzacja kompilacji, 212 automatyzacja odziedziczonych projektów, 213 efekty, 217 kompilacja lokalna, 212 konserwacja skryptu kompilacji, 215 przeciwwskazania, 217 skrypt doskonaäy kompilacji, 214 stosowanie automatyzacji, 213 Ĉrodowisko IDE, 216 Ĉrodowisko rozwojowe, 216 ulepszanie kompilacji, 216

E efekt cocktail party, 139 efektywna wspóäpraca, 425 efektywne zwiñzki, 425 eksperci, 24, 28 ekspert z dziedziny, 46 eksperymenty, 391 ekstremalne rozwiñzania, 82 eliminacja miejsc sprzyjajñcych powstawaniu bäödów, 193 eliminowanie marnotrawstwa, 431 dñĔenie do wysokiej przepustowoĈci, 436 debugowanie masowe, 431 maksymalizacja liczby zadaþ, których nie trzeba wykonywaè, 435 praca w maäych kroczkach, 431 stopniowe wprowadzanie zmian, 431 szybkie wykrywanie niepowodzeþ, 433

empatia miödzy klientem a programistñ, 126 empatia miödzy programistami a testerami, 127 energiczna praca, 91, 101, 102 czas pracy, 105 efekty, 105 gra planistyczna, 103 pomocne punkty, 103 posiadanie duĔej iloĈci energii, 102 programowanie w parach, 103 przeciwwskazania, 105 przerwy, 104 wizja, 103 wolny czas, 102 wspomaganie, 103 etykieta, 203 executive sponsor, 52 Extract Method, 365 Extreme Programming, 9

F FitNesse, 336 fixture, 336 focused integration test, 355 formatowanie kodu, 161 fragmenty XP, 82

G gaäñĒ, 203 generowanie mniejsza liczba bäödów, 192 zadania, 281 gäowa, 203 gotowoĈè technologiczna, 219 gra planistyczna, 33, 103, 262 cud wspóäpracy, 264 efekty, 266 klienci, 265 koszty, 262 okreĈlanie priorytetów, 262 przeciwwskazania, 266 rozczarowanie, 263 rozwiñzywanie sporów, 263 szacowanie, 262 wartoĈci, 262 wygrywanie, 264 zawyĔanie szacunków, 264 gra zespoäowa, 262 grupy wspólnej nauki, 300

SKOROW DZ 465

H half-baked object, 362 harmonogram, 21, 188, 274 iteracje, 278 heurystyki, 405 horyzont planowania, 256

I idealne godziny, 282 ignorowanie ryzyka, 271 informacje, 107 informacyjne miejsce pracy, 91, 107 diagramy, 108 diagramy usprawniania procesu, 108 duĔe, widoczne diagramy, 108 efekty, 111 informacje, 107 liczenie, 110 odröczne diagramy, 108 przeciwwskazania, 111 raporty, 110 instalacja, 35 integracja, 221 asynchroniczna, 223, 225 synchroniczna, 223 wieloetapowa, 224 interfejs uĔytkownika, 34, 47 interfejsy udostöpniane, 376 inĔynieria w obie strony, 362 iteracje, 57, 78, 82 izolowanie niezaleĔnych komponentów, 376

J jakoĈè kodu, 180 jeden kod bazowy, 207 jedna para nazwa-wartoĈè, 344 jözyk äatwy do refaktoryzacji, 69 JUnit, 352

K kadra zarzñdzajñca, 24 kalendarze zespoäowe, 108 karteczki, 124 karteczki z opowieĈciami, 302 karty opowieĈci, 302 kierowanie przez klientów, 335 kierownictwo, 24 kierownik techniczny, 51 klasy danych, 361

466 SKOROW DZ

klasy prawie jak statyczne, 361 klienci, 43, 44 kontrola wersji, 205 wiedza ekspercka, 325 knowledge silo, 229 kod bazowy, 231 kod gotowy do udostöpnienia, 441 kod Ēródäowy, 451 kompilacja, 212 lokalna, 212 pomocnicza, 224 przesäany kod, 224 w integracji wieloetapowej, 224 komunikacja, 138, 145, 234 osmotyczna, 139 testy klienta, 331 koncentracja na kliencie, 303 koncentracja na reguäach biznesowych, 334 kontrola wersji, 202 aktualizacja, 202 anulowanie, 203 baza danych, 209 biblioteki, 208 blokada, 203 caäy projekt, 205 ciñgäa integracja, 202 debugowanie róĔnicowe, 204 efekty, 210 etykieta, 203 gaäñĒ, 203, 207 gaäözie prywatne, 208 gäowa, 203 integracja kodu Ēródäowego z innych projektów, 209 jeden kod bazowy, 207 klienci, 205 kopia robocza, 202 minimalizacja naruszania kompilacji, 206 model blokady, 203 model równolegäy, 204 narzödzia, 208 Perforce, 208 platforma programistyczna, 209 pobieranie, 202 podróĔ w czasie, 204 przeciwwskazania, 210 przesyäanie, 203 przywracanie, 203 repozytorium, 202 rozgaäözianie, 203 równolegäe wprowadzanie zmian, 203 scalanie, 203

Subversion, 208 systemy, 208 TortoiseSvn, 208 utrzymywanie porzñdku, 206 VSS, 208 wierzchoäek, 203 wykorzystanie gaäözi, 207 zatwierdzanie, 203 znacznik, 203 kontrola zagroĔeþ, 272 kopia robocza, 202 koszty opowieĈci, 312 koszty zadaþ wchodzñcych w skäad iteracji, 314 krótkie spotkania robocze, 157 codzienny mäyn, 157 efekty, 159 przeciwwskazania, 160 przeprowadzanie, 157 zwiözäoĈè, 158 kryteria sukcesu, 243 kultura organizacji, 258 kwestionariusz samooceny, 85

L liczba opowieĈci, 179 liczba programistów, 66 liczba wierszy kodu Ēródäowego, 179 lider, 70 lock, 203 logika biznesowa, 384 luĒne powiñzanie, 452

Ĥ äamanie reguä, 421 äñczenie opowieĈci, 304

M magazyn, 436 maksymalizacja liczby zadaþ, których nie trzeba wykonywaè, 435 maäe pomieszczenie robocze, 142 manifest zwinnoĈci, 25 mapa strumienia wartoĈci, 184, 185 marnotrawstwo, 431 menedĔer produktu, 30, 44, 45, 64, 242 brak doĈwiadczenia, 64 brak zaangaĔowania, 65 umiejötnoĈci, 46 zbyt zajöty, aby mógä przebywaè z zespoäem, 64

menedĔer projektu, 51 menedĔerowie, 24 mentor, 28 merge, 203 metody, 26 metody prywatne, 358 metody szacowania, 309 mindfulness, 59 minimal marketable feature, 250 minimalny zestaw funkcji rynkowych, 250 mäyn, 26, 157 MMF, 250 mnoĔniki zarzñdzania ryzykiem, 269, 276 mock objects, 354 model blokady, 203 model dziedziny, 154 model równolegäy, 204 modelowanie dziedziny, 154 moderator produktu, 242 moment liczenia usterek, 177 mówienie prawdy, 133 myĈlenie, 91, 341 analizy przyczynowo-skutkowe, 112 energiczna praca, 102 informacyjne miejsce pracy, 107 programowanie w parach, 93 retrospekcje, 115

N nadgodziny, 134 nagäe Ĕñdania, 287 naprawianie bäödów, 289 od razu, 194 waĔne bäödy, 79 narzödzia do testowania, 352 naturalny coach, 70 NBTP, 374 Nie bödziesz tego potrzebowaä, 374 Nie powtarzaj siö, 451 niedoĈwiadczeni liderzy, 70 nieformalne ustalenia dotyczñce wspóäpracy, 73 Nienazwana cecha, 447, 449 niepeäne obiekty, 362 niestandardowe rozwiñzania wewnötrzne, 147 niestandardowe rozwiñzania zewnötrzne, 148 nieudostöpnione oprogramowanie, 436 niewykorzystanie moĔliwoĈci, 437 notatki, 404 nowy kod bazowy, 68 NPS, 451 null, 361 NUnit, 352 NUnitAsp, 362 SKOROW DZ 467

O obiekty biznesowe, 384 fixture, 336 zastöpcze, 354 obserwacja, 404 obsesja na punkcie typów prostych, 360 obwinianie o bäödy, 195 ocena zwinnoĈci zespoäu, 83 diagram do samooceny, 85 kwestionariusz samooceny, 85 myĈlenie, 85 planowanie, 87 udostöpnianie, 86 wspóäpraca, 86 wytwarzanie, 87 odciñĔanie programistów, 317 odpowiednia wielkoĈè zespoäu, 65 odpowiednie osoby do odpowiednich zadaþ, 427 odröczne diagramy, 108 odwaga, 421 odziedziczony kod, 356 odziedziczony projekt, 76 ogólne zasady projektowania, 451 ogólny plan zarzñdzania ryzykiem, 268 ograniczanie liczby interfejsów udostöpnianych, 376 ograniczenie czasowe iteracji, 278, 310 on-site customer, 33 opis, 331 opowieĈci, 57, 301 architektura, 306 dotyczñce dokumentacji, 304 dzielenie opowieĈci, 304 efekty, 307 infrastruktura techniczna, 306 karty opowieĈci, 302 koncentracja na kliencie, 303 koszty, 312 kryteria ukoþczenia, 301 äñczenie opowieĈci, 304 o bäödach, 305 pozafunkcjonalne, 305 projekt, 306 przeciwwskazania, 308 punktowe, 305 refaktoryzacja, 306 specjalne opowieĈci, 304 spotkania, 306 szacowanie, 306 wartoĈè dla klienta, 301 opór czäonków zespoäu, 63 opóĒnienie, 398

468 SKOROW DZ

oprogramowanie, 72 bezpäatne, 420 do sprzedaĔy publicznej, 149 nie istnieje, 447 o otwartym dostöpie do kodu Ēródäowego, 420 specjalistyczne, 149 w wersji produkcyjnej, 186 z kodem spaghetti, 354 optymalizacja na podstawie pomiarów, 454 optymalizacja wydajnoĈci, 395 efekty, 400 koszty opowieĈci dotyczñcych wydajnoĈci, 399 moment optymalizacji, 397 na bieĔñco, 399 opowieĈci dotyczñce wydajnoĈci, 398 opóĒnienie, 398 poziomy wydajnoĈci, 398 przeciwwskazania, 400 przepustowoĈè, 398 sposoby, 396 szybkoĈè reagowania, 398 testerzy, 398 testy wydajnoĈci, 397, 400 wady, 397 wydajnoĈè akceptowalna, 398 wydajnoĈè optymalna, 398 organizacja, 22 oparta na zarzñdzaniu sieciowym, 55 organizacyjne przeciwciaäa, 128 ostatni moment na podjöcie zobowiñzaþ, 57, 256 otwarte pomieszczenie robocze, 143

P pamiöè podröczna, 395 pary, 93 peänoetatowi czäonkowie zespoäu, 55 Perforce, 208 pilot, 93 ping-pong w parach, 97 pisanie kodu, 34 pisanie opowieĈci dotyczñcych wydajnoĈci, 398 pisanie raĔñco oczywistego kodu, 452 plan zarzñdzania ryzykiem, 268 planowanie, 33, 239 gra planistyczna, 262 opowieĈci, 301 przystosowawcze, 257 rozwiñzania punktowe, 392 szacowanie, 309 wizja, 241 zapas, 293 zarzñdzanie ryzykiem, 268

planowanie iteracji, 75, 278 batman, 288, 290 ceremonia podejmowania zobowiñzaþ, 283 czöĈciowo ukoþczona praca, 287 däugoĈè iteracji, 291 dzienne iteracje, 289 efekty, 290 generowanie zadaþ, 281 harmonogram iteracji, 278 idealne godziny, 282 nagäe Ĕñdania, 287 naprawianie bäödów, 289 ograniczenie czasowe iteracji, 278 planowanie, 279 po sesji planowania, 283 problemy, 286 przeciwwskazania, 290 Ĉledzenie iteracji, 285 utracone iteracje, 286 zadania inĔynieryjne, 280 zarzñdzanie däugimi sesjami planowania, 284 planowanie wydania, 75, 76, 247 czöste udostöpnianie, 247, 250 czöste wydania, 249 daty wydaþ, 254 efekty, 259 elastycznoĈè, 260 horyzont planowania, 256 jeden projekt, 247 kultura organizacji, 258 ostatni moment na podjöcie zobowiñzaþ, 256 przeciwwskazania, 260 przygotowanie planu, 253 przystosowanie planów, 252 w peäni gotowe, 255 wczesne udostöpnianie, 247 zachowanie elastycznoĈci, 253 Platforma Fit, 336 pobieranie, 202 podejmowanie zobowiñzaþ dotyczñcych wydania, 272 podjöcie zobowiñzaþ, 57 podstawowe raporty o postöpach, 174 podwojenie szacunków, 277 poleganie na ludziach, 425 budowanie efektywnych zwiñzków, 425 budowanie procesu dla ludzi, 429 odpowiednie osoby do odpowiednich zadaþ, 427 pomiar zmiennoĈci szybkoĈci, 180 pomieszczenie robocze, 141, 142 porzñdkowanie zalegäoĈci, 79 poĈrednik, 64 powiñzanie, 452 powtarzanie, 343

poziomy wydajnoĈci, 398 praca zespoäu w jednym miejscu, 63 praktyki, 26, 416 praktyki XP, 36, 40 wedäug ról, 52 prawdziwe projektowanie obiektowe, 154 prawo Parkinsona, 299 precyzowanie wspólnego jözyka, 155 primitive obsession, 361 problemy z harmonogramem, 134 proces, 26 ciñgäa integracja, 221 dla ludzi, 429 producenci, 323 produkt, 241 programiĈci, 24, 48 programowanie ekstremalne, 9 strukturalne, 448 zwinne, 19, 23 programowanie w parach, 91, 93, 145, 298, 432 efekty, 100 energiczna praca, 103 komfort, 96 myĈlenie na gäos, 99 narzödzia, 97 niedopasowane umiejötnoĈci, 97 nieparzysta liczba programistów, 99 pilot, 93 pilotowanie, 95 ping-pong w parach, 97 praca zdalna, 100 prowadzñcy, 93 prowadzenie, 95 przeciwwskazania, 100 przepäyw, 93 skróty klawiaturowe, 97 sposób komunikacji, 97 stanowiska pracy, 96 tworzenie par, 94 wyzwania, 96 zmiana partnera, 94 projekt, 448 rozwijany od podstaw, 74 projektanci, 49 grafiki, 47 interakcji, 47 projektowanie, 34 interakcje, 48 obiektowe, 154 pomieszczenie robocze, 141 prognostyczne, 387 refleksyjne, 360, 387 skoncentrowane na dziedzinie, 154

SKOROW DZ 469

promocja wizji, 244 promocja zespoäu, 132 propagowanie wizji, 45 prostota, 373 prosty projekt, 372 efekty, 378 interfejsy udostöpniane, 376 izolowanie niezaleĔnych komponentów, 376 NBTP, 374 Nie bödziesz tego potrzebowaä, 374 ograniczanie liczby interfejsów udostöpnianych, 376 przeciwwskazania, 378 Raz i tylko raz, 374 samodokumentujñcy siö kod, 375 szybkie zgäaszanie bäödów, 377 prowadzñcy, 93 przedstawiciel klienta, 33, 43, 64, 150 przedziaäy czasu, 56 przeglñdy klienckie, 149, 327 przeäom, 382 przepäyw, 93 przeprowadzanie demonstracji iteracji, 167 przeprowadzanie eksperymentów, 391 przeprowadzka do otwartego pomieszczenia roboczego, 143 przepustowoĈè, 398, 437 przerób, 177 przerwy w pracy, 104 przesuwanie testerów do przodu, 80 przesyäanie, 203 przeszukiwanie dwudzielne, 204 przewidywanie daty wydania, 274 przygotowanie plan wydania, 253 pomieszczenie, 140 przyjazny i spójny zespóä, 70 przykäadowe pomieszczenie robocze, 142 przypisywanie ról, 54 przywracanie, 203 punkty funkcyjne, 179 pusty äaþcuch znaków, 345

Q Quality Without a Name, 447 QWAN, 447

R rada do przeglñdów klienckich, 149 raporty, 110, 174 cotygodniowe demonstracje, 175 dla zarzñdu, 174

470 SKOROW DZ

dodatkowe raporty dla zarzñdu, 176 dodatkowe raporty o postöpach, 175 efekty, 181 jakoĈè kodu, 180 liczba opowieĈci, 179 liczba wierszy kodu Ēródäowego, 179 listy elektroniczne z opisem stanu, 176 mapy, 175 o postöpach, 174 plany wydaþ i iteracji, 175 podstawowe raporty o postöpach, 174 przeciwwskazania, 181 przerób, 177 punkty funkcyjne, 179 rodzaje, 174 stan projektu, 180 szybkoĈè, 179 usterki, 177 wizja, 175 wydajnoĈè, 176 wykorzystanie czasu, 177 wykresy wykonanych zadaþ, 175 Raz i tylko raz, 374 raĔñco oczywisty kod, 452 realizacja zobowiñzaþ, 129 refaktoryzacja, 56, 296, 343, 360, 363 analiza istniejñcego kodu, 362 bawienie siö z wartoĈciñ null, 361 baza danych, 369 chirurgia odpryskowa, 360 czöstoĈè, 368 duĔe zmiany projektowe, 369 efekty, 370 Extract Method, 365 IDE, 363 klasy danych, 361 klasy prawie jak statyczne, 361 niepeäne obiekty, 362 niepowodzenie testów, 369 obsesja na punkcie typów prostych, 360 praktyka, 363 projektowanie refleksyjne, 360 przeciwwskazania, 370 sposoby, 363 zaleĔnoĈè w czasie, 362 zapachy kodu, 360 zbitki danych, 360 zróĔnicowane zmiany, 360 refleksyjne projektowanie, 324 reguäy, 421 biznesowe, 334 dziesiöè minut, 383 z dziedziny, 46 repository, 202 repozytorium, 202

retrospekcje, 83, 91, 108, 115 burza mózgów, 116 cele, 118 ciche kategoryzowanie, 117 efekty, 121 iteracje, 115 niespodzianki, 115 po retrospekcji, 119 podstawowa zasada, 116 projekt, 115 przeciwwskazania, 121 przeprowadzanie, 115 przyspieszanie przebiegu, 121 rodzaje, 115 wydania, 115 revert, 203 röczne testy regresji, 50 roll back, 203 rozgaäözianie, 203 rozwaga, 59 rozwiñzania punktowe, 95, 305, 391 efekty, 393 planowanie, 392 przeciwwskazania, 394 przeprowadzanie eksperymentów, 391 tworzenie w parach, 393 rozwiñzywanie sporów, 263 rozwój ewolucyjny, 380 rozwój na potrzeby wäasne, 147 równolegäe przechodzenie przez etapy, 32 równolegäe wprowadzanie zmian, 203 równowaga w projektach, 449 RuntimeException, 365

S samodokumentujñcy siö kod, 375 samodzielna organizacja, 43 samoorganizowanie siö, 428 sandbox, 202 scalanie, 203 scrum, 26 seam, 357 serwer do ciñgäej integracji, 222 sesja eksploracyjna, 404 shotgun surgery, 360 silos wiedzy, 229 skracanie zapasu, 297 skrypt kompilacji, 214 skutecznoĈè komunikacji, 137 skutki czöstych wydaþ, 249 SLOC, 179 säaba wäasnoĈè kodu, 233 smoke test, 357

source lines of code, 179 specjaliĈci do spraw technicznych, 49 specjalne opowieĈci, 304 spis zagroĔeþ, 270 späacanie däugu technicznego, 77, 78, 293, 317, 454 spoäecznoĈè projektowa, 52 udziaäowcy, 52 wäaĈciciel projektu, 52 spójnoĈè, 452 spójnoĈè pamiöci podröcznej, 395 spójnoĈè zespoäu, 70 sprzöt potrzebny w otwartym pomieszczeniu roboczym, 71 srebrne opowieĈci, 300 stabilna szybkoĈè, 318 stabilne szacunki, 311 stan projektu, 180 standardy pisania kodu, 76, 161 efekty, 166 formatowanie kodu, 161 minimalny zbiór standardów, 162 przeciwwskazania, 166 przestrzeganie standardów, 164 radzenie sobie z niezgodñ, 163 ustalanie, 162 stanowiska do pracy w parach, 96 sterowanie refaktoryzacjñ, 386 stopniowa praca, 326 stopniowe projektowanie architektury, 384 stopniowe projektowanie klas, 383 stopniowe projektowanie metod, 382 stopniowe wprowadzanie zmian, 431 stopniowe zbieranie wymagaþ, 325 efekty, 329 funkcje, 326 kryteria ukoþczenia, 326 makiety, 326 ogólne oczekiwania, 326 opowieĈci, 326 przeciwwskazania, 329 przeglñdy z udziaäem klientów, 327 stopniowa praca, 326 testy klienta, 326 wizje, 326 Ĕywa dokumentacja wymagaþ, 325 stopniowy rozwój projektu i architektury, 380 architektura sterowana ryzykiem, 385 ciñgäe projektowanie, 381 efekty, 389 przeciwwskazania, 389 stopniowe projektowanie architektury, 384 stopniowe projektowanie klas, 383 stopniowe projektowanie metod, 382

SKOROW DZ

471

stosowanie fragmentów XP, 82 ciñgäa integracja, 83 dziesiöciominutowa kompilacja, 83 iteracje, 82 retrospekcja, 83 wytwarzanie sterowane testami, 83 stosowanie XP do istniejñcych projektów, 76 naprawa waĔnych bäödów, 79 porzñdkowanie zalegäoĈci, 79 przesuwanie testerów do przodu, 80 späacanie däugu technicznego, 78 wprowadzanie porzñdku w chaos, 78 wyäanianie siö z ciemnoĈci, 80 znaczñce decyzje, 77 stosowanie XP do zupeänie nowych projektów, 74 stosowanie XP w organizacji opartej na etapach, 80 etap analiz, 81 etap pisania kodu, 82 etap planowania, 81 etap projektowania, 81 etap testów, 82 etap wdraĔania, 82 stovepipe systems, 66 styl interfejsu uĔytkownika, 34 Subversion, 208 sukces, 20, 21, 274 osobisty, 24 poziom organizacji, 22, 23 techniczny, 23 syndrom drugiego uĔytkownika, 74 syndrom studenta, 299 system kominowy, 66 system kontroli wersji, 208, 226 szablon deklaracji wizji, 245 szacowanie, 75, 262, 306, 309 dokäadnoĈè, 311 doäñczanie nowych programistów, 318 efekty, 320 idealne dni, 309 koszt opowieĈci, 312 koszt opowieĈci dotyczñcych wydajnoĈci, 399 koszt zadaþ wchodzñcych w skäad iteracji, 314 metody, 309 odciñĔanie programistów, 317 ograniczenie czasowe iteracji, 310 opowieĈci, 320 przeciwwskazania, 321 punkty opowieĈci, 309 späacanie däugu technicznego, 317 stabilne szacunki, 311 szybkoĈè, 309, 319 trudnoĈci, 314 wspieranie energicznej pracy, 317

472 SKOROW DZ

wyjaĈnianie szacunków, 315 zaleĔnoĈci techniczne w opowieĈciach, 320 zapewnianie niezbödnych zasobów, 318 zebrania klientów, 314 zwiökszanie szybkoĈci, 317 zwiökszanie zaangaĔowania klientów, 317 szanowanie celów klientów, 131 szukanie mentora, 28 szwy, 357 szybkie wykrywanie niepowodzeþ, 433, 453 szybkie zgäaszanie bäödów, 377 szybkoĈè, 58, 179, 309, 319 wytwarzanie sterowane testami, 353 szybkoĈè reagowania, 398

Ļ Ĉcisäa wäasnoĈè kodu, 232 Ĉledzenie iteracji, 285 Ĉmiaäe programowanie, 236

T tablice z efektami sesji projektowania, 108 TDD, 34, 35, 193, 298, 339 teoria ograniczeþ, 58 test-driven development, 339 testerzy, 24, 49, 335 testNull(), 346 testowanie, 35 graniczne, 405 procesy, 196 testy akceptacji, 39, 337 funkcjonalne, 337 integracji, 355 jednostek, 215, 354 jednostek logiki kodu ukrytego, 362 kompleksowe, 355, 356 regresji, 35, 50 wstöpne, 357 wydajnoĈci, 397 testy eksploracyjne, 39, 40, 197, 402 ataki zwiñzane z typami danych, 406 CRUD, 406 czynnoĈci po znalezieniu bäödu, 408 deklaracja, 403 efekty, 410 heurystyki, 405 liczba: zero, jeden, wiele, 405 notatki, 404 obserwacja, 404 pozycja: poczñtek, Ĉrodek, koniec, 405

przeciwwskazania, 410 sesja eksploracyjna, 404 testerzy, 409 unikanie usterek, 402 wstrzykniöcie polecenia, 406 wymiana sztuczek i technik, 409 zbieranie informacji zwrotnych, 409 zäotowäosa: za duĔe, za maäe, w sam raz, 405 Ĕadne, kilka, wszystkie, 405 testy klienta, 34, 39, 168, 331 automatyzacja przykäadów, 336 demonstracja, 332 efekty, 337 kierowanie przez klientów, 335 koncentracja na reguäach biznesowych, 334 opis, 331 przeciwwskazania, 338 testerzy, 335 wytwarzanie, 333 the planning game, 33 Throwable, 393 time dependency, 362 timeboxing, 57 TortoiseSvn, 208 tradycyjny cykl Ĕycia, 30 tworzenie deklaracja wizji, 243 diagramy usprawniania procesu, 109 pary, 94 testy jednostek, 354 testy wydajnoĈci, 397

U uczciwoĈè, 132 udostöpnianie, 183 brak bäödów, 191 ciñgäa integracja, 219 dokumentacja, 234 dziesiöciominutowa kompilacja, 211 kontrola wersji, 202 mapa strumienia wartoĈci, 184, 185 w peäni gotowe, 186 wspóäwäasnoĈè kodu, 229 udziaäowcy, 24, 52 UI, 34 ukryte koszty, 186 umiar, 297 uniemoĔliwianie pomyäek, 197 unikanie usterek, 402 update, 202 upraszczanie, 452 procesy, 435

usprawnianie procesu, 197, 419 adaptacja, 420 dopracowywanie, 420 äamanie reguä, 421 zrozumienie projektu, 419 ustalanie data wydaþ, 254 standardy pisania kodu, 162 wizja, 242 wynagrodzenie, 135 usterki, 177, 196 utracone iteracje, 286 utrzymywanie porzñdku, 206 uĔytkownicy, 24

V valueFor(), 347 verify_order_id(), 395 Visual SourceSafe, 208 VSS, 208

W w peäni gotowe, 186, 441 efekty, 189 oprogramowanie w wersji produkcyjnej, 186 planowanie wydania, 255 przeciwwskazania, 190 testerzy, 189 zapewnianie peänej gotowoĈci, 187 znajdowanie czasu, 188 waga ryzyka, 271 wannabee static class, 361 wartoĈci, 415, 416 null, 361 wartoĈè kodu, 183 wczesne udostöpnianie, 247 wersje beta, 252 WHET, 409 wiedza z dziedziny, 46 wiele par nazwa-wartoĈè, 348 wielkoĈè zapasu, 293 wielkoĈè zespoäu, 54, 65 wierzchoäek, 203 wizja, 40, 45, 76, 103, 241 deklaracja, 243 dokumentowanie, 242 efekty, 246 kryteria sukcesu, 243 pochodzenie, 241 produkt, 241 promocja, 244

SKOROW DZ 473

wizja przeciwwskazania, 246 spory, 245 szablon deklaracji, 245 ustalanie, 242 wizjoner, 241 wäaĈciciel produktu, 45 wäaĈciciel projektu, 52 wolny czas, 102 working agreement, 73 wpäyw czöstych wydaþ na wartoĈè, 248 wpäyw równolegäego wykonywania zadaþ na wartoĈè, 248 wprowadzanie ciñgäa integracja, 222 porzñdek w chaos, 78 zapas, 77, 293 zmiany, 72 wprowadzanie XP, 61 doĈwiadczony coach programista, 69 jözyk äatwy do refaktoryzacji, 69 nieformalne ustalenia dotyczñce wspóäpracy, 73 nowy kod bazowy, 68 odpowiednia wielkoĈè zespoäu, 65 oprogramowanie, 72 praca zespoäu w jednym miejscu, 63 przedstawiciele klientów, 64 przyjazny i spójny zespóä, 70 sprzöt, 71 stosowanie do istniejñcych projektów, 76 stosowanie do zupeänie nowych projektów, 74 stosowanie w organizacji opartej na etapach, 80 stosowanie wszystkich praktyk, 67 wsparcie zarzñdu, 62 wysokie umiejötnoĈci w obszarze projektowania, 68 wyzwania, 72 zgoda zespoäu, 63 wraĔenie, 128 wsparcie zarzñdu, 62 wspieranie energicznej pracy, 317 wspomaganie energicznej pracy, 103 wspólna praca, 137 doskonaäa komunikacja, 138 efekty, 145 haäas, 144 maäe pomieszczenie robocze, 142 projektowanie pomieszczenia roboczego, 141 prywatnoĈè, 144 przeciwwskazania, 145 przeprowadzka do otwartego pomieszczenia roboczego, 143

474 SKOROW DZ

przygotowanie pomieszczenia, 140 radzenie sobie z nieskutecznñ komunikacjñ, 137 skutecznoĈè komunikacji, 137 wspólne spoĔywanie posiäków, 127 wspólny jözyk, 152 dwa jözyki, 152 efekty, 155 kod, 154 model dziedziny, 154 posäugiwanie siö tym samym jözykiem, 153 precyzowanie wspólnego jözyka, 155 problem wiedzy z dziedziny, 152 przeciwwskazania, 156 wspóäpraca, 123 demonstracje iteracji, 167 karteczki, 124 krótkie spotkania robocze, 157 raporty, 174 standardy pisania kodu, 161 wspólna praca, 137 wspólny jözyk, 152 zaangaĔowanie prawdziwego klienta, 147 zaufanie, 126 wspóäwäasnoĈè kodu, 229 efekty, 232 kod bazowy, 231 konflikty w czasie scalania, 231 praca nad nieznanym kodem, 229 przeciwwskazania, 232 silos wiedzy, 229 säaba wäasnoĈè, 233 Ĉcisäa wäasnoĈè, 232 ukryte korzyĈci, 230 zapewnianie, 229 wstöpne planowanie wydaþ, 260 wstrzykniöcie polecenia, 406 wydajnoĈè, 398 akceptowalna, 398 optymalna, 398 proces rozwoju oprogramowania, 176 wyjaĈnianie, 452 wyjaĈnianie szacunków, 315 wykazywanie siö aktywnoĈciñ, 129 wykorzystanie czasu, 177 wykresy wykonanych zadaþ, 175 wykrywanie niepowodzeþ, 433 wyäanianie siö z ciemnoĈci, 80 wymagania, 34 wymyĈlanie metod, 27 wyniki biznesowe, 442 wysoka jakoĈè projektu, 380 wysoka przepustowoĈè, 436 wysokie umiejötnoĈci w obszarze projektowania, 68

wyspecjalizowane testy integracji, 355 wytwarzanie, 323, 333 optymalizacja wydajnoĈci, 395 prosty projekt, 372 refaktoryzacja, 360 rozwiñzania punktowe, 391 stopniowe zbieranie wymagaþ, 325 stopniowy rozwój projektu i architektury, 380 testy eksploracyjne, 402 testy klienta, 331 wytwarzanie sterowane testami, 34, 83, 94, 193, 298, 339 count(), 349 cykl, 341 czerwony pasek, 342 efekty, 358 jedna para nazwa-wartoĈè, 344 metody prywatne, 358 myĈlenie, 341 narzödzia do testowania, 352 odziedziczony kod, 356 powtarzanie, 343 przeciwwskazania, 358 pusty äaþcuch znaków, 345 refaktoryzacja, 343, 358 skutecznoĈè, 339 stosowanie, 340 szybkoĈè, 353 testNull(), 346 testy jednostek, 354 testy kompleksowe, 356 testy wstöpne, 357 tworzenie interfejsu uĔytkownika, 358 valueFor(), 347 wiele par nazwa-wartoĈè, 348 wyspecjalizowane testy integracji, 355 zielony pasek, 342

X XP, 9, 23, 27, 29 analitycy biznesowi, 48 architektura, 34 coachowie, 50 cykl Ĕycia, 32 däug techniczny, 56 ekspert z dziedziny, 46 etapy, 36 instalacja, 35 iteracje, 57 myĈlenie, 91 opowieĈci, 57 ostatni moment na podjöcie zobowiñzaþ, 57

planowanie, 33 podejĈcie do rozwoju oprogramowania, 39 praktyki, 40 praktyki wedäug ról, 52 programiĈci, 48 projektanci interakcji, 47 projektowanie interakcji, 48 projekty, 34 przedstawiciele klienta, 43 przedziaäy czasu, 56 przypisywanie ról, 54 refaktoryzacja, 56 rozwaga, 59 równolegäe przechodzenie przez etapy, 32 samodzielna organizacja, 43 spoäecznoĈè projektowa, 52 szybkoĈè, 58 Ĉcisäa pötla informacji zwrotnych, 33 teoria ograniczeþ, 58 testerzy, 49 testowanie, 35 testy eksploracyjne, 40 wielkoĈè zespoäu, 54 wizja, 40, 45 wprowadzanie, 61 wytwarzanie sterowane testami, 34 zarzñdzanie ryzykiem, 40 zespoäy wielofunkcyjne, 43 zespóä, 42 xUnit, 352, 397

Y yang, 102 yin, 102

Z zaangaĔowanie klientów, 44 zaangaĔowanie prawdziwego klienta, 147 efekty, 150 niestandardowe rozwiñzania wewnötrzne, 147 niestandardowe rozwiñzania zewnötrzne, 148 oprogramowanie do sprzedaĔy publicznej, 149 oprogramowanie specjalistyczne, 149 przeciwwskazania, 150 przedstawiciel klienta, 150 rozwój na potrzeby wäasne, 147 zadania inĔynieryjne, 280 zagroĔenia specyficzne dla projektu, 269 zaleĔnoĈè w czasie, 362 zapachy kodu, 360

SKOROW DZ 475

zapas, 77, 293 czas na naukö, 295 efekty, 299 grupy wspólnej nauki, 300 niewielka liczba nieobowiñzkowych nadgodzin, 296 przeciwwskazania, 299 refaktoryzacja jako zabezpieczenie, 296 rezygnacja z czasu na naukö, 297 skracanie, 297 späacanie däugu technicznego, 293 srebrne opowieĈci, 300 umiar, 297 wielkoĈè, 293 wprowadzanie, 293 zapewnianie ciñgäoĈè zespoäu, 128 korzyĈci dla firmy, 21 niezbödne zasoby, 318 peäna gotowoĈè, 187 sukces techniczny, 23 wspóäwäasnoĈè kodu, 229 wyniki biznesowe, 442 zapewnianie wartoĈci, 439 czöste udostöpnianie, 444 kod gotowy do udostöpnienia, 441 wyniki biznesowe, 442 zwinnoĈè, 439 zapobieganie usterkom w obszarze zabezpieczeþ, 199 zarzñd, 62 zarzñdzanie däugie sesje planowania, 284 problemy, 130 sieciowe, 55 Ĉrodowisko programistyczne 34 wizja, 45 zarzñdzanie ryzykiem, 40, 268 diagram wykonanych zadaþ, 273 dziaäania äagodzñce, 271 dziaäania naprawcze, 271 efekty, 276 harmonogram, 274, 275 ignorowanie ryzyka, 271 kontrola zagroĔeþ, 272 mnoĔniki zarzñdzania ryzykiem, 269 plan zarzñdzania ryzykiem, 268 podejmowanie zobowiñzaþ dotyczñcych wydania, 272 podwojenie szacunków, 277 przeciwwskazania, 276 przewidywanie daty wydania, 274 spis zagroĔeþ, 270

476 SKOROW DZ

sukces, 274 udziaäowcy, 275 waga ryzyka, 271 wskaĒniki ostrzegawcze, 271 zagroĔenia specyficzne dla projektu, 269 zagroĔenia wyjñtkowe, 270 zasady, 415, 416 zasady zwinnej filozofii, 26 zatwierdzanie, 203 zaufanie, 126 ciñgäoĈè zespoäu, 128 efekty, 135 empatia miödzy klientem a programistñ, 126 empatia miödzy programistami a testerami, 127 etap docierania, 134 promocja zespoäu, 132 przeciwwskazania, 135 realizacja zobowiñzaþ, 129 szanowanie celów klientów, 131 uczciwoĈè, 132 wraĔenie, 128 wspólne spoĔywanie posiäków, 127 wykazywanie siö aktywnoĈciñ, 129 zarzñdzanie problemami, 130 zbitki danych, 360 zerowy poziom bäödów, 192 zespoäowe wytwarzanie oprogramowania, 43 zespoäy stosujñce XP, 33, 42, 43 analitycy biznesowi, 48 architekci, 49 coach programista, 51 coachowie, 50 eksperci z dziedziny, 46 menedĔer produktu, 45 menedĔer projektu, 51 ocena zwinnoĈci zespoäu, 83 peänoetatowi czäonkowie zespoäu, 55 programiĈci, 48 projektanci, 49 projektanci interakcji, 47 przedstawiciele klienta, 43 specjaliĈci do spraw technicznych, 49 testerzy, 49 wielkoĈè zespoäu, 54, 65 zespoäy wielofunkcyjne, 43 zgoda zespoäu, 63 zielony pasek, 342 zmiana oczekiwaþ, 198 zmienna potencjalna wartoĈè oprogramowania, 183 zmiennoĈè szybkoĈci, 180 zmniejszanie iloĈè dokumentacji, 235 ryzyko, 386

znacznik, 203 znajdowanie czasu, 188 zobowiñzania, 283 zrozumienie projektu, 419 zróĔnicowane zmiany, 360 zwiökszanie moce umysäowe, 93 szybkoĈè, 317 zaangaĔowanie klientów, 317

zwinne metody, 26 zwinne miotanie siö, 39 zwinne wytwarzanie oprogramowania, 9, 19, 25 manifest zwinnoĈci, 25 zwinnoĈè, 439 zespoäy, 83

ś Ĕywa dokumentacja wymagaþ, 325

SKOROW DZ 477