Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00127 006902 22754935 na godz. na dobę w sumie
wyszukaj dokładnie | pobierz wtyczkę
Agile. Przewodnik po zwinnych metodykach programowania - ebook/pdf
Agile. Przewodnik po zwinnych metodykach programowania - ebook/pdf
Autor: , Liczba stron: 352
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-283-0943-2 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> techniki programowania
Porównaj ceny (książka, ebook (-50%), audiobook).
Czytaj online.
Komentuj

Poznaj nowoczesne podejście do wytwarzania oprogramowania!

W XXI wieku ogromnie wzrosło tempo rozwoju cyfrowych usług. Tradycyjne sposoby wytwarzania oprogramowania nie są już w stanie nadążyć za oczekiwaniami klientów. Dziś nikt nie będzie czekał, aż dopracujesz wszystkie zaplanowane funkcje i wypuścisz produkt na rynek. Konkurencja Cię wyprzedzi! Czy dasz się jej pokonać? Odpowiedzią na to pytanie jest słowo, które robi furorę w branży IT: Agile. Zwinne wytwarzanie oprogramowania to przyszłość — przekonaj się sam!

W ramach Agile istnieje wiele podejść do wytwarzania oprogramowania. Jeżeli zastanawiasz się nad tym, które najlepiej zadziała w Twoim środowisku, trafiłeś na odpowiednią książkę. Znajdziesz w niej omówienie ścieżek takich jak Scrum, Lean, Kanban oraz XP (ang. eXtreme Programming), ale najpierw poczytasz trochę na temat tego, czym jest zwinność i do czego możesz ją wykorzystać. Poznasz zalety i zagrożenia związane z konkretnymi podejściami oraz obszary, w których każde z nich sprawdzi się najlepiej. Ta książka pozwoli Ci zmienić sposób pracy. Dzięki niej masz szansę stworzyć wyjątkowo produktywny zespół, którego nikt nie zatrzyma. Bądź zwinny!

Sprawdź, jak wykorzystać siłę zwinności!

Znajdź podobne książki Ostatnio czytane w tej kategorii

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)

Gdzie kupić całą publikację:

Agile. Przewodnik po zwinnych metodykach programowania
Autor: ,
Sklep
Format
Cena
Helion.pl Helion.pl
ebook/pdf
29,50 zł
Idź do sklepu »

Opinie na temat publikacji:

Inne popularne pozycje z tej kategorii:

Czytaj również:

Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: