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 w stanie 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.
