Darmowy fragment publikacji:
Tytuł oryginału: Learning Agile: Understanding Scrum, XP, Lean, and Kanban
Tłumaczenie: Tomasz Walczak (wstęp, rozdz. 2 – 10), Joanna Zatorska (rozdz. 1)
ISBN: 978-83-283-0940-1
© 2015 Helion S.A.
Authorized Polish translation of the English edition of Learning Agile, ISBN 9781449331924 © 2015
O’Reilly Media.
This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all
rights to publish and sell the same.
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. 32 231 22 19, 32 230 98 63
e-mail: helion@helion.pl
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/agilpz
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 treści
Przedmowa .............................................................................................................. 11
Wprowadzenie .......................................................................................................... 13
1. Poznaj Agile .............................................................................................................. 15
16
20
21
21
24
Czym jest Agile?
Kto powinien przeczytać tę książkę?
Cele do osiągnięcia
Wpakujemy Ci Agile do głowy wszelkimi możliwymi sposobami
Struktura książki
2. Wartości Agile ........................................................................................................... 27
28
31
33
37
42
46
52
Lider zespołu, architekt i kierownik projektu wchodzą do baru…
Uniwersalne rozwiązania nie istnieją
Podejście zwinne nas uratuje! Prawda?
Niespójna perspektywa
Manifest Agile pomaga zespołom zrozumieć cel stosowania poszczególnych technik
Jak zrozumieć słonia?
Od czego zacząć wprowadzanie nowej metodyki?
3. Zasady Agile ............................................................................................................. 57
58
58
61
68
76
80
83
Dwanaście zasad podejścia zwinnego
Klient ma zawsze rację, prawda?
Dostarczanie projektu
Komunikacja i współpraca
Przebieg projektu — posuwanie się do przodu
Nieustanne ulepszanie projektów i zespołu
Projekt w podejściu zwinnym — łączenie wszystkich zasad
7
Poleć książkęKup książkę4. Scrum i samoorganizujące się zespoły ........................................................................ 87
89
91
93
106
107
115
116
124
Zasady podejścia Scrum
Akt I. Ja móc Scrum?
W zespole stosującym podejście Scrum wszyscy są właścicielami projektu
Akt II. Aktualizacje stanu są dobre w sieciach społecznościowych!
Codzienne spotkania są dla całego zespołu
Akt III. Sprintem prosto w mur
Sprinty, plany i retrospekcje
Akt IV. Pies goniący samochód
5. Planowanie w Scrumie i wspólne zobowiązanie ....................................................... 131
132
134
149
150
Akt V. Nie do końca przygotowani na nieoczekiwane
Historie użytkowników, szybkość i ogólnie przyjęte praktyki w podejściu Scrum
Akt VI. Runda honorowa
Jeszcze o wartościach w Scrumie
6. XP i otwartość na zmiany ......................................................................................... 165
166
167
176
178
183
187
188
Akt I. Nadgodziny
Podstawowe techniki XP
Akt II. Zmieniliśmy strategię, ale ciągle przegrywamy
Wartości XP pomagają zespołom zmienić nastawienie
Budowanie właściwego nastawienia zaczyna się od wartości XP
Akt III. Zmiana sytuacji
Zrozumienie zasad XP pomaga otworzyć się na zmiany
7. Prostota i projektowanie przyrostowe w XP ............................................................. 203
Akt IV. Nadgodziny, część II — znów to samo
204
Kod i projekt
205
Decyzje związane z kodem i projektem podejmuj w ostatnim sensownym momencie 217
224
Projektowanie przyrostowe i holistyczne techniki XP
Akt V. Ostateczny wynik
235
8. Lean, unikanie marnotrawstwa i spojrzenie na całość .............................................. 245
246
254
255
257
262
269
Myślenie odchudzone
Akt I. I jeszcze jedna sprawa…
Kreowanie herosów i myślenie magiczne
Eliminowanie marnotrawstwa
Lepsze zrozumienie produktu
Dostarczanie tak wcześnie, jak to możliwe
8
(cid:95)
Spis treści
Poleć książkęKup książkę9. Kanban, przepływ i nieustanne doskonalenie ...........................................................285
287
288
294
306
322
Akt II. Ciągły wyścig
Zasady podejścia Kanban
Doskonalenie procesu za pomocą podejścia Kanban
Pomiar przepływu i zarządzanie nim
Zachowania emergentne w Kanbanie
10. Coach metodyk zwinnych .........................................................................................333
334
335
339
343
345
Akt III. I jeszcze jedna sprawa (znów?)…
Coachowie rozumieją, dlaczego ludzie nie zawsze chcą się zmieniać
Coachowie rozumieją proces uczenia się
Coach rozumie, dzięki czemu metodyka działa
Zasady coachingu
Skorowidz ................................................................................................................34(cid:25)
Spis treści
(cid:95)
9
Poleć książkęKup książkę10
(cid:95)
Spis treści
Poleć książkęKup książkęROZDZIAŁ 3.
Zasady Agile
Gdybym zapytał ludzi, czego oczekują, powiedzieliby, że szybszych koni.
— Henry Ford1
Nie istnieje jeden przepis pozwalający za każdym razem otrzymać doskonałe oprogramowanie.
Zespoły stosujące podejście zwinne zdają sobie z tego sprawę. Dlatego posługują się ideami i pod-
stawowymi regułami, które pomagają dokonywać właściwych wyborów i unikać problemów, a także
radzić sobie z nieuniknionymi kłopotami, gdy się pojawią.
Poznałeś już cztery wartości z manifestu Agile. Oprócz nich istnieje dwanaście zasad, które każdy
użytkownik podejścia zwinnego powinien stosować w czasie pracy w zespole programistów. Gdy
siedemnastu pierwszych sygnatariuszy manifestu Agile spotkało się w Snowbird w stanie Utah,
szybko wymyślili oni cztery wspomniane wartości. Więcej czasu zajęło im opracowanie dołą-
czonych do manifestu dwunastu dodatkowych zasad. Jeden z sygnatariuszy, Alistair Cockburn,
wspomina2:
Nasza siedemnastoosobowa grupa szybko uzgodniła wartości. Opracowanie deklaracji z następnego
poziomu okazało się zbyt poważnym zadaniem, abyśmy mogli ukończyć je w czasie zaplanowanym
na spotkanie. Wartości wymienione w tym punkcie stanowią obecny zestaw roboczy.
Przedstawione deklaracje będą ewoluować, gdy poznamy reakcje ludzi na nasze słowa i wymyślimy
bardziej precyzyjne sformułowania. Będę zaskoczony, jeśli się okaże, że ta wersja nie stanie się prze-
starzała wkrótce po opublikowaniu tej książki. Najnowszą wersję znajdziesz w witrynie Agile Alliance
(http://www.agilealliance.org/).
Alistair miał rację. Sformułowanie zasad ze wspomnianej witryny różni się nieco od wersji z tej
książki. Jednak choć język się zmienia, idee i reguły pozostają niezmienne.
W tym rozdziale poznasz 12 zasad podejścia zwinnego. Dowiesz się, czym są, dlaczego są po-
trzebne i jak wpływają na projekty. Zobaczysz na praktycznym przykładzie, jak zastosować te za-
sady w rzeczywistym projekcie. Aby ułatwić naukę, przypisaliśmy reguły do czterech kategorii:
1 Toczą się spory na temat tego, czy Henry Ford rzeczywiście to powiedział, jednak prawie wszyscy są zgodni co
do tego, że to stwierdzenie z pewnością by mu się spodobało.
2 Alistair Cockburn, Agile Software Development: The Cooperative Game, wydanie drugie (Boston: Addison
Wesley, 2006).
57
Poleć książkęKup książkędostarczanie, komunikacja, wykonanie i rozwój. Te kategorie dotyczą kwestii powtarzających się
w zasadach i ogólnie w podejściu zwinnym. Jednak choć taki podział pozwala na skuteczną naukę,
pamiętaj, że każda reguła jest niezależna.
Dwanaście zasad podejścia zwinnego
1. Naszym priorytetem jest zapewnianie satysfakcji klientów dzięki szybkiemu i ciągłemu do-
starczaniu wartościowego oprogramowania.
2. Jesteśmy otwarci na zmiany wymagań nawet na późnych etapach prac. Procesy zwinne po-
zwalają poradzić sobie ze zmianami w celu zapewnienia klientom przewagi konkurencyjnej.
3. Często dostarczamy działające oprogramowanie; zajmuje to od kilku tygodni do kilku miesięcy,
przy czym preferowane są krótsze okresy.
4. Najwydajniejszym i najskuteczniejszym sposobem przekazywania informacji zespołowi pro-
gramistów i komunikowania się w jego ramach jest bezpośrednia rozmowa.
5. Pracownicy biznesowi i programiści muszą codziennie wspólnie pracować nad projektem.
6. Opieraj projekty na zmotywowanych osobach. Zapewnij im potrzebne środowisko i wsparcie
oraz uwierz, że wykonają zadanie.
7. Główną miarą postępów jest działające oprogramowanie.
8. W procesach zwinnych ważna jest możliwość utrzymania tempa programowania. Sponsorzy,
programiści i użytkownicy powinni móc w nieskończoność utrzymywać stałe tempo pracy.
9. Ciągła troska o techniczną doskonałość i dobry projekt są zgodne z podejściem zwinnym.
10. Konieczna jest prostota rozumiana jako sztuka maksymalizowania niewykonywanej pracy.
11. Najlepsze architektury, wymagania i projekty są owocem pracy samoorganizujących się zespołów.
12. Zespół regularnie zastanawia się nad tym, jak zwiększyć swoją efektywność, a następnie od-
powiednio usprawnia i dostosowuje swoje postępowanie3.
Klient ma zawsze rację, prawda?
Wróć do początku rozdziału i ponownie przeczytaj cytat. Co Henry Ford chciał tak naprawdę
powiedzieć? Mówi o dawaniu ludziom tego, czego potrzebują, a nie tego, o co proszą. Klient ma określone
potrzeby. Jeśli budujesz oprogramowanie, które ma je zaspokajać, musisz je zrozumieć — i to nie-
zależnie od tego, czy klient potrafi Ci je zakomunikować. Jak należy współpracować z klientem, który
nie potrafi na początku projektu wytłumaczyć, że potrzebuje samochodu, a nie tylko szybszych koni?
Właśnie ta kwestia jest podstawą dwunastu zasad; chodzi o to, aby zespół mógł zbudować opro-
gramowanie, którego użytkownik naprawdę potrzebuje. Przedstawione reguły są oparte na idei
budowania projektów w celu zapewnienia wartości. Jednak słowo „wartość” jest w tym kontekście
kłopotliwe, ponieważ każdy może uznawać za wartościowe w oprogramowaniu coś innego. Różni
ludzie mają odmienne potrzeby.
3 Źródło: http://agilemanifesto.org/principles.html (wersja z czerwca 2014 roku).
58
(cid:95)
Rozdział 3. Zasady Agile
Poleć książkęKup książkęMożliwe, że trzymasz w ręku dobry przykład ilustrujący to zagadnienie. Jeśli czytasz tę książkę na
przenośnym czytniku e-booków, używasz oprogramowania napisanego w celu wyświetlania e-booków
w tym urządzeniu. Poświęć minutę na zastanowienie się nad wszystkimi interesariuszami (osobami,
które mogą czegoś oczekiwać od danego projektu) takiego oprogramowania:
(cid:120) Dla czytelnika ważne jest, aby oprogramowanie umożliwiało łatwe czytanie książek. Istotna
jest możliwość przechodzenia między stronami, zaznaczania fragmentów, wykonywania notatek,
wyszukiwania tekstu i zapamiętywania ostatniej czytanej strony.
(cid:120) Dla autorów bardzo istotne jest to, by napisane słowa były poprawnie wyświetlane, wypunk-
towania były wyróżnione wcięciem (co ułatwia lekturę) oraz by możliwe było łatwe poruszanie
się do przodu i wstecz po tekście i przypisach. Ważny jest też ogólny odbiór książki, żeby czy-
telnicy mogli czerpać przyjemność z czytania i czegoś się nauczyć.
(cid:120) Dla redaktorów z wydawnictwa Helion ważna jest łatwość dystrybucji książki, a także — jeśli
dana pozycja Ci się podoba — możliwość dodania pozytywnej recenzji i zakupu innych książek
tego wydawnictwa.
(cid:120) Dla księgarni lub sprzedawcy, od którego kupiłeś tę książkę, liczy się to, abyś mógł bardzo
łatwo przeglądać i kupować dostępne pozycje oraz szybko i bez trudu pobierać je do czytnika.
Prawdopodobnie uda Ci się wskazać również innych interesariuszy i ważne dla nich kwestie.
Każdy z wymienionych czynników reprezentuje zapewnianą interesariuszom wartość.
Pierwsze dostępne na rynku czytniki nie miały wszystkich wymienionych funkcji. Potrzeba było dużo
czasu, aby oprogramowanie działające w czytnikach wyewoluowało do obecnej postaci. Ponadto
jest prawie pewne, że to oprogramowanie będzie coraz lepsze, ponieważ pracujące nad nim zespoły
odkryją nowe sposoby zapewniania wartości.
Łatwo jest dostrzec wartość, jaką dają czytniki, gdyż każdy jest mądry po fakcie. Znacznie trudniej
jest zauważyć wartość na początku projektu. Przeprowadźmy krótki eksperyment mentalny, by się
o tym przekonać. Jak mógłby wyglądać czytnik, gdyby opracować go w modelu kaskadowym?
„Rób tak, jak mówię, a nie tak, jak powiedziałem”
Wyobraź sobie, że pracujesz w zespole rozwijającym pierwszy przenośny czytnik e-booków. Grupa
odpowiedzialna za sprzęt dostarczyła prototyp z portem USB, przez który można wczytywać e-booki,
i z małą klawiaturą służącą do interakcji z urządzeniem. Ty wraz z zespołem masz przygotować
oprogramowanie wyświetlające e-booki użytkownikom.
Niestety, firma ma długą historię tworzenia oprogramowania za pomocą wyjątkowo nieefektyw-
nego modelu kaskadowego, w którym najpierw zajmuje się ważnymi wymaganiami. Dlatego kie-
rownik projektu zaczyna od zwołania wielkiego spotkania z udziałem wszystkich osób, do których
udało mu się dotrzeć. Cały zespół spędza kilka następnych tygodni w sali obrad, gdzie w różnym
czasie pojawiają się: starsi menedżerowie z Twojej firmy, przedstawiciele zaprzyjaźnionego wy-
dawnictwa, które chce publikować e-booki obsługiwane przez czytnik, starszy sprzedawca z księ-
garni internetowej chcącej sprzedawać te książki, a także inni interesariusze, których kierowni-
kowi projektu udało się znaleźć i nakłonić do udziału w spotkaniu.
Klient ma zawsze rację, prawda?
(cid:95)
59
Poleć książkęKup książkęPo wielu dniach intensywnych spotkań i gorących dyskusji analitycy biznesowi zdołali opracować
rozbudowaną specyfikację z wymaganiami wszystkich interesariuszy, z którymi udało się poroz-
mawiać. Wymagało to dużo pracy, jednak w efekcie powstała specyfikacja, która wszystkim się
podoba. Opisane są w niej rozbudowane funkcje dla użytkowników, dzięki którym będzie to naj-
bardziej zaawansowane oprogramowanie dla przenośnych czytników. Uwzględnione są też: funk-
cje rejestrowania statystyk marketingowych przeznaczone dla wydawnictwa, sklep internetowy
umożliwiający łatwy zakup książek, a nawet dostosowane do autorów innowacyjne mechanizmy
podglądu i edycji książek w trakcie ich pisania, usprawniające proces publikacji. Zapowiada się
naprawdę rewolucyjne oprogramowanie. Razem z zespołem przystępujecie do szacowania czasu
potrzebnego do realizacji projektu i ustalacie, że zajmie to piętnaście miesięcy. Wydaje się, że
to długo, jednak wszyscy są podekscytowani i masz pewność, że zdołacie dostarczyć oprogramo-
wanie na czas.
Mija półtora roku. Zespół pracował bardzo ciężko. Programiści siedzieli nad kodem wieczorami
i w weekendy, co negatywnie odbiło się na jakości niejednego małżeństwa. W projekt włożono
ogrom pracy, ale produkt jest gotowy i udało się go dostarczyć dokładnie według planu, niemal
co do dnia (tak, wiemy, że to prawie niemożliwe, lecz na potrzeby tego eksperymentu odrzuć
wątpliwości i wyobraź sobie, że ten jeden raz ta sztuka się udała). Kod dla każdego wymagania ze
specyfikacji został zaimplementowany, przetestowany i uznany za zakończony. Zespół jest bardzo
dumny, a wszyscy interesariusze, którzy widzieli oprogramowanie, zgadzają się, że dostali dokładnie
to, o co prosili.
Produkt trafia na rynek, jednak okazuje się niewypałem. Nikt go nie kupuje, a interesariusze nie
są zadowoleni. Co się stało?
Okazuje się, że oprogramowanie potrzebne półtora roku wcześniej obecnie nie jest już przydatne.
W czasie trwania prac nad projektem w branży pojawił się nowy standardowy format e-booków.
Ponieważ nie uwzględniono go w specyfikacji, nie jest on obsługiwany. Żaden ze sprzedawców
internetowych nie chce publikować książek w niestandardowym formacie używanym w czytniku.
Ponadto choć zespół zbudował świetny sklep internetowy, jest on znacznie mniej zaawansowany
niż sklepy obecnie wykorzystywane przez sprzedawców, dlatego nie jest dla nich atrakcyjny. Poza
tym opracowana dużym nakładem pracy specjalna funkcja podglądu dla autorów okazuje się
mniej przydatna niż oferowana przez konkurencję możliwość przesyłania e-mailem dokumentów
Worda bezpośrednio do czytnika i ich wyświetlania.
Co za porażka! Początkowa specyfikacja była bardzo wartościowa dla wszystkich klientów — za-
równo wewnętrznych, jak i zewnętrznych. Jednak obecnie oprogramowanie, które zespół półtora
roku temu zgodził się zbudować, jest znacznie mniej wartościowe. Niektóre z potrzebnych zmian
można było dostrzec na wczesnym etapie prac nad projektem, ale inne na początku nie były
oczywiste. Zespół musiałby bardzo szybko i często zmieniać kierunek prac, aby móc uwzględnić
modyfikacje. Model kaskadowy z początkowym określaniem rozbudowanych wymagań nie daje
zespołowi swobody niezbędnej do reagowania na zmiany.
Jak więc znaleźć lepszy sposób na zaspokojenie potrzeb interesariuszy i klientów w ramach pro-
jektu, który pozwala dostarczyć działające oprogramowanie?
60
(cid:95)
Rozdział 3. Zasady Agile
Poleć książkęKup książkęDostarczanie projektu
Zespoły stosujące podejście zwinne wiedzą, że najważniejsze jest dostarczenie działającego opro-
gramowania klientom. Z rozdziału 2. wiesz już, jak osiągają ten cel — dzięki pracy zespołowej,
komunikacji z klientami i reagowaniu na zmiany. Jak przekłada się to na codzienną pracę zespołu?
Jeśli za priorytet uznasz częste dostarczanie wartości, to dzięki traktowaniu każdej zmiany jako
czegoś korzystnego dla projektu i częstemu udostępnianiu oprogramowania zespół może pracować
wspólnie z klientami nad ciągłym wprowadzaniem poprawek. Oprogramowanie, które zespół utwo-
rzy, może nie być różne od pierwotnie planowanego, ale to dobrze, ponieważ ostatecznie powstanie
oprogramowanie potrzebne klientom.
Zasada numer 1. Naszym priorytetem jest zapewnianie satysfakcji klientów
dzięki szybkiemu i ciągłemu dostarczaniu wartościowego oprogramowania
Pierwsza zasada porusza trzy różne i ważne kwestie: szybkie udostępnianie oprogramowania, cią-
głe dostarczanie wartości i zapewnianie satysfakcji klientów. Aby w pełni pojąć istotę tej zasady,
trzeba zrozumieć zależności między tymi aspektami.
Zespoły projektowe funkcjonują w rzeczywistym świecie, gdzie sprawy nigdy nie toczą się idealnie.
Nawet zespół, który wykona świetną pracę przy zbieraniu i spisywaniu wymagań, z pewnością
pominie niektóre kwestie, ponieważ dla żadnego systemu nie da się bezbłędnie wykryć wszystkich
wymagań. Nie chcemy przez to powiedzieć, że nie należy się starać w tym obszarze. Metodyki
zwinne są oparte na dobrych praktykach przekazywania i spisywania wymagań. Trzeba jednak
pamiętać, że dopóki klienci nie zaczną używać działającego oprogramowania, trudno im będzie
dokładnie wyobrazić sobie, jak będzie ono pracować.
Dlatego skoro klient może przekazać rzetelne informacje zwrotne dopiero po zobaczeniu działają-
cego oprogramowania, najlepiej jest zapewnić sobie te informacje dzięki szybkiemu dostarczaniu
produktu. Udostępnij pierwszą pracującą wersję oprogramowania tak szybko, jak to możliwe.
Nawet jeśli pokażesz tylko jedną działającą funkcję, z której klient będzie mógł korzystać, i tak
warto to zrobić. Jest to korzystne dla zespołu, ponieważ klient może przekazać rzetelne informacje,
które pomogą nadać właściwy kierunek pracom nad projektem. Jest to dobre także dla klientów,
gdyż dzięki działającemu oprogramowaniu mogą zrobić coś, co wcześniej było niemożliwe. Ponie-
waż oprogramowanie funkcjonuje i klienci mogą je stosować do wykonywania potrzebnych zadań,
zespół zapewnił prawdziwą wartość. Możliwe, że jest ona niewielka, ale to i tak dużo więcej w po-
równaniu z niedostarczaniem żadnej wartości — zwłaszcza jeśli alternatywą jest coraz bardziej
sfrustrowany użytkownik, który musi długo czekać na otrzymanie oprogramowania od zespołu.
Wadą szybkiego dostarczania jest to, że oprogramowanie udostępniane początkowo klientom jest
bardzo niekompletne. Użytkownikom i interesariuszom czasem naprawdę trudno jest się z tym
pogodzić. Choć niektórym łatwo jest zaakceptować wczesne wersje oprogramowania, inni czują
się z nimi niekomfortowo. Wiele osób przeżywa trudne chwile, gdy ma korzystać z oprogramo-
wania, które jest dalekie od doskonałości. W praktyce w wielu firmach (szczególnie w dużych or-
ganizacjach, w których ludzie przez lata współpracują z programistami) zespół pracujący nad
oprogramowaniem musi dosłownie negocjować warunki dostarczania produktu interesariuszom.
Dostarczanie projektu
(cid:95)
61
Poleć książkęKup książkęJeśli współpraca między zespołem programistów a przyszłymi użytkownikami oprogramowania nie
układa się dobrze, użytkownicy i interesariusze po otrzymaniu niekompletnego produktu mogą
ocenić go bardzo surowo, a nawet wpaść w panikę, jeżeli zabraknie w nim oczekiwanej funkcji.
Podstawowe wartości podejścia zwinnego zapewniają rozwiązanie tego problemu. Jest nim współ-
praca z klientem przy negocjowaniu kontraktu. Zespół związany niezmienną specyfikacją i nieela-
stycznymi biurokratycznymi barierami nie ma możliwości wprowadzania poprawek w projekcie
oprogramowania. Grupa pracująca w takich warunkach musi uruchomić nowy proces zarządzania
zmianą, co wymaga nowych negocjacji kontraktu z klientem. Natomiast zespół ściśle współpra-
cujący z klientami może na bieżąco wprowadzać wszystkie niezbędne zmiany. Na tym polega ciągłe
dostarczanie oprogramowania.
Z tego powodu metodyki zwinne zwykle są oparte na iteracjach. Zespoły stosujące podejście
zwinne w ramach planowania iteracji wybierają funkcje i wymagania, które zapewnią największą
wartość. Jedyny sposób na ustalenie tych funkcji polega na współpracy z klientem i uwzględnia-
niu informacji zwrotnych uzyskanych w poprzedniej iteracji. Dzięki temu zespół możesz szybko
zaspokoić potrzeby klienta i zademonstrować wartość oprogramowania. W dłuższej perspektywie
pozwala to dostarczyć gotowy produkt zapewniający możliwie dużą wartość.
Zasada numer 2. Jesteśmy otwarci na zmiany wymagań nawet na późnych
etapach prac. Procesy zwinne pozwalają poradzić sobie ze zmianami
w celu zapewnienia klientom przewagi konkurencyjnej
Wielu odnoszących sukcesy praktyków podejścia zwinnego ma początkowo duże trudności z ak-
ceptacją tej zasady. Łatwo jest teoretycznie mówić o otwartości na zmiany. Jednak gdy w trakcie
gorączkowych prac nad projektem zespół natrafi na zmianę, która wymaga dużo wysiłku, sytuacja
może się stać napięta. Dotyczy to przede wszystkim tych programistów, którzy wiedzą, że przeło-
żony będzie wymagał od nich dotrzymania wcześniejszych terminów niezależnie od ilości pracy
koniecznej do uwzględnienia zmian. Poradzenie sobie z tym problemem — zwłaszcza w kulturze,
w której ludzi obwinia się o opóźnienia — bywa trudne. Może jednak przynieść też wiele satys-
fakcji, ponieważ otwartość na zmiany wymagań to jedno z najwartościowszych narzędzi w przy-
borniku zwinnych zespołów.
Dlaczego zmiany w projekcie budzą tyle emocji? Zrozumienie tej kwestii jest kluczem do oma-
wianej zasady. Przypomnij sobie sytuację, w której pracowałeś nad projektem i odkryłeś, że mu-
sisz zmienić rozwijane rozwiązanie. Jak się czułeś? Wcześniej uważałeś, że prace nad projektem
przebiegają sprawnie. Prawdopodobnie podjąłeś już liczne decyzje: jak podzielić pracę, co napisać,
co dostarczyć klientom. Nagle ktoś spoza projektu mówi, że część planów i pracy jest niepotrzebna
— że Ty zrobiłeś coś źle.
Bardzo trudno jest zaakceptować czyjeś stwierdzenie, że zrobiłeś coś źle, szczególnie jeśli wykonu-
jesz zadanie dla tej właśnie osoby. Dla większości inżynierów oprogramowania ważna jest duma
z dobrze wykonanej pracy. Chcemy dostarczać produkty, pod którymi możemy się podpisać i które
zaspokajają potrzeby użytkowników. Zmiana w projekcie jest zagrożeniem, ponieważ oznacza za-
kwestionowanie wybranej drogi i poczynionych założeń.
62
(cid:95)
Rozdział 3. Zasady Agile
Poleć książkęKup książkęBardzo często ktoś prosi Cię o zmianę kierunku prac po wcześniejszym bezpośrednim wskazaniu
obecnego kierunku. Jeżeli dana osoba poprosiła Cię o utworzenie danej funkcji, a Ty przystąpiłeś
do pracy i ukończyłeś już połowę zadania, bardzo frustrujące są słowa: „W zasadzie teraz, kiedy
o tym myślę, uważam, że powinniśmy zbudować coś zupełnie innego”. Możesz odebrać to jako
brak szacunku dla Twojej pracy. Teraz musisz się cofnąć i pozmieniać kod, który uważałeś
za skończony. Trudno jest nie przyjąć wtedy postawy defensywnej. Jeszcze gorsze jest, jeśli to
Ciebie obwinia się za to, że nie potrafisz czytać klientowi w myślach i spowodowałeś przekro-
czenie terminu.
Prawie każdy programista przynajmniej raz znalazł się w takiej sytuacji. Jak w świetle tego można
zachować otwartość na zmiany w wymaganiach?
Pierwszy krok w kierunku otwierania się na zmiany w wymaganiach polega na próbie spojrzenia
na świat z perspektywy klienta. Nie zawsze jest to łatwe, ale jest za to pouczające. Czy uważasz, że
klient, który pierwotnie zasugerował Ci zły kierunek, zrobił to celowo? Jak sądzisz — co sobie
pomyślał, gdy odkrył, że kilka miesięcy temu poprosił Cię o przygotowanie niewłaściwego opro-
gramowania, i gdy uświadomił sobie, że z tego powodu zmarnowałeś mnóstwo czasu? Dla niego
kontakt z Tobą i poproszenie o zmiany oznacza przyznanie się do pomyłki, która będzie koszto-
wać Cię dużo pracy. Nie jest to łatwe. Dlatego nie jest niczym dziwnym, że klienci często długo
odwlekają zakomunikowanie zespołowi potrzeby wprowadzenia zmian. Jest to krępujące zadanie
i klienci wiedzą, że przynoszą złe wieści. Prawdopodobnie nie zdołasz dotrzymać terminu, po-
dobnie jak sam klient. Jeśli użytkownik ma potrzeby i firma wydaje pieniądze na zbudowanie
oprogramowania, które ma je zaspokajać, to gdy produkt nie jest dostosowany do tych potrzeb,
nie zapewnia wartości. Winny jest wtedy klient, ponieważ na początku projektu przekazał Ci
niewłaściwe informacje.
Oznacza to, że dwie osoby muszą dokonać niemożliwego. Od Ciebie oczekuje się, że będziesz
czytał w myślach klienta. Z kolei on ma umieć przewidywać przyszłość. Gdy spojrzysz na sytuację
w ten sposób, łatwiej będzie Ci zachować otwartość na zmiany. Jeśli jednak wolisz unikać zmian
i uparcie trzymać się planu przygotowanego na początku prac nad projektem, rozwiązanie jest
proste — przyjmuj do zespołu wyłącznie telepatów i jasnowidzów.
Czym jest otwartość na zmiany? Oznacza ona, że:
(cid:120) Nikt nie robi problemów, gdy potrzebna jest zmiana. Członkowie zespołu (i ich przełożeni)
mają świadomość, że są tylko ludźmi i są omylni. Wiedzą też, że dla firmy lepsze jest pozwo-
lenie na popełnianie błędów i częste ich naprawianie niż oczekiwanie doskonałości już przy
pierwszym podejściu.
(cid:120) Wszyscy płyniemy na jednej łodzi. Każdy członek zespołu, włącznie ze współpracującymi
z nim klientami, jest odpowiedzialny za wymagania i wprowadzane w nich zmiany. Jeśli wy-
magania są błędne, winę za to ponoszą zarówno zespół, jak i klienci. Nie ma więc sensu ob-
winiać się wzajemnie o zmiany.
(cid:120) Nie odwlekamy zmian do czasu, gdy jest już za późno. To prawda, popełnienie błędu jest
krępujące. Jednak ponieważ wszyscy mają tego świadomość, warto starać się jak najszybciej
rozwiązać problem. Pozwala to ograniczyć zakres szkód.
Dostarczanie projektu
(cid:95)
63
Poleć książkęKup książkę(cid:120) Nie traktujemy zmian jak błędów. Dokonaliśmy najlepszych wyborów, jakie były możliwe
w świetle dostępnych wcześniej informacji. To, że te rozwiązania okazały się niewłaściwe,
można było odkryć tylko dzięki temu, iż podjęte decyzje pomogły dostrzec potrzebę wpro-
wadzenia dokonywanych teraz zmian.
(cid:120) Wyciągamy wnioski ze zmian. Jest to najskuteczniejszy sposób rozwoju zespołu i poprawy
umiejętności w obszarze wspólnego tworzenia oprogramowania.
Zasada numer 3. Często dostarczamy działające oprogramowanie; zajmuje to
od kilku tygodni do kilku miesięcy, przy czym preferowane są krótsze okresy
Może uważasz, że zachowanie otwartości na zmiany w wymaganiach to ciekawy pomysł, który
pomoże Ci w pracy nad projektami. Możesz jednak sądzić, że to bezsensowne podejście. Nie jesteś
w tym odosobniony. Wielu członków zespołów programistycznych (zwłaszcza konserwatywni
kierownicy projektów) początkowo ma wątpliwości co do otwartości na zmiany. Kierownicy każdego
dnia muszą radzić sobie ze zmianami, a nastawienie do zmian w podejściu zwinnym jest bardzo
odmienne od tradycyjnego ich traktowania. Praktycy metod zwinnych opisują tradycyjne nasta-
wienie do zmian jako podejście „dowódź i kontroluj”.
Pojęcie „dowódź i kontroluj” jest zapożyczone ze słownictwa militarnego. W książce Beautiful Teams
z 2010 roku przeprowadziliśmy wywiad z głównym inżynierem z firmy Norhtrop Grumman, Neilem
Siegelem, który przedstawił definicję tego określenia:
Andrew: Nie znam się na systemach militarnych — czym jest system dowodzenia i kontroli?
Neil: Jest to system informacyjny dla dowódców wojskowych. Umożliwia im komunikowanie się
między sobą i zachowanie orientacji w sytuacji. Pozwala ustalić, gdzie znajdują się jednostki i jaki
jest ich status. W ten sposób dowódca określa, co się dzieje. Kiedyś pola bitwy były niewielkie.
Dowódca mógł stać na wzgórzu z lornetką i obserwować sytuację. Jednak od około 1900 roku pola
bitwy stały się na tyle duże, że nie wystarczyło zająć pozycji na wzgórzu, jak niegdyś robił to Napoleon.
Do śledzenia całego pola bitwy potrzebne zaczęły być technologie. Właśnie do tego używane są systemy
dowodzenia i kontroli.
Zarządzanie projektem w modelu „dowódź i kontroluj” przypomina dowodzenie i kontrolę
w wojsku.
(cid:120) Termin „dowodzenie” określa sposób przypisywania zadań zespołowi przez kierownika pro-
jektu. Możliwe, że zespół nie odpowiada bezpośrednio przed daną osobą, ale może ona kon-
trolować przydzielanie prac. Ta osoba dzieli projekt na porcje, opracowuje harmonogram
i przypisuje zadania członkom zespołu.
(cid:120) Słowo „kontrolowanie” dotyczy sposobu zarządzania zmianami. Zmiany w projektach są
nieuniknione. Praca zajmuje więcej czasu, niż oczekiwano, ludzie biorą chorobowe lub od-
chodzą z firmy, sprzęt jest niedostępny albo zepsuty — może wydarzyć się wiele nieoczeki-
wanych rzeczy. Kierownicy projektu nieustannie śledzą takie sytuacje, a w ramach kontroli
projektu po ich wykryciu aktualizują plany, aby uwzględnić zmiany w harmonogramie i do-
kumentacji, przydzielają zespołowi nowe zadania i zarządzają oczekiwaniami interesariuszy,
żeby wszyscy wiedzieli, co się dzieje.
64
(cid:95)
Rozdział 3. Zasady Agile
Poleć książkęKup książkęPrzyczyną początkowego braku otwartości na zmiany u tradycyjnych kierowników projektu jest
to, że kierownik wie, iż opisane problemy będą pojawiać się także w projektach prowadzonych me-
todami zwinnymi, a zespół będzie musiał sobie z nimi poradzić. Zaakceptowanie zmian i otwar-
tość na nie wydają się prostą drogą do wywołania chaosu w projekcie. Jeśli w grupach stosujących
podejście zwinne nie jest stosowana metoda „dowódź i kontroluj”, jak mogą one jednocześnie ra-
dzić sobie ze zmianami i z codziennymi problemami typowymi dla zespołów projektowych?
Aby zachować otwartość na zmiany i uniknąć chaosu, trzeba często dostarczać działające oprogra-
mowanie. Zespół wykorzystuje iteracje do podziału projektu na równe okresy. W ramach poka-
zanych na rysunku 3.1 iteracji programiści tworzą działające oprogramowanie. Na koniec każdej
iteracji zespół przeprowadza pokaz, by przedstawić klientom, co zbudował, i retrospektywnie wy-
ciąga wnioski z danego okresu. Później następuje sesja planowania, w trakcie której określany jest
zakres prac z następnej iteracji. Przewidywalny harmonogram i stałe punkty kontrolne pomagają
zespołowi szybko wykryć potrzebne zmiany, a także zapewniają wszystkim wolne od przypisywania
winy środowisko, w którym można przedyskutować każdą zmianę i opracować strategię pozwala-
jącą uwzględnić poprawki w projekcie.
Rysunek 3.1. Zespół posługuje się iteracjami, aby często udostępniać oprogramowanie, i w każdej nowej wersji
wprowadza nowe funkcje
W tym kontekście podejście zwinne staje się bardzo atrakcyjne dla tradycyjnych kierowników
projektu stosujących nastawienie „dowódź i kontroluj”. Taki kierownik chce kontroli nad termi-
nami. Iteracje ze ściśle ustalonymi ramami czasowymi dają taką kontrolę. Iteracje rozwiązują też
jeden z największych problemów kierowników — radzenie sobie ze zmianami pojawiającymi się
na końcowych etapach prac. Jednym z najtrudniejszych zadań tradycyjnego kierownika projektu
Dostarczanie projektu
(cid:95)
65
Poleć książkęKup książkęjest monitorowanie zmian. Codzienne przeglądy i retrospektywne analizy iteracji pozwalają kie-
rownikowi wykorzystać cały zespół do wczesnego wykrywania potrzebnych poprawek przed wy-
stąpieniem problemów w projekcie.
Rola kierownika projektu przestaje być związana z dowodzeniem i kontrolą. Wcześniej kierownik
przedstawiał zespołowi dzienny plan bitwy i nieustannie go dostosowywał, aby zachować właści-
wy kierunek prac. Obecnie kierownik współpracuje z zespołem i dba o to, by każdy jego członek
cały czas pamiętał o ogólnej perspektywie i dążył do tych samych celów. Łatwiej jest to robić, gdy
zespół pracuje w ramach krótkich iteracji prowadzących do dostarczenia działającego oprogra-
mowania. W ten sposób każdy ma konkretne cele i dużo lepiej wie, co ma robić. Ponadto każda
osoba ma poczucie, że odpowiada nie tylko za własne zadania, ale też za to, co cały zespół dostarczy
na koniec iteracji.
Lepszy sposób dostarczania oprogramowania do czytnika e-booków
W jaki sposób opisane zasady mogą pomóc w przypadku nieudanego projektu oprogramowania
do czytnika e-booków? Wróćmy do problemów, na jakie natrafił zespół. Produkt okazał się po-
rażką, ponieważ nie posiadał ważnych funkcji oferowanych przez konkurencję (obsługi standar-
dowego formatu e-booków i możliwości przesyłania e-mailem dokumentów do urządzenia). Poza
tym udostępniał rozwiązania niedostosowane do rynku (sklep internetowy).
Zacznijmy projekt od początku. Tym razem przyjmijmy, że kierownik projektu współpracuje
z interesariuszami, a zespół wykonuje jednomiesięczne sprinty. Projekt przebiega więc zupełnie
inaczej:
(cid:120) Po trzecim sprincie jeden z programistów informuje, że zatwierdzony został nowy standar-
dowy format e-booków. Zespół decyduje się zaimplementować w czwartym sprincie bibliotekę
obsługującą ten format. W piątym sprincie biblioteka ma zostać wbudowana w interfejs użyt-
kownika czytnika.
(cid:120) Po dziesięciu miesiącach prac powstaje działające oprogramowanie, które można załadować
do prototypowych urządzeń i udostępnić użytkownikom wersji beta. Kierownik projektu roz-
mawia z tymi użytkownikami i odkrywa, że woleliby mieć możliwość przesyłania do czytników
dokumentów Worda i artykułów prasowych. Zespół w ramach następnego sprintu dodaje do
czytnika integrację z pocztą elektroniczną, dzięki czemu użytkownicy mogą przesyłać e-mailem
artykuły do urządzeń.
(cid:120) Po roku interesariusze informują zespół, że sklep internetowy jest niepotrzebny, bo wszyscy
sprzedawcy korzystają ze standardowego formatu e-booków. Na szczęście sklep nie był trak-
towany priorytetowo i poświęcono mu bardzo niewiele czasu, gdyż w trakcie sprintu zajmo-
wano się ważniejszymi funkcjami.
Ponieważ zespół po każdym sprincie udostępniał działające oprogramowanie, usunięcie funkcji
z kolejki zadań pozwoliło dostarczyć produkt przed czasem! Wydawnictwo było gotowe do sprze-
daży książek, bo wszyscy pracujący w nim starsi menedżerowie otrzymali wczesną wersję opro-
gramowania i prototypowe urządzenia do wypróbowania. Dzięki temu wydawnictwo było zaan-
gażowane w projekt i miało motywację do udostępnienia książek bezpośrednio po pojawieniu się
pierwszej wersji produktu. Nowy model pracy przedstawia rysunek 3.2.
66
(cid:95)
Rozdział 3. Zasady Agile
Poleć książkęKup książkęRysunek 3.2. Na początku każdej iteracji zespół wybiera z rejestru zadań funkcje, nad którymi będzie pracował
Dzięki ciągłemu udostępnianiu, otwartości na zmiany i dostarczaniu po każdej iteracji działającego
oprogramowania w projekcie czytnika e-booków udało się przed czasem ukończyć udany produkt.
W odróżnieniu od zespołu korzystającego z modelu kaskadowego, w którym programiści po za-
twierdzeniu wymagań zostali odcięci od klientów, zespół w podejściu zwinnym pozostawał w sta-
łym kontakcie z użytkownikami. Dzięki temu mógł reagować na zmiany sytuacji i zbudować
lepszy produkt.
Jednak w zespole pracującym nad czytnikiem e-booków nie wszystko funkcjonuje perfekcyjnie.
Programiści dostarczają działające oprogramowanie w ramach iteracji, ale są przytłoczeni doku-
mentacją. Wszyscy są bardzo zadowoleni, że utknęli w pracy nad oprogramowaniem, które nie
będzie się sprzedawać. Lecz za każdym razem, gdy zespół wykryje ciekawą zmianę, którą należy
wprowadzić w projekcie, połowa grupy musi wracać do specyfikacji i aktualizować ją, tak by plany
były aktualne i prace toczyły się w odpowiednim kierunku. Można odnieść wrażenie, że aktuali-
zowanie dokumentacji zajmuje równie dużo czasu co pisanie kodu.
Członkowie zespołu rozmawiali o tym, jak ograniczyć ilość pracy niezbędnej do aktualizowania
dokumentacji. Prowadzono długie dyskusje na temat odpowiedniego poziomu jej szczegółowości.
Jednak za każdym razem, kiedy próbowano z czegoś zrezygnować, znajdowała się osoba, która
(słusznie) zwracała uwagę na to, że jeśli zespół nie opisze funkcji, wymagania, projektu lub przy-
padku testowego, ktoś może czegoś nie zrozumieć. Jeżeli potem implementacja okaże się błędna,
zespół zostanie o to obwiniony. Wygląda więc na to, że wszystkie fragmenty dokumentacji są nie-
zbędne, ponieważ bez tego zespół narazi się na tworzenie nieodpowiedniego oprogramowania.
Dostarczanie projektu
(cid:95)
67
Poleć książkęKup książkęCzy jest sposób na ograniczenie tego obciążenia bez ryzykowania problemów w projekcie? Czy
w ogóle istnieje „właściwy” poziom szczegółowości dokumentacji projektów?
Punkty kluczowe
(cid:120) Dwanaście zasad programowania zwinnego, które są dodatkiem do manifestu
Agile, zapewnia użytkownikom podejścia zwinnego kierunek prac i wgląd
w praktyki oraz metody.
(cid:120) Zespoły stosujące podejście zwinne zapewniają klientom satysfakcję dzięki
szybkiemu uzyskiwaniu informacji zwrotnych i ciągłemu udostępnianiu oprogra-
mowania, co gwarantuje, że otrzymane informacje są aktualne (zasada numer 1).
(cid:120) Zespoły stosujące podejście zwinne są otwarte na zmiany i traktują je jako po-
zytywne i korzystne poprawki w projekcie (zasada numer 2).
(cid:120) Dzięki ograniczonym czasowo iteracjom, które pozwalają często udostępniać
działające oprogramowanie, zespoły stosujące podejście zwinne nieustannie do-
stosują projekt, co prowadzi do zapewniania maksymalnej wartości klientom
(zasada numer 3).
Komunikacja i współpraca
Zespoły programistyczne od zawsze zmagają się z pytaniem: jak szczegółowa ma być dokumentacja?
Zespoły od lat szukają uniwersalnej metodyki w celu rozwiązania problemów z procesem, pro-
gramowaniem i dostarczaniem rozwiązań, starają się też opracować uniwersalny system lub szablon
tworzenia dokumentacji, który pozwoli w magiczny sposób zapisać wszystko, co jest potrzebne
do utworzenia oprogramowania i jego późniejszej konserwacji.
Oto tradycyjny sposób myślenia o dokumentacji oprogramowania: potrzebujemy systemu zarzą-
dzania dokumentacją, aby każdy mógł w nim zapisywać dostępne informacje i łączyć je z danymi
innych osób. Jeśli używany jest system śledzenia wpisów i można ustalić wszystkie powiązania
między informacjami, otrzymamy prawie doskonały wgląd w to, co należy zbudować, jak to
przetestować, jak zainstalować i konserwować. To podejście opiera się na założeniu, że programi-
ści mogą powiązać każdy element projektu z wymaganiem, a testerzy — połączyć każdy przypa-
dek testowy z aspektami projektu, wymagań i zakresu prac. Gdy zespół będzie musiał na przykład
zmodyfikować fragment projektu, będzie mógł precyzyjnie określić wymagające zmian wymagania,
kod, zakres prac i przypadki testowe. Dzięki temu nie trzeba będzie marnować dużych ilości czasu
na analizy. Inżynierowie oprogramowania nazywają ten proces analizą wpływu i często starają się
tworzyć rozbudowane macierze powiązań, w których wszystkie aspekty zakresu prac, wymagań,
projektu i testów są połączone ze sobą. Kierownik projektu może wykorzystać takie macierze do
wiązania kodu, raportów o błędach, elementów projektów i wymagań z ich źródłami.
Wróćmy więc do pytania, które sprawia zespołom trudności — ile dokumentacji należy tworzyć?
Dla zespołów stosujących podejście zwinne odpowiedź brzmi: tyle, aby można było zbudować projekt.
Dokładny zakres dokumentacji zależy od zespołu, poziomu komunikacji i rozwiązywanego problemu.
68
(cid:95)
Rozdział 3. Zasady Agile
Poleć książkęKup książkęPomyśl o różnych rodzajach dokumentacji przygotowywanych przez zespoły programistów. Trzeba
zapisać w postaci długich notatek wszystkie decyzje podjęte na każdym spotkaniu, przygotować
dokumenty z odnośnikami opisujące każdy aspekt wszystkich źródeł i magazynów danych, a tak-
że utworzyć skomplikowane macierze z wyszczególnieniem ról, obowiązków i zasad powiązanych
z każdą z osób. Przydatność każdej dokumentacji da się uzasadnić. Jeśli jednak nie pomaga ona
w budowaniu oprogramowania i nie jest potrzebna z innych przyczyn (na przykład prawnych lub
dla inwestora, starszych menedżerów albo innych interesariuszy), zespół zwinny nie będzie jej
pisał. Jeżeli natomiast zespół stwierdzi, że naprawdę pomoże mu przygotowanie wymagań funk-
cjonalnych, może je opracować i nadal stosować podejście zwinne. Wszystko zależy od tego, co
sprawdza się w zespole. Jest to jeden z aspektów swobody, jaką daje podejście zwinne.
Duża część dodatkowej dokumentacji, wykraczającej poza to, czego zespół potrzebuje do budo-
wania oprogramowania (chodzi tu o wyczerpującą dokumentację, macierz śledzenia i materiały
do analizy wpływu), ma przede wszystkim umożliwiać pełną analizę wpływu zmian. Choć w po-
dejściu zwinnym stosowany jest inny (i często znacznie wydajniejszy) sposób zarządzania zmia-
nami w projekcie, praktycy powinni pamiętać, że tradycyjna dokumentacja ma służyć podobnym
celom. W modelu kaskadowym wyczerpująca dokumentacja ma pozwalać na lepsze radzenie
sobie ze zmianami.
Paradoksalnie rozbudowana dokumentacja częściej przeszkadza w zarządzaniu zmianami, niż
w tym pomaga. Marzeniem, którego spełnienie mają umożliwić perfekcyjna dokumentacja i me-
chanizmy śledzenia, jest system pozwalający zespołowi na automatyczne określenie wpływu każ-
dej zmiany, co daje możliwość precyzyjnego ustalenia, jakie elementy wymagają poprawek.
Niestety, w większości zespołów zarządzanie zmianami z wykorzystaniem kompletnej dokumen-
tacji nie jest takie proste. Na początku projektu trzeba poświęcić bardzo dużo czasu na próby
prognozowania przyszłości i precyzyjnego zapisania dokumentacji. W trakcie projektu konieczne
jest aktualizowanie napisanych dokumentów i śledzenie nowych mechanizmów. Jeśli zmieniła się
pierwotna wizja rozwijanego produktu, trzeba zmodyfikować także wszystkie związane z nią do-
kumenty. Z czasem może to prowadzić do dezaktualizacji wielu dokumentów, a ich przygotowy-
wanie i modyfikowanie wymaga od zespołu dużo pracy.
Ponieważ wyczerpująca dokumentacja nie jest doskonała, prowadzi do niepotrzebnych zmian
i marnowania wysiłku. Każdy fragment dokumentacji jest pisany z perspektywy osoby pełniącej
określoną funkcję. Analityk biznesowy przygotowuje wymagania ze swojego punktu widzenia, ar-
chitekt rozwija projekty według własnej wizji, a inżynierowie z działu jakości tworzą plany testów
z jeszcze innej perspektywy. Gdy trzeba powiązać wszystkie te aspekty w macierzy śledzenia, po-
jawiają się niespójności, których można oczekiwać ze względu na różne punkty widzenia. Two-
rzenie dokumentacji staje się celem samym w sobie i wymaga dodatkowego wysiłku na początku
projektu. Kiedy w końcu pojawią się zmiany, całą pracę włożoną w uzgadnianie perspektyw i two-
rzenie jednego wyczerpującego zestawu dokumentacji trzeba wykonać od nowa. To sprawia, że zespół
marnuje czas na ponowne pisanie dokumentacji, odtwarzanie macierzy śledzenia i rozwiązywanie
konfliktów, podczas gdy powinien pisać kod, testować oprogramowanie i wprowadzać zmiany.
Musi istnieć wydajniejszy sposób tworzenia oprogramowania.
Komunikacja i współpraca
(cid:95)
69
Poleć książkęKup książkęZasada numer 4. Najwydajniejszym i najskuteczniejszym sposobem
przekazywania informacji zespołowi programistów i komunikowania się
w jego ramach jest bezpośrednia rozmowa
Praktycy podejścia zwinnego wiedzą, że dokumentacja to jedna z form komunikowania się4. Jeśli
piszę dokumentację i Ci ją przekazuję, celem nie jest napisanie dokumentacji. Ważne jest to, aby
informacje z mojego i Twojego umysłu były jak najbardziej zbliżone do siebie (inaczej niż na ry-
sunku 3.3). W wielu sytuacjach dokumentacja jest dobrym narzędziem, które pozwala uzyskać taki
efekt. Jednak nie jest ona jedynym dostępnym sposobem komunikacji.
Rysunek 3.3. Gdy członkowie zespołu nie komunikują się ze sobą, mogą zgadzać się ze sobą na ogólnym poziomie,
ale dążyć do różnych celów. Wyczerpująca dokumentacja jeszcze pogarsza sytuację, ponieważ może powodować
niejednoznaczność
Bezpośrednia rozmowa to prawie zawsze lepsze od dokumentacji narzędzie wymiany informacji
w zespole projektowym. Każdy wie, że osobiste omówienie problemu to najskuteczniejszy sposób na
zrozumienie nowego zagadnienia. Ludzie łatwiej zapamiętują informacje, gdy uzyskają je w trakcie
rozmowy, niż gdy przeczytają je z kartki lub w dokumencie Worda. To dlatego w podejściu zwinnym
ważna jest głównie komunikacja między poszczególnymi osobami. Dokumentacja rezerwowana jest
dla sytuacji, w których po pewnym czasie trzeba przypomnieć sobie skomplikowane informacje.
4 Po prawdzie tradycyjni kierownicy projektów też zdają sobie z tego sprawę. Typowy kierownik projektu zna róż-
nice między komunikacją formalną i nieformalną, a także między komunikacją pisemną i ustną. Uczy się też do-
strzegać niewerbalne wskazówki w komunikacji oraz tego, że komunikacja twarzą w twarz to najskuteczniejszy
sposób przekazywania informacji. Te zagadnienia są nawet poruszane na egzaminie PMP!
70
(cid:95)
Rozdział 3. Zasady Agile
Poleć książkęKup książkęNa szczęście zespołom, które są przyzwyczajone do używania wyczerpującej dokumentacji, łatwo
jest przejść do skuteczniejszej komunikacji bezpośredniej. Wynika to z tego, że większość zespo-
łów nie próbuje opracować idealnej, kompletnej dokumentacji i macierzy śledzenia. Inżynierowie
oprogramowania są z natury praktyczni. Gdy widzą, jak dużo pracy wymaga przygotowanie wy-
czerpującej dokumentacji, i tak wybierają bezpośrednią rozmowę. Ostatecznie jest to jedyny spo-
sób pozwalający skutecznie rozwijać oprogramowanie. Dzięki uznaniu, że tworzenie wyczerpują-
cej dokumentacji jest często niewłaściwym rozwiązaniem, mogą przestać czuć się winni tego, że
nie potrafią dokonać niemożliwego (czyli zbudować idealnej kompletnej dokumentacji). Przecież
nawet gdyby przygotowali wyczerpującą dokumentację, nie byłaby ona przydatna w projekcie.
Najskuteczniejszą metodą przekazywania ważnych zagadnień w projekcie jest zadbanie o to, aby
wszyscy myśleli w ten sam sposób. Dzięki temu każdy może na bieżąco podejmować właściwe de-
cyzje. Jeśli grupa ludzi patrzy na świat z tej samej perspektywy i otwarcie dzieli się pozytywnymi
oraz negatywnymi przemyśleniami, uzyskuje wspólny punkt widzenia. Gdy pojawia się zmiana
wymagająca wyboru nowego kierunku, członkowie zespołu nie muszą wiele sobie tłumaczyć.
Ostatecznym celem komunikacji w zespole jest zbudowanie poczucia wspólnoty, tak aby duża
część wiedzy znajdowała się już w umysłach poszczególnych osób. W końcu wielokrotne wyja-
śnianie tych samych rzeczy nie jest wydajnym podejściem. Bez poczucia wspólnoty osobom peł-
niącym różne funkcje trudniej jest dopasować się do perspektywy innych członków zespołu. Im
większe jest poczucie wspólnoty i bardziej uwspólniony punkt widzenia, tym częściej poszczegól-
ne osoby niezależnie dojdą do podobnych odpowiedzi na te same pytania. Pozwala to zapewnić
stabilniejsze fundamenty w momencie wprowadzania zmian, ponieważ łatwiej jest rozwiązać
konflikty i zacząć pracę nad kodem — i to bez rozpraszania się na aktualizowanie dokumentacji.
Zasada numer 5. Pracownicy biznesowi i programiści
muszą codziennie współpracować przy projekcie
Zespoły stosujące podejście zwinne czasem zapominają, że współpracujący z nimi użytkownicy
biznesowi też mają swoje zadania. To prowadzi do naturalnych rozbieżności między programi-
stami a pracownikami biznesowymi, dla których tworzone jest oprogramowanie.
Aby zbudować dobre oprogramowanie, zespół musi przeprowadzić wiele bezpośrednich rozmów
z pracownikami biznesowymi, ponieważ potrzebuje wiedzy na temat problemów firmy, które
rozwijany produkt ma rozwiązywać. Pracownicy biznesowi posiadają tę wiedzę, gdyż rozwiązują
te same problemy bez pomocy oprogramowania. Dlatego dla większości osób współpracujących
z programistami uczestnictwo w projekcie związanym z oprogramowaniem stanowi tylko niewiel-
ką część zadań. Takie osoby najchętniej ograniczyłyby kontakty z programistami do minimum.
Idealny scenariusz to wzięcie udziału w jednym lub dwóch spotkaniach, określenie, co oprogra-
mowanie ma robić, i otrzymanie po krótkim czasie perfekcyjnie działającego oprogramowania.
Natomiast zespoły dążą do jak najczęstszych kontaktów z pracownikami biznesowymi. Programi-
ści muszą poznać problemy biznesowe, które mają zostać rozwiązane. Robią to przez rozmowy
z użytkownikami biznesowymi, towarzyszenie im przy pracy i obserwowanie jej efektów. Programi-
sta, który potrzebuje takich informacji, chce pełnej uwagi ze strony każdego pracownika biznesowego.
Im dłużej musi czekać na odpowiedzi na swoje pytania, tym wolniej projekt posuwa się naprzód.
Komunikacja i współpraca
(cid:95)
71
Poleć książkęKup książkęJednak pracownicy biznesowi nie chcą spędzać całego czasu z zespołem projektowym, ponieważ
mają zadania do wykonania. Kto wygra w tej sytuacji?
Zespoły stosujące podejście zwinne mają rozwiązanie tego problemu, pozwalające odnieść zwy-
cięstwo zarówno pracownikom biznesowym, jak i programistom. Należy zacząć od zrozumienia,
że zespół dostarcza firmie wartościowe oprogramowanie. Gotowy produkt jest dla firmy warty
określoną kwotę. Jeśli wartość oprogramowania jest wyższa niż koszt jego wytworzenia, opłaca się
w nie zainwestować. Dobry projekt powinien być na tyle wartościowy, żeby pracownicy biznesowi
dostrzegli, iż jest on wart włożenia w niego wysiłku. Rysunek 3.4 przedstawia wykres uwzględniający
wartość i koszt rozwijanych funkcji.
Rysunek 3.4. Niektóre funkcje z rejestru zadań są dla firmy bardziej wartościowe od innych. Zespół musi znaleźć
równowagę między wartością (ile dana funkcja jest warta) a kosztami (ile pracy trzeba włożyć w zbudowanie
danego mechanizmu) przy określaniu, które rozwiązania należy opracować w każdej iteracji
Gdy pracownicy biznesowi i programiści budują oprogramowanie jako zespół, w dłuższej per-
spektywie najwydajniejsza jest ich codzienna współpraca przy projekcie. W przeciwnym razie pra-
cownicy biznesowi zapoznają się z efektami prac zespołu i będą mogli udzielić informacji zwrot-
nych na późnym etapie prac, a wprowadzanie zmian pod koniec projektu jest bardzo kosztowne.
Wczesne wykrywanie zmian wymaga znacznie mniej czasu. Dlatego w przekroju całego projektu
codzienna współpraca z zespołem zajmuje każdemu użytkownikowi biznesowemu mniej czasu.
To z tego powodu zespoły, które często dostarczają działające oprogramowanie, powinny priory-
tetowo traktować najbardziej wartościowe funkcje. Dzięki temu pracownicy biznesowi szybko otrzy-
mają coś wartościowego. To jeden z aspektów umowy. Dlatego dobre zespoły stosujące podejście
72
(cid:95)
Rozdział 3. Zasady Agile
Poleć książkęKup książkęzwinne uważają pracowników biznesowych za ważną część grupy, równie istotną jak programiści.
Grupy stosujące podejście zwinne bardzo różnią się pod tym względem od tradycyjnych zespo-
łów. Te ostatnie traktują użytkowników biznesowych jak klientów, z którymi trzeba negocjować.
Zespół zwinny współpracuje z klientem (jest nim zwykle właściciel produktu) jak z kimś, kto ma
równie duże prawo do wpływu na przebieg projektu. Sprowadza się to do podstawowej wartości
podejścia zwinnego, zachęcającej do współpracy z klientem zamiast do negocjowania kontraktu.
Dobry właściciel produktu pomaga ograniczyć czas spędzany przez pracowników biznesowych
z zespołem. Obie strony muszą się codziennie spotykać, jednak właściciel produktu może skon-
centrować się na zrozumieniu wartości oprogramowania i problemów biznesowych, które należy
rozwiązać. Dzięki temu zespół może wykorzystać czas spędzany z pracownikami biznesowymi na
weryfikowanie informacji, które otrzymał już od właściciela produktu.
Zasada numer 6. Opieraj projekty na zmotywowanych osobach.
Zapewnij im potrzebne środowisko i wsparcie oraz uwierz, że wykonają zadanie
Projekty przebiegają najlepiej, gdy wszyscy w firmie uważają, że zespół rozwija wartościowe opro-
gramowanie, a także gdy wszystkie osoby (włącznie z właścicielem produktu) rozumieją, co sprawia,
że oprogramowanie jest cenne dla organizacji.
Problemy mogą natomiast wystąpić w środowisku, w którym ludzie nie widzą wartości w opro-
gramowaniu lub nie są nagradzani za poprawne rozwijanie produktu. Nie jest niczym niezwy-
kłym, że firma opracowuje systemy oceny wydajności i naliczania wynagrodzeń, które zniechęcają
do rozwijania oprogramowania w efektywny, zwinny sposób. Może to negatywnie wpływać na
przebieg projektu. Oto często spotykane „programy motywacyjne”, które szkodzą zespołom sto-
sującym podejście zwinne:
(cid:120) Dawanie programistom złych ocen, gdy w trakcie sprawdzania kodu wykrywane są błędy.
Nagradzanie za kod, w którym nie wykryto usterek. To podejście powoduje, że programiści
przestają znajdować błędy w trakcie sprawdzania kodu.
(cid:120) Nagradzanie testerów za liczbę zgłoszonych błędów. To zachęca do nadmiernej drobiazgowo-
ści i tworzenia mało wartościowych raportów. Ponadto zniechęca to testerów do współpracy
z programistami, ponieważ buduje między obiema grupami antagonistyczne nastawienie.
(cid:120) Ocenianie pracy analityków biznesowych na podstawie ilości napisanej dokumentacji, a nie
według wiedzy przekazanej zespołowi.
Ostatecznie pracę całego zespołu należy oceniać na podstawie dostarczonego produktu, a nie we-
dług pełnionych funkcji. Oczywiście jeśli programista wykonuje kiepską pracę lub dezorganizuje
projekt, przełożony powinien zwrócić mu na to uwagę. Pracowników należy oceniać na podsta-
wie ich wkładu (albo jego braku) w realizowanie celów całego zespołu. Jednak zdecydowanie nie
wolno zniechęcać ich do wykraczania poza przypisane im role. W odpowiednim środowisku nale-
ży nagrodzić programistę, który dostrzegł pominięty aspekt problemu biznesowego, oraz testera,
który wykrył usterki w kodzie lub architekturze i poinformował o tym zespół. W tym modelu wszy-
scy członkowie zespołu otrzymują potrzebne wsparcie, a projekt ma większe szanse powodzenia.
Komunikacja i współpraca
(cid:95)
73
Poleć książkęKup książkęWyczerpująca dokumentacja i macierze śledzenia są wyjątkowo podstępnym źródłem problemów
związanych ze środowiskiem i wsparciem w zespole. Zamiast budować atmosferę zaufania, zachę-
cają do „chronienia swojego tyłka”. Zespół przyjmuje wtedy podejście oparte na negocjowaniu
kontraktu zamiast na współpracy z klientem.
Tester dbający o „chronienie tyłka” poświęca czas na upewnianie się, że dla każdego wymagania
istnieje test, i to niezależnie od tego, czy pomaga zapewnić wysoką jakość oprogramowania. Pro-
gramiści z takim nastawieniem dosłownie traktują wymagania bez zastanawiania się nad tym, czy
pisany kod jest wartościowy dla użytkowników. Dzieje się tak, ponieważ w środowisku, w którym
ważne jest „chronienie tyłka”, próba zbudowania czegoś, co jest klientowi naprawdę potrzebne,
może prowadzić do nagany za tworzenie oprogramowania niezgodnie ze specyfikacją. Analitycy
biznesowi i właściciele produktu „chronią tyłek”, upewniając się, że zakres prac i wymagania są
do siebie precyzyjnie dopasowane. Często pomijają przy tym wartościowe, ale kłopotliwe wyma-
gania, które nie wynikają bezpośrednio z istniejącej dokumentacji.
„Chronić tyłki” najczęściej muszą członkowie zespołów pracujący w środowisku, w którym zmia-
na jest traktowana jak coś złego. Gdy zespół posługuje się wyczerpującą dokumentacją, łatwo jest
postrzegać zmiany jako niekorzystne zjawisko, ponieważ wymagają one ponownej oceny zakresu
prac, zaktualizowania specyfikacji, zmodyfikowania projektu, poprawienia macierzy śledzenia itd.
To prowadzi do podziałów, gdyż kierownicy w takich firmach starają się znaleźć kozła ofiarnego,
którego można obwinić o dodatkową pracę związaną ze zmianą. Ludzie w takim zespole starają się
pisać zabezpieczającą ich dokumentację, aby chronić się przed obwinieniem. To zmusza wszystkich
w grupie do „chronienia tyłków”. Każdy dba wtedy o to, by móc wskazać fragment dokumentacji,
do którego się stosował. Pozwala to uniknąć złej oceny lub nagany.
Odwrotnością „chronienia tyłka” jest zaufanie. Jeśli w firmie przygotowywana jest tylko minimalna
dokumentacja niezbędna w projekcie, powstaje środowisko, w którym zespołowi wierzy się, że
w obliczu zmian podejmie właściwe decyzje. Stosujący zwinne podejście zespół z nastawieniem
„wszyscy płyniemy na jednej łodzi”, w którym to zespole w razie niepowodzenia wszyscy czują się
za to odpowiedzialni, nie potrzebuje „chronić tyłków”. Łatwiej jest wtedy radzić sobie ze zmia-
nami, ponieważ nie trzeba przygotowywać niepotrzebnej dokumentacji. Zamiast tego można
rozwiązać problem za pomocą bezpośredniej komunikacji i zapisywać tylko niezbędne informacje.
Zespół może tak pracować, bo wie, że firma wierzy w jego kompetencje — nawet jeśli konieczne
jest przedłużenie terminu wykonania projektu.
Lepsza komunikacja w projekcie czytnika e-booków
W projekcie czytnika e-booków z pewnością przyda się lepsza komunikacja. Pamiętasz intensyw-
ne spotkania, na których analitycy biznesowi starannie tworzyli rozbudowany zestaw wymagań?
Początkowo nikt nie traktuje go jako wyrafinowanego narzędzia do „chronienia tyłka”. Wszyscy
w zespole szczerze wierzą, że dzięki wielodniowym dyskusjom na temat każdego szczegółu opro-
gramowania uda się uwzględnić wszystkie zagadnienia, co pozwoli zbudować możliwie najlepszy
produkt. Ponieważ poświęcono na specyfikację tyle czasu, każdy jest gotów trzymać się jej i bronić,
nawet jeśli się okaże, że końcowy produkt może nie odnieść sukcesu rynkowego. Gdyby zespół
74
(cid:95)
Rozdział 3. Zasady Agile
Poleć książkęKup książkępotrafił dokładnie przewidzieć, czego użytkownicy będą potrzebowali za dwa lata, takie podejście
świetnie by się sprawdziło! Szkoda tylko, że tak się nie stało. Przynajmniej nikt nie stracił pracy,
bo wszyscy potrafili udowodnić, że ściśle trzymali się specyfikacji.
Co by się stało, gdyby zespół od początku posługiwał się lepszym modelem komunikacji? Jakie
zmiany są możliwe, gdy zamiast przygotowywać kompletny zestaw wymagań, zespół zapisuje jedy-
nie minimalną dokumentację, niezbędną do rozpoczęcia pracy? Odpowiedzią jest rysunek 3.5.
Rysunek 3.5. Gdy zespół w większym stopniu polega na bezpośrednich rozmowach i korzysta z minimalnej
ilości dokumentacji potrzebnej do zbudowania projektu, wszystkim łatwiej jest uzgodnić informacje
Członkowie zespołu muszą sobie ufać, aby podejmować właściwe decyzje. Byłoby to bardzo pomocne
w trakcie prac nad formatem e-booków, gdyż pozwoliłoby to uniknąć przywiązania do nieaktual-
nego formatu ustalonego na początku projektu i w zamian wprowadzić nowszy format. Jeszcze
lepsze jest to, że w momencie rozpoczęcia pracy nad sklepem internetowym może być już oczywi-
ste, iż nie jest to dobry pomysł. Wtedy można po prostu z niego zrezygnować. Nie jest to jednak
dopuszczalne, gdy sklep jest częścią dokumentacji, której zespół musi się trzymać. Lepsza komu-
nikacja pozwala aktualizować projekt i dostarczyć bardziej wartościowy produkt.
Wyobraź sobie, jak może to wyglądać w zespole pracującym nad czytnikiem. Teraz pracownicy mają
lepsze nastawienie do dokumentacji, ponieważ stanowi ona znacznie mniejsze obciążenie. Zespół
uważa, że może zaoszczędzić dużo czasu dzięki lepszej komunikacj
Pobierz darmowy fragment (pdf)