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

Podobne wpisy
Zintegrowane środowisko wytwarzania aplikacji web’owych na platformie .NET

W artykule przedstawiono opis pakietu narzędziowego VS.NET (Microsoft) z Rational XDE (IBM) do wytwarzania aplikacji webowych pracujących w środowisku urządzeń więcej

Rational Software Architect Pierwszy Krok

Technorati Tagi: Rational Software Architect,inżynieria oprogramowania W artykule zaprezentowano jak rozpocząć pracę z i opis elementów tego narzędzia CASE. Środowisko więcej

Software Project Management GigaCon

Trzecia edycja konferencji Software Project Management GigaCon (25-26 września) to kolejna okazja na wymianę w szerszym gronie zagadnień związanych z więcej

Wstęp do projektowania aplikacji w Rational Software Architect

Rational Software Architect jest kolejną po Rational Rose i Rational XDE generacją narzędzi wspierających twórców oprogramowania w czasie projektowania. RSA więcej

Reklama
MODESTO - licencje Enterprise Architect

Zostaw komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Przewiń do góry