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

Szko a przetrwania

17

Wodospad

18

Pan Samochodzik i tworzenie oprogramowania

23

Ludzie z kryjówek

24

Wychodzenie z kryjówki

26

My"lenie odwrotne

27

Zdrowie szale#ców

28

Manifest agile

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

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 du%ej organizacji

68

W a"ciciel 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 zespo y

120

Zespo y komponentowe

121

&awa przysi'g ych

124

5.

PLATON, IDEE I RYBY.

Jak zwinnie zarządzać wymaganiami?

131

Jaszczurka czy dinozaur?

131

Diabe tkwi w... komunikacji

133

Historyjki u%ytkownika

140

ZaINWESTuj w dobre historyjki

147

Rejestr produktu i ocean plazmy

158

Historyjki, epiki, tematy... thriller

160

Wymagania jak góra lodowa

161

Piel'gnacja

162

Praca z du%ym rejestrem

163

Tylko 150, reszta nie ma znaczenia

165

6.

LIZANIE ZNACZKÓW I CHIRURGIA MÓZGU.

Szacowanie projektów w Scrumie

167

Kadzid owy dym, ekstatyczny trans

167

O istocie szacowania

168

W punktach czy w osobodniach?

190

Troch' techniki i cz owiek… si' nie gubi

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* post'p 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 du%ych projektach

256

Zrobione czy niezrobione?

260

Puste taczki

262

Komunikacja

265

-ledzenie post'pu prac

267

9.

W POKOJU SZTABOWYM.

Codzienne scrumy

273

Wniosek o zako#czenie wojny

273

Codzienny scrum

278

Jak si' komunikowa*?

290

Zespo y rozproszone

293

Scrum of Scrums

297

10.

FURTKA DO OGRODU.

O tym, jak zorganizować przegląd sprintu

301

W sklepie z zabawkami

301

Przegl$d sprintu

302

Metoda Kawasakiego

304

Zara%a* dobr$ energi$

305

Furtka do ogrodu

306

Atak na Ziemian

307

11.

MYŚLODSIEWNIA.

Retrospektywa na koniec sprintu

309

My"lodsiewnia

309

Oczyszczenie

310

Najcz'"ciej pomijana praktyka

311

Lekcja anatomii

312

Próba ogarni'cia kuwety

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

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

1

.

Tak sobie my"l', %e gdybym ja, podobnie jak Bear Grylls, zosta rzucony

na pastw' losu i musia przetrwa* w najdzikszych miejscach na "wiecie, na
pewno nie schodzi bym w dó wodospadem. Znaj$c moje fizyczne mo%liwo-
"ci, dodatkowo bior$c pod uwag' fakt, %e nie s u%y em w SAS 21, z pewno-
"ci$ poszuka bym jakiej" innej drogi w dó — niekoniecznie takiej, która
skaza aby mnie na po amanie sobie r$k i nóg na "liskich kamieniach lub na
nabawienie si' hipotermii od lodowatej wody. Metody agile (z ang. zwinny)
to szybka droga do celu, która omija wodospad, bystrza i wszystko, co mo%e
si' zdarzy* po drodze.

Wodospad

Z powstaniem zwinnych metod tworzenia oprogramowania by o troch' tak,
jak z powstaniem %ycia na Ziemi. Ich podstawowe idee, wyznawane warto"ci
i zasady ewoluowa y wraz z dyscyplin$ in%ynierii oprogramowania, a wi'c
od pocz$tku jej istnienia (prze om lat 50. i 60. XX w.). Niew$tpliwym 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).

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

MYŚLENIE ODWROTNE

19

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. WyobraYcie 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
Nolana

2

. Chcia oby si' w ama* przez sen do "wiadomo"ci klienta i zaszczepi*

mu ide' cierpliwego czekania i „niewrzucania” nam dodatkowej roboty. Ale…
nie ma sprawiedliwo"ci na tym "wiecie. Musimy kilka rzeczy przeprojektowa*,

2

http://www.imdb.com/title/tt1375666/ (dost'p: 3 maja 2012).

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

20

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. WyobraYcie sobie np., %e na etapie testów systemowych
nagle dowiadujecie si', %e okre"lone rozwi$zanie zosta o Yle 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óYniej 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óYniej 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'

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

MYŚLENIE ODWROTNE

21

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

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

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

MYŚLENIE ODWROTNE

23

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 ludYmi. Na czym ten b $d polega ? WyobraY 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.

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

24

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 MySlenia wed1ug wartoSci ks. Józefa
Tischnera (na pewno kojarzycie jego kultow$ ju% dzisiaj FilozofiT po góralsku

5

,

je"li nie — polecam!):

Cz1owiek w kryjówce chroni siT przed Swiatem i przed innymi. Przysz1oSV
nie obiecuje cz1owiekowi nic wielkiego, pamiTV przesz1oSci podsuwa mu przed
oczy same doznane poraWki, przestrzeX nie zaprasza do Wadnego ruchu. Wpraw-
dzie w kryjówce nadzieja nie znika bez reszty, tylko maleje, ale maleje do tego
stopnia, We staje siT jedynie nadziej; przetrwania

6

.

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, MySlenie wed1ug wartoSci, Znak, Kraków 2000, s. 412 – 413.

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

MYŚLENIE ODWROTNE

25

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 odpowiedY, %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óYniej
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 Yle 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óYniej 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
Yród em problemów. Tymczasem to cz'sto wyj;tkowoSV decyduje o sukcesie
danego przedsi'wzi'cia. Ten, kto ogl$da film LSnienie 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).

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

26

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 jakiS próg, który trzeba przekroczyV. Próg znaczy koniec kry-
jówki i pocz;tek nowej przestrzeni. JeSli siT widzi koniec, a nie widzi siT po-
cz;tku, bTdzie siT mimo wszystko wiTcej kochaV z1udzenie niW prawdT

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, MySlenie wed1ug wartoSci, op. cit., s. 427.

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

MYŚLENIE ODWROTNE

27

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 mySlisz,
pomySl odwrotnie

9

. Rzecz zdarzy a si' przed olimpiad$ w Meksyku, która

odby a si' w 1986 r. By to czas, kiedy technika skoków wzwy% polega a na
tym, %e sportowcy w trakcie skoku „przerzucali” swoje cia o równolegle do
poprzeczki. Na wspomnianej olimpiadzie pojawi si', wtedy jeszcze ma o
znany zawodnik, Dick Fosbury, który podbieg do poprzeczki, ustawionej
na rekordowej wysoko"ci 2 m 24 cm. Wybi si' i zamiast skoczy* jak 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 mySlisz, pomySl odwrotnie, t um. O. Siara, Insignis, Kraków

2008, s. 7.

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

28

i zas yn$ jako „flop Fosbury’ego”. Dick skoczy wy%ej ni% ktokolwiek przed-
tem, bo odwa%y si' mySleV 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 mySleli 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 wynika1a st;d, We ludzie, w tym nasi pracownicy,
zapomnieli, do jakich wartoSci odwo1uje siT Apple. D1ugo zastanawialiSmy siT,
jak powiedzieV komuS, za czym siT opowiadamy, jakie wartoSci wyznajemy,
aW uSwiadomiliSmy sobie, We kiedy nie znasz kogoS dobrze, moWesz go zapytaV:
„Kim s; twoi bohaterowie?”. MoWna siT wiele dowiedzieV o ludziach na tej pod-
stawie. StwierdziliSmy wiTc: „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].

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

MYŚLENIE ODWROTNE

29

Zdrowie szaleXców. OdmieXców. Buntowników. Wichrzycieli. Okr;g1ych ko1-
ków w kwadratowych dziurach. Tych, którzy patrz; na wszystko inaczej. Nie
lubi; regu1. Nie maj; szacunku dla status quo. MoWesz ich cytowaV, nie zga-
dzaV siT z nimi, gloryfikowaV ich albo szkalowaV. Tylko zignorowaV ich nie
moWesz. Bo oni zmieniaj; Swiat. Popychaj; ludzkoSV do przodu. I chociaW nie-
którzy widz; w nich szaleXców, my widzimy ich geniusz. Bo ludzie na tyle
szaleni, aby mySleV, We mog; zmieniV Swiat, faktycznie go zmieniaj;

11

.

Powstanie zwinnych metod tworzenia oprogramowania od samego po-

cz$tku by o pewnego rodzaju mySleniem 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
biznesu

12

. Metody agile znalaz y si' na 18. miejscu.

Manifest agile

Równolegle z kszta towaniem si' nowej fali „my"lenia odwrotnego” jako
opozycji do tego wszystkiego, co wi$za o si' z tradycyjnym rozwojem 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).

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 w asny i niczym nieskr'powany sposób, zaczynaj$
tworzy* now$ rzeczywisto"* — ta rzeczywisto"* póYniej 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,

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

®

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

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

32

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

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

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

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

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

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

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

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

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 kszta t litery T

U

ujawnianie, Patrz: elicitation
user story, Patrz: historyjka

u%ytkownika

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

W a"ciciel

Klasy, 46
Produktu, 49, 53, 60, 61, 69, 71, 72, 73,

74, 75, 77, 78, 80, 120, 121, 140, 145,
147, 148, 151, 153, 154, 163, 166,
190, 198, 200, 202, 207, 208, 212,
213, 214, 216, 229, 242, 253, 285, 306

Work Breakdown Structure, Patrz: WBS
Wujec Tom, 40
wydanie, 209, 210, 229

planowanie, 207, 212, 227, 229, 230,

231, 232

wydobywanie, Patrz: elicitation
wykres spalania, 233, 234, 236, 270, 271,

287, 294

wymagania, 133, 134, 135, 138, 139, 140,

141, 144, 146, 150, 153, 158, 162, 169,
171, 172, 190, 193, 196

biznesowe, 18
funkcjonalne, 18

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

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ

Czytaj dalej...

SCRUM. O ZWINNYM ZARZĄDZANIU PROJEKTAMI

340

Kup ksi

ąĪkĊ

Pole

ü ksiąĪkĊ