niedziela, 15 lipca 2007

Przerwanie iteracji

Kilka osób pytało się jakie jest moje zdanie na temat przerywania iteracji w projekcie zarządzanym metodami zwinnymi. Zgodnie z pierwsza zasadą konsultanta prawidłowa odpowiedź powinna brzmieć "to zależy". I tak jest w rzeczywistości. Podjęcie decyzji o przerwaniu iteracji jest wynikiem działania czynników środowiska w którym przebiega dany projekt i trudno dać tu odpowiedź zawsze prawdziwą. Tym niemniej mogę podzielić się paroma wskazówkami.

Podjęcie decyzji o przerwaniu iteracji powinno być działaniem ostatecznym podejmowanym tylko wtedy jeżeli żadna inna technika zarządcza nie przyniesie lepszych biznesowo skutków. Podejście iteracyjne jest jedną z podstawowych zasad zarządzania zwinnego i jako taka nie może być w dowolny sposób łamana. Złamanie tej zasady musi mieć mocną podstawę biznesową i za każdym razem powinno być zatwierdzane przez najwyższe władze danego projektu (sponsora lub komitet sterujący). W interesie kierownika projektu jest jednak, aby takie decyzje nie były podejmowane. Podjęcie ich i złamanie tym samym umowy zawartej na początku iteracji może bowiem bardzo szybko doprowadzić do chaosu w projekcie. Jeżeli bowiem raz zapadnie zgoda na przerwanie iteracji to później powołując się na ten precedens bardzo łatwo będzie podjąć tego typu decyzje po raz kolejny. Dlatego kierownikowi projektu dla jego własnego przyszłego spokoju powinno zależeć na dotrzymaniu umów i nie przerywaniu iteracji.

Prześledźmy w jakich przypadkach najczęściej pojawia się pokusa przerwania iteracji i jakie są opcje w tych przypadkach.

Przypadek pierwszy i najczęstszy to sytuacja, kiedy w czasie trwania iteracji nagle okazuje się, że klient już nie chce produkowanej przez nas aktualnie funkcjonalności. W takim przypadku przerwanie iteracji nie powinno nastąpić. Iteracje w projektach zwinnych są dość krótkie (maksimum 8 tygodni), więc sytuacja kiedy w czasie trwania iteracji klient nagle przekonuje się, że pewna funkcjonalność na którą sam się zgodził kilka tygodni temu nie jest mu potrzebna nie powinna się wydarzyć. Jeżeli się zaś wydarzy to, choć to trudne, umów trzeba dotrzymywać. Na początku iteracji wszystkie strony zgadzają sie co do zakresu danej iteracji i podobnie jak klient oczekuje od zespołu, że nie wycofa się z podjętego zobowiązania tak samo zespół ma prawo oczekiwać, że nie wycofa się klient. Dodatkowo przerwanie iteracji z taką motywacją spowodowałoby, że w produkcie pozostałyby pewne ślady już wykonanej a nie dokończonej pracy. To mogłoby mieć negatywny wpływ na przyszłą stabilność i jakość produktu. Dlatego prace należy dokończyć. Sporne funkcjonalności mają być wykonane z pełną jakością a w produkcie końcowym mogą być na przykład zakomentowane czy w inny sposób ukryte. Ewentualne nowe funkcjonalności trzeba zrealizować zgodnie z procesem w następnej iteracji. Przed następną iteracją należy się tylko zastanowić, czy w związku z nagłymi zmianami zakresu nie należałoby zmodyfikować (skrócić) czasu trwania iteracji. Taka decyzja musi być podjęta w gronie kierownictwa projektu i nie może być pochopna.

Inny klasyczny przypadek to sytuacja kiedy w trakcie pracy nad funkcjonalnością w ramach iteracji zespół zorientował się, że nie ma możliwości technicznego stworzenia zakładanej funkcjonalności. Przypadek dużo trudniejszy od poprzedniego. Przede wszystkim jeżeli taka sytuacja nastąpiła należy rozważyć możliwość wykonania zakładanej funkcjonalności w technicznie inny sposób niż to było planowane na początku. Drugą opcją jest modyfikacja funkcjonalności w taki sposób, aby była ona wykonalna. Obie te decyzje muszą być skonsultowane ze wszystkimi zainteresowanymi w tym przede wszystkim z klientem / właścicielem produktu. To do niego bowiem należą wszystkie decyzje produktowe w projekcie i będzie on miał ostatnie zdanie w kwestii rozwiązania takiego problemu. Jeżeli nie ma możliwości wykonania danej funkcjonalności w inny technicznie sposób ani klient nie jest chętny zmienić funkcjonalności tak aby była wykonalna to są znowu dwie opcje. Albo zakańczamy iterację i przygotowujemy nową, albo w ramach danej iteracji zespół zobowiązuje się wykonać inną funkcjonalność. Zależy to od wielu czynników (z których najważniejszym jest czas jaki pozostał do końca danej iteracji), lecz w celu zapewnienia spójności zarządzania projektem w większości znanych przypadków lepiej zastosować podejście drugie.

Jedyny znany mi przypadek kiedy bez żadnych obiekcji należy wygasić (ale nie raptownie zakończyć) iterację to sytuacja kiedy znikło uzasadnienie biznesowe dla realizowanego projektu. Projekty są realizowane po to aby organizacje osiągnęły mierzalne rezultaty. Jeżeli nie ma możliwości osiągnięcia tychże rezultatów to kontynuowanie prac nad projektem i dalsze generowanie kosztów przestaje mieć sens. Jeżeli taka sytuacja zaistnieje to projekt należy poprawnie zamknąć, czyli dokończyć rozpoczęte prace, udokumentować wykonane prace, zarchiwizować dane, stworzyć "lessons learned" z projektu itp. Pod żadnym pozorem nie może to być rzucenie wszystkiego i odejście od biurek. Sygnał do podjęcia takich działań musi wyjść od sponsora projektu i być potwierdzona przez właściciela produktu/klienta.

Podsumowując: zwinne zarządzanie projektami rządzi się relatywnie małą ilością zasad. Zasady te powinny być jednak rygorystycznie przestrzegane, bo bardzo łatwo jest znaleźć się po drugiej stronie cienkiej linii, gdzie już rządzi czysty chaos. Iteracyjność jest jedną z tych podstawowych zasad i nie wolno jej łamać bez posiadania twardych, biznesowych dowodów na słuszność takiej decyzji.

Brak komentarzy: