Battle for Agility

Planować czy startować?

December 20th, 2006 Marcin Niebudek

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.

Kategorie: Agile dla managerów

(7 votes, average: 4 out of 5)

 Loading ...