Tytuł oryginału: The Agile Samurai: How Agile Masters Deliver Great Software

Tłumaczenie: Andrzej Stefański

ISBN: 978-83-246-3483-5

Copyright © 2010 Pragmatic Programmers, LLC
All rights reserved

Copyright © 2012 by Helion S.A.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any
means, electronic or mechanical, including photocopying, recording or by any information storage
retrieval system, without permission from the Publisher.

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.

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/zwisam
Możesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Printed in Poland.

•

Kup książkę

•

Poleć książkę

•

Oceń książkę

•

Księgarnia internetowa

•

Lubię to! » Nasza społeczność

Spis treci

Podzikowania ...................................................................................... 9

Dobrze Ci widzie ............................................................................. 11

Cz I. Wprowadzenie ............................................................ 15

Rozdzia 1. Zwinno w piguce ........................................................ 17

1.1. Dostarczaj czego wartociowego co tydzie ............................................... 18

1.2. Jak dziaa zwinne planowanie? .................................................................. 21

1.3. Zrobione oznacza zrobione ....................................................................... 23

1.4. Trzy proste prawdy .................................................................................. 24

Rozdzia 2. Poznaj swój zwinny zespó ............................................ 27

2.1. Czym wyróniaj si zwinne projekty? ....................................................... 28

2.2. Co napdza zwinny zespó ........................................................................ 30

2.3. Typowe role ............................................................................................. 36

2.4. Wskazówki co do tworzenia Twojego zwinnego zespou .............................. 45

Cz II. Inicjacja projektu zwinnego .................................... 49

Rozdzia 3. Jak zapakowa autokar ................................................. 51

3.1. Co zabija wikszo projektów ................................................................... 52

3.2. Zadawaj trudne pytania ............................................................................ 52

3.3. Zrób tablic koncepcyjn .......................................................................... 54

Kup książkę

Poleć książkę

6



Zwinny samuraj

3.4. Jak to dziaa ............................................................................................. 54

3.5. Tablica koncepcyjna w piguce .................................................................. 55

Rozdzia 4. Kontekst projektu ........................................................... 57

4.1. Zapytaj: po co tu jestemy? ....................................................................... 58

4.2. Tworzenie krótkiego podsumowania .......................................................... 60

4.3. Projekt opakowania .................................................................................. 63

4.4. Stwórz list „NIE” ................................................................................... 66

4.5. Poznaj swoich ssiadów ............................................................................ 68

Rozdzia 5. Realizacja ......................................................................... 75

5.1. Poka rozwizanie .................................................................................... 76

5.2. Zapytaj, co nie da nam spokojnie spa ....................................................... 77

5.3. Okrel rozmiar ......................................................................................... 81

5.4. Wyjanij dokadnie, co zamierzasz dostarczy ............................................. 83

5.5. Poka, co si bdzie dziao ........................................................................ 90

Cz III. Planowanie zwinnego projektu ............................. 97

Rozdzia 6. Zbieranie historii uytkowników ................................. 99

6.1. Problem z dokumentacj ......................................................................... 100

6.2. Wprowad historie uytkownika .............................................................. 103

6.3. Cechy dobrych historii uytkownika ......................................................... 104

6.4. Jak przeprowadzi warsztaty zbierania historii .......................................... 112

Rozdzia 7. Szacowanie: pikna sztuka zgadywania .................... 119

7.1. Problem z wysokopoziomowymi szacunkami ............................................ 120

7.2. Zamiana cytryn w lemoniad .................................................................. 121

7.3. Jak to dziaa? ......................................................................................... 127

Rozdzia 8. Zwinne planowanie: zmagania z rzeczywistoci .... 135

8.1. Problemy z planowaniem statycznym ....................................................... 136

8.2. Stwórz zwinny plan ................................................................................ 138

8.3. Bd elastyczny co do zakresu projektu .................................................... 140

8.4. Twój pierwszy plan ................................................................................ 143

Kup książkę

Poleć książkę

Spis treci

 7

8.5. Wykres malejcy .................................................................................... 151

8.6. Zmiana projektu w projekt zwinny .......................................................... 155

8.7. Zastosowanie w praktyce ........................................................................ 156

Cz IV. Realizacja zwinnego projektu .............................. 165

Rozdzia 9. Zarzdzanie iteracjami: dziaanie .............................. 167

9.1. Jak dostarcza wartociowe rzeczy co tydzie ............................................ 168

9.2. Zwinna iteracja ...................................................................................... 169

9.3. Potrzebna pomoc ................................................................................... 170

9.4. Krok 1. Analiza i projektowanie: przygotowanie do pracy ......................... 171

9.5. Krok 2. Programowanie: praca ............................................................... 177

9.6. Krok 3. Testowanie: sprawdzanie pracy .................................................. 178

9.7. Kanban ................................................................................................. 180

Rozdzia 10. Tworzenie zwinnego planu komunikacji ................. 185

10.1. Cztery rzeczy do zrobienia w kadej iteracji ............................................ 186

10.2. SPH — spotkanie planowania historii .................................................. 186

10.3. Pokaz .................................................................................................. 188

10.4. Zaplanuj nastpn iteracj .................................................................... 188

10.5. Jak poprowadzi miniprzegld ............................................................... 190

10.6. Jak nie prowadzi codziennych podsumowa .......................................... 192

10.7. Wykorzystaj to, co dziaa ...................................................................... 193

Rozdzia 11. Przygotowanie wizualizacji przestrzeni roboczej .... 197

11.1. Oho… Mamy kopoty! ......................................................................... 198

11.2. Jak stworzy wizualizacj przestrzeni roboczej ......................................... 201

11.3. Poka swoje zamiary ............................................................................ 203

11.4. Stwórz i ogo wspólny sownik dla danej dziedziny ................................ 204

11.5. Uwaaj na bdy .................................................................................. 205

Cz V. Tworzenie zwinnego oprogramowania ................ 209

Rozdzia 12. Testowanie jednostkowe: wiedzie, e dziaa ........ 211

12.1. Witamy w Vegas! ................................................................................. 212

12.2. Wprowad testy jednostkowe ................................................................ 214

Kup książkę

Poleć książkę

8



Zwinny samuraj

Rozdzia 13. Refaktoryzacja: spacanie dugu technicznego ....... 221

13.1. Wprowadzanie dynamicznych zmian ..................................................... 222

13.2. Dug techniczny ................................................................................... 223

13.3. Spacanie przez refaktoryzacj ............................................................... 225

Rozdzia 14. Programowanie oparte na testach (TDD) ................ 233

14.1. Najpierw napisz testy ............................................................................ 234

14.2. Wykorzystanie testów do opanowania zoonoci .................................... 238

Rozdzia 15. Ciga integracja:

utrzymywanie gotowoci produkcyjnej ................... 243

15.1. Pokaz .................................................................................................. 244

15.2. Kultura gotowoci produkcyjnej ............................................................. 246

15.3. Czym jest ciga integracja? .................................................................. 247

15.4. Jak to dziaa? ....................................................................................... 248

15.5. Przygotuj proces publikacji kodu ........................................................... 249

15.6. Stwórz automatyczn kompilacj ........................................................... 250

15.7. Pracuj nad maymi fragmentami ............................................................ 252

15.8. Co dalej? ............................................................................................. 254

Dodatki .................................................................................... 257

Dodatek A. Zasady zwinnoci .......................................................... 259

A.1. Manifest Agile ...................................................................................... 259

A.2. Dwanacie zasad zwinnoci .................................................................... 260

Dodatek B. Zasoby internetowe ...................................................... 261

Dodatek C. Bibliografia .................................................................... 263

Kup książkę

Poleć książkę

Rozdzia 4.

Kontekst projektu

Oprogramowanie to jedna z tych unikalnych aktywnoci, w których czy
si projektowanie, konstruowanie, sztuk i nauk w jednym. Zespoy mu-
sz podejmowa tysice decyzji i kompromisów kadego dnia. Bez dobre-
go kontekstu lub dokadnego zrozumienia niemoliwe jest wybieranie naj-
lepszych rozwiza w sposób wiadomy i wywaony.

Na pocztku tworzenia tablicy koncepcyjnej bdziemy próbowali bardzo
jasno wyjani „dlaczego” kryjce si za naszym projektem, odpowiadajc
na takie pytania, jak:



Dlaczego tu jestemy?



Jak mona to krótko podsumowa?



Jak powinna wyglda reklama naszego produktu?



Czego nie zamierzamy robi?



Kto nas otacza?

Kup książkę

Poleć książkę

58



Kontekst projektu

Po przeczytaniu tego rozdziau Ty i Twój zespó bdziecie dokadnie
rozumieli, jaki jest cel projektu, bdziecie wiedzieli, dlaczego go tworzycie,
i bdziecie w stanie jasno i szybko przekaza to innym.

Ale najpierw zacznijmy od zapytania sponsorów: dlaczego tu jestemy.

4.1. Zapytaj: po co tu jestemy?

Zanim jakikolwiek zespó projektowy bdzie móg odnie prawdziwy
sukces, musi zrozumie dlaczego kryjce si za tym, co tworzy. Gdy czon-
kowie zespou rozumiej dlaczego, mog:



podejmowa lepsze, bardziej wiadome decyzje;



w lepszy sposób godzi przeciwiestwa i wypracowywa kompromisy;



tworzy lepsze, bardziej innowacyjne rozwizania, poniewa mog
myle samodzielnie.

Chodzi tutaj te o to, by sam móg znale  myl przewodni oraz wszystko
zobaczy na wasne oczy.

Id i przekonaj si sam

Czym innym jest logicznie zrozumie, dlaczego si tutaj znale limy, a czym
zupenie innym samemu to zobaczy. Aby naprawd dokadnie wej w skór
Twojego klienta i zrozumie, czego on potrzebuje, musisz pój i zobaczy
to na wasne oczy.

Pój i zobaczy oznacza, e czonkowie Twojego zespou musz ruszy
tyek i zobaczy miejsce, w którym odbywa si caa akcja.

Kup książkę

Poleć książkę

4.1. Zapytaj: po co tu jestemy?

 59

Toyota: mistrzowie sprawdzania na wasne oczy

W swojej wspaniaej ksice Droga Toyoty [Lik04] Jeffrey Liker opisuje
histori gównego inyniera, któremu powierzono przeprojektowa-
nie Toyoty Sienna 2004 pod ktem klientów z Ameryki Pónocnej.
Aby poczu, jak ludzie w Ameryce Pónocnej yj, pracuj i uywaj
swoich samochodów, on i jego zespó przejechali Toyot Sienna
przez wszystkie stany i prowincje USA, Kanad oraz Meksyk.

Oto, co odkryli:



Kierowcy w Ameryce Pónocnej czciej jedz i pij w swoich
samochodach ni kierowcy w Japonii (gdzie przemierzane dy-
stanse s z reguy krótsze). Z tego powodu w kadej Toyocie
Sienna moesz zobaczy na rodku podstawk i czternacie
uchwytów na kubki w standardzie.



Drogi w Kanadzie maj wysz koron (wypuko na rodku)
ni w Ameryce, dlatego kontrolowanie „znoszenia” podczas
jazdy jest tam bardzo wane.



Mocniejsze boczne wiatry w Ontario czyni odporno na
boczne powiewy duo waniejszym zagadnieniem do rozwi-
zania. Jeli jedziesz gdzie przy silnym bocznym wietrze, nowa
Sienna jest duo bardziej stabilna i atwiejsza do opanowania.

Cho gówny inynier mógby to wyczyta w raporcie marketingo-
wym, nie przejby si tym tak bardzo i nie zrozumia tak dokadnie,
jak teraz — po przejechaniu i zobaczeniu tych rzeczy na wasne oczy.

Na przykad jeli tworzysz system uprawnie dla firmy budowlanej pra-
cujcej przy wykopach, jed na budow. Porozmawiaj z osobami odpo-
wiedzialnymi za bezpieczestwo. Zobacz baraki. Popatrz na spartaskie
warunki, kiepskie poczenie z internetem i ograniczone powierzchnie, na
których musz pracowa Twoi klienci. Spd dzie na budowie i popra-
cuj z lud mi, którzy bd uywa Twojego systemu dzie i noc. Zaanga-
uj si, zadawaj pytania, sta si swoim klientem.

Odkryj swoj myl przewodni

Myl przewodnia to krótkie wyraenie, fraza lub zdanie podsumowujce
cel lub przyczyn Twojego projektu lub misji. To takie zdanie, wiato
rozjaniajce drog, na które mona si powoa w kadym momencie,
które w wirze walki pomoe zdecydowa, czy naley atakowa, czy moe
utrzymywa pozycj.

Kup książkę

Poleć książkę

60



Kontekst projektu

W ksice Made to stick [HH07] Chip i Dan Heath opisuj histori,
w której pracownicy firmy Southwest Airlines zastanawiali si, czy doda
saatk z kurczakiem w czasie jednego z lotów.

Gdy pado pytanie, czy zmniejszy to koszty i cen biletu (myl przewodnia
dyrektora generalnego Herbsa Kellehera), stao si jasne, e dodanie
opcjonalnej saatki z kurczakiem nie ma adnego sensu.

Myl przewodni Twojego projektu nie musi by nic wielkiego lub inspi-
rujcego. Moe to by co naprawd prostego i zwizego.

Kluczem do tego wiczenia jest skonienie ludzi do rozmowy o tym, dla-
czego ich zdaniem znajduj si oni w tym miejscu, a nastpnie potwier-
dzenie u Twojego klienta, czy rzeczywicie dokadnie o to chodzi.

4.2. Tworzenie krótkiego podsumowania

Szybko! Decydenci z funduszy venture (VC), do których chcielicie si
dosta przez ostatnie trzy miesice, wanie wsiedli do windy i masz trzy-
dzieci sekund, eby wyoy im pomys na Twój nowy, wykluwajcy si
startup. Sukces sprawi, e Twoje przedsiwzicie zapie wiatr w agle.
Poraka oznacza dalsze ycie na makaronie z serem.

Taka jest idea krótkiego podsumowania (ang. elevator pitch) —
sposobu na przekazanie esencji Twojego pomysu w bardzo krótkim cza-
sie. Krótkie podsumowania nie s jednak tylko dla pocztkujcych przed-
sibiorców. S one równie wspaniaym sposobem na zwize opisanie
nowych projektów programistycznych.

Kup książkę

Poleć książkę

4.2. Tworzenie krótkiego podsumowania

 61

S tysice powodów, aby wykona Twój projekt

Ostatnio przeprowadziem to wiczenie z zespoem majcym za-
projektowa system fakturowania dla nowego dziau firmy i byem
zdumiony liczb przyczyn, które czonkowie zespou podali jako
powód tworzenia nowego systemu.

Niektórzy myleli, e powodem jest redukcja liczby stron na faktu-
rze w celu oszczdzania papieru. Inni myleli, e miao to uproci
faktury i dziki temu zredukowa obcienie biura obsugi klienta.
Jeszcze inni myleli, e jest to okazja do uruchomienia profilowa-
nych kampanii marketingowych, aby spróbowa sprzeda klientom
dodatkowe produkty i usugi.

Wszystkie odpowiedzi byy dobre i kada z nich osobno tumaczy-
aby prowadzenie projektu. Ale tylko dziki dugim dyskusjom, deba-
tom i próbom zrozumienia pojawi si prawdziwy cel powstania pro-
jektu, którym byo po prostu uproszczenie faktur i zredukowanie
rozmiaru biura obsugi klienta.

Dobre krótkie podsumowanie powinno spenia kilka funkcji w Twoim
projekcie.

I.

Wprowadzi jasno.

Zamiast próby dostarczenia wszystkiego dla kadego, krótkie pod-
sumowanie zmusza zespó do odpowiedzenia na trudne pytanie —
czym jest produkt i dla kogo.

II.

Zmusi zespó do mylenia o kliencie.

Skupiajc si na tym, co ma by zrobione w projekcie i dlaczego,
zespoy zyskuj wartociowy wgld w to, co jest wane w produk-
cie, a przede wszystkim, dlaczego klient go kupuje.

III.

Trafia w sedno.

Jak laser, krótkie podsumowanie przecina mas pyu i dociera do
sedna tego, czym jest projekt. Ta jasno pomaga ustali priory-
tety i znakomicie poprawia stosunek sygnau do szumu na temat
tego, co naprawd si liczy.

Kup książkę

Poleć książkę

62



Kontekst projektu

Przyjrzyjmy si teraz szablonowi, który pomoe przygotowa Twoje pod-
sumowanie.

Szablon krótkiego podsumowania



dla [docelowy klient]



który [opis potrzeby lub okazji]



produkt [nazwa produktu]



jest [kategoria produktu]



który [kluczowa korzy, wany powód, by kupi]



w odrónieniu od [gówna konkurencyjna alternatywa]



nasz produkt [opis lub najwaniejsza przewaga].

Nie ma jednego sposobu na wykonanie krótkiego podsumowania. Ja lubi
ten, który opisa Geoffrey Moore w ksice Crossing the Chasm [Moo91].



dla [docelowy klient] — tumaczy, dla kogo jest projekt lub kto sko-
rzysta z jego uywania;



który [opis potrzeby lub okazji] — rozszerza problem lub potrzeb,
któr chce zaspokoi klient;



produkt [nazwa produktu] — Nadaje ycia naszemu projektowi,
przypisujc mu nazw. Nazwy s wane, poniewa przekazuj za-
miary;



jest [kategoria produktu] — tumaczy, czym w rzeczywistoci ta
usuga jest lub co oferuje produkt.

Bycie zwizym jest trudne

Jednym z powodów tak duej mocy krótkiego podsumowania jest
jego zwiza forma. Nie myl jednak, e napisanie czego krótkiego
jest proste.

Moe trzeba bdzie przej wiele prób, zanim Ty i Twój zespó znaj-
dziecie dobre podsumowanie, dlatego nie martw si, jeli nie trafisz
za pierwszym razem. Napisanie dobrego podsumowania moe by
bardzo trudn prac, ale wart wysiku.

Napisabym do Ciebie krótszy list, ale nie miaem czasu.

— stwierdzi Blaise

Pascal w Prowincjakach.

Kup książkę

Poleć książkę

4.3. Projekt opakowania

 63



który [kluczowa korzy, wany powód, by kupi] — tumaczy,
dlaczego Twój klient zechce kupi przede wszystkim ten produkt;



w odrónieniu od [gówna konkurencyjna alternatywa] — mówi,
dlaczego nie uywamy nadal tego, co ju jest;



nasz produkt [opis lub najwaniejsza przewaga] — wyrónia i tu-
maczy, w jaki sposób nasz produkt si wyrónia lub dlaczego jest
lepszy ni konkurencyjne rozwizania. To najwaniejsza rzecz. Od
tego zaley, czy otrzymamy pienidze na nasz projekt.

Dwa zdania krótkiego podsumowania obejmuj wszystko, czego potrze-
bujemy, by szybko przekaza esencj swojego projektu lub pomysu. Mó-
wi one nam, czym i dla kogo jest nasz produkt, a przede wszystkim, dla-
czego ktokolwiek mógby chcie go kupi.

Moesz przygotowywa krótkie podsumowanie ze swoim zespoem na
wiele rónych sposobów. Moesz wydrukowa szablon i kaza wszystkim
wypeni go samodzielnie, zanim zbierzesz wszystkich razem.

Jeli wolisz oszczdzi kilka drzew, po prostu wywietl szablon na ekranie
i wypenij go razem z grup, przechodzc przez wszystkie elementy sza-
blonu po kolei.

Z krótkim podsumowaniem w doni signijmy do Twojej kreatywnoci
i zaprojektujmy opakowanie Waszego produktu.

4.3. Projekt opakowania

Kup książkę

Poleć książkę

64



Kontekst projektu

Oprogramowanie jest czasami zem koniecznym dla firm. Zamiast podej-
mowa cae ryzyko i niepewno zwizan z duymi projektami, wiele z nich
bdzie wolao i do sklepu, zapaci i po prostu kupi to, co jest niezbdne.

Cho dokadnie dopasowane pakiety oprogramowania o wartoci milionów
dolarów prawdopodobnie jeszcze dugo nie zagoszcz na pókach super-
marketów, pojawia si interesujce pytanie. Gdybymy mogli znale  nasze
oprogramowanie na póce w supermarkecie, jak powinno wyglda jego
opakowanie? I jeszcze waniejsze: czy bymy je kupili?

Tworzenie opakowania dla Twojego projektu i postawienie pytania, dlaczego
kto miaby je kupi, kae Twojemu zespoowi skupi si na tym, co wa-
ne dla Twojego klienta, oraz na tym, jakie s dodatkowe korzyci z Two-
jego produktu. Lepiej, eby zespó by wiadom obu tych rzeczy podczas
tworzenia oprogramowania.

Jak to dziaa?

Wiem, co teraz mylisz. „Nie jestem kreatywny. Nie pracuj w reklamie.
Prawdopodobnie nie jestem w stanie stworzy reklamy swojego produktu”.

Mam dla Ciebie dobr wiadomo. Oczywicie, e moesz. A ja zamie-
rzam Ci pokaza w trzech prostych krokach, jak to zrobi.

Krok 1: urzd burz mózgów na temat korzyci
wynikajcych z Twojego produktu

Nigdy nie mów klientom o cechach Twojego produktu — ich to nie ob-
chodzi. Ludzie s jednak zainteresowani tym, w jaki sposób Twój produkt
uatwi im ycie. Innymi sowy: korzyciami wynikajcymi z Twojego pro-
duktu.

Zaómy przykadowo, e próbujemy przekona rodzin do korzyci wynika-
jcych z kupienia minivana. Moglibymy pokaza im list wszystkich cech.
Moemy te pokaza, w jaki sposób minivan uczyniby ich ycie lepszym.

Kup książkę

Poleć książkę

4.3. Projekt opakowania

 65

Widzisz rónic?

Tak wic pierwszym krokiem przy tworzeniu opakowania Twojego pro-
duktu jest zebranie Twojego zespou oraz klientów i przeprowadzenie
burzy mózgów na temat wszystkich powodów, dla których ludzie mogliby
chcie uywa tego produktu. Wybierz z nich trzy najwaniejsze.

Krok 2: stwórz haso reklamowe

Kluczem do dobrego sloganu jest to, by powiedzie tak duo, jak to tylko
moliwe za pomoc bardzo niewielu sów. Nie musz Ci mówi, na czym
skupiaj si ponisze firmy, poniewa ich slogany mówi wszystko:



Acura — Prawdziwa definicja luksusu. Dla Ciebie.



FedEx — Spokojna gowa.



Starbucks — Codzienne chwile przyjemnoci.

Czy odczuwasz emocje pynce z tych hase?

Teraz rozlu nij si. To cakiem nieze slogany, a Twój nie musi by a tak
profesjonalny. Po prostu spotkaj si ze swoim zespoem, ogranicz burz
mózgów na temat hasa reklamowego do dziesiciu lub pitnastu minut
i ciesz si z tego, e moesz powiczy kreatywn cz swojego mózgu.
Pamitaj, aden slogan nie jest przesodzony.

Krok 3: Zaprojektuj opakowanie

Wspaniale! Jeste prawie u celu. Ze swoimi trzema przekonujcymi po-
wodami do zakupu i silnie przycigajcym sloganem jeste ju gotowy, by
je poczy.

Kup książkę

Poleć książkę

66



Kontekst projektu

W tym wiczeniu wyobra sobie, e Twój klient wszed do sklepu z opro-
gramowaniem i zobaczy opakowanie Twojego produktu lece na póce,
a gdy je wzi do rki, wygldao tak przekonujco, e od razu kupi dzie-
si sztuk dla siebie i swoich przyjació.

A teraz szybko, narysuj to opakowanie!

Nie musi to by druga Mona Lisa. Uyj zwykego papieru do flipcharta,
kolorowych markerów, papieru, nalepek i cokolwiek jeszcze wpadnie Ci
w rce. Wykrzycz swój slogan. Poka klientom zalety produktu. Powi
pitnacie minut, aby zaprojektowa opakowanie produktu najlepsze, jakie
jeste w stanie.

Wspaniale! Widzisz, nie byo to takie trudne. Zabaw si troch przy tym
(nie kadego dnia moesz uywa kredek i kreli przekonujcy obraz
produktu). Jest to dobre wiczenie na budowanie zespou i zabawny
sposób, aby krytycznie pomyle na temat pytania dlaczego stojcego za
Twoim oprogramowaniem.

Teraz zobaczmy, co mona zrobi, aby rozpocz ustalanie oczekiwa co
do zakresu naszego projektu.

4.4. Stwórz list „NIE”

Podczas ustalania oczekiwa co do zakresu Twojego projektu powiedze-
nie, czego nie zamierzasz zrobi, moe by tak samo wane, jak powie-
dzenie tego, co zamierzasz zrobi.

Kup książkę

Poleć książkę

4.4. Stwórz list „NIE”

 67

Tworzc list „NIE”, jasno okrelasz, co jest w zakresie, a co poza zakre-
sem Twojego projektu. Zrobienie tego nie tylko jasno ustali oczekiwania
Twojego klienta, ale take zapewni, e Ty i Twój zespó skupiacie si na
rzeczach naprawd wanych, ignorujc wszystko inne.

Jak to dziaa?

Lista „NIE” jest wspania wizualizacj, przejrzycie pokazujc, co jest
w zakresie, a co poza zakresem Twojego projektu. Po prostu siadasz ze
swoim klientem i zespoem i podczas burzy mózgów na temat wszystkich
ogólnych funkcjonalnoci, które klient chciaby zobaczy w swoim opro-
gramowaniu, wypeniasz puste pola.

W zawiera rzeczy, na których chcemy si skupi. Tutaj mówimy: „To s
wielkie gazy, które bdziemy przesuwa w tym projekcie”. Mog to by
najwaniejsze funkcjonalnoci (jak raportowanie) lub ogólne cele (jak skalo-
walno w stylu Amazon).

POZA zawiera rzeczy, którymi nie chcemy sobie zawraca gowy. Mog
to by rzeczy, które chcemy odoy do kolejnej wersji, lub po prostu takie,
które s poza zakresem tego projektu. Na razie jednak nie zamierzamy si
nimi przejmowa. Spadaj ze stou.

NIEWYJA NIONE to lista rzeczy, co do których jeszcze nie podjlimy
decyzji. Jest to bardzo wartociowa pozycja, poniewa pokazuje prawd
o wielu projektach programistycznych. Mog one znaczy wiele rzeczy dla
wielu ludzi — a tego wanie chcemy unikn. W kocu bdziemy chcieli
przenie wszystkie nasze NIEWYJA NIONE do czci W lub POZA.

Pikno tej wizualnej prezentacji tkwi w tym, jak duo wida na pierwszy
rzut oka. Szybko przegldajc wane pozycje znajdujce si w zakresie po
lewej stronie, poza zakresem po prawej i w kocu niewyjanione na dole,
kady moe wyrobi sobie jasny obraz tego, gdzie le granice naszego
projektu.

Kup książkę

Poleć książkę

68



Kontekst projektu

Majc wyra nie zdefiniowany zakres, moemy i do przodu i zobaczy,
kto znajduje si w otoczeniu projektu.

4.5. Poznaj swoich ssiadów

Dobrzy ssiedzi mog by Twoimi najlepszymi przyjaciómi. S pod rk,
gdy zatrzasn Ci si drzwi. S pod rk, gdy potrzebujesz wiertarki. No,
a zrobi si cakiem mio, gdy pomoesz im uruchomi sie bezprzewodow
w domu.

Pytanie za milion dolarów

Przygotowywaem kiedy wspólnie z du kanadyjsk firm tablic
koncepcyjn, gdy wiceprezes dziau zapyta, jak ten nowy system
bdzie zintegrowany z istniejcym przestarzaym mainframe’em.

W pokoju mógby usysze spadajc kropl. Wiceprezes, który
podpisuje czeki i jest osobicie odpowiedzialny za sukces tego pro-
jektu, nie wiedzia, e nowy system nigdy nie bdzie zintegrowany
ze starym. On ma go po prostu zastpi.

I to wanie dlatego stworzylimy list „NIE” — aby unikn duej
zmiany oczekiwa na jakim dalszym etapie projektu. Lepiej zrobi to
teraz, ni próbowa zmieni co takiego, gdy projekt jest ju tworzony.

Kup książkę

Poleć książkę

4.5. Poznaj swoich ssiadów

 69

Moesz wierzy lub nie, ale Twój projekt ma te ssiadów. Tyle e za-
miast przechowywa zapasowe klucze i poycza Ci wiertark, zarzdzaj oni
bazami danych, robi audyty bezpieczestwa i zapewniaj dziaanie sieci.

Poznajc swoich ssiadów, moesz na pocztku zbudowa relacje, które
bd owocoway podczas trwania projektu. Poza tym kulturalnie jest po-
wiedzie od czasu do czasu „Cze” i nie biec do nich dopiero, gdy Twój
dom si pali. I, co najwaniejsze, podstaw kadej odnoszcej sukcesy
spoecznoci projektowej jest zaufanie.

Moja pierwsza dua wpadka projektowa

Wszyscy popeniamy bdy. Jeden z moich najwikszych popeniem, pro-
wadzc zespó ThoughtWorks wykonujcy pewn prac w firmie Microsoft.

Poszedem tam i zaczem projekt, mylc, e nasza spoeczno projek-
towa wyglda tak:

I przez pewien czas wszystko byo w porzdku. Zespó pracowa w sposób
zwinny. Regularnie dostarczalimy dziaajce oprogramowanie i ycie
byo pikne.

Nagle, pod koniec projektu, zaczo si dzia co dziwnego. Grupy i lu-
dzie, których nigdy nie widziaem ani nie spotkaem, nagle zaczli si
pojawia znikd, stawiajc dziwne wymagania mnie i mojemu zespoowi.



Jedna z grup chciaa sprawdzi nasz architektur (jak gdyby nasza
architektura wymagaa sprawdzania!).



Inna chciaa si upewni, e wypeniamy korporacyjne reguy bez-
pieczestwa (ba!).



Jeszcze inna chciaa zrobi przegld naszej dokumentacji (jakiej do-
kumentacji?).

Kup książkę

Poleć książkę

70



Kontekst projektu

Kim byli ci wszyscy ludzie? Skd si wzili? I dlaczego tak bardzo chcieli
pokrzyowa nasze plany?

W cigu jednej nocy nasza mia maa spoeczno projektowa zmienia si
z maego zespou szeciu ludzi w co duo wikszego i rozbudowanego.

Cho chciaem obwinia wszystkich dookoa, e ingeruj w nasze plany,
tak naprawd nie doceniem stwierdzenia, e spoeczno zwizana z pro-
jektem jest zawsze wiksza, ni Ci si wydaje

1

.

W punkcie „Poznaj swoich ssiadów” bdziesz chcia zrobi map spo-
ecznoci zwizanej z Twoim projektem, namierzy wszystkich i rozpocz
budowanie relacji, zanim bdziesz ich potrzebowa. W ten sposób, gdy
przyjdzie ten moment, nie bdziecie sobie kompletnie obcy i bd oni
w duo lepszej pozycji, by Ci pomóc.

Jak to dziaa?

Zbierz cay zespó i zróbcie burz mózgów, na której wynotujecie wszystkich
ludzi, z którymi powinnicie si skontaktowa przed uruchomieniem pro-
jektu. Nieocenieni bd przy tym czonkowie zespou pracujcy w firmie od
dawna i wiadomi wszystkich regu korporacyjnych oraz puapek organiza-
cyjnych, które bdzie trzeba omin.

Gdy ju wiesz, na czym stoisz, porozmawiaj z kad z grup i ustal, czy mo-
esz przypisa do kadej nazwisko i dane kontaktowe. Twój meneder pro-
jektu czy inna osoba, która bdzie odpowiedzialna w projekcie za utrzymy-
wanie takich zewntrznych relacji, moe nastpnie opracowa plan zaan-
gaowania tych grup.

1

The Blind Men and the Elephant [Sch03].

Kup książkę

Poleć książkę

4.5. Poznaj swoich ssiadów

 71

Kawa, pczki i szczero

Jeli chodzi o budowanie poprawnych relacji z ssiadami, trudno
przeceni dobr kaw z pczkiem…

Kawa, poniewa jest serwowana w miym, ciepym kubku i ssiedzi,
oprócz tego, e si z niej uciesz, bd Ci kojarzy z uczuciem ciepa.

Pczki, poniewa gdy bdziesz mówi swoim ssiadom, jak bardzo
doceniasz to, e masz ich obok siebie, ich ciaa bd cieszyy si
sodkim smakiem cukru i dziki temu ssiedzi bd Ci kojarzy ze
sodycz.

Ale najwaniejszym narzdziem do budowania wspaniaych relacji
z Twoimi ssiadami jest szczero.

Aby Twoi ssiedzi poczuli si naprawd docenieni i wartociowi, mu-
sisz ich tak postrzega. Wyapi oni nieszczere pochway w uamku
sekundy. Ale prawdziwe uznanie i szczere podzikowania pozwol
szybko ich do siebie przekona. A Ty i Twój projekt wicej na tym
skorzystacie.

UCZE: Mistrzu, sporo tych wicze wymaga czasu od sponsorów i udzia-
owców. A co jeli s oni niedostpni lub zbyt zajci, aby odpowiada na
tego typu pytania dotyczce projektu?

Kup książkę

Poleć książkę

72



Kontekst projektu

MISTRZ: Wtedy moesz sobie pogratulowa. Za to, e wanie odkrye
najwiksze ryzyko swojego projektu.

UCZE: Co to za ryzyko?
MISTRZ: Zaangaowanie klienta. Bez zaangaowanego klienta Twój
projekt ma problemy, zanim si jeszcze zacznie. Jeli Twoi klienci nie maj
czasu, eby powiedzie Ci, dlaczego piszesz dla nich to oprogramowanie, to
moe wcale nie naley go pisa.

UCZE: Czy mówisz, e wtedy powinnimy zatrzyma projekt?
MISTRZ: Mówi, e aby mie udany projekt, potrzebujesz zaangaowa-
nia klientów i udziaowców. I e bez tego jeste zgubiony, niezalenie, czy
Ci si to podoba, czy nie.

Ucze: Jeli co takiego nastpi, co powinienem zrobi?
MISTRZ: Musisz jasno, ale dobitnie wytumaczy klientom, czego bdzie
wymagao przeprowadzenie tego projektu z sukcesem. Ich zaangaowanie
i powicenie s niezbdne. Moe to nie jest dobry czas na ten projekt?
Prawdopodobnie oni s naprawd zajci i po prostu maj za duo na go-
wie. Jeli tak jest, powiedz im, e bdziesz do ich dyspozycji, gdy bd go-
towi, a tymczasem masz innych klientów do obsuenia.

UCZE: Dzikuj, Mistrzu. Musz to przemyle.

Co dalej?

Zanim pójdziemy dalej, zatrzymajmy si i odetchnijmy.

Czujesz to?

Widzisz, co si tutaj dzieje?

Z kadym kolejnym wiczeniem tablicy koncepcyjnej istota i zakres pro-
jektu staj si coraz bardziej zrozumiae.



Znamy dlaczego stojce za naszym projektem.



Mamy dobre krótkie podsumowanie.



Wiemy, jak powinno wyglda opakowanie naszego produktu.



Ustawiamy wyra ne ograniczniki zakresu projektu.



Mamy do dobre rozeznanie wród naszych ssiadów.

Kup książkę

Poleć książkę

4.5. Poznaj swoich ssiadów

 73

Wiem, co teraz mylisz. Znamy ju wystarczajco kontekst! Kiedy przej-
dziemy do rzeczy i zaczniemy rozmawia o tym, jak to zbudowa? Wa-
nie teraz.

W rozdziale 5. zaczniemy wizualizowa Twój projekt od strony technicznej
i dowiemy si, co bdzie potrzebne do jego zrealizowania.

Zatem odwró stron i przygotuj si do dziaania.

Kup książkę

Poleć książkę

74



Kontekst projektu

Kup książkę

Poleć książkę

Skorowidz

A

Acura, slogan, 65
adaptacyjne planowanie, 22
adaptive planning, Patrz adaptacyjne

planowanie

agile planning, Patrz zwinne

planowanie

analityk, 39, 91
analiza, 171

na-czas, 172

architektura, wybór, 77
automatyczna kompilacja, 250, 251, 252

oprogramowanie, 251

B

Beck, Kent, 102, 218, 241
Bloomberg, Michael, 79
bdy, 205
budet, 92, 93

C

Carnegie, Dale, 190
ciga integracja, 247, 248, 252
coach, 45

coaching, 45
collective code ownership,

Patrz wspówasno kodu

cone of uncertainty, Patrz stoek

niepewnoci

CruiseControl, 251



wiczenie Druckera, 42

D

deliver by date, Patrz dostarczenie

oprogramowania w okrelonym
terminie

deliver by feature set, Patrz dostarczenie

okrelonego zestawu funkcjonalnoci

diagram przepywu, 173
dug techniczny, 223, 224
Dodds, Keith, 52
dokumentacja, 100, 101

porównanie z historiami

uytkownika, 107

problemy, 100, 101

dostarczenie okrelonego zestawu

funkcjonalnoci, 149, 150, 151

Kup książkę

Poleć książkę

266



Zwinny samuraj

dostarczenie oprogramowania

w okrelonym terminie, 149, 150

Droga Toyoty, ksika, 59
Druckera, wiczenie, 42

E

elastyczno co do zakresu, 21
elevator pitch, Patrz krótkie

podsumowanie

Evans, Eric, 205

F

Feathers, Martin, 231
Feathers, Michael, 216
FedEx, slogan, 65
flexible on scope, Patrz elastyczno

co do zakresu

Fowler, Martin, 102, 231, 253

G

Galton, Francis, 130
Gibbons, Robin, 54
Git, 249
gówna lista historii, 21, 26, 138, 143
gotowo produkcyjna, 246

H

haso reklamowe, 65
Heath, Chip i Dan, 60
historie uytkownika, 21, 103, 104

cechy, 104, 105
negocjowalne, 106
pomoc w pisaniu, 108
porównanie z dokumentacj, 107
sowa kluczowe, 103
szablon, 111, 112
testowalne, 106

I

idealne dni, 127
inception deck, Patrz tablica

koncepcyjna

informacje zwrotne, 19, 190
integracja ciga, 247, 248, 252
INVEST, 107
iteracja, 21, 26, 138, 169

"0", 178
planowanie, 189
przykady, 170
rzeczy do zrobienia, 186

J

Jobs, Steve, 31

K

Kanban, 180, 181, 182
Kelleher, Herbs, 60
klient, 26, 36, 91

kontakt, 19
nowe wymagania, 157
w zespole, 31, 37
zaangaowany, 30, 31, 37
zwinny, 36, 37

kod

publikacja, 249
wspówasno, 179

kompilacja automatyczna, 250, 251,

252

oprogramowanie, 251

krótkie podsumowanie, 55, 62, 63

funkcje, 61
idea, 60
szablon, 62
tworzenie, 60

Kup książkę

Poleć książkę

Skorowidz

 267

L

Lean, 25
Liker, Jeffrey, 59

M

Made to stick, ksika, 60
Manifest Agile, 259
master story list, Patrz gówna lista

historii

McConnel, Steve, 120
meneder projektu, 43, 91
metody zwinne, 21, 22, 23

role w projektach, 36

minimal marketable feature set, Patrz

minimalny sprzedawalny zestaw
funkcjonalnoci

minimalny sprzedawalny zestaw

funkcjonalnoci, 144

miniprzegld, prowadzenie, 190
mistrz scruma, 45
MMF, Patrz minimalny sprzedawalny

zestaw funkcjonalnoci

Moore, Geoffrey, 62
Mott, Randy, 82, 83
myl przewodnia, 59, 60

N

negocjowalne historie uytkownika, 106

O

odbudowanie wiarygodnoci u klienta, 32
on-site customer, Patrz klient w zespole
opakowanie, projekt, 63, 64, 65, 66
opis produktu, Patrz gówna lista

historii

oprogramowanie

dostarczanie, 18, 19, 20

P

personas, Patrz role
plan, tworzenie, 138, 139, 143
planistyczny poker, 131
planowanie, 137, 138

adaptacyjne, 22
priorytety, 147
statyczne, 136
zwinne, 21

PM, Patrz meneder projektu
podsumowania

codzienne, 192
prowadzenie, 190, 191, 192

pokaz, 188

szybkie przygotowanie, 244

poker planistyczny, 131
powieci, 115
product owner, Patrz waciciel

produktu

programista, 40, 91
programowanie

oparte na testach, 234, 237, 238
praca, 177
w parach, 176

programowanie ekstremalne, 31, 215,

246

nazewnictwo, 26

projekt

budet, 92, 93
czas trwania, 81, 82, 83
elastyczno, 140, 142
klient, 36, 37
koniec czasu, 161
myl przewodnia, 59, 60
opakowanie, 63, 64, 65, 66
prezentacja planu, 90
problemy, 198
rozmiar, 81, 83

Kup książkę

Poleć książkę

268



Zwinny samuraj

projekt

ryzyka, 77, 78, 79, 80
mier, 52
trzy proste prawdy, 24, 25
ustalanie terminów, 149
wpadki, 69
zakres, 66, 67, 144
zespó programistyczny, 38
zmiana w projekt zwinny, 155
zwinny, 27, 28, 29
ródo mieci, 146

projektant interakcji z uytkownikiem,

44, 91

publikacja kodu, 249

R

refaktoryzacja, 221, 224, 225, 226,

227, 229, 230, 231

release, Patrz wydanie
repozytoria, 249
role, 174
rozmiar projektu, 81, 83
ryzyka projektowe, 77

rozmowa, 78, 79, 80

S

samoorganizacja zespou, 32, 33
Scrum, 25, 31

mistrz scruma, 45
nazewnictwo, 26

scrum master, Patrz Scrum, mistrz

scruma

slogany, 65

Acura, 65
FedEx, 65
Starbucks, 65

sownik, opracowanie, 204

SPH, Patrz spotkanie planowania

historii

SPI, Patrz spotkanie planowania

iteracji

spike, Patrz szpilka
sposób spartaskiego wojownika, 159
spotkanie planowania historii, 186, 187
spotkanie planowania iteracji, 189
sprint, Patrz iteracja
Starbucks, slogan, 65
statyczne planowanie, 136
stoek niepewnoci, 120, 121
Subversion, 249
Surowiecki, James, 130
system punktowy, 124, 125, 126
szacowanie, 120, 121

bezwzgldne, 124
dokadne, 121
planistyczny poker, 131
problemy, 120
system punktowy, 124, 125, 126
triangulacja, 127
wzgldne, 123, 124

szpilka, 130
szybko zespou, 21, 138, 148

szacowanie, 147, 149

T

tablica historii, 199, 200, 201, 202
tablica koncepcyjna, 51, 54, 55, 57,

199, 201

idea, 54
podsumowanie, 93
w piguce, 55

tablica wska ników, 87, 88, 89
tablica wydania, 199
TDD, Patrz programowanie oparte

na testach

Kup książkę

Poleć książkę

Skorowidz

 269

team velocity, Patrz szybko zespou
test-driven development, Patrz

programowanie oparte na testach

tester, 41, 42, 91
testowalne historie uytkownika, 106
testowanie, 178, 179
testy akceptacyjne uytkownika, 179
testy jednostkowe, 214, 215, 216, 217,

218

The Pixar Touch, film, 31
ThoughtWorks, 52, 54, 69, 87
triangulacja, 127
trudne pytania, 52

U

UAT, Patrz testy akceptacyjne

uytkownika

user stories, Patrz historie uytkownika
UX, Patrz projektant interakcji

z uytkownikiem

V

visual workspace, Patrz wizualizacja

przestrzeni roboczej

W

Wake, Bill, 107
warsztaty zbierania historii, 112
wizualizacja przestrzeni roboczej, 197,

201

tworzenie, 201

wizualizacja rozwizania, 76
waciciel produktu, Patrz klient
waciciel projektu, 37
wpadki projektowe, 69
wspówasno kodu, 179

Wcieka Czwórka, 85, 86

budet, 86
czas, 86
jako, 86
zakres, 87

wydanie, 144
wykres malejcy, 151, 152, 153, 200
wykres rosncy, 153, 154
wymagania, 102

X

XP, 25

Z

zasady zwinnoci, 20, 24, 31, 33, 34,

102, 141, 144, 190, 226

wszystkie, 260

zespó, 90

cross-functional, Patrz zespó,

wszechstronno

miejsce pracy, 30
odbudowanie wiarygodnoci

u klienta, 32

odpowiedzialno i samodzielno,

33, 34

rozproszony, 30
samoorganizacja, 32, 33
spotkania, 192, 193
szybko, 21, 138, 147, 148, 149
szybko mniejsza od planowanej,

158

typowe role, 36
utrata czonka, 160
wspólny jzyk z klientem, 204
wszechstronno, 34, 35, 46
zaangaowani klienci, 30, 31
zwinny, 27, 28, 29, 38

Kup książkę

Poleć książkę

270



Zwinny samuraj

zespó programistyczny, 36, 38

analityk, 39, 91
klient, 91
meneder projektu, 43, 91
programista, 40, 91
projektant interakcji z

uytkownikiem, 44, 91

tester, 41, 42, 91

zwinna analiza, 171, 172
zwinne metody, 21, 22, 23
zwinne planowanie, 21
zwinnoci, zasady, 20, 24, 31, 33, 34,

102, 141, 144, 190, 226

wszystkie, 260

zwinny projekt, 27, 28, 29

zwinny zespó, 27, 28, 29, 38

Kup książkę

Poleć książkę