Zarządzanie zmianą – waterfall i Agile naprzeciw wyzwaniu

Zmiana to zagadnienie, które ma wpływ na zaakceptowany zakres projektu (zmienia go). Uruchamia procedurę: zarządzanie zmianą.

Zmiany spowodowane mogą być:

• różną interpretacją zapisów w specyfikacji
• zmieniającymi się wymaganiami klienta
• błędami zarówno w samej dokumentacji, jak i aplikacji

Błędy i zmiany mają podobną siłę rażenia, mogą mieć nawet podobne źródło, a także skutki dla projektu. O tym skąd się biorą błędy w oprogramowaniu pisałam w jednym z wpisów, mianowicie pojawiają się już na etapie analizy i projektowania, czyli we wczesnym etapie życia projektu. W kolejnych etapach już tylko się mnożą.

Dziś przyglądam się zmianom w ujęciu kosztowym oraz temu, jak próba zabezpieczenia się przed nimi w dwóch pierwszych etapach w waterfallu ogranicza rzeczywiste prawdopodobieństwo ich wystąpienia i negatywny wpływ na projekt oraz jak radzi sobie ze zmianą Agile.

Zmiana – nie ma nic bardziej pewnego

Zgodnie z prawem Murphy’ego konieczność znaczących zmian w projekcie jest odwrotnie proporcjonalna do czasu pozostającego do oddania tego projektu. Im bliżej końca projektu, tym nawet najmniejsze zmiany potrafią być najbardziej kosztowne i czasochłonne, stają się pilne z uwagi na zbliżający się odbiór projektu. Również im bliżej końca, tym jest ich więcej.

Prawdy na temat zmiany

1. Zmiana jest czymś, co na pewno wydarzy się w projekcie.
2. Im dalej od startu projektu, tym więcej zmian (im krótszy w czasie projekt, tym mniejsze prawdopodobieństwo wystąpienia zmian).
3. Im bardziej chcesz uniknąć zmiany, tym większe prawdopodobieństwo, że ona się pojawi.
4. Dokumentacja, ani specjalizacja nie uchronią projektu przed zmianą.
5. Możliwą ochroną przed zmianą jest brak zaangażowania klienta.
6. Zmiany rodzą błędy. Błędy wymuszają zmiany.

Co na to waterfall?

Waterfall stara się sprostać zmianom poprzez zarządzanie nimi, czyli ich właściwe przeprocesowanie, które nie polega na zapobieganiu, ale kontrolowaniu zmian. Ważne jest takie wdrożenie zmiany do projektu (czyli jej realizacja), aby cele projektu zostały osiągnięte. To rodzi opór i niechęć przed zmianą. Tradycyjny „change request” wymaga weryfikacji wpływu zmiany na inne części aplikacji, oszacowania kosztu jej wdrożenia oraz wpływu na harmonogram. Tak rozumiana zmiana psuje szyki, jest niemile widziana, stąd taka asekuracja w waterfallu już na etapie analizy, projektowania i przez cały czas trwania projektu. Dążenie do bezwzględnej spójności i szczelności wydłuża etap analizy i projektowania (czyt. zwiększa koszt), nie dając przy tym pewności osiągnięcia tego, na czym klientowi zależy ani wyeliminowania błędów oraz zmian. Projekt jest na nie skazany.

Słowo „zaakceptowany” w definicji zmiany również jednoznacznie wskazuje na waterfall, bowiem w Agile’u zakres jest przyrostowo ustalany i akceptowany. Agile zakłada też częstą rewizję wymagań i rozwiązań wraz z procesami ich adaptacji, stąd zmiany się nie boi. Waterfall tylko udaje, że się nie boi.

A co na to Agile?

Lean mówi: „Nie należy wykonywać wszystkich analiz na początku, bo i tak będą zmiany.”

DSDM Atern w swoich podstawowych założeniach podkreśla: „Zadania, które należy wykonać w celu wykonania danego systemu, zawsze podlegają zmianom.”

Scrum w swoim manifeście zawiera punkt: „Reagowanie na zmiany ponad podążanie za planem.”

Jak widać metodyki zwinne są otwarte na zmiany. Są odpowiedzią na obserwację, że wymagania klienta często zmieniają się w trakcie trwania projektu. Właściwszym podejściem jest zatem dopuszczenie zmian, zamiast unikanie ich. Tę zwinność zapewnia również redukcja specjalistycznych ról.

Hipoteza

Nie mam wątpliwości, że zbieranie i projektowanie wymagań w waterfallu (próba zdefiniowania i zamknięcia zakresu przed startem implementacji) mają za zadanie docelowo podnieść jakość projektu, a także ograniczyć ryzyko wystąpienia zmian i błędów. Model wynagrodzenia „fixed price” daje poczucie bezpieczeństwa klientom, a także coś więcej niż horyzont czasowy zakończenia projektu – deadline. Tak rozumiana jakość i poczucie kosztowego i czasowego bezpieczeństwa mają swoją cenę, bowiem analiza i projektowanie podnoszą koszt projektu, a poczucie bezpieczeństwa jest iluzoryczne. W końcu przyjdzie zmiana, za którą trzeba będzie zapłacić.

Stawiam zatem hipotezę:

Etap analizy i projektowania w metodykach kaskadowych nie minimalizują w wymierny kosztowo sposób ryzyka wystąpienia zmiany czy błędu funkcjonalnego, jak również ich wpływu na projekt.

Nie mam dowodów na potwierdzenie powyższej hipotezy, ponieważ nie mam wystarczających danych do analizy. Mam subiektywne odczucia, miękkie obserwacje, intuicyjne dane i 1 wniosek:

Lepiej zapłacić za zmianę niż za próbę uniknięcia jej.

Model „time and material”, zaangażowanie analityków i projektantów w cały cykl wytwarzania oprogramowania i otwartość, a nie odporność na zmiany to odpowiedź na nieuniknione. Jeśli w zarządzaniu projektami oswoisz fakt wystąpienia zmiany, nie będziesz musiał nią zarządzać, bo to, co się wydarzy nie będzie zmianą w rozumieniu waterfall’owej definicji.

Możesz dyskutować z powyższym, do czego zachęcam. Możesz się z tym nie zgodzić – chętnie poznam Twoje argumenty. Powinieneś wiedzieć:

• Nie neguję zasadności etapów analizy i projektowania, lubię analityków i projektantów
• Nie hołduję metodykom zwinnym, jakby się mogło wydawać ;-)

Zastanawiam się tylko czy koszt próby zdefiniowania, zapisania i zaprojektowania już na starcie tego, co i tak się zmieni w trakcie, nie przekracza sumy kosztów wszystkich zmian i błędów funkcjonalnych. I czy waterfall nie zapomniał się zaktualizować i dostosować do wymogu naszych czasów – do zmiany właśnie.