Autor oraz Wydawnictwo HELION dołożyli wszelkich starań ...Pan Samochodzik i tworzenie...

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ściani 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ściza ewentualne szkody wynikłe z wykorzystania informacji zawartych w książce.

Redaktor prowadzący: Ewelina BurskaIlustracje: Ola BułhakProjekt okładki: Ola Bułhak

Wydawnictwo HELIONul. Kościuszki 1c, 44-100 GLIWICEtel. 32 231 22 19, 32 230 98 63e-mail: [email protected]: 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/scrum2Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

ISBN: 978-83-246-2519-2

Copyright © Helion 2015

Printed in Poland.

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

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

http://helion.pl/rt/scrum2http://helion.pl/rf/scrum2http://helion.pl/ro/scrum2http://helion.plhttp://ebookpoint.pl/r/4CAKF

3

SPIS TREŚCI

O AUTORZE 7

PODZIĘKOWANIA 9

WSTĘP DO DRUGIEGO WYDANIA 13

WPROWADZENIE 17

ZAMIAST WSTĘPU 19

1 MYŚLENIE ODWROTNE. Czym jest agile? 21Szko a przetrwania 21Wodospad 22Pan Samochodzik i tworzenie oprogramowania 27Ludzie z kryjówek 28Wychodzenie z kryjówki 30My lenie odwrotne 31Zdrowie szale ców 32Manifest agile 33

2 LEKCJE PŁYWANIA. O zwinnym zarządzaniu projektami 37Klasyka i jazz 37Piankowe wyzwanie 44Dama z asiczk 46Agile i pornografia 48Scrum 52Lekcje p ywania 58

Poleć książkęKup książkę

http://onepress.pl/rf/scrum2http://onepress.pl/rt/scrum2

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

4

3 KONTRABASISTA. Nowe role i obowiązki 61Lekcja z Kontrabasisty 61Scrum Master 62Cechy dobrego Scrum Mastera 67Wybór Scrum Mastera 74W du ej organizacji 77W a ciciel Produktu 77Czy kierownik projektu jest potrzebny w Scrumie? 91

4 ŁAWA PRZYSIĘGŁYCH. O hodowaniu zwinnych zespołów projektowych 107Ugotowani 107Zespó = nirwana projektu 109Szlachetny cel 113Uprawa zwinnych zespo ów 115Wielofunkcyjne zespo y 130Zespo y komponentowe 131

awa przysi g ych 134

5 PLATON, IDEE I RYBY. Jak zwinnie zarządzać wymaganiami? 141Jaszczurka czy dinozaur? 141Diabe tkwi w… komunikacji 143Historyjki u ytkownika 150ZaINWESTuj w dobre historyjki 157Rejestr produktu i ocean plazmy 168Historyjki, epiki, tematy… thriller 170Wymagania jak góra lodowa 171Piel gnacja 172Praca z du ym rejestrem 174Tylko 150, reszta nie ma znaczenia 175

6 LIZANIE ZNACZKÓW I CHIRURGIA MÓZGU. Szacowanie projektów w Scrumie 177Kadzid owy dym, ekstatyczny trans 177O istocie szacowania 178W punktach czy w osobodniach? 200Troch techniki i cz owiek… si nie gubi 205

7 O ŻEGLOWANIU I OBIERANIU CEBULI. Planowanie projektów w Scrumie 215Obsesja planowania 215Zwinne planowanie 216

eglowanie i obieranie cebuli 218Jak si do tego zabra ? 220



SPIS TREŚCI

5

Plan wydania 239Planowanie na du skal 241Jak ledzi post p prac? 245

8 BIEGNIJ, FORREST, BIEGNIJ. Sprint 251Jak na nartach po Barcelonie 251Planowanie sprintu 252Plan sprintu 265Gotowi!… Do startu!… Gotowi?! 266W du ych projektach 268Zrobione czy niezrobione? 272Puste taczki 274Komunikacja 277

ledzenie post pu prac 279

9 W POKOJU SZTABOWYM. Codzienne scrumy 285Wniosek o zako czenie wojny 285Codzienny scrum 290Jak si komunikowa ? 302Zespo y rozproszone 305Scrum of Scrums 309

10 FURTKA DO OGRODU. O tym, jak zorganizować przegląd sprintu 313W sklepie z zabawkami 313Przegl d sprintu 314Metoda Kawasakiego 316Zara a dobr energi 317Furtka do ogrodu 318Atak na Ziemian 319

11 MYŚLODSIEWNIA. Retrospektywa na koniec sprintu 321My lodsiewnia 321Oczyszczenie 322Najcz ciej pomijana praktyka 323Lekcja anatomii 324Próba ogarni cia kuwety 333

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

SKOROWIDZ 347




6



21

1MYŚ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 przetrwaniaJestem wielkim fanem Beara Gryllsa, bohatera programu telewizyjnego emi-towanego przez Discovery Channel — Ultimate Survival (polski tytu : Szko aprzetrwania). Dzielny Bear, podró nik i by y o nierz s u b specjalnych SAS21 (Special Air Service), uzbrojony jedynie w nó , manierk , krzesiwo i ubranie,pokazuje, jak przetrwa w absolutnie ekstremalnych warunkach. Pami tamjeden z odcinków (w a ciwie chyba by to pilot pierwszego sezonu), który bykr 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 rodkiemwodospadu. Je li kto z Was widzia ten odcinek, to wie, e Bear pokony-wa go troch „na raty”. Najpierw pierwszy etap — doj cie do wodospadu.Potem drugi — zdobycie ma ej pó ki skalnej, oczywi cie niewidocznej zewzgl du na ogromn mas lodowatej wody, wpadaj cej wprost na Beara.Kolejny moment to zej cie na pó k skaln , ale jak? Za pomoc drabinkizrobionej z linek paralotni, na której nasz bohater wyl dowa na pocz tkuprogramu. I wreszcie ostatni etap — skok z kilku metrów do uj cia rzeki. My l ,e opisana scena „pokonywania wodospadu” bardzo dobrze pokazuje pu ap-

k , w jak wpada wi kszo z nas, stosuj c dobrze znany wszystkim tzw. wa-terfall 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




22

znacznie skróci drog , tym samym szybciej dotrze do zamierzonego celu.Do kogo , kto nie ma du ego do wiadczenia w rozwijaniu oprogramowania,taki argument mo e faktycznie trafia . Opiera si przecie na bardzo logicznychprzes ankach — najpierw musimy wiedzie , czego chce od nas klient (wyma-gania biznesowe), eby my mogli my le o specyfikacji technicznej. Dopierokiedy 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, retesty i —uwaga! — Wielki Fina , czyli demonstracja efektów naszej pracy klientowi, któ-ry dostaje opon zawieszon na linie zamiast wymarzonej hu tawki1.

Tak sobie my l , e gdybym ja, podobnie jak Bear Grylls, zosta rzuconyna pastw losu i musia przetrwa w najdzikszych miejscach na wiecie, napewno 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 nanabawienie si hipotermii od lodowatej wody. Metody agile (z ang. zwinny)to szybka droga do celu, która omija wodospad, bystrza i wszystko, co mo esi zdarzy po drodze.

WodospadZ powstaniem zwinnych metod tworzenia oprogramowania by o troch tak,jak z powstaniem ycia na Ziemi. Ich podstawowe idee, wyznawane warto cii zasady ewoluowa y wraz z dyscyplin in ynierii oprogramowania, a wi cod pocz tku jej istnienia (prze om lat 50. i 60. XX w.). Niew tpliwym katalizato-rem, który przyczyni si do ich rozwoju, by wiat tradycyjnych metod wy-twórczych, które najpe niej definiuje podej cie zwane kaskadowym (od ang.waterfall). Polega na tym, e aktywno ci projektowe realizowane s liniowo(sekwencyjnie) — p yn niczym Nil, tworz c imponuj ce kaskady wodne (dwiez nich maj posta pot nych wodospadów, nazywanych Ripon i Owena). Cyklycia projektu dzielony jest na okre lone fazy, które wzajemnie od siebie

zale . Najpierw ustalane s potrzeby klienta (wymagania biznesowe), po-tem t umaczy si je na j zyk zrozumia y dla programistów (wymaganiafunkcjonalne), eby z kolei, na ich podstawie, mo na by o zaprojektowa

1 http://www.projectcartoon.com/cartoon/32 (dost p: 23 wrze nia 2014).



MYŚLENIE ODWROTNE

23

okre lone rozwi zania techniczne (projekt systemu). Kolejna faza to imple-mentacja wybranych rozwi za , które s integrowane, testowane i utrzy-mywane (ang. maintenance) w wyniku wdro enia. Zwró cie uwag na to, eka 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 metodykaskadowej, z którymi sam, jako pocz tkuj cy kierownik projektu, musia emsi 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. LowLevel Design). Nagle dzwoni klient i mówi, e chcia by troch rozbudowa dwieostatnie funkcjonalno ci, o których rozmawiali cie pi dni temu, i dodatkowodorzuci 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 zgodniez powszechnym prawem ci enia, a czasoprzestrze zakrzywia si w nie-prawdopodobny wr cz sposób. Scena ywcem wyj ta z Incepcji ChristopheraNolana2. Chcia oby si w ama przez sen do wiadomo ci klienta i zaszczepimu ide cierpliwego czekania i „niewrzucania” nam dodatkowej roboty. Ale…

2 http://www.imdb.com/title/tt1375666/ (dost p: 23 wrze nia 2014).




24

nie ma sprawiedliwo ci na tym wiecie. Musimy kilka rzeczy przeprojektowa ,przeplanowa i stara si jako podnie morale sfrustrowanego zespo u.Nie trzeba ju chyba dodawa , jak bardzo takie „wrzutki” zwi kszaj kosztyprowadzonego projektu.

Kolejnym problemem, który napotka em przy okazji stosowania modelukaskadowego, jest formalne pozbawienie prawa g osu naszego klienta w trak-cie prowadzenia prac rozwojowych. Celowo napisa em „formalne”, gdyklient i tak kontaktowa si z nami na wiele ró nych sposobów i demonstrowaswoje widzimisi . I nic nie mogli my zrobi . Nie pomaga o alarmowanie o tymproblemie wy szego kierownictwa, które, jak jedna z pluszowych zabawekstoj cych przy wej ciu do Smyka, natr tnie powtarza o: „Takie jest ycie! Do-brze wiesz, e jest to nasz strategiczny partner (czytaj: dojna krowa) i musimyto 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 systemowychnagle 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 narodowisko produkcyjne klienta. W tym momencie Wasze plany bior w eb.

To jest troch tak, jak z wyjazdem na weekendowy biwak na Mazury. Pakuje-my 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, siedemnasta. Jedziemy juoko o dwóch godzin, nagle ona, patrz c b dnym wzrokiem na przeje -d aj ce s siednim pasem auta, pyta: „Krzysiek, a namiot?”. Mo ecie sobiewyobrazi , jaki jest dalszy ci g tej historii. Z modelem kaskadowym jestpodobnie. Im pó niej si zorientujemy, e nie mamy namiotu, tym wi cejnas kosztuje powrót po niego.

W modelu kaskadowym nad sukcesem ka dej fazy czuwa osobny ze-spó , który skupia ludzi o bardzo zbli onych kompetencjach. Na przyk adza faz wymaga odpowiadaj analitycy biznesowi, analitycy systemowioraz in ynierowie wymaga . Na etapie projektowania pierwsze skrzypcegraj projektanci i architekci. Pó niej do gry wchodz programi ci, którzyimplementuj przyj te wcze niej rozwi zania, a wyniki swoich prac prze-kazuj dalej testerom, którzy z kolei sprawdzaj , czy wszystko dzia a zgod-nie z wymaganiami, a wi c z tym, czym zajmowa si pierwszy zespó . Je eliwszystko jest przetestowane, a znalezione b dy poprawione, produkt trafia



MYŚLENIE ODWROTNE

25

w r ce wdro eniowców, a w nast pnej kolejno ci zespo u zajmuj cego sipracami utrzymaniowymi. Proces ten przypomina troch a cuch pokar-mowy, w którym mamy do czynienia z szeregiem ró nych organizmówustawionych w takiej kolejno ci, e ka dy z nich jest ród em po ywienia dlakolejnego. Na rysunku 1.2 bli ej niezidentyfikowana ro lina jest pokarmemdla d d ownicy, któr zjada ze smakiem na niadanie ma y ó wik, b d cyniez 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, jestpierwszym ogniwem a cucha projektowego. Wytwory jego prac (lista wyma-ga klienta) s „zjadane” przez zespó projektantów („zjadaj cych”), którzyz kolei dostarczaj cennego po ywienia (projekt systemu) zespo om programi-stów. a cuszek ten zamyka si na etapie, kiedy klient konsumuje „gotowyprodukt”. W przyrodzie a cuchy pokarmowe s d ugie i wzajemnie po-przeplatane — tworz sieci ró nego rodzaju zale no ci pokarmowych. I tojest co , czego nie bierze si pod uwag w podej ciu kaskadowym. Tambowiem zak ada si p ynne przej cie pomi dzy jedn faz a drug .

Model kaskadowy, przez surowe rozgraniczenie prac wykonywanychprzez ró ne zespo y, powoduje rozmycie odpowiedzialno ci za rozwójproduktu. Ka dy zespó skupia si tylko na swojej dzia ce i w aden sposóbnie czuje si odpowiedzialny za to, co robi zespó kolejny. Ka dy zamyka si




26

w swoim silosie. Przypomina mi to pewn histori . Kilka lat temu by em naweselu 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 okazjiodbywaj . 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 tacy jak ja, którzy dostali si do zabawy z „ apanki” — mieliutworzy ko o i kolejno podawa sobie ma y eczk do herbaty. W tymczasie zespó pastwi si nad weso ymi weselnikami, graj c skoczne „umpa…umpa…”, od czasu do czasu robi c niespodziewane przerwy. I w a nie te„przerwy”, ni z gruchy ni z pietruchy, powodowa y, e cz owiek chcia jaknajszybciej pozby si tej okropnej y eczki i czym pr dzej wcisn j w r ces siada. Jest to postawa, któr wyzwala a zasada tej zabawy, e gdy tylkomuzyka 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 siedniegozespo u — „Niech oni si tym martwi ”. „To nie jest ju nasz problem”. Ilerazy s yszeli cie takie has a w swoim projekcie? Pami tacie, jak nieraz danyproblem (b d, poprawka) by przerzucany mi dzy programistami, testerami,utrzymaniowcami lub osobami z obs ugi klienta? „Przecie my zrobili my totak, jak by o w wymaganiach, to ONI zawalili, nie MY!”. Albo: „MY tego nieb dziemy naprawia , bo my my tego nie robili, to ICH robota”. W modelukaskadowym poszczególne zespo y przypominaj troch monady, o którychmó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 ofLarge Software System (1970) opisa model kaskadowy, powiedzia bardzociekaw rzecz: „Podoba mi si ten pomys , ale jego implementacja jest ry-zykowna i ma tendencj do b dów”4. Jest swoistym paradoksem, e wieleosó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: 23 wrze nia 2014).



MYŚLENIE ODWROTNE

27

Pan Samochodzik i tworzenie oprogramowaniaMetody agile powsta y jako reakcja na za o enie, które od samego pocz tkuby o g boko zakorzenione w in ynierii oprogramowania: „proces tworze-nia oprogramowania jest procesem, który niczym nie ró ni si od procesuprodukcyjnego”. Jest linia produkcyjna, s stanowiska robocze (maszynowe,r czne lub mieszane), pogrupowane wed ug kolejnych operacji procesutechnicznego. Idea „linii produkcyjnej” w momencie powstania by a alterna-tywnym rozwi zaniem wobec dotychczasowej produkcji rzemie lniczej i jejutworzenie 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, eawansowa 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 pracahistoryka sztuki, postanowi wi c zacz masow produkcj pokracznegowehiku u, zbudowanego na bazie rozbitego Ferrari 410 Superamerica. Jako mene-d er odpowiadasz za lini produkcyjn . Natychmiast eliminujesz wszystkiepojawiaj ce si defekty; jeste w ciek y i nie tolerujesz b dów pope nia-nych przez pracowników, którzy obs uguj lini ; traktujesz ich jak kolejnytrybik maszyny, który w razie potrzeby zawsze mo na wymieni na inny;no i jeste mistrzem wszelkich instrukcji — wszystko musi „tyka ” jak w szwaj-carskim zegarku i na wszystko jest standardowa procedura. Aha, jeszczejedno: nie znosisz eksperymentów — nie ma czasu sprawdza , czy co si dawykonywa lepiej, czy nie, to nie jest przecie Twoja rola.




28

Takie podej cie faktycznie ma sens i sprawdza si podczas pracy przylinii produkcyjnej, np. samochodów. Ogromnym b dem jest jednak próbazaaplikowania tego modelu do projektów software’owych, w których klu-czow rol odgrywa tzw. „czynnik ludzki”. To od stopnia zaanga owanialudzi, ich kreatywno ci, umiej tno ci akceptowania problemów, radzeniasobie z konfliktami, zdolno ci komunikacji, pracy w grupie zale y sukcesdanego 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 sido „kryjówek”, z których nie trzeba si zbytnio wychyla , eby prze y ko-lejny dzie w pracy.

Ludzie z kryjówekPoniewa 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ózefaTischnera (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 onie obiecuje cz owiekowi nic wielkiego, pami przesz o ci podsuwa mu przedoczy 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 tegostopnia, 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 czynieniaz sytuacj , gdy kierownik zawsze bra sprawy w swoje r ce w obawie o Waszekompetencje. Wspó pracowa em kiedy z firm , w której spotka em si z dokomiczn sytuacj , a przypomina a mi ona dawne dzia ania G ównego Urz duKontroli Prasy, Publikacji i Widowisk cenzuruj cego publikacje prasowe, ra-diowe i telewizyjne w PRL-u. Ka dy e-mail, który Scrum Master lub lidertechniczny 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.



MYŚLENIE ODWROTNE

29

kierownik studiowa ka d wiadomo , która wychodzi a poza firm , i nanosikluczowe — jak twierdzi — poprawki. Kiedy zapyta em go, dlaczego to robi.Szybko dosta em odpowied , e jego ludzie nie maj wyczucia tzw. „kwestiipolitycznych”, wi c nie b dzie z tego wzgl du ryzykowa utraty kontraktuz 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ó niejprzejd do defensywy i przestan wykazywa jak kolwiek wol twórczegodzia ania. Bo, koniec ko ców, po co podejmowa takie dzia anie, skorozawsze 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 ” rozumiemosob 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 gdy ju przyjdzie, to wszystko, co robi, traktujejako rodek do samopodniety. Obecno tego rodzaju ludzi w zespole projek-towym jest bardzo destruktywna i trzeba dobrze si zastanowi , zanim zatrud-nimy takich „gagatków” do pracy w naszej firmie. Dla kierownika, który swojinspiracj czerpie z linii produkcyjnej, programista-indywidualista jest tylkoró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 tradycyjnegostylu 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, jakco zrobi . Zadania musz by wykonywane mechanicznie, eby ze wszystkimzd 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 codpowiedniej 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 ejkorporacji z, wydawa oby si , uporz dkowan struktur i tzw. „dojrza ymadem organizacyjnym”. Jednym z zada , do których zosta em zatrudniony,

7 http://www.imdb.com/title/tt0081505/ (dost p: 23 wrze nia 2014).




30

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 technikestymacyjnych. Pocz tkowo wszystko sz o jak po ma le. Zespó z Polski bardzoszybko si wdro y . Wspólnie przygotowali my kilka arkuszy estymacyjnychdo wcze niej z o onych zamówie . I tu zacz y si schody. Nasi niemieccykoledzy nie mogli zrozumie , dlaczego w wycenie uwzgl dnili my analizrozwi za architektonicznych, czas sp dzony na telekonferencjach, a tak ezrobienie prototypu sprawdzaj cego jedno z mo liwych rozwi za . Ta fir-ma w ogóle nie bra a pod uwag , e zanim co zrobimy, musimy najpierw sizastanowi , jak to zrobi . Spotka si , pogada , pomy le nad rozwi zaniem.Nie da si ludzi podpi do klawiatury i kaza im pisa kod.

Wychodzenie z kryjówkiAgile 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 mniejszychkawa 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 realizacjiWaszych 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. Jestrzecz zupe nie normaln , e cz sto zmienia si kierunek prac rozwojowych.Klient co kilka tygodni dostaje fragment dzia aj cego produktu, mo e go sobieogl dn , nacieszy si nim, zg osi swoje zastrze enia oraz zaproponowanowe pomys y. To jest du a si a tego podej cia. Pami tam, e jako pocz tkuj -cy kierownik projektu, przygotowuj c harmonogram prac na podstawie meto-dyki kaskadowej, zawsze mia em problem ze zmienno ci wymaga . Zbiera-em nawet metryk ledz c ich fluktuacj (Ile pojawi o si nowych? Ile

8 J. Tischner, My lenie wed ug warto ci, dz.cyt., s. 427.



MYŚLENIE ODWROTNE

31

zmieniono starych? Ile te zmiany nas kosztowa y?), a wszystko po to, ebymie „haka” na klienta na wypadek, gdyby przysz o mu do g owy czepiasi nas, e po raz kolejny nie zd yli my z osi gni ciem zaplanowanegokamienia 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 stosowazwinne 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 stosowanymmetodom i narz dziom tworz co , co mogliby my nazwa demokratycznymstylem zarz dzania. Kierownik projektu nie jest ju „królem”, który panujenad ludem, niezale nie od uk adów politycznych i systemów. Jest bardziejs ug i mentorem osób, które anga uj si w projekt. Jego rola musi wi c zostaodpowiednio 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 orazkto si nimi zajmie. Rola kierownika musi wi c zosta ustalona na nowo,w kontek cie warto ci i zasad, które przynosi ze sob idea zwinno ci. B dzieo tym wi cej w rozdziale 3., po wi conym rolom w Scrumie.

Myślenie odwrotneMetody agile powsta y w wyniku próby spojrzenia na proces tworzeniaoprogramowania w nieco inny — odwrotny sposób. Na my l przychodzi mitutaj 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óraodby a si w 1986 r. By to czas, kiedy technika skoków wzwy polega a natym, e sportowcy w trakcie skoku „przerzucali” swoje cia o równolegle dopoprzeczki. Na wspomnianej olimpiadzie pojawi si , wtedy jeszcze ma oznany zawodnik, Dick Fosbury, który podbieg do poprzeczki ustawionejna rekordowej wysoko ci 2 m 24 cm. Wybi si i zamiast skoczy jak wszy-scy, obróci si do poprzeczki plecami. Unosz c nogi, pokona j ty em. Jegostyl skakania obowi zuje do dzisiaj i zas yn jako „flop Fosbury’ego”. Dick

9 P. Arden, Cokolwiek my lisz, pomy l odwrotnie, t um. O. Siara, Insignis, Kraków

2008, s. 7.




342



347

SKOROWIDZ

AAlbrecht Allan, 197analityk

biznesowy, 83, 89, 130, 144, 145, 148systemowy, 130

Arden Paul, 31Arystoteles, 143, 202Atlassian, 79, 275

BBeck Kent, 34, 151Bezos Jeff, 125b dy, 260, 261Boehm Barry, 184Brass Dick, 74Brown Tim, 123burndown chart, Patrz: wykres spalania

C, Cannon-Brokkes Mike, 275, 276Chambers Harry, 94Chief Architect, Patrz: G ówny ArchitektChief Engineer, Patrz: G ówny In ynierChief Product Owner, Patrz: W a ciciel

Produktu G ównyChief Scrum Master, Patrz: Scrum Master

G ównyci g

Fibonacciego, 208geometryczny, 208

Class Owner, Patrz: W a ciciel Klasy

Cockburn Alistar, 34Codziennik, 306Coelho Paulo, 184Cohn Mike, 157, 167, 190, 217, 272, 297cross-functional teams, Patrz: zespó

wielofunkcyjnyCskiszentmihalyi Mihaly, 140cykl

wytwórczy, 51ycia projektu, Patrz: projekt cykl

yciaczas trwania, 186, 187, 193wiczenie Piankowe wyzwanie, 44

Ddaily scrum, Patrz: scrum codziennyDama z asiczk , 47De Pree Max, 68definicja uko czenia, 273definition of done, Patrz: definicja

uko czenia, kryterium uko czeniapracy

DeLuca Jeff, 34DeMarco Tom, 115Demiurg, 40Derby Esther, 324diagram rybiej o ci Ishikawy, 331dokumentacja, 35Drucker Peter, 95DSDM, 34, 51Dunbar Robin, 175duration, Patrz: czas trwania




348

Dynamic Systems DevelopmentMethodology, Patrz: DSDM

dzie idealny, 188, 201, 202, 203, 204,205, 230, 246, 252

Eeffort, Patrz: pracoch onnoelicitation, 148Entergy, 113entropia, 41, 42entroskop, 41epik, 88, 170, 171, 172, 176, 195, 225, 226, 244estymacja, 30, 124, 163, 179, 181, 195, 199,

200, 203, 206, 207, 211, 234, Patrz te :szacowanie

Extreme Progamming, 34, 49, 50, 151,165, 170

FFarquhar Scott, 276FDD, 50feature team, Patrz: zespó funkcjonalnyFeature-Driven Development, 34,

Patrz: FDDfeng shui, 116Feynman Richard, 104Fforde Jasper, 41Fisher Darin, 79Fosbury Dick, 31Fowler Martin, 151frequent delivery, 52Furman Richard, 277

GGallo Carmine, 314G ówny Architekt, 50G ówny In ynier, 87godzina idealna, 257, 266Goodger Ben, 79Google, 79Google Chrome, 79Google Docs, 306gra innowacyjna, 66Gran Torino, 99Greenleaf Robert, 55, 68grooming, 172, 267, 297

HHamel Gary, 113hand-over, 149Heidegger Martin, 209Heller Micha , 86hermeneutyka, 142historyjka u ytkownika, 64, 90, 151, 157,

159, 168, 170, 171, 176, 208, 210, 212, 221,241, 244, 252, 255, 265, 267, 268, 280

badawcza, 165, 196, Patrz te : spikecechy, 157, 158, 159, 160, 162, 163,

165, 166INVEST, 158karta, 154konfirmacja, 156konwersacja, 155

czenie, 159tworzenie, 164wielko , 164, 189, 198, 221, 268zamykanie, 272

Hobbes Thomas, 156Hohmann Luk, 329homo socius, 143

Iideal day, Patrz: dzie idealnyidealna godzina, Patrz: godzina idealnaidealny dzie , Patrz: dzie idealnyimpediment backlog, Patrz: przeszkoda

rejestrimpediments, Patrz: zespó przeszkodyimplementacja, 23, 24, 38, 130, 273inkrement, 48Innovation Games, 329inspekcja kodu, 64, 73, 124integrowanie, 23interesariusz, 40, 42, 82, 179, 277, 319INVEST, 158in ynier wymaga , 144, 145, 148, 149in ynieria oprogramowania, 22iteracja, 48, 55, 315, Patrz te : sprint

JJacobellis Nick, 48Jaspers Karl, 49, 99Jeffries Ron, 154



SKOROWIDZ

349

JIRA, 79, 275, 282Jobs Steve, 32, 81, 313, 317

Kkampania Think Different, 32Kanban, 51Kawasaki Guy, 316Kennedy John Fitzgerald, 80kierownik projektu, 63, 71, 77, 89, 90, 91,

92, 93, 95, 96, 97, 103, 115, 122, 124, 179,280, 290

kierownik projeku, 206klika, 112, 114kod

flagowy MKS, 272inspekcja, Patrz: inspekcja kodu

komunikacja, 143, 144, 277, 302, 305niewerbalna, 144, 302, 303osmotyczna, 52werbalna, 144

komunikat JA, 337, 338komunikator internetowy, 305konwersacja, 151, 155, 157, 164, 168, 173kryterium

akceptacyjne, 157, 210, 268, 316uko czenia pracy, 56

Kubrick Stanley, 29

L, Larsen Diana, 324lean, 51Lean Manufacturing, 51lejek niepewno ci, 184, 232, 233Lencioni Patrick, 289Leonardo da Vinci, 47liczba Dunbara, 175, 176Line Product Owner, Patrz: W a ciciel

Produktu Liniowylinie kodu, 188Lipnack Jessica, 306lista kontrolna, 156Lister Timothy, 115Low Level Design, Patrz: projekt

niskopoziomowyLowndes Leil, 82ludzie

na kszta t litery I, 129na kszta t litery T, 123, 129, 138

Lumet Sidney, 134a cuch projektowy, 25cznik, 307, 308

Mmaintenance, 23Malle Louis, 48manifest agile, 34Manifest zwinnego tworzenia

oprogramowania, 34, 49Manifesto for Agile Software

Development, 34mapa drogowa, 35McConnell Steve, 184McLuhann Marshall, 305McManus Ray, 52mened er produktu, 77, 83metoda

5W, 331agile, 22, 27, 30, 31, 48, 49, 200, 216, 217Codziennika, Patrz: CodziennikCrystal, 34, 52DSDM, Patrz: DSDMDu ej sali, 271iteracyjna, 30kaskadowa, Patrz: model kaskadowy

cznika, Patrz: cznikScrum, 34, 50, 52, 53, 54, 56

argon, 55zwinna, Patrz: metoda agile

mikrozarz dzanie, 94, 323model

CMMI, 35Kano, 66, 226kaskadowy, 21, 22, 23, 24, 25, 26, 30,

35, 37, 50, 130, 143, 147, 185, 200, 227sekwencyjny, Patrz: model

kaskadowyTukcmana, 66wzgl dnego wa enia Karla

Wiegersa, 66MoSCoW, 51mowa cia a, Patrz: komunikacja

niewerbalnaMozart Wolfgang Amadeusz, 37




350

NNa blacie, Patrz: TriangulacjaNierenberg Gerard, 161Nolan Christopher, 23Nonaka Ikujiro, 138, 139

Oosmotic communication,

Patrz: komunikacja osmotycznaosmotyczna komunikacja,

Patrz: komunikacja osmotycznaosobodzie , Patrz: dzie idealny

PPage Scott, 137, 138Parmenides, 209Penderecki Krzysztof, 43pet project, Patrz: pieszczoszekPichler Roman, 267, 319pieszczoszek, 79Planning Poker, 199, 207, 208, 222planowanie, Patrz: projekt plan, sprint

planowanie, wydanie planowaniedo przodu, 269

Platon, 148Polanyi Michael, 118Poppendieck Mary, 51Poppendieck Tom, 51Popper Karl, 183pracoch onno , 126, 186, 193, 197, 201,

203, 226priorytet, 225, 226, 229, 253, 255, 265, 279priorytetyzacja wymaga , 51proces, 63

empiryczny, 40, 43, 44, 46, 48powtarzalny, 38, 40, 46

product backlog, Patrz: rejestrproduktu

Product Owner, Patrz: W a cicielProduktu

produktrejestr, Patrz: rejestr produktuwydanie, 88

programista, 145, 147, 148, 149, 150, 157,161, 168, 226

programowanie w parach, 73

projektcykl ycia, 22interesariusz, Patrz: interesariuszkaskadowy, 143niskopoziomowy, 23plan, 36, 38, 216, 217przeszkoda, Patrz: przeszkodaryzyko, 228systemu, Patrz: system projektszacowanie, Patrz: szacowaniez o ono , 40, 41zorientowany

na dat , 237, 238na funkcjonalno ci, 239

projektowanieliniowe, 22sekwencyjne, Patrz: projektowanie

liniowepró niactwo spo eczne, 128przekazanie, Patrz: hand-overprzeszkoda, 300, 301

rejestr, 301przywództwo s u ebne, 55, 64, 68punkt, 188, 189, 193, 202, 203, 226, 230,

246, 252, 263funkcyjny, 188, 197

punkty, 200Putnam Doug, 126

QQSM, 125Quantitative Software Management,

Patrz: QSM

Rrefinement, 173rejestr

produktu, 51, 55, 78, 80, 130, 168, 171,172, 176, 220, 221, 244piel gnacja, 172, 173pluralizm, 174

przeszkód, Patrz: przeszkoda rejestrsprintu, 55

Release Kick-Off, 88retrospektywa, 51, 290, 321, 323, 324, 329,

331, 335analiza, 325, 331czas trwania, 338



SKOROWIDZ

351

wiczenia, 326, 329, 334, 335decyzja, 325, 331meble, 339przygotowanie sceny, 325, 326zamkni cie, 325, 333zbieranie danych, 325, 328, 329

Ringelmann Max, 128Robertson James, 148Robertson Suzanne, 148rola projektowa, 50, 61Royce Winston, 26Rubinstein Artur, 38ryzyko, 228, 242

S, samoorganizacja, 95, 96, 97, 103, 140, 280,

302samotranscendencja, 139Schwaber Ken, 62, 67, 265Schwarz Roger, 334scrum

codzienny, 290, 292, 293, 294, 297,302, 306, 307, 308, 309atrybut mówcy, 294czas, 292miejsce, 291, 302na odleg o , 303, 304, 305

rola, 61, 63Scrum Master, 55, 61, 62, 63, 65, 67, 68,

69, 70, 71, 72, 73, 74, 85, 86, 208, 209,212, 226, 283, 291, 294, 299, 300, 301,307, 323, 329, 335, 339

G ówny, 77, 310obowi zki, 65selekcja kandydatów, 75

Scrum of Scrums, 309, 310servant leadership, Patrz: przywództwo

s u ebnesesja piel gnacyjna, Patrz: groomingShipIt Days, 275, 276Skillman Peter, 44Sorensen Ted, 80specjalista, 124, 129specyfikacja

techniczna, 22wymaga , 168

spike, 165, 196

spotkaniecodzienne, Patrz: scrum codziennyprojektowe, 288, 290

sprint, 55, 64, 150, 164, 166, 221, 222, 230,253, 321, Patrz te : wydanie

cel, 254, 266, 315demonstracja, 156d ugo , 223informacja zwrotna, 223planowanie, 172, 219, 252, 256, 258,

262, 265, 267, 268, 271, 277przegl d, 314, 315, 318, 319synchronizacja, 270tablica, 279, 291, 297

zdalna, 281, 292zamykanie, 85

sprint backlog, Patrz: rejestr sprintusprint burndown chart, Patrz: wykres

spalania pracystakeholder, Patrz: interesariuszStamps Jeffrey, 306Sta ko Tomasz, 43Stewart Potter, 48story point, Patrz: punktstrefy czasowe, 307Streisand Barbra, 39Süskind Patrik, 61system

architektura, 24implementacja, Patrz: implementacjakolejkowania pracy, 51projekt, 23, 25

szacowanie, 179, 181, 184, 186, 206, 207,212, 220, 222, 231, 235, Patrz te :estymacja

w czasie idealnym, 200, 201, 205,230, 257

w punktach, 189, 192, 193, 195, 197,198, 200, 202, 203, 205, 230

zwinne, 187, 188, 189, 192, 193, 195,197, 198

rodowisko pracy, 116

Ttablica sprintu, Patrz: sprint tablicatacit knowledge, Patrz: wiedza ukrytaTakeuchi Hirotaka, 138, 139Taylor Cecil, 43




352

telekonferencja, 303, 305temat, 88, 171, 176, 225, 226, 244test

akceptacyjny, 156, 167, 268, 273jednostkowy, 273regresyjny, 224, 273

tester, 145, 147, 149, 150, 226, 281testowanie, 23, 24, 130, 132, 167, 224, 273theme, Patrz: tematThink Different, 32Tischner Józef, 28, 115, 225Tomasz z Akwinu, 209Toyota, 51, 87Triangulacja, 207, 212, 222Truman Harry, 73T-shaped People, Patrz: ludzie na kszta t

litery T

U, Vujawnianie, Patrz: elicitationuser story, Patrz: historyjka

u ytkownikautrzymywanie, Patrz: maintenencevelocity, Patrz: zespó pr dko

WWake William, 157, 163warunki rodowiskowe, 36waterfall model, Patrz: model

kaskadowywa enie relatywne, 226WBS, 30Welch Jack, 146wideokonferencja, 212, 304, 305wiedza ukryta, 57, 118, 119Wiegers Karl, 66Wiegersa model wzgl dnego wa enia, 66wielozadaniowo , 120, 128Witkacy, 46W a ciciel Klasy, 50W a ciciel Produktu, 55, 61, 65, 70, 77, 79,

80, 82, 83, 84, 85, 86, 87, 130, 131, 150,155, 157, 158, 161, 163, 164, 173, 176,200, 208, 210, 212, 219, 220, 225, 226,228, 241, 254, 265, 297, 315, 318

G ówny, 87, 88, 241, 271

Liniowy, 87, 241rekrutacja, 89

Work Breakdown Structure, Patrz: WBSWujec Tom, 44wydanie, 221, 241, Patrz te : sprint

d ugo , 222planowanie, 219, 225, 239, 241, 242,

243, 244wydobywanie, Patrz: elicitationwykres spalania, 245, 299, 306

liniowy, 245pracy, 69s upkowy, 246, 247, 248, 249sprintu, 282, 283

wymagania, 143, 144, 145, 148, 149, 150,151, 156, 160, 168, 172, 179, 182, 200, 206

biznesowe, 22funkcjonalne, 22pozyskiwanie od klienta, 148, 149specyfikacja, 154, 163

YYoung Jeffrey, 81

Z, zadanie, 253, 257, 258, 266, 280, 297, 301

wielko , 259zasada ograniczonego zaufania, 156, 179zespó , 66, 109, 112, 116, 118, 140, 155, 157,

165, 173, 179, 208, 222, 226, 241, 265cel, 113, 114fazy ewolucji, 66funkcjonalny, 50, 130, 131komponentowy, 131, 132, 133pr dko , 70, 159, 170, 201, 209, 222,

230, 231, 241, 252, 253, 254, 255,263, 266, 328

szacowanie, 230, 233, 235przeszkody, 67rozproszony, 155, 305, 306, 307, 308, 309samoorganizuj cy si , 95spotkanie, Patrz: scrum codziennywielko , 125, 126, 127wielofunkcyjny, 130, 135, 138, 139, 200wirtualny, Patrz: zespó rozproszony

argon, 146, 148



http://program-partnerski.helion.pl

Autor oraz Wydawnictwo HELION dołożyli wszelkich starań ...Pan Samochodzik i tworzenie...

Documents

Transcript of Autor oraz Wydawnictwo HELION dołożyli wszelkich starań ...Pan Samochodzik i tworzenie...