Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00131 008397 11000622 na godz. na dobę w sumie
Agile Software Development. Gra zespołowa. Wydanie II - książka
Agile Software Development. Gra zespołowa. Wydanie II - książka
Autor: Liczba stron: 480
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-1503-2 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> agile - programowanie
Porównaj ceny (książka, ebook, audiobook).
Poznaj zasady doskonałej metodologii wytwarzania oprogramowania

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. Gra zespołowa' 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.

Poznaj wydajne i efektywne zwinne programowanie!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Agile Software Development. Gra zespo‡owa. Wydanie II Autor: Alistair Cockburn T‡umaczenie: Rafa‡ Joæca ISBN: 978-83-246-1503-2 Tytu‡ 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 (cid:149) Jak dopasowa(cid:230) metodologiŒ Agile do specyfiki firmy? (cid:149) W jaki spos(cid:243)b powi„za(cid:230) Agile z innymi metodologiami? (cid:149) Jak wdro¿y(cid:230) Agile w ca‡ej strukturze firmy? Produkcja oprogramowania wymaga nie tylko doskona‡ej znajomo(cid:156)ci technologii, ale tak¿e metodologii zarz„dzania projektem. Kluczowym elementem jest tu umiejŒtno(cid:156)(cid:230) b‡yskawicznego reagowania na zmiany, sytuacje kryzysowe i b‡Œdy. Istnieje wiele usystematyzowanych metodologii wytwarzania oprogramowania, kt(cid:243)re jednak rzadko sprawdzaj„ siŒ w przypadku ma‡ych zespo‡(cid:243)w projektowych lub projekt(cid:243)w realizowanych w kr(cid:243)tkim czasie. Dla takich projekt(cid:243)w opracowano metodologiŒ Agile. To (cid:132)zwinne programowanie(cid:148) zdobywa coraz wiŒcej zwolennik(cid:243)w i jest wdra¿ane w wielu przedsiŒbiorstwach. Ksi„¿ka (cid:132)Agile Software Development: The Cooperative Game (2nd Edition) (The Agile Software Development Series)(cid:148) to om(cid:243)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(cid:230). Przeczytasz o programowaniu ekstremalnym, adaptacji tej metodologii do potrzeb konkretnych zadaæ i unikaniu b‡Œd(cid:243)w przy wytwarzaniu oprogramowania. (cid:149) Zasady in¿ynierii oprogramowania (cid:149) Dob(cid:243)r zespo‡u projektowego (cid:149) Komunikacja wewn„trz zespo‡u projektowego (cid:149) Wyb(cid:243)r odpowiedniej metodologii (cid:149) Programowanie ekstremalne (cid:149) Zarz„dzanie zmianami (cid:149) Metodologie Crystal Poznaj wydajne i efektywne zwinne programowanie! Wydawnictwo Helion ul. Ko(cid:156)ciuszki 1c 44-100 Gliwice tel. 032 230 98 63 e-mail: helion@helion.pl SPIS TREŚCI SPIS RYSUNKÓW I TABEL SPIS OPOWIADAŃ PRZEDMOWA PRZEDMOWA DO DRUGIEGO WYDANIA ROZDZIAŁ 0. NIEWIADOME I NIEKOMUNIKATYWNE 9 15 19 29 33 Problem z analizą doświadczenia ................................................................ 35 Niemożność komunikacji .............................................................................. 39 Trzy poziomy słuchania ................................................................................ 44 Co zatem będę robił jutro? ............................................................................ 49 ROZDZIAŁ 0.1. NIEWIADOME I NIEKOMUNIKATYWNE — EWOLUCJA 51 Komunikacja i wspólne doświadczenia ...................................................... 53 Shu-ha-ri ........................................................................................................... 54 ROZDZIAŁ 1. GRA ZESPOŁOWA POMYSŁOWOŚCI I KOMUNIKACJI 57 Oprogramowanie i poezja ............................................................................. 59 Oprogramowanie i gry .................................................................................. 60 Drugie spojrzenie na grę zespołową ........................................................... 66 Co to oznacza dla mnie? ................................................................................ 73 ROZDZIAŁ 1.1. ZESPOŁOWA GRA POMYSŁOWOŚCI I KOMUNIKACJI — EWOLUCJA 75 Gra bagienna ................................................................................................... 77 Współzawodnictwo we współpracy ............................................................ 78 Inne miejsca z grą zespołową ....................................................................... 80 Raz jeszcze o inżynierii oprogramowania .................................................. 80 5 6 • SPIS TREŚCI ROZDZIAŁ 2. POJEDYNCZE OSOBY 93 Ci dziwni ludzie ...............................................................................................95 Obchodzenie trybów porażki ........................................................................99 Lepsze działanie w jednych aspektach niż w innych .............................107 Korzystanie z trybów sukcesu .....................................................................118 Co 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 ...................................................................133 Zasklepianie luk komunikacyjnych ...........................................................147 Zespoły jako społeczności ............................................................................155 Zespoły jako ekosystemy .............................................................................164 Co 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 .........................................173 Pojęcia metodologiczne ................................................................................173 Zasady projektowania metodologii ...........................................................198 XP od kuchni ..................................................................................................221 Dlaczego w ogóle zajmować się metodologiami? ....................................225 Co zatem będę robił jutro? ...........................................................................227 ROZDZIAŁ 4.1. METODOLOGIE — EWOLUCJA 229 Metodologie kontra strategie ......................................................................231 Metodologie w całej organizacji .................................................................232 Procesy jako cykle .........................................................................................233 Opisanie metodologii prostszymi słowami ...............................................236 SPIS TREŚCI • 7 ROZDZIAŁ 5. ZWINNOŚĆ I ADAPTACJA 239 Lekko, aczkolwiek wystarczająco .............................................................. 241 Zwinność ........................................................................................................ 243 Dostosowywanie się ..................................................................................... 250 Co zatem będę robił jutro? .......................................................................... 260 ROZDZIAŁ 5.1. ZWINNOŚĆ I ADAPTACJA — EWOLUCJA 261 Sprostowanie błędnego zrozumienia przekazu ...................................... 264 Ewolucja metodologii zwinnych ................................................................ 281 Nowe zagadnienia metodologii ................................................................. 293 Powracające pytania ..................................................................................... 309 Zwinność poza tworzeniem oprogramowania ........................................ 329 ROZDZIAŁ 6. METODOLOGIE CRYSTAL 353 Kształt rodziny Crystal ................................................................................. 355 Crystal Clear .................................................................................................. 358 Crystal Orange .............................................................................................. 360 Crystal Orange Web ..................................................................................... 362 Co zatem będę robił jutro? .......................................................................... 366 ROZDZIAŁ 6.1. METODOLOGIE CRYSTAL — EWOLUCJA 367 Genetyczny kod Crystal .............................................................................. 369 Crystal Clear .................................................................................................. 374 Rozciąganie Crystal Clear do Yellow ......................................................... 376 DODATEK A MANIFEST ZWINNEGO WYTWARZANIA OPROGRAMOWANIA 383 Agile Alliance ................................................................................................. 385 Manifest .......................................................................................................... 386 Wspieranie wartości ..................................................................................... 388 DODATEK A.1 MANIFEST ZWINNEGO WYTWARZANIA OPROGRAMOWANIA I „DEKLARACJA WZAJEMNEJ ZALEŻNOŚCI” 395 Nowa odsłona manifestu zwinności ......................................................... 397 Deklaracja wzajemnej zależności ............................................................... 400 8 • SPIS TREŚCI DODATEK B NAUR, EHN, MUSASHI 407 Peter Naur, „Programowanie jako budowanie teorii” ............................409 Pelle Ehn. Gry językowe Wittgensteina ....................................................419 Musashi ...........................................................................................................431 DODATEK B.1 NAUR, EHN, MUSASHI — EWOLUCJA 437 Naur .................................................................................................................439 Ehn ...................................................................................................................439 Musashi ...........................................................................................................439 DODATEK C SŁOWO KOŃCOWE 441 Zwinne wytwarzanie oprogramowania ....................................................443 Biznes jako gra zespołowa ...........................................................................444 Przywództwo .................................................................................................444 Wszyscy ..........................................................................................................445 DODATEK D BIBLIOGRAFIA SKOROWIDZ 447 461 5 Zwinność 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, przejmowaniu inicjatywy i bezpośredniej komunikacji twarzą w twarz. • Metodologia to zestaw konwencji stosowanych przez zespół, przy czym różne konwencje sprawdzają się w różnych rodzajach projektów. • Lekkie metodologie pozwalają dostarczać oprogramowanie szybciej, ale wraz 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 odpowiednia dla danego projektu i jak mamy zastosować wspomniane zasady w naszym konkretnym projekcie? Podrozdział „Lekko, aczkolwiek wystarczająco” wskazuje, jaka lekkość jest odpowiednia dla danego projektu, a w szczególności, co oznacza bycie zbyt lekkim. 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ów itp. Gdy projekt oddala się od tych istotnych miejsc, trzeba w nim stosować mniej zwinne mechanizmy. W szczególności zespoły wirtualne znacząco utrudniają wprowadzenie w życie zasad zwinności, bo są od siebie mocno oddalone. 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ło dobrze, a co należy zmienić. 239 Zwinność i adaptacja LEKKO, ACZKOLWIEK WYSTARCZAJĄCO......................................241 Ledwo wystarczające ................................................................................... 242 Zalecenia dotyczące dokumentacji............................................................ 243 ZWINNOŚĆ ...........................................................................243 Punkty krytyczne.......................................................................................... 244 Problem z zespołami wirtualnymi ............................................................. 246 DOSTOSOWYWANIE SIĘ ...........................................................250 Potrzeba analizy przeszłych działań ......................................................... 250 Technika rozwoju metodologii................................................................... 250 Sposoby analizy projektu ............................................................................ 258 CO ZATEM BĘDĘ ROBIŁ JUTRO? ................................................260 240 LEKKO, ACZKOLWIEK WYSTARCZAJĄCO Przedstawiona do tej pory teoria wskazuje, by przede wszystkim stosować przekaz ustny do propagowania wszystkich informacji zebra- nych w trakcie realizacji projektu. Nasza intuicja podpowiada nam, że prze- kaz ustny nie wystarcza. P O S Z U K I W A N I E D O K U M E N T A C J I Pewien programista zaproponował swojej firmie ponowne napisanie jej flagowego produktu, ponieważ nie było do niego dokumentacji, żadna z pozostałych osób nie znała szczegółów powstania systemu i 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 jednym i tym samym oryginalnym projekcie. Wszyst- kie trzy miały być wytwarzane w rożnych miejscach. Stwierdził również, że w takiej sytuacji przekaz ustny po prostu nie ma prawa bytu. Jest całkiem możliwe, że zdobyte informacje był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ępnej rozgrywki, podcinamy sobie skrzydła. Lekko, aczkolwiek wystarczająco • 241 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ć zasoby dla każdego z celów. W idealnej sytuacji dokumentowanie należałoby odkładać na jak 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ę robimy zbyt późno, może się okazać, że odeszła osoba, która wiedziała coś istotnego dla następnego projektu. 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 nie ma znaczenia, czy modele i inna dokumen- tacja są kompletne i czy idealnie odpowiadają rzeczywistemu systemowi lub czy są zgodne z aktualną wersją kodu. Ważne jest tylko, czy osoby, 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 dodatkowy wysiłek włożony w dokumentowanie modeli ponad 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 dziwacznego procesu” (to ich słowa, nie moje). Analizując te wypowiedzi w nowym świetle, nietrudno domyślić się, że odnieśli sukces dlatego, że dokonali dobrego wyboru i zaprzestali prac nad pewnymi kanałami komunikacji od razu po tym, jak osiągnęli wystarczający poziom zrozumienia. Wykonali odpowiednią pracę dokumentacyjną, ale jej nie doskonalili. 242 • Rozdział 5. Zwinność i adaptacja Adekwatność to doskonały warunek, jeśli zespół musi szybko gnać w kierunku głównego celu, a nie ma wielu zasobów. Przypomnijmy programistę, który powie- dział: „Jest dla mnie oczywiste, że gdy zaczy- nam tworzyć przypadki użycia, modele obiektów itp., moja praca ma jakieś znaczenie. Ale w pewnym momencie przestaje ona być użyteczna, stając się problemem i źródłem strat. Nie potra- fię wykryć przekroczenia tego punktu i nigdy nie słyszałem dyskusji na ten temat. To bardzo denerwujące, ponie- waż użyteczne działania zamieniają się w stratę czasu”. Poszukujemy punktu, w którym użyteczna praca staje się balastem. To druga z wymie- nionych umiejętności. LEDWO WYSTARCZAJĄCE Sądzę, że nie muszę dawać przykładów zbyt ciężkich lub zbyt lekkich metodologii. Więk- szość programistów widziała lub słyszała wiele takich przykładów. Z drugiej strony „jedynie trochę za lek- kie” metodologie są trudne do znalezienia i wyjątkowo przydatne naukowo. To dzięki nim dowiadujemy się, co oznacza wyrażenie ledwo wystarczający. We wcześniejszej części książki pojawiły się dwie tego rodzaju historie: „Ciągły brak dokumentacji” i „Przyklejanie myśli do ścia- ny”. W każdej z nich dobrze działający projekt w kluczowym momencie przechodził poniżej poziomu wystarczalności. C I Ą G Ł Y B R A K D O K U M E N T A C J I ( P O W T Ó R K A) Ten zespół stosował wszystkie praktyki XP i dostarczał oprogramowanie klientowi w określonym czasie. Po kilku latach spon- sor spowolnił prace projektowe, aż wreszcie je zatrzymał. Gdy zespół przestał istnieć, po syste- mie nie pozostała żadna pisana doku- mentacja, więc żadna z innych osób nie mogła poznać szczegółów jego budowy. Wystarczająca dawniej kultura werbalna przestała wystarczać. W tej historii zespół osiągnął podstawowy cel gry, dostarczył działający system, ale nie udało mu 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 dla potrzeb 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” Naura moż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ń. P R Z Y K L E J A N I E M Y Ś L I D O Ś C I A N Y ( P O W T Ó R K A) Analitycy nie mogli poradzić sobie z dzie- dziną, która była zbyt złożona. Właśnie przeszli z ciężkiego procesu na XP i sądzili, że nie wolno im tworzyć żadnej papierowej dokumentacji. Mijały miesiące i mieli coraz to większe problemy ze zdecydowaniem się na szcze- góły następnych etapów prac i wskazanie implikacji swoich decyzji. Znaleźli się poni- żej linii wystarczalności dla swojej gry. Aby uzdrowić 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ść” nie jest związana bezpośrednio z metodologią, ale raczej z brakiem dopasowania metodo- logii i projektu jako ekosystemu. To, co jest ledwo 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 nie komunikują się ze sobą wystarczająco dobrze, by zapewnić efektywne przekazywanie in- formacji. Wartość idealna, „ledwo wystarczalna”, zależy od rodzaju projektu i wielu innych czynnikó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 znalezieniu punktu „ledwo wystarczalny” przy każdej większej zmianie elementów projektu. Zwinność • 243 nikacji, jeśli to tylko możliwe, włączając w to wizyty osobiste lub krótkie klipy wideo. • Jeśli projektanci są ekspertami w swej dziedzinie i siedzą blisko siebie, poproś o zastąpienie dokumentacji projektowej rysunkami na tablicy, a następnie zrób zdjęcia tych rysunków. • Pamiętaj jednak, o tym, że inne osoby przychodzące po zespole projektowym mogą wymagać bardziej szczegółowej do- kumentacji. • Niech dokumentacja będzie zadaniem równoległym, odzwierciedlającym walkę o zasoby, a nie liniową ścieżką przez cały proces tworzenia oprogramowania. • Staraj się być możliwie pomysłowy w kwe- stii osiągania obu celów, ale unikaj bycia idealnym, bo to kosztuje zbyt wiele. • Szukaj (używam tu nieco przesadzonych przymiotników) najlżejszej i najmniej perfekcyjnej metodologii, która sprosta wyznaczonemu zadaniu. Z drugiej strony zapewnij wystarczająco mocną i rygory- styczną komunikację. ZWINNOŚĆ ZALECENIA DOTYCZĄCE DOKUMENTACJI Oto kilka zaleceń związanych z tworzeniem dokumentacji. • Nie proś o to, by wymagania były dosko- nałe, dokumenty projektowe zawsze aktu- alne i odzwierciedlające stan kodu, a plan projektu 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ępowanie dokumentacji szybszymi środkami komu- Zwinność zakłada efektywność i manewro- wość. Proces zwinny jest zarówno lekki, jak i 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 tej sytuacji pozostać zwinnym?”. Czterdziestoosobowy zespół nie będzie tak samo zwinny jako sześcioosobowy, znajdujący się w jednym pokoju. Każdy zespół może jed- nak starać się zmaksymalizować zastosowanie 244 • Rozdział 5. Zwinność i adaptacja zasad metodologii zwinnej, by być możliwie lekkim i szybkim. Zespół czterdziestoosobowy bę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ęstym wygrywaniu i informacjach zwrotnych. Jeśli zespoły będą uważały, będą okresowo sprawdzały dopasowanie stosowanej meto- dologii do ekosystemu i ewentualnie prze- mieszczenia punktu „ledwo wystarczalny”. PUNKTY KRYTYCZNE Częścią bycia zwinnym jest identyfikacja krytycznych punktów wydajnego tworzenia oprogramowania, a następnie przesuwanie projektu tak blisko tych punktów, jak to możliwe. Zespół, któremu uda się dostosować do jednego z punktów krytycznych, zaczyna korzystać z zalet wydajnego mechanizmu. Jeśli zespołowi nie uda się dostosować do któregoś z punktów krytycznych, musi pogo- dzić się z mniejszą efektywnością. Zespół powinien myśleć kreatywnie, w jaki sposób zbliżać się do punktów krytycznych i jak radzić sobie z sytuacją, gdy punkty te nie są możliwe do spełnienia. Oto pięć punktów krytycznych. Od dwóch do ośmiu osób w jednym pokoju W tym układzie przesył informacji jest naj- szybszy. Ludzie mogą zadawać sobie pytania bez zbytniego podnoszenia głosu. Wiedzą, kiedy inni są gotowi odpowiadać na pytania. Co więcej, przysłuchują się rozmowom innych bez 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 tym samym pokoju. Gdy nie uda nam się osiągnąć tego punktu krytycznego, 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 zastosowali jednak kamery internetowe, by przynajm- niej w części zniwelować konieczność pracy w 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 to uniemożliwiała. Eksperci klienta na miejscu Możliwość stałego korzystania z ekspertów klienta oznacza, że bardzo szybko uzyskuje- my informacje zwrotne na temat wyników pracy. Często są to minuty, rzadziej godziny. Tego rodzaju szybkie informacje zwrotne powodują, że zespół programistyczny lepiej rozumie potrzeby i przyzwyczajenia klienta, więc popełnia mniej błędów przy wprowa- dzaniu nowych pomysłów. Wypróbowuje również więcej pomysłów, co czyni końcowy produkt znacznie lepszym. Przy dobrej współ- pracy, programiści testują pomysły eksper- tów i oferują kontrpropozycje. Pozwala to klientom lepiej zorientować się we własnych żądaniach dotyczących sposobu działania systemu. Koszt związany z niezastosowaniem tego punktu 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 opisano alternatywy — cotygodniowe sesje spraw- dzające z udziałem użytkowników; analizy etnograficzne społeczności użytkowników; ankiety; wykorzystanie zaprzyjaźnionych grup 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 jednak zwiększa koszt uzyskiwania tego rodzaju informacji. Jednomiesięczne przyrosty Nic nie zastąpi szybkich informacji zwrot- nych, zarówno na poziomie produktu, jak i na poziomie procesu programistycznego. Przyrostowe tworzenie oprogramowania pozwala zapewnić dobrą informację zwrotną. Krótkie przyrosty zapewniają, że zarówno wymagania, jak i sam proces są poprawiane bardzo szybko. Pozostaje pytanie: „Jak długie powinny być przerwy między kolejnymi dostarczeniami?”. Prawidłowa odpowiedź bywa różna, ale zespoł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ć swoje wysiłki na maksymalnie trzy miesiące, ale nie dłużej. W przypadku dłuższych okresów wydań wiele osób informuje mnie o zbytnim rozkojarzeniu, utracie intensywności działań i kreatywności. Co bardzo ważne, przyrostowe rozwijanie aplikacji daje zespołowi szansę na naprawienie swojego procesu. Im dłuższy okres między wydaniami, tym dłuższy czas między możliwymi naprawami. Jeśli byłby to jedyny aspekt sprawy, ide- alnym okresem przyrostowym byłby jeden tydzień. Trzeba jednak pamiętać o koszcie wdrożenia produktu na zakończenie każdego okresu. Wydaje mi się, że najlepszym punktem krytycznym w tym przypadku jest jeden miesiąc, ale widziałem również udane pro- jekty wykorzystujące okres o długości dwóch i trzech miesięcy. Jeśli zespół nie może dostarczyć produktu końcowym użytkownikom co kilka miesięcy (niezależnie od powodów), warto mimo to tworzyć system w sposób przyrostowy i przy- gotowywać go do dostarczenia w wyznaczo- nych okresach czasu (udając, że sponsor żąda jego natychmiastowego dostarczenia w obec- nej postaci). Celem takiej pracy jest ćwiczenie każdej części procesu wytwarzania oprogra- mowania i poprawianie wszystkich elemen- tów procesu co kilka miesięcy. W pełni zautomatyzowane testy regresyjne W 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ą bardziej skłonni poprawiać kod innych osób, bo wiedzą, ż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ą automatyczne testy regresyjne. Co poniedziałek urucha- miają testy i sprawdzają, czy ktoś bez ich wiedzy zmodyfikował system. 246 • Rozdział 5. Zwinność i adaptacja Innymi słowy, zautomatyzowane testy po- prawiają zarówno jakość systemu, jak i jakość życia programistów. Istnieją pewne części systemów (a nawet całe systemy), dla których trudno napisać zautomatyzowane testy. Jednym z przykładów mogą być graficzne interfejsy 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 dla opracowywanych przez siebie partii sys- temów. Doświadczeni programiści W idealnej sytuacji — punkcie krytycznym — zespół składa się tylko i wyłącznie z doświad- czonych programistów. Analizowane przeze mnie zespoły, które składały się z doświad- czonych programistów, miały inne i lepsze wyniki w porównaniu z zespołami średnimi i mieszanymi. Ponieważ dobrzy i doświadczeni progra- miści mogą być od dwóch do dziesięciu razy bardziej wydajni od swoich kolegów, można drastycznie zmniejszyć rozmiar zespołu, jeśli składa się tylko i wyłącznie z doświadczonych programistów. Przed wykonywaniem i w trakcie wyko- nywania projektu „Winifred” estymowaliśmy, że projekt do udanej realizacji w wyznaczo- nym przedziale czasu potrzebuje 6 dobrych programistó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świadczonych programistów tworzyło najtrudniejsze części systemu i dużo czasu spędzało na pomocy mniej 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, że czł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 powodowane przez 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 przeniesienia pomysłów. Jeśli z powodu dużej odległości osób zwiększa się koszt przekazania wiedzy, zwiększa się także koszt związany z niezada- niem kluczowych pytań. Dzielenie zespołu to 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 lokalizacjach Programowanie w wielu lokalizacjach ma miejsce, gdy większy zespół pracuje w sto- sunkowo niewielkiej liczbie lokalizacji, a po- szczególne grupy programistyczne tworzące poszczególne podsystemy znajdują się w jed- nej lokalizacji. Dodatkowym warunkiem jest stosunkowo mocna separacja poszczególnych podsystemów. Ten sposób programowania i prowadzenia projektów jest z sukcesami stosowany od dzie- sięcioleci. Kluczem do sukcesu w takim przypadku jest posiadanie pełnego i kompetentnego zespołu w każdej z lokalizacji oraz zapewnie- nie wystarczająco częstych spotkań poszcze- gólnych grup, by mogły się dzielić swoimi doświadczeniami i wizjami. Choć w takim sposobie pracy wiele spraw może pójść nie tak, jest to rozwiązanie spraw- dzone, ze stosunkowo dobrze wypracowanymi regułami pracy (w odróżnieniu od dwóch po- zostałych modeli zespołów wirtualnych). Programowanie zamorskie Ten rodzaj pracy występuje, gdy „projektanci” z jednej lokalizacji wysyłają specyfikacje i testy do „programistów” z innej lokalizacji, najczę- ściej z innego kraju. Ponieważ zamorska lokalizacja nie ma architektó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ływem powietrza. Projektanci w jednej lokalizacji muszą przekazać pomysły przez cienkie kanały komunikacyjne osobom, które stosują inne słownictwo i znajdują się tysiące kilometrów dalej. Programiści potrzebują odpowiedzi na tysiące pytań. Jeśli znajdą błędy w projekcie, muszą wykonać trzy kosztowne zadania: zaczekać na następne spotkanie telefoniczne lub wideo, przekazać swoje obserwacje i prze- konać projektantów o możliwych błędach w projekcie. Koszt w erg-sekundach na mem jest zastraszający, a same opóźnienia ogromne. T E S T O W A N I E P R O G R A M O W A N I A Z A M O R S K I E G O Pewien projektant powiedział mi, że jego zespół musi określać program niemalże na poziomie kodu źródłowego i tworzyć testy, Zwinność • 247 by mieć pewność, że programiści poprawnie zaimplementowali wszystkie wymagania. Projektanci wykonywali całą nieprzyjemną robotę papierkową, ale nie dostawali na- grody w postaci pisania kodu. Ponieważ tworzenie projektu i testów zajmowało ogromną ilość czasu, mogliby równie dobrze sami pisać kod oraz odkry- wać błędy w projekcie i to najczęściej szybciej. Nie udało mi się jeszcze znaleźć projektów prowadzonych w ten sposób, które okaza- łyby się udane metodologicznie. Zawsze nie przechodziły trzeciego testu: przesłuchiwane przeze 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ąc w 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ń szansy na skorzystanie z informacji zwrotnych i szyb- kości komunikacji w projektach prowadzo- nych w wielu lokalizacjach. Programowanie rozproszone Programowanie 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 tylko jedna osoba lub są to dwie osoby) w każdym z miejsc. Programowanie rozproszone staje się coraz bardziej popularne, ale nie znaczy to, że jest efektywne. Koszt przenoszenia pomysłów jest znaczny, 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, 248 • Rozdział 5. Zwinność i adaptacja w którym jedna lub dwie osoby stanowią w miarę niezależny podzespół. W takiej sytu- acji zadania powierzane programiście są jasne i spójne. Niestety, najczęściej mamy do czynienia z sytuacją przedstawioną poniżej. R O Z P R O S Z E N I E K R Z Y Ż O W E Firma tworzyła cztery powiązane produkty w czterech lokalizacjach, a każdy produkt skł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 tym samym miejscu zespołów jednego podsy- stemu dla wszystkich produktów tworzo- nych w firmie. W obu przypadkach ludzie byliby w fizycznej bliskości z innymi oso- bami, z którymi muszą się wymieniać in- formacjami. W praktyce okazało się, że dziesiątki osób zaangażowanych w projekty przy- dzielono w taki sposób, że w tym samym mieście pracowali ludzie przydzieleni do róż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ły się daleko! Od czasu do czasu programiści informują mnie o efektywnym tworzeniu oprogramo- wania z kimś znajdującym się w całkowicie innym miejscu. Oznacza to, że cały czas jest jeszcze coś nowego do odkrycia: co pozwala ludziom tak dobrze komunikować się za pomocą tak słabego kanału komunikacyj- nego? Czy to po prostu szczęśliwe dopaso- wanie osobowości lub stylów myślenia? Czy te dwie osoby wypracowały miniaturowy model odpowiadający programowaniu w kilku loka- lizacjach? Czy korzystają z czegoś, czego więk- szość z nas nie jest w stanie nazwać? U D A N E P R O G R A M O W A N I E R O Z P R O S Z O N E Spędziłem pewien wieczór, rozmawiając z kilkoma osobami, które z sukcesem zaangażowały jako grupę czterech lub pięciu programistów, którzy nigdy się nie spotkali. Powiedziały, że poza bardzo uważnym podzieleniem problemu spędzają dużo czasu przy telefonie, dzwoniąc do siebie kilka razy w ciągu dnia. Poza tą raczej oczywistą taktyką koor- dynatorka zespołu pracowała szczególnie cięż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, że musi znaleźć innego koordynatora prac, podobnego do siebie — kogoś, kto będzie miał 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 oprogramowania Choć tworzenie oprogramowania open source przypomina model rozproszony, różni się od niego 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 projekty open source grają w grę zespołową o nieogra- niczonych zasobach. 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 czasu może pracować nad projektem. W tych grach często słyszymy następujące stwierdzenia: „Ukończ to, zanim zamknie się okno rynkowe!”. „Twoim zadaniem jest równoważenie jakości i czasu wytwarzania!”. „Wdrażaj!”. Z drugiej strony projekt open source działa według zasady, że wystarczy odpowiednio dużo oczu, umysłów, palców i czasu, by powstał dobry model i naprawdę dobrej jakoś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żda z 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, bo bazuje na wewnętrznych potrzebach, a nie zewnętrznych kwestiach finansowych. (Wię- cej informacji na ten temat znajdziesz w roz- dziale 2.). Ludzie tworzą oprogramowanie open source dla przyjemności, jako usługę dla społeczności, o którą dbają, lub w celu bycia rozpoznawanym 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 (cid:180)dral-bazaar/homesteading). Celem typowego programisty w firmie jest stanie się drugim Billem Gatesem. Porówny- Zwinność • 249 walnym celem dla programisty open source byłoby stanie się drugim Linusem Torvaldsem. Warto również pamiętać o innej strukturze zespołó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. Ochroniarz nie musi być najlepszym programistą. Wystar- czy, że jest dobrym programistą z łatwym nawiązywaniem kontaktów i z bardzo dobrym okiem na wykrywanie szczegółów. Po pew- nym czasie kilku najlepszych współtwórców programu zaczyna zajmować centrum, stając się głównymi właścicielami intelektualnymi projektu. 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 komunikacja programistów open source była dostępna dla każdego. Rozważmy to w świetle projektu komercyjnego. 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ę na klasę wyższą i niższą. Jeśli analitycy siedzą po jednej 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 projekcie jest tylko „my”, nie ma rozróżnienia na „my i oni”. W występowaniu lub braku wystę- powania tego podziału kluczową rolę gra sposób wymiany informacji między grupami i pogaduszki. Jeśli istnieją enklawy zbierające specjalistów z jednej dziedziny, pogaduszki niemal 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 250 • Rozdział 5. Zwinność i adaptacja pewną dyskusję, w której nie mogą uczestni- czyć inne osoby. Osoby z rozproszonej grupy mogł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 jest tylko „my”. Chciałbym pewnego dnia zobaczyć i prze- analizować dokładniej ten aspekt projektów open 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 jest inny, a każdy projekt różni się od innych wie- loma szczegółami, podsystemami, podzespo- łami i zakresem czasowym. Każda sytuacja wymaga zastosowania innej metodologii (zbioru konwencji). Sekret polega na sposobie konstrukcji róż- nych metodologii dostosowanych do kon- kretnych sytuacji, ale w taki sposób, by nie zabierało to dużo czasu i nie przeszkadzało w dostarczeniu oprogramowania. Nie chcemy ró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 do ciągle zmieniających się potrzeb wymaga wykonania dwóch rzeczy na poziomie osobi- stym i zespołu. 1. Zastanawiaj się nad tym, co robisz. 2. Niech zespół co drugi tydzień spędza godzinę na analizie własnych nawyków. Jeśli wykonasz te dwa zadania, powstająca metodologia będzie efektywna, zwinna i do- stosowana do konkretnej sytuacji. Jeśli nie możesz tego zrobić… cóż, pozostaniesz tam, gdzie jesteś. Choć tajemniczy składnik jest naprawdę prosty, bardzo trudno wprowadzić go w życie z powodu dziwactw ludzkiej natury. Ludzie najczęściej nie chcą nawet słyszeć o spotkaniu. W niektórych firmach poziom braku zaufania jest 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 uda się powtórzyć. Warto znaleźć w firmie osobę, która ma odpowiednie predyspozycje do organizacji tego 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ń. Teraz Odkryj mocne i słabe strony firmy dzięki krót- kim rozmowom o projekcie. Możesz to zrobić na początku projektu, ale ró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 momencie budować 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ć sobie lepsze pojęcie o sposobie jego działania. Nie- mniej bardziej istotne okazuje się uzyska- nie typowych odpowiedzi dotyczących wielu projektó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ępnym razem. nym razem. 4. Zapytaj, co należałoby powtórzyć następ- 5. Określ priorytety. 6. Znajdź dowolne luki w produkcie pracy lub projekcie. Dostosowywanie się • 251 Krok 1. Zapytaj o podanie jednego przykładu każdego wytworzonego produktu pracy Analizując ten aspekt, łatwo stwierdzić, ile biurokratycznego narzutu występowało w projekcie i jakie szczegółowe pytania o pro- dukty pracy należy zadać w trakcie wywiadu. Szukaj duplikacji pracy oraz miejsc, gdzie trudno było utrzymać aktualność efektów pracy. Zapytaj, czy używano programowania przyrostowego, a jeśli tak, to w jaki sposób aktualizowano dokumenty w kolejnych ite- racjach. Szukaj opisów sposobu, w jaki używano nieformalnej komunikacji, by rozwiązać nie- jasności w dokumentacji. D U P L I K A C J A E F E K T Ó W P R A C Y W jednym z projektów lider zespołu przed- stawił mi 23 produkty pracy. Zauważyłem, że wiele z nich pokrywało się, więc zapytałem, czy te późniejsze były generowane przez narzędzia na podstawie wcześniejszych. Lider odpowiedział, że nie; były od podstaw tworzone przez ludzi. Zadałem więc pytanie, jak pracujące nad tym osoby postrzegały swoją pracę. Powiedział, że jej nienawidziły, ale i tak zmuszał je do jej wykonywania. Po zobaczeniu przykładów efektów pracy przechodzimy do następnego punktu. Krok 2. Poproś o podanie krótkiej historii projektu Zapisz datę rozpoczęcia, ewentualne zmiany wielkości zespołu (powiększenie lub zmniej- szenie), strukturę zespołu, dobre i złe chwile związane z pracą nad projektem. Wykonaj to, by móc oszacować rozmiar i typ projektu, a także by znaleźć interesujące pytania do zadania. 252 • Rozdział 5. Zwinność i adaptacja O D K R Y W A N I E P R O G R A M O W A N I A P R Z Y R O S T O W E G O 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 czasie wskaź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ę, by usłyszeć o tak oczywistej porażce. Niespodzianką okazało się to, co zrobili po pierwszej porażce. Po pierwszej iteracji zmienili w projekcie niemalż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ób to samo). Co najbardziej zaskakujące, nie tylko rozmawiali o tym, co należy zmienić, ale również rzeczywiście zmieniali swój sposób pracy. Lekcja, jaką wyniosłem z tego wywiadu, nie miała nic wspólnego z pośrednimi efektami pracy, 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ści na temat różnych wzlotów i upadków prze- chodzimy do następnej kwestii. Krok 3. Zapytaj, co należałoby zmienić następnym razem Zapytaj: „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ępnego punktu. Krok 4. Zapytaj, co należałoby powtórzyć następnym razem Zapytaj: „Jakie są kluczowe sprawy, które z 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. W S P Ó L N E U P I J A N I E 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, przez wspólne wyjścia na miasto, kanały komuni- kacji, narzędzia programistyczne, architekturę systemów po model dziedzinowy. Zapisuj wszystko, co usłyszysz. Krok 5. Określ priorytety Zapytaj: „Jakie są twoje priorytety z uwzględ- nieniem spraw, które lubiłeś w projekcie? Co jest najważniejsze do utrzymania, a co możesz negocjować?”. Zapisz odpowiedzi. Warto również zadać pytanie: „Co cię naj- bardziej zaskoczyło w projekcie?”. Krok 6. Znajdź dowolne luki w produkcie pracy lub projekcie Zapytaj, czy powinieneś coś jeszcze wie- dzieć na temat projektu, i zobacz, gdzie to doprowadzi. W pewnej firmie wykonaliśmy dwustro- nicowy szablon wywiadu, by zapisywać wyni- ki i łatwo wymieniać się informacjami. Szablon zawierał 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ątek i 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. W Z O R Z E C K O M U N I K A C J I W firmie, w której wykonaliśmy szablon, we wszystkich projektach pojawił się ten sam schemat: „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 dobrych wynikó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ło miejsce następujące zdarzenie. Dostosowywanie się • 253 W Z O R Z E C K O M U N I K A C J I W A K C J I Uczestniczyłem w jednym z trzech prowa- dzonych w tamtym czasie projektów. Każdy z nich dotyczył małych zespołów i ludzi sie- dzących w różnych miastach. Jak zapewne się domyślasz, spędziłem mnóstwo czasu i energii na komunikacji ze sponsorami i programistami. Wszystkie trzy projekty ukończono mniej więcej w tym samym czasie. Dyrektor działu programistycznego zapytał się, co jest powodem różnicy — dlaczego projekt, w którym uczestniczyłem zakończył się sukcesem, a dwa pozostałe prowadzone w 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ędzy programistami i sponsorami lub między poszczególnymi osobami z zespołu. Stwierdził, że to bardzo interesujący pomysł. Zarówno programiści, jak i spon- sorzy z dwóch innych projektów zgłaszali problemy komunikacyjne z liderami pro- jektów. Zarówno programiści, jak i sponso- rzy czuli się odizolowani. Z drugiej strony sponsorzy w moim projekcie byli bardzo zadowoleni z poziomu komunikacji. W innej firmie znalazłem inny wspólny motyw. Oto, co usłyszałem od jednej z prze- słuchiwanych osób. M O T Y W R Ó Ż N I C Y K U L T U R O W E J 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 innego podejścia tamtych osób do pewnych spraw, a także z powodu znacznej odległości od nich. 254 • Rozdział 5. Zwinność i adaptacja Firma potrzebowała wzmocnić mechanizmy komunikacji między dwoma wspomnianymi grupami, a także zastosować dodatkowe oceny efektów pracy. Z przedstawionych historyjek warto za- pamiętać, że to, czego nauczysz się w trakcie wywiadów, może okazać się niezwykle ważne już w następnym projekcie. Zwracaj uwagę na ostrzeżenia pojawiające się w trakcie wywiadów. Na początku projektu Postaraj się w jakiś sposób skrócić standar- dową metodologię firmy. Należy to zrobić nie- zależnie od tego, czy bazową metodologią jest ISO9001, XP, RUP, Crystal lub własne roz- wiązania. Etap 1. Dostosowanie metodologii bazowej Jeśli to możliwe, niech nad propozycją bazo- wej metodologii dla projektu pracują dwie osoby. Praca będzie przebiegać szybciej, osoby te prawdopodobnie odkryją błędy w myśle- niu drugiej strony i pomogą sobie nawzajem w 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 rysunku 4.22). Określić, jakiego poziomu popraw- ności oprogramowania się wymaga i jakie szkody mogą spowodować ewentualne błę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ć, jak rozbudowaną dokumentację należy wyko- nać; wskazać poziom obrzędowości ocen i długość przyrostu lub iteracji (czas wy- magany do dostarczenia działającego kodu rzeczywistym użytkownikom, nawet jeśli są oni tylko testerami). Jeśli okaże się, że czas iteracji jest dłuższy niż cztery miesiące, trzeba znaleźć inny sposób na tworzenie przetestowanej i działającej wersji systemu w mniej niż cztery miesiące, by zasy- mulować rzeczywiste dostarczanie systemu. 3. Wybrać metodologię bazową, która nie jest znacząco różna od sposobu pracy prefe- rowanego przez zespół. Pamiętaj, że łatwiej modyfikować istniejącą metodologię, niż tworzyć własną. Można zacząć 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 podstawowych przepływów — kto przekazuje co i ko- mu — a także wskazać konwencje, na które grupa zapewne się zgodzi. Przedstawione zadania mogą zająć od jed- nego do kilku dni w przypadku projektów mał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 prace zakończyć w ciągu następnych dwóch dni. Krok 2. Metodologia początkowa Zwołaj zebranie zespołu, na którym zostanie omówiona metodologia bazowa i konwen- cje. Zmodyfikuj ją, by stała się metodologią początkową. W większych projektach, gdzie zebranie 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 czym bę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 tylko zalecane? • Jak zostanie rozwiązane raportowanie czasu? • 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 ewentualnych problemów komunikacyjnych i dotyczących morale. 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- • rozwiązania komunikacyjne do przećwi- wadzenia, czenia. Dostosowywanie się • 255 To Twoja metodologia początkowa. Spotkanie powinno zająć połowę dnia, ale nie więcej niż cały dzień. W połowie pierwszej iteracji Niezależnie od tego, czy iteracja ma długość dwóch tygodni, czy trzech miesięcy, prze- prowadzasz krótkie wywiady z członkami zespołu, indywidualnie lub grupowo, w poło- wie iteracji. Poświęć na nie od jednej do trzech godzin. Oto podstawowe pytanie, które należy zadać: 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łkowicie zepsuty. 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 na wprowadzanie zmian tuż po pierwszym uda- nym dostarczeniu systemu. Z tego powodu celem pierwszego wy- wiadu lub spotkania jest wykrycie, czy nie dzieje się coś krytycznego, co mogłoby zagro- zić dostarczeniu pierwszej wersji. Jeśli zauważysz, że aktualny sposób pracy nie 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 do odrzucania metodologii. Wynika to po części z ambicji zarządu układającego nierealistyczne harmonogramy i zbyt optymistycznych pro- gramistów, którzy często zapominają o potrze- bie nauki, spotkań i poprawiania błędów. Ma na to również wpływ szybkość uczenia się 256 • Rozdział 5. Zwinność i adaptacja nowych technologii i kolegów z zespołu. Prze- sadzenie z liczbą rzeczy, którą można dostar- czyć w pierwszym wydaniu, naprawdę jest całkowicie normalne. Pierwszym krokiem powinna być redukcja zasięgu. Może się okazać, że zmniejszenie zasięgu nie 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ć specyfikacji architektury. 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 lepszym stopniu wykorzystać nieformalne kanały ko- munikacji. Konieczne mogą okazać się awa- ryjne zmiany zespołu, awaryjne szkolenia, konsultacje i zatrudnienie doświadczonych programistów z zewnątrz. Głównym celem jest dostarczenie czegoś — pewnego niewielkiego, działającego i prze- testowanego kodu w pierwszej iteracji. To bardzo istotny czynnik sukcesu projektu (Cockburn 1998). Po wydaniu pierwszej wer- sji będzie można chwilę odsapnąć i dokładnie zastanowić się nad powodem problemów. Po każdej iteracji Po każdej iteracji zwołaj zebranie na temat wniosków dotyczących sposobu pracy. Analiza wniosków to bardzo istotny czyn- nik sukcesu w ewolucji metodologii, podobnie jak programowanie przyrostowe stanowi je- den z czynników sukcesu wytwarzania opro- gramowania. Długość i intensywność analizy zależy od firmy i kraju. Amerykanie są zawsze zajęci, mają mało pieniędzy i ciągle biegną. Nie dziwi wię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
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Agile Software Development. Gra zespołowa. Wydanie II
Autor:

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: