Battle for Agility

Planować czy startować?

Wydaje mi się, że dosyć mocno rozpowszechnione jest przekonanie, że techniki agile są chaotyczne i nie ma w nich miejsca na stary dobry plan. Nic bardziej mylnego! Chodzi o to, że nie bardzo jest w nim miejsce na stary “wielki” plan. Tradycyjne metodyki zarządzania projektami jaskrawo zaznaczają granice faz w cyklu życia projektu oraz nadmiernie wydłużają czasy ich trwania. To co chcemy osiągnąć, to szybki start projektu. Chcemy podzielić projekt na krótkie etapy (iteracje, sprinty, wszelkie inne nazwy dozwolone). Każdy etap stanie się dla nas mini projektem, który będzie zawierał pełne spektrum czynności - od planowania i projektowania po implementację bardzo mocno wspartą testami. Niby nic, a jednak to sprowadzenie dużych problemów do takiej mikro skali doskonale się sprawdza. Systemy które tworzymy są coraz bardziej skomplikowane. Coraz trudniej też przewidzieć wszystko na początku projektu. Ryzyko pomyłki jest wtedy bardzo duże, a zabrnięcie w ślepy zaułek kosztowne. Iteracyjne podejście pozwala zminimalizować ryzyko pomyłek i obniżyć koszty zmian.

Czy potrzebny jest nam szczegółowy plan?

Ostatnio oglądałem wywiad “Running Tested Features” podczas, którego Ron Jeffries użył pewnego wykresu dla zaprezentowania różnicy między długą fazą planowania na początku projektu oraz podejściem polegającym na konsekwentnym dostarczaniu klientowi kolejnych przybliżeń jego produktu. Poniżej drobna mutacja tego wykresu.

Nie ukrywam, że takie postawienie sprawy jest pewnym uproszczeniem, ale trafnie oddaje jeden z aspektów iteracyjnego podejścia do problemu i szybkiego startu implementacji.

Punkt przecięcia czarnych przerywanych linii wyznacza nasz cel - dostarczenie określonej funkcjonalności w danym terminie (typowy problem biznesowy, gdzie data wejścia na rynek jest z góry określona i na jej ustalenie ma wpływ wiele nietechnicznych czynników).

Punkt A wyznacza czas zakończenia fazy planowania (np. zamknięcie specyfikacji) i uruchomienie fazy implementacji. Aby zdążyć dostarczyć pełny produkt w wyznaczonym terminie musimy zakładać dość szybkie tempo “wspinania się” po osi funkcjonalności aby trafić w wyznaczony punkt w terminie B (tempo tym szybsze im dłużej trwa planowanie). Poza tym bardzo rzadko wychodzi tak, że zgodnie z planem dostarczamy pełną oczekiwaną przez klienta funkcjonalność. Zwykle po momencie B ciągnie się jeszcze faza poprawek i modyfikacji (więc czerwona linia w momencie B zwykle jest poniżej zakładanego zestawu funkcjonalności).

Stosując podejście iteracyjne zakładamy, że w możliwie krótkich odstępach czasu staramy się dostarczać klientowi kolejne elementy zamówionej funkcjonalności. Bardzo ważnym aspektem (który ma wpływ na planowanie w procesie agile) jest to, że zawsze staramy się dostarczyć klientowi coś co jest on w stanie zweryfikować, coś co stanowi dla niego jakiś użyteczny element systemu (dla przykładu kompletny projekt bazy danych nie stanowi dla klienta wartości użytkowej bez pozostałych warstw systemu). Zaczynając od początku dostarczać funkcjonalności zmniejszamy nachylenie krzywej (kolor niebieski), czyli teoretycznie pozwalamy sobie na spokojniejsze tempo. Tak faktycznie to tempo nie jest wolniejsze tylko trochę bardziej realne do utrzymania. Jeśli okaże się, że to jest właśnie tempo jakie będzie w stanie osiągnąć zespół to przy długim planowaniu nie zdążymy z funkcjonalnością (przerywana linia czerwona).

Linia niebieska w praktyce oscyluje raz powyżej, raz poniżej prostej prowadzącej do punktu przecięcia zakresu funkcjonalności i terminu. Ta oscylacja może wynikać np. z drobnego mijania się z koncepcją klientów/użytkowników, konieczności korekty projektu systemu, tak aby spełniał nowe pojawiające się po każdym etapie wymagania. Tempo takiej pracy na pewno okaże się wolniejsze niż po dokładnym projekcie, bo trzeba więcej w iteracjach eksperymentować. Jestem jednak przekonany, że iteracyjne projektowanie + refaktoryzacja kodu nie zajmą aż tyle czasu, żeby nie dało się go utrzymać na wymaganym poziomie. Pytanie czy przy mozolnym planowaniu i projektowaniu wszystkiego naprzód da się skończyć w pozostałym czasie.

1 comment December 20th, 2006

Zwinne działania zaczepne

Ponarzekałem sobie już sporo na skostniałe metody podejścia do projektów. Może nawet znajdziesz w tych narzekaniach trochę merytorycznych argumentów popierających przedstawiane tutaj tezy. Ale w końcu trzeba przejść do konkretów. Zaczynamy nowy projekt. Co zrobić aby wprowadzić do niego jak najwięcej praktyk agile. Po pierwsze nie należy starać się wprowadzać zbyt dużej liczby nowych elementów na raz. Wiele razy można było się spotkać z dyskusjami na temat tego, “jak bardzo agile się już jest”. Moim zdaniem dobry proces czerpiący ze zwinnych metodyk powinien przejawiać się w następujących aspektach:

• nastawienie na zmiany, jako naturalną kolej rzeczy (to jedna z cech przewodnich praktyk agile)
• iteracyjność przejawiająca się również (a może przede wszystkim) w samym wprowadzaniu agile do projektu - stosujmy te same praktyki na poziomie doskonalenia procesu, jak i na poziomie implementacji i doskonalenia samego systemu
• minimalizm w podejmowanych działaniach i maksymalizm w osiąganych efektach - najczęściej mylnie kojarzony tylko ze skracaniem czasu i obniżaniem kosztów pracy, podczas gdy chodzi także o ciągłe podwyższanie jakości i kompletności produktu oraz o doskonalenie “warsztatu”.

Wykonujemy pracę coraz szybciej i taniej nie dlatego, że robimy coraz słabsze systemy, tylko dlatego, że jesteśmy coraz lepsi, tak jak nasz lekki proces. Tak więc małymi krokami do celu. Proces wdrażania agile można zacząć od dołu, czyli od nas programistów. Nie koniecznie trzeba też od razu uświadamiać wszystkich managerów. Próbujemy wykonać mały krok. Jak się uda pochwalimy się sukcesem. Managerów od razu uspokajam… nie będę proponował samowoli, rewolucji, czy innych działań wywrotowych. Raczej nazwijmy je na razie drobnymi działaniami zaczepnymi. Pewne rzeczy można zrobić inaczej i to się opłaca. A zaczniemy od początku - czyli od szacowania i planowania.

Przed uruchomieniem projektu czas na krótki rekonesans - dochodzi do oszacowania zakresu i pracochłonności projektu (tak… trzeba klientowi podać cenę, a nie chcemy sobie strzelać w kolano). To pierwszy moment, kiedy możemy spróbować czegoś agile. Na temat zbierania i analizy wymagań napisano i powiedziano dotąd bardzo wiele. Ale mamy włożyć w to minimum środków, aby osiągnąć jak najlepsze wyniki. Potrzebujemy określić jaki system mamy zbudować.

Zebranie wymagań i zakres projektu

Zadaniem numer jeden będzie zebranie zespołu, który będzie wykonywał projekt i doprowadzenie do spotkania z klientem lub osobami, które będą określały wymagania. Każdy rzeczywisty użytkownik systemu będzie tutaj na wagę złota, ale pracujemy z tym kogo mamy. Podczas tego spotkania chcemy doprowadzić do pewnego rodzaju burzy mózgów wszystkich zebranych.

Pierwszym etapem spotkania będzie określenie, kto będzie użytkownikiem systemu. Chodzi o ustalenie ról użytkowników jacy mogą używać systemu (przerywamy wymyślanie, jeśli zauważymy, że z trudem przychodzą nam do głowy kolejne typy). Efektem może być krótka lista. Na koniec poświęćmy chwilę na ew. wyeliminowanie ról powtarzających się pod nieco inną nazwą, lub na pewną generalizację ról o podobnych zadaniach. Taka lista ułatwi nam realizację kolejnej części spotkania.

Podstawowa zasada - mamy zawsze dostarczać użytkownikom części systemu, które będą mogli użyć. Zaczynamy zastanawiać się jakie funkcjonalności ma ten system posiadać. Głównie opowiadać powinien klient, my dopytujemy o ew. szczegóły lub prosimy o wyjaśnienie niejasnych kwestii (często rzeczy oczywiste dla klienta nie są oczywiste dla programistów). Nie musimy być specjalistami w dziedzinie klienta, mamy się znać na tworzeniu systemów informatycznych. Dlatego pytajmy o wszytko czego nie rozumiemy - wyjaśnienia na tym etapie nic nie kosztują, później będzie gorzej. Sprawny kierownik czy analityk może często pomóc naprowadzać klienta na odpowiedni tor pytaniami, jeśli nie będzie on potrafił określić dobrze swoich potrzeb.

Wymagania będziemy spisywać w formie krótkich zdań objaśniających co użytkownik może lub chce zrobić z systemem (używajmy w tym celu wcześniej wyłowionych nazw ról). Np.:

“Klient sklepu internetowego może dodać do swojego koszyka produkt, którego szczegóły ogląda na stronie.”

“Pracownik BOK może zmienić na życzenie klienta zamówienie o podanym numerze. Wymaga to wcześniejszej autentykacji klienta sklepu”.

Takie krótkie opisy wymagań nazywamy historyjkami użytkownika (ang. user stories). Cała istota tych historyjek polega na tym, że powinny one być doskonale zrozumiałe dla klienta/użytkownika, a jednocześnie powinny stanowić dobry pogląd na to co system ma robić i co trzeba zaimplementować. User stories powinny być w miarę krótkie i powinny odpowiadać pojedynczym funkcjonalnościom, lub zestawom funkcjonalności, które nie mają sensu bez siebie nawzajem. Chodzi o to, żeby dało się je implementować osobno i w dowolnej kolejności. Tradycyjnie do zapisywania user stories polecane są niewielkie papierowe kartoniki (na tyle duże, aby takie user story się zmieściło, ale jednocześnie na tyle małe, żeby nie dało się na nich pisać całych opowiadań). Kartoniki są wygodne również z innego powodu - można je dowolnie mieszać, tasować, przekładać i wreszcie w dowolnej chwili taki kartonik można podrzeć.

Drugą ważną cechą user stories jest to, że zawsze powinny przedstawiać punkt widzenia użytkownika/roli. Dlatego aby zweryfikować czy dobrze myślimy o user story można zadać sobie klika pytań pomocniczych:

• Jak zaprezentuję implementację takiej pojedynczej historyjki klientowi?
• Jak użytkownik będzie mógł użyć tak przedstawionej funkcjonalności?
• Jak przetestować czy ta funkcja działa bez pisania dodatkowego kodu?
• Czy do implementacji tej funkcjonalności będę musiał ruszyć wszystkie warstwy systemu?

Znowu wyciągamy jak największą ilość historyjek od klienta/użytkownika. Kończymy kiedy zaczyna brakować pomysłów na nowe user stories. Cała taka sesja nie powinna trwać więcej niż kilka godzin. Jeśli zadanie jest wyjątkowo duże i skomplikowane, to warto podzielić je na mniejsze (np. podsystemy, moduły) i zorganizować klika sesji tematycznych. Z całą pewnością takie sesje zajmą mniej czasu niż tradycyjne wywiady analityków i tworzenie specyfikacji wymagań. Jeśli zespołowi i klientowi nie odpowiadają kartki, można użyć Excela lub innego prostego narzędzia. Chodzi o to, że nie zależy nam szczególnie na formie, tylko na treści.

To jest pewien model. Jeśli nie uda się go zrealizować za pierwszym razem, to trudno. Najważniejsze na tym etapie jest przejście na zapis wymagań odzwierciedlający punkt widzenia użytkownika, bez zbędnego narzutu technicznego. Z takim bagażem historyjek możemy przejść do szacowania…

Szacowanie czasochłonności

Jest wiele różnych technik szacowania. Najistotniejsze, aby w szacowaniu wzięli udział wszyscy członkowie zespołu, bo to oni potem będą mieli podjąć się realizacji poszczególnych zadań. Jeśli zespół jest niedoświadczony, to można do szacowania zaprosić również jednego czy dwoje bardziej doświadczonych kolegów z innych zespołów.

Szacujemy kolejno każdą z zebranych user stories. Każda osoba na własną rękę. Potem omawiamy krótko rozbieżności - ktoś mógł czegoś nie uwzględniać, albo wręcz przeciwnie - któryś z członków zespołu doskonale zna temat i wie, że pewne elementy można wykonać szybciej.

Największym problemem jest zwykle to w jakiej jednostce szacować? Tutaj pojawia się drugie miejsce gdzie można spróbować zastosować podejście najczęściej spotykane w technikach agile. Szacowanie w jednostkach “idealnych” lub wręcz wyimaginowanych (to drugie jest często wspominane ale osobiście uważam, że przynajmniej na start z agile nie bardzo się ono nadaje). Moja rada jest taka - jeśli do tej pory szacowaliśmy w firmie wszystko w osobogodzinach przechodźmy na idealne godziny programistyczne, jeśli w dniach przechodźmy na dni idealne. Jednym słowem, nie zmieniajmy radykalnie jednostki na jakieś punkty czy coś, do czego nie jesteśmy przyzwyczajeni.

Co to jest idealna godzina/dzień programistyczny? Jest to wyidealizowany czas, który poświęcilibyśmy tylko i wyłącznie na pracę nad wyznaczonym zadaniem. Czas zmierzony z zegarkiem w ręku, kiedy wszystkie nasze czynności wiążą się z wykonaniem zadania. Ĺťadnych rozmów z kolegami, żadnych odpowiedzi na rzucone w salę pytania, żadnych telefonów, kawy czy herbaty w kuchni, papierosa czy nawet wyjścia do toalety. Tylko praca w czystej formie. Każdy rozsądnie myślący człowiek powiedziałby w tym miejscu, że przecież takie dni czy godziny praktycznie się nie zdarzają. I oczywiście tak jest. Co więcej jest to zupełnie naturalne. W takim razie co to ma wspólnego z szacowaniem?

Każdy z nas udzielając odpowiedzi na pytanie “Ile potrwa zdanie X?” może jej udzielić, albo na bazie wcześniejszych doświadczeń związanych z takim samym lub podobnym zadaniem, albo starając się szybko w myślach rozłożyć zadanie na mniejsze znane mu elementy. Podświadomie porównujemy w takim momencie postawiony przed nami problem do innych, które już kiedyś rozwiązaliśmy. Chodzi o to, że myśląc o czasie, podświadomie myślimy w jednostkach idealnych. Tymczasem naszej pracy towarzyszy szereg innych czynności nie przekładających się bezpośrednio na tworzenie oprogramowania. Poza codziennymi nawykami, jak zrobienie sobie kawy, zdarza się też wiele zdarzeń nieprzewidywanych. Typowe z nich, to pytania od kolegów, odbieranie telefonów, itp. Nie jesteśmy w stanie przewidzieć ich ilości i zwykle tego nie robimy. “Zrobię to w maksymalnie 4 godziny” oznacza częściej “Zrobię to w maksymalnie 4 godziny, jak nic mi nie będzie przeszkadzać” niż “Jeśli uwzględnić 2 telefony po 5 min, jedno wyjście do toalety i może 3 pytania, którym poświęcę w sumie 10 min, to zadanie o które mnie pytasz zrobię w maksymalnie 4 godz.”

Każdy indywidualnie ma pewne tempo pracy, które można określi np. jako ilość idealnych godzin, jakie dana osoba jest w stanie faktycznie zrealizować w ciągu 8-godzinnego dnia pracy. Albo ilość idealnych dni jakie jesteśmy w stanie faktycznie zrealizować w 5-dniowym tygodniu. Ta wielkość często nosi nazwę wydajności (ang. velocity) i zależy zarówno od indywidualnych cech pracownika jak i od samego projektu czy też otaczającego nas środowiska pracy. Tradycyjne metodyki zarządzania projektami bardzo często nie uwzględniają takiego efektu. Agile natomiast zachęca do przejścia na szacowanie w jednostkach idealnych (skoro i tak okazuje się, że podświadomie właśnie tak szacujemy). Ważne będzie także ciągłe badanie velocity naszego zespołu, bo jest to narzędzie znacznie ułatwiające prognozowanie przyszłego stanu projektu.
Z każdym nowym projektem i przy w miarę stabilnym składzie zespołu powinno udać się nam zauważyć pewną średnią wartość takiej wydajności, a to już bardzo cenna informacja dla np. wycen projektu. Także w trakcie projektu należy badać wydajność, bo rozpoczynając dokonaliśmy pewnego przypuszczenia co do tego, na jakim poziomie będzie się ona kształtowała, a teraz czas to zweryfikować.

Tak więc naszą listę user stories oszacujmy w jednostkach idealnych przy zachowaniu używanej do tej pory wielkości (godzin lub dni). W dużym skrócie, aby podać klientowi przewidywaną cenę projektu, należałoby takie szacunki pomnożyć prze pewien współczynnik. Dla zespołu posiadającego już pewne doświadczenie i nie rozpraszanego zbyt często “zadaniami na boku” przyjąłbym przy pierwszym projekcie bezpiecznie taki współczynnik na poziomie 1,25 - 1,5. Wynik mnożenia da przewidywaną liczbę godzin lub dni roboczych, które już w miarę prosto da się przełożyć na koszty. Więc dalej manager może już z taką informacją przystępować do negocjacji. Niemniej na tym etapie nie robiłbym jeszcze takich mnożeń. Kolejnym krokiem będzie ubranie tak oszacowanych zadań w plan iteracji i ew, wydań, ale o tym następnym razem.

Tymczasem, jeśli kogoś zainteresowało podejście oparte na user stories i velocity (o którym też trochę więcej przy okazji planowania, bo tam będzie to użyteczna informacja), to polecam bardzo dobrą książkę Mike’a Cohna pt. “User Stories Applied” (niestety dostępna po angielsku).

Udanego pisania historyjek.

8 comments December 6th, 2006