Od razu zaznaczam, że nie wdrożyłem do mojego projektu wszystkich myśli XP. Nie było to jednak konieczne, ponieważ metodyki AGILE niczego nie nakazują, co sprawia, że można korzystać zarówno z nich całych, jak również z ich fragmentów.
Pierwszy krok - USER STORIES
Zgodnie z najprostszym modelem cyklu życia projektu, na początku jest tylko idea i kilka osób, które ją rozwijają. W XP etap definiowania zawiera się w USER STORIES, czyli historyjkach użytkownika. Autorzy metodyki twierdzą, że kompletny projekt powinien składać się z zestawu historyjek opisujących funkcjonalności aplikacji, których czas wykonania waha się pomiędzy 1 a 3 tygodniami. Jeżeli historyjkę da się wykonać szybciej, to jest zbyt małym detalem i powinna zostać dołączona do większej całości. Historyjki na których wykonanie potrzeba więcej niż 3 tygodnie są zbyt skomplikowane i trzeba je rozbić. Wszystko to w myśl częstego i regularnego publikowania kolejnych wersji aplikacji i dobrego kontaktu z klientem.
W przypadku mobilnej przeglądarki video dla MT mieliśmy do czynienia z jedną historyjką, którą oszacowaliśmy na 2-3 tygodnie pracy oraz jedną wymagającą tylko 1 tygodnia. Celowo zrezygnowaliśmy z tradycyjnego UI Flow i innych schematów, żeby w kontakcie z klientem pozostać na poziomie potrzeb, a nie kwestii technicznych. Okazało się to dobrym krokiem, ponieważ otrzymaliśmy od klienta opis "doświadczeń" użytkownika aplikacji, a nie suchy przekaz na temat tego co znajduje się na kolejnych ekranach.
Ważną kwestią w kontekście USER STORIES wydaje się to, że nie powinny one zawierać wyłącznie pojedynczych funkcjonalności. Gdyby tak było, to kolejne iteracje projektu realizowałyby go w sposób szeregowy, co nie jest efektywne. Celem menedżerów jest takie planowanie projektów, żeby dzięki wykorzystaniu równoległych ciągów zadań optymalizować wykorzystanie zasobów w czasie. Dlatego w przypadku projektu dla MT zaplanowaliśmy w ramach każdej historyjki szereg zadań wykonywanych równolegle. Co więcej, nie wszystkie zadania w pierwszej historyjce zostały zakończone przed przystąpieniem do drugiej. Po prostu nie należały one do specyfikacji testowej, którą opracowaliśmy dla pierwszej iteracji. Dopiero zamknięcie drugiej iteracji zakończyło kilka zadań realizowanych od początku projektu.
Drugi krok - RELEASE PLANNING
Metodyka XP podchodzi do kwestii planowania projektu od strony produktowej. Produktami projektu są kolejne wersje (release's) aplikacji. Planowanie projektu w ramach XP polega więc na rozpisaniu w czasie publikacji kolejnych wersji tworzonego systemu w oparciu o USER STORIES. RELEASE PLAN jest punktem wyjścia do zastosowania standardowych technik (WBS, Gantt, CPM, PERT), które umożliwią komfortowe zarządzanie zespołem. Jak wspomniałem wcześniej, publikacja kolejnej wersji aplikacji, nie jest tożsama z zamknięciem wszystkich zadań realizowanych na danym etapie. Jest to raczej kamień milowy wieńczący ważny etap projektu. Metodyka XP nie wspomina o stosowaniu tych narzędzi, więc menedżer ma tutaj pole do interpretacji. Jest ona dosyć istotna, ponieważ na etapie RELEASE PLANNING tak na prawdę nie powstaje szczegółowy plan zadań programistycznych, a jedynie ogólny zarys tego, co będzie się działo w kolejnych iteracjach. Daje to podstawy do planowania czasu i kosztów projektu, ale nie tak precyzyjne, jak w innych metodykach.
Planując publikację kolejnych wersji MT odeszliśmy od bardzo elastycznego (żeby nie powiedzieć podejścia "w ciemno") na rzecz elastycznego podejścia do planowania zadań projektu. Wyszliśmy z założenia, że jeżeli na początku nie stworzymy przynajmniej ram WBS i Gantta dla całego projektu, to możemy nie "dowieźć" go w terminie. W ten sposób odeszliśmy nieco od założeń XP.
Trzeci krok (powtarzany) - ITERACJE
Sercem etapu realizacji projektu wg XP jest pętla iteracji, w ramach których realizowane są kolejne USER STORIES w kolejności zaplanowanej krok wcześniej. Modelowe podejście do iteracji zakłada, że plan na daną iterację jest tworzony bezpośrednio przed jej wykonaniem. Powinien składać się z zadań (poziom liścia) na tyle szczegółowych, żeby były wykonywane przez jedną osobę, w ciągu 1-3 dni.
Projekt dla MT był w tym zakresie zarządzany nieco inaczej. Jako, że plan zadań powstał w kroku drugim, planowanie iteracji polegało na analizie i ewentualnie modyfikacji wcześniejszego planu. Pozwoliło to na zachowanie rozsądnego poziomu elastyczności.
Nieco inaczej podeszliśmy też do ACCEPTANCE TESTS, czyli po prostu testowania zgodności ze specyfikacją. Zamiast czekać do końca iteracji, mniej więcej co 2-3 dni (po zakończeniu zadań lub zestawów zadań) wysyłaliśmy dema do klienta. Dzięki temu, jeszcze w ramach danej iteracji mogliśmy reagować na błędy lub drobne zmiany oczekiwań. W rezultacie, po zakończeniu pierwszej iteracji mogliśmy przejść do kolejnej bez potrzeby planowania poprawek.
Wg nomenklatury XP mieliśmy wobec tego 2 x SMALL RELEASE (zgodnie z planem kolejnych wersji) i 8 x "VERY" SMALL RELEASE, które zawierały się w ramach iteracji.
Podsumowanie
Wykorzystanie metodyki XP w przypadku projektu dla MT dało same pozytywne rezultaty. Przede wszystkim udało nam się idealnie zmieścić w terminie. Po drugie, uniknęliśmy dużych poprawek, które kosztują czas i pieniądze. Po trzecie, zyskaliśmy zadowolonego klienta.
Linki
XP - http://www.extremeprogramming.org
Brak komentarzy:
Prześlij komentarz