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. [phone]
e-mail: [e-mail]
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ść

3

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

17

Wodospad

18

Pan Samochodzik i tworzenie oprogramowania

23

Ludzie z kryjówek

24

Wychodzenie z kryjówki

26

Mylenie odwrotne

27

Zdrowie szaleców

28

Manifest agile

29

2.

LEKCJE PŁYWANIA.

O zwinnym zarządzaniu projektami

33

Klasyka i jazz

33

Piankowe wyzwanie

40

Dama z asiczk

42

Agile i pornografia

44

Scrum

48

Lekcje pywania

50

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

4

3.

KONTRABASISTA.

Nowe role i obowiązki

53

Lekcja z Kontrabasisty

53

ScrumMaster

54

Cechy dobrego ScrumMastera

58

Wybór ScrumMastera

66

W duej organizacji

68

Waciciel Produktu

69

Czy kierownik projektu jest potrzebny w Scrumie?

82

4.

ŁAWA PRZYSIĘGŁYCH.

O hodowaniu zwinnych zespołów projektowych

97

Ugotowani

97

Zespó = nirwana projektu

99

Szlachetny cel

103

Uprawa zwinnych zespoów

105

Wielofunkcyjne zespoy

120

Zespoy komponentowe

121

awa przysigych

124

5.

PLATON, IDEE I RYBY.

Jak zwinnie zarządzać wymaganiami?

131

Jaszczurka czy dinozaur?

131

Diabe tkwi w... komunikacji

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

203

Obsesja planowania

203

Zwinne planowanie

204

eglowanie i obieranie cebuli

206

Jak si do tego zabra?

208

Kup książkę

Poleć książkę

SPIS TREŚCI

5

Plan wydania

227

Planowanie na du skal

229

Jak ledzi postp prac?

233

8.

BIEGNIJ, FORREST, BIEGNIJ.

Sprint

239

Jak na nartach po Barcelonie

239

Planowanie sprintu

240

Plan sprintu

253

Gotowi!… Do startu!… Gotowi?!

254

W duych projektach

256

Zrobione czy niezrobione?

260

Puste taczki

262

Komunikacja

265

ledzenie postpu prac

267

9.

W POKOJU SZTABOWYM.

Codzienne scrumy

273

Wniosek o zakoczenie wojny

273

Codzienny scrum

278

Jak si komunikowa?

290

Zespoy rozproszone

293

Scrum of Scrums

297

10.

FURTKA DO OGRODU.

O tym, jak zorganizować przegląd sprintu

301

W sklepie z zabawkami

301

Przegld sprintu

302

Metoda Kawasakiego

304

Zaraa dobr energi

305

Furtka do ogrodu

306

Atak na Ziemian

307

11.

MYŚLODSIEWNIA.

Retrospektywa na koniec sprintu

309

Mylodsiewnia

309

Oczyszczenie

310

Najczciej pomijana praktyka

311

Lekcja anatomii

312

Próba ogarnicia kuwety

321

12.

WSPÓLNY REJS.

Historia z morza wzięta

331

SKOROWIDZ

335

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

6

Kup książkę

Poleć książkę

17

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: 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 wodo-
spadu. 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 opisa-
na 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

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

18

skróci drog, tym samym szybciej dotrze do zamierzonego celu. Do ko-
go, 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 (wyma-
gania biznesowe), ebymy mogli myle o specyfikacji technicznej. Dopiero
kiedy ju mamy te dwa etapy za sob, moemy rozpocz prace architekto-
niczne i zaj si dokumentacj wybranych rozwiza. 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 hutawki

1

.

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 moliwo-
ci, dodatkowo biorc pod uwag fakt, e nie suyem w SAS 21, z pewno-
ci 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 katali-
zatorem, 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 linio-
wo (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 (wyma-
gania biznesowe), potem tumaczy si je na jzyk zrozumiay dla programi-
stów (wymagania funkcjonalne), eby z kolei, na ich podstawie, mona

1

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

Kup książkę

Poleć książkę

MYŚLENIE ODWROTNE

19

byo zaprojektowa okrelone rozwizania techniczne (projekt systemu).
Kolejna faza to implementacja wybranych rozwiza, które s: integrowa-
ne, 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. Wyobracie sobie sytuacj, e skoczylicie prace zwi-
zane 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 nie-
prawdopodobny wrcz sposób. Scena ywcem wyjta z Incepcji Christophera
Nolana

2

. 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).

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

20

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 trak-
cie 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 jed-

nej fazy do drugiej. Wyobracie sobie np., e na etapie testów systemowych
nagle dowiadujecie si, e okrelone rozwizanie zostao le zaprojektowa-
ne 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. Paku-
jemy si: piwór, karimata, ubrania, rczniki (oczywicie wszystko razy kilka,
chyba e nie bierzemy ony i dzieci), buty, kosmetyczka, latarka, zapaki, sa-
perka, 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 wyobra-
zi, 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 fa-
z 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 im-
plementuj przyjte wczeniej rozwizania, a wyniki swoich prac przeka-
zuj 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

Kup książkę

Poleć książkę

MYŚLENIE ODWROTNE

21

pracami utrzymaniowymi. Proces ten przypomina troch acuch pokar-
mowy, 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 uwielbia-
jcego 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 wyma-
ga klienta) s „zjadane” przez zespó projektantów („zjadajcych”), które
z kolei dostarczaj cennego poywienia (projekt systemu) zespoom programi-
stów. acuszek ten zamyka si na etapie, kiedy klient konsumuje „gotowy
produkt”. W przyrodzie acuchy pokarmowe s dugie i wzajemnie po-
przeplatane — tworz sieci rónego rodzaju zalenoci pokarmowych. I to
jest co, co nie jest brane pod uwag w podejciu kaskadowym. Tam bo-
wiem 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

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

22

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 dobro-
wolnie, jak i ci, tacy jak ja, dostali si do zabawy z „apanki” — mieli utwo-
rzy koo i kolejno podawa sobie ma yeczk do herbaty. W tym czasie
zespó pastwi si nad wesoymi weselnikami, grajc skoczne „umpa... um-
pa...”, 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 okna

3

.

Winston Royce, który jako pierwszy w artykule Managing the Development of

Large Software System (1970) opisa model kaskadowy, powiedzia bardzo
ciekaw rzecz: „Podoba mi si ten pomys, ale jego implementacja jest ry-
zykowna 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 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 (dostp: 3 maja 2012).

Kup książkę

Poleć książkę

MYŚLENIE ODWROTNE

23

Pan Samochodzik i tworzenie oprogramowania

Metody agile powstay jako reakcja na zaoenie, które od samego pocztku
byo gboko zakorzenione w inynierii oprogramowania: „proces tworze-
nia 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 alterna-
tywnym rozwizaniem wobec dotychczasowej produkcji rzemielniczej i jej
utworzenie stanowio niekwestionowan zasug amerykaskiego koncer-
nu 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 zarzdza-
nia ludmi. 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 wehi-
kuu, zbudowanego na bazie rozbitego Ferrari 410 Superamerica. Jako meneder
odpowiadasz za lini produkcyjn. Natychmiast eliminujesz wszystkie po-
jawiajce 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 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.

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

24

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 klu-
czow 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 pro-
dukcji moe prowadzi do postaw zupenie odwrotnych — stumienia ini-
cjatywy, braku odwagi w wyraaniu swoich opinii i pomysów, chowania si
do „kryjówek”, z których nie trzeba si zbytnio wychyla, eby przey ko-
lejny dzie w pracy.

Ludzie z kryjówek

Poniewa prywatnie zawsze byem i dalej jestem „fanatykiem” filozofii w ka-
dym wydaniu, przytocz krótki fragment Mylenia wedug wartoci ks. Józefa
Tischnera (na pewno kojarzycie jego kultow ju dzisiaj Filozofi po góralsku

5

,

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. Wpraw-
dzie w kryjówce nadzieja nie znika bez reszty, tylko maleje, ale maleje do tego
stopnia, e staje si jedynie nadziej przetrwania

6

.

Styl zarzdzania, który próbuje odzwierciedla wiat produkcji, „spy-

cha” 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, ra-
diowe i telewizyjne w PRL-u. Kady e-mail, który ScrumMaster lub lider
techniczny wysya do klienta, musia by wczeniej wnikliwie przeanalizowa-
ny 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.

Kup książkę

Poleć książkę

MYŚLENIE ODWROTNE

25

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. „kwe-
stii politycznych”, wic nie bdzie z tego wzgldu ryzykowa kontraktu
z klientem, który jest jego jedyn „dojn krow”. Niestety nie byem w sta-
nie 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 pro-

dukcji jest zabijanie indywidualnoci. Przez „indywidualist” rozumiem
osob majc swoje zdanie, kreatywn, patrzc 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ó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ówi

7

.

Ostatni rzecz, o której chciabym wspomnie w kontekcie tradycyjnego

stylu zarzdzania, jest koncentracja na realizacji zada. W zarzdzaniu wzo-
rujcym 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 do-
staniemy projekt do rki, rzucamy si w wir pracy, najczciej nie majc
odpowiedniej iloci czasu na planowanie, analiz nowych metod i techno-
logii, na szkolenia, czytanie fachowych ksiek, na wspólne dyskusje o pro-
blemach. 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).

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

26

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 esty-
macyjnych 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 naj-
pierw si zastanowi, jak to zrobi. Spotka si, pogada, pomyle nad roz-
wizaniem. 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 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 pocztek nowej przestrzeni. Jeli si widzi koniec, a nie widzi si po-
cztku, bdzie si mimo wszystko wicej kocha zudzenie ni prawd

8

.

Jaki pocztek proponuj metody agile? Przede wszystkim dziki itera-

cyjnej metodzie pracy, w której projekt podzielony jest na kilka mniejszych
kawaków (iteracji), akceptuj „prawo” czonków zespoów do robienia b-
dó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 so-
bie ogldn, nacieszy si nim — zgosi swoje zastrzeenia oraz zapropono-
wa nowe pomysy. To jest dua sia tego podejcia. Pamitam, e jako poczt-
kujcy 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.

Kup książkę

Poleć książkę

MYŚLENIE ODWROTNE

27

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 wyma-
gania i pierwotny zakres prac poszerzy si o trzy nowe funkcjonalnoci. Mu-
sz 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 sen-

sie 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 pro-
jektu, 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 odwrotnie

9

. 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 wszy-
scy, 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.

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

28

i zasyn jako „flop Fosbury’ego”. Dick skoczy wyej ni ktokolwiek przed-
tem, 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 skr-
cali sobie karków przy ldowaniu”. A jednak.

Zdrowie szaleńców

Ludziom, którzy myleli odwrotnie, bya w caoci powicona jedna z naj-
bardziej 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 pod-
stawie. Stwierdzilimy wic: „Dobra, powiemy im, kim s nasi bohaterowie”

10

.

O kampanii Think Different mówi si czsto, e przyczynia si do odbu-

dowania wizerunku firmy Apple po fiasku sprzed poprzednich lat. Nie jestem
specem od marketingu, ale dla mnie bya to najbardziej innowacyjna seria re-
klam, jakie kiedykolwiek widziaem. Na ekranie pojawiay si, sprytnie zmon-
towane, czarno-biae migawki bohaterów, wynalazców, mylicieli i buntowni-
ków. Moglimy tam zobaczy Alberta Einsteina, który pali fajk, Boba Dylana
grajcego na harmonijce, Martina Luthera Kinga wygaszajcego swoje naj-
synniejsze kazanie: I Have a Dream (Mam marzenie), Richarda Bransona po-
trzsajcego butelk szampana, taczc Marth Graham, pen pokoju twarz
Mahatmy Ghandiego czy malujcego 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 [tum. fragmentu: M. Chrapko].

Kup książkę

Poleć książkę

MYŚLENIE ODWROTNE

29

Zdrowie szaleców. Odmieców. Buntowników. Wichrzycieli. Okrgych ko-
ków w kwadratowych dziurach. Tych, którzy patrz na wszystko inaczej. Nie
lubi regu. Nie maj szacunku dla status quo. Moesz ich cytowa, nie zga-
dza si z nimi, gloryfikowa ich albo szkalowa. Tylko zignorowa ich nie
moesz. Bo oni zmieniaj wiat. Popychaj ludzko do przodu. I chocia nie-
którzy widz w nich szaleców, my widzimy ich geniusz. Bo ludzie na tyle
szaleni, aby myle, e mog zmieni wiat, faktycznie go zmieniaj

11

.

Powstanie zwinnych metod tworzenia oprogramowania od samego po-

cztku byo pewnego rodzaju myleniem odwrotnym do tego wszystkiego, co
dziao si w inynierii oprogramowania od jej powstania. Idee zwinnoci kie-
koway 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 pro-
wadzenia projektów. W lipcu 2007 r. portal CNN Money przeprowadzi
ankiet, na podstawie której wyoni list pidziesiciu najbardziej wpy-
wowych ludzi, idei, trendów, produktów — tego, co zmienio bieg wiata
biznesu

12

. 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 opro-
gramowania, 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).

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

30

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 sys-
tematyzowa metody agile. To wtedy, w 1986 r., zaczyna by gono 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 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 opra-
cowany 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 projek-
tów maj ludzie zaangaowani w ich rozwój. Czynnik ludzki jest elementem,

Kup książkę

Poleć książkę

MYŚLENIE ODWROTNE

31

którego bardzo brakuje we wszystkich modelach i standardach zaawanso-
wanych 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 uwy-

datniay wpyw tego czynnika — czy to na poziomie ycia organizacji, czy
w porzdkowaniu rónego rodzaju dziaa projektowych. Oczywicie umo-
liwia wprowadzenie okrelonych zwinnych praktyk, które promuj prac
zespoow, 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ę

Czytajc to stwierdzenie manifestu, przypominam sobie rozmowy prowa-
dzone przy okazji rónego rodzaju wdroe — rozmowy z programistami,
którzy narzekali na prowadzenie i utrzymywanie dokumentacji w ich pro-
jektach. 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 tymcza-
sem klienta i tak interesuje dziaajcy 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 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 finanso-
wy 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 ka-
dym etapie prac rozwojowych. Praca programistów zaley bardzo mocno
od informacji zwrotnej, któr dostarcza klient.

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

32

Reagowanie na zmiany ponad trzymaniem się planu

Osoby, które kiedykolwiek miay do czynienia z tradycyjnymi metodami two-
rzenia 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 po-
dan rzecz. Moglimy przey brak kawy w firmie, ale nie kolejne „wrzut-
ki” 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 ele-
mentem naszych prac wytwórczych. Oczywicie to nie oznacza, e nasze
projekty nie powinny mie planu i e planowanie jest niepotrzebne. Prze-
ciwnie! Plan musi by. Jednak kadorazowo jest on dopasowywany do zmie-
niajcych si warunków rodowiskowych.

Podstawowe wartoci manifestu zostay dodatkowo wzbogacone o 12 za-

sad, które mona potraktowa, jako swoist list kontroln zwinnego projektu.
Mona si z nimi zapozna na wspominanej ju stronie: http://agilemanifesto.org/.

Kup książkę

Poleć książkę

335

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

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

336

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

Kup książkę

Poleć książkę

SKOROWIDZ

337

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

Ł

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

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

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

338

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

Kup książkę

Poleć książkę

SKOROWIDZ

339

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

Kup książkę

Poleć książkę

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

340

Kup książkę

Poleć książkę