Planowanie w projekcie w nurcie Agile

Planując pracę  swoją czy też swojego zespołu staram się przestrzegać kilku zasad. Oto one:

Plan szczegółowy buduję jedynie dla najbliższych zadań. Moim zadaniem użyteczne są plany na kilka najbliższych dni, tygodni, ale nie na kilka najbliższych miesięcy.

Nie przepadam za wykresami Gantta. Coraz częściej dochodzę do wniosku, że wykresy Gantta mają małą wartość dla projektów agile. Pomagają mi przemyśleć główne zależności ale nic więcej. Najlepszą techniką jest dla mnie się lista zadań dotyczących iteracji.

Zawsze staram się planować z zespołem. To ważne by ludzie wykonujący pracę byli aktywnie zaangażowani w planowanie. Są oni wtedy bardziej zmotywowani, aby wykonać swoją pracę dobrze. Ponadto jako współtwórcy planu prac łatwiej go akceptują.

Określam cele. Spotkania, na których planuję zaczynam od określenia celu jaki chce osiągnąć za miesiąc, tydzień lub na zakończenie iteracji. Celem są produkty, które mają być wytworzone. 

Stosuję krótkie iteracje. Jedyną prawdziwą miarą postępów projektu jest dostarczenie działającego oprogramowania lub w fazie projektowanie modeli i dokumentacji projektowej. Dzięki krótkim iteracjom, zazwyczaj co 1-4 tygodnie, dostarczam twardych dowodów na to, że mój zespół czyni postępy. Zapewnia to lepszy wgląd w prawdziwy status projektu. 

Buduję modele oparte na wymaganiach. Staram się opracować wymagania w postaci scenariuszy: (user stories, przypadki użycia) Każdy scenariusz jest już wymaganiem stawianym systemowi. Zanim jednak dojdzie do opisania scenariusza w pierwszej fazie projektu identyfikuję potencjalne przypadki użycia na podstawie procesów biznesowych lub innych dostępnych danych. Tak zidentyfikowane przypadki użycia nie są dość precyzyjne ale są już bytem, który mogę włożyć w harmonogram prac w ramach iteracji. Potem zespół dostaje tylko dwa zadania –  przygotowanie scenariuszy i jeśli są one sensowne przygotowanie modeli w UML uszczegóławiających przypadek użycia. Nie dzielę planu na drobniejsze zadania.

Określając stan zaawansowania prac stosuję statusy zamiast procentów. Gdy zadania w iteracji wyznaczają przypadki użycia to stosuję tylko 3 rodzaje statusów do opisania ich stanu. nowy – oczekuje na swoja  kolej, opisany – gdy przypadek użycia ma  scenariusze, zamodelowany – gdy przypadek użycia został opisany diagramami UML. W ten sposób szybko jestem wstanie określić na jakim etapie zaawansowania prac jestem w danej iteracji.

I na koniec. Nic tak nie służy planowaniu jak badanie przyczyn odchyleń od pierwotnego planu. Dzięki temu można zawsze, przy kolejnej iteracji, dostosować styl i reguły planowania do istniejących uwarunkowań projektowych.

Podobne wpisy

  • Szacowanie procesów biznesowych metodą diagramów aktywności W trakcie prac projektowych lub analitycznych wielokrotnie powstaje potrzeba policzenia parametrów procesu biznesowego lub szacowania złożoności budowanego oprogramowania.  Większość […]
  • KILKA PORAD DLA MODELOWANIA WYMAGAŃ METODĄ AGILE Chciałbym podzielić się kilkoma istotnymi zasadami, które, mam nadzieję, że pomogą ustanowić efektywne podstawy dla modelowania wymogów metodą agile (i nie tylko). 1. "Niezwykle […]
  • Jak żyć Panie Premierze? W czasie ostatnich wyborów, jeden z uczestników spotkania wyborczego zapytał: “Jak żyć Panie Premierze?” Przekładając na grunt modelowania często słyszę: “Jak modelować?”. I o ile daleko […]
  • Dlaczego warto używać metod Agile? Metody Agile skupiają się na krótszych iteracjach, w których to oprogramowanie dość często jest doprowadzane do takiego poziomu jakości, który pozwala na jego wydanie, zazwyczaj trwa to od […]
  • Demonstracja czyli o ważności informacji zwrotnej Jednym z moich zaleceń, związanych z nurtem Agile, jest: “Pokazuj to co zbudowałeś tak często jak się tylko da”. Należy zastosować to podejście, aby uzyskać informację zwrotną na temat […]
Reklama

Zostaw komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Przewiń do góry