Autorstwo: Mariusz Chrapko (rozdziały 1 12), Mike Cohn (Wprowadzenie)

Transkrypt

1

2 Autorstwo: Mariusz Chrapko (rozdziały 1 12), Mike Cohn (Wprowadzenie) Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji. Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli. Autor oraz Wydawnictwo HELION dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor oraz Wydawnictwo HELION nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce. Redaktor prowadzący: Ewelina Burska Ilustracje: Aleksandra Bułhak Projekt okładki: Magdalena Stasik Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock. Wydawnictwo HELION ul. Kościuszki 1c, GLIWICE tel , helion@helion.pl WWW: (księgarnia internetowa, katalog książek) Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję. ISBN: Copyright Helion 2013 Printed in Poland. Kup książkę Poleć książkę Oceń książkę Księgarnia internetowa Lubię to!» Nasza społeczność

3 SPIS TREŚCI O AUTORZE 7 PODZIĘKOWANIA 9 WPROWADZENIE 13 ZAMIAST WSTĘPU MYŚLENIE ODWROTNE. Czym jest agile? 17 Szko a przetrwania 17 Wodospad 18 Pan Samochodzik i tworzenie oprogramowania 23 Ludzie z kryjówek 24 Wychodzenie z kryjówki 26 My lenie odwrotne 27 Zdrowie szale ców 28 Manifest agile LEKCJE PŁYWANIA. O zwinnym zarządzaniu projektami 33 Klasyka i jazz 33 Piankowe wyzwanie 40 Dama z asiczk 42 Agile i pornografia 44 Scrum 48 Lekcje p ywania 50 3

4 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI 3. KONTRABASISTA. Nowe role i obowiązki 53 Lekcja z Kontrabasisty 53 ScrumMaster 54 Cechy dobrego ScrumMastera 58 Wybór ScrumMastera 66 W du ej organizacji 68 W a ciciel Produktu 69 Czy kierownik projektu jest potrzebny w Scrumie? ŁAWA PRZYSIĘGŁYCH. O hodowaniu zwinnych zespołów projektowych 97 Ugotowani 97 Zespó = nirwana projektu 99 Szlachetny cel 103 Uprawa zwinnych zespo ów 105 Wielofunkcyjne zespo y 120 Zespo y komponentowe 121 awa przysi g ych PLATON, IDEE I RYBY. Jak zwinnie zarządzać wymaganiami? 131 Jaszczurka czy dinozaur? 131 Diabe tkwi w... komunikacji 133 Historyjki u ytkownika 140 ZaINWESTuj w dobre historyjki 147 Rejestr produktu i ocean plazmy 158 Historyjki, epiki, tematy... thriller 160 Wymagania jak góra lodowa 161 Piel gnacja 162 Praca z du ym rejestrem 163 Tylko 150, reszta nie ma znaczenia LIZANIE ZNACZKÓW I CHIRURGIA MÓZGU. Szacowanie projektów w Scrumie 167 Kadzid owy dym, ekstatyczny trans 167 O istocie szacowania 168 W punktach czy w osobodniach? 190 Troch techniki i cz owiek si nie gubi O ŻEGLOWANIU I OBIERANIU CEBULI. Planowanie projektów w Scrumie 203 Obsesja planowania 203 Zwinne planowanie 204 eglowanie i obieranie cebuli 206 Jak si do tego zabra? 208 4

5 SPIS TREŚCI Plan wydania 227 Planowanie na du skal 229 Jak ledzi post p prac? BIEGNIJ, FORREST, BIEGNIJ. Sprint 239 Jak na nartach po Barcelonie 239 Planowanie sprintu 240 Plan sprintu 253 Gotowi! Do startu! Gotowi?! 254 W du ych projektach 256 Zrobione czy niezrobione? 260 Puste taczki 262 Komunikacja 265 ledzenie post pu prac W POKOJU SZTABOWYM. Codzienne scrumy 273 Wniosek o zako czenie wojny 273 Codzienny scrum 278 Jak si komunikowa? 290 Zespo y rozproszone 293 Scrum of Scrums FURTKA DO OGRODU. O tym, jak zorganizować przegląd sprintu 301 W sklepie z zabawkami 301 Przegl d sprintu 302 Metoda Kawasakiego 304 Zara a dobr energi 305 Furtka do ogrodu 306 Atak na Ziemian MYŚLODSIEWNIA. Retrospektywa na koniec sprintu 309 My lodsiewnia 309 Oczyszczenie 310 Najcz ciej pomijana praktyka 311 Lekcja anatomii 312 Próba ogarni cia kuwety WSPÓLNY REJS. Historia z morza wzięta 331 SKOROWIDZ 335 5

6 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI 6

7 1 MYŚLENIE ODWROTNE Czym jest agile? Większość naszych wielkich wynalazków i genialnych osiągnięć zawdzięczamy lenistwu, czy to narzuconemu, czy dobrowolnemu. Umysł nasz lubi być karmiony, jak łyżeczką, pomysłami innych ludzi, jeśli się go jednak pozbawi tej pożywki, zaczyna, zrazu niechętnie, myśleć samodzielnie, a tego rodzaju myślenie, proszę pamiętać, jest myśleniem oryginalnym i może przynieść bardzo cenne rezultaty. Agatha Christie, Zatrute pióro Szkoła przetrwania Jestem wielkim fanem Beara Gryllsa, bohatera programu telewizyjnego emitowanego przez Discovery Channel Ultimate Survival (polski tytu : Szko a przetrwania). Dzielny Bear, podró nik i by y o nierz s u b specjalnych SAS 21 (Special Air Service), uzbrojony jedynie w nó, manierk, krzesiwo i ubranie, pokazuje, jak przetrwa w absolutnie ekstremalnych warunkach. Pami tam jeden z odcinków (w a ciwie chyba by to pilot 1. sezonu), który by kr cony w Górach Skalistych, w USA. Du e wra enie zrobi a na mnie scena, w której Bear schodzi w dó rzeki (by o mo e z 9 metrów) samym rodkiem wodospadu. Je li kto z Was widzia ten odcinek, to wie, e Bear pokonywa go troch na raty. Najpierw pierwszy etap doj cie do wodospadu. Potem drugi zdobycie ma ej pó ki skalnej, oczywi cie niewidocznej ze wzgl du na ogromn mas lodowatej wody, wpadaj cej wprost na Beara. Kolejny moment to zej cie na pó k skaln, ale jak? za pomoc drabinki zrobionej z linek paralotni, na której nasz bohater wyl dowa na pocz tku programu. I wreszcie ostatni etap skok z kilku metrów do uj cia rzeki. My l, e opisana scena pokonywania wodospadu bardzo dobrze pokazuje pu apk, w jak wpada wi kszo z nas, stosuj c dobrze znany wszystkim tzw. waterfall model (z ang. metodyka kaskadowa). Na pierwszy rzut oka wydaje nam si, e nie ma innej drogi. Kiedy si pokonuje wodospad, mo na sobie przecie znacznie 17

8 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI skróci drog, tym samym szybciej dotrze do zamierzonego celu. Do kogo, kto nie ma du ego do wiadczenia w rozwijaniu oprogramowania, taki argument mo e faktycznie trafia. Opiera si przecie na bardzo logicznych przes ankach najpierw musimy wiedzie, czego chce od nas klient (wymagania biznesowe), eby my mogli my le o specyfikacji technicznej. Dopiero kiedy ju mamy te dwa etapy za sob, mo emy rozpocz prace architektoniczne i zaj si dokumentacj wybranych rozwi za. Gdy ju nam si to uda, wreszcie mekka! upragnione pisanie kodu. Potem ju tylko testy, retesty i uwaga! Wielki Fina, czyli demonstracja efektów naszej pracy klientowi, który dostaje opon zawieszon na linie zamiast wymarzonej hu tawki 1. Tak sobie my l, e gdybym ja, podobnie jak Bear Grylls, zosta rzucony na pastw losu i musia przetrwa w najdzikszych miejscach na wiecie, na pewno nie schodzi bym w dó wodospadem. Znaj c moje fizyczne mo liwo- ci, dodatkowo bior c pod uwag fakt, e nie s u y em w SAS 21, z pewno- ci poszuka bym jakiej innej drogi w dó niekoniecznie takiej, która skaza aby mnie na po amanie sobie r k i nóg na liskich kamieniach lub na nabawienie si hipotermii od lodowatej wody. Metody agile (z ang. zwinny) to szybka droga do celu, która omija wodospad, bystrza i wszystko, co mo e si zdarzy po drodze. Wodospad Z powstaniem zwinnych metod tworzenia oprogramowania by o troch tak, jak z powstaniem ycia na Ziemi. Ich podstawowe idee, wyznawane warto ci i zasady ewoluowa y wraz z dyscyplin in ynierii oprogramowania, a wi c od pocz tku jej istnienia (prze om lat 50. i 60. XX w.). Niew tpliwym katalizatorem, który przyczyni si do ich rozwoju, by wiat tradycyjnych metod wytwórczych, które najpe niej definiuje podej cie zwane kaskadowym (od ang. waterfall). Polega na tym, e aktywno ci projektowe realizowane s liniowo (sekwencyjnie) p yn niczym Nil, tworz c imponuj ce kaskady wodne (dwie z nich maj posta pot nych wodospadów nazywanych Ripon i Owena). Cykl ycia projektu dzielony jest na okre lone fazy, które wzajemnie od siebie zale. Najpierw ustalane s potrzeby klienta (wymagania biznesowe), potem t umaczy si je na j zyk zrozumia y dla programistów (wymagania funkcjonalne), eby z kolei, na ich podstawie, mo na 1 Zob. (dost p: 3 maja 2012). 18

9 MYŚLENIE ODWROTNE by o zaprojektowa okre lone rozwi zania techniczne (projekt systemu). Kolejna faza to implementacja wybranych rozwi za, które s : integrowane, testowane i utrzymywane (ang. maintenance) w wyniku wdro enia. Zwró cie uwag na to, e ka da faza w tym podej ciu stanowi domkni t ca o. Jej produkty wyj ciowe (outputs) stanowi wej cia (inputs) do fazy nast pnej, co pokazuje rysunek 1.1. Rysunek 1.1. Cykl kaskadowy projektu Bardzo dobrze pami tam problemy wynikaj ce ze stosowania metody kaskadowej, z którymi sam, jako pocz tkuj cy kierownik projektów, musia em si kiedy zmierzy. Przede wszystkim do szybko doszed em do wniosku, e sta e wymagania w projekcie s tak rzadkie jak oscarowe role u Arnolda Schwarzeneggera. Wyobra cie sobie sytuacj, e sko czyli cie prace zwi zane z przygotowaniem niskopoziomowego projektu systemu (ang. Low Level Design). Nagle dzwoni klient i mówi, e chcia by troch rozbudowa dwie ostatnie funkcjonalno ci, o których rozmawiali cie pi dni temu, i dodatkowo dorzuci jedn now. Do dzisiaj my leli cie, e wszystko jest pod kontrol. Nagle ca y wiat wywraca si do góry nogami, grawitacja nie dzia a zgodnie z powszechnym prawem ci enia, a czasoprzestrze zakrzywia si w nieprawdopodobny wr cz sposób. Scena ywcem wyj ta z Incepcji Christophera Nolana 2. Chcia oby si w ama przez sen do wiadomo ci klienta i zaszczepi mu ide cierpliwego czekania i niewrzucania nam dodatkowej roboty. Ale nie ma sprawiedliwo ci na tym wiecie. Musimy kilka rzeczy przeprojektowa, 2 (dost p: 3 maja 2012). 19

10 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI przeplanowa i stara si jako podnie morale sfrustrowanego zespo u. Nie trzeba ju chyba dodawa, jak bardzo takie wrzutki zwi kszaj koszty prowadzonego projektu. Kolejnym problemem, który napotka em przy okazji stosowania modelu kaskadowego, jest formalne pozbawienie prawa g osu naszego klienta w trakcie prowadzenia prac rozwojowych. Celowo napisa em formalne, gdy klient i tak kontaktowa si z nami na wiele ró nych sposobów i demonstrowa swoje widzimisi. I nic nie mogli my zrobi. Nie pomaga o alarmowanie o tym problemie wy szego kierownictwa, które, jak jedna z pluszowych zabawek stoj cych przy wej ciu do Smyka, natr tnie powtarza o: Takie jest ycie! Dobrze wiesz, e jest to nasz strategiczny partner (czyt. dojna krowa) i musimy to jako znie. G owa do góry! Nast pnym razem b dzie lepiej. Nie by o. Model kaskadowy umo liwia ró nego rodzaju ucieczki b dów z jednej fazy do drugiej. Wyobra cie sobie np., e na etapie testów systemowych nagle dowiadujecie si, e okre lone rozwi zanie zosta o le zaprojektowane i musicie wróci do wcze niejszej fazy, rozgrzeba architektur systemu, zaimplementowa odpowiednie poprawki, zrobi testy i wdro y zmiany na rodowisko produkcyjne klienta. W tym momencie Wasze plany bior w eb. To jest troch tak, jak z wyjazdem na weekendowy biwak, na Mazury. Pakujemy si : piwór, karimata, ubrania, r czniki (oczywi cie wszystko razy kilka, chyba e nie bierzemy ony i dzieci), buty, kosmetyczka, latarka, zapa ki, saperka, adowarka do telefonu, konserwy Wreszcie wyje d amy z Krakowa. Nawet nam sprawnie posz o, mimo e jest pi tek i Jedziemy ju oko o dwie godziny, nagle ona, patrz c b dnym wzrokiem na przeje d aj ce s siednim pasem auta, pyta: Krzysiek, a namiot?. Mo ecie sobie wyobrazi, jaki jest dalszy ci g tej historii. Z modelem kaskadowym jest podobnie. Im pó niej si zorientujemy, e nie mamy namiotu, tym wi cej nas kosztuje powrót po niego. W modelu kaskadowym nad sukcesem ka dej fazy czuwa inny zespó, który skupia ludzi o bardzo zbli onych kompetencjach. Na przyk ad za faz wymaga odpowiadaj analitycy biznesowi, analitycy systemowi oraz in ynierowie wymaga. Na etapie projektowania pierwsze skrzypce graj projektanci i architekci. Pó niej do gry wchodz programi ci, którzy implementuj przyj te wcze niej rozwi zania, a wyniki swoich prac przekazuj dalej testerom, którzy z kolei sprawdzaj, czy wszystko dzia a zgodnie z wymaganiami, a wi c z tym, czym zajmowa si pierwszy zespó. Je eli wszystko jest przetestowane, a znalezione b dy poprawione, produkt trafia w r ce wdro eniowców, a w nast pnej kolejno ci zespo u zajmuj cego si 20

11 MYŚLENIE ODWROTNE pracami utrzymaniowymi. Proces ten przypomina troch a cuch pokarmowy, w którym mamy do czynienia z szeregiem ró nych organizmów ustawionych w takiej kolejno ci, e ka dy z nich jest ród em po ywienia dla kolejnego. Na rysunku 1.2 bli ej niezidentyfikowana ro lina jest pokarmem dla d d ownicy, któr zjada ze smakiem na niadanie ma y ó wik, b d cy niez ym obiadowym k skiem dla zm czonego lataniem or a, wprost uwielbiaj cego te opancerzone stwory. Mamy tu wi c i zjadaj cych, i zjadanych. Rysunek 1.2. Łańcuch pokarmowy W modelu kaskadowym zespó, który zbiera i analizuje wymagania, jest pierwszym ogniwem a cucha projektowego. Wytwory jego prac (lista wymaga klienta) s zjadane przez zespó projektantów ( zjadaj cych ), które z kolei dostarczaj cennego po ywienia (projekt systemu) zespo om programistów. a cuszek ten zamyka si na etapie, kiedy klient konsumuje gotowy produkt. W przyrodzie a cuchy pokarmowe s d ugie i wzajemnie poprzeplatane tworz sieci ró nego rodzaju zale no ci pokarmowych. I to jest co, co nie jest brane pod uwag w podej ciu kaskadowym. Tam bowiem zak ada si p ynne przej cie pomi dzy jedn faz a drug. Model kaskadowy, przez surowe rozgraniczenie prac wykonywanych przez ró ne zespo y, powoduje rozmycie odpowiedzialno ci za rozwój produktu. Ka dy zespó skupia si tylko na swojej dzia ce i w aden sposób nie czuje si odpowiedzialny za to, co robi zespó kolejny. Ka dy zamyka si w swoim silosie. Przypomina mi to pewn histori. Kilka lat temu by em na 21

12 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI weselu u mojego znajomego. Nie wiem jak Wy, ale ja, delikatnie mówi c, nie najlepiej znosz wszelkiej ma ci zabawy weselne, które si przy tej okazji odbywaj. No ale przecie nie wypada o odmówi. Gra by a bardzo prosta. Polega a na tym, e go cie weselni zarówno ci, którzy zg osili si dobrowolnie, jak i ci, tacy jak ja, dostali si do zabawy z apanki mieli utworzy ko o i kolejno podawa sobie ma y eczk do herbaty. W tym czasie zespó pastwi si nad weso ymi weselnikami, graj c skoczne umpa... umpa..., od czasu do czasu robi c niespodziewane przerwy. I w a nie te przerwy, ni z gruchy ni z pietruchy, powodowa y, e cz owiek chcia jak najszybciej pozby si tej okropnej y eczki. I czym pr dzej wcisn j w r ce s siada. Jest to postawa, któr wyzwala a zasada tej zabawy, e gdy tylko muzyka przestaje gra, a kto zostanie z problemem w r ku, wypada z gry. Projekty w modelu kaskadowym przypominaj bardzo zabaw z y eczk. Ka dy zespó chce jak najszybciej wypchn to, co zrobi, do s siedniego zespo u Niech oni si tym martwi. To nie jest ju nasz problem. Ile razy s yszeli my takie has a w swoim projekcie? Pami tacie, jak nieraz dany problem (b d, poprawka) by przerzucany mi dzy programistami, testerami, utrzymaniowcami lub osobami z obs ugi klienta? Przecie my zrobili my to tak, jak by o w wymaganiach, to ONI zawalili, nie MY!. Albo: MY tego nie b dziemy naprawia, bo my my tego nie robili, to ich robota. W modelu kaskadowym poszczególne zespo y przypominaj troch monady, o których mówi Leibniz. Monady nie maj drzwi ani okien. S wiatem samym w sobie. yj w radykalnej separacji. Nie komunikuj si, bo, u ywaj c metafory, któr pos u y si niemiecki filozof do tego potrzebne s drzwi i okna 3. Winston Royce, który jako pierwszy w artykule Managing the Development of Large Software System (1970) opisa model kaskadowy, powiedzia bardzo ciekaw rzecz: Podoba mi si ten pomys, ale jego implementacja jest ryzykowna i ma tendencj do b dów 4. Jest swoistym paradoksem, e wiele osób uwa a tego cz owieka za twórc metodyki kaskadowej cz owieka, który widzia w niej du e zagro enie. 3 Zob. F. Copleston, Historia filozofii, t um. J. Marz cki, t. IV, Instytut Wydawniczy PAX, Warszawa 1995, s W. Royce, Managing the Development of Large Software System, Proceedings of IEEE WESCON 26 (August): 1 9, Process/waterfall.pdf (dost p: 3 maja 2012). 22

13 MYŚLENIE ODWROTNE Pan Samochodzik i tworzenie oprogramowania Metody agile powsta y jako reakcja na za o enie, które od samego pocz tku by o g boko zakorzenione w in ynierii oprogramowania: proces tworzenia oprogramowania jest procesem, który niczym nie ró ni si od procesu produkcyjnego. Jest linia produkcyjna, s stanowiska robocze (maszynowe, r czne lub mieszane), pogrupowane wed ug kolejnych operacji procesu technicznego. Idea linii produkcyjnej, w momencie powstania, by a alternatywnym rozwi zaniem wobec dotychczasowej produkcji rzemie lniczej i jej utworzenie stanowi o niekwestionowan zas ug ameryka skiego koncernu Ford. In ynierowie oprogramowania pope nili jednak zasadniczy b d, próbuj c przenie ten pomys na grunt projektów software owych. Co gorsza, na tym za o eniu osadzona zosta a ca a dotychczasowa filozofia zarz dzania lud mi. Na czym ten b d polega? Wyobra sobie, Drogi Czytelniku, e awansowa e i zosta e kierownikiem projektu w zak adzie Tomasza N. N. (tytu owy bohater ksi ki Pan Samochodzik), któremu znudzi a si ju praca historyka sztuki, postanowi zacz masow produkcj pokracznego wehiku u, zbudowanego na bazie rozbitego Ferrari 410 Superamerica. Jako mened er odpowiadasz za lini produkcyjn. Natychmiast eliminujesz wszystkie pojawiaj ce si defekty; jeste w ciek y i nie tolerujesz b dów pope nianych przez pracowników, którzy obs uguj lini ; traktujesz ich jak kolejny trybik maszyny, który w razie potrzeby zawsze mo na wymieni na inny; no i jeste mistrzem wszelkich instrukcji wszystko musi tyka jak w szwajcarskim zegarku i na wszystko jest standardowa procedura. Aha, jeszcze jedno: nie znosisz eksperymentów nie ma czasu sprawdza, czy co si da wykonywa lepiej, czy nie, to nie jest przecie Twoja rola. 23

14 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI Takie podej cie faktycznie ma sens i sprawdza si podczas pracy przy linii produkcyjnej, np. samochodów. Ogromnym b dem jest jednak próba zaaplikowania tego modelu do projektów software owych, w których kluczow rol odgrywa tzw. czynnik ludzki. To od stopnia zaanga owania ludzi, ich kreatywno ci, umiej tno ci akceptowania problemów, radzenia sobie z konfliktami, zdolno ci komunikacji, pracy w grupie zale y sukces danego projektu. Stosowanie mechanizmów zaczerpni tych ze wiata produkcji mo e prowadzi do postaw zupe nie odwrotnych st umienia inicjatywy, braku odwagi w wyra aniu swoich opinii i pomys ów, chowania si do kryjówek, z których nie trzeba si zbytnio wychyla, eby prze y kolejny dzie w pracy. Ludzie z kryjówek Poniewa prywatnie zawsze by em i dalej jestem fanatykiem filozofii w ka dym wydaniu, przytocz krótki fragment My lenia wed ug warto ci ks. Józefa Tischnera (na pewno kojarzycie jego kultow ju dzisiaj Filozofi po góralsku 5, je li nie polecam!): Cz owiek w kryjówce chroni si przed wiatem i przed innymi. Przysz o nie obiecuje cz owiekowi nic wielkiego, pami przesz o ci podsuwa mu przed oczy same doznane pora ki, przestrze nie zaprasza do adnego ruchu. Wprawdzie w kryjówce nadzieja nie znika bez reszty, tylko maleje, ale maleje do tego stopnia, e staje si jedynie nadziej przetrwania 6. Styl zarz dzania, który próbuje odzwierciedla wiat produkcji, spycha cz onków zespo ów projektowych w a nie do kryjówek. Zauwa cie, w ilu projektach, w których sami uczestniczyli cie, mieli cie do czynienia z sytuacj, gdy kierownik zawsze bra sprawy w swoje r ce w obawie o Wasze kompetencje. Wspó pracowa em kiedy z firm, w której spotka em si z do komiczn sytuacj, a przypomina a mi ona dawne dzia ania G ównego Urz du Kontroli Prasy, Publikacji i Widowisk cenzuruj cego publikacje prasowe, radiowe i telewizyjne w PRL-u. Ka dy , który ScrumMaster lub lider techniczny wysy a do klienta, musia by wcze niej wnikliwie przeanalizowany i autoryzowany przez kierownika projektu. Z aptekarsk wr cz precyzj 5 J. Tischner, Historia filozofii po góralsku, Znak, Kraków J. Tischner, My lenie wed ug warto ci, Znak, Kraków 2000, s

15 MYŚLENIE ODWROTNE kierownik studiowa ka d wiadomo, która wychodzi a poza firm, nanosi kluczowe jak twierdzi poprawki. Kiedy zapyta em go, dlaczego to robi. Szybko dosta em odpowied, e jego ludzie nie maj wyczucia tzw. kwestii politycznych, wi c nie b dzie z tego wzgl du ryzykowa kontraktu z klientem, który jest jego jedyn dojn krow. Niestety nie by em w stanie go przekona, e w ten sposób zabija inicjatyw w zespole i w efekcie kszta tuje mentalno ludzi z kryjówek, którzy wcze niej czy pó niej przejd do defensywy i przestan wykazywa jak kolwiek wol twórczego dzia ania. Bo, koniec ko ców, po co podejmowa takie dzia anie, skoro zawsze istnieje ryzyko, e mo e si to le sko czy dla projektu? Innym powa nym b dem mened erów wychowanych w wiecie produkcji jest zabijanie indywidualno ci. Przez indywidualist rozumiem osob maj c swoje zdanie, kreatywn, patrz c na problemy, które wcze- niej czy pó niej pojawi si w projekcie, zawsze w sposób nowatorski i inny od wszystkich proponowanych. Nie chodzi mi jednak o artyst, który pojawia si w pracy, kiedy chce, a kiedy ju przyjdzie, to wszystko, co robi, traktuje jako rodek do samopodniety. Obecno takich ludzi w zespole projektowym jest bardzo destruktywna i trzeba dobrze si zastanowi, zanim zatrudnimy takich gagatków do pracy w naszej firmie. Dla kierownika, który swoj inspiracj czerpie z linii produkcyjnej, programista-indywidualista jest tylko ród em problemów. Tymczasem to cz sto wyj tkowo decyduje o sukcesie danego przedsi wzi cia. Ten, kto ogl da film L nienie Stanleya Kubricka, z rewelacyjn rol Jacka Nicholsona, z pewno ci wie, o czym mówi 7. Ostatni rzecz, o której chcia bym wspomnie w kontek cie tradycyjnego stylu zarz dzania, jest koncentracja na realizacji zada. W zarz dzaniu wzoruj cym si na produkcji samochodów nie ma czasu na my lenie o tym, jak co zrobi. Zadania musz by wykonywane mechanicznie, eby ze wszystkim zd y na czas. Tymczasem w projektach software owych tak si nie da. Oczywi cie wszyscy o tym wiemy, niemniej cz sto jest tak, e kiedy ju dostaniemy projekt do r ki, rzucamy si w wir pracy, najcz ciej nie maj c odpowiedniej ilo ci czasu na planowanie, analiz nowych metod i technologii, na szkolenia, czytanie fachowych ksi ek, na wspólne dyskusje o problemach. W ubieg ym roku mia em przyjemno wspó pracowa z firm, która programowa a na odleg o dla niemieckiego zleceniodawcy du ej korporacji z, wydawa oby si, uporz dkowan struktur i tzw. dojrza ym adem organizacyjnym. Jednym z zada, do których zosta em zatrudniony, 7 (dost p: 3 maja 2012). 25

16 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI by o usprawnienie procesów szacowania parametrów projektu. Chodzi o o to, eby nauczy ludzi przygotowywa WBS-a (ang. Work Breakdown Structure), odpowiednio definiowa zadania projektowe, a tak e wdro y jedn z technik estymacyjnych. Pocz tkowo wszystko sz o jak po ma le. Zespó z Polski bardzo szybko si wdro y. Wspólnie przygotowali my kilka arkuszy estymacyjnych do wcze niej z o onych zamówie. I tu zacz y si schody. Nasi niemieccy koledzy nie mogli zrozumie, dlaczego w wycenie uwzgl dnili my analiz rozwi za architektonicznych, czas sp dzony na telekonferencjach, a tak e zrobienie prototypu sprawdzaj cego jedno z mo liwych rozwi za. Ta firma w ogóle nie bra a pod uwag, e zanim co zrobimy, musimy najpierw si zastanowi, jak to zrobi. Spotka si, pogada, pomy le nad rozwi zaniem. Nie da si ludzi podpi do klawiatury i kaza im pisa kod. Wychodzenie z kryjówki Agile to rodzina metod, które pomagaj ludziom zarz dzanym wed ug regu linii produkcyjnej wyj z kryjówek. Kryjówka ma jaki próg, który trzeba przekroczy. Próg znaczy koniec kryjówki i pocz tek nowej przestrzeni. Je li si widzi koniec, a nie widzi si pocz tku, b dzie si mimo wszystko wi cej kocha z udzenie ni prawd 8. Jaki pocz tek proponuj metody agile? Przede wszystkim dzi ki iteracyjnej metodzie pracy, w której projekt podzielony jest na kilka mniejszych kawa ków (iteracji), akceptuj prawo cz onków zespo ów do robienia b dów. Zastanówcie si przez chwil, na ile lepych zau ków w trakcie realizacji Waszych projektów natrafili cie (bez wzgl du na ich rozmiar i z o ono ). Ile by o meandrów? Ile razy walili cie g ow w mur, nie wiedz c, co robi dalej w któr stron i? Agile zak ada, e projekty s podatne na b dy. Jest rzecz zupe nie normaln, e cz sto zmienia si kierunek prac rozwojowych. Klient co kilka tygodni dostaje fragmenty dzia aj cego produktu, mo e go sobie ogl dn, nacieszy si nim zg osi swoje zastrze enia oraz zaproponowa nowe pomys y. To jest du a si a tego podej cia. Pami tam, e jako pocz tkuj cy kierownik projektu, przygotowuj c harmonogram prac w oparciu o metodyk kaskadow, zawsze mia em problem ze zmienno ci wymaga. Zbiera em nawet metryk ledz c ich fluktuacj (ile pojawi o si nowych? 8 J. Tischner, My lenie wed ug warto ci, op. cit., s

17 MYŚLENIE ODWROTNE ile zmieniono starych? ile te zmiany nas kosztowa y?), a wszystko po to, eby mie haka na klienta na wypadek, gdyby przysz o mu do g owy czepia si nas, bo po raz kolejny nie zd yli my z osi gni ciem zaplanowanego kamienia milowego, bo w trakcie implementacji kilka razy zmieni y si wymagania i pierwotny zakres prac poszerzy si o trzy nowe funkcjonalno ci. Musz przyzna, e zawsze by em bezsilny. Kiedy jednak zacz em stosowa zwinne praktyki projektowe, wszystko si zmieni o. Agile oswoi zmian. Pokaza, e nie taki diabe straszny.... Metody zwinne promuj opisany wcze niej indywidualizm. W tym sensie s drog pod pr d tradycyjnego stylu zarz dzania. Dzi ki stosowanym metodom i narz dziom tworz co, co mogliby my nazwa demokratycznym stylem zarz dzania. Kierownik projektu nie jest ju królem, który panuje nad ludem, niezale nie od uk adów politycznych i systemów. Jest bardziej s ug i mentorem osób, które anga uj si w projekt. Jego rola musi wi c zosta odpowiednio przedefiniowana. Dodatkowo o demokracji wiadczy fakt, e w adza zosta a oddana w r ce ludu. Odt d to zespó, a nie kierownik projektu, decyduje o tym, jak zdefiniowa poszczególne zadania projektowe oraz kto si nimi zajmie. Rola kierownika musi wi c zosta zdefiniowana na nowo, w kontek cie warto ci i zasad, które przynosi ze sob idea zwinno ci. B dzie o tym wi cej w rozdziale 3., po wi conym rolom w Scrumie. Myślenie odwrotne Metody agile powsta y w wyniku próby spojrzenia na proces tworzenia oprogramowania w nieco inny odwrotny sposób. Na my l przychodzi mi tutaj historia, któr przeczyta em w ksi ce Paula Ardena Cokolwiek my lisz, pomy l odwrotnie 9. Rzecz zdarzy a si przed olimpiad w Meksyku, która odby a si w 1986 r. By to czas, kiedy technika skoków wzwy polega a na tym, e sportowcy w trakcie skoku przerzucali swoje cia o równolegle do poprzeczki. Na wspomnianej olimpiadzie pojawi si, wtedy jeszcze ma o znany zawodnik, Dick Fosbury, który podbieg do poprzeczki, ustawionej na rekordowej wysoko ci 2 m 24 cm. Wybi si i zamiast skoczy jak wszyscy, ustawi swoje cia o w kierunku poprzeczki, obracaj c si do niej plecami. Unosz c nogi, pokona j ty em. Jego styl skakania obowi zuje do dzisiaj 9 P. Arden, Cokolwiek my lisz, pomy l odwrotnie, t um. O. Siara, Insignis, Kraków 2008, s

18 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI i zas yn jako flop Fosbury ego. Dick skoczy wy ej ni ktokolwiek przedtem, bo odwa y si my le inaczej. Metody agile to w a nie przyk ad my lenia odwrotnego wzgl dem pokonywania poprzeczki w tradycyjny sposób, czyli w naszym przypadku stosowania podej cia kaskadowego. Kiedy po raz pierwszy ogl da em w internecie zdj cia skoczków, którzy oddawali swoje skoki przed 1986 r., pomy la em: Jak oni mogli tak nienaturalnie skaka? Przecie to zupe nie cudaczne. A wierzy si nie chce, e ludzie nie skr cali sobie karków przy l dowaniu. A jednak. Zdrowie szaleńców Ludziom, którzy my leli odwrotnie, by a w ca o ci po wi cona jedna z najbardziej innowacyjnych kampanii reklamowych wszechczasów Think Different firmy Apple. Steve Jobs w jednym z wywiadów opowiada, jak dosz o do jej powstania: Kampania Think Different wynika a st d, e ludzie, w tym nasi pracownicy, zapomnieli, do jakich warto ci odwo uje si Apple. D ugo zastanawiali my si, jak powiedzie komu, za czym si opowiadamy, jakie warto ci wyznajemy, a u wiadomili my sobie, e kiedy nie znasz kogo dobrze, mo esz go zapyta : Kim s twoi bohaterowie?. Mo na si wiele dowiedzie o ludziach na tej podstawie. Stwierdzili my wi c: Dobra, powiemy im, kim s nasi bohaterowie 10. O kampanii Think Different mówi si cz sto, e przyczyni a si do odbudowania wizerunku firmy Apple po fiasku sprzed poprzednich lat. Nie jestem specem od marketingu, ale dla mnie by a to najbardziej innowacyjna seria reklam, jakie kiedykolwiek widzia em. Na ekranie pojawia y si, sprytnie zmontowane, czarno-bia e migawki bohaterów, wynalazców, my licieli i buntowników. Mogli my tam zobaczy Alberta Einsteina, który pali fajk, Boba Dylana graj cego na harmonijce, Martina Luthera Kinga wyg aszaj cego swoje najs ynniejsze kazanie: I Have a Dream (Mam marzenie), Richarda Bransona potrz saj cego butelk szampana, ta cz c Marth Graham, pe n pokoju twarz Mahatmy Ghandiego czy maluj cego Picassa. Tym wszystkim obrazom towarzyszy znakomity tekst czytany przez aktora Richarda Dreyfussa: S. Levy, The Perfect Thing. How the ipod Shuffles Commerce, Culture and Coolness, Simon & Schuster, New York 2006, s. 118 [t um. fragmentu: M. Chrapko].

19 MYŚLENIE ODWROTNE Zdrowie szale ców. Odmie ców. Buntowników. Wichrzycieli. Okr g ych ko ków w kwadratowych dziurach. Tych, którzy patrz na wszystko inaczej. Nie lubi regu. Nie maj szacunku dla status quo. Mo esz ich cytowa, nie zgadza si z nimi, gloryfikowa ich albo szkalowa. Tylko zignorowa ich nie mo esz. Bo oni zmieniaj wiat. Popychaj ludzko do przodu. I chocia niektórzy widz w nich szale ców, my widzimy ich geniusz. Bo ludzie na tyle szaleni, aby my le, e mog zmieni wiat, faktycznie go zmieniaj 11. Powstanie zwinnych metod tworzenia oprogramowania od samego pocz tku by o pewnego rodzaju my leniem odwrotnym do tego wszystkiego, co dzia o si w in ynierii oprogramowania od jej powstania. Idee zwinno ci kie kowa y w g owach takich odmie ców, jak: Gerald M. Weinberg, Frederick P. Brooks, Tom De Marco, Timothy Lister. Oni ju w latach 70. podkre lali znaczenie my lenia odwrotnego w tworzeniu oprogramowania i odej cia od mentalno ci zaczerpni tej ze wiata produkcji, która to mentalno mia aby sens, gdyby my pracowali w barach szybkiej obs ugi (lub innym rodowisku produkcyjnym), ale na pewno nie przy projektach software owych, gdzie ludzie bardziej pracuj g ow ni r kami. wiat metod zwinnych, który powstawa niemal e równolegle do wiata kaskadowego, by wiatem ludzi patrz cych na wszystko inaczej. wiatem, który powywraca do góry nogami wszystkie dotychczasowe regu y prowadzenia projektów. W lipcu 2007 r. portal CNN Money przeprowadzi ankiet, na podstawie której wy oni list pi dziesi ciu najbardziej wp ywowych ludzi, idei, trendów, produktów tego, co zmieni o bieg wiata biznesu 12. Metody agile znalaz y si na 18. miejscu. Manifest agile Równolegle z kszta towaniem si nowej fali my lenia odwrotnego jako opozycji do tego wszystkiego, co wi za o si z tradycyjnym rozwojem oprogramowania, rodzi y si konkretne praktyki stosowane przez ambasadorów zmiany. Lata 80. i 90. to czas stosowania alternatyw, w pewnym sensie: uczenia si na b dach wynikaj cych z próby zaszczepienia idei linii produkcyjnej 11 YouTube, Apple Crazy Ones, (dost p: 3 maja 2012) [t um. fragmentu: M. Chrapko]. 12 The 50 Who Matter Now, CNN Money, biz2/0706/gallery.50whomatter.biz2/33.html (dost p: 3 maja 2012). 29

20 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI do wiata tworzenia oprogramowania. Jest to okres, w którym ró ne grupy praktyków, na swój w asny i niczym nieskr powany sposób, zaczynaj tworzy now rzeczywisto ta rzeczywisto pó niej zostanie nazwana s owem agile. Lata 80. i 90. to równie czas, kiedy próbuje si nazywa i systematyzowa metody agile. To wtedy, w 1986 r., zaczyna by g o no o metodzie Scrum; zostaje opracowana Dynamic Systems Development Methodology (1994 r.); Kent Beck nazywa praktyki Extreme Progamming (1996 r., cho prawdziwy boom tej metody to 2000 r.); Alistar Cockburn mówi o metodach Crystal, a Jeff DeLuca publikuje Feature-Driven Development (1998 r.). Nowa fala praktyk nabiera rozmachu. W 2001 r. w o rodku wypoczynkowym Snowbird, w USA (stan Utah), zbiera si grupa zwolenników nowego podej cia celem nazwania tego, co tak naprawd charakteryzuje powstaj ce metody. W efekcie zostaje opracowany tzw. Manifesto for Agile Software Development (z ang. Manifest zwinnego tworzenia oprogramowania), który stanowi deklaracj podstawowych warto ci i zasad agile (w ca o ci do przeczytania na stronie: Pierwsza cz manifestu to cztery krótkie stwierdzenia, które w sposób prosty i jasny oddaj filozofi zwinno ci. Mówi o tym, jakie warto ci zwolennicy zwinnych metod ceni najbardziej. Zosta y one przedstawione na rysunku 1.3. Rysunek 1.3. Manifest agile Ludzie i interakcje ponad procesami i narzędziami Mo na mie wietnie zdefiniowane procesy, kupi bardzo drogie narz dzia, ale i tak, koniec ko ców, najwi kszy wp yw na powodzenie naszych projektów maj ludzie zaanga owani w ich rozwój. Czynnik ludzki jest elementem, 30

21 MYŚLENIE ODWROTNE którego bardzo brakuje we wszystkich modelach i standardach zaawansowanych procesów wytwórczych, np. w modelu CMMI. Oczywi cie mo na odpiera ten atak, mówi c, e model ten ma troch inne zastosowanie jego zadaniem jest nakre li map drogow, która pomo e zorganizowa wiat procesów w firmie. Niemniej prawda jest taka, e w praktyce model CMMI nie zawiera adnych konkretnych mechanizmów, które by uwydatnia y wp yw tego czynnika czy to na poziomie ycia organizacji, czy w porz dkowaniu ró nego rodzaju dzia a projektowych. Oczywi cie umo liwia wprowadzenie okre lonych zwinnych praktyk, które promuj prac zespo ow, wzmacniaj komunikacj interpersonaln, jednak w aden sposób nie zapewnia, e te praktyki zostan wprowadzone. Działające produkty ponad złożoną dokumentację Czytaj c to stwierdzenie manifestu, przypominam sobie rozmowy prowadzone przy okazji ró nego rodzaju wdro e rozmowy z programistami, którzy narzekali na prowadzenie i utrzymywanie dokumentacji w ich projektach. Cz sto mieli wra enie, e poruszaj si mi dzy jedn a drug ryz papieru; e w efekcie produkuj stosy dokumentów, które s generowane, bo taka jest polityka firmy i tego wymaga od nich kierownictwo. A tymczasem klienta i tak interesuje dzia aj cy software, który jest wolny od defektów i dostarczony na czas. Dlatego dokumentacja powinna raczej wspiera rozwój produktów, ni go utrudnia. Współpraca z klientem ponad negocjacją kontraktu Przy tym ha le, ale i przy wszystkich pozosta ych warto ciach i zasadach manifestu, nale y pami ta, e jest jeszcze realny wiat naszych projektów. I wszystko to, co tworzy ich niepowtarzaln rzeczywisto. Dlatego nawet je eli Wasi klienci kupi idee filozofii zwinno ci, to mimo to zawsze b d si chcieli jako zabezpieczy (a na pewno b dzie tego chcia ich dzia finansowy czy prawny) na wypadek, gdyby co posz o nie tak. Ci g a wspó praca z klientem na ka dym etapie prac rozwojowych jest jedn z podstawowych charakterystyk projektów zwinnych, która stanowi odpowied na metody kaskadowe, gdzie podpisanie kontraktu z klientem stanowi o o tym, czy dany projekt wystartuje, czy nie. Filozofia agile to obecno klienta na ka dym etapie prac rozwojowych. Praca programistów zale y bardzo mocno od informacji zwrotnej, któr dostarcza klient. 31

22 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI Reagowanie na zmiany ponad trzymaniem się planu Osoby, które kiedykolwiek mia y do czynienia z tradycyjnymi metodami tworzenia oprogramowania, bardzo dobrze pami taj te chwile, kiedy w trakcie implementacji pojawia y si nowe wymagania lub klient nagle co zmienia. Zmiana w trakcie kolejnych faz rozwojowych by a wtedy najmniej po dan rzecz. Mogli my prze y brak kawy w firmie, ale nie kolejne wrzutki od klienta. Zmiana by a czym obcym, niechcianym. Bali my si jej jak ognia. Du zas ug metod agile jest oswojenie zmiennych ycze klienta w trakcie prac rozwojowych. Zmiana jest dobra, jest niezmiennym elementem naszych prac wytwórczych. Oczywi cie to nie oznacza, e nasze projekty nie powinny mie planu i e planowanie jest niepotrzebne. Przeciwnie! Plan musi by. Jednak ka dorazowo jest on dopasowywany do zmieniaj cych si warunków rodowiskowych. Podstawowe warto ci manifestu zosta y dodatkowo wzbogacone o 12 zasad, które mo na potraktowa, jako swoist list kontroln zwinnego projektu. Mo na si z nimi zapozna na wspominanej ju stronie: 32

23 SKOROWIDZ A Albrecht Allan, 187 analityk biznesowy, 74, 80, 120, 134, 135, 138 analityk systemowy, 120 Atlassian, 263 atrybut mówcy, 281 B Beck Kent, 30, 141 Bezos Jeff, 115 blokada, 49 b dy, 248, 249 Boehm Barry, 174 Brass Dick, 66 Brown Tim, 113 burndown chart, Patrz: wykres spalania C Cannon-Brokkes Mike, 263, 264 Chambers Harry, 86 Chief Architect, Patrz: G ówny Architekt Chief Engineer, Patrz: G ówny In ynier Chief ScrumMaster, Patrz: G ówny ScrumMaster ci g Fibonacciego, 198 geometryczny, 198 Class Owner, Patrz: W a ciciel Klasy Cockburn Alistar, 30 Codziennik, 294 Cohn Mike, 147, 157, 180, 205, 260, 285 cross-functional teams, Patrz: zespó wielofunkcyjny Cskiszentmihalyi Mihaly, 130 cykl wytwórczy, 47 ycia projektu, Patrz: projekt cykl ycia czas trwania, 176, 177, 183 wiczenie Piankowe wyzwanie, 40 daily scrum, Patrz: scrum codzienny Dama z asiczk, 43 definicja uko czenia, 261 definition of done, Patrz: definicja uko czenia DeLuca Jeff, 30 DeMarco Tom, 105 Derby Esther, 312 dni idealne, 178, 191, 193, 195, 218, 240 dokumentacja, 31 Drucker Peter, 86 DSDM, 30, 47 Ć D 335

24 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI Dunbar Robin, 165 duration, Patrz: czas trwania Dynamic Systems Development Methodology, Patrz: DSDM effort, Patrz: pracoch onno elicitation, 138 Entergy, 103 entroskop, 37 epik, 79, 160, 161, 166, 185, 213, 214, 232 estymacja, 26, 169, 171, 189, 190, 193, 196, 197, 201, 222 Extreme Progamming, 30, 45, 46, 141, 155, 160 Farquhar Scott, 264 FDD, 30, 46 Feature Team, Patrz: Zespó Funkcjonalny Feature-Driven Development, Patrz: FDD feng shui, 106 Feynman Richard, 96 Fforde Jasper, 37 Fisher Darin, 70 Fosbury Dick, 27 Fowler Martin, 141 frequent delivery, 48 E F G G ówny Architekt, 46 G ówny In ynier, 78 G ówny ScrumMaster, 69 godziny idealne, 245, 254 Goodger Ben, 70 Google Chrome, 70 Gran Torino, 91 grooming, 162, 255, 285 hand-over, 139 Heller Micha, 77 hermeneutyka, 132 H historyjka badawcza, 155 historyjka u ytkownika, 81, 141, 147, 149, 150, 152, 153, 154, 155, 156, 158, 160, 161, 166, 179, 188, 198, 200, 201, 209, 229, 232, 240, 243, 253, 255, 256, 268 INVEST, 148 karta, 144 konfirmacja, 146 konwersacja, 145 Hohmann Luk, 317 ideal days, Patrz: dni idealne idealne dni, Patrz: dni idealne idealne godziny, Patrz: godziny idealne impediment, Patrz: blokada impediment backlog, Patrz: przeszkody rejestr implementacja, 19, 20, 34, 120, 261 inkrement, 44 Innovation Games, 317 inspekcja kodu, 56, 261 integrowanie, 19 interesariusz, 36, 38, 74, 169, 265, 307 INVEST, 148 in ynier wymaga, 134, 135, 138, 139 in ynieria oprogramowania, 18 iteracja, 44 Jacobellis Nick, 44 Jaspers Karl, 45, 90 Jeffries Ron, 144 JIRA, 71, 270 Jobs Steve, 28, 72, 301, 305 I J K kampania Think Different, 28 Kanban, 47 Kawasaki Guy, 304 Kennedy John Fitzgerald, 71 kierownik projektu, 69, 80, 81, 82, 84, 86, 87, 95, 112, 114, 169, 268, 278 kierownik projeku, 196 klika, 102, 105 kod flagowy MKS,

25 SKOROWIDZ komunikacja, 265, 290 osmotyczna, 48 komunikator internetowy, 293 konwersacja, 141, 145, 147, 154, 158, 163 kryterium akceptacyjne, 147, 200, 256, 304 Kubrick Stanley, 25 Larsen Diana, 312 lean, 47 lean management, 47 Lean Manufacturing, 47 lejek niepewno ci, 174, 220, 221 Lencioni Patrick, 277 Leonard da Vinci, 43 linie kodu, 178 lista kontrolna, 146 Lister Timothy, 105 Low Level Design, Patrz: projekt niskopoziomowy Lowndes Leil, 74 ludzie na kszta t litery T, 113, 119, 128 L Ł a cuch projektowy, 21 cznik, 295 M maintenance, 19 Malle Louis, 44 Manifest zwinnego tworzenia oprogramowania, 30, 45 Manifesto for Agile Software Development, 30 mapa drogowa, 31 McConnell Steve, 174 McLuhann Marshall, 293 mened er produktu, 69, 74 metoda Crystal, 30, 48 iteracyjna, 26 kaskadowa, Patrz: model kaskadowy Scrum, 30, 46, 48 metodyka kaskadowa, 17 mikrozarz dzanie, 85 model CMMI, 31 kaskadowe, 175 kaskadowy, 19, 20, 21, 22, 26, 31, 33, 46, 120, 133, 137, 190, 215 sekwencyjny, Patrz: model kaskadowy Model Kano, 214 MoSCoW, 47 N Na blacie, Patrz: Triangulacja Nonaka Ikujiro, 128, 129 osmotic communication, Patrz: komunikacja osmotyczna osmotyczna komunikacja, Patrz: komunikacja osmotyczna osobodzie, Patrz: dni idealne O P Page Scott, 127, 128 Penderecki Krzysztof, 39 Pichler Roman, 255, 307 Planning Poker, 189, 197, 198, 209 planowanie, 32, Patrz te : projekt plan, sprint planowanie, wydanie planowanie do przodu, 257 Polanyi Michael, 108 po czenie online, 57 Poppendieck Mary, 47 Poppendieck Tom, 47 Popper Karl, 173 pracoch onno, 116, 176, 183, 187, 191, 193, 214 priorytet, 212, 213, 217, 241, 243, 253, 267 priorytetyzacja wymaga, 47 proces, 55 empiryczny, 36, 39, 40, 42, 44 powtarzalny, 34, 36, 42 product backlog, Patrz: rejestr produktu Product Backlog, Patrz: rejestr produktu Product Owner, Patrz: W a ciciel Produktu 337

26 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI programista, 135, 137, 138, 139, 140, 145, 147, 151, 158, 214 projekt cykl ycia, 18 interesariusz, Patrz: interesariusz niskopoziomowy, 19 plan, 34, 204, 205 ryzyko ryzyko, 216 systemu, Patrz: system projekt z o ono, 36, 37 zorientowany na dat, 225 zorientowany na funkcjonalno ci, 227 projektowanie liniowe, 18 sekwencyjne, Patrz: projektowanie liniowe pró niactwo spo eczne, 117 przekazanie, Patrz: hand-over przeszkody, 289 przeszkoga, Patrz: blokada punkty, 178, 179, 182, 183, 188, 190, 192, 193, 214, 218, 240, 251 funkcyjne, 178 Putnam Doug, 116 QSM, 115 Quantitative Software Management, Patrz: QSM rejestr produktu, 47, 49, 70, 72, 120, 158, 162, 166, 208, 209, 232 relatywne wa enie, 214 Release Kick-Off, 79 retrospektywa, 47, 309, 311, 312, 316, 317, 319, 321 Ringelmann Max, 118 Robertson Suzanne i James, 138 rola projektowa, 46, 49, 53 Royce Winston, 22 Rubinstein Artur, 34 ryzyko, 216, 230 projektowe, 49 Q R S samoorganizacja, 86, 87, 88, 95, 130, 268, 290 samotranscendencja, 129 Schwaber Ken, 54, 253 Schwarz Roger, 322 scrum analiza, 319 codzienny, 278, 279, 280, 281, 282, 285, 290, 291, 294, 295, 296, 297 Scrum of Scrums, 297, 298 ScrumMaster, 49, 53, 54, 55, 57, 58, 60, 61, 63, 65, 66, 76, 78, 198, 199, 202, 214, 271, 279, 282, 287, 289, 295, 311, 323, 327 sesja piel gnacyjna, Patrz: grooming Skillman Peter, 40 Sorensen Ted, 71 specjalista, 114, 119 specyfikacja techniczna, 18 wymaga, 158 spike, 155, 186 spotkanie, 312 codzienne, Patrz: scrum codzienny projektowe, 278 sprint, 48, 56, 77, 140, 146, 154, 156, 163, 209, 210, 218, 241, 259, 309 cel, 242, 254, 303 planowanie, 207, 240, 244, 246, 250, 253, 256 przegl d, 302, 306 synchronizacja, 258 tablica, 267, 279, 285 stakeholder, Patrz: interesariusz Sta ko Tomasz, 39 Stewart Potter, 44 story points, Patrz: punkty strefy czasowe, 295 Streisand Barbra, 35 Süskind Patrik, 53 system architektura, 20 implementacja, Patrz: implementacja kolejkowania pracy, 47 projekt, 19,

27 SKOROWIDZ szacowanie, 169, 171, 173, 174, 176, 177, 178, 179, 182, 187, 188, 190, 192, 197, 201, 208, 209, 219, 245 Ś rodowisko pracy, 106 T tablica sprintu, Patrz: sprint tablica tacit knowledge, Patrz: wiedza ukryta Takeuchi Hirotaka, 128, 129 telekonferencja, 291 temat, 79, 161, 166, 212, 214, 232 test akceptacyjny, 146, 157, 256, 261 jednostkowy, 261 regresyjny, 212, 261 tester, 135, 137, 139, 140, 145, 214, 269 testowanie, 19, 20, 120, 122, 157, 212, 261 Think Different, 28 Tischner Józef, 24, 105, 213 Toyota Production System, 47 Triangulacja, 197, 201, 209 Truman Harry, 64 T-shaped People, Patrz: ludzie na kszta t litery T ujawnianie, Patrz: elicitation user story, Patrz: historyjka u ytkownika utrzymywanie, Patrz: maintenence U W Wake Bill, 154 Wake William, 147 warunki rodowiskowe, 32 waterfall model, Patrz: metodyka kaskadowa WBS, 26 Welch Jack, 136 wideokonferencja, 57, 202, 292 wiedza ukryta, 108 wielozadaniowo, 110 Witkacy, 42 W a ciciel Klasy, 46 Produktu, 49, 53, 60, 61, 69, 71, 72, 73, 74, 75, 77, 78, 80, 120, 121, 140, 145, 147, 148, 151, 153, 154, 163, 166, 190, 198, 200, 202, 207, 208, 212, 213, 214, 216, 229, 242, 253, 285, 306 Work Breakdown Structure, Patrz: WBS Wujec Tom, 40 wydanie, 209, 210, 229 planowanie, 207, 212, 227, 229, 230, 231, 232 wydobywanie, Patrz: elicitation wykres spalania, 233, 234, 236, 270, 271, 287, 294 wymagania, 133, 134, 135, 138, 139, 140, 141, 144, 146, 150, 153, 158, 162, 169, 171, 172, 190, 193, 196 biznesowe, 18 funkcjonalne, 18 Young Jeffrey, 72 Y Z zadanie, 241, 245, 246, 254, 268, 285 wielko, 247 zasada ograniczonego zaufania, 146, 169 zespó, 99, 102, 105, 106, 108, 130, 145, 147, 155, 156, 163, 169, 198, 210, 214, 229, 253, 278 funkcjonalny, 120, 121 komponentowy, 122, 123 pr dko, 149, 160, 191, 199, 210, 218, 219, 221, 229, 240, 243, 251, 254 rozproszony, 293, 296 wielko, 115, 116 wielofunkcyjny, 120, 129, 190 wirtualny, Patrz: zespó rozproszony Zespó Funkcjonalny, 46 argon, 136, 138 Ż 339

28 SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI 340

29

30