Wydawnictwo Helion

ul. Koœciuszki 1c

44-100 Gliwice

tel. [phone]

e-mail: [e-mail]

Agile Development.

Filozofia programowania

zwinnego

Autor: James Shore, Shane Warden

ISBN: 978-83-246-1614-5

Tytu³ orygina³u:

The Art of Agile Development

Format: 168x237, stron: 480

Zbiór praktycznych wskazówek dla producentów oprogramowania

•

Jak wdro¿yæ metodologiê programowania zwinnego?

•

W jaki sposób zaanga¿owaæ klientów w projekt?

•

Jak kontrolowaæ jakoœæ produktów?

Programowanie zwinne (Agile Development) to obecnie jedna z najpopularniejszych

metodologii zarz¹dzania projektami programistycznymi. Metodyka Agile jest szczególnie

u¿yteczna w ma³ych zespo³ach programistycznych, w których z racji u³atwionej

komunikacji nie ma potrzeby tworzenia rozbudowanej dokumentacji. Programowanie

zwinne opiera siê na iteracyjnej realizacji kolejnych etapów projektu. Kluczem do sukcesu

w tej metodzie jest efektywna wspó³praca miêdzy cz³onkami zespo³u projektowego.
Ksi¹¿ka „Agile Development. Filozofia programowania zwinnego

”

to przewodnik

po programowaniu ekstremalnym, oznaczanym zwykle skrótem XP, które jest jedn¹

z technik wchodz¹cych w sk³ad tej metodyki. Czytaj¹c j¹, dowiesz siê, jak wdra¿aæ

metodologiê Agile w firmie, na czym polega programowanie ekstremalne i jak¹ rolê

w procesie pe³ni¹ poszczególni cz³onkowie grupy projektowej. Nauczysz siê budowaæ

zespó³ i okreœlaæ zakresy zadañ osób bior¹cych udzia³ w pracach, planowaæ

harmogram udostêpniania kolejnych wersji produktu oraz kierowaæ procesem jego

tworzenia. Poznasz metody testowania programu i usuwania z niego b³êdów, zasady

pisania dokumentacji oraz regu³y prowadzenia spotkañ roboczych z klientami.

•

Wdra¿anie programowania zwinnego

•

Techniki programowania ekstremalnego

•

Cz³onkowie zespo³u XP

•

Zarz¹dzanie zespo³em

•

Anga¿owanie klienta w proces wytwórczy

•

Tworzenie raportów

•

Udostêpnianie kolejnych wersji systemu

•

Standardy pisania kodu

•

Testowanie i usuwanie b³êdów

•

Optymalizacja wydajnoœci programu

Od filozofii do mistrzostwa w zwinnym programowaniu!

5

Spis treci

Wprowadzenie ..............................................................................................................9

Cz I

Zaczynamy

1. Dlaczego

zwinne programowanie? ............................................................................ 19

Czym jest sukces?

20

Poza harmonogram

21

Znaczenie sukcesów na poziomie organizacji

22

Wkraczanie w wiat zwinnego programowania

23

2. Jak

by

zwinnym?

........................................................................................................25

Zwinne metody

26

Czy warto wymyla wasne metody?

27

Droga do mistrzostwa

27

Szukanie mentora

28

3. Zrozumie XP ...............................................................................................................29

Cykl ycia w XP

32

Zespó w XP

42

Pojcia zwizane z XP

55

4. Wprowadzanie

XP ....................................................................................................... 61

Czy XP to co dla nas?

61

Naprzód!

71

Ocena zwinnoci zespou

83

6 S P I S

T R E  C I

Cz II Stosowanie XP

5. Mylenie

....................................................................................................................... 91

Programowanie w parach

93

Energiczna praca

102

Informacyjne miejsce pracy

107

Analizy przyczynowo-skutkowe

112

Retrospekcje 115

6. Wspópraca ................................................................................................................ 123

Zaufanie

126

Wspólna praca

137

Zaangaowanie prawdziwego klienta

147

Wspólny jzyk

152

Krótkie spotkania robocze

157

Standardy pisania kodu

161

Demonstracje iteracji

167

Raporty

174

7. Udostpnianie

............................................................................................................ 183

„W peni gotowe”

186

Brak bdów

191

Kontrola wersji

202

Dziesiciominutowa kompilacja

211

Ciga integracja

219

Wspówasno kodu

229

Dokumentacja 234

8. Planowanie

................................................................................................................239

Wizja

241

Planowanie wydania

247

Gra planistyczna

262

Zarzdzanie ryzykiem

268

Planowanie iteracji

278

Zapas

293

Opowieci

301

Szacowanie 309

9. Wytwarzanie .............................................................................................................323

Stopniowe zbieranie wymaga

325

Testy klienta

331

Wytwarzanie sterowane testami

339

S P I S T R E  C I

7

Refaktoryzacja 360
Prosty projekt

372

Stopniowy rozwój projektu i architektury

380

Rozwizania punktowe

391

Optymalizacja wydajnoci

395

Testy eksploracyjne

402

Cz III Mistrzostwo w dziedzinie programowania zwinnego

10. Wartoci

i zasady ....................................................................................................... 415

Wspólne elementy

415

O wartociach, zasadach i praktykach

416

Dalsza lektura

417

11. Usprawnianie

procesu ............................................................................................... 419

Zrozumienie projektu

419

Dopracowywanie i adaptacja

420

amanie regu

421

12. Poleganie na ludziach ...............................................................................................425

Budowanie efektywnych zwizków

425

Odpowiednie osoby do odpowiednich zada

427

Budowanie procesu dla ludzi

429

13. Eliminowanie

marnotrawstwa ................................................................................. 431

Praca w maych, odwracalnych etapach

431

Szybkie wykrywanie niepowodze

433

Maksymalizacja liczby zada, których nie trzeba wykonywa

435

Denie do wysokiej przepustowoci

436

14. Zapewnianie

wartoci ...............................................................................................439

Wykorzystanie zwinnoci

439

Warto ma tylko kod gotowy do udostpnienia

441

Zapewnianie wyników biznesowych

442

Czste udostpnianie

444

15. Denie do doskonaoci technicznej .......................................................................447

Oprogramowanie nie istnieje

447

Projekt to narzdzie uatwiajce zrozumienie

448

Równowaga w projektach

449

Nienazwana cecha

449

8 S P I S

T R E  C I

Doskonay projekt

450

Ogólne zasady projektowania

451

Zasady w praktyce

454

Denie do mistrzostwa

456

Literatura cytowana ..................................................................................................457

Skorowidz ..................................................................................................................463

1 9

ROZDZIA 1

Dlaczego zwinne programowanie?

Zwinne wytwarzanie oprogramowania (ang. agile development) jest popularne. Wszystkie „fajne”
firmy korzystaj z tego podejcia: Google, Yahoo, Symantec, Microsoft i tak dalej

1

. Znam firm,

która zmienia nazw na Agili-cotam, aby przyczy si do trendu. Organizacja ta zadzwonia
do mnie z prob, abym usprawni ich „zwinne procesy”, które po dokadniejszej analizie
okazay si niczym wicej jak zlecaniem programowania firmom zewntrznym w innym kraju
ni zwykle. Oczekuj, e w bardzo niedalekiej przyszoci w ofercie duych firm konsultingowych
pojawi si Certyfikowane zwinne procesy i Certyfikowani konsultanci do spraw zwinnego
programowania.

Prosz, nie dajcie si wcign w ten baagan.

W 1986 roku Brooks zapowiedzia, e uniwersalne rozwizania nie powstan, e do roku 1996
adna pojedyncza technologia ani technika zarzdzania nie doprowadzi do dziesiciokrotnego
wzrostu produktywnoci, niezawodnoci lub prostoty [Brooks]. I rzeczywicie, nikomu si
to nie udao.

Równie zwinne wytwarzanie oprogramowania nie jest uniwersalnym rozwizaniem.

Co wicej, nie zalecam stosowania zwinnego programowania, jeli ma suy wycznie
zwikszeniu produktywnoci. Zalety tego podejcia — take moliwo czstszego udostpniania
oprogramowania — wynikaj z odmiennego trybu pracy, a nie z szybszego wykonywania zada.
Cho wedug anegdotycznych wzmianek zespoy stosujce zwinne programowanie wykazuj si
ponadprzecitn wydajnoci

2

, efekt ten nie powinien by gówn przyczyn wprowadzania

tego podejcia. Zespó potrzebuje czasu na opanowanie zwinnego wytwarzania oprogramowania.
W trakcie nauki — a moe to zaj kwarta lub dwa — czonkowie grupy bd pracowa wolniej,
a nie szybciej. Ponadto nacisk na produktywno czasem zachca zespó do stosowania
uproszcze i mniejszego rygoru w pracy, co moe doprowadzi do spadku wydajnoci.

1

ródo: róne raporty uytkowników na konferencjach powiconych programowaniu ekstremalnemu
i zwinnemu programowaniu.

2

Zobacz na przykad [Van Schooenderwoert], [Mah] i [Anderson 2006].

2 0

R O Z D Z I A  1 . D L A C Z E G O Z W I N N E P R O G R A M O W A N I E ?

Zwinne wytwarzanie oprogramowania jest obecnie modne, ale to nie powód, aby stosowa
to podejcie. W trakcie podejmowania decyzji dotyczcej jego wprowadzenia wana jest
odpowied na tylko jedno pytanie.

Czy zwinne wytwarzanie oprogramowania pomoe w osiganiu wikszych sukcesów?

Kiedy zespó odpowie na to pytanie, bdzie wiedzia, czy powinien stosowa zwinne
programowanie.

Czym jest sukces?

Tradycyjnie sukces utosamiany jest z dostarczeniem produktu na czas, w oczekiwanej cenie
i zgodnie ze specyfikacj. Standish prezentuje kilka klasycznych definicji [Standish]:

Udane

„Oprogramowanie ukoczono na czas,
po oczekiwanych kosztach, z mechanizmami
i funkcjami zgodnymi z wyjciow specyfikacj”.

Z problemami

„Oprogramowanie jest gotowe i dziaa, ale przekroczono budet oraz harmonogram,
a mechanizmy i funkcje s ubosze ni w wyjciowej specyfikacji”.

Nieudane

„W pewnym miejscu cyklu rozwoju rozwój oprogramowania anulowano”.

Mimo popularnoci tych definicji, nie s one w peni poprawne. Projekt moe by udany, nawet
jeli producent nie zarobi na nim ani grosza. Z kolei nawet jeli przyniesie milionowe zyski,
mona go uzna za problematyczny.

W magazynie „CIO” znajduje si komentarz do tej osobliwoci:

Nawet te projekty, które speniaj wszystkie tradycyjne kryteria powodzenia — w zakresie
czasu, budetu i specyfikacji — mog okaza si nieudane, poniewa produkty nie s
atrakcyjne dla uytkowników lub w ostatecznym rozrachunku nie zapewniaj firmie
korzyci.

[…] Podobnie, projekty uznawane za nieudane wedug tradycyjnych miar z brany IT
mog okaza si sukcesem, kiedy — mimo problemów w obszarze kosztów, czasu lub
specyfikacji — system jest uwielbiany przez odbiorców i zapewnia nieoczekiwane korzyci.
Na przykad w firmie wiadczcej usugi finansowe nowy system […] zosta dostarczony
z szeciomiesicznym opónieniem i kosztowa ponad dwa razy wicej, ni zakadano
(ostateczny koszt wyniós 5,7 miliona dolarów). Jednak projekt zwikszy elastyczno
organizacji (po 13 miesicach) i oceniono go jako wielki sukces. Wysoko umarzanych
kredytów spada o 33 miliony dolarów, a krótszy czas potrzebny na zapewnienie korzyci
i wysza wydajno doprowadziy do 50-procentowego wzrostu w liczbie jednoczenie
prowadzonych testów strategii cigania wierzytelnoci

3

.

3

Nelson R. Ryan, Applied Insight — Tracks in the Snow, „CIO Magazine”. http://www.cio.com/archive/090106/

´

applied.html.

Mimo popularnoci tych

definicji, czego w nich brakuje.

P O Z A H A R M O N O G R A M

2 1

Poza harmonogram

Sukces musi zalee od czego innego ni mieszczenie si w terminie, ale od czego?

Kiedy byem dzieckiem, cieszya mnie sama zabawa. Uwielbiaem wyzwania zwizane
z programowaniem. Kade uruchomienie aplikacji traktowaem jak wielkie zwycistwo.
Wtedy nawet program, który nie dziaa, traktowaem jak pewnego rodzaju sukces, jeli
tylko tworzenie go sprawiao mi rado . Powodzenie postrzegaem gównie w kategoriach
osobistych nagród.

Kiedy nabraem dowiadczenia, zaczem pisa bardziej skomplikowane programy i czsto
gubiem si w ich dziaaniu. Musiaem porzuci niektóre projekty przed ich ukoczeniem.
Zaczem wierzy , e kluczem do sukcesu jest atwo konserwacji. Spostrzeenie to potwierdzio
si, kiedy podjem prac i zaczem wspópracowa z zespoami innych programistów. Byem
z siebie dumny, kiedy napisaem kod, który by elegancki i atwy w konserwacji. Sukces
oznacza wtedy doskonao techniczn.

Niektóre projekty kocz si niepowodzeniem mimo dobrego kodu. Nawet doskonale
przeprowadzone projekty mog by nieciekawe dla uytkowników. Doszedem do wniosku,
e zespó projektowy, w którym pracuj, jest czci wikszego systemu, obejmujcego dziesitki,
setki, a nawet tysice osób. Produkty maj zapewnia zadowolenie ich wszystkich, a przede
wszystkim tych, którzy odpowiadaj za wysoko mojej pensji. Dla osób, które opacaj prac,
warto oprogramowania musi przewysza jego koszty. Sukces oznaczania zapewnianie
korzyci firmie.

Przedstawione definicje nie s ze sob sprzeczne. Wany jest sukces na wszystkich trzech
poziomach (zobacz rysunek 1.1). Bez powodzenia na poziomie osobistym twórca bdzie mia
problemy z umotywowaniem siebie i pracowników. Bez sukcesu technicznego kod ródowy
w pewnym momencie zaamie si pod swym ciarem. Przy braku powodzenia na poziomie
organizacji moe si okaza , e zespó nie jest ju potrzebny.

Rysunek 1.1. Oblicza sukcesu

2 2

R O Z D Z I A  1 . D L A C Z E G O Z W I N N E P R O G R A M O W A N I E ?

Znaczenie sukcesów na poziomie organizacji

Zespoy programistyczne czsto zaniedbuj sukces na poziomie firmy na rzecz atwiejszego
do osignicia powodzenia technicznego i osobistego. Naley jednak pamita o tym, e nawet
jeli dana osoba nie bierze odpowiedzialnoci za sukces organizacji, jej przeoeni oceniaj
zespó na tym poziomie. Wysza kadra zarzdzajca i dyrektorzy wykonawczy prawdopodobnie
nie bd zwraca uwagi na to, czy oprogramowanie jest eleganckie, atwe w konserwacji, a nawet
lubiane przez uytkowników. Dla przeoonych licz si wyniki, czyli zwrot z inwestycji
w projekt. Jeli zespó nie osiga sukcesów w tym obszarze, menederowie podejm dziaania,
które zapewni powodzenie.

Niestety, wysza kadra zarzdzajca zwykle nie ma czasu lub odpowiedniej perspektywy,
aby w kadym projekcie stosowa wyrafinowane rozwizania. Dlatego czciej uywaj
miecza ni skalpela i susznie oczekuj, e to zespó projektowy zajmie si szczegóami.

Kiedy menederowie s niezadowoleni z wyników zespou, wycigaj miecze. Najbardziej
oczywisty obiekt ci to koszty. S dwa proste sposoby na ich zmniejszenie: bardzo krótkie
terminy, które maj skróci czas wytwarzania, oraz zlecanie zada firmom majcym siedziby
w pastwach o niszych kosztach pracy. Mona te zastosowa oba te rozwizania jednoczenie.

S to jednak nieeleganckie techniki. Krótkie terminy czsto wyduaj czas pracy zamiast go
skraca [McConnell 1999, s. 220], a zlecanie zada firmom zewntrznym wie si z ukrytymi
kosztami [Overby].

Czy krótkie terminy i groba zlecenia zada firmom zewntrznym brzmi znajomo? Jeli tak,
pora na wzicie przez zespó odpowiedzialnoci za sukces, i to nie tylko osobisty i techniczny,
ale take na poziomie organizacji.

CO CENI ORGANIZACJE?

Cho warto niektórych projektów wynika bezporednio ze sprzeday, korzyci organizacji obejmuj take
czynniki inne ni dochody. Projekty zapewniaj warto na wiele sposobów i nie zawsze mona wyceni je
w z otówkach i groszach.

Mona wyróni nast pujce ród a wartoci (obok dochodów i oszcz dnoci)

4

:

x odrónianie si od konkurencji;
x kreowanie marki;
x wzrost lojalnoci klientów;
x spe nianie wymaga prawnych;
x oryginalne badania;
x informacje strategiczne.

4

Oparte czciowo na [Danne i Cleland-Huang].

W K R A C Z A N I E W  W I A T Z W I N N E G O P R O G R A M O W A N I A

2 3

Wkraczanie w wiat zwinnego programowania

Czy zwinne wytwarzanie oprogramowania pomoe zespoowi w osiganiu wikszych
sukcesów? Moliwe. Zwinne programowanie koncentruje si osiganiu celów osobistych,
technicznych oraz organizacji. Jeli zespó ma problemy w którym z tych obszarów, wdroenie
zwinnego wytwarzania oprogramowania moe okaza si pomocne.

Sukces na poziomie organizacji

Zwinne metody pozwalaj osign sukces na poziomie organizacji poprzez koncentracj
na zapewnianiu wartoci i zmniejszaniu kosztów. Bezporednio przekada si to na wyszy
zwrot z inwestycji. Zwinne metody powoduj take wczesne ustalanie oczekiwa, dlatego
jeli projekt nie prowadzi do sukcesu organizacji, wiadomo o tym na tyle wczenie, e mona
anulowa go przed poniesieniem wysokich nakadów.

Zespoy stosujce zwinne programowanie zwikszaj warto dziki wczeniu w prac
ekspertów biznesowych i skoncentrowaniu wysików na podstawowych wartociach, które
projekt ma zapewnia organizacji. W projektach realizowanych zgodnie ze zwinnym podejciem
jako pierwsze przygotowywane s najbardziej wartociowe funkcje, a zespó czsto udostpnia
nowe wersje, co znacznie zwiksza warto . Kiedy zmieni si potrzeby biznesowe lub zespó
zdobdzie nowe informacje, mona zmieni kierunek prac, aby dostosowa go do zaistniaej
sytuacji. Dowiadczone zespoy stosujce zwinne podejcie poszukuj nieoczekiwanych
moliwoci, które pozwol ulepszy plan dziaania.

Takie zespoy pozwalaj zmniejszy koszty. Po czci wynika to z doskonaoci technicznej.
W najlepszych zwinnych projektach pojawia si tylko kilka bdów miesicznie. Mniejsze jest
take marnotrawstwo, co jest efektem wczesnego anulowania sabych projektów i zastpowania
kosztownych praktyk rozwoju prostszymi. Komunikacja w zwinnych zespoach jest szybka
i precyzyjna, a praca jest moliwa nawet w przypadku nieobecnoci kluczowych osób.
Czonkowie regularnie kontroluj proces i nieustannie usprawniaj kod, dziki czemu
konserwacja oprogramowania i wprowadzanie w nim poprawek s atwiejsze.

Sukces techniczny

Programowanie ekstremalne, czyli zwinna metoda, na której koncentruj si w tej ksice,
szczególnie dobrze nadaje si do zapewniania sukcesu technicznego. Programici stosujcy XP
wspópracuj ze sob, co pomaga im kontrolowa drobne szczegóy istotne w doskonaych
produktach, a jednoczenie gwarantuje, e kady fragment kodu przejrz przynajmniej
dwie osoby. Programici nieustannie integruj kod, co umoliwia zespoowi udostpnienie
oprogramowania w kadym momencie, kiedy ma to sens biznesowy. Cay zespó koncentruje
si na cakowitym ukoczeniu jednej funkcji przed przystpieniem do pracy nad nastpn.
Zapobiega to nieoczekiwanym opónieniom w momencie udostpniania produktu i umoliwia
swobodne zmienianie kierunku.

Programowanie ekstremalne obejmuje, obok struktury rozwoju, zaawansowane praktyki
techniczne, które prowadz do osignicia doskonaoci technicznej. Najbardziej znan
technik jest wytwarzanie sterowane testami. Pomaga ono pisa kod, który dziaa dokadnie
tak, jak programici tego oczekuj. Zespoy stosujce XP tworz take proste, nieustannie
zmieniajce si projekty, które mona atwo zmodyfikowa przy zmianie planów.

2 4

R O Z D Z I A  1 . D L A C Z E G O Z W I N N E P R O G R A M O W A N I E ?

Sukces osobisty

Sukces osobisty jest, no có, osobisty. Zwinne programowanie moe nie spenia wszystkich
wymaga w obszarze sukcesu osobistego. Jednak po przyzwyczajeniu si do tej techniki
uytkownik, niezalenie od zajmowanego stanowiska, prawdopodobnie odkryje wiele jej zalet.

Kierownictwo i wysza kadra zarzdzajca

Te osoby doceni dugowieczno oprogramowania i koncentracj zespou na zapewnianiu
wysokiego zwrotu z inwestycji.

Uytkownicy, udziaowcy, eksperci z dziedziny i menederowie produktu

Te osoby doceni wpyw, jaki maj na kierunek rozwoju oprogramowania, a take
koncentracj zespou na dostarczeniu uytecznych i wartociowych programów oraz
wysok czstotliwo udostpniania wersji.

Menederowie produktu i projektu

Menederowie doceni moliwo zmiany kierunku prac w obliczu nowych potrzeb
biznesowych, zdolno zespou do podejmowania i speniania zobowiza oraz wysze
zadowolenie udziaowców.

Programici

Programici doceni wysz jako pracy wynikajc z podniesienia jakoci technicznej,
wikszego wpywu na szacunki i harmonogramy oraz niezalenoci zespou.

Testerzy

Testerzy doceni traktowanie ich jak penoprawnych czonków zespou, moliwo wpywu
na jako na wszystkich etapach projektu oraz bardziej wymagajc i mniej schematyczn
prac.

Praca w zwinnych zespoach to jeden z najprzyjemniejszych okresów w mojej karierze.
Wystarczy, e wyobra sobie przyjacielsk atmosfer w zespole, który wspópracuje w celu
zaprojektowania i udostpnienia produktu o trwaej wartoci, gdzie kady czonek grupy
z entuzjazmem przyczynia si do skutecznego dziaania caoci. Wyobra sobie branie
odpowiedzialnoci za dany obszar — techniczny, biznesowych lub zwizany z zarzdzaniem
— i zaufanie reszty zespou do moich zawodowych sdów i umiejtnoci. Jake przyjemne
jest rozwizywanie problemów projektowych i obserwowanie poprawy jakoci.

Zwinne programowanie zmienia obraz brany. Rozwój i udostpnianie oprogramowania
w nowy sposób wymaga duo pracy i pomylunku. Jednak jeli zespó stosuje omawiane
podejcie spójnie i przestrzegajc wszelkich zasad, moe uzyska niezwyke wyniki. Bdzie
regularnie wytwarza naprawd wartociowe oprogramowanie i kadego tygodnia demonstrowa
postpy. Ponadto rozwój oprogramowania stanie si przyjemniejszy ni kiedykolwiek wczeniej.

Wszyscy gotowi? Zaczynamy.