środa, 18 kwietnia 2007

Zwinne zmiany

Nawiązując jeszcze do wspomnianego już tematu zmian w projektach chcę obalić jeden mit związany ze zmianami, tym razem w projektach zarządzanych technikami zwinnymi. Ale od początku.

Oprócz tzw. "standardowych" czy też "tradycyjnych" metod zarządzania projektami istnieje też bardzo bliska mi klasa metod zarządzania projektami określana wspólnym mianem "Agile Project Management" czy też po naszemu zwinnym zarządzaniem projektami. Nadaje się rewelacyjnie do zarządzania projektami o wysokiej niepewności, czyli projektami zwinnymi. Jedną z fundamentalnych wartości zwinnego zarządzania projektami jest:

Responding to change over following the plan.

Czy odpowiadanie na zmianę jest bardziej wartościowe od trzymania się planu. Trzymanie się planu oczywiście też jest wartościowe, odpowiadanie na zmianę jest jednak bardziej wartościowe. O innych wartościach (są 4) zwinnego zarządzania projektami możecie przeczytać tutaj.

Teraz uwaga! Wiele osób błędnie interpretuje wspomniane zwinne podejście jako zachętę do wprowadzania dowolnych zmian, w dowolnych chwilach i generalnie wyrzucenia planu (i planowania) do kosza. To mit i duże nieporozumienie. Zwinne nie znaczy chaotyczne. Odrzucenie planowania i niekontrolowane zmiany prowadziłoby w prosty sposób do chaosu. A zwinne zarządzanie projektami rządzi się ścisłymi zasadami, których łamać nie można. Podobnie jak nie można ich łamać w tradycyjnym zarządzaniu. Łamanie zasad zawsze prowadzi do chaosu, niezależnie od techniki zarządzania.

Aby wyjaśnić temat zmian w zwinnym zarządzaniu należy jednak zacząć od czegoś bardziej fundamentalnego. Projekty zarządzane technikami zwinnymi zawsze realizowane są w iteracjach. Każda z iteracji dostarcza w pełni kompletny, ściśle określony podzbiór ostatecznej funkcjonalności produktu końcowego. Mówiąc prościej: każda iteracja dostarcza wartość dla klienta w postaci działającej wersji produktu. W związku z tym w dowolnym punkcie projektu funkcjonalności produktu końcowego można podzielić na trzy grupy: te, które zostały już zrealizowane, te które są realizowane w bieżącej iteracji oraz te które są do zrealizowania w przyszłych iteracjach. Jedną z najważniejszych zasad zwinnego zarządzania projektami jest: nie wolno wprowadzać zmian do funkcjonalności realizowanej w bieżącej iteracji. Funkcjonalności, które już zostały zrealizowane wolno zmieniać, trafiają one wtedy na listę do realizacji. Funkcjonalności z listy do zrobienia można oczywiście modyfikować bez żadnych warunków. Jeżeli istnieje dobrze uzasadniona potrzeba zmiany funkcjonalności realizowanej w ramach bieżącej iteracji to taką funkcjonalność wprowadza się jako nową na listę funkcjonalności do zrealizowania w przyszłości.

Jaki jest tego skutek? Otóż zespół projektowy w dowolnym momencie trwania projektu zarządzanego technikami zwinnymi pracuje nad niezmiennym zestawem funkcjonalności. Do czasu zakończenia danej iteracji ten zestaw wymagań nie może ulec zmianie. Ewentualnie zmiany pojawią się jako nowe funkcjonalności do zrealizowania w następnej iteracji. W ramach bieżącej zestaw wymagań zawsze jest stały i zawsze ma być ukończony na koniec iteracji. Zwinne oznacza stabilne. Zespół projektowy w każdej chwili zna minimalny zakres czasowy stabilności wymagań: do końca danej iteracji. Odpowiadanie na zmiany jest wyrażane w przyszłych działaniach a nie w natychmiastowej zmianie zakresu pracy dla grupy realizującej projekt. Złamanie tej zasady prowadzi do chaosu. Jest to zupełnie inna sytuacja niż w przypadku projektów zarządzanych tradycyjnie, gdzie zmiana może nastąpić w dowolnej chwili, jak tylko odpowiednie ciało zarządzające zmianami je zatwierdzi.

Wbrew pozorom doświadczenie wskazuje, że członkowie projektów (programiści - z tej branży mam doświadczenia) wolą pracować w stabilnym środowisku zwinnym niż w tradycyjnym projekcie, w którym zmiany spadają nie wiadomo w której chwili i to zwykle z klauzulą "do zrobienia jak najszybciej". Również wbrew temu co mogłoby się wydawać zmiany dotyczące już dostarczonej funkcjonalności po pewnym czasie zaczynają występować bardzo rzadko i projekt zwinny uzyskuje dużą stabilność. Dzieje się tak ze względu na mechanizm wyboru funkcjonalności do realizacji i jego wpływ na decyzje klienta. Ale to już temat na inną historię.

Brak komentarzy: