Issuu on Google+


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, 44-100 GLIWICE tel. 32 231 22 19, 32 230 98 63 e-mail: helion@helion.pl WWW: http://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku! Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie?scrumo Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

ISBN: 978-83-246-3828-4

Copyright © Helion 2013 Printed in Poland.

• Kup książkę • Poleć książkę • Oceń książkę

• Księgarnia internetowa • Lubię to! » Nasza społeczność


SPIS TREŚCI

O AUTORZE

7

PODZIĘKOWANIA

9

WPROWADZENIE

13

ZAMIAST WSTĘPU

15

1. MYŚLENIE ODWROTNE. Czym jest agile?

17

Szkoa przetrwania Wodospad Pan Samochodzik i tworzenie oprogramowania Ludzie z kryjówek Wychodzenie z kryjówki Mylenie odwrotne Zdrowie szaleców Manifest agile

17 18 23 24 26 27 28 29

2. LEKCJE PŁYWANIA. O zwinnym zarządzaniu projektami

33

Klasyka i jazz Piankowe wyzwanie Dama z asiczk Agile i pornografia Scrum Lekcje pywania

33 40 42 44 48 50

3 Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

3. KONTRABASISTA. Nowe role i obowiązki Lekcja z Kontrabasisty ScrumMaster Cechy dobrego ScrumMastera Wybór ScrumMastera W duej organizacji Waciciel Produktu Czy kierownik projektu jest potrzebny w Scrumie?

4. ŁAWA PRZYSIĘGŁYCH. O hodowaniu zwinnych zespołów projektowych Ugotowani Zespó = nirwana projektu Szlachetny cel Uprawa zwinnych zespoów Wielofunkcyjne zespoy Zespoy komponentowe awa przysigych

5. PLATON, IDEE I RYBY. Jak zwinnie zarządzać wymaganiami?

53 54 58 66 68 69 82

97 97 99 103 105 120 121 124

131

Jaszczurka czy dinozaur? Diabe tkwi w... komunikacji

131 133

Historyjki uytkownika

140

ZaINWESTuj w dobre historyjki

147

Rejestr produktu i ocean plazmy

158

Historyjki, epiki, tematy... thriller

160

Wymagania jak góra lodowa

161

Pielgnacja

162

Praca z duym rejestrem

163

Tylko 150, reszta nie ma znaczenia

165

6. LIZANIE ZNACZKÓW I CHIRURGIA MÓZGU. Szacowanie projektów w Scrumie

167

Kadzidowy dym, ekstatyczny trans

167

O istocie szacowania

168

W punktach czy w osobodniach?

190

Troch techniki i czowiek… si nie gubi

195

7. O ŻEGLOWANIU I OBIERANIU CEBULI. Planowanie projektów w Scrumie



53

203

Obsesja planowania

203

Zwinne planowanie eglowanie i obieranie cebuli Jak si do tego zabra ?

204 206 208

4

Kup książkę

Poleć książkę


SPIS TREŚCI

Plan wydania Planowanie na du skal Jak ledzi postp prac?

227 229 233

8. BIEGNIJ, FORREST, BIEGNIJ. Sprint

239

Jak na nartach po Barcelonie Planowanie sprintu Plan sprintu Gotowi!… Do startu!… Gotowi?! W duych projektach Zrobione czy niezrobione? Puste taczki Komunikacja ledzenie postpu prac

9. W POKOJU SZTABOWYM. Codzienne scrumy Wniosek o zakoczenie wojny Codzienny scrum Jak si komunikowa ? Zespoy rozproszone Scrum of Scrums

10. FURTKA DO OGRODU. O tym, jak zorganizować przegląd sprintu W sklepie z zabawkami Przegld sprintu Metoda Kawasakiego Zaraa dobr energi Furtka do ogrodu Atak na Ziemian

11. MYŚLODSIEWNIA. Retrospektywa na koniec sprintu

239 240 253 254 256 260 262 265 267

273 273 278 290 293 297

301 301 302 304 305 306 307

309

Mylodsiewnia Oczyszczenie Najczciej pomijana praktyka Lekcja anatomii Próba ogarnicia kuwety

309 310 311 312 321

12. WSPÓLNY REJS. Historia z morza wzięta

331

SKOROWIDZ

335

5 Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI



6

Kup książkę

Poleć książkę


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: Szkoa przetrwania). Dzielny Bear, podrónik i byy onierz sub specjalnych SAS 21 (Special Air Service), uzbrojony jedynie w nó, manierk, krzesiwo i ubranie, pokazuje, jak przetrwa w absolutnie ekstremalnych warunkach. Pamitam jeden z odcinków (waciwie chyba by to pilot 1. sezonu), który by krcony w Górach Skalistych, w USA. Due wraenie zrobia na mnie scena, w której Bear schodzi w dó rzeki (byo moe z 9 metrów) samym rodkiem wodospadu. Jeli kto z Was widzia ten odcinek, to wie, e Bear pokonywa go troch „na raty”. Najpierw pierwszy etap — dojcie do wodospadu. Potem drugi — zdobycie maej póki skalnej, oczywicie niewidocznej ze wzgldu na ogromn mas lodowatej wody, wpadajcej wprost na Beara. Kolejny moment to zejcie na pók skaln, ale jak? — za pomoc drabinki zrobionej z linek paralotni, na której nasz bohater wyldowa na pocztku programu. I wreszcie ostatni etap — skok z kilku metrów do ujcia rzeki. Myl, e opisana scena „pokonywania wodospadu” bardzo dobrze pokazuje puapk, w jak wpada wikszo z nas, stosujc 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, mona sobie przecie znacznie 17  Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

skróci drog, tym samym szybciej dotrze do zamierzonego celu. Do kogo, kto nie ma duego dowiadczenia w rozwijaniu oprogramowania, taki argument moe faktycznie trafia . Opiera si przecie na bardzo logicznych przesankach — najpierw musimy wiedzie , czego chce od nas klient (wymagania biznesowe), ebymy mogli myle o specyfikacji technicznej. Dopiero kiedy ju mamy te dwa etapy za sob, moemy rozpocz prace architektoniczne i zaj si dokumentacj wybranych rozwiza. 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 hutawki1. Tak sobie myl, e gdybym ja, podobnie jak Bear Grylls, zosta rzucony na pastw losu i musia przetrwa w najdzikszych miejscach na wiecie, na pewno nie schodzibym w dó wodospadem. Znajc moje fizyczne moliwoci, dodatkowo biorc pod uwag fakt, e nie suyem w SAS 21, z pewnoci poszukabym jakiej innej drogi w dó — niekoniecznie takiej, która skazaaby mnie na poamanie sobie rk 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 moe si zdarzy po drodze.

Wodospad Z powstaniem zwinnych metod tworzenia oprogramowania byo troch tak, jak z powstaniem ycia na Ziemi. Ich podstawowe idee, wyznawane wartoci i zasady ewoluoway wraz z dyscyplin inynierii oprogramowania, a wic od pocztku jej istnienia (przeom lat 50. i 60. XX w.). Niewtpliwym katalizatorem, który przyczyni si do ich rozwoju, by wiat tradycyjnych metod wytwórczych, które najpeniej definiuje podejcie zwane kaskadowym (od ang. waterfall). Polega na tym, e aktywnoci projektowe realizowane s liniowo (sekwencyjnie) — pyn niczym Nil, tworzc imponujce kaskady wodne (dwie z nich maj posta potnych wodospadów — nazywanych Ripon i Owena). Cykl ycia projektu dzielony jest na okrelone fazy, które wzajemnie od siebie zale. Najpierw ustalane s potrzeby klienta (wymagania biznesowe), potem tumaczy si je na jzyk zrozumiay dla programistów (wymagania funkcjonalne), eby z kolei, na ich podstawie, mona 1



Zob. http://www.projectcartoon.com/cartoon/32 (dostp: 3 maja 2012).

18

Kup książkę

Poleć książkę


MYŚLENIE ODWROTNE

byo zaprojektowa okrelone rozwizania techniczne (projekt systemu). Kolejna faza to implementacja wybranych rozwiza, które s: integrowane, testowane i utrzymywane (ang. maintenance) w wyniku wdroenia. Zwró cie uwag na to, e kada faza w tym podejciu stanowi domknit cao . Jej produkty wyjciowe (outputs) stanowi wejcia (inputs) do fazy nastpnej, co pokazuje rysunek 1.1.

Rysunek 1.1. Cykl kaskadowy projektu

Bardzo dobrze pamitam problemy wynikajce ze stosowania metody kaskadowej, z którymi sam, jako pocztkujcy kierownik projektów, musiaem si kiedy zmierzy . Przede wszystkim do szybko doszedem do wniosku, e stae wymagania w projekcie s tak rzadkie jak oscarowe role u Arnolda Schwarzeneggera. Wyobra cie sobie sytuacj, e skoczylicie prace zwizane z przygotowaniem niskopoziomowego projektu systemu (ang. Low Level Design). Nagle dzwoni klient i mówi, e chciaby troch rozbudowa dwie ostatnie funkcjonalnoci, o których rozmawialicie pi dni temu, i dodatkowo dorzuci jedn now. Do dzisiaj mylelicie, e wszystko jest pod kontrol. Nagle cay wiat wywraca si do góry nogami, grawitacja nie dziaa zgodnie z powszechnym prawem cienia, a czasoprzestrze zakrzywia si w nieprawdopodobny wrcz sposób. Scena ywcem wyjta z Incepcji Christophera Nolana2. Chciaoby si wama przez sen do wiadomoci klienta i zaszczepi

mu ide cierpliwego czekania i „niewrzucania” nam dodatkowej roboty. Ale… nie ma sprawiedliwoci na tym wiecie. Musimy kilka rzeczy przeprojektowa , 2

http://www.imdb.com/title/tt1375666/ (dostp: 3 maja 2012).

19  Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

przeplanowa i stara si jako podnie morale sfrustrowanego zespou. Nie trzeba ju chyba dodawa , jak bardzo takie „wrzutki” zwikszaj koszty prowadzonego projektu. Kolejnym problemem, który napotkaem przy okazji stosowania modelu kaskadowego, jest formalne pozbawienie prawa gosu naszego klienta w trakcie prowadzenia prac rozwojowych. Celowo napisaem „formalne”, gdy klient i tak kontaktowa si z nami na wiele rónych sposobów i demonstrowa swoje widzimisi. I nic nie moglimy zrobi . Nie pomagao alarmowanie o tym problemie wyszego kierownictwa, które, jak jedna z pluszowych zabawek stojcych przy wejciu do Smyka, natrtnie powtarzao: „Takie jest ycie! Dobrze wiesz, e jest to nasz strategiczny partner (czyt. dojna krowa) i musimy to jako znie . Gowa do góry! Nastpnym razem bdzie lepiej”. Nie byo. Model kaskadowy umoliwia rónego rodzaju „ucieczki” bdów z jednej fazy do drugiej. Wyobra cie sobie np., e na etapie testów systemowych nagle dowiadujecie si, e okrelone rozwizanie zostao le zaprojektowane i musicie wróci do wczeniejszej fazy, rozgrzeba architektur systemu, zaimplementowa odpowiednie poprawki, zrobi testy i wdroy 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, rczniki (oczywicie wszystko razy kilka, chyba e nie bierzemy ony i dzieci), buty, kosmetyczka, latarka, zapaki, saperka, adowarka do telefonu, konserwy… Wreszcie wyjedamy z Krakowa. Nawet nam sprawnie poszo, mimo e jest pitek i 17.00. Jedziemy ju okoo dwie godziny, nagle ona, patrzc bdnym wzrokiem na przejedajce ssiednim pasem auta, pyta: „Krzysiek, a namiot?”. Moecie sobie wyobrazi , jaki jest dalszy cig tej historii. Z modelem kaskadowym jest podobnie. Im pó niej si zorientujemy, e nie mamy namiotu, tym wicej nas kosztuje powrót po niego. W modelu kaskadowym nad sukcesem kadej fazy czuwa inny zespó, który skupia ludzi o bardzo zblionych kompetencjach. Na przykad za faz wymaga odpowiadaj analitycy biznesowi, analitycy systemowi oraz inynierowie wymaga. Na etapie projektowania pierwsze skrzypce graj projektanci i architekci. Pó niej do gry wchodz programici, którzy implementuj przyjte wczeniej rozwizania, a wyniki swoich prac przekazuj dalej testerom, którzy z kolei sprawdzaj, czy wszystko dziaa zgodnie z wymaganiami, a wic z tym, czym zajmowa si pierwszy zespó. Jeeli wszystko jest przetestowane, a znalezione bdy poprawione, produkt trafia w rce wdroeniowców, a w nastpnej kolejnoci zespou zajmujcego si 

20

Kup książkę

Poleć książkę


MYŚLENIE ODWROTNE

pracami utrzymaniowymi. Proces ten przypomina troch acuch pokarmowy, w którym mamy do czynienia z szeregiem rónych organizmów ustawionych w takiej kolejnoci, e kady z nich jest ródem poywienia dla kolejnego. Na rysunku 1.2 bliej niezidentyfikowana rolina jest pokarmem dla ddownicy, któr zjada ze smakiem na niadanie may ówik, bdcy niezym obiadowym kskiem dla zmczonego lataniem ora, wprost uwielbiajcego te opancerzone stwory. Mamy tu wic i „zjadajcych”, i „zjadanych”.

Rysunek 1.2. Łańcuch pokarmowy

W modelu kaskadowym zespó, który zbiera i analizuje wymagania, jest pierwszym ogniwem acucha projektowego. Wytwory jego prac (lista wymaga klienta) s „zjadane” przez zespó projektantów („zjadajcych”), które z kolei dostarczaj cennego poywienia (projekt systemu) zespoom programistów. acuszek ten zamyka si na etapie, kiedy klient konsumuje „gotowy produkt”. W przyrodzie acuchy pokarmowe s dugie i wzajemnie poprzeplatane — tworz sieci rónego rodzaju zalenoci pokarmowych. I to jest co, co nie jest brane pod uwag w podejciu kaskadowym. Tam bowiem zakada si pynne przejcie pomidzy jedn faz a drug. Model kaskadowy, przez surowe rozgraniczenie prac wykonywanych przez róne zespoy, powoduje rozmycie odpowiedzialnoci za rozwój produktu. Kady zespó skupia si tylko na swojej dziace i w aden sposób nie czuje si odpowiedzialny za to, co robi zespó kolejny. Kady zamyka si w swoim silosie. Przypomina mi to pewn histori. Kilka lat temu byem na 21  Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

weselu u mojego znajomego. Nie wiem jak Wy, ale ja, delikatnie mówic, nie najlepiej znosz wszelkiej maci zabawy weselne, które si przy tej okazji odbywaj. No ale przecie nie wypadao odmówi . Gra bya bardzo prosta. Polegaa na tym, e gocie weselni — zarówno ci, którzy zgosili si dobrowolnie, jak i ci, tacy jak ja, dostali si do zabawy z „apanki” — mieli utworzy koo i kolejno podawa sobie ma yeczk do herbaty. W tym czasie zespó pastwi si nad wesoymi weselnikami, grajc skoczne „umpa... umpa...”, od czasu do czasu robic niespodziewane przerwy. I wanie te „przerwy”, ni z gruchy ni z pietruchy, powodoway, e czowiek chcia jak najszybciej pozby si tej okropnej yeczki. I czym prdzej wcisn j w rce ssiada. Jest to postawa, któr wyzwalaa zasada tej zabawy, e gdy tylko muzyka przestaje gra , a kto zostanie z „problemem” w rku, wypada z gry. Projekty w modelu kaskadowym przypominaj bardzo zabaw z yeczk. Kady zespó chce jak najszybciej „wypchn ” to, co zrobi, do ssiedniego zespou — „Niech oni si tym martwi”. „To nie jest ju nasz problem”. Ile razy syszelimy takie hasa w swoim projekcie? Pamitacie, jak nieraz dany problem (bd, poprawka) by przerzucany midzy programistami, testerami, utrzymaniowcami lub osobami z obsugi klienta? „Przecie my zrobilimy to tak, jak byo w wymaganiach, to ONI zawalili, nie MY!”. Albo: „MY tego nie bdziemy naprawia , bo mymy tego nie robili, to ich robota”. W modelu kaskadowym poszczególne zespoy 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, uywajc metafory, któr posuy si niemiecki filozof — do tego potrzebne s drzwi i okna3. 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 bdów”4. Jest swoistym paradoksem, e wiele osób uwaa tego czowieka za twórc metodyki kaskadowej — czowieka, który widzia w niej due zagroenie.

3

Zob. F. Copleston, Historia filozofii, tum. J. Marzcki, t. IV, Instytut Wydawniczy PAX, Warszawa 1995, s. 299 – 300. 4 W. Royce, Managing the Development of Large Software System, Proceedings of IEEE WESCON 26 (August): 1 – 9, http://www.cs.umd.edu/class/spring2003/cmsc838p/ Process/waterfall.pdf (dostp: 3 maja 2012). 

22

Kup książkę

Poleć książkę


MYŚLENIE ODWROTNE

Pan Samochodzik i tworzenie oprogramowania Metody agile powstay jako reakcja na zaoenie, które od samego pocztku byo gboko zakorzenione w inynierii oprogramowania: „proces tworzenia oprogramowania jest procesem, który niczym nie róni si od procesu produkcyjnego”. Jest linia produkcyjna, s stanowiska robocze (maszynowe, rczne lub mieszane), pogrupowane wedug kolejnych operacji procesu technicznego. Idea „linii produkcyjnej”, w momencie powstania, bya alternatywnym rozwizaniem wobec dotychczasowej produkcji rzemielniczej i jej utworzenie stanowio niekwestionowan zasug amerykaskiego koncernu Ford. Inynierowie oprogramowania popenili jednak zasadniczy bd, próbujc przenie ten pomys na grunt projektów software’owych. Co gorsza, na tym zaoeniu osadzona zostaa caa dotychczasowa filozofia zarzdzania lud mi. Na czym ten bd polega? Wyobra sobie, Drogi Czytelniku, e awansowae i zostae kierownikiem projektu w zakadzie Tomasza N. N. (tytuowy bohater ksiki Pan Samochodzik), któremu znudzia si ju praca historyka sztuki, postanowi zacz masow produkcj pokracznego wehikuu, zbudowanego na bazie rozbitego Ferrari 410 Superamerica. Jako meneder odpowiadasz za lini produkcyjn. Natychmiast eliminujesz wszystkie pojawiajce si defekty; jeste wcieky i nie tolerujesz bdów popenianych przez pracowników, którzy obsuguj lini; traktujesz ich jak kolejny trybik maszyny, który w razie potrzeby zawsze mona 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  Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

Takie podejcie faktycznie ma sens i sprawdza si podczas pracy przy linii produkcyjnej, np. samochodów. Ogromnym bdem jest jednak próba zaaplikowania tego modelu do projektów software’owych, w których kluczow rol odgrywa tzw. „czynnik ludzki”. To od stopnia zaangaowania ludzi, ich kreatywnoci, umiejtnoci akceptowania problemów, radzenia sobie z konfliktami, zdolnoci komunikacji, pracy w grupie zaley sukces danego projektu. Stosowanie mechanizmów zaczerpnitych ze wiata produkcji moe prowadzi do postaw zupenie odwrotnych — stumienia inicjatywy, braku odwagi w wyraaniu swoich opinii i pomysów, chowania si do „kryjówek”, z których nie trzeba si zbytnio wychyla , eby przey kolejny dzie w pracy.

Ludzie z kryjówek Poniewa prywatnie zawsze byem i dalej jestem „fanatykiem” filozofii w kadym wydaniu, przytocz krótki fragment Mylenia wedug wartoci ks. Józefa Tischnera (na pewno kojarzycie jego kultow ju dzisiaj Filozofi po góralsku5, jeli nie — polecam!): Czowiek w kryjówce chroni si przed wiatem i przed innymi. Przyszo nie obiecuje czowiekowi nic wielkiego, pami przeszoci podsuwa mu przed oczy same doznane poraki, 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 przetrwania6. Styl zarzdzania, który próbuje odzwierciedla wiat produkcji, „spycha” czonków zespoów projektowych wanie do „kryjówek”. Zauwacie, w ilu projektach, w których sami uczestniczylicie, mielicie do czynienia z sytuacj, gdy kierownik zawsze bra sprawy w swoje rce w obawie o Wasze kompetencje. Wspópracowaem kiedy z firm, w której spotkaem si z do

komiczn sytuacj, a przypominaa mi ona dawne dziaania Gównego Urzdu Kontroli Prasy, Publikacji i Widowisk cenzurujcego publikacje prasowe, radiowe i telewizyjne w PRL-u. Kady e-mail, który ScrumMaster lub lider techniczny wysya do klienta, musia by wczeniej wnikliwie przeanalizowany i autoryzowany przez kierownika projektu. Z aptekarsk wrcz „precyzj”



5

J. Tischner, Historia filozofii po góralsku, Znak, Kraków 1997.

6

J. Tischner, Mylenie wedug wartoci, Znak, Kraków 2000, s. 412 – 413.

24

Kup książkę

Poleć książkę


MYŚLENIE ODWROTNE

kierownik studiowa kad wiadomo , która wychodzia poza firm, nanosi kluczowe — jak twierdzi — poprawki. Kiedy zapytaem go, dlaczego to robi. Szybko dostaem odpowied , e jego ludzie nie maj wyczucia tzw. „kwestii politycznych”, wic nie bdzie z tego wzgldu ryzykowa kontraktu z klientem, który jest jego jedyn „dojn krow”. Niestety nie byem w stanie go przekona , e w ten sposób zabija inicjatyw w zespole i — w efekcie — ksztatuje mentalno „ludzi z kryjówek”, którzy wczeniej czy pó niej przejd do defensywy i przestan wykazywa jakkolwiek wol twórczego dziaania. Bo, koniec koców, po co podejmowa takie dziaanie, skoro zawsze istnieje ryzyko, e moe si to le skoczy dla projektu? Innym powanym bdem menederów wychowanych w wiecie produkcji jest zabijanie indywidualnoci. Przez „indywidualist” rozumiem osob majc swoje zdanie, kreatywn, patrzc na problemy, które wczeniej 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ódem problemów. Tymczasem to czsto wyjtkowo decyduje o sukcesie danego przedsiwzicia. Ten, kto oglda film Lnienie Stanleya Kubricka, z rewelacyjn rol Jacka Nicholsona, z pewnoci wie, o czym mówi7. Ostatni rzecz, o której chciabym wspomnie w kontekcie tradycyjnego stylu zarzdzania, jest koncentracja na realizacji zada. W zarzdzaniu wzorujcym si na produkcji samochodów nie ma czasu na mylenie o tym, jak co zrobi . Zadania musz by wykonywane mechanicznie, eby ze wszystkim zdy na czas. Tymczasem w projektach software’owych tak si nie da. Oczywicie wszyscy o tym wiemy, niemniej czsto jest tak, e kiedy ju dostaniemy projekt do rki, rzucamy si w wir pracy, najczciej nie majc odpowiedniej iloci czasu na planowanie, analiz nowych metod i technologii, na szkolenia, czytanie fachowych ksiek, na wspólne dyskusje o problemach. W ubiegym roku miaem przyjemno wspópracowa z firm, która „programowaa na odlego ” dla niemieckiego zleceniodawcy — duej korporacji z, wydawaoby si, uporzdkowan struktur i tzw. dojrzaym adem organizacyjnym. Jednym z zada, do których zostaem zatrudniony, 7

http://www.imdb.com/title/tt0081505/ (dostp: 3 maja 2012).

25  Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

byo usprawnienie procesów szacowania parametrów projektu. Chodzio o to, eby nauczy ludzi przygotowywa WBS-a (ang. Work Breakdown Structure), odpowiednio definiowa zadania projektowe, a take wdroy jedn z technik estymacyjnych. Pocztkowo wszystko szo jak po male. Zespó z Polski bardzo szybko si wdroy. Wspólnie przygotowalimy kilka arkuszy estymacyjnych do wczeniej zoonych zamówie. I tu zaczy si schody. Nasi niemieccy koledzy nie mogli zrozumie , dlaczego w wycenie uwzgldnilimy analiz rozwiza architektonicznych, czas spdzony na telekonferencjach, a take zrobienie prototypu sprawdzajcego jedno z moliwych rozwiza. Ta firma w ogóle nie braa pod uwag, e zanim co zrobimy, musimy najpierw si zastanowi , jak to zrobi . Spotka si, pogada , pomyle nad rozwizaniem. Nie da si ludzi podpi do klawiatury i kaza im pisa kod.

Wychodzenie z kryjówki Agile to rodzina metod, które pomagaj ludziom zarzdzanym wedug regu linii produkcyjnej wyj z kryjówek. Kryjówka ma jaki próg, który trzeba przekroczy. Próg znaczy koniec kryjówki i pocztek nowej przestrzeni. Jeli si widzi koniec, a nie widzi si pocztku, bdzie si mimo wszystko wicej kocha zudzenie ni prawd8. Jaki pocztek proponuj metody agile? Przede wszystkim dziki iteracyjnej metodzie pracy, w której projekt podzielony jest na kilka mniejszych kawaków (iteracji), akceptuj „prawo” czonków zespoów do robienia bdów. Zastanówcie si przez chwil, na ile lepych zauków w trakcie realizacji Waszych projektów natrafilicie (bez wzgldu na ich rozmiar i zoono ). Ile byo meandrów? Ile razy walilicie gow w mur, nie wiedzc, co robi dalej — w któr stron i ? Agile zakada, e projekty s podatne na bdy. Jest rzecz zupenie normaln, e czsto zmienia si kierunek prac rozwojowych. Klient co kilka tygodni dostaje fragmenty dziaajcego produktu, moe go sobie ogldn , nacieszy si nim — zgosi swoje zastrzeenia oraz zaproponowa nowe pomysy. To jest dua sia tego podejcia. Pamitam, e jako pocztkujcy kierownik projektu, przygotowujc harmonogram prac w oparciu o metodyk kaskadow, zawsze miaem problem ze zmiennoci wymaga. Zbieraem nawet metryk ledzc ich fluktuacj (ile pojawio si nowych? 8



J. Tischner, Mylenie wedug wartoci, op. cit., s. 427.

26

Kup książkę

Poleć książkę


MYŚLENIE ODWROTNE

ile zmieniono starych? ile te zmiany nas kosztoway?), a wszystko po to, eby mie „haka” na klienta na wypadek, gdyby przyszo mu do gowy czepia

si nas, bo po raz kolejny nie zdylimy z osigniciem zaplanowanego kamienia milowego, bo w trakcie implementacji kilka razy zmieniy si wymagania i pierwotny zakres prac poszerzy si o trzy nowe funkcjonalnoci. Musz przyzna , e zawsze byem bezsilny. Kiedy jednak zaczem stosowa

zwinne praktyki projektowe, wszystko si zmienio. Agile „oswoi” zmian. Pokaza, e „nie taki diabe straszny...”. Metody zwinne promuj opisany wczeniej indywidualizm. W tym sensie s drog pod prd tradycyjnego stylu zarzdzania. Dziki stosowanym metodom i narzdziom tworz co, co moglibymy nazwa demokratycznym stylem zarzdzania. Kierownik projektu nie jest ju „królem”, który panuje nad ludem, niezalenie od ukadów politycznych i systemów. Jest bardziej sug i mentorem osób, które angauj si w projekt. Jego rola musi wic zosta

odpowiednio przedefiniowana. Dodatkowo o „demokracji” wiadczy fakt, e „wadza zostaa oddana w rce ludu”. Odtd to zespó, a nie kierownik projektu, decyduje o tym, jak zdefiniowa poszczególne zadania projektowe oraz kto si nimi zajmie. Rola kierownika musi wic zosta zdefiniowana na nowo, w kontekcie wartoci i zasad, które przynosi ze sob idea zwinnoci. Bdzie o tym wicej w rozdziale 3., powiconym rolom w Scrumie.

Myślenie odwrotne Metody agile powstay w wyniku próby spojrzenia na proces tworzenia oprogramowania w nieco inny — odwrotny sposób. Na myl przychodzi mi tutaj historia, któr przeczytaem w ksice Paula Ardena Cokolwiek mylisz, pomyl odwrotnie9. Rzecz zdarzya si przed olimpiad w Meksyku, która odbya si w 1986 r. By to czas, kiedy technika skoków wzwy polegaa na tym, e sportowcy w trakcie skoku „przerzucali” swoje ciao równolegle do poprzeczki. Na wspomnianej olimpiadzie pojawi si, wtedy jeszcze mao znany zawodnik, Dick Fosbury, który podbieg do poprzeczki, ustawionej na rekordowej wysokoci 2 m 24 cm. Wybi si i zamiast skoczy jak wszyscy, ustawi swoje ciao w kierunku poprzeczki, obracajc si do niej plecami. Unoszc nogi, pokona j tyem. Jego styl skakania obowizuje do dzisiaj

9

P. Arden, Cokolwiek mylisz, pomyl odwrotnie, tum. O. Siara, Insignis, Kraków 2008, s. 7.

27  Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

i zasyn jako „flop Fosbury’ego”. Dick skoczy wyej ni ktokolwiek przedtem, bo odway si myle inaczej. Metody agile to wanie przykad „mylenia odwrotnego” wzgldem pokonywania poprzeczki w tradycyjny sposób, czyli w naszym przypadku — stosowania podejcia kaskadowego. Kiedy po raz pierwszy ogldaem w internecie zdjcia skoczków, którzy oddawali swoje skoki przed 1986 r., pomylaem: „Jak oni mogli tak nienaturalnie skaka ? Przecie to zupenie cudaczne. A wierzy si nie chce, e ludzie nie skrcali sobie karków przy ldowaniu”. A jednak.

Zdrowie szaleńców Ludziom, którzy myleli odwrotnie, bya w caoci powicona jedna z najbardziej innowacyjnych kampanii reklamowych wszechczasów — Think Different firmy Apple. Steve Jobs w jednym z wywiadów opowiada, jak doszo do jej powstania: Kampania Think Different wynikaa std, e ludzie, w tym nasi pracownicy, zapomnieli, do jakich wartoci odwouje si Apple. Dugo zastanawialimy si, jak powiedzie komu, za czym si opowiadamy, jakie wartoci wyznajemy, a uwiadomilimy sobie, e kiedy nie znasz kogo dobrze, moesz go zapyta: „Kim s twoi bohaterowie?”. Mona si wiele dowiedzie o ludziach na tej podstawie. Stwierdzilimy wic: „Dobra, powiemy im, kim s nasi bohaterowie”10. O kampanii Think Different mówi si czsto, e przyczynia si do odbudowania wizerunku firmy Apple po fiasku sprzed poprzednich lat. Nie jestem specem od marketingu, ale dla mnie bya to najbardziej innowacyjna seria reklam, jakie kiedykolwiek widziaem. Na ekranie pojawiay si, sprytnie zmontowane, czarno-biae migawki bohaterów, wynalazców, mylicieli i buntowników. Moglimy tam zobaczy Alberta Einsteina, który pali fajk, Boba Dylana grajcego na harmonijce, Martina Luthera Kinga wygaszajcego swoje najsynniejsze kazanie: I Have a Dream (Mam marzenie), Richarda Bransona potrzsajcego butelk szampana, taczc Marth Graham, pen pokoju twarz Mahatmy Ghandiego czy malujcego Picassa. Tym wszystkim obrazom towarzyszy znakomity tekst czytany przez aktora Richarda Dreyfussa:

10

S. Levy, The Perfect Thing. How the iPod Shuffles Commerce, Culture and Coolness, Simon & Schuster, New York 2006, s. 118 [tum. fragmentu: M. Chrapko]. 

28

Kup książkę

Poleć książkę


MYŚLENIE ODWROTNE

Zdrowie szaleców. Odmieców. Buntowników. Wichrzycieli. Okrgych koków w kwadratowych dziurach. Tych, którzy patrz na wszystko inaczej. Nie lubi regu. Nie maj szacunku dla status quo. Moesz ich cytowa, nie zgadza si z nimi, gloryfikowa ich albo szkalowa. Tylko zignorowa ich nie moesz. Bo oni zmieniaj wiat. Popychaj ludzko do przodu. I chocia niektórzy widz w nich szaleców, my widzimy ich geniusz. Bo ludzie na tyle szaleni, aby myle, e mog zmieni wiat, faktycznie go zmieniaj11. Powstanie zwinnych metod tworzenia oprogramowania od samego pocztku byo pewnego rodzaju myleniem odwrotnym do tego wszystkiego, co dziao si w inynierii oprogramowania od jej powstania. Idee zwinnoci kiekoway w gowach takich „odmieców”, jak: Gerald M. Weinberg, Frederick P. Brooks, Tom De Marco, Timothy Lister. Oni ju w latach 70. podkrelali znaczenie „mylenia odwrotnego” w tworzeniu oprogramowania i odejcia od mentalnoci zaczerpnitej ze wiata produkcji, która to mentalno miaaby sens, gdybymy pracowali w barach szybkiej obsugi (lub innym rodowisku produkcyjnym), ale na pewno nie przy projektach software’owych, gdzie ludzie bardziej pracuj gow ni rkami. wiat metod zwinnych, który powstawa niemale równolegle do wiata kaskadowego, by wiatem ludzi patrzcych na wszystko inaczej. wiatem, który powywraca do góry nogami wszystkie dotychczasowe reguy prowadzenia projektów. W lipcu 2007 r. portal CNN Money przeprowadzi ankiet, na podstawie której wyoni list pi dziesiciu najbardziej wpywowych ludzi, idei, trendów, produktów — tego, co zmienio bieg wiata biznesu12. Metody agile znalazy si na 18. miejscu.

Manifest agile Równolegle z ksztatowaniem si nowej fali „mylenia odwrotnego” jako opozycji do tego wszystkiego, co wizao si z tradycyjnym rozwojem oprogramowania, rodziy si konkretne praktyki stosowane przez ambasadorów zmiany. Lata 80. i 90. to czas stosowania alternatyw, w pewnym sensie: uczenia si na bdach wynikajcych z próby zaszczepienia idei linii produkcyjnej 11

YouTube, Apple — Crazy Ones, http://www.youtube.com/watch?v=4oAB83Z1ydE (dostp: 3 maja 2012) [tum. fragmentu: M. Chrapko]. 12 The 50 Who Matter Now, CNN Money, http://money.cnn.com/galleries/2007/ biz2/0706/gallery.50whomatter.biz2/33.html (dostp: 3 maja 2012).

29  Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

do wiata tworzenia oprogramowania. Jest to okres, w którym róne grupy praktyków, na swój wasny i niczym nieskrpowany sposób, zaczynaj tworzy now rzeczywisto — ta rzeczywisto pó niej zostanie nazwana sowem „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 gono 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 orodku wypoczynkowym Snowbird, w USA (stan Utah), zbiera si grupa zwolenników nowego podejcia celem nazwania tego, co tak naprawd charakteryzuje powstajce metody. W efekcie zostaje opracowany tzw. Manifesto for Agile Software Development (z ang. Manifest zwinnego tworzenia oprogramowania), który stanowi deklaracj podstawowych wartoci i zasad agile (w caoci do przeczytania na stronie: http://agilemanifesto.org/). Pierwsza cz manifestu to cztery krótkie stwierdzenia, które w sposób prosty i jasny oddaj filozofi zwinnoci. Mówi o tym, jakie wartoci zwolennicy zwinnych metod ceni najbardziej. Zostay one przedstawione na rysunku 1.3.

Rysunek 1.3. Manifest agile

Ludzie i interakcje ponad procesami i narzędziami Mona mie wietnie zdefiniowane procesy, kupi bardzo drogie narzdzia, ale i tak, koniec koców, najwikszy wpyw na powodzenie naszych projektów maj ludzie zaangaowani w ich rozwój. Czynnik ludzki jest elementem, 

30

Kup książkę

Poleć książkę


MYŚLENIE ODWROTNE

którego bardzo brakuje we wszystkich modelach i standardach zaawansowanych procesów wytwórczych, np. w modelu CMMI®. Oczywicie mona odpiera ten atak, mówic, e model ten ma troch inne zastosowanie — jego zadaniem jest nakreli map drogow, która pomoe zorganizowa

wiat procesów w firmie. Niemniej prawda jest taka, e w praktyce model CMMI® nie zawiera adnych konkretnych mechanizmów, które by uwydatniay wpyw tego czynnika — czy to na poziomie ycia organizacji, czy w porzdkowaniu rónego rodzaju dziaa projektowych. Oczywicie umoliwia wprowadzenie okrelonych zwinnych praktyk, które promuj prac zespoow, wzmacniaj komunikacj interpersonaln, jednak w aden sposób nie zapewnia, e te praktyki zostan wprowadzone.

Działające produkty ponad złożoną dokumentację Czytajc to stwierdzenie manifestu, przypominam sobie rozmowy prowadzone przy okazji rónego rodzaju wdroe — rozmowy z programistami, którzy narzekali na prowadzenie i utrzymywanie dokumentacji w ich projektach. Czsto mieli wraenie, e poruszaj si midzy 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 dziaajcy 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 hale, ale i przy wszystkich pozostaych wartociach i zasadach manifestu, naley pamita , e jest jeszcze realny wiat naszych projektów. I wszystko to, co tworzy ich niepowtarzaln rzeczywisto . Dlatego nawet jeeli Wasi klienci „kupi” idee filozofii zwinnoci, to mimo to zawsze bd si chcieli jako zabezpieczy (a na pewno bdzie tego chcia ich dzia finansowy czy prawny) na wypadek, gdyby co poszo nie tak. Ciga wspópraca z klientem na kadym etapie prac rozwojowych jest jedn z podstawowych charakterystyk projektów zwinnych, która stanowi odpowied na metody kaskadowe, gdzie podpisanie kontraktu z klientem stanowio o tym, czy dany projekt wystartuje, czy nie. Filozofia agile to obecno klienta na kadym etapie prac rozwojowych. Praca programistów zaley bardzo mocno od informacji zwrotnej, któr dostarcza klient. 31  Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

Reagowanie na zmiany ponad trzymaniem się planu Osoby, które kiedykolwiek miay do czynienia z tradycyjnymi metodami tworzenia oprogramowania, bardzo dobrze pamitaj te chwile, kiedy w trakcie implementacji pojawiay si nowe wymagania lub klient nagle co zmienia. Zmiana w trakcie kolejnych faz rozwojowych bya wtedy najmniej podan rzecz. Moglimy przey brak kawy w firmie, ale nie kolejne „wrzutki” od klienta. Zmiana bya czym obcym, niechcianym. Balimy si jej jak ognia. Du zasug metod agile jest „oswojenie” zmiennych ycze klienta w trakcie prac rozwojowych. Zmiana jest dobra, jest niezmiennym elementem naszych prac wytwórczych. Oczywicie to nie oznacza, e nasze projekty nie powinny mie planu i e planowanie jest niepotrzebne. Przeciwnie! Plan musi by . Jednak kadorazowo jest on dopasowywany do zmieniajcych si warunków rodowiskowych. Podstawowe wartoci manifestu zostay dodatkowo wzbogacone o 12 zasad, które mona potraktowa , jako swoist list kontroln zwinnego projektu. Mona si z nimi zapozna na wspominanej ju stronie: http://agilemanifesto.org/.



32

Kup książkę

Poleć książkę


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 bdy, 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 Inynier Chief ScrumMaster, Patrz: Gówny ScrumMaster cig Fibonacciego, 198 geometryczny, 198

Class Owner, Patrz: Waciciel 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

D daily scrum, Patrz: scrum codzienny Dama z asiczk, 43 definicja ukoczenia, 261 definition of done, Patrz: definicja ukoczenia 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

335  Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

Dunbar Robin, 165 duration, Patrz: czas trwania Dynamic Systems Development Methodology, Patrz: DSDM

E effort, Patrz: pracochonno

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

F 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

G Gówny Architekt, 46 Gówny Inynier, 78 Gówny ScrumMaster, 69 godziny idealne, 245, 254 Goodger Ben, 70 Google Chrome, 70 Gran Torino, 91 grooming, 162, 255, 285

H hand-over, 139 Heller Micha, 77 hermeneutyka, 132 

historyjka badawcza, 155 historyjka uytkownika, 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

I 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 inynier wymaga, 134, 135, 138, 139 inynieria oprogramowania, 18 iteracja, 44

J Jacobellis Nick, 44 Jaspers Karl, 45, 90 Jeffries Ron, 144 JIRA, 71, 270 Jobs Steve, 28, 72, 301, 305

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

336

Kup książkę

Poleć książkę


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

L Larsen Diana, 312 lean, 47 lean management, 47 Lean Manufacturing, 47 lejek niepewnoci, 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 ksztat litery T, 113, 119, 128

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

O osmotic communication, Patrz: komunikacja osmotyczna osmotyczna komunikacja, Patrz: komunikacja osmotyczna osobodzie, Patrz: dni idealne

P Ł acuch 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 meneder produktu, 69, 74 metoda Crystal, 30, 48 iteracyjna, 26 kaskadowa, Patrz: model kaskadowy Scrum, 30, 46, 48 metodyka kaskadowa, 17 mikrozarzdzanie, 85

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 poczenie online, 57 Poppendieck Mary, 47 Poppendieck Tom, 47 Popper Karl, 173 pracochonno , 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: Waciciel Produktu

337  Kup książkę

Poleć książkę


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 zoono , 36, 37 zorientowany na dat, 225 zorientowany na funkcjonalnoci, 227 projektowanie liniowe, 18 sekwencyjne, Patrz: projektowanie liniowe próniactwo spoeczne, 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

Q QSM, 115 Quantitative Software Management, Patrz: QSM

R rejestr produktu, 47, 49, 70, 72, 120, 158, 162, 166, 208, 209, 232 relatywne waenie, 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



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 pielgnacyjna, 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 przegld, 302, 306 synchronizacja, 258 tablica, 267, 279, 285 stakeholder, Patrz: interesariusz Stako 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, 21

338

Kup książkę

Poleć książkę


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 ksztat litery T

U ujawnianie, Patrz: elicitation user story, Patrz: historyjka uytkownika utrzymywanie, Patrz: maintenence

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

Waciciel 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

Y Young Jeffrey, 72

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 prdko , 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  Kup książkę

Poleć książkę


SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI



340

Kup książkę

Poleć książkę



Scrum. O zwinnym zarz dzaniu projektami