Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00215 004773 15203191 na godz. na dobę w sumie
Scrum. O zwinnym zarządzaniu projektami - książka
Scrum. O zwinnym zarządzaniu projektami - książka
Autor: Liczba stron: 344
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-3828-4 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> biznes it >> zarządzanie projektami it
Porównaj ceny (książka, ebook, audiobook).
O metodzie Scrum czyli o zwinnym zarządzaniu projektami - rozmowa, pół żartem pół serio, z Mariuszem Chrapko



Poznaj Scrum i bądź efektywny!

Zwinne metody projektowania, takie jak Scrum, święcą dziś triumfy jako alternatywne podejście do przeprowadzania skomplikowanych, wieloaspektowych projektów, zwłaszcza z dziedziny IT. W przeciwieństwie do tradycyjnych systemów, Scrum zakłada podział projektu na krótkie iteracje (sprinty), z których każda kończy się przedstawieniem fragmentu działającego produktu. Niezwykle ważną częścią projektu jest działanie w pełnej zgodzie z osiągnięciami psychologii - nic nie dzieje się tu bez uwzględnienia potrzeb członków zespołu projektowego oraz docelowego klienta.

Jeśli chcesz dowiedzieć się więcej o zwinnych sposobach prowadzenia projektów i zastosować je we własnej pracy, Mariusz Chrapko podpowie Ci, jak planować takie procesy, rozdzielać role, zbierać informacje i unikać poważniejszych błędów. Wskaże, jak szacować projekty i określać postępy prac. Wszystko to, okraszone mnóstwem konkretnych przykładów, barwnych analogii i dowcipnych anegdot, sprawi, że książka nie tylko bardzo Ci pomoże, ale także dostarczy wiele przyjemności podczas lektury.

Scrum - wykorzystaj jego siłę!


To wciągające kompendium wiedzy o metodach Agile i nie tylko... 'Zwinnie' wprowadza czytelnika w świat nowego podejścia do wykorzystania potencjału ludzi tworzących oprogramowanie. Lektura obowiązkowa dla softwarowych zawodowców.
Ludmiła Pisiewicz,
dyrektor Departamentu Rozwoju Aplikacji, PMP, MBA, ING Bank Śląski

Świetne połączenie teorii z praktyką, poparte ciekawymi przykładami. Polecam!
Piotr Czupryn,
kierownik zespołu, Lufthansa Systems Poland

Książka zdecydowanie powinna przypaść do gustu wszystkim profesjonalistom poszukującym alternatywy dla tradycyjnych procesów tworzenia oprogramowania.
dr Edward Lubkiewicz,
kierownik zespołów IT Nokia Siemens Networks

Autor doskonale łączy teorię z praktyką. Książkę wyróżnia styl, który sprawia, że czyta się ją niezwykle przyjemnie.
Łukasz Łopuszański,
redaktor naczelny magazynu 'Programista'

Temat ujęty w ciekawy, nowatorski sposób. Wiele przykładów podkreślających znaczenie pracy zespołowej. Brawa za praktyczne podejście!
Krzysztof Kestranek,
QA Manager Autodesk

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

Darmowy fragment publikacji:

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ść O AUTORZE PODZIĘKOWANIA WPROWADZENIE ZAMIAST WSTĘPU 1. MYŚLENIE ODWROTNE. Czym jest agile? Szkoïa przetrwania Wodospad Pan Samochodzik i tworzenie oprogramowania Ludzie z kryjówek Wychodzenie z kryjówki MyĂlenie odwrotne Zdrowie szaleñców Manifest agile 2. LEKCJE PŁYWANIA. O zwinnym zarządzaniu projektami Klasyka i jazz Piankowe wyzwanie Dama z ïasiczkÈ Agile i pornografia Scrum Lekcje pïywania SPIS TREŚCI 7 9 13 15 17 17 18 23 24 26 27 28 29 33 33 40 42 44 48 50 3  SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI 3. KONTRABASISTA. Nowe role i obowiązki Lekcja z Kontrabasisty ScrumMaster Cechy dobrego ScrumMastera Wybór ScrumMastera W duĝej organizacji WïaĂciciel 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 zespoïy Zespoïy komponentowe ’awa przysiÚgïych 5. PLATON, IDEE I RYBY. Jak zwinnie zarządzać wymaganiami? Jaszczurka czy dinozaur? Diabeï tkwi w... komunikacji Historyjki uĝytkownika ZaINWESTuj w dobre historyjki Rejestr produktu i ocean plazmy Historyjki, epiki, tematy... thriller Wymagania jak góra lodowa PielÚgnacja Praca z duĝym rejestrem Tylko 150, reszta nie ma znaczenia 6. LIZANIE ZNACZKÓW I CHIRURGIA MÓZGU. Szacowanie projektów w Scrumie Kadzidïowy dym, ekstatyczny trans O istocie szacowania W punktach czy w osobodniach? TrochÚ techniki i czïowiek… siÚ nie gubi 7. O ŻEGLOWANIU I OBIERANIU CEBULI. Planowanie projektów w Scrumie Obsesja planowania Zwinne planowanie ¿eglowanie i obieranie cebuli Jak siÚ do tego zabraÊ?  4 53 53 54 58 66 68 69 82 97 97 99 103 105 120 121 124 131 131 133 140 147 158 160 161 162 163 165 167 167 168 190 195 203 203 204 206 208 Plan wydania Planowanie na duĝÈ skalÚ Jak ĂledziÊ postÚp prac? 8. BIEGNIJ, FORREST, BIEGNIJ. Sprint Jak na nartach po Barcelonie Planowanie sprintu Plan sprintu Gotowi!… Do startu!… Gotowi?! W duĝych projektach Zrobione czy niezrobione? Puste taczki Komunikacja ¥ledzenie postÚpu prac 9. W POKOJU SZTABOWYM. Codzienne scrumy Wniosek o zakoñczenie wojny Codzienny scrum Jak siÚ komunikowaÊ? Zespoïy rozproszone Scrum of Scrums 10. FURTKA DO OGRODU. O tym, jak zorganizować przegląd sprintu W sklepie z zabawkami PrzeglÈd sprintu Metoda Kawasakiego ZaraĝaÊ dobrÈ energiÈ Furtka do ogrodu Atak na Ziemian 11. MYŚLODSIEWNIA. Retrospektywa na koniec sprintu MyĂlodsiewnia Oczyszczenie NajczÚĂciej pomijana praktyka Lekcja anatomii Próba ogarniÚcia kuwety 12. WSPÓLNY REJS. Historia z morza wzięta SKOROWIDZ SPIS TREŚCI 227 229 233 239 239 240 253 254 256 260 262 265 267 273 273 278 290 293 297 301 301 302 304 305 306 307 309 309 310 311 312 321 331 335 5  SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI  6 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 emi- towanego 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 wodo- spadu. 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 opisa- na 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  SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI skróciÊ drogÚ, tym samym szybciej dotrzeÊ do zamierzonego celu. Do ko- goĂ, 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 (wyma- gania biznesowe), ĝebyĂmy mogli myĂleÊ o specyfikacji technicznej. Dopiero kiedy juĝ mamy te dwa etapy za sobÈ, moĝemy rozpoczÈÊ prace architekto- niczne i zajÈÊ siÚ dokumentacjÈ wybranych rozwiÈzañ. Gdy juĝ nam siÚ to uda, wreszcie mekka! — upragnione pisanie kodu. Potem juĝ tylko testy, rete- sty i — uwaga! — Wielki Finaï, czyli demonstracja efektów naszej pracy klien- towi, który dostaje oponÚ zawieszonÈ na linie zamiast wymarzonej huĂtawki1. 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 katali- zatorem, 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È linio- wo (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 (wyma- gania biznesowe), potem tïumaczy siÚ je na jÚzyk zrozumiaïy dla programi- stów (wymagania funkcjonalne), ĝeby z kolei, na ich podstawie, moĝna 1 Zob. http://www.projectcartoon.com/cartoon/32 (dostÚp: 3 maja 2012).  18 MYŚLENIE ODWROTNE byïo zaprojektowaÊ okreĂlone rozwiÈzania techniczne (projekt systemu). Kolejna faza to implementacja wybranych rozwiÈzañ, które sÈ: integrowa- ne, 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 nie- prawdopodobny wrÚcz sposób. Scena ĝywcem wyjÚta z Incepcji Christophera Nolana2. 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 http://www.imdb.com/title/tt1375666/ (dostÚp: 3 maja 2012). 19  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 trak- cie 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 jed- nej fazy do drugiej. Wyobraěcie sobie np., ĝe na etapie testów systemowych nagle dowiadujecie siÚ, ĝe okreĂlone rozwiÈzanie zostaïo ěle zaprojektowa- ne 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. Paku- jemy siÚ: Ăpiwór, karimata, ubrania, rÚczniki (oczywiĂcie wszystko razy kilka, chyba ĝe nie bierzemy ĝony i dzieci), buty, kosmetyczka, latarka, zapaïki, sa- perka, ïadowarka do telefonu, konserwy… Wreszcie wyjeĝdĝamy z Krakowa. Nawet nam sprawnie poszïo, mimo ĝe jest piÈtek i 17.00. 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 wyobra- ziÊ, 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 fa- zÚ 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 im- plementujÈ przyjÚte wczeĂniej rozwiÈzania, a wyniki swoich prac przeka- zujÈ 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 MYŚLENIE ODWROTNE pracami utrzymaniowymi. Proces ten przypomina trochÚ ïañcuch pokar- mowy, 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 uwielbia- jÈ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 wyma- gañ klienta) sÈ „zjadane” przez zespóï projektantów („zjadajÈcych”), które z kolei dostarczajÈ cennego poĝywienia (projekt systemu) zespoïom programi- stów. ’añcuszek ten zamyka siÚ na etapie, kiedy klient konsumuje „gotowy produkt”. W przyrodzie ïañcuchy pokarmowe sÈ dïugie i wzajemnie po- przeplatane — tworzÈ sieci róĝnego rodzaju zaleĝnoĂci pokarmowych. I to jest coĂ, co nie jest brane pod uwagÚ w podejĂciu kaskadowym. Tam bo- wiem 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  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Ú dobro- wolnie, jak i ci, tacy jak ja, dostali siÚ do zabawy z „ïapanki” — mieli utwo- rzyÊ 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... um- pa...”, 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 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 ry- zykowna 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 Wydawni- czy 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 (dostÚp: 3 maja 2012).  22 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 tworze- nia 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 alterna- tywnym rozwiÈzaniem wobec dotychczasowej produkcji rzemieĂlniczej i jej utworzenie stanowiïo niekwestionowanÈ zasïugÚ amerykañskiego koncer- nu 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Èdza- nia 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 wehi- kuïu, zbudowanego na bazie rozbitego Ferrari 410 Superamerica. Jako menedĝer odpowiadasz za liniÚ produkcyjnÈ. Natychmiast eliminujesz wszystkie po- jawiajÈ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 je- steĂ mistrzem wszelkich instrukcji — wszystko musi „tykaÊ” jak w szwaj- carskim 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  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 klu- czowÈ 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 pro- dukcji moĝe prowadziÊ do postaw zupeïnie odwrotnych — stïumienia ini- cjatywy, 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Ê ko- lejny 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óralsku5, 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. Wpraw- dzie w kryjówce nadzieja nie znika bez reszty, tylko maleje, ale maleje do tego stopnia, ĝe staje siÚ jedynie nadziejÈ przetrwania6. Styl zarzÈdzania, który próbuje odzwierciedlaÊ Ăwiat produkcji, „spy- cha” 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, ra- diowe i telewizyjne w PRL-u. Kaĝdy e-mail, który ScrumMaster lub lider techniczny wysyïaï do klienta, musiaï byÊ wczeĂniej wnikliwie przeanalizowa- ny i autoryzowany przez kierownika projektu. Z aptekarskÈ wrÚcz „precyzjÈ” 5 J. Tischner, Historia filozofii po góralsku, Znak, Kraków 1997. 6 J. Tischner, MyĂlenie wedïug wartoĂci, Znak, Kraków 2000, s. 412 – 413.  24 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. „kwe- stii 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 sta- nie 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 pro- dukcji 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 poja- wia 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 ta- kich „gagatków” do pracy w naszej firmie. Dla kierownika, który swojÈ inspi- racjÚ 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 wzo- rujÈ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ĝ do- staniemy projekt do rÚki, rzucamy siÚ w wir pracy, najczÚĂciej nie majÈc odpowiedniej iloĂci czasu na planowanie, analizÚ nowych metod i techno- logii, na szkolenia, czytanie fachowych ksiÈĝek, na wspólne dyskusje o pro- blemach. 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 http://www.imdb.com/title/tt0081505/ (dostÚp: 3 maja 2012). 25  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 esty- macyjnych 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 naj- pierw siÚ zastanowiÊ, jak to zrobiÊ. SpotkaÊ siÚ, pogadaÊ, pomyĂleÊ nad roz- wiÈ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 re- guï linii produkcyjnej wyjĂÊ z kryjówek. Kryjówka ma jakiĂ próg, który trzeba przekroczyÊ. Próg znaczy koniec kry- jówki i poczÈtek nowej przestrzeni. JeĂli siÚ widzi koniec, a nie widzi siÚ po- czÈtku, bÚdzie siÚ mimo wszystko wiÚcej kochaÊ zïudzenie niĝ prawdÚ8. Jaki poczÈtek proponujÈ metody agile? Przede wszystkim dziÚki itera- cyjnej 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 so- bie oglÈdnÈÊ, nacieszyÊ siÚ nim — zgïosiÊ swoje zastrzeĝenia oraz zapropono- waÊ nowe pomysïy. To jest duĝa siïa tego podejĂcia. PamiÚtam, ĝe jako poczÈt- kujÈ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. 427.  26 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Ú wyma- gania i pierwotny zakres prac poszerzyï siÚ o trzy nowe funkcjonalnoĂci. Mu- szÚ 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 sen- sie 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 pro- jektu, 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 odwrotnie9. 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 wszy- scy, 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. 7. 27  SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI i zasïynÈï jako „flop Fosbury’ego”. Dick skoczyï wyĝej niĝ ktokolwiek przed- tem, 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 naj- bardziej 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 pod- stawie. 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 odbu- dowania wizerunku firmy Apple po fiasku sprzed poprzednich lat. Nie jestem specem od marketingu, ale dla mnie byïa to najbardziej innowacyjna seria re- klam, jakie kiedykolwiek widziaïem. Na ekranie pojawiaïy siÚ, sprytnie zmon- towane, czarno-biaïe migawki bohaterów, wynalazców, myĂlicieli i buntowni- ków. MogliĂmy tam zobaczyÊ Alberta Einsteina, który pali fajkÚ, Boba Dylana grajÈcego na harmonijce, Martina Luthera Kinga wygïaszajÈcego swoje naj- sïynniejsze kazanie: I Have a Dream (Mam marzenie), Richarda Bransona po- trzÈsajÈcego butelkÈ szampana, tañczÈcÈ MarthÚ Graham, peïnÈ pokoju twarz Mahatmy Ghandiego czy malujÈcego Picassa. Tym wszystkim obrazom towa- rzyszyï 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 [tïum. fragmentu: M. Chrapko].  28 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 zga- dzaÊ siÚ z nimi, gloryfikowaÊ ich albo szkalowaÊ. Tylko zignorowaÊ ich nie moĝesz. Bo oni zmieniajÈ Ăwiat. PopychajÈ ludzkoĂÊ do przodu. I chociaĝ nie- któ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 po- czÈ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 pro- wadzenia projektów. W lipcu 2007 r. portal CNN Money przeprowadziï ankietÚ, na podstawie której wyïoniï listÚ piÚÊdziesiÚciu najbardziej wpïy- wowych ludzi, idei, trendów, produktów — tego, co zmieniïo bieg Ăwiata biznesu12. 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 opro- gramowania, 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, http://www.youtube.com/watch?v=4oAB83Z1ydE (dostÚp: 3 maja 2012) [tïum. fragmentu: M. Chrapko]. 12 The 50 Who Matter Now, CNN Money, http://money.cnn.com/galleries/2007/ biz2/0706/gallery.50whomatter.biz2/33.html (dostÚp: 3 maja 2012). 29  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 sys- tematyzowaÊ metody agile. To wtedy, w 1986 r., zaczyna byÊ gïoĂno o me- todzie Scrum; zostaje opracowana Dynamic Systems Development Metho- dology (1994 r.); Kent Beck nazywa praktyki Extreme Progamming (1996 r., choÊ prawdziwy boom tej metody to 2000 r.); Alistar Cockburn mówi o meto- dach 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 opra- cowany 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: http://agilemanifesto.org/). 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 projek- tów majÈ ludzie zaangaĝowani w ich rozwój. Czynnik ludzki jest elementem,  30 MYŚLENIE ODWROTNE którego bardzo brakuje we wszystkich modelach i standardach zaawanso- wanych 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 uwy- datniaï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 spo- só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 prowa- dzone przy okazji róĝnego rodzaju wdroĝeñ — rozmowy z programistami, którzy narzekali na prowadzenie i utrzymywanie dokumentacji w ich pro- jektach. 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 tymcza- sem klienta i tak interesuje dziaïajÈcy software, który jest wolny od defek- tó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ï finanso- wy 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  SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI Reagowanie na zmiany ponad trzymaniem się planu Osoby, które kiedykolwiek miaïy do czynienia z tradycyjnymi metodami two- rzenia 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 „wrzut- ki” 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 ele- mentem naszych prac wytwórczych. OczywiĂcie to nie oznacza, ĝe nasze projekty nie powinny mieÊ planu i ĝe planowanie jest niepotrzebne. Prze- ciwnie! Plan musi byÊ. Jednak kaĝdorazowo jest on dopasowywany do zmie- niajÈcych siÚ warunków Ărodowiskowych. Podstawowe wartoĂci manifestu zostaïy dodatkowo wzbogacone o 12 za- sad, które moĝna potraktowaÊ, jako swoistÈ listÚ kontrolnÈ zwinnego projektu. Moĝna siÚ z nimi zapoznaÊ na wspominanej juĝ stronie: http://agilemanifesto.org/.  32 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 D 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 335  SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI Dunbar Robin, 165 duration, Patrz: czas trwania Dynamic Systems Development Methodology, Patrz: DSDM E 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 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 Inĝynier, 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  336 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 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 inĝynier wymagañ, 134, 135, 138, 139 inĝynieria 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 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 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 Ł ï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 SKOROWIDZ 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 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  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 Q QSM, 115 Quantitative Software Management, Patrz: QSM R 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  338 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, 21 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 SKOROWIDZ 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, wydobywanie, Patrz: elicitation wykres spalania, 233, 234, 236, 270, 271, 231, 232 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  SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI  340
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Scrum. O zwinnym zarządzaniu projektami
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ą: