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

  • 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 […]
  • 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ść […]
  • 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 […]
  • Zasada TAO – trzy cechy jeden zespół W dużych firmach spotkałem się czasem z sytuacją, w której to różne zespoły (np.: analitycy biznesowi i programiści) wzajemnie się zwalczali poprzez wytykanie nieścisłości w dokumentacji, […]
  • 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 […]
Reklama

Zostaw komentarz

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