Planowanie

Opowiadania użytkowników

Opowiadania użytkowników (ang. user stories) mają takie same zastosowanie, jak schematy tzw. przypadków użycia (ang. use cases), ale znacznie się różnią. Są używane m.in. aby określić szacunkowy czas, jaki należy poświęcić na spotkanie w celu opracowania planu nowej wersji. Są także używane zamiast dużego dokumentu zawierającego wszystkie spisane wymagania. Opowiadania te są pisane przez klientów po prostu jako spis rzeczy, które nasz system powinien robić dla nich. Są podobne do scenariuszy użycia, ale nie ograniczają się do opisywania interfejsu użytkownika. Są przeważnie w formacie trójzdaniowych akapitów tekstu napisanych przez klienta, używających jego słownictwa, bez technicznej terminologii.

Opowiadania te sterują także tworzeniem testów akceptacyjnych. Testy te mają za zadanie stwierdzić, czy oczekiwania użytkowników zostały poprawnie zaimplementowane.

Jednym z największych powodów nieporozumień są różnice pomiędzy opowiadaniami, a specyfikacji wymagań. Główną cechą odróżniającą te dwa podejścia jest poziom szczegółowości opisu. Historie użytkowników powinny zapewniać tylko taką ilość szczegółów, jaka jest wystarczająca do rozsądnego oszacowania czasu potrzebnego na ich implementację. Gdy nadejdzie czas implementacji danego opowiadania wykonawcy po prostu skontaktują się z klientem i otrzymają dokładniejszy opis wymagań.

Projektanci ocenią jak długo będzie trwała implementacja oczekiwań. Każde opowiadanie zabierze nam 1, 2 lub 3 tygodnie pracy, oczywiście, jeśli wszystko pójdzie idealnie. Ten wzorcowy czas wykonania mówi nam jak długo zajęłoby jego wprowadzenie, gdyby nie było żadnych przerw, żadnych innych zadań i byśmy dokładnie wiedzieli, co jest do zrobienia. Jeśli czas może być dłuższy niż 3 tygodnie, to wymagane jest podzielenie naszej historii na mniejsze fragmenty. Jeśli jest krótszy niż 1 tydzień i wiesz, że sprawa jest drobiazgowa, połącz kilka streszczeń. Około 80 opowiadań (?20) jest doskonałą ilością do opracowania planu wersji.

Inną cechą różniącą opowiadania i specyfikację wymagań jest akcent na potrzeby użytkownika. Powinieneś unikać szczegółów specyficznych technologii, struktury bazy danych i algorytmów. Powinieneś próbować utrzymać historie skoncentrowane wokół potrzeb i korzyści klienta, nie wdając się na tym etapie w szczegóły samego interfejsu aplikacji.

Planowanie publikacji

Zwołujemy okresowe spotkania w celu opracowania planu publikacji. Służą one ustaleniu kierunku rozwoju projektu - plan ten jest następnie używany przy określaniu kolejnych iteracji. Zebraniem kieruje zbiór reguł, zezwalający wszystkim ludziom zaangażowanym w tworzenie projektu na podejmowanie decyzji w zależności od ich kompetencji. Zasady te definiują metody negocjacji planu i jego zatwierdzenia.

Opowiadania użytkowników i oblane testy są przekładane na zadania programistyczne, które je zapewnią. Zadania są zapisane na kartach. Karty te określają szczegółowy plan iteracji.

Podstawowym punktem spotkania jest ocenienie każdego opowiadania i przypisanie mu liczby, określającej szacunkową ilość tygodni potrzebnych do jego realizacji. Liczba ta nie uwzględnia żadnych innych obowiązków i wynikłych z nich opóźnień, zakładamy idealną sytuację, gdy możemy poświęcić cały dostępny czas na jego realizację. Nie bierzemy pod uwagę żadnej dodatkowej pracy, ale wliczamy testowanie. Odbiorca decyduje, które opowiadania są ważniejsze lub mają większy priorytet wykonania.

Historie użytkowników są drukowane lub spisywane na kartach. Developerzy i klienci rozmieszczają karty na stole wybierając zestaw opowiadań, które mają być zaimplementowane jako pierwsze, w tej, a które dopiero w kolejnej wersji. Użyteczny system do testowania, dostarczający wcześnie nowe wersje aplikacji byłby pożądany.

Możesz planować określając czas lub zakres realizacji. Za pomocą szybkości projektowania możesz wyznaczyć ile opowiadań może zostać zaimplementowanych w ciągu zadanego czasu lub jak długo zajmie ukończenie prac nad danym zbiorem (zakresem) opowiadań. Jeśli planujesz określając czas, mnożysz liczbę iteracji przez prędkość projektowania obliczając ilość opowiadań zdolnych do realizacji. Jeśli planujesz określając zakres opowiadań, podziel sumę tygodni oszacowaną na ich podstawie przez prędkość projektowania. Uzyskasz wtedy liczbę iteracji potrzebnych do ukończenia wersji.

Poszczególne iteracje są planowane dokładnie tuż przed ich rozpoczęciem, nigdy nie ustalamy ich przebiegu z góry. Spotkania prowadzone w celu opracowania planu wersji, zwane także grą (ang. planning game) mają swoje reguły, których opis można znaleźć w repozytorium wzorców Portland.

Kiedy plan publikacji zostanie już ukończony, ale nie spodoba się kierownictwu kusząca staje się myśl o zmianie czasów realizacji opowiadań. Nie wolno tak robić! Opowiadania zostały dobrze ocenione i wymaga się, aby w takim stanie zostały uwzględnione na spotkaniu związanym z planowaniem iteracji. Zamiast tego opracujcie nowy plan publikacji, akceptowalny przez wszystkie strony. Negocjujcie aż zarówno developerzy, klienci jak i kierownictwo zgodzą się na jego przebieg.

Główną filozofią planowania publikacji jest opisywanie projektu czterema wielkościami: zakresem, zasobami, czasem i jakością. Zakres określa jak dużo jest do zrobienia. Zasoby oznaczają ile mamy dostępnych ludzi. Czas mówi nam kiedy projekt lub wersja będzie ukończona. Jakość natomiast opisuje jak dobre będzie nasze oprogramowanie i jak dokładnie zostanie ono przetestowane.

Kierownictwo może określić tylko trzy z nich. Czwartą dostajemy już zawsze podczas samej realizacji. Zauważ, że obniżenie jakości poniżej doskonałości ma nieprzewidywalny wpływ na trzy pozostałe cechy. W istocie mamy więc tylko 3 parametry, które aktualnie możemy chcieć zmienić. Niech developerzy zapanują także nad pragnieniem klientów chcących, aby projekt został natychmiast ukończony poprzez zaangażowanie naraz zbyt wielu ludzi do pracy.

Plan wydania

Po spisaniu opowiadań użytkowników możecie zwoływać spotkania w celu stworzenia planu publikacji. Plan wersji wyznacza dokładnie, które historie mają zostać wprowadzone w danej wersji systemu i kiedy można się tego spodziewać. Daje użytkownikom zestaw opowiadań do wyboru podczas planowania iteracji, które z nich zostaną zaimplementowane podczas najbliższej z nich. Wybrane historie są przekładane na odrębne zadania programistyczne do zaimplementowania w czasie iteracji.

Opowiadania są także przekładane na testy akceptacyjne podczas iteracji. Testy te są uruchamiane w czasie bieżącej i późniejszych iteracji w celu weryfikacji, kiedy historie zostały ukończone prawidłowo i można kontynuować dalszą pracę.

Gdy tempo projektowania drastycznie spadnie w przeciągu dwóch lub kilku iteracji wyprzedź kolejne zdarzenia i wyznacz spotkanie z klientami na którym ustalisz nowy plan wersji.

Plan publikacji był wcześniej nazywany planem zobowiązań (ang. commitment schedule). Nazwa ta została zmieniona na taką, która dokładniej opisuje jego przeznaczenie i w bardziej logiczny sposób nawiązuje do planu iteracji.

Regularnie publikuj nowe wersje

Twórcy projektu muszą regularnie wypuszczać nowe wersje swojego systemu. Wynika to z iteracyjnego podejścia do projektowania. Częste spotkania poświęcone planowaniu nowych wersji służą ujawnieniu drobnych elementów funkcjonalności, które mogą być w najbliższym czasie zaimplementowane. Klient na bieżąco ma dostęp do aktualnej wersji naszego środowiska i dzięki temu może dzielić się wartościowymi spostrzeżeniami z wykonawcami projektu. Im dłużej będziesz czekał na wprowadzenie ważnego elementu do systemu, tym mniej czasu będziesz miał na jego dopracowanie.

Szybkość projektowania

