Agile Software

Development.
Gra zespoowa. Wydanie II
Autor: Alistair Cockburn
Tumaczenie: Rafa Joca
ISBN: 978-83-246-1503-2
Tytu oryginau: Agile Software Development:
The Cooperative Game (2nd Edition)
(The Agile Software Development Series)
Format: 170x230, stron: 480
Poznaj zasady doskonaej metodologii wytwarzania oprogramowania
Jak dopasowa metodologi Agile do specyfiki firmy?
W jaki sposb powiza Agile z innymi metodologiami?
Jak wdroy Agile w caej strukturze firmy?

Produkcja oprogramowania wymaga nie tylko doskonaej znajomoci technologii,

ale take metodologii zarzdzania projektem. Kluczowym elementem jest tu umiejtno
byskawicznego reagowania na zmiany, sytuacje kryzysowe i bdy. Istnieje wiele
usystematyzowanych metodologii wytwarzania oprogramowania, ktre jednak rzadko
sprawdzaj si w przypadku maych zespow projektowych lub projektw
realizowanych w krtkim czasie. Dla takich projektw opracowano metodologi Agile.
To zwinne programowanie zdobywa coraz wicej zwolennikw i jest wdraane
w wielu przedsibiorstwach.
Ksika Agile Software Development: The Cooperative Game (2nd Edition)
(The Agile Software Development Series) to omwienie metodologii Agile i inynierii
oprogramowania. Czytajc j, poznasz zaoenia zwinnego programowania i sposoby
zarzdzania 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
bdw przy wytwarzaniu oprogramowania.

Wydawnictwo Helion
ul. Kociuszki 1c
44-100 Gliwice
tel. 032 230 98 63
e-mail: helion@helion.pl

Zasady inynierii oprogramowania

Dobr zespou projektowego
Komunikacja wewntrz zespou projektowego
Wybr odpowiedniej metodologii
Programowanie ekstremalne
Zarzdzanie zmianami
Metodologie Crystal

Poznaj wydajne i efektywne zwinne programowanie!

SPIS TRECI
SPIS RYSUNKW I TABEL

ROZDZIA 0.

SPIS OPOWIADA

15

PRZEDMOWA

19

PRZEDMOWA DO DRUGIEGO WYDANIA

29

NIEWIADOME I NIEKOMUNIKATYWNE

33

Problem z analiz dowiadczenia ................................................................ 35

Niemono komunikacji .............................................................................. 39
Trzy poziomy suchania ................................................................................ 44
Co zatem bd robi jutro? ............................................................................ 49

ROZDZIA 0.1.

NIEWIADOME I NIEKOMUNIKATYWNE EWOLUCJA

51

Komunikacja i wsplne dowiadczenia ...................................................... 53

Shu-ha-ri ........................................................................................................... 54

ROZDZIA 1.

GRA ZESPOOWA POMYSOWOCI I KOMUNIKACJI

57

Oprogramowanie i poezja ............................................................................. 59

Oprogramowanie i gry .................................................................................. 60
Drugie spojrzenie na gr zespoow ........................................................... 66
Co to oznacza dla mnie? ................................................................................ 73

ROZDZIA 1.1.

ZESPOOWA GRA POMYSOWOCI I KOMUNIKACJI EWOLUCJA

75

Gra bagienna ................................................................................................... 77

Wspzawodnictwo we wsppracy ............................................................ 78
Inne miejsca z gr zespoow ....................................................................... 80
Raz jeszcze o inynierii oprogramowania .................................................. 80

6 SPIS TRECI

ROZDZIA 2.

POJEDYNCZE OSOBY

93

Ci dziwni ludzie ............................................................................................... 95

Obchodzenie trybw poraki ........................................................................ 99
Lepsze dziaanie w jednych aspektach ni w innych ............................. 107
Korzystanie z trybw sukcesu ..................................................................... 118
Co powinienem zrobi jutro? ...................................................................... 124

ROZDZIA 2.1.

POJEDYNCZE OSOBY EWOLUCJA

125

Rwnowaenie strategii ............................................................................... 127

ROZDZIA 3.

KOMUNIKACJA I WSPPRACA ZESPOW

131

Sposoby przepywu informacji ................................................................... 133

Zasklepianie luk komunikacyjnych ........................................................... 147
Zespoy jako spoecznoci ............................................................................ 155
Zespoy jako ekosystemy ............................................................................. 164
Co zatem bd robi jutro? ........................................................................... 166

ROZDZIA 3.1.

ZESPOY EWOLUCJA

167

Ponowne spojrzenie na prosty ukad biura .............................................. 169

ROZDZIA 4.

METODOLOGIE

171

Ekosystem, ktry dostarcza oprogramowanie ......................................... 173

Pojcia metodologiczne ................................................................................ 173
Zasady projektowania metodologii ........................................................... 198
XP od kuchni .................................................................................................. 221
Dlaczego w ogle zajmowa si metodologiami? .................................... 225
Co zatem bd robi jutro? ........................................................................... 227

ROZDZIA 4.1.

METODOLOGIE EWOLUCJA

229

Metodologie kontra strategie ...................................................................... 231

Metodologie w caej organizacji ................................................................. 232
Procesy jako cykle ......................................................................................... 233
Opisanie metodologii prostszymi sowami ............................................... 236

SPIS TRECI 7

ROZDZIA 5.

ZWINNO I ADAPTACJA

239

Lekko, aczkolwiek wystarczajco .............................................................. 241

Zwinno ........................................................................................................ 243
Dostosowywanie si ..................................................................................... 250
Co zatem bd robi jutro? .......................................................................... 260

ROZDZIA 5.1.

ZWINNO I ADAPTACJA EWOLUCJA

261

Sprostowanie bdnego zrozumienia przekazu ...................................... 264

Ewolucja metodologii zwinnych ................................................................ 281
Nowe zagadnienia metodologii ................................................................. 293
Powracajce pytania ..................................................................................... 309
Zwinno poza tworzeniem oprogramowania ........................................ 329

ROZDZIA 6.

METODOLOGIE CRYSTAL

353

Ksztat rodziny Crystal ................................................................................. 355

Crystal Clear .................................................................................................. 358
Crystal Orange .............................................................................................. 360
Crystal Orange Web ..................................................................................... 362
Co zatem bd robi jutro? .......................................................................... 366

ROZDZIA 6.1.

METODOLOGIE CRYSTAL EWOLUCJA

367

Genetyczny kod Crystal .............................................................................. 369

Crystal Clear .................................................................................................. 374
Rozciganie Crystal Clear do Yellow ......................................................... 376

DODATEK A

MANIFEST ZWINNEGO WYTWARZANIA OPROGRAMOWANIA

383

Agile Alliance ................................................................................................. 385

Manifest .......................................................................................................... 386
Wspieranie wartoci ..................................................................................... 388

DODATEK A.1

MANIFEST ZWINNEGO WYTWARZANIA OPROGRAMOWANIA

I DEKLARACJA WZAJEMNEJ ZALENOCI

395

Nowa odsona manifestu zwinnoci ......................................................... 397

Deklaracja wzajemnej zalenoci ............................................................... 400

8 SPIS TRECI

DODATEK B

NAUR, EHN, MUSASHI

407

Peter Naur, Programowanie jako budowanie teorii ............................ 409

Pelle Ehn. Gry jzykowe Wittgensteina .................................................... 419
Musashi ........................................................................................................... 431

DODATEK B.1

NAUR, EHN, MUSASHI EWOLUCJA

437

Naur ................................................................................................................. 439

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

DODATEK C

SOWO KOCOWE

441

Zwinne wytwarzanie oprogramowania .................................................... 443

Biznes jako gra zespoowa ........................................................................... 444
Przywdztwo ................................................................................................. 444
Wszyscy .......................................................................................................... 445

DODATEK D

SKOROWIDZ

BIBLIOGRAFIA

447

461

5
Zwinno i adaptacja
Mamy ju wszystkie elementy ukadanki. Dowiedziae si, e:
Tworzenie oprogramowania jest gr zespoow pomysowoci i komunikacji.
Ludzie s dziwni, ale dobrzy w spogldaniu wokoo, przejmowaniu
inicjatywy i bezporedniej komunikacji twarz w twarz.
Metodologia to zestaw konwencji stosowanych przez zesp, przy czym
rne konwencje sprawdzaj si w rnych rodzajach projektw.
Lekkie metodologie pozwalaj dostarcza oprogramowanie szybciej, ale
wraz z powikszaniem si zespou potrzeba ciszych metodologii.
Projekty to unikatowe ekosystemy, wic trzeba tak dobiera metodologi, by pasowaa do ekosystemu projektu.
Wszystko do siebie adnie pasuje, ale jaka lekko jest odpowiednia
dla danego projektu i jak mamy zastosowa wspomniane zasady w naszym
konkretnym projekcie?
Podrozdzia Lekko, aczkolwiek wystarczajco wskazuje, jaka lekko jest
odpowiednia dla danego projektu, a w szczeglnoci, co oznacza bycie zbyt
lekkim. Naszym celem jest zrwnowaenie lekkoci i wystarczalnoci.
Podrozdzia Zwinno omawia znaczenie pewnych istotnych miejsc
projektu: kolokacj, blisko uytkownikw, dowiadczenie programistw
itp. Gdy projekt oddala si od tych istotnych miejsc, trzeba w nim stosowa
mniej zwinne mechanizmy. W szczeglnoci zespoy wirtualne znaczco
utrudniaj wprowadzenie w ycie zasad zwinnoci, bo s od siebie mocno
oddalone.
Podrozdzia Dostosowywanie si opisuje technik tworzenia lekkiej, aczkolwiek wystarczajcej metodologii osobistej, ktra moe przynie korzy
projektowi. Kluczow spraw okazuje si analiza co kilka tygodni, co poszo
dobrze, a co naley zmieni.
239

Zwinno i adaptacja
LEKKO, ACZKOLWIEK WYSTARCZAJCO......................................241
Ledwo wystarczajce ................................................................................... 242
Zalecenia dotyczce dokumentacji ............................................................ 243

ZWINNO ...........................................................................243
Punkty krytyczne.......................................................................................... 244
Problem z zespoami wirtualnymi ............................................................. 246

DOSTOSOWYWANIE SI ...........................................................250
Potrzeba analizy przeszych dziaa ......................................................... 250
Technika rozwoju metodologii................................................................... 250
Sposoby analizy projektu ............................................................................ 258

CO ZATEM BD ROBI JUTRO? ................................................260

240

Lekko, aczkolwiek wystarczajco 241

L EKKO ,

ACZKOLWIEK
WYSTARCZAJCO

Przedstawiona do tej pory teoria wskazuje, by

przede wszystkim stosowa przekaz ustny do
propagowania wszystkich informacji zebranych w trakcie realizacji projektu.
Nasza intuicja podpowiada nam, e przekaz ustny nie wystarcza.
POSZUKIWANIE DOKUMENTACJI
Pewien programista zaproponowa swojej
firmie ponowne napisanie jej flagowego
produktu, poniewa nie byo do niego
dokumentacji, adna z pozostaych osb
nie znaa szczegw powstania systemu
i nie potrafia wykona niezbdnych modyfikacji. Powiedzia rwnie, e ma nadziej,
e po nowym projekcie pozostanie dokumentacja.
Kto inny opowiedzia mi o trzech projektach, ktre miay bazowa na jednym
i tym samym oryginalnym projekcie. Wszystkie trzy miay by wytwarzane w ronych
miejscach. Stwierdzi rwnie, e w takiej
sytuacji przekaz ustny po prostu nie ma
prawa bytu.

Jest cakiem moliwe, e zdobyte informacje

byy za mao lepkie. Warto jeszcze raz przyjrze si zasadzie gry zespoowej:
Gwnym celem jest dostarczenie oprogramowania; celem drugorzdnym jest przygotowanie si do nastpnej rozgrywki.
Powody osignicia pierwszego celu s
oczywiste jeli nie dostarczymy oprogramowania, nie ma znaczenia, jak dobrze przygotowywalimy si do nastpnej gry.
Jeli jednak dostarczymy oprogramowanie i sabo przygotujemy si do nastpnej
rozgrywki, podcinamy sobie skrzyda.

Obydwa dziaania konkuruj ze sob.

Zrwnowaenie dwch konkurujcych dziaa wymaga dwch umiejtnoci.
Pierwsza polega na prawidowym zgadywaniu, w jaki sposb zaalokowa zasoby
dla kadego z celw. W idealnej sytuacji
dokumentowanie naleaoby odkada na
jak najpniejszy czas, a nastpnie tworzy
jak najmniejsze dokumenty. Zbyt rozbudowana dokumentacja wykonywana zbyt wczenie opnia dostarczenie oprogramowania.
Jeli jednak zbyt ma dokumentacj robimy
zbyt pno, moe si okaza, e odesza osoba,
ktra wiedziaa co istotnego dla nastpnego
projektu.
Druga umiejtno polega na odgadniciu, jak wiele mona zwiza z tradycj ustn
grupy, a ile naley umieci w dokumentacji. Zauwa, e w pewnym momencie nie
ma znaczenia, czy modele i inna dokumentacja s kompletne i czy idealnie odpowiadaj
rzeczywistemu systemowi lub czy s zgodne
z aktualn wersj kodu. Wane jest tylko, czy
osoby, ktre bd czytay dokumentacj, znajd w niej potrzebne informacje.
Odpowiednia ilo dokumentacji to dokadnie tyle, ile potrzeba, by kto mg wykona nastpny ruch w grze. Kady dodatkowy
wysiek woony w dokumentowanie modeli
ponad t kwesti jest strat pienidzy.
Bardzo czsto osoby, ktre przesuchiwaem w zwizku z udanym projektem,
mwiy, e udao im si pomimo oczywistych brakw w dokumentacji i dziwacznego
procesu (to ich sowa, nie moje). Analizujc
te wypowiedzi w nowym wietle, nietrudno
domyli si, e odnieli sukces dlatego, e
dokonali dobrego wyboru i zaprzestali prac
nad pewnymi kanaami komunikacji od razu
po tym, jak osignli wystarczajcy poziom
zrozumienia. Wykonali odpowiedni prac
dokumentacyjn, ale jej nie doskonalili.

242 Rozdzia 5. Zwinno i adaptacja

Adekwatno to doskonay warunek, jeli

zesp musi szybko gna w kierunku gwnego
celu, a nie ma wielu zasobw.
Przypomnijmy programist, ktry powiedzia:
Jest dla mnie oczywiste, e gdy zaczynam tworzy przypadki uycia, modele
obiektw itp., moja praca ma jakie
znaczenie. Ale w pewnym momencie
przestaje ona by uyteczna, stajc si
problemem i rdem strat. Nie potrafi wykry przekroczenia tego punktu
i nigdy nie syszaem dyskusji na ten
temat. To bardzo denerwujce, poniewa uyteczne dziaania zamieniaj si
w strat czasu.
Poszukujemy punktu, w ktrym uyteczna
praca staje si balastem. To druga z wymienionych umiejtnoci.

LEDWO WYSTARCZAJCE
Sdz, e nie musz dawa przykadw zbyt
cikich lub zbyt lekkich metodologii. Wikszo programistw widziaa lub syszaa
wiele takich przykadw.
Z drugiej strony jedynie troch za lekkie metodologie s trudne do znalezienia
i wyjtkowo przydatne naukowo. To dziki
nim dowiadujemy si, co oznacza wyraenie
ledwo wystarczajcy.
We wczeniejszej czci ksiki pojawiy
si dwie tego rodzaju historie: Cigy brak
dokumentacji i Przyklejanie myli do ciany. W kadej z nich dobrze dziaajcy projekt
w kluczowym momencie przechodzi poniej
poziomu wystarczalnoci.

CIGY BRAK DOKUMENTACJI

(POWTRKA)
Ten zesp stosowa wszystkie praktyki XP
i dostarcza oprogramowanie klientowi
w okrelonym czasie. Po kilku latach sponsor spowolni prace projektowe, a wreszcie
je zatrzyma.
Gdy zesp przesta istnie, po systemie nie pozostaa adna pisana dokumentacja, wic adna z innych osb nie
moga pozna szczegw jego budowy.
Wystarczajca dawniej kultura werbalna
przestaa wystarcza.

W tej historii zesp osign podstawowy cel

gry, dostarczy dziaajcy system, ale nie udao
mu si przygotowa do nastpnej gry zwizanej z pielgnacj i modyfikacj systemu.
Kto moe wykorzysta moj wasn logik przeciwko mnie, argumentujc, e ilo
dokumentacji okazaa si wprost idealna dla
potrzeb firmy projekt zosta anulowany,
nigdy go nie wznowiono, wic poprawn
i minimaln iloci dokumentacji okaza si
jej brak!
Zauwamy jednak, e zgodnie z programowaniem jako budowaniem teorii Naura
moemy stwierdzi, e zesp stworzy wasn teori w trakcie tworzenia oprogramowania, ale nie pozostawi wystarczajcych
ladw, by nastpny zesp mg skorzysta
z ich dowiadcze.
PRZYKLEJANIE MYLI DO CIANY
(POWTRKA)
Analitycy nie mogli poradzi sobie z dziedzin, ktra bya zbyt zoona. Wanie
przeszli z cikiego procesu na XP i sdzili,
e nie wolno im tworzy adnej papierowej
dokumentacji.
Mijay miesice i mieli coraz to wiksze
problemy ze zdecydowaniem si na szczegy nastpnych etapw prac i wskazanie

Zwinno 243

implikacji swoich decyzji. Znaleli si poniej linii wystarczalnoci dla swojej gry. Aby
uzdrowi projekt, musieli zacz tworzy
wicej dokumentacji.
W pewnym momencie dostrzegli t
sytuacj i zaczli tworzy dokumentacj,
ktra pozwolia im osign poziom wystarczalnoci.

Warto zauway, e niewystarczalno nie

jest zwizana bezporednio z metodologi,
ale raczej z brakiem dopasowania metodologii i projektu jako ekosystemu. To, co jest
ledwo wystarczajce dla jednego zespou,
moe by a nadto wystarczajce lub niewystarczajce dla innego. Niewystarczalno
pojawia si, gdy czonkowie zespou nie
komunikuj si ze sob wystarczajco dobrze,
by zapewni efektywne przekazywanie informacji.
Warto idealna, ledwo wystarczalna,
zaley od rodzaju projektu i wielu innych
czynnikw. Ta sama metodologia moe by
nadmiarowa w jednej czci projektu, a niewystarczajca w innej jego czci.
Druga umiejtno polega na znalezieniu
punktu ledwo wystarczalny przy kadej
wikszej zmianie elementw projektu.

ZALECENIA DOTYCZCE DOKUMENTACJI

Oto kilka zalece zwizanych z tworzeniem
dokumentacji.
Nie pro o to, by wymagania byy doskonae, dokumenty projektowe zawsze aktualne i odzwierciedlajce stan kodu, a plan
projektu zawsze odpowiada jego aktualnemu stanowi.
Pro, by wymagania zawieray wystarczajc ilo informacji, by zapewni wydajn
prac projektantw. Pro o zastpowanie
dokumentacji szybszymi rodkami komu-

nikacji, jeli to tylko moliwe, wczajc

w to wizyty osobiste lub krtkie klipy
wideo.
Jeli projektanci s ekspertami w swej
dziedzinie i siedz blisko siebie, popro
o zastpienie dokumentacji projektowej
rysunkami na tablicy, a nastpnie zrb
zdjcia tych rysunkw.
Pamitaj jednak, o tym, e inne osoby
przychodzce po zespole projektowym
mog wymaga bardziej szczegowej dokumentacji.
Niech dokumentacja bdzie zadaniem
rwnolegym, odzwierciedlajcym walk
o zasoby, a nie liniow ciek przez cay
proces tworzenia oprogramowania.
Staraj si by moliwie pomysowy w kwestii osigania obu celw, ale unikaj bycia
idealnym, bo to kosztuje zbyt wiele.
Szukaj (uywam tu nieco przesadzonych
przymiotnikw) najlejszej i najmniej
perfekcyjnej metodologii, ktra sprosta
wyznaczonemu zadaniu. Z drugiej strony
zapewnij wystarczajco mocn i rygorystyczn komunikacj.

Z WINNO
Zwinno zakada efektywno i manewrowo. Proces zwinny jest zarwno lekki, jak
i wystarczajcy. Lekko pozwala zachowa
zwrotno. Wystarczalno ma zwizek z chci pozostania danej osoby w grze.
Pytaniem zwizanym z metodologi zwinn nie jest: Czy mog w tej sytuacji zastosowa metodologi zwinn?, lecz: Jak w tej
sytuacji pozosta zwinnym?.
Czterdziestoosobowy zesp nie bdzie tak
samo zwinny jako szecioosobowy, znajdujcy
si w jednym pokoju. Kady zesp moe jednak stara si zmaksymalizowa zastosowanie

244 Rozdzia 5. Zwinno i adaptacja

zasad metodologii zwinnej, by by moliwie

lekkim i szybkim. Zesp czterdziestoosobowy
bdzie musia zastosowa cisz metodologi
zwinn; mniejszy zesp moe sobie pozwoli na lejsz. Oba zespoy powinny skupi
si na komunikacji, spoecznoci, czstym
wygrywaniu i informacjach zwrotnych.
Jeli zespoy bd uwaay, bd okresowo
sprawdzay dopasowanie stosowanej metodologii do ekosystemu i ewentualnie przemieszczenia punktu ledwo wystarczalny.

PUNKTY KRYTYCZNE
Czci bycia zwinnym jest identyfikacja
krytycznych punktw wydajnego tworzenia
oprogramowania, a nastpnie przesuwanie
projektu tak blisko tych punktw, jak to
moliwe.
Zesp, ktremu uda si dostosowa do
jednego z punktw krytycznych, zaczyna
korzysta z zalet wydajnego mechanizmu.
Jeli zespoowi nie uda si dostosowa do
ktrego z punktw krytycznych, musi pogodzi si z mniejsz efektywnoci. Zesp
powinien myle kreatywnie, w jaki sposb
zblia si do punktw krytycznych i jak radzi
sobie z sytuacj, gdy punkty te nie s moliwe
do spenienia.
Oto pi punktw krytycznych.
Od dwch do omiu osb w jednym pokoju
W tym ukadzie przesy informacji jest najszybszy.
Ludzie mog zadawa sobie pytania bez
zbytniego podnoszenia gosu. Wiedz, kiedy
inni s gotowi odpowiada na pytania. Co
wicej, przysuchuj si rozmowom innych
bez przerywania wasnej pracy. Szkice projektu i jego plan znajduj si na tablicy w zasigu wzroku.
Ludzie bardzo czsto mwi mi, e cho to
rodowisko jest czasem haaliwe, najbardziej

wydajna praca projektowa odbywa si wanie w maych zespoach, ktre pracuj w tym
samym pokoju.
Gdy nie uda nam si osign tego punktu
krytycznego, znaczco wzrasta koszt przenoszenia informacji. Kade drzwi, kady naronik i kade pitro zwiksza ten koszt.
W historii E-bycie i e-wiadomo opowiadam o jednym z zespow, ktry nie mg
speni tego punktu. Programici zastosowali
jednak kamery internetowe, by przynajmniej w czci zniwelowa konieczno pracy
w rnych miejscach. By szybko odpowiada
na krtkie pytania, wykorzystywali komunikatory internetowe. Starali si w jak najlepszy sposb odtworzy zalety punktu krytycznego w sytuacji, ktra teoretycznie to
uniemoliwiaa.
Eksperci klienta na miejscu
Moliwo staego korzystania z ekspertw
klienta oznacza, e bardzo szybko uzyskujemy informacje zwrotne na temat wynikw
pracy. Czsto s to minuty, rzadziej godziny.
Tego rodzaju szybkie informacje zwrotne
powoduj, e zesp programistyczny lepiej
rozumie potrzeby i przyzwyczajenia klienta,
wic popenia mniej bdw przy wprowadzaniu nowych pomysw. Wyprbowuje
rwnie wicej pomysw, co czyni kocowy
produkt znacznie lepszym. Przy dobrej wsppracy, programici testuj pomysy ekspertw i oferuj kontrpropozycje. Pozwala to
klientom lepiej zorientowa si we wasnych
daniach dotyczcych sposobu dziaania
systemu.
Koszt zwizany z niezastosowaniem tego
punktu krytycznego dotyczy obnienia prawdopodobiestwa wykonania naprawd uytecznego produktu i zwikszenia kosztu rnorakich eksperymentw.

Zwinno 245

Istnieje wiele alternatywnych mechanizmw radzenia sobie z szybk informacj

zwrotn, gdy nie uda si wprowadzi opisanego punktu, ale s one mniej efektywne.
W cigu ostatnich lat dosy dobrze opisano
alternatywy cotygodniowe sesje sprawdzajce z udziaem uytkownikw; analizy
etnograficzne spoecznoci uytkownikw;
ankiety; wykorzystanie zaprzyjanionych
grup testujcych. Z pewnoci s i inne alternatywy.
Niemono wprowadzenia wspomnianego punktu krytycznego nie zwalnia od stara zwizanych z uzyskaniem dobrej i szybkiej informacji zwrotnej. Najczciej jednak
zwiksza koszt uzyskiwania tego rodzaju
informacji.
Jednomiesiczne przyrosty
Nic nie zastpi szybkich informacji zwrotnych, zarwno na poziomie produktu, jak
i na poziomie procesu programistycznego.
Przyrostowe tworzenie oprogramowania
pozwala zapewni dobr informacj zwrotn.
Krtkie przyrosty zapewniaj, e zarwno
wymagania, jak i sam proces s poprawiane
bardzo szybko. Pozostaje pytanie: Jak dugie
powinny by przerwy midzy kolejnymi
dostarczeniami?.
Prawidowa odpowied bywa rna, ale
zespoy projektowe, ktre miaem okazj
przepytywa, wskazyway na okres od jednego do trzech miesicy z moliw redukcj
do dwch tygodni lub rozszerzeniem do czterech miesicy.
Wydaje si, e ludzie mog skupi swoje
wysiki na maksymalnie trzy miesice, ale
nie duej. W przypadku duszych okresw
wyda wiele osb informuje mnie o zbytnim
rozkojarzeniu, utracie intensywnoci dziaa
i kreatywnoci. Co bardzo wane, przyrostowe
rozwijanie aplikacji daje zespoowi szans na

naprawienie swojego procesu. Im duszy

okres midzy wydaniami, tym duszy czas
midzy moliwymi naprawami.
Jeli byby to jedyny aspekt sprawy, idealnym okresem przyrostowym byby jeden
tydzie. Trzeba jednak pamita o koszcie
wdroenia produktu na zakoczenie kadego
okresu.
Wydaje mi si, e najlepszym punktem
krytycznym w tym przypadku jest jeden
miesic, ale widziaem rwnie udane projekty wykorzystujce okres o dugoci dwch
i trzech miesicy.
Jeli zesp nie moe dostarczy produktu
kocowym uytkownikom co kilka miesicy
(niezalenie od powodw), warto mimo to
tworzy system w sposb przyrostowy i przygotowywa go do dostarczenia w wyznaczonych okresach czasu (udajc, e sponsor da
jego natychmiastowego dostarczenia w obecnej postaci). Celem takiej pracy jest wiczenie
kadej czci procesu wytwarzania oprogramowania i poprawianie wszystkich elementw procesu co kilka miesicy.
W peni zautomatyzowane testy regresyjne
W peni zautomatyzowane testy regresyjne
(jednostkowe, funkcjonalne lub oba) oferuj
dwie zalety:
Programici mog modyfikowa lub usprawnia kod, a nastpnie testowa go jednym naciniciem przycisku. Dziki automatycznym testom ludzie s bardziej
skonni poprawia kod innych osb, bo
wiedz, e testy nie pozwol im na wprowadzenie subtelnych bdw.
Ludzie zgaszaj mi, e bardziej relaksuj
si w weekendy, jeli maj automatyczne
testy regresyjne. Co poniedziaek uruchamiaj testy i sprawdzaj, czy kto bez ich
wiedzy zmodyfikowa system.

246 Rozdzia 5. Zwinno i adaptacja

Innymi sowy, zautomatyzowane testy poprawiaj zarwno jako systemu, jak i jako
ycia programistw.
Istniej pewne czci systemw (a nawet
cae systemy), dla ktrych trudno napisa
zautomatyzowane testy.
Jednym z przykadw mog by graficzne
interfejsy uytkownika. Dowiadczeni programici doskonale zdaj sobie z tego spraw,
wic staraj si zminimalizowa liczb podsystemw, ktre musz by testowane rcznie.
Jeli sam system nie ma zautomatyzowanych testw, dowiadczeni programici staraj si znale sposoby tworzenia testw dla
opracowywanych przez siebie partii systemw.
Dowiadczeni programici
W idealnej sytuacji punkcie krytycznym
zesp skada si tylko i wycznie z dowiadczonych programistw. Analizowane przeze
mnie zespoy, ktre skaday si z dowiadczonych programistw, miay inne i lepsze
wyniki w porwnaniu z zespoami rednimi
i mieszanymi.
Poniewa dobrzy i dowiadczeni programici mog by od dwch do dziesiciu razy
bardziej wydajni od swoich kolegw, mona
drastycznie zmniejszy rozmiar zespou, jeli
skada si tylko i wycznie z dowiadczonych
programistw.
Przed wykonywaniem i w trakcie wykonywania projektu Winifred estymowalimy,
e projekt do udanej realizacji w wyznaczonym przedziale czasu potrzebuje 6 dobrych
programistw jzyka Smalltalk. Poniewa
w tym czasie nie udao nam si pozyska szeciu dobrych programistw, musielimy zaangaowa a 24. Czterech dowiadczonych
programistw tworzyo najtrudniejsze czci
systemu i duo czasu spdzao na pomocy
mniej dowiadczonym kolegom.

Jeli nie moesz speni tego punktu, zastanw si nad wprowadzeniem peno- lub petatowego trenera, ktry poprawi efektywno
pracy niedowiadczonych osb.

PROBLEM Z ZESPOAMI WIRTUALNYMI

Wirtualny oznacza w tym przypadku, e
czonkowie zespou nie siedz razem. Poniewa sowo to zyskao ostatnio na popularnoci,
sponsorzy projektw staraj si nim wytumaczy ogromne bariery komunikacyjne stawiane zespoom.
We wczeniejszej czci ksiki przedstawiem szkody dla projektu powodowane
przez rozdzielenie osb wskutek umieszczenia ich w rnych czciach budynku. Szybko tworzenia systemu jest zwizana z czasem i energi potrzebn do przeniesienia
pomysw. Jeli z powodu duej odlegoci
osb zwiksza si koszt przekazania wiedzy,
zwiksza si take koszt zwizany z niezadaniem kluczowych pyta. Dzielenie zespou
to proszenie si o zwikszony koszt projektu.
Rozproszone geograficznie zespoy dziel
na trzy grupy o rnym poziomie szkd wyrzdzanych projektowi. Poszczeglnym kategoriom nadaem nazwy: wiele lokalizacji,
zamorski i rozproszony.
Programowanie w wielu lokalizacjach
Programowanie w wielu lokalizacjach ma
miejsce, gdy wikszy zesp pracuje w stosunkowo niewielkiej liczbie lokalizacji, a poszczeglne grupy programistyczne tworzce
poszczeglne podsystemy znajduj si w jednej lokalizacji. Dodatkowym warunkiem jest
stosunkowo mocna separacja poszczeglnych
podsystemw.
Ten sposb programowania i prowadzenia
projektw jest z sukcesami stosowany od dziesicioleci.

Zwinno 247

Kluczem do sukcesu w takim przypadku

jest posiadanie penego i kompetentnego
zespou w kadej z lokalizacji oraz zapewnienie wystarczajco czstych spotka poszczeglnych grup, by mogy si dzieli swoimi
dowiadczeniami i wizjami.
Cho w takim sposobie pracy wiele spraw
moe pj nie tak, jest to rozwizanie sprawdzone, ze stosunkowo dobrze wypracowanymi
reguami pracy (w odrnieniu od dwch pozostaych modeli zespow wirtualnych).
Programowanie zamorskie
Ten rodzaj pracy wystpuje, gdy projektanci
z jednej lokalizacji wysyaj specyfikacje i testy
do programistw z innej lokalizacji, najczciej z innego kraju.
Poniewa zamorska lokalizacja nie ma
architektw, projektantw i testerw, w znaczcy sposb rni si sposobem pracy od programowania w wielu lokalizacjach.
Oto, w jaki sposb mona opisa programowanie zamorskie, uywajc okrele
zwizanych z gr zespoow i przepywem
powietrza.
Projektanci w jednej lokalizacji musz
przekaza pomysy przez cienkie kanay
komunikacyjne osobom, ktre stosuj inne
sownictwo i znajduj si tysice kilometrw
dalej. Programici potrzebuj odpowiedzi na
tysice pyta. Jeli znajd bdy w projekcie,
musz wykona trzy kosztowne zadania:
zaczeka na nastpne spotkanie telefoniczne
lub wideo, przekaza swoje obserwacje i przekona projektantw o moliwych bdach
w projekcie. Koszt w erg-sekundach na mem
jest zastraszajcy, a same opnienia ogromne.
TESTOWANIE
PROGRAMOWANIA ZAMORSKIEGO

Pewien projektant powiedzia mi, e jego

zesp musi okrela program niemale na
poziomie kodu rdowego i tworzy testy,

by mie pewno, e programici poprawnie

zaimplementowali wszystkie wymagania.
Projektanci wykonywali ca nieprzyjemn
robot papierkow, ale nie dostawali nagrody w postaci pisania kodu.
Poniewa tworzenie projektu i testw
zajmowao ogromn ilo czasu, mogliby
rwnie dobrze sami pisa kod oraz odkrywa bdy w projekcie i to najczciej
szybciej.

Nie udao mi si jeszcze znale projektw

prowadzonych w ten sposb, ktre okazayby si udane metodologicznie. Zawsze nie
przechodziy trzeciego testu: przesuchiwane
przeze mnie osoby twierdziy, e nie chc
ponownie pracowa w ten sposb.
Na szczcie w ostatnim czasie coraz wicej firm programistycznych stara si zamieni
swoje projekty w co na ksztat programowania w wielu lokalizacjach, umieszczajc
w jednym miejscu architektw, projektantw,
programistw i testerw. Cho wi komunikacyjna nadal jest duga i cienka, czonkowie zespow maj przynajmniej cie szansy
na skorzystanie z informacji zwrotnych i szybkoci komunikacji w projektach prowadzonych w wielu lokalizacjach.
Programowanie rozproszone
Programowanie rozproszone wystpuje wtedy, gdy zesp jest rozmieszczony w stosunkowo wielu lokalizacjach ze stosunkowo niewielk liczb osb (bardzo czsto jest to tylko
jedna osoba lub s to dwie osoby) w kadym
z miejsc.
Programowanie rozproszone staje si coraz
bardziej popularne, ale nie znaczy to, e jest
efektywne. Koszt przenoszenia pomysw jest
znaczny, a koszt straconej szansy spowodowany niezadaniem pytania jeszcze wikszy.
Model rozproszony dziaa stosunkowo dobrze,
jeli naladuje model z wieloma lokalizacjami,

248 Rozdzia 5. Zwinno i adaptacja

w ktrym jedna lub dwie osoby stanowi

w miar niezaleny podzesp. W takiej sytuacji zadania powierzane programicie s jasne
i spjne.
Niestety, najczciej mamy do czynienia
z sytuacj przedstawion poniej.
ROZPROSZENIE KRZYOWE
Firma tworzya cztery powizane produkty
w czterech lokalizacjach, a kady produkt
skada si z wielu podsystemw.
Najlepszym rozwizaniem byoby umieszczenie zespow tworzcych wszystkie systemy jednego produktu w tej samej lokalizacji lub ewentualnie rozmieszczenie w tym
samym miejscu zespow jednego podsystemu dla wszystkich produktw tworzonych w firmie. W obu przypadkach ludzie
byliby w fizycznej bliskoci z innymi osobami, z ktrymi musz si wymienia informacjami.
W praktyce okazao si, e dziesitki
osb zaangaowanych w projekty przydzielono w taki sposb, e w tym samym
miecie pracowali ludzie przydzieleni do
rnych podsystemw ronych produktw.
Byli wic otoczeni przez osoby, ktre w niewielkim stopniu mogy im pomc w zdobyciu potrzebnych informacji, a osoby z ktrymi musiay si komunikowa znajdoway
si daleko!

Od czasu do czasu programici informuj

mnie o efektywnym tworzeniu oprogramowania z kim znajdujcym si w cakowicie
innym miejscu. Oznacza to, e cay czas jest
jeszcze co nowego do odkrycia: co pozwala
ludziom tak dobrze komunikowa si za
pomoc tak sabego kanau komunikacyjnego? Czy to po prostu szczliwe dopasowanie osobowoci lub stylw mylenia? Czy te
dwie osoby wypracoway miniaturowy model
odpowiadajcy programowaniu w kilku lokalizacjach? Czy korzystaj z czego, czego wikszo z nas nie jest w stanie nazwa?

UDANE

PROGRAMOWANIE

ROZPROSZONE

Spdziem pewien wieczr, rozmawiajc

z kilkoma osobami, ktre z sukcesem
zaangaoway jako grup czterech lub
piciu programistw, ktrzy nigdy si nie
spotkali.
Powiedziay, e poza bardzo uwanym
podzieleniem problemu spdzaj duo
czasu przy telefonie, dzwonic do siebie
kilka razy w cigu dnia.
Poza t raczej oczywist taktyk koordynatorka zespou pracowaa szczeglnie
ciko, by zapewni wysoki poziom zaufania i przyjaznoci. Co kilka tygodni odwiedzaa kadego z programistw i staraa si,
by jej wizyta bya uyteczna i nie przeradzaa si w sesj obwiniania.
Za wszelk cen staraa si powieli
udany model tworzenia oprogramowania.
Pod koniec spotkania stwierdzia, e
musi znale innego koordynatora prac,
podobnego do siebie kogo, kto bdzie
mia podobny talent do zapewniania atmosfery zaufania i przyjaznoci.

Zdziwiy mnie dwa aspekty ich pracy:

zwracanie duej uwagi na budowanie
wzajemnego zaufania,
ogromna ilo energii powicana na
codzienn komunikacj, by zapewni odpowiedni wiedz, zaufanie i informacje zwrotne.
Tworzenie wolnego oprogramowania
Cho tworzenie oprogramowania open source
przypomina model rozproszony, rni si od
niego w kwestiach filozoficznych, ekonomicznych i struktury zespou.
Wikszo firm programistycznych w trakcie prowadzenia projektu gra w gr zespoow o ograniczonych zasobach, ale projekty
open source graj w gr zespoow o nieograniczonych zasobach.

Zwinno 249

Zesp w projekcie komercyjnym stara si

osign pewien cel w wyznaczonym czasie,
majc do dyspozycji okrelon sum pienidzy. Ograniczenie finansowe i czasowe okrela, ilu ludzi i w jak dugim przedziale czasu
moe pracowa nad projektem. W tych grach
czsto syszymy nastpujce stwierdzenia:
Ukocz to, zanim zamknie si okno
rynkowe!.
Twoim zadaniem jest rwnowaenie
jakoci i czasu wytwarzania!.
Wdraaj!.
Z drugiej strony projekt open source dziaa
wedug zasady, e wystarczy odpowiednio
duo oczu, umysw, palcw i czasu, by
powsta dobry model i naprawd dobrej
jakoci kod. W szczeglnoci istnieje teoretycznie nieograniczona liczba osb zainteresowanych rozwojem programu i nie ma adnego okna rynkowego, w ktrym trzeba si
zmieci. Projekt yje wasnym yciem. Kada
z osb poprawia system tam, gdzie jest saby,
wykorzystujc dostpn dla siebie energi
i czas.
Struktura nagrd rwnie jest inna, bo
bazuje na wewntrznych potrzebach, a nie
zewntrznych kwestiach finansowych. (Wicej informacji na ten temat znajdziesz w rozdziale 2.). Ludzie tworz oprogramowanie
open source dla przyjemnoci, jako usug dla
spoecznoci, o ktr dbaj, lub w celu bycia
rozpoznawanym i cenionym przez innych.
Ten model motywacyjny jest dokadniej opisany w tekcie Homesteading the Noosphere
(Raymond, http://catb.org/~esr/writings/cathe
dral-bazaar/homesteading).
Celem typowego programisty w firmie jest
stanie si drugim Billem Gatesem. Porwny-

walnym celem dla programisty open source

byoby stanie si drugim Linusem Torvaldsem.
Warto rwnie pamita o innej strukturze
zespow open source i zespow tradycyjnych.
Cho kady moe napisa lub poprawi fragment kodu, istniej wybrani ochroniarze, ktrzy chroni centraln baz kodu. Ochroniarz
nie musi by najlepszym programist. Wystarczy, e jest dobrym programist z atwym
nawizywaniem kontaktw i z bardzo dobrym
okiem na wykrywanie szczegw. Po pewnym czasie kilku najlepszych wsptwrcw
programu zaczyna zajmowa centrum, stajc
si gwnymi wacicielami intelektualnymi
projektu. Wok tych ludzi zbiera si niezliczona liczba innych osb, ktre przesyaj
poprawki i sugestie, wykrywaj i zgaszaj
bdy, a take pisz dokumentacj.
Sugeruje si i zaleca, by caa komunikacja
programistw open source bya dostpna dla
kadego. Rozwamy to w wietle projektu
komercyjnego.
W projekcie komercyjnym z wykorzystujcym zesp umieszczony w jednym miejscu problemy rozpoczynaj si, jeli spoeczno programistw zaczyna dzieli si na
klas wysz i nisz. Jeli analitycy siedz po
jednej stronie, a programici po drugiej, rozdzielenie my i oni atwo buduje wrogo
midzy poszczeglnymi grupami (tzw. frakcje). W dobrze zrwnowaonym projekcie
jest tylko my, nie ma rozrnienia na my
i oni. W wystpowaniu lub braku wystpowania tego podziau kluczow rol gra
sposb wymiany informacji midzy grupami
i pogaduszki. Jeli istniej enklawy zbierajce
specjalistw z jednej dziedziny, pogaduszki
niemal na pewno dotyczy bd rwnie
komentarzy na temat tamtych.
W modelu open source rwnowana sytuacja miaaby miejsce, gdyby jedna z podgrup
(znajdujca si w jednym miejscu), prowadzia

250 Rozdzia 5. Zwinno i adaptacja

pewn dyskusj, w ktrej nie mog uczestniczy inne osoby. Osoby z rozproszonej grupy
mogyby wyrobi w sobie przewiadczenie,
e s obywatelami drugiej kategorii odcitymi od serca spoecznoci i od istotnych konwersacji.
Gdy caa komunikacja jest dostpna w internecie i widoczna dla kadego, trudno ukry
rnego rodzaju pogoski, wic zawsze jest
tylko my.
Chciabym pewnego dnia zobaczy i przeanalizowa dokadniej ten aspekt projektw
open source.

D OSTOSOWYWANIE SI
Jeli czytasz ksik od samego pocztku,
zapewne nadal nie potrafisz znale odpowiedzi na jeden problem.
Kada osoba jest inna, kady projekt jest
inny, a kady projekt rni si od innych wieloma szczegami, podsystemami, podzespoami i zakresem czasowym. Kada sytuacja
wymaga zastosowania innej metodologii
(zbioru konwencji).
Sekret polega na sposobie konstrukcji rnych metodologii dostosowanych do konkretnych sytuacji, ale w taki sposb, by nie
zabierao to duo czasu i nie przeszkadzao
w dostarczeniu oprogramowania. Nie chcemy
rwnie, by kada osoba uczestniczca w projekcie musiaa by ekspertem w zakresie metodologii.
Zapewne domylasz si, co bdzie tematem tego podrozdziau.

POTRZEBA ANALIZY PRZESZYCH DZIAA

Sztuczka z dostosowywaniem konwencji do
cigle zmieniajcych si potrzeb wymaga
wykonania dwch rzeczy na poziomie osobistym i zespou.

1. Zastanawiaj si nad tym, co robisz.

2. Niech zesp co drugi tydzie spdza

godzin na analizie wasnych nawykw.

Jeli wykonasz te dwa zadania, powstajca

metodologia bdzie efektywna, zwinna i dostosowana do konkretnej sytuacji. Jeli nie
moesz tego zrobi c, pozostaniesz tam,
gdzie jeste.
Cho tajemniczy skadnik jest naprawd
prosty, bardzo trudno wprowadzi go w ycie
z powodu dziwactw ludzkiej natury. Ludzie
najczciej nie chc nawet sysze o spotkaniu.
W niektrych firmach poziom braku zaufania
jest tak wysoki, e pewne osoby nie rozmawiaj ze sob, a co dopiero, gdyby mieli spotyka si na wsplnych spotkaniach.
W takiej sytuacji mona zrobi tylko jedno zorganizowa spotkanie, przesa wszystkim wnioski i zobaczy, czy spotkanie uda
si powtrzy.
Warto znale w firmie osob, ktra ma
odpowiednie predyspozycje do organizacji
tego rodzaju spotka. Czasem trzeba poszuka
kogo spoza zainteresowanych grup, kogo
o odpowiednich zdolnociach i duej akceptacji przez rnych czonkw zespou.

TECHNIKA ROZWOJU METODOLOGII

Oto technika konstrukcji i dostrajania metodologii w locie. Przedstawi, co naley robi
w piciu rnych momentach:

teraz,
na pocztku projektu,
w poowie pierwszej iteracji,
po kadej iteracji,
w poowie nastpnej iteracji.

Po tym opisie przedstawi przykadowe, jednogodzinne wiczenie z analizy wczeniejszych dziaa.

Dostosowywanie si 251

Teraz
Odkryj mocne i sabe strony firmy dziki krtkim rozmowom o projekcie.
Moesz to zrobi na pocztku projektu, ale
rwnie dobrze moesz to zrobi teraz, niezalenie od poziomu zaawansowania projektu.
Uzyskane informacje pomog na kadym etapie prac. Moesz wic w dowolnym momencie
budowa wasny zbir rozmw o projekcie.
W idealnej sytuacji kilka osb moe porozmawia z kilkoma innymi osobami, by powsta
zestaw od 6 do 10 raportw z wywiadw.
Bywa uyteczne, cho nie jest wymagane,
przeprowadzenie wywiadu z wicej ni jedn
osob z danego projektu. Mona na przykad porozmawia z dwoma osobami na nastpujcych stanowiskach: meneder projektu,
lider zespou, projektant interfejsu uytkownika i programista. Dziki ich rnym sposobom patrzenia na projekt mona wyrobi sobie
lepsze pojcie o sposobie jego dziaania. Niemniej bardziej istotne okazuje si uzyskanie typowych odpowiedzi dotyczcych wielu
projektw.
Pamitaj, e istotne moe okaza si kade sowo wypowiedziane przez rozmwc.
W trakcie wywiadu nie wyraaj adnych wasnych opinii, ale korzystaj ze swojego dowiadczenia i oceny sytuacji, by formuowa
kolejne pytania.
Wydaje mi si, e powiniene zastosowa
nastpujc kolejno poruszanych kwestii:
1. Zapytaj o podanie jednego przykadu ka-

dego wytworzonego produktu pracy.

2. Popro o podanie krtkiej historii projektu.

3. Zapytaj, co naleaoby zmieni nastpnym

razem.

4. Zapytaj, co naleaoby powtrzy nastp-

nym razem.

5. Okrel priorytety.
6. Znajd dowolne luki w produkcie pracy

lub projekcie.

Krok 1. Zapytaj o podanie jednego przykadu

kadego wytworzonego produktu pracy

Analizujc ten aspekt, atwo stwierdzi,

ile biurokratycznego narzutu wystpowao
w projekcie i jakie szczegowe pytania o produkty pracy naley zada w trakcie wywiadu.
Szukaj duplikacji pracy oraz miejsc, gdzie
trudno byo utrzyma aktualno efektw
pracy.
Zapytaj, czy uywano programowania
przyrostowego, a jeli tak, to w jaki sposb
aktualizowano dokumenty w kolejnych iteracjach.
Szukaj opisw sposobu, w jaki uywano
nieformalnej komunikacji, by rozwiza niejasnoci w dokumentacji.
DUPLIKACJA EFEKTW PRACY
W jednym z projektw lider zespou przedstawi mi 23 produkty pracy.
Zauwayem, e wiele z nich pokrywao
si, wic zapytaem, czy te pniejsze byy
generowane przez narzdzia na podstawie
wczeniejszych.
Lider odpowiedzia, e nie; byy od
podstaw tworzone przez ludzi.
Zadaem wic pytanie, jak pracujce
nad tym osoby postrzegay swoj prac.
Powiedzia, e jej nienawidziy, ale i tak
zmusza je do jej wykonywania.

Po zobaczeniu przykadw efektw pracy

przechodzimy do nastpnego punktu.
Krok 2. Popro o podanie
krtkiej historii projektu

Zapisz dat rozpoczcia, ewentualne zmiany

wielkoci zespou (powikszenie lub zmniejszenie), struktur zespou, dobre i ze chwile
zwizane z prac nad projektem.
Wykonaj to, by mc oszacowa rozmiar
i typ projektu, a take by znale interesujce
pytania do zadania.

252 Rozdzia 5. Zwinno i adaptacja

ODKRYWANIE

PROGRAMOWANIA

PRZYROSTOWEGO

Oto, w jaki sposb poznaem fascynujc

histori projektu, ktremu nadaem nazw
Ingrid (Cockburn 1998).
W pocztkowej fazie projektu, zesp
uzbiera wikszo znanych mi w tym czasie
wskanikw poraki. To, e ich pierwsza,
czteromiesiczna iteracja okazaa si katastrof, nie byo dla mnie adnym zaskoczeniem. Zaczem si nawet zastanawia,
dlaczego przebyem tak dug drog, by
usysze o tak oczywistej porace.
Niespodziank okazao si to, co zrobili
po pierwszej porace.
Po pierwszej iteracji zmienili w projekcie
niemale wszystko. Nigdy wczeniej nie syszaem o takim przypadku.
Cztery miesice pniej ponownie zbudowali system, uywajc innych rozwiza;
nie drastycznie rnych, ale wystarczajcych.
Co cztery miesice dostarczali dziaajce i przetestowane oprogramowanie,
a nastpnie siadali razem, by dowiedzie
si, co zrobili i jak usprawni proces (zrb
to samo).
Co najbardziej zaskakujce, nie tylko
rozmawiali o tym, co naley zmieni, ale
rwnie rzeczywicie zmieniali swj sposb
pracy.

Lekcja, jak wyniosem z tego wywiadu, nie

miaa nic wsplnego z porednimi efektami
pracy, ale raczej z fenomenem chci osignicia sukcesu i chci zmian (nawet co cztery miesice), byle tylko osign wymarzony sukces.
Po usyszeniu historii projektu i opowieci
na temat rnych wzlotw i upadkw przechodzimy do nastpnej kwestii.
Krok 3. Zapytaj, co naleaoby zmieni
nastpnym razem

Zapytaj: Jakie s najwaniejsze bdy popenione w trakcie projektu, ktrych nie chciaby powtrzy w nastpnym projekcie?.

Zapisz odpowiedzi i staraj si dodatkowymi pytaniami poznawa szczegy.

Po usyszeniu tego, czego ludzie nie chc
zrobi, ponownie przejd do nastpnego
punktu.
Krok 4. Zapytaj, co naleaoby powtrzy
nastpnym razem

Zapytaj: Jakie s kluczowe sprawy, ktre

z pewnoci chciaby powtrzy w nastpnym projekcie?.
Zapisz odpowiedzi. Jeli kto odpowie:
Ta czwartkowa gra w siatkwk bya naprawd dobra, take to zapisz.
WSPLNE UPIJANIE SI
Pewnego razu, gdy zadaem to pytanie
(w Skandynawii), uzyskaem odpowied:
Wsplne upijanie si.
Postanowiem sprbowa tego na wasnej skrze i tego samego wieczoru wybralimy si do pubu. Rzeczywicie, nastpnego dnia zauwayem znaczn popraw
poczucia wsplnoty.

Odpowiedzi na to pytanie bywaj naprawd

przerne: od jedzenia w lodwce, przez
wsplne wyjcia na miasto, kanay komunikacji, narzdzia programistyczne, architektur
systemw po model dziedzinowy. Zapisuj
wszystko, co usyszysz.
Krok 5. Okrel priorytety

Zapytaj: Jakie s twoje priorytety z uwzgldnieniem spraw, ktre lubie w projekcie? Co

jest najwaniejsze do utrzymania, a co moesz
negocjowa?. Zapisz odpowiedzi.
Warto rwnie zada pytanie: Co ci najbardziej zaskoczyo w projekcie?.
Krok 6. Znajd dowolne luki
w produkcie pracy lub projekcie

Zapytaj, czy powiniene co jeszcze wiedzie na temat projektu, i zobacz, gdzie to

doprowadzi.

Dostosowywanie si 253

W pewnej firmie wykonalimy dwustronicowy szablon wywiadu, by zapisywa wyniki i atwo wymienia si informacjami. Szablon
zawiera nastpujce czci:
1. Nazw projektu, stanowisko przesuchi-

wanej osoby (sam przesuchiwany pozostawa anonimowy).

2. Dane zwizane z projektem (pocztek
i koniec, maksymalna wielko zespou,
docelowa dziedzina, uywane technologie).
3. Historia projektu.
4. Co poszo le i czego nie naley powtarza.
5. Co poszo dobrze i co naley powtrzy.
6. Priorytety.
7. Inne.
Wykonaj wiczenie, zbierz wypenione szablony i przyjrzyj si im dokadniej. W zalenoci od sytuacji kilka osb moe spotka si
razem i porozmawia o wywiadach lub te
tylko przeczyta zebrane notatki.
Poszukaj wsplnych elementw w analizowanych projektach.
WZORZEC KOMUNIKACJI
W firmie, w ktrej wykonalimy szablon, we
wszystkich projektach pojawi si ten sam
schemat:
Gdy mamy dobr komunikacj z klientami i sponsorami oraz wewntrz zespou,
osigamy dobre wyniki. Gdy taka komunikacja nie wystpuje, nie osigamy dobrych
wynikw.

Cho przedstawione stwierdzenie wydaje si

trywialne, rzadko zostaje dostrzeone i zapisane. W rzeczywistoci rok po zebraniu przedstawionych wczeniej wynikw w firmie miao
miejsce nastpujce zdarzenie.

WZORZEC KOMUNIKACJI W AKCJI

Uczestniczyem w jednym z trzech prowadzonych w tamtym czasie projektw. Kady
z nich dotyczy maych zespow i ludzi siedzcych w rnych miastach.
Jak zapewne si domylasz, spdziem
mnstwo czasu i energii na komunikacji ze
sponsorami i programistami.
Wszystkie trzy projekty ukoczono mniej
wicej w tym samym czasie. Dyrektor dziau
programistycznego zapyta si, co jest
powodem rnicy dlaczego projekt,
w ktrym uczestniczyem zakoczy si
sukcesem, a dwa pozostae prowadzone
w tym samym czasie okazay si porak.
Przypomniawszy sobie wczeniejsze wywiady, stwierdziem, e moe to mie co
wsplnego z jakoci komunikacji midzy
programistami i sponsorami lub midzy
poszczeglnymi osobami z zespou.
Stwierdzi, e to bardzo interesujcy
pomys. Zarwno programici, jak i sponsorzy z dwch innych projektw zgaszali
problemy komunikacyjne z liderami projektw. Zarwno programici, jak i sponsorzy czuli si odizolowani. Z drugiej strony
sponsorzy w moim projekcie byli bardzo
zadowoleni z poziomu komunikacji.

W innej firmie znalazem inny wsplny

motyw. Oto, co usyszaem od jednej z przesuchiwanych osb.
MOTYW RNICY KULTUROWEJ
Wszyscy nasi projektanci interfejsw uytkownika maj doktoraty z psychologii i siedz kilka piter nad programistami.
Wystpia wic midzy nimi i programistami luka edukacyjna, kulturowa i fizyczna.
Mielimy problemy z powodu innego
podejcia tamtych osb do pewnych spraw,
a take z powodu znacznej odlegoci od
nich.

254 Rozdzia 5. Zwinno i adaptacja

Firma potrzebowaa wzmocni mechanizmy

komunikacji midzy dwoma wspomnianymi
grupami, a take zastosowa dodatkowe oceny
efektw pracy.
Z przedstawionych historyjek warto zapamita, e to, czego nauczysz si w trakcie
wywiadw, moe okaza si niezwykle wane
ju w nastpnym projekcie. Zwracaj uwag
na ostrzeenia pojawiajce si w trakcie
wywiadw.
Na pocztku projektu
Postaraj si w jaki sposb skrci standardow metodologi firmy. Naley to zrobi niezalenie od tego, czy bazow metodologi jest
ISO9001, XP, RUP, Crystal lub wasne rozwizania.
Etap 1. Dostosowanie metodologii bazowej

Jeli to moliwe, niech nad propozycj bazowej metodologii dla projektu pracuj dwie
osoby. Praca bdzie przebiega szybciej, osoby
te prawdopodobnie odkryj bdy w myleniu drugiej strony i pomog sobie nawzajem
w doszlifowaniu pomysw.
Musz przej przez cztery kroki.
1. Okreli, prac ilu osb trzeba bdzie koor-

dynowa, a take pozna ich rozmieszczenie geograficzne (patrz siatka z rysunku

4.22). Okreli, jakiego poziomu poprawnoci oprogramowania si wymaga i jakie
szkody mog spowodowa ewentualne
bdy. Okreli i zapisa priorytety projektu: czas wypuszczenia na rynek, poprawno, inne istotne czynniki.
2. Wykorzystujc zasady projektowania metodologii z rozdziau 4., osoby te musz
okreli podstawowe parametry metodologii: poda, jak cise powinno by
przestrzeganie standardw; poda, jak
rozbudowan dokumentacj naley wyko-

na; wskaza poziom obrzdowoci ocen

i dugo przyrostu lub iteracji (czas wymagany do dostarczenia dziaajcego kodu
rzeczywistym uytkownikom, nawet jeli
s oni tylko testerami).
Jeli okae si, e czas iteracji jest duszy ni
cztery miesice, trzeba znale inny sposb na
tworzenie przetestowanej i dziaajcej wersji
systemu w mniej ni cztery miesice, by zasymulowa rzeczywiste dostarczanie systemu.
3. Wybra metodologi bazow, ktra nie jest

znaczco rna od sposobu pracy preferowanego przez zesp.

Pamitaj, e atwiej modyfikowa istniejc
metodologi, ni tworzy wasn. Mona
zacz od standardw korporacyjnych, opublikowanych wersji RUP, XP, Crystal Clear,
Crystal Orange lub metodologii uytej w poprzednim projekcie.
4. Skrci metodologi do podstawowych

przepyww kto przekazuje co i komu a take wskaza konwencje, na

ktre grupa zapewne si zgodzi.
Przedstawione zadania mog zaj od jednego do kilku dni w przypadku projektw
maej i redniej wielkoci. Jeli zaczyna wydawa si, e dwie osoby spdz nad wyborem metodologii bazowej wicej ni tydzie,
dodaj do zespou jeszcze dwie osoby, by prace
zakoczy w cigu nastpnych dwch dni.
Krok 2. Metodologia pocztkowa

Zwoaj zebranie zespou, na ktrym zostanie

omwiona metodologia bazowa i konwencje. Zmodyfikuj j, by staa si metodologi
pocztkow. W wikszych projektach, gdzie
zebranie caego zespou jest niepraktyczne,
zbierz reprezentantw kadego stanowiska.

Dostosowywanie si 255

Celem spotkania jest:

wyapanie ozdobnikw,
znalezienie sposobw usprawnienia procesu i zmniejszenia kosztu komunikacji,
wykrycie problemw, ktrych nie ujawni
szkic metodologii bazowej.
W trakcie spotkania postaraj si odpowiedzie
na nastpujce pytania:
Jak dugie bd iteracje i przyrosty (i czym
bd si rniy)?
Gdzie bd siedzie ludzie?
Co zrobi, by utrzyma wysokie morale
i dobry poziom komunikacji?
Jakie bd potrzebne produkty pracy
i systemy oceny, jaka musi by ich obrzdowo?
Ktre standardy narzdzi, rysowania, testw i kodu s obowizkowe, a ktre tylko
zalecane?
Jak zostanie rozwizane raportowanie
czasu?
Ktre konwencje naley ustali ju teraz,
a ktre mona wprowadzi i rozwin
w pniejszym terminie?
Podstawowym celem spotkania jest wskazanie sposobw wykrywania ewentualnych
problemw komunikacyjnych i dotyczcych
morale.
Wynikami spotkania powinny by:
podstawowy przepyw pracy,
kryteria wsppracy poszczeglnych rl,
w szczeglnoci w kwestii nakadania si
obowizkw i deklarowania kamieni milowych,
oglne standardy i konwencje do wprowadzenia,
rozwizania komunikacyjne do przewiczenia.

To Twoja metodologia pocztkowa.

Spotkanie powinno zaj poow dnia, ale
nie wicej ni cay dzie.
W poowie pierwszej iteracji
Niezalenie od tego, czy iteracja ma dugo
dwch tygodni, czy trzech miesicy, przeprowadzasz krtkie wywiady z czonkami
zespou, indywidualnie lub grupowo, w poowie iteracji. Powi na nie od jednej do trzech
godzin.
Oto podstawowe pytanie, ktre naley
zada:
Czy uda nam si to zrobi, jeli bdziemy pracowa tak, jak teraz?
Nie naley oczekiwa, i w pierwszej iteracji uda si cakowicie zmieni sposb dziaania zespou, chyba e jest on cakowicie
zepsuty. Szukamy raczej sposobu bezpiecznego dostarczenia pierwszej wersji. Jeli metodologia pocztkowa bdzie moga wytrzyma tak dugo, bdziesz mia wicej czasu,
wicej dowiadczenia i lepszy moment na
wprowadzanie zmian tu po pierwszym udanym dostarczeniu systemu.
Z tego powodu celem pierwszego wywiadu lub spotkania jest wykrycie, czy nie
dzieje si co krytycznego, co mogoby zagrozi dostarczeniu pierwszej wersji.
Jeli zauwaysz, e aktualny sposb pracy
nie sprawdza si, najpierw rozwa ograniczenie zasigu pierwszego dostarczenia.
Wikszo zespow przeszacowuje to,
co jest w stanie dostarczy w pierwszej wersji. To normalne i nie stanowi powodu do
odrzucania metodologii. Wynika to po czci
z ambicji zarzdu ukadajcego nierealistyczne
harmonogramy i zbyt optymistycznych programistw, ktrzy czsto zapominaj o potrzebie nauki, spotka i poprawiania bdw. Ma
na to rwnie wpyw szybko uczenia si

256 Rozdzia 5. Zwinno i adaptacja

nowych technologii i kolegw z zespou. Przesadzenie z liczb rzeczy, ktr mona dostarczy w pierwszym wydaniu, naprawd jest
cakowicie normalne.
Pierwszym krokiem powinna by redukcja
zasigu.
Moe si okaza, e zmniejszenie zasigu
nie wystarcza. Moe si okaza, e wymagania nie s wystarczajco jasne dla programistw lub e architekci nie s w stanie w odpowiednim czasie zakoczy specyfikacji
architektury.
Jeli tak si dzieje, musisz zareagowa
szybko i znale nowy sposb pracy. To w poczeniu z drastycznie zmniejszonym zasigiem powinno spowodowa udane dostarczenie pierwszej wersji.
Mona wprowadzi nakadanie si prac,
posadzi ludzi bliej siebie, zmniejszy idealno pocztkowej architektury i w lepszym
stopniu wykorzysta nieformalne kanay komunikacji. Konieczne mog okaza si awaryjne zmiany zespou, awaryjne szkolenia,
konsultacje i zatrudnienie dowiadczonych
programistw z zewntrz.
Gwnym celem jest dostarczenie czego
pewnego niewielkiego, dziaajcego i przetestowanego kodu w pierwszej iteracji. To
bardzo istotny czynnik sukcesu projektu
(Cockburn 1998). Po wydaniu pierwszej wersji bdzie mona chwil odsapn i dokadnie
zastanowi si nad powodem problemw.
Po kadej iteracji
Po kadej iteracji zwoaj zebranie na temat
wnioskw dotyczcych sposobu pracy.
Analiza wnioskw to bardzo istotny czynnik sukcesu w ewolucji metodologii, podobnie
jak programowanie przyrostowe stanowi jeden z czynnikw sukcesu wytwarzania oprogramowania.

Dugo i intensywno analizy zaley od

firmy i kraju. Amerykanie s zawsze zajci,
maj mao pienidzy i cigle biegn. Nie dziwi
wic, e Amerykanie na analiz powicaj
jedynie od 2 do 4 godzin. W innych czciach
wiata analiza wnioskw trwa duej.
Pewnego razu uczestniczyem w dwudniowym spotkaniu poza miejscem pracy,
ktre czyo analiz sposobu pracy, budowanie wizi zespou i planowanie nastpnej
iteracji. Co nie powinno dziwi, miao miejsce
w Europie.
Gwnym powodem przesunicia analizy do momentu zakoczenia pierwszej iteracji jest moliwo poznania penego efektu
wszystkich elementw metodologii, poniewa udao si dostarczy dziaajce i przetestowane oprogramowanie. Tylko wtedy mona oceni, czego zrobio si za mao, a czego
za duo.
Istnieje rwnie drugi powd, dla ktrego
warto zaczeka z analiz do koca iteracji:
ludzie bardzo czsto s wyczerpani tu po
wydaniu oprogramowania. Spotkanie daje
szans na zapanie oddechu. Przeprowadzane
regularnie integruje si z rytmem projektu.
Po kadej iteracji czonkowie zespou chtnie
skorzystaj z odmiany i uspokojenia umysu.
Niezalenie od tego, czy spotkanie zajmuje
dwie godziny, czy dwa dni, naley przede
wszystkim zada dwa pytania:
1. Czego si nauczylimy?.
2. Co moemy zrobi lepiej?.

Odpowiedzi mog dotyczy rnych kwestii

zwizanych z projektem: od zarzdzania
przez mierzenie czasu, komunikacj w grupie,
ukad biurek, oceny projektu, po standardy
i skad zespou.
Bardzo czsto zespoy po pierwszej iteracji
zacieniaj standardy, maj wicej dowiad-

Dostosowywanie si 257

czenia, lepiej przekazuj sobie prac, robi

wicej testw i znaj struktur zespou.
Zmiany w drugiej i kolejnych iteracjach
bd znacznie mniejsze, poniewa zesp
dostarczy ju oprogramowanie i wie, jak to
zrobi ponownie.
W poowie nastpnej iteracji
Po pierwszej iteracji zesp ma ju jeden
(ledwie wystarczajcy) udany sposb pracy.
Uyta metodologia staje si w tym przypadku
metodologi awaryjn.
Majc plan ratunkowy, mona nieco odwaniej proponowa zmiany w trakcie spotkania w poowie drugiej i kolejnych iteracji.
W trakcie spotka w poowie nastpnych
iteracji starajcie si szuka nowych i lepszych
sposobw dostarczania oprogramowania.
Zobacz, czy moesz wykona ktre z poniszych zada:
wyci cay fragment metodologii,
zwikszy rwnolego prac,
lepiej wykorzysta komunikacj nieformaln do przekazywania informacji o projekcie,
wprowadzi nowe i lepsze systemy testowania,
wprowadzi nowsze i lepsze wytyczne
dotyczce pisania testw.
zapewni blisz wspprac rnych grup
uczestniczcych w projekcie: ekspertw
dziedzinowych i uytkowych, programistw, testerw, trenerw, biura obsugi
klienta i biura napraw.
Do uzyskania danych w trakcie iteracji wykorzystuj wywiady bezporednie lub spotkania grupowe. Przez ten czas zesp zbierze
odpowiednie dowiadczenie i bdzie wiedzia,
czego dotycz spotkania i co naley w nich
zgasza.

Jeli w projekcie s stosowane iteracje

o dugoci trzech tygodni lub krtsze, mona
zrezygnowa z pniejszych analiz w poowie
iteracji.
Dlaczego w ogle zajmowa si analiz
w poowie iteracji, skoro ju udao si dostarczy oprogramowanie i s planowane analizy
dziaania po kadej iteracji?
W poowie cyklu iteracji to, co sprawia
najwiksze problemy, jest najlepiej widoczne.
Szczegy problemu nie bd tak dobrze
pamitane za 6 lub 8 tygodni, czyli w trakcie
spotkania po iteracji. Lepiej jest wic od razu
pozna szczegy problemw i wyprbowa
sposoby ich rozwizania, ni czeka na ich
poznanie kilka tygodni, a nawet miesicy.
A jeli nowy pomys okae si niewypaem?
Czasem zesp prbuje nowego pomysu
w drugiej lub trzeciej iteracji, ale okazuje si, e
nowe rozwizanie nie funkcjonuje zgodnie
z prognozami.
ZMIANY

STRUKTURY ZESPOU

W POOWIE PROJEKTU

W jednym projekcie przeszlimy przez trzy

rne struktury zespou w trakcie trzeciej
iteracji.
Na pocztku trzeciej iteracji stwierdzilimy, e stosowana do tej pory struktura
zespou nie sprawdza si najlepiej. Wybralimy wic now struktur do zastosowania
w trzeciej iteracji.
Okazaa si katastrof. Ju po dwch
tygodniach wiedzielimy, e musimy j
szybko zmieni.
Zamiast wraca do oryginau, dziwnej
ale zapewniajcej sukces struktury, zasugerowalimy nowe podejcie i od razu wcielilimy je w ycie.
Okazao si dobre, wic stosowalimy
je a do koca projektu.

258 Rozdzia 5. Zwinno i adaptacja

Dziki przetestowaniu kilku rozwiza w jednej iteracji, udao si nam szybko usprawni
metodologi. Warto pamita o istnieniu takiej
szansy.
Ocena po zakoczeniu projektu
Stosowanie analiz w trakcie i po kadej iteracji
zmniejsza potrzeb stosowania ocen poprojektowych. Wydaje mi si, e ocen naley
dokonywa w trakcie projektu, gdy zmiany
mog jeszcze przynie projektowi co dobrego. Po projekcie jest ju na to za pno.
Najczciej okazuje si, e zespoy, ktre
stosuj oceny poprojektowe nie przejmuj si
analiz w trakcie trwania projektu, a nastpnie
bardzo mocno chc si dowiedzie, co poprawi w nastpnym projekcie. Jeli znajdziesz
si na takim spotkaniu, zasugeruj, by nastpnym razem przeprowadza spotkania w trakcie trwania projektu, a nie po nim.
Z drugiej strony ocena poprojektowa to
dobry moment do podsumowania oglnej
pracy zespou i sposobu zarzdzania projektem. W takiej sytuacji proponuj zapozna si
z ksik Project Retrospectives (Kerth 2001),
ktra omawia, w jaki sposb prowadzi dwudniow sesj oceny projektu.
Zastanw si w trakcie analizy przeprowadzanej po projekcie, kto mgby skorzysta ze zgromadzonych informacji i jakie
wskazwki mona przekaza osobom prowadzcym nastpne projekty. Warto wykona
krtk (dwustronicow) notk dla nastpnego
zespou, podsumowujc plusy i minusy aktualnego projektu.
Oczywicie, warto take napisa krtkie
jednostronicowe uwagi na kocu kadej z analiz po iteracji jako standardowy wynik ich
przeprowadzenia.

SPOSOBY ANALIZY PROJEKTU

Namacalnym wynikiem sesji analizy w trakcie
iteracji lub po niej jest lista spraw umieszczana pniej na cianie, by bya widoczna dla
wszystkich osb uczestniczcych w projekcie i przypominaa im o nowych zadaniach.
Osobicie lubi od razu w trakcie spotkania pisa na docelowym arkuszu papieru. To
wanie on najlepiej utkwi w pamici caej
grupy. Inne osoby lubi kopiowa wypracowane wyniki na czyste arkusze, by zapewni
ich lepszy wygld. Osoby, ktre tworzyy analiz przedstawion na rysunku 3.10 zdecydoway si na uycie samoprzylepnych karteczek zamiast bloku papieru.
Przykadowy sposb analizy projektu
Istnieje kilka technik prowadzenia spotkania
analizujcego projekt i przedstawiajcego
wyniki. Preferuj uycie najprostszego rozwizania, jakie uda si wymyli. Oto skrcona
wersja mojej propozycji (bardziej szczegowy
opis znajduje si w: Cockburn 2005 i Tabaka
2006).
ANALIZA PROJEKTU
Cze. Witam na spotkaniu, ktrego celem
jest analiza projektu, by mc doskonali
nasze sposoby wytwarzania oprogramowania.
Celem tego spotkania nie jest wytykanie
palcami, obwinianie ani unikanie obwiniania. Ma ono na celu wskazanie, w ktrych
miejscach si zacinamy, i zaproponowanie
rozwizania tych problemw.
Wynikiem tego spotkania bdzie arkusz
papieru z pomysami do zastosowania
w nastpnej iteracji i sprawami, o ktrych
po prostu chcemy pamita.
Arkusz podzielimy na trzy czci.
Po lewej stronie umiecimy rzeczy, ktre
robimy dobrze i ktrych nie chcemy straci
w nastpnej iteracji.

Dostosowywanie si 259

Po prawej stronie umiecimy rzeczy,

nad ktrymi musimy jeszcze mocno popracowa.
Po lewej stronie na dole umiecimy
przeciwwag do tego, co robimy dobrze,
czyli wskaemy problemy, z ktrymi staramy
si upora (patrz rysunek 5.1).

Rysunek 5.1. Przykad wynikw spotkania analizujcego

projekt

Zacznijmy od tego, co zrobilimy dobrze.

Czy jest co, co robimy dobrze, i chcemy,
bymy wykonywali to w ten sam sposb
w nastpnej iteracji?

W tym momencie rozpoczyna si dyskusja.

Cakiem moliwe, e kto zacznie wymienia problematyczne obszary zamiast tego, co
robimy dobrze. Jeli problem jest istotny,
zapisz go od razu w czci dotyczcej problemw. Zapewnij czas na zastanowienie si
i dyskusj.
W pewnym momencie poprowad dyskusj dalej.
Dobrze. Jakie problemy wystpiy w ostatniej iteracji i jak chcemy si ich pozby?

W czci dotyczcej problemw pisz moliwie

niewiele: kady problem opisuj tylko kilkoma
sowami i w miar moliwoci cz podobne

problemy. Celem tej czci jest zasugerowanie

obszarw wymagajcych poprawy, a nie skupianie si na problemach.
Zbierz sugestie. Jeli lista stanie si bardzo duga, zapytaj, ile z tych nowych rozwiza zesp rzeczywicie chce wprowadzi
w nastpnej iteracji. Spogldanie na dug list
spraw do poprawienia moe dziaa depresyjnie. Najlepiej, by lista spraw do poprawienia bya krtka. Pisanie po arkuszu grubym
flamastrem to doskonay sposb szybkiego
pozbywania si wolnego miejsca na kartce.
Okresowo sprawdzaj, czy kto nie zgosi
dodatkowych rozwiza, ktre grupa powinna
pozostawi.
Pod koniec spotkania ponownie przeanalizujcie ca list. Zauwa, czy ludzie rzeczywicie zgadzaj si na nowe pomysy, czy po
prostu siedz cicho.
Po spotkaniu umie arkusz papieru w widocznym miejscu.
Na nastpne spotkanie tego typu przynie
wczeniejszy arkusz papieru i zacznij od analizy tego, co udao si wykona, co si sprawdzio, a co jeszcze wymaga sprawdzenia.
Przeprowadzanie tego rodzaju spotka co
2 6 tygodni zapewnia rozwj lokalnej kultury metodologii zwinnej.
Warto oceny projektu
Fragment na temat shu-ha-ri z wprowadzenia pasuje do wniosku pyncego z oceniania
projektu:
Gdy uczysz si techniki i gdy asymptotycznie dociera ona do twojego umysu, gdy widzisz innych wiczcych,
zaczynasz si zastanawia nad jej popraw. Warto zada kilka interesujcych pyta:
1. Jak dziaa ta technika?
2. Dlaczego ta technika dziaa?

260 Rozdzia 5. Zwinno i adaptacja

3. Jak ta technika wie si z innymi

praktykowanymi przeze mnie technikami?

4. Jakie s konieczne warunki pocztkowe i kocowe, by zastosowa t
technik w walce?
Gdy tworzysz sensowny repertuar
technik, z ktrych potrafisz dobrze korzysta, musisz spotyka si z moliwie wieloma innymi praktykami. Gdy
ogldasz innych, musisz zada sobie
trzy pytania i odpowiedzie na nie:
1. Ktrych praktykw ceni i podzi-

wiam?
2. Czy wykonuj dziaania inaczej ode

mnie?
3. Jak mog zmieni moje dziaania

(model mentalny i jego realizacj),

by zniwelowa rnice, ktre wydaj
mi si istotne?
Pytania na temat przeciwnika, ktre
naley sobie zada:
1. Gdzie moesz kontrolowa dziaa-

nia i ruchy przeciwnika?

2. Gdzie moesz si uspokoi i uczyni techniki bardziej efektywnymi
dziki wyciszeniu umysu?
3. Czy przeciwnik wyglda podobnie
do podziwianych praktykw?
W trakcie analizy musisz szczerze
oceni wyniki kadego testu. Wracaj do
shu przez ha i ri, jakby chadza lepymi uliczkami.
Sam nie mgbym okreli tego lepiej.

CO

ZATEM BD ROBI JUTRO ?

Potraktuj zwinno jako nastawienie, a nie

wzr. Spjrz na aktualny projekt i zapytaj:
W jaki sposb moemy pracowa wedug
zasad zwinnoci?.
Przyjrzyj si, jak daleko Twj zesp znajduje si od punktw krytycznych. Przekonaj si, jak w kreatywny sposb moesz
si do nich zbliy lub je zasymulowa.
Zobacz, gdzie zesp moe uczyni metodologi lejsz. Zobacz, gdzie to nie wystarcza.
Przeprowad jeden z opisanych wywiadw na temat projektu.
Niech inne osoby rwnie przeprowadz
wywiady. Podzielcie si wynikami. Znajd
w wywiadach wsplne wtki.
Przeprowad jednogodzinn analiz projektu. Gdy zaczn si opisy problemw,
zapisz je. Porwnaj je nastpnie z list
przedstawion w rozdziale 3. Poszukaj
rozwiza i rozszerz list. Wyniki analizy
umie na arkuszu papieru. Zauwa, ile
osb si nim zainteresowao.
Przekonaj si, czy atwiej zebra ludzi na
drug analiz projektu. Naucz si przekonywa ludzi do mniejszego narzekania, a czstszego zgaszania sposobw naprawy sytuacji.
Staraj si sta projektantem metodologii drugiego poziomu. Tak, to cz Twojej profesji.