Agile Software Development. Gra zespołowa. Wydanie II

Wydawnictwo Helionul. Ko�ciuszki 1c44-100 Gliwicetel. 032 230 98 63e-mail: [email protected]

Agile Software Development. Gra zespo³owa. Wydanie IIAutor: Alistair CockburnT³umaczenie: Rafa³ JoñcaISBN: 978-83-246-1503-2Tytu³ orygina³u: Agile Software Development: The Cooperative Game (2nd Edition) (The Agile Software Development Series)Format: 170x230, stron: 480

Poznaj zasady doskona³ej metodologii wytwarzania oprogramowania

� Jak dopasowaæ metodologiê Agile do specyfiki firmy?� W jaki sposób powi¹zaæ Agile z innymi metodologiami?� Jak wdro¿yæ Agile w ca³ej strukturze firmy?

Produkcja oprogramowania wymaga nie tylko doskona³ej znajomo�ci technologii, ale tak¿e metodologii zarz¹dzania projektem. Kluczowym elementem jest tu umiejêtno�æ b³yskawicznego reagowania na zmiany, sytuacje kryzysowe i b³êdy. Istnieje wiele usystematyzowanych metodologii wytwarzania oprogramowania, które jednak rzadko sprawdzaj¹ siê w przypadku ma³ych zespo³ów projektowych lub projektów realizowanych w krótkim czasie. Dla takich projektów opracowano metodologiê Agile. To �zwinne programowanie� zdobywa coraz wiêcej zwolenników i jest wdra¿ane w wielu przedsiêbiorstwach.

Ksi¹¿ka �Agile Software Development: The Cooperative Game (2nd Edition) (The Agile Software Development Series)� to omówienie metodologii Agile i in¿ynierii oprogramowania. Czytaj¹c j¹, poznasz za³o¿enia zwinnego programowania i sposoby zarz¹dzania projektem, zgodne z wytycznymi tej metodologii. Dowiesz siê, jakie ograniczenia posiada Agile i jak sobie z nimi radziæ. Przeczytasz o programowaniu ekstremalnym, adaptacji tej metodologii do potrzeb konkretnych zadañ i unikaniu b³êdów przy wytwarzaniu oprogramowania.

� Zasady in¿ynierii oprogramowania� Dobór zespo³u projektowego� Komunikacja wewn¹trz zespo³u projektowego� Wybór odpowiedniej metodologii� Programowanie ekstremalne� Zarz¹dzanie zmianami� Metodologie Crystal

Poznaj wydajne i efektywne zwinne programowanie!

http://helion.pl/view/2547w



http://helion.pl/add/2547w/agilsd




mailto:[email protected]

http://helion.pl/view/2547w/agilsd.htm

http://helion.pl/view/2547w/agilsd.htm

5

SPIS TREŚCI

SPIS RYSUNKÓW I TABEL 9

SPIS OPOWIADAŃ 15

PRZEDMOWA 19

PRZEDMOWA DO DRUGIEGO WYDANIA 29

ROZDZIAŁ 0. NIEWIADOME I NIEKOMUNIKATYWNE 33

Problem z analizą doświadczenia ................................................................ 35Niemożność komunikacji .............................................................................. 39Trzy poziomy słuchania ................................................................................ 44Co zatem będę robił jutro? ............................................................................ 49

ROZDZIAŁ 0.1. NIEWIADOME I NIEKOMUNIKATYWNE — EWOLUCJA 51

Komunikacja i wspólne doświadczenia ...................................................... 53Shu-ha-ri ........................................................................................................... 54

ROZDZIAŁ 1. GRA ZESPOŁOWA POMYSŁOWOŚCI I KOMUNIKACJI 57

Oprogramowanie i poezja ............................................................................. 59Oprogramowanie i gry .................................................................................. 60Drugie spojrzenie na grę zespołową ........................................................... 66Co to oznacza dla mnie? ................................................................................ 73

ROZDZIAŁ 1.1. ZESPOŁOWA GRA POMYSŁOWOŚCI I KOMUNIKACJI — EWOLUCJA 75

Gra bagienna ................................................................................................... 77Współzawodnictwo we współpracy ............................................................ 78Inne miejsca z grą zespołową ....................................................................... 80Raz jeszcze o inżynierii oprogramowania .................................................. 80

6 • SPIS TREŚCI

ROZDZIAŁ 2. POJEDYNCZE OSOBY 93

Ci dziwni ludzie ...............................................................................................95Obchodzenie trybów porażki ........................................................................99Lepsze działanie w jednych aspektach niż w innych .............................107Korzystanie z trybów sukcesu .....................................................................118Co powinienem zrobić jutro? ......................................................................124

ROZDZIAŁ 2.1. POJEDYNCZE OSOBY — EWOLUCJA 125

Równoważenie strategii ...............................................................................127

ROZDZIAŁ 3. KOMUNIKACJA I WSPÓŁPRACA ZESPOŁÓW 131

Sposoby przepływu informacji ...................................................................133Zasklepianie luk komunikacyjnych ...........................................................147Zespoły jako społeczności ............................................................................155Zespoły jako ekosystemy .............................................................................164Co zatem będę robił jutro? ...........................................................................166

ROZDZIAŁ 3.1. ZESPOŁY — EWOLUCJA 167

Ponowne spojrzenie na prosty układ biura ..............................................169

ROZDZIAŁ 4. METODOLOGIE 171

Ekosystem, który dostarcza oprogramowanie .........................................173Pojęcia metodologiczne ................................................................................173Zasady projektowania metodologii ...........................................................198XP od kuchni ..................................................................................................221Dlaczego w ogóle zajmować się metodologiami? ....................................225Co zatem będę robił jutro? ...........................................................................227

ROZDZIAŁ 4.1. METODOLOGIE — EWOLUCJA 229

Metodologie kontra strategie ......................................................................231Metodologie w całej organizacji .................................................................232Procesy jako cykle .........................................................................................233Opisanie metodologii prostszymi słowami ...............................................236

SPIS TREŚCI • 7

ROZDZIAŁ 5. ZWINNOŚĆ I ADAPTACJA 239

Lekko, aczkolwiek wystarczająco .............................................................. 241Zwinność ........................................................................................................ 243Dostosowywanie się ..................................................................................... 250Co zatem będę robił jutro? .......................................................................... 260

ROZDZIAŁ 5.1. ZWINNOŚĆ I ADAPTACJA — EWOLUCJA 261

Sprostowanie błędnego zrozumienia przekazu ...................................... 264Ewolucja metodologii zwinnych ................................................................ 281Nowe zagadnienia metodologii ................................................................. 293Powracające pytania ..................................................................................... 309Zwinność poza tworzeniem oprogramowania ........................................ 329

ROZDZIAŁ 6. METODOLOGIE CRYSTAL 353

Kształt rodziny Crystal ................................................................................. 355Crystal Clear .................................................................................................. 358Crystal Orange .............................................................................................. 360Crystal Orange Web ..................................................................................... 362Co zatem będę robił jutro? .......................................................................... 366

ROZDZIAŁ 6.1. METODOLOGIE CRYSTAL — EWOLUCJA 367

Genetyczny kod Crystal .............................................................................. 369Crystal Clear .................................................................................................. 374Rozciąganie Crystal Clear do Yellow ......................................................... 376

DODATEK A MANIFEST ZWINNEGO WYTWARZANIA OPROGRAMOWANIA 383

Agile Alliance ................................................................................................. 385Manifest .......................................................................................................... 386Wspieranie wartości ..................................................................................... 388

DODATEK A.1 MANIFEST ZWINNEGO WYTWARZANIA OPROGRAMOWANIA

I „DEKLARACJA WZAJEMNEJ ZALEŻNOŚCI” 395

Nowa odsłona manifestu zwinności ......................................................... 397Deklaracja wzajemnej zależności ............................................................... 400

8 • SPIS TREŚCI

DODATEK B NAUR, EHN, MUSASHI 407

Peter Naur, „Programowanie jako budowanie teorii” ............................409Pelle Ehn. Gry językowe Wittgensteina ....................................................419Musashi ...........................................................................................................431

DODATEK B.1 NAUR, EHN, MUSASHI — EWOLUCJA 437

Naur .................................................................................................................439Ehn ...................................................................................................................439Musashi ...........................................................................................................439

DODATEK C SŁOWO KOŃCOWE 441

Zwinne wytwarzanie oprogramowania ....................................................443Biznes jako gra zespołowa ...........................................................................444Przywództwo .................................................................................................444Wszyscy ..........................................................................................................445

DODATEK D BIBLIOGRAFIA 447

SKOROWIDZ 461

239

5Zwinność i adaptacja

Mamy już wszystkie elementy układanki. Dowiedziałeś się, że:

• Tworzenie oprogramowania jest grą zespołową pomysłowości i komuni-kacji.

• Ludzie są dziwni, ale dobrzy w spoglądaniu wokoło, przejmowaniuinicjatywy i bezpośredniej komunikacji twarzą w twarz.

• Metodologia to zestaw konwencji stosowanych przez zespół, przy czymróżne konwencje sprawdzają się w różnych rodzajach projektów.

• Lekkie metodologie pozwalają dostarczać oprogramowanie szybciej, alewraz z powiększaniem się zespołu potrzeba cięższych metodologii.

• Projekty to unikatowe ekosystemy, więc trzeba tak dobierać metodo-logię, by pasowała do ekosystemu projektu.

Wszystko do siebie ładnie pasuje, ale… jaka lekkość jest odpowiedniadla danego projektu i jak mamy zastosować wspomniane zasady w naszymkonkretnym projekcie?

Podrozdział „Lekko, aczkolwiek wystarczająco” wskazuje, jaka lekkość jestodpowiednia dla danego projektu, a w szczególności, co oznacza bycie zbytlekkim. Naszym celem jest zrównoważenie lekkości i wystarczalności.

Podrozdział „Zwinność” omawia znaczenie pewnych „istotnych miejsc”projektu: kolokację, bliskość użytkowników, doświadczenie programistówitp. Gdy projekt oddala się od tych istotnych miejsc, trzeba w nim stosowaćmniej zwinne mechanizmy. W szczególności zespoły wirtualne znaczącoutrudniają wprowadzenie w życie zasad zwinności, bo są od siebie mocnooddalone.

Podrozdział „Dostosowywanie się” opisuje technikę tworzenia lekkiej, acz-kolwiek wystarczającej metodologii osobistej, która może przynieść korzyśćprojektowi. Kluczową sprawą okazuje się analiza co kilka tygodni, co poszłodobrze, a co należy zmienić.

240

Zwinność i adaptacja

LEKKO, ACZKOLWIEK WYSTARCZAJĄCO......................................241Ledwo wystarczające ................................................................................... 242Zalecenia dotyczące dokumentacji ............................................................ 243

ZWINNOŚĆ ...........................................................................243Punkty krytyczne.......................................................................................... 244Problem z zespołami wirtualnymi ............................................................. 246

DOSTOSOWYWANIE SIĘ ...........................................................250Potrzeba analizy przeszłych działań ......................................................... 250Technika rozwoju metodologii................................................................... 250Sposoby analizy projektu ............................................................................ 258

CO ZATEM BĘDĘ ROBIŁ JUTRO? ................................................260

Lekko, aczkolwiek wystarczająco • 241

LEKKO, ACZKOLWIEKWYSTARCZAJĄCO

Przedstawiona do tej pory teoria wskazuje, byprzede wszystkim stosować przekaz ustny dopropagowania wszystkich informacji zebra-nych w trakcie realizacji projektu.

Nasza intuicja podpowiada nam, że prze-kaz ustny nie wystarcza.

POSZUKIWANIE DOKUMENTACJ I

Pewien programista zaproponował swojejfirmie ponowne napisanie jej flagowegoproduktu, ponieważ nie było do niegodokumentacji, żadna z pozostałych osóbnie znała szczegółów powstania systemui nie potrafiła wykonać niezbędnych mody-fikacji. Powiedział również, że ma nadzieję,że po nowym projekcie pozostanie doku-mentacja.

Ktoś inny opowiedział mi o trzech pro-jektach, które miały bazować na jednymi tym samym oryginalnym projekcie. Wszyst-kie trzy miały być wytwarzane w rożnychmiejscach. Stwierdził również, że w takiejsytuacji przekaz ustny po prostu nie maprawa bytu.

Jest całkiem możliwe, że zdobyte informacjebyły za mało „lepkie”. Warto jeszcze raz przyj-rzeć się zasadzie gry zespołowej:

Głównym celem jest dostarczenie opro-gramowania; celem drugorzędnym jest przy-gotowanie się do następnej rozgrywki.

Powody osiągnięcia pierwszego celu sąoczywiste — jeśli nie dostarczymy oprogra-mowania, nie ma znaczenia, jak dobrze przy-gotowywaliśmy się do następnej gry.

Jeśli jednak dostarczymy oprogramowa-nie i słabo przygotujemy się do następnejrozgrywki, podcinamy sobie skrzydła.

Obydwa działania konkurują ze sobą.Zrównoważenie dwóch konkurujących dzia-łań wymaga dwóch umiejętności.

Pierwsza polega na prawidłowym zga-dywaniu, w jaki sposób zaalokować zasobydla każdego z celów. W idealnej sytuacjidokumentowanie należałoby odkładać najak najpóźniejszy czas, a następnie tworzyćjak najmniejsze dokumenty. Zbyt rozbudo-wana dokumentacja wykonywana zbyt wcze-śnie opóźnia dostarczenie oprogramowania.Jeśli jednak zbyt małą dokumentację robimyzbyt późno, może się okazać, że odeszła osoba,która wiedziała coś istotnego dla następnegoprojektu.

Druga umiejętność polega na odgadnię-ciu, jak wiele można związać z tradycją ustnągrupy, a ile należy umieścić w dokumenta-cji. Zauważ, że w pewnym momencie niema znaczenia, czy modele i inna dokumen-tacja są kompletne i czy idealnie odpowiadająrzeczywistemu systemowi lub czy są zgodnez aktualną wersją kodu. Ważne jest tylko, czyosoby, które będą czytały dokumentację, znaj-dą w niej potrzebne informacje.

Odpowiednia ilość dokumentacji to do-kładnie tyle, ile potrzeba, by ktoś mógł wyko-nać następny ruch w grze. Każdy dodatkowywysiłek włożony w dokumentowanie modeliponad tę kwestię jest stratą pieniędzy.

Bardzo często osoby, które przesłuchi-wałem w związku z udanym projektem,mówiły, że udało im się „pomimo oczywi-stych braków w dokumentacji i dziwacznegoprocesu” (to ich słowa, nie moje). Analizującte wypowiedzi w nowym świetle, nietrudnodomyślić się, że odnieśli sukces dlatego, żedokonali dobrego wyboru i zaprzestali pracnad pewnymi kanałami komunikacji od razupo tym, jak osiągnęli wystarczający poziomzrozumienia. Wykonali odpowiednią pracędokumentacyjną, ale jej nie doskonalili.

242 • Rozdział 5. Zwinność i adaptacja

Adekwatność to doskonały warunek, jeślizespół musi szybko gnać w kierunku głównegocelu, a nie ma wielu zasobów.

Przypomnijmy programistę, który powie-dział:

„Jest dla mnie oczywiste, że gdy zaczy-nam tworzyć przypadki użycia, modeleobiektów itp., moja praca ma jakieśznaczenie. Ale w pewnym momencieprzestaje ona być użyteczna, stając sięproblemem i źródłem strat. Nie potra-fię wykryć przekroczenia tego punktui nigdy nie słyszałem dyskusji na tentemat. To bardzo denerwujące, ponie-waż użyteczne działania zamieniają sięw stratę czasu”.

Poszukujemy punktu, w którym użytecznapraca staje się balastem. To druga z wymie-nionych umiejętności.

LEDWO WYSTARCZAJĄCE

Sądzę, że nie muszę dawać przykładów zbytciężkich lub zbyt lekkich metodologii. Więk-szość programistów widziała lub słyszaławiele takich przykładów.

Z drugiej strony „jedynie trochę za lek-kie” metodologie są trudne do znalezieniai wyjątkowo przydatne naukowo. To dziękinim dowiadujemy się, co oznacza wyrażenieledwo wystarczający.

We wcześniejszej części książki pojawiłysię dwie tego rodzaju historie: „Ciągły brakdokumentacji” i „Przyklejanie myśli do ścia-ny”. W każdej z nich dobrze działający projektw kluczowym momencie przechodził poniżejpoziomu wystarczalności.

CIĄGŁY BRAK DOKUMENTACJ I

(POWTÓRKA)Ten zespół stosował wszystkie praktyki XPi dostarczał oprogramowanie klientowiw określonym czasie. Po kilku latach spon-sor spowolnił prace projektowe, aż wreszcieje zatrzymał.

Gdy zespół przestał istnieć, po syste-mie nie pozostała żadna pisana doku-mentacja, więc żadna z innych osób niemogła poznać szczegółów jego budowy.Wystarczająca dawniej kultura werbalnaprzestała wystarczać.

W tej historii zespół osiągnął podstawowy celgry, dostarczył działający system, ale nie udałomu się przygotować do następnej gry zwią-zanej z pielęgnacją i modyfikacją systemu.

Ktoś może wykorzystać moją własną lo-gikę przeciwko mnie, argumentując, że ilośćdokumentacji okazała się wprost idealna dlapotrzeb firmy — projekt został anulowany,nigdy go nie wznowiono, więc poprawnąi minimalną ilością dokumentacji okazał sięjej brak!

Zauważmy jednak, że zgodnie z „progra-mowaniem jako budowaniem teorii” Nauramożemy stwierdzić, że zespół stworzył wła-sną teorię w trakcie tworzenia oprogramo-wania, ale nie pozostawił wystarczającychśladów, by następny zespół mógł skorzystaćz ich doświadczeń.

PRZYKLEJANIE MYŚL I DO ŚCIANY

(POWTÓRKA)Analitycy nie mogli poradzić sobie z dzie-dziną, która była zbyt złożona. Właśnieprzeszli z ciężkiego procesu na XP i sądzili,że nie wolno im tworzyć żadnej papierowejdokumentacji.

Mijały miesiące i mieli coraz to większeproblemy ze zdecydowaniem się na szcze-góły następnych etapów prac i wskazanie

Zwinność • 243

implikacji swoich decyzji. Znaleźli się poni-żej linii wystarczalności dla swojej gry. Abyuzdrowić projekt, musieli zacząć tworzyćwięcej dokumentacji.

W pewnym momencie dostrzegli tęsytuację i zaczęli tworzyć dokumentację,która pozwoliła im osiągnąć poziom wy-starczalności.

Warto zauważyć, że „niewystarczalność” niejest związana bezpośrednio z metodologią,ale raczej z brakiem dopasowania metodo-logii i projektu jako ekosystemu. To, co jestledwo wystarczające dla jednego zespołu,może być aż nadto wystarczające lub nie-wystarczające dla innego. Niewystarczalnośćpojawia się, gdy członkowie zespołu niekomunikują się ze sobą wystarczająco dobrze,by zapewnić efektywne przekazywanie in-formacji.

Wartość idealna, „ledwo wystarczalna”,zależy od rodzaju projektu i wielu innychczynników. Ta sama metodologia może byćnadmiarowa w jednej części projektu, a nie-wystarczająca w innej jego części.

Druga umiejętność polega na znalezieniupunktu „ledwo wystarczalny” przy każdejwiększej zmianie elementów projektu.

ZALECENIA DOTYCZĄCE DOKUMENTACJI

Oto kilka zaleceń związanych z tworzeniemdokumentacji.

• Nie proś o to, by wymagania były dosko-nałe, dokumenty projektowe zawsze aktu-alne i odzwierciedlające stan kodu, a planprojektu zawsze odpowiadał jego aktual-nemu stanowi.

• Proś, by wymagania zawierały wystarcza-jącą ilość informacji, by zapewnić wydajnąpracę projektantów. Proś o zastępowaniedokumentacji szybszymi środkami komu-

nikacji, jeśli to tylko możliwe, włączającw to wizyty osobiste lub krótkie klipywideo.

• Jeśli projektanci są ekspertami w swejdziedzinie i siedzą blisko siebie, poprośo zastąpienie dokumentacji projektowejrysunkami na tablicy, a następnie zróbzdjęcia tych rysunków.

• Pamiętaj jednak, o tym, że inne osobyprzychodzące po zespole projektowymmogą wymagać bardziej szczegółowej do-kumentacji.

• Niech dokumentacja będzie zadaniemrównoległym, odzwierciedlającym walkęo zasoby, a nie liniową ścieżką przez całyproces tworzenia oprogramowania.

• Staraj się być możliwie pomysłowy w kwe-stii osiągania obu celów, ale unikaj byciaidealnym, bo to kosztuje zbyt wiele.

• Szukaj (używam tu nieco przesadzonychprzymiotników) najlżejszej i najmniejperfekcyjnej metodologii, która sprostawyznaczonemu zadaniu. Z drugiej stronyzapewnij wystarczająco mocną i rygory-styczną komunikację.

ZWINNOŚĆ

Zwinność zakłada efektywność i manewro-wość. Proces zwinny jest zarówno lekki, jaki wystarczający. Lekkość pozwala zachowaćzwrotność. Wystarczalność ma związek z chę-cią pozostania danej osoby w grze.

Pytaniem związanym z metodologią zwin-ną nie jest: „Czy mogę w tej sytuacji zastoso-wać metodologię zwinną?”, lecz: „Jak w tejsytuacji pozostać zwinnym?”.

Czterdziestoosobowy zespół nie będzie taksamo zwinny jako sześcioosobowy, znajdującysię w jednym pokoju. Każdy zespół może jed-nak starać się zmaksymalizować zastosowanie


zasad metodologii zwinnej, by być możliwielekkim i szybkim. Zespół czterdziestoosobowybędzie musiał zastosować cięższą metodologięzwinną; mniejszy zespół może sobie pozwo-lić na lżejszą. Oba zespoły powinny skupićsię na komunikacji, społeczności, częstymwygrywaniu i informacjach zwrotnych.

Jeśli zespoły będą uważały, będą okresowosprawdzały dopasowanie stosowanej meto-dologii do ekosystemu i ewentualnie prze-mieszczenia punktu „ledwo wystarczalny”.

PUNKTY KRYTYCZNE

Częścią bycia zwinnym jest identyfikacjakrytycznych punktów wydajnego tworzeniaoprogramowania, a następnie przesuwanieprojektu tak blisko tych punktów, jak tomożliwe.

Zespół, któremu uda się dostosować dojednego z punktów krytycznych, zaczynakorzystać z zalet wydajnego mechanizmu.Jeśli zespołowi nie uda się dostosować doktóregoś z punktów krytycznych, musi pogo-dzić się z mniejszą efektywnością. Zespółpowinien myśleć kreatywnie, w jaki sposóbzbliżać się do punktów krytycznych i jak radzićsobie z sytuacją, gdy punkty te nie są możliwedo spełnienia.

Oto pięć punktów krytycznych.

Od dwóch do ośmiu osób w jednym pokojuW tym układzie przesył informacji jest naj-szybszy.

Ludzie mogą zadawać sobie pytania bezzbytniego podnoszenia głosu. Wiedzą, kiedyinni są gotowi odpowiadać na pytania. Cowięcej, przysłuchują się rozmowom innychbez przerywania własnej pracy. Szkice pro-jektu i jego plan znajdują się na tablicy w za-sięgu wzroku.

Ludzie bardzo często mówią mi, że choć tośrodowisko jest czasem hałaśliwe, najbardziej

wydajna praca projektowa odbywa się wła-śnie w małych zespołach, które pracują w tymsamym pokoju.

Gdy nie uda nam się osiągnąć tego punktukrytycznego, znacząco wzrasta koszt przeno-szenia informacji. Każde drzwi, każdy naroż-nik i każde piętro zwiększa ten koszt.

W historii „E-bycie i e-świadomość” opo-wiadam o jednym z zespołów, który nie mógłspełnić tego punktu. Programiści zastosowalijednak kamery internetowe, by przynajm-niej w części zniwelować konieczność pracyw różnych miejscach. By szybko odpowiadaćna krótkie pytania, wykorzystywali komu-nikatory internetowe. Starali się w jak naj-lepszy sposób odtworzyć zalety punktu kry-tycznego w sytuacji, która teoretycznie touniemożliwiała.

Eksperci klienta na miejscuMożliwość stałego korzystania z ekspertówklienta oznacza, że bardzo szybko uzyskuje-my informacje zwrotne na temat wynikówpracy. Często są to minuty, rzadziej godziny.

Tego rodzaju szybkie informacje zwrotnepowodują, że zespół programistyczny lepiejrozumie potrzeby i przyzwyczajenia klienta,więc popełnia mniej błędów przy wprowa-dzaniu nowych pomysłów. Wypróbowujerównież więcej pomysłów, co czyni końcowyprodukt znacznie lepszym. Przy dobrej współ-pracy, programiści testują pomysły eksper-tów i oferują kontrpropozycje. Pozwala toklientom lepiej zorientować się we własnychżądaniach dotyczących sposobu działaniasystemu.

Koszt związany z niezastosowaniem tegopunktu krytycznego dotyczy obniżenia praw-dopodobieństwa wykonania naprawdę uży-tecznego produktu i zwiększenia kosztu róż-norakich eksperymentów.

Zwinność • 245

Istnieje wiele alternatywnych mechani-zmów radzenia sobie z szybką informacjązwrotną, gdy nie uda się wprowadzić opisa-nego punktu, ale są one mniej efektywne.W ciągu ostatnich lat dosyć dobrze opisanoalternatywy — cotygodniowe sesje spraw-dzające z udziałem użytkowników; analizyetnograficzne społeczności użytkowników;ankiety; wykorzystanie zaprzyjaźnionychgrup testujących. Z pewnością są i inne alter-natywy.

Niemożność wprowadzenia wspomnia-nego punktu krytycznego nie zwalnia od sta-rań związanych z uzyskaniem dobrej i szyb-kiej informacji zwrotnej. Najczęściej jednakzwiększa koszt uzyskiwania tego rodzajuinformacji.

Jednomiesięczne przyrostyNic nie zastąpi szybkich informacji zwrot-nych, zarówno na poziomie produktu, jaki na poziomie procesu programistycznego.Przyrostowe tworzenie oprogramowaniapozwala zapewnić dobrą informację zwrotną.Krótkie przyrosty zapewniają, że zarównowymagania, jak i sam proces są poprawianebardzo szybko. Pozostaje pytanie: „Jak długiepowinny być przerwy między kolejnymidostarczeniami?”.

Prawidłowa odpowiedź bywa różna, alezespoły projektowe, które miałem okazjęprzepytywać, wskazywały na okres od jed-nego do trzech miesięcy z możliwą redukcjądo dwóch tygodni lub rozszerzeniem do czte-rech miesięcy.

Wydaje się, że ludzie mogą skupić swojewysiłki na maksymalnie trzy miesiące, alenie dłużej. W przypadku dłuższych okresówwydań wiele osób informuje mnie o zbytnimrozkojarzeniu, utracie intensywności działańi kreatywności. Co bardzo ważne, przyrostowerozwijanie aplikacji daje zespołowi szansę na

naprawienie swojego procesu. Im dłuższyokres między wydaniami, tym dłuższy czasmiędzy możliwymi naprawami.

Jeśli byłby to jedyny aspekt sprawy, ide-alnym okresem przyrostowym byłby jedentydzień. Trzeba jednak pamiętać o koszciewdrożenia produktu na zakończenie każdegookresu.

Wydaje mi się, że najlepszym punktemkrytycznym w tym przypadku jest jedenmiesiąc, ale widziałem również udane pro-jekty wykorzystujące okres o długości dwóchi trzech miesięcy.

Jeśli zespół nie może dostarczyć produktukońcowym użytkownikom co kilka miesięcy(niezależnie od powodów), warto mimo totworzyć system w sposób przyrostowy i przy-gotowywać go do dostarczenia w wyznaczo-nych okresach czasu (udając, że sponsor żądajego natychmiastowego dostarczenia w obec-nej postaci). Celem takiej pracy jest ćwiczeniekażdej części procesu wytwarzania oprogra-mowania i poprawianie wszystkich elemen-tów procesu co kilka miesięcy.

W pełni zautomatyzowane testy regresyjneW pełni zautomatyzowane testy regresyjne(jednostkowe, funkcjonalne lub oba) oferujądwie zalety:

• Programiści mogą modyfikować lub uspra-wniać kod, a następnie testować go jed-nym naciśnięciem przycisku. Dzięki auto-matycznym testom ludzie są bardziejskłonni poprawiać kod innych osób, bowiedzą, że testy nie pozwolą im na wpro-wadzenie subtelnych błędów.

• Ludzie zgłaszają mi, że bardziej relaksująsię w weekendy, jeśli mają automatycznetesty regresyjne. Co poniedziałek urucha-miają testy i sprawdzają, czy ktoś bez ichwiedzy zmodyfikował system.


Innymi słowy, zautomatyzowane testy po-prawiają zarówno jakość systemu, jak i jakośćżycia programistów.

Istnieją pewne części systemów (a nawetcałe systemy), dla których trudno napisaćzautomatyzowane testy.

Jednym z przykładów mogą być graficzneinterfejsy użytkownika. Doświadczeni pro-gramiści doskonale zdają sobie z tego sprawę,więc starają się zminimalizować liczbę pod-systemów, które muszą być testowane ręcznie.

Jeśli sam system nie ma zautomatyzowa-nych testów, doświadczeni programiści sta-rają się znaleźć sposoby tworzenia testów dlaopracowywanych przez siebie partii sys-temów.

Doświadczeni programiściW idealnej sytuacji — punkcie krytycznym —zespół składa się tylko i wyłącznie z doświad-czonych programistów. Analizowane przezemnie zespoły, które składały się z doświad-czonych programistów, miały inne i lepszewyniki w porównaniu z zespołami średnimii mieszanymi.

Ponieważ dobrzy i doświadczeni progra-miści mogą być od dwóch do dziesięciu razybardziej wydajni od swoich kolegów, możnadrastycznie zmniejszyć rozmiar zespołu, jeśliskłada się tylko i wyłącznie z doświadczonychprogramistów.

Przed wykonywaniem i w trakcie wyko-nywania projektu „Winifred” estymowaliśmy,że projekt do udanej realizacji w wyznaczo-nym przedziale czasu potrzebuje 6 dobrychprogramistów języka Smalltalk. Ponieważw tym czasie nie udało nam się pozyskać sze-ściu dobrych programistów, musieliśmy zaan-gażować aż 24. Czterech doświadczonychprogramistów tworzyło najtrudniejsze częścisystemu i dużo czasu spędzało na pomocymniej doświadczonym kolegom.

Jeśli nie możesz spełnić tego punktu, zasta-nów się nad wprowadzeniem pełno- lub pół-etatowego trenera, który poprawi efektywnośćpracy niedoświadczonych osób.

PROBLEM Z ZESPOŁAMI WIRTUALNYMI

Wirtualny oznacza w tym przypadku, żeczłonkowie zespołu nie siedzą razem. Ponie-waż słowo to zyskało ostatnio na popularności,sponsorzy projektów starają się nim wytłu-maczyć ogromne bariery komunikacyjne sta-wiane zespołom.

We wcześniejszej części książki przed-stawiłem szkody dla projektu powodowaneprzez rozdzielenie osób wskutek umieszcze-nia ich w różnych częściach budynku. Szyb-kość tworzenia systemu jest związana z cza-sem i energią potrzebną do przeniesieniapomysłów. Jeśli z powodu dużej odległościosób zwiększa się koszt przekazania wiedzy,zwiększa się także koszt związany z niezada-niem kluczowych pytań. Dzielenie zespołuto proszenie się o zwiększony koszt projektu.

Rozproszone geograficznie zespoły dzielęna trzy grupy o różnym poziomie szkód wy-rządzanych projektowi. Poszczególnym kate-goriom nadałem nazwy: wiele lokalizacji,zamorski i rozproszony.

Programowanie w wielu lokalizacjachProgramowanie w wielu lokalizacjach mamiejsce, gdy większy zespół pracuje w sto-sunkowo niewielkiej liczbie lokalizacji, a po-szczególne grupy programistyczne tworząceposzczególne podsystemy znajdują się w jed-nej lokalizacji. Dodatkowym warunkiem jeststosunkowo mocna separacja poszczególnychpodsystemów.

Ten sposób programowania i prowadzeniaprojektów jest z sukcesami stosowany od dzie-sięcioleci.

Zwinność • 247

Kluczem do sukcesu w takim przypadkujest posiadanie pełnego i kompetentnegozespołu w każdej z lokalizacji oraz zapewnie-nie wystarczająco częstych spotkań poszcze-gólnych grup, by mogły się dzielić swoimidoświadczeniami i wizjami.

Choć w takim sposobie pracy wiele sprawmoże pójść nie tak, jest to rozwiązanie spraw-dzone, ze stosunkowo dobrze wypracowanymiregułami pracy (w odróżnieniu od dwóch po-zostałych modeli zespołów wirtualnych).

Programowanie zamorskieTen rodzaj pracy występuje, gdy „projektanci”z jednej lokalizacji wysyłają specyfikacje i testydo „programistów” z innej lokalizacji, najczę-ściej z innego kraju.

Ponieważ zamorska lokalizacja nie maarchitektów, projektantów i testerów, w zna-czący sposób różni się sposobem pracy od pro-gramowania w wielu lokalizacjach.

Oto, w jaki sposób można opisać pro-gramowanie zamorskie, używając określeńzwiązanych z grą zespołową i przepływempowietrza.

Projektanci w jednej lokalizacji musząprzekazać pomysły przez cienkie kanałykomunikacyjne osobom, które stosują innesłownictwo i znajdują się tysiące kilometrówdalej. Programiści potrzebują odpowiedzi natysiące pytań. Jeśli znajdą błędy w projekcie,muszą wykonać trzy kosztowne zadania:zaczekać na następne spotkanie telefonicznelub wideo, przekazać swoje obserwacje i prze-konać projektantów o możliwych błędachw projekcie. Koszt w erg-sekundach na memjest zastraszający, a same opóźnienia ogromne.

TESTOWANIE

PROGRAMOWANIA ZAMORSK IEGO

Pewien projektant powiedział mi, że jegozespół musi określać program niemalże napoziomie kodu źródłowego i tworzyć testy,

by mieć pewność, że programiści poprawniezaimplementowali wszystkie wymagania.Projektanci wykonywali całą nieprzyjemnąrobotę papierkową, ale nie dostawali na-grody w postaci pisania kodu.

Ponieważ tworzenie projektu i testówzajmowało ogromną ilość czasu, moglibyrównie dobrze sami pisać kod oraz odkry-wać błędy w projekcie i to najczęściejszybciej.

Nie udało mi się jeszcze znaleźć projektówprowadzonych w ten sposób, które okaza-łyby się udane metodologicznie. Zawsze nieprzechodziły trzeciego testu: przesłuchiwaneprzeze mnie osoby twierdziły, że nie chcąponownie pracować w ten sposób.

Na szczęście w ostatnim czasie coraz wię-cej firm programistycznych stara się zamienićswoje projekty w coś na kształt programo-wania w wielu lokalizacjach, umieszczającw jednym miejscu architektów, projektantów,programistów i testerów. Choć więź komu-nikacyjna nadal jest długa i cienka, członko-wie zespołów mają przynajmniej cień szansyna skorzystanie z informacji zwrotnych i szyb-kości komunikacji w projektach prowadzo-nych w wielu lokalizacjach.

Programowanie rozproszoneProgramowanie rozproszone występuje wte-dy, gdy zespół jest rozmieszczony w stosun-kowo wielu lokalizacjach ze stosunkowo nie-wielką liczbą osób (bardzo często jest to tylkojedna osoba lub są to dwie osoby) w każdymz miejsc.

Programowanie rozproszone staje się corazbardziej popularne, ale nie znaczy to, że jestefektywne. Koszt przenoszenia pomysłów jestznaczny, a koszt straconej szansy spowodo-wany niezadaniem pytania jeszcze większy.Model rozproszony działa stosunkowo dobrze,jeśli naśladuje model z wieloma lokalizacjami,


w którym jedna lub dwie osoby stanowiąw miarę niezależny podzespół. W takiej sytu-acji zadania powierzane programiście są jasnei spójne.

Niestety, najczęściej mamy do czynieniaz sytuacją przedstawioną poniżej.

ROZPROSZENIE KRZYŻOWE

Firma tworzyła cztery powiązane produktyw czterech lokalizacjach, a każdy produktskładał się z wielu podsystemów.

Najlepszym rozwiązaniem byłoby umie-szczenie zespołów tworzących wszystkie sys-temy jednego produktu w tej samej lokali-zacji lub ewentualnie rozmieszczenie w tymsamym miejscu zespołów jednego podsy-stemu dla wszystkich produktów tworzo-nych w firmie. W obu przypadkach ludziebyliby w fizycznej bliskości z innymi oso-bami, z którymi muszą się wymieniać in-formacjami.

W praktyce okazało się, że dziesiątkiosób zaangażowanych w projekty przy-dzielono w taki sposób, że w tym samymmieście pracowali ludzie przydzieleni doróżnych podsystemów rożnych produktów.Byli więc otoczeni przez osoby, które w nie-wielkim stopniu mogły im pomóc w zdoby-ciu potrzebnych informacji, a osoby z któ-rymi musiały się komunikować znajdowałysię daleko!

Od czasu do czasu programiści informująmnie o efektywnym tworzeniu oprogramo-wania z kimś znajdującym się w całkowicieinnym miejscu. Oznacza to, że cały czas jestjeszcze coś nowego do odkrycia: co pozwalaludziom tak dobrze komunikować się zapomocą tak słabego kanału komunikacyj-nego? Czy to po prostu szczęśliwe dopaso-wanie osobowości lub stylów myślenia? Czy tedwie osoby wypracowały miniaturowy modelodpowiadający programowaniu w kilku loka-lizacjach? Czy korzystają z czegoś, czego więk-szość z nas nie jest w stanie nazwać?

UDANE PROGRAMOWANIE

ROZPROSZONE

Spędziłem pewien wieczór, rozmawiającz kilkoma osobami, które z sukcesemzaangażowały jako grupę czterech lubpięciu programistów, którzy nigdy się niespotkali.

Powiedziały, że poza bardzo uważnympodzieleniem problemu spędzają dużoczasu przy telefonie, dzwoniąc do siebiekilka razy w ciągu dnia.

Poza tą raczej oczywistą taktyką koor-dynatorka zespołu pracowała szczególnieciężko, by zapewnić wysoki poziom zaufa-nia i przyjazności. Co kilka tygodni odwie-dzała każdego z programistów i starała się,by jej wizyta była użyteczna i nie przera-dzała się w sesję obwiniania.

Za wszelką cenę starała się powielićudany model tworzenia oprogramowania.

Pod koniec spotkania stwierdziła, żemusi znaleźć innego koordynatora prac,podobnego do siebie — kogoś, kto będziemiał podobny talent do zapewniania atmo-sfery zaufania i przyjazności.

Zdziwiły mnie dwa aspekty ich pracy:• zwracanie dużej uwagi na budowanie

wzajemnego zaufania,• ogromna ilość energii poświęcana na

codzienną komunikację, by zapewnić od-powiednią wiedzę, zaufanie i informa-cje zwrotne.

Tworzenie wolnego oprogramowaniaChoć tworzenie oprogramowania open sourceprzypomina model rozproszony, różni się odniego w kwestiach filozoficznych, ekonomicz-nych i struktury zespołu.

Większość firm programistycznych w trak-cie prowadzenia projektu gra w grę zespo-łową o ograniczonych zasobach, ale projektyopen source grają w grę zespołową o nieogra-niczonych zasobach.

Zwinność • 249

Zespół w projekcie komercyjnym stara sięosiągnąć pewien cel w wyznaczonym czasie,mając do dyspozycji określoną sumę pienię-dzy. Ograniczenie finansowe i czasowe okre-śla, ilu ludzi i w jak długim przedziale czasumoże pracować nad projektem. W tych grachczęsto słyszymy następujące stwierdzenia:

„Ukończ to, zanim zamknie się oknorynkowe!”.

„Twoim zadaniem jest równoważeniejakości i czasu wytwarzania!”.

„Wdrażaj!”.

Z drugiej strony projekt open source działawedług zasady, że wystarczy odpowiedniodużo oczu, umysłów, palców i czasu, bypowstał dobry model i naprawdę dobrejjakości kod. W szczególności istnieje teore-tycznie nieograniczona liczba osób zaintere-sowanych rozwojem programu i nie ma żad-nego okna rynkowego, w którym trzeba sięzmieścić. Projekt żyje własnym życiem. Każdaz osób poprawia system tam, gdzie jest słaby,wykorzystując dostępną dla siebie energięi czas.

Struktura nagród również jest inna, bobazuje na wewnętrznych potrzebach, a niezewnętrznych kwestiach finansowych. (Wię-cej informacji na ten temat znajdziesz w roz-dziale 2.). Ludzie tworzą oprogramowanieopen source dla przyjemności, jako usługę dlaspołeczności, o którą dbają, lub w celu byciarozpoznawanym i cenionym przez innych.Ten model motywacyjny jest dokładniej opi-sany w tekście Homesteading the Noosphere(Raymond, http://catb.org/~esr/writings/cathe

dral-bazaar/homesteading).Celem typowego programisty w firmie jest

stanie się drugim Billem Gatesem. Porówny-

walnym celem dla programisty open sourcebyłoby stanie się drugim Linusem Torvaldsem.

Warto również pamiętać o innej strukturzezespołów open source i zespołów tradycyjnych.Choć każdy może napisać lub poprawić frag-ment kodu, istnieją wybrani ochroniarze, któ-rzy chronią centralną bazę kodu. Ochroniarznie musi być najlepszym programistą. Wystar-czy, że jest dobrym programistą z łatwymnawiązywaniem kontaktów i z bardzo dobrymokiem na wykrywanie szczegółów. Po pew-nym czasie kilku najlepszych współtwórcówprogramu zaczyna zajmować centrum, stającsię głównymi właścicielami intelektualnymiprojektu. Wokół tych ludzi zbiera się niezli-czona liczba innych osób, które przesyłająpoprawki i sugestie, wykrywają i zgłaszająbłędy, a także piszą dokumentację.

Sugeruje się i zaleca, by cała komunikacjaprogramistów open source była dostępna dlakażdego. Rozważmy to w świetle projektukomercyjnego.

W projekcie komercyjnym z wykorzystu-jącym zespół umieszczony w jednym miej-scu problemy rozpoczynają się, jeśli społecz-ność programistów zaczyna dzielić się naklasę wyższą i niższą. Jeśli analitycy siedzą pojednej stronie, a programiści po drugiej, roz-dzielenie „my i oni” łatwo buduje wrogośćmiędzy poszczególnymi grupami (tzw. „frak-cje”). W dobrze zrównoważonym projekciejest tylko „my”, nie ma rozróżnienia na „myi oni”. W występowaniu lub braku wystę-powania tego podziału kluczową rolę grasposób wymiany informacji między grupamii pogaduszki. Jeśli istnieją enklawy zbierającespecjalistów z jednej dziedziny, pogaduszkiniemal na pewno dotyczyć będą równieżkomentarzy na temat „tamtych”.

W modelu open source równoważna sytu-acja miałaby miejsce, gdyby jedna z podgrup(znajdująca się w jednym miejscu), prowadziła


pewną dyskusję, w której nie mogą uczestni-czyć inne osoby. Osoby z rozproszonej grupymogłyby wyrobić w sobie przeświadczenie,że są obywatelami drugiej kategorii odcię-tymi od serca społeczności i od istotnych kon-wersacji.

Gdy cała komunikacja jest dostępna w in-ternecie i widoczna dla każdego, trudno ukryćróżnego rodzaju pogłoski, więc zawsze jesttylko „my”.

Chciałbym pewnego dnia zobaczyć i prze-analizować dokładniej ten aspekt projektówopen source.

DOSTOSOWYWANIE SIĘ

Jeśli czytasz książkę od samego początku,zapewne nadal nie potrafisz znaleźć odpo-wiedzi na jeden problem.

Każda osoba jest inna, każdy projekt jestinny, a każdy projekt różni się od innych wie-loma szczegółami, podsystemami, podzespo-łami i zakresem czasowym. Każda sytuacjawymaga zastosowania innej metodologii(zbioru konwencji).

Sekret polega na sposobie konstrukcji róż-nych metodologii dostosowanych do kon-kretnych sytuacji, ale w taki sposób, by niezabierało to dużo czasu i nie przeszkadzałow dostarczeniu oprogramowania. Nie chcemyrównież, by każda osoba uczestnicząca w pro-jekcie musiała być ekspertem w zakresie meto-dologii.

Zapewne domyślasz się, co będzie tema-tem tego podrozdziału.

POTRZEBA ANALIZY PRZESZŁYCH DZIAŁAŃ

Sztuczka z dostosowywaniem konwencji dociągle zmieniających się potrzeb wymagawykonania dwóch rzeczy na poziomie osobi-stym i zespołu.

1. Zastanawiaj się nad tym, co robisz. 2. Niech zespół co drugi tydzień spędzagodzinę na analizie własnych nawyków.

Jeśli wykonasz te dwa zadania, powstającametodologia będzie efektywna, zwinna i do-stosowana do konkretnej sytuacji. Jeśli niemożesz tego zrobić… cóż, pozostaniesz tam,gdzie jesteś.

Choć tajemniczy składnik jest naprawdęprosty, bardzo trudno wprowadzić go w życiez powodu dziwactw ludzkiej natury. Ludzienajczęściej nie chcą nawet słyszeć o spotkaniu.W niektórych firmach poziom braku zaufaniajest tak wysoki, że pewne osoby nie rozma-wiają ze sobą, a co dopiero, gdyby mieli spo-tykać się na wspólnych spotkaniach.

W takiej sytuacji można zrobić tylko jed-no — zorganizować spotkanie, przesłać wszy-stkim wnioski i zobaczyć, czy spotkanie udasię powtórzyć.

Warto znaleźć w firmie osobę, która maodpowiednie predyspozycje do organizacjitego rodzaju spotkań. Czasem trzeba poszukaćkogoś spoza zainteresowanych grup, kogośo odpowiednich zdolnościach i dużej akcep-tacji przez różnych członków zespołu.

TECHNIKA ROZWOJU METODOLOGII

Oto technika konstrukcji i dostrajania meto-dologii „w locie”. Przedstawię, co należy robićw pięciu różnych momentach:

• teraz,• na początku projektu,• w połowie pierwszej iteracji,• po każdej iteracji,• w połowie następnej iteracji.

Po tym opisie przedstawię przykładowe, jed-nogodzinne ćwiczenie z analizy wcześniej-szych działań.

Dostosowywanie się • 251

TerazOdkryj mocne i słabe strony firmy dzięki krót-kim rozmowom o projekcie.

Możesz to zrobić na początku projektu, alerównie dobrze możesz to zrobić teraz, nieza-leżnie od poziomu zaawansowania projektu.Uzyskane informacje pomogą na każdym eta-pie prac. Możesz więc w dowolnym momenciebudować własny zbiór rozmów o projekcie.

W idealnej sytuacji kilka osób może poroz-mawiać z kilkoma innymi osobami, by powstałzestaw od 6 do 10 raportów z wywiadów.Bywa użyteczne, choć nie jest wymagane,przeprowadzenie wywiadu z więcej niż jednąosobą z danego projektu. Można na przy-kład porozmawiać z dwoma osobami na na-stępujących stanowiskach: menedżer projektu,lider zespołu, projektant interfejsu użytkow-nika i programista. Dzięki ich różnym sposo-bom patrzenia na projekt można wyrobić sobielepsze pojęcie o sposobie jego działania. Nie-mniej bardziej istotne okazuje się uzyska-nie typowych odpowiedzi dotyczących wieluprojektów.

Pamiętaj, że istotne może okazać się każ-de słowo wypowiedziane przez rozmówcę.W trakcie wywiadu nie wyrażaj żadnych wła-snych opinii, ale korzystaj ze swojego do-świadczenia i oceny sytuacji, by formułowaćkolejne pytania.

Wydaje mi się, że powinieneś zastosowaćnastępującą kolejność poruszanych kwestii:

1. Zapytaj o podanie jednego przykładu każ-dego wytworzonego produktu pracy.

2. Poproś o podanie krótkiej historii projektu. 3. Zapytaj, co należałoby zmienić następnymrazem.

4. Zapytaj, co należałoby powtórzyć następ-nym razem.

5. Określ priorytety. 6. Znajdź dowolne luki w produkcie pracylub projekcie.

Krok 1. Zapytaj o podanie jednego przykładukażdego wytworzonego produktu pracyAnalizując ten aspekt, łatwo stwierdzić,ile biurokratycznego narzutu występowałow projekcie i jakie szczegółowe pytania o pro-dukty pracy należy zadać w trakcie wywiadu.

Szukaj duplikacji pracy oraz miejsc, gdzietrudno było utrzymać aktualność efektówpracy.

Zapytaj, czy używano programowaniaprzyrostowego, a jeśli tak, to w jaki sposóbaktualizowano dokumenty w kolejnych ite-racjach.

Szukaj opisów sposobu, w jaki używanonieformalnej komunikacji, by rozwiązać nie-jasności w dokumentacji.

DUPL IKACJA EFEKTÓW PRA CY

W jednym z projektów lider zespołu przed-stawił mi 23 produkty pracy.

Zauważyłem, że wiele z nich pokrywałosię, więc zapytałem, czy te późniejsze byłygenerowane przez narzędzia na podstawiewcześniejszych.

Lider odpowiedział, że nie; były odpodstaw tworzone przez ludzi.

Zadałem więc pytanie, jak pracującenad tym osoby postrzegały swoją pracę.Powiedział, że jej nienawidziły, ale i takzmuszał je do jej wykonywania.

Po zobaczeniu przykładów efektów pracyprzechodzimy do następnego punktu.

Krok 2. Poproś o podaniekrótkiej historii projektuZapisz datę rozpoczęcia, ewentualne zmianywielkości zespołu (powiększenie lub zmniej-szenie), strukturę zespołu, dobre i złe chwilezwiązane z pracą nad projektem.

Wykonaj to, by móc oszacować rozmiari typ projektu, a także by znaleźć interesującepytania do zadania.


ODKRYWANIE PROGRAMOWA N IA

PRZYROSTOWEGO

Oto, w jaki sposób poznałem fascynującąhistorię projektu, któremu nadałem nazwę„Ingrid” (Cockburn 1998).

W początkowej fazie projektu, zespółuzbierał większość znanych mi w tym czasiewskaźników porażki. To, że ich pierwsza,czteromiesięczna iteracja okazała się kata-strofą, nie było dla mnie żadnym zasko-czeniem. Zacząłem się nawet zastanawiać,dlaczego przebyłem tak długą drogę, byusłyszeć o tak oczywistej porażce.

Niespodzianką okazało się to, co zrobilipo pierwszej porażce.

Po pierwszej iteracji zmienili w projekcieniemalże wszystko. Nigdy wcześniej nie sły-szałem o takim przypadku.

Cztery miesiące później ponownie zbu-dowali system, używając innych rozwiązań;nie drastycznie różnych, ale wystarczających.

Co cztery miesiące dostarczali dzia-łające i przetestowane oprogramowanie,a następnie siadali razem, by dowiedziećsię, co zrobili i jak usprawnić proces (zróbto samo).

Co najbardziej zaskakujące, nie tylkorozmawiali o tym, co należy zmienić, alerównież rzeczywiście zmieniali swój sposóbpracy.

Lekcja, jaką wyniosłem z tego wywiadu, niemiała nic wspólnego z pośrednimi efektamipracy, ale raczej z fenomenem chęci osiągnię-cia sukcesu i chęci zmian (nawet co cztery mie-siące), byle tylko osiągnąć wymarzony sukces.

Po usłyszeniu historii projektu i opowieścina temat różnych wzlotów i upadków prze-chodzimy do następnej kwestii.

Krok 3. Zapytaj, co należałoby zmienićnastępnym razemZapytaj: „Jakie są najważniejsze błędy popeł-nione w trakcie projektu, których nie chciał-byś powtórzyć w następnym projekcie?”.

Zapisz odpowiedzi i staraj się dodatko-wymi pytaniami poznawać szczegóły.

Po usłyszeniu tego, czego ludzie nie chcązrobić, ponownie przejdź do następnegopunktu.

Krok 4. Zapytaj, co należałoby powtórzyćnastępnym razemZapytaj: „Jakie są kluczowe sprawy, którez pewnością chciałbyś powtórzyć w następ-nym projekcie?”.

Zapisz odpowiedzi. Jeśli ktoś odpowie:„Ta czwartkowa gra w siatkówkę była na-prawdę dobra”, także to zapisz.

WSPÓLNE UP I JANIE S IĘ

Pewnego razu, gdy zadałem to pytanie(w Skandynawii), uzyskałem odpowiedź:„Wspólne upijanie się”.

Postanowiłem spróbować tego na wła-snej skórze i tego samego wieczoru wybra-liśmy się do pubu. Rzeczywiście, następ-nego dnia zauważyłem znaczną poprawępoczucia wspólnoty.

Odpowiedzi na to pytanie bywają naprawdęprzeróżne: od jedzenia w lodówce, przezwspólne wyjścia na miasto, kanały komuni-kacji, narzędzia programistyczne, architekturęsystemów po model dziedzinowy. Zapisujwszystko, co usłyszysz.

Krok 5. Określ priorytetyZapytaj: „Jakie są twoje priorytety z uwzględ-nieniem spraw, które lubiłeś w projekcie? Cojest najważniejsze do utrzymania, a co możesznegocjować?”. Zapisz odpowiedzi.

Warto również zadać pytanie: „Co cię naj-bardziej zaskoczyło w projekcie?”.

Krok 6. Znajdź dowolne lukiw produkcie pracy lub projekcieZapytaj, czy powinieneś coś jeszcze wie-dzieć na temat projektu, i zobacz, gdzie todoprowadzi.


W pewnej firmie wykonaliśmy dwustro-nicowy szablon wywiadu, by zapisywać wyni-ki i łatwo wymieniać się informacjami. Szablonzawierał następujące części:

1. Nazwę projektu, stanowisko przesłuchi-wanej osoby (sam przesłuchiwany pozo-stawał anonimowy).

2. Dane związane z projektem (począteki koniec, maksymalna wielkość zespołu,docelowa dziedzina, używane technologie).

3. Historia projektu. 4. Co poszło źle i czego nie należy powtarzać. 5. Co poszło dobrze i co należy powtórzyć. 6. Priorytety. 7. Inne.

Wykonaj ćwiczenie, zbierz wypełnione sza-blony i przyjrzyj się im dokładniej. W zależ-ności od sytuacji kilka osób może spotkać sięrazem i porozmawiać o wywiadach lub teżtylko przeczytać zebrane notatki.

Poszukaj wspólnych elementów w anali-zowanych projektach.

WZORZEC KOMUNIKACJ I

W firmie, w której wykonaliśmy szablon, wewszystkich projektach pojawił się ten samschemat:

„Gdy mamy dobrą komunikację z klien-tami i sponsorami oraz wewnątrz zespołu,osiągamy dobre wyniki. Gdy taka komuni-kacja nie występuje, nie osiągamy dobrychwyników”.

Choć przedstawione stwierdzenie wydaje siętrywialne, rzadko zostaje dostrzeżone i zapi-sane. W rzeczywistości rok po zebraniu przed-stawionych wcześniej wyników w firmie miałomiejsce następujące zdarzenie.

WZORZEC KOMUNIKACJ I W AKCJ I

Uczestniczyłem w jednym z trzech prowa-dzonych w tamtym czasie projektów. Każdyz nich dotyczył małych zespołów i ludzi sie-dzących w różnych miastach.

Jak zapewne się domyślasz, spędziłemmnóstwo czasu i energii na komunikacji zesponsorami i programistami.

Wszystkie trzy projekty ukończono mniejwięcej w tym samym czasie. Dyrektor działuprogramistycznego zapytał się, co jestpowodem różnicy — dlaczego projekt,w którym uczestniczyłem zakończył sięsukcesem, a dwa pozostałe prowadzonew tym samym czasie okazały się porażką.

Przypomniawszy sobie wcześniejsze wy-wiady, stwierdziłem, że może to mieć cośwspólnego z jakością komunikacji międzyprogramistami i sponsorami lub międzyposzczególnymi osobami z zespołu.

Stwierdził, że to bardzo interesującypomysł. Zarówno programiści, jak i spon-sorzy z dwóch innych projektów zgłaszaliproblemy komunikacyjne z liderami pro-jektów. Zarówno programiści, jak i sponso-rzy czuli się odizolowani. Z drugiej stronysponsorzy w moim projekcie byli bardzozadowoleni z poziomu komunikacji.

W innej firmie znalazłem inny wspólnymotyw. Oto, co usłyszałem od jednej z prze-słuchiwanych osób.

MOTYW RÓŻNICY KULTUROW EJ

Wszyscy nasi projektanci interfejsów użyt-kownika mają doktoraty z psychologii i sie-dzą kilka pięter nad programistami.

Wystąpiła więc między nimi i programi-stami luka edukacyjna, kulturowa i fizyczna.

Mieliśmy problemy z powodu innegopodejścia tamtych osób do pewnych spraw,a także z powodu znacznej odległości odnich.


Firma potrzebowała wzmocnić mechanizmykomunikacji między dwoma wspomnianymigrupami, a także zastosować dodatkowe ocenyefektów pracy.

Z przedstawionych historyjek warto za-pamiętać, że to, czego nauczysz się w trakciewywiadów, może okazać się niezwykle ważnejuż w następnym projekcie. Zwracaj uwagęna ostrzeżenia pojawiające się w trakciewywiadów.

Na początku projektuPostaraj się w jakiś sposób skrócić standar-dową metodologię firmy. Należy to zrobić nie-zależnie od tego, czy bazową metodologią jestISO9001, XP, RUP, Crystal lub własne roz-wiązania.

Etap 1. Dostosowanie metodologii bazowejJeśli to możliwe, niech nad propozycją bazo-wej metodologii dla projektu pracują dwieosoby. Praca będzie przebiegać szybciej, osobyte prawdopodobnie odkryją błędy w myśle-niu drugiej strony i pomogą sobie nawzajemw doszlifowaniu pomysłów.

Muszą przejść przez cztery kroki.

1. Określić, pracę ilu osób trzeba będzie koor-dynować, a także poznać ich rozmieszcze-nie geograficzne (patrz siatka z rysunku4.22). Określić, jakiego poziomu popraw-ności oprogramowania się wymaga i jakieszkody mogą spowodować ewentualnebłędy. Określić i zapisać priorytety pro-jektu: czas wypuszczenia na rynek, po-prawność, inne istotne czynniki.

2. Wykorzystując zasady projektowania me-todologii z rozdziału 4., osoby te musząokreślić podstawowe parametry meto-dologii: podać, jak ścisłe powinno byćprzestrzeganie standardów; podać, jakrozbudowaną dokumentację należy wyko-

nać; wskazać poziom obrzędowości oceni długość przyrostu lub iteracji (czas wy-magany do dostarczenia działającego kodurzeczywistym użytkownikom, nawet jeślisą oni tylko testerami).

Jeśli okaże się, że czas iteracji jest dłuższy niżcztery miesiące, trzeba znaleźć inny sposób natworzenie przetestowanej i działającej wersjisystemu w mniej niż cztery miesiące, by zasy-mulować rzeczywiste dostarczanie systemu.

3. Wybrać metodologię bazową, która nie jestznacząco różna od sposobu pracy prefe-rowanego przez zespół.

Pamiętaj, że łatwiej modyfikować istniejącąmetodologię, niż tworzyć własną. Możnazacząć od standardów korporacyjnych, opu-blikowanych wersji RUP, XP, Crystal Clear,Crystal Orange lub metodologii użytej w po-przednim projekcie.

4. Skrócić metodologię do podstawowychprzepływów — kto przekazuje co i ko-mu — a także wskazać konwencje, naktóre grupa zapewne się zgodzi.

Przedstawione zadania mogą zająć od jed-nego do kilku dni w przypadku projektówmałej i średniej wielkości. Jeśli zaczyna wy-dawać się, że dwie osoby spędzą nad wybo-rem metodologii bazowej więcej niż tydzień,dodaj do zespołu jeszcze dwie osoby, by pracezakończyć w ciągu następnych dwóch dni.

Krok 2. Metodologia początkowaZwołaj zebranie zespołu, na którym zostanieomówiona metodologia bazowa i konwen-cje. Zmodyfikuj ją, by stała się metodologiąpoczątkową. W większych projektach, gdziezebranie całego zespołu jest niepraktyczne,zbierz reprezentantów każdego stanowiska.


Celem spotkania jest:

• wyłapanie ozdobników,• znalezienie sposobów usprawnienia pro-

cesu i zmniejszenia kosztu komunikacji,• wykrycie problemów, których nie ujawnił

szkic metodologii bazowej.

W trakcie spotkania postaraj się odpowiedziećna następujące pytania:

• Jak długie będą iteracje i przyrosty (i czymbędą się różniły)?

• Gdzie będą siedzieć ludzie?• Co zrobić, by utrzymać wysokie morale

i dobry poziom komunikacji?• Jakie będą potrzebne produkty pracy

i systemy oceny, jaka musi być ich obrzę-dowość?

• Które standardy narzędzi, rysowania, te-stów i kodu są obowiązkowe, a które tylkozalecane?

• Jak zostanie rozwiązane raportowanieczasu?

• Które konwencje należy ustalić już teraz,a które można wprowadzić i rozwinąćw późniejszym terminie?

Podstawowym celem spotkania jest wska-zanie sposobów wykrywania ewentualnychproblemów komunikacyjnych i dotyczącychmorale.

Wynikami spotkania powinny być:

• podstawowy przepływ pracy,• kryteria współpracy poszczególnych ról,

w szczególności w kwestii nakładania sięobowiązków i deklarowania kamieni mi-lowych,

• ogólne standardy i konwencje do wpro-wadzenia,

• rozwiązania komunikacyjne do przećwi-czenia.

To Twoja metodologia początkowa.Spotkanie powinno zająć połowę dnia, ale

nie więcej niż cały dzień.

W połowie pierwszej iteracjiNiezależnie od tego, czy iteracja ma długośćdwóch tygodni, czy trzech miesięcy, prze-prowadzasz krótkie wywiady z członkamizespołu, indywidualnie lub grupowo, w poło-wie iteracji. Poświęć na nie od jednej do trzechgodzin.

Oto podstawowe pytanie, które należyzadać:

Czy uda nam się to zrobić, jeśli bę-dziemy pracować tak, jak teraz?

Nie należy oczekiwać, iż w pierwszej itera-cji uda się całkowicie zmienić sposób dzia-łania zespołu, chyba że jest on całkowiciezepsuty. Szukamy raczej sposobu bezpiecz-nego dostarczenia pierwszej wersji. Jeśli me-todologia początkowa będzie mogła wytrzy-mać tak długo, będziesz miał więcej czasu,więcej doświadczenia i lepszy moment nawprowadzanie zmian tuż po pierwszym uda-nym dostarczeniu systemu.

Z tego powodu celem pierwszego wy-wiadu lub spotkania jest wykrycie, czy niedzieje się coś krytycznego, co mogłoby zagro-zić dostarczeniu pierwszej wersji.

Jeśli zauważysz, że aktualny sposób pracynie sprawdza się, najpierw rozważ ograni-czenie zasięgu pierwszego dostarczenia.

Większość zespołów przeszacowuje to,co jest w stanie dostarczyć w pierwszej wer-sji. To normalne i nie stanowi powodu doodrzucania metodologii. Wynika to po częściz ambicji zarządu układającego nierealistyczneharmonogramy i zbyt optymistycznych pro-gramistów, którzy często zapominają o potrze-bie nauki, spotkań i poprawiania błędów. Mana to również wpływ szybkość uczenia się


nowych technologii i kolegów z zespołu. Prze-sadzenie z liczbą rzeczy, którą można dostar-czyć w pierwszym wydaniu, naprawdę jestcałkowicie normalne.

Pierwszym krokiem powinna być redukcjazasięgu.

Może się okazać, że zmniejszenie zasięgunie wystarcza. Może się okazać, że wymaga-nia nie są wystarczająco jasne dla programi-stów lub że architekci nie są w stanie w od-powiednim czasie zakończyć specyfikacjiarchitektury.

Jeśli tak się dzieje, musisz zareagowaćszybko i znaleźć nowy sposób pracy. To w po-łączeniu z drastycznie zmniejszonym zasię-giem powinno spowodować udane dostar-czenie pierwszej wersji.

Można wprowadzić nakładanie się prac,posadzić ludzi bliżej siebie, zmniejszyć ide-alność początkowej architektury i w lepszymstopniu wykorzystać nieformalne kanały ko-munikacji. Konieczne mogą okazać się awa-ryjne zmiany zespołu, awaryjne szkolenia,konsultacje i zatrudnienie doświadczonychprogramistów z zewnątrz.

Głównym celem jest dostarczenie czegoś —pewnego niewielkiego, działającego i prze-testowanego kodu w pierwszej iteracji. Tobardzo istotny czynnik sukcesu projektu(Cockburn 1998). Po wydaniu pierwszej wer-sji będzie można chwilę odsapnąć i dokładniezastanowić się nad powodem problemów.

Po każdej iteracjiPo każdej iteracji zwołaj zebranie na tematwniosków dotyczących sposobu pracy.

Analiza wniosków to bardzo istotny czyn-nik sukcesu w ewolucji metodologii, podobniejak programowanie przyrostowe stanowi je-den z czynników sukcesu wytwarzania opro-gramowania.

Długość i intensywność analizy zależy odfirmy i kraju. Amerykanie są zawsze zajęci,mają mało pieniędzy i ciągle biegną. Nie dziwiwięc, że Amerykanie na analizę poświęcająjedynie od 2 do 4 godzin. W innych częściachświata analiza wniosków trwa dłużej.

Pewnego razu uczestniczyłem w dwu-dniowym spotkaniu poza miejscem pracy,które łączyło analizę sposobu pracy, budo-wanie więzi zespołu i planowanie następnejiteracji. Co nie powinno dziwić, miało miejscew Europie.

Głównym powodem przesunięcia ana-lizy do momentu zakończenia pierwszej ite-racji jest możliwość poznania pełnego efektuwszystkich elementów metodologii, ponie-waż udało się dostarczyć działające i przete-stowane oprogramowanie. Tylko wtedy moż-na ocenić, czego zrobiło się za mało, a czegoza dużo.

Istnieje również drugi powód, dla któregowarto zaczekać z analizą do końca iteracji:ludzie bardzo często są wyczerpani tuż powydaniu oprogramowania. Spotkanie dajeszansę na złapanie oddechu. Przeprowadzaneregularnie integruje się z rytmem projektu.Po każdej iteracji członkowie zespołu chętnieskorzystają z odmiany i uspokojenia umysłu.

Niezależnie od tego, czy spotkanie zajmujedwie godziny, czy dwa dni, należy przedewszystkim zadać dwa pytania:

1. „Czego się nauczyliśmy?”. 2. „Co możemy zrobić lepiej?”.

Odpowiedzi mogą dotyczyć różnych kwestiizwiązanych z projektem: od zarządzaniaprzez mierzenie czasu, komunikację w grupie,układ biurek, oceny projektu, po standardyi skład zespołu.

Bardzo często zespoły po pierwszej iteracjizacieśniają standardy, mają więcej doświad-


czenia, lepiej przekazują sobie pracę, robiąwięcej testów i znają strukturę zespołu.

Zmiany w drugiej i kolejnych iteracjachbędą znacznie mniejsze, ponieważ zespółdostarczył już oprogramowanie i wie, jak tozrobić ponownie.

W połowie następnej iteracjiPo pierwszej iteracji zespół ma już jeden(ledwie wystarczający) udany sposób pracy.Użyta metodologia staje się w tym przypadkumetodologią awaryjną.

Mając plan ratunkowy, można nieco od-ważniej proponować zmiany w trakcie spo-tkania w połowie drugiej i kolejnych iteracji.

W trakcie spotkań w połowie następnychiteracji starajcie się szukać nowych i lepszychsposobów dostarczania oprogramowania.

Zobacz, czy możesz wykonać któreś z po-niższych zadań:

• wyciąć cały fragment metodologii,• zwiększyć równoległość prac,• lepiej wykorzystać komunikację niefor-

malną do przekazywania informacji o pro-jekcie,

• wprowadzić nowe i lepsze systemy tes-towania,

• wprowadzić nowsze i lepsze wytycznedotyczące pisania testów.

• zapewnić bliższą współpracę różnych grupuczestniczących w projekcie: ekspertówdziedzinowych i użytkowych, programi-stów, testerów, trenerów, biura obsługiklienta i biura napraw.

Do uzyskania danych w trakcie iteracji wyko-rzystuj wywiady bezpośrednie lub spotka-nia grupowe. Przez ten czas zespół zbierzeodpowiednie doświadczenie i będzie wiedział,czego dotyczą spotkania i co należy w nichzgłaszać.

Jeśli w projekcie są stosowane iteracjeo długości trzech tygodni lub krótsze, możnazrezygnować z późniejszych analiz w połowieiteracji.

Dlaczego w ogóle zajmować się analiząw połowie iteracji, skoro już udało się dostar-czyć oprogramowanie i są planowane analizydziałania po każdej iteracji?

W połowie cyklu iteracji to, co sprawianajwiększe problemy, jest najlepiej widoczne.Szczegóły problemu nie będą tak dobrzepamiętane za 6 lub 8 tygodni, czyli w trakciespotkania po iteracji. Lepiej jest więc od razupoznać szczegóły problemów i wypróbowaćsposoby ich rozwiązania, niż czekać na ichpoznanie kilka tygodni, a nawet miesięcy.

A jeśli nowy pomysł okaże się niewy-pałem?

Czasem zespół próbuje nowego pomysłuw drugiej lub trzeciej iteracji, ale okazuje się, żenowe rozwiązanie nie funkcjonuje zgodniez prognozami.

ZMIANY STRUKTURY ZESPOŁU

W POŁOWIE PROJEKTU

W jednym projekcie przeszliśmy przez trzyróżne struktury zespołu w trakcie trzeciejiteracji.

Na początku trzeciej iteracji stwierdzi-liśmy, że stosowana do tej pory strukturazespołu nie sprawdza się najlepiej. Wybra-liśmy więc nową strukturę do zastosowaniaw trzeciej iteracji.

Okazała się katastrofą. Już po dwóchtygodniach wiedzieliśmy, że musimy jąszybko zmienić.

Zamiast wracać do oryginału, dziwnejale zapewniającej sukces struktury, zasu-gerowaliśmy nowe podejście i od razu wcie-liliśmy je w życie.

Okazało się dobre, więc stosowaliśmyje aż do końca projektu.


Dzięki przetestowaniu kilku rozwiązań w jed-nej iteracji, udało się nam szybko usprawnićmetodologię. Warto pamiętać o istnieniu takiejszansy.

Ocena po zakończeniu projektuStosowanie analiz w trakcie i po każdej iteracjizmniejsza potrzebę stosowania ocen popro-jektowych. Wydaje mi się, że ocen należydokonywać w trakcie projektu, gdy zmianymogą jeszcze przynieść projektowi coś do-brego. Po projekcie jest już na to za późno.

Najczęściej okazuje się, że zespoły, którestosują oceny poprojektowe nie przejmują sięanalizą w trakcie trwania projektu, a następniebardzo mocno chcą się dowiedzieć, co popra-wić w następnym projekcie. Jeśli znajdzieszsię na takim spotkaniu, zasugeruj, by następ-nym razem przeprowadzać spotkania w trak-cie trwania projektu, a nie po nim.

Z drugiej strony ocena poprojektowa todobry moment do podsumowania ogólnejpracy zespołu i sposobu zarządzania projek-tem. W takiej sytuacji proponuję zapoznać sięz książką Project Retrospectives (Kerth 2001),która omawia, w jaki sposób prowadzić dwu-dniową sesję oceny projektu.

Zastanów się w trakcie analizy przepro-wadzanej po projekcie, kto mógłby skorzy-stać ze zgromadzonych informacji i jakiewskazówki można przekazać osobom pro-wadzącym następne projekty. Warto wykonaćkrótką (dwustronicową) notkę dla następnegozespołu, podsumowując plusy i minusy aktu-alnego projektu.

Oczywiście, warto także napisać krótkiejednostronicowe uwagi na końcu każdej z ana-liz po iteracji jako standardowy wynik ichprzeprowadzenia.

SPOSOBY ANALIZY PROJEKTU

Namacalnym wynikiem sesji analizy w trakcieiteracji lub po niej jest lista spraw umiesz-czana później na ścianie, by była widoczna dlawszystkich osób uczestniczących w projek-cie i przypominała im o nowych zadaniach.

Osobiście lubię od razu w trakcie spotka-nia pisać na docelowym arkuszu papieru. Towłaśnie on najlepiej utkwi w pamięci całejgrupy. Inne osoby lubią kopiować wypraco-wane wyniki na czyste arkusze, by zapewnićich lepszy wygląd. Osoby, które tworzyły ana-lizę przedstawioną na rysunku 3.10 zdecy-dowały się na użycie samoprzylepnych kar-teczek zamiast bloku papieru.

Przykładowy sposób analizy projektuIstnieje kilka technik prowadzenia spotkaniaanalizującego projekt i przedstawiającegowyniki. Preferuję użycie najprostszego roz-wiązania, jakie uda się wymyślić. Oto skróconawersja mojej propozycji (bardziej szczegółowyopis znajduje się w: Cockburn 2005 i Tabaka2006).

ANAL IZA PROJEKTU

Cześć. Witam na spotkaniu, którego celemjest analiza projektu, by móc doskonalićnasze sposoby wytwarzania oprogramo-wania.

Celem tego spotkania nie jest wytykaniepalcami, obwinianie ani unikanie obwinia-nia. Ma ono na celu wskazanie, w którychmiejscach się zacinamy, i zaproponowanierozwiązania tych problemów.

Wynikiem tego spotkania będzie arkuszpapieru z pomysłami do zastosowaniaw następnej iteracji i sprawami, o którychpo prostu chcemy pamiętać.

Arkusz podzielimy na trzy części.Po lewej stronie umieścimy rzeczy, które

robimy dobrze i których nie chcemy stracićw następnej iteracji.


Po prawej stronie umieścimy rzeczy,nad którymi musimy jeszcze mocno popra-cować.

Po lewej stronie na dole umieścimyprzeciwwagę do tego, co robimy dobrze,czyli wskażemy problemy, z którymi staramysię uporać (patrz rysunek 5.1).

Rysunek 5.1. Przykład wyników spotkania analizującegoprojekt

Zacznijmy od tego, co zrobiliśmy dobrze.Czy jest coś, co robimy dobrze, i chcemy,byśmy wykonywali to w ten sam sposóbw następnej iteracji?

W tym momencie rozpoczyna się dyskusja.Całkiem możliwe, że ktoś zacznie wymie-niać problematyczne obszary zamiast tego, corobimy dobrze. Jeśli problem jest istotny,zapisz go od razu w części dotyczącej pro-blemów. Zapewnij czas na zastanowienie sięi dyskusję.

W pewnym momencie poprowadź dysku-sję dalej.

Dobrze. Jakie problemy wystąpiły w ostat-niej iteracji i jak chcemy się ich pozbyć?

W części dotyczącej problemów pisz możliwieniewiele: każdy problem opisuj tylko kilkomasłowami i w miarę możliwości łącz podobne

problemy. Celem tej części jest zasugerowanieobszarów wymagających poprawy, a nie sku-pianie się na problemach.

Zbierz sugestie. Jeśli lista stanie się bar-dzo długa, zapytaj, ile z tych nowych rozwią-zań zespół rzeczywiście chce wprowadzićw następnej iteracji. Spoglądanie na długą listęspraw do poprawienia może działać depre-syjnie. Najlepiej, by lista spraw do poprawie-nia była krótka. Pisanie po arkuszu grubymflamastrem to doskonały sposób szybkiegopozbywania się wolnego miejsca na kartce.

Okresowo sprawdzaj, czy ktoś nie zgłosiłdodatkowych rozwiązań, które grupa powinnapozostawić.

Pod koniec spotkania ponownie przeana-lizujcie całą listę. Zauważ, czy ludzie rzeczy-wiście zgadzają się na nowe pomysły, czy poprostu siedzą cicho.

Po spotkaniu umieść arkusz papieru w wi-docznym miejscu.

Na następne spotkanie tego typu przynieśwcześniejszy arkusz papieru i zacznij od ana-lizy tego, co udało się wykonać, co się spraw-dziło, a co jeszcze wymaga sprawdzenia.

Przeprowadzanie tego rodzaju spotkań co2 – 6 tygodni zapewnia rozwój lokalnej kul-tury — metodologii zwinnej.

Wartość oceny projektuFragment na temat shu-ha-ri z wprowadze-nia pasuje do wniosku płynącego z ocenianiaprojektu:

„Gdy uczysz się techniki i gdy asymp-totycznie dociera ona do twojego umy-słu, gdy widzisz innych ćwiczących,zaczynasz się zastanawiać nad jej po-prawą. Warto zadać kilka interesują-cych pytań:

1. Jak działa ta technika? 2. Dlaczego ta technika działa?


3. Jak ta technika wiąże się z innymipraktykowanymi przeze mnie tech-nikami?

4. Jakie są konieczne warunki począt-kowe i końcowe, by zastosować tętechnikę w walce?

Gdy tworzysz sensowny repertuartechnik, z których potrafisz dobrze ko-rzystać, musisz spotykać się z możli-wie wieloma innymi praktykami”. Gdyoglądasz innych, musisz zadać sobietrzy pytania i odpowiedzieć na nie:

1. Których praktyków cenię i podzi-wiam?

2. Czy wykonują działania inaczej odemnie?

3. Jak mogę zmienić moje działania(model mentalny i jego realizację),by zniwelować różnice, które wydająmi się istotne?

Pytania na temat przeciwnika, którenależy sobie zadać:

1. Gdzie możesz kontrolować działa-nia i ruchy przeciwnika?

2. Gdzie możesz się uspokoić i uczy-nić techniki bardziej efektywnymidzięki wyciszeniu umysłu?

3. Czy przeciwnik wygląda podobniedo podziwianych praktyków?

W trakcie analizy musisz szczerzeocenić wyniki każdego testu. Wracaj doshu przez ha i ri, jakbyś chadzał śle-pymi uliczkami”.

Sam nie mógłbym określić tego lepiej.

CO ZATEM BĘDĘ ROBIŁ JUTRO?

Potraktuj zwinność jako nastawienie, a niewzór. Spójrz na aktualny projekt i zapytaj:„W jaki sposób możemy pracować wedługzasad zwinności?”.

• Przyjrzyj się, jak daleko Twój zespół znaj-duje się od punktów krytycznych. Prze-konaj się, jak w kreatywny sposób możeszsię do nich zbliżyć lub je zasymulować.

• Zobacz, gdzie zespół może uczynić meto-dologię lżejszą. Zobacz, gdzie to nie wy-starcza.

• Przeprowadź jeden z opisanych wywia-dów na temat projektu.

• Niech inne osoby również przeprowadząwywiady. Podzielcie się wynikami. Znajdźw wywiadach wspólne wątki.

• Przeprowadź jednogodzinną analizę pro-jektu. Gdy zaczną się opisy problemów,zapisz je. Porównaj je następnie z listąprzedstawioną w rozdziale 3. Poszukajrozwiązań i rozszerz listę. Wyniki analizyumieść na arkuszu papieru. Zauważ, ileosób się nim zainteresowało.

• Przekonaj się, czy łatwiej zebrać ludzi nadrugą analizę projektu. Naucz się prze-konywać ludzi do mniejszego narzeka-nia, a częstszego zgłaszania sposobów na-prawy sytuacji.

Staraj się stać projektantem metodologii dru-giego poziomu. Tak, to część Twojej profesji.

Agile Software Development. Gra zespołowa. Wydanie II

Technology

Transcript of Agile Software Development. Gra zespołowa. Wydanie II