Prędkość projektowania (ang. project velocity) jest miarą określającą jak szybko ukończycie swój projekt. Często używamy tutaj współczynnika obciążenia (ang. load factor), ale prędkość projektowania wydaje się być znacznie prostszą w użyciu. Jeśli to pomoże, użyjcie współczynnika obciążenia i na jego podstawie określcie szacunkową prędkość projektowania, którą wykorzystacie.

Aby wyznaczyć tempo projektowania po prostu zliczcie ile opowiadań użytkowników lub ile zadań do zaimplementowania zebraliście podczas bieżącej iteracji.

Podczas spotkania planującego wersję możemy użyć ilości opowiadań, które zostały już wprowadzone w życie do oszacowania ile z pozostałych (i nowych) historii zostanie zaimplementowanych w najbliższym czasie.

Podczas spotkania planującego iterację twórcy mają prawo przypisać odpowiednią liczbę dni do prac nad zadaniem, równą prędkości projektowania zmierzonej podczas poprzedniej iteracji.

Ten prosty mechanizm pozwala twórcom odnaleźć się po trudnej iteracji. Szybkość tworzenia projektu rośnie, gdyż pozwalamy developerom na dopytywanie się klientów o kolejne historie, kiedy ich bieżąca praca zostanie wykonana wcześniej i nie ma żadnych innych zadań oczekujących na wykonanie.

Nie kłopotajcie się dzieląc prędkość projektowania przez długość iteracji czy liczbę programistów. Ta wartość w żadnym razie nie może służyć do porównania wydajności różnych projektów, ponieważ każdy zespół projektantów może wprowadzać różne odchyleniami do szacunkowej sumy opowiadań i zadań, niekiedy zawyżają, a kiedy indziej mogą zaniżyć. Na dłuższą metę to nie ma znaczenia. Śledzenie ilości wykonanej pracy podczas każdej z iteracji jest kluczem do utrzymania tempa projektowania na tym samym poziomie.

Można spodziewać się kilku skoków prędkości projektowania, zarówno w górę jak i w dół. Ale jeśli prędkość ta dramatycznie zmieni się na czas dłuższy niż jedna iteracja, powinniście wykorzystać spotkania, związane z planowaniem nowej wersji, aby ponownie ocenić i przenegocjować plan ich tworzenia. Gdy ponownie rozpoczną się pracę nad systemem, spodziewajcie się kolejnej zmiany prędkości, wynikającej z konieczności ponownego podjęcia się zadań.

Współczynnik obciążenia

Współczynnik obciążenia jest równy rzeczywistym, kalendarzowym dniom niezbędnym do zrealizowania danego zadania, podzielonym przez, wyliczoną przez developerów, liczbę dni tzw. "idealnych". Aby zrozumieć to pojęcie, pomyśl o zadaniu, którego rozwiązanie zajęłoby ci jeden dzień, oczywiście pod warunkiem, że skupiasz się jedynie na nim i nic Cię nie rozprasza. A teraz wyobraź sobie, że starasz się to zrealizować w praktyce, w rzeczywistości. Współczynnik obciążeniowy określa liczbę dni, jakie rzeczywiście zajmie ukończenie tego zadania.

Współczynniki (czynniki) od 2 do 5 to norma. Jeśli musisz odgadywać, jakiego czynnika potrzebujesz, aby rozpocząć zadanie, powinieneś rozważyć użycie odpowiedniej technologii i skorzystać z doświadczenia innych ludzi. Współczynnik 2 rokuje optymistycznie, 3 to technologia typowa. Czwórka i piątka natomiast używane są w projektach wymagających użycia technologii nietypowej. Ron Jeffries radzi używania trójki w początkowej fazie nowego projektu.

Następnie musisz zmierzyć i śledzić współczynnik obciążenia, a najlepiej jeszcze - tempo programowania w trakcie całego projektu.

Współczynnik obciążenia nie może być używany do porównywania dwóch projektów Każdy projekt, jak też zespół nad nim pracujący jest niepowtarzalny i będzie miał inne współczynniki obciążenia.

Jeśli współczynnik zmieni się w sposób dramatyczny, zwołajcie spotkanie aby ponownie ocenić i przenegocjować plan publikacji. Należy się spodziewać, że kiedy system ruszy, współczynnik ponownie ulegnie zmianie z powodu zdań podtrzymujących.

Iteracyjna rozbudowa

Rozbudowa projektu poprzez iteracje (ang. iterative development) dodaje element zwinności procesowi tworzenia. Podzielcie swój plan zajęć na mniej więcej tuzin iteracji, każda o długości od 1 do 3 tygodni.

Nie planujcie swoich zadań z góry, na zapas. Zamiast tego na początku każdej iteracji stosujcie spotkania poświęcone jej planowaniu, aby określić co w danym kroku powinno być zrobione.

Jest to przeciwieństwo do reguły patrzenia naprzód i próby implementacji czegokolwiek, co nie jest zaplanowane na bieżącą iterację. Będzie mnóstwo czasu na implementację tej funkcjonalności, kiedy stanie się bardziej znaczącą sprawą, uwidocznioną w planie wersji.

Jeśli nigdy nie będziecie zawczasu dodawać funkcjonalności i praktykować planowanie na bieżąco, będziecie mieli łatwiej utrzymać się w czołówce zmieniających się wymagań użytkownika.

Planowanie iteracji

Spotkanie poświęcone planowaniu jest zwoływane na początku każdej iteracji w celu opracowania jej planu, uwzględniającego zadania dla programistów. Każda iteracja trwa przez okres od 1 do 3 tygodni. Klient wybiera opowiadania z planu wersji, które powinny być zaimplementowane podczas bieżącej iteracji, w kolejności od najbardziej dla niego znaczących. Są także wybierane do załatwienia testy akceptacyjne, które zakończyły się niepowodzeniem.

Opowiadania użytkowników i oblane testy są przekładane na zadania programistyczne, które je zapewnią. Zadania są zapisane na kartach. Karty te określają szczegółowy plan iteracji.

Każde z zadań powinno wymagać od 1 do 3 "idealnych dni" do wykonania. Pisząc "idealny dzień" mamy na myśli czas bez uwzględnienia niespodziewanych sytuacji, mogących przerwać pracę. Zadania, które trwają krócej niż 1 dzień, mogą zostać połączone w jedną grupę. Zadania trwające dłużej niż 3 dni powinny zostać ponownie przeanalizowane.

Developerzy podpisują się pod zadania i oceniają ile czasu im zajmie ich ukończenie. Ważny jest fakt, że osoba podejmująca się zadania sama określa jak długo zajmie jego wykonanie.

Wcześniej określona prędkość projektowania jest używana, aby określić czy iteracja jest już zamknięta czy jeszcze nie. Suma dni potrzebnych na realizację zadań nie może przekroczyć prędkości projektowania z poprzedniej iteracji. Jeśli bieżąca iteracja jest za duża, klient musi wybrać część opowiadań do odłożenia do czasu następnej (ang. snow plowing).

Jeśli iteracja jest za mała można zaakceptować inne opowiadania. Prędkość w dniach i zadaniach (planowanie iteracji) ma większe znaczenie niż prędkość w tygodniach i opowiadaniach (planowanie publikacji), gdyż jest bardziej dokładna.

Przerzucanie opowiadań użytkowników z jednej iteracji na drugą może być często odbierane jako alarmujące. Bez obawy. Przypomnij sobie znaczenie arkuszy testujących i refaktoryzacji. Długi i niedopełnienia na jednym z tych poziomów mogą znacznie spowolnić cały proces. Unikaj dodawania jakiejkolwiek funkcjonalności dopóki nie zostanie ona zaplanowana. Po prostu dodaj to co potrzebujesz teraz. Dodawanie czegoś "ekstra" może tylko spowolnić twoją pracę.

Niech nie kusi was skrócenie czasu potrzebnego na wykonanie zadań i realizację opowiadań. Proces planowania polega na szacunkowych obliczeniach i nie uwzględnia wszystkich aspektów. Takie drobne zmiany mogą spowodować wiele problemów.

Obserwujcie prędkość projektowania i przekładanie opowiadań. Może będziecie musieli ponownie ocenić wszystkie opowiadania i przenegocjować plan publikacji co każde 3 do 5 iteracji, to normalne. Jak długo będziecie zawsze najpierw implementować najbardziej wartościowe opowiadania, tak długo będziecie robić najlepsze z możliwego dla swojego klienta i kierownictwa.

Rozwijanie projektu poprzez iteracje nadaje zwinności całemu procesowi. Spróbujcie planowania na bieżąco, zamiast wybiegać ze szczegółowymi zadaniami dla programistów poza bieżącą iterację.

Przenoszenie ludzi między zadaniami

Zmieniaj ludzi pracujących nad projektem, by uniknąć znaczącego odpływu wiedzy lub wystąpienia wąskiego gardła kodowania. Może zdarzyć się sytuacja, gdy jedyna osoba pracująca nad wyznaczonym zadaniem zdecyduje odejść z zespołu lub, gdy po prostu masz mnóstwo rzeczy czekających na zrealizowanie. Wówczas możesz stwierdzić, że projekt wlecze się w żółwim tempie.

Różne firmy często poważnie rozważają możliwość tzw. "szkoleń poprzecznych" (ang. cross training) by uchronić te obszary wiedzy, które łatwo jest utracić. Gdy zmieniasz ludzi pracujących w obrębie głównego kodu, a dodatkowo łączysz to jeszcze z programowaniem w parach, to właśnie stosujesz metodę "szkoleń przemiennych". Sytuacja zmienia się z takiej, gdy jedna osoba wie wszystko o danej sekcji kodu, na taką, gdzie wszyscy znają większą część kodu w poszczególnych sekcjach.

Zespół jest o wiele bardziej "elastyczny?, jeśli wszyscy posiadają wystarczającą ilość informacji o każdej części systemu, który jest opracowywany. Zamiast posiadać małą grupkę osób przeciążonych pracą w trakcie, gdy reszta zespołu nie ma nic do roboty, możesz uczynić produktywnym cały zespół. Dowolna ilość developerów może zostać przypisania najbardziej pracochłonnym zadaniom. Płynne balansowanie takim przepływem jest spełnieniem marzeń menadżera.

Staraj się po prostu zachęcać, by każda osoba z zespołu spróbowała popracować nad nową częścią projektu, lub przynajmniej nad częścią danej iteracji. Taką możliwość daje, bez obawy utraty produktywności pracy, programowanie w parach. Metoda ta zapewnia ponadto ciągłość wymiany myśli i pomysłów. Jeśli zachodzi taka potrzeba, jedna osoba z pary może zostać "wymieniona" na kogoś innego i wówczas ta druga kontynuuje pracę z nowym partnerem.

Codzienne "spotkania na stojąco".

Podczas typowego spotkania dotyczącego projektu, większość uczęszczających na nie ludzi nie wnosi do niego niczego konkretnego, a przychodzi tylko by usłyszeć końcowe wnioski. Znaczna część czasu developera tracona jest więc na trywialne rozmowy. Gdy znaczna liczba osób uczęszcza na takie spotkania, niepotrzebnie marnotrawione są środki i energia potrzebna do tworzenia projektu a ponadto wyłania się koszmarna konieczność tworzenia planu.

Głównym założeniem "spotkań na stojąco" jest efektywna komunikacja pomiędzy członkami zespołu. Codzienne poranne spotkania, mają na celu mówienie o napotkanych problemach, możliwych rozwiązaniach a także motywowanie zespołu do koncentrowania się na sprawach najistotniejszych. Wszyscy zebrani stoją w kole, co pozwala uniknąć długich dyskusji i jest bardziej efektywne - lepiej zorganizować jedno krótkie ale obowiązkowe spotkanie, niż urządzać ich wiele, na których obecnych jest zaledwie kilku developerów.

Jeśli urządzacie takie właśnie spotkania, obecność na jakichkolwiek innych spotkaniach zależy od tego czy dana osoba jest tam naprawdę niezbędna i czy wnosi ona coś konkretnego do projektu. W takiej sytuacji możliwe jest nawet uniknięcie planowania większości spotkań. Mogą być one urządzane spontanicznie, przed komputerem, gdzie można na miejscu testować kod a nowe pomysły od razu wcielać w życie.

Takie spotkanie, to nie kolejne zebranie gdzie marnuje się czyjś czas. Zastąpi ono wiele innych, pozwalając ponadto na oszczędności kilka razy przewyższające czas jego trwania.

Napraw XP, kiedy się zepsuje

Usprawnij (napraw) proces, kiedy zawiedzie. Nie mówimy "jeśli", ponieważ już teraz wiadomo, że twój projekt będzie wymagał pewnych zmian. Na dobry start przestrzegaj zasad XP, ale nie wahaj się wprowadzić zmian, jeśli coś nie funkcjonuje prawidłowo. Należy przestrzegać reguł do momentu, gdy zmieni je zespół. Nie znaczy to jednak, że może on robić cokolwiek zechce. Developerzy muszą dokładnie wiedzieć, czego mogą się spodziewać od siebie nawzajem. Trzymanie się ustalonego zestawu zasad to jedyny sposób, aby sprostać tym wymaganiom. Odbywajcie spotkania, na których można ustalić, co działa a co nie, oraz obmyślić możliwości ulepszania XP.