Zanim bezpośrednio odpowiesz na pytanie zawarte w tytule, zawsze dobrze jest wyjaśnić, jaki ostateczny cel projektu chcesz osiągnąć
Jak produkt będzie wyglądał za miesiąc, pół roku i za rok. Ale opisz to teraz. To da ci pewną perspektywę i ustali podstawowe oczekiwania dotyczące poziomu przewidywalności, elastyczności, zwinności, szybkości wprowadzenia produktu na rynek i ustalenia kosztów w czasie.
Tak, dzisiaj tworzenie projektów wodospadów wydaje się absurdalnym pomysłem. Zwłaszcza, jeśli niezliczoną ilość razy udowodniono już, że chcąc szybko reagować na zmiany na rynkach, nie ma innego wyjścia, jak działać zwinnie. Jeśli jednak Twoim celem jest dostarczenie za rok produktu z funkcjami, które są już dość jasne i ograniczone od samego początku, a masz zespoły składające się z osób, które nie miały żadnego doświadczenia z metodologią zwinną, to oczywiście pozostań konserwatywny i idź kaskadowo.
Nie w każdej sprawie da się tak łatwo zakończyć. Przyjrzyjmy się, jak lepiej ocenić, która metodologia jest lepsza dla Twojego projektu.
Spis treści:
Jak wygląda wodospad?
Zamiast wdawać się w definicje, które wszyscy znają już od kilku dziesięcioleci, praktyczny wynik projektu wodospadu zwykle wygląda następująco:
Cały ten proces może zająć od kilku miesięcy do kilku lat. Jak można przewidzieć, użytkownicy zobaczą wyniki dopiero na końcu tego procesu. Tak więc po długim oczekiwaniu nadchodzi moment prawdy (lub porażki).
Jeśli w ciągu tego długiego czasu coś się zmieni i produkt końcowy powinien wyglądać nieco inaczej, taką sytuację nazywamy prośbą o zmianę. Projekt należy ponownie otworzyć, przerobić i ponownie zatwierdzić. Przedłuża cały harmonogram zajęć o kolejną część. Każda zmiana wymaga wcześniejszego ponownego uruchomienia całego procesu.
Z drugiej strony masz solidną definicję fazy, stały budżet dla każdej fazy i ustalony czas. Nawet jeśli będziesz musiał długo czekać na pierwszy wynik, jeśli szanse na zmiany po drodze są minimalne, nadal może to być preferowana opcja.
Jak wygląda Agile?
Oto jak projekt może działać w konfiguracji Agile:
To tylko krótkie podsumowanie, ale różnica w stosunku do wodospadu jest już wyraźna. Szybka informacja zwrotna, adaptacja, odzwierciedlenie zmieniających się w czasie aktualnych potrzeb, pierwszy wartościowy produkt dostarczony w możliwie najkrótszym czasie. To wszystko są właściwości, których nie masz szans uzyskać w projekcie wodospadu.
Zwinny kontra wodospad
Projekt nie może zakończyć się sukcesem bez zastosowania odpowiedniej metodologii zarządzania projektem. Oznacza to zdefiniowanie procesów, metryk, ocen i ogólnych sposobów pracy zespołów tworzących projekt.
Zespoły muszą wiedzieć, jakich zasad należy przestrzegać, co określi kamienie milowe, kiedy je osiągnąć oraz jak mierzyć i oceniać sukces. Jednocześnie interesariusze muszą zrozumieć, czego się spodziewać po projekcie i kiedy będą mogli zobaczyć pierwsze efekty prac.
Dokonując odrobiny uogólnienia można powiedzieć, że projekty działające w środowiskach chmurowych znacznie częściej skłaniają się ku metodologiom zwinnym (a przynajmniej powinny). Projekty wykorzystujące infrastrukturę lokalną nadal bardzo często preferują procesy kaskadowe. To naturalny wniosek.
Środowisko chmurowe jest zbudowane od podstaw, aby dostosować się do stale zmieniającego się środowiska. Jak najszybciej (poprzez różne „elastyczne” usługi) dostosowuje się do nowej rzeczywistości. Środowisko on-premise jest często predefiniowane na początku. Trudno to zmienić w czasie, dlatego zespoły pracują ze zmiennymi deterministycznymi przez cały czas trwania projektu.
Podsumowanie podejścia Agile vs. Waterfall.
CechaWaterfall ApproachZwinne podejścieObsługa wymagań użytkownikaZmiana traktowana jest jako proces formalny (Żądanie zmiany). Może zaistnieć potrzeba ponownego wykonania pracy, co będzie miało wpływ na koszty i terminy. Akceptuje zmiany jako część standardowego procesu, bez znaczącego wpływu na koszty i terminy. Planowanie i zakres projektu Na początku określa zakres i się go trzyma. Fazy są sztywne i zgodne z pierwotnym planem. Ma jasną wizję produktu końcowego, ale pozwala na zmiany. Praca jest podzielona na sprinty z elastycznym sposobem realizacji zadań. Śledzenie postępu projektuŚledzi postęp w każdej fazie. Opóźnienia w jednej fazie mogą mieć wpływ na harmonogram całego projektu. Śledzi postęp poprzez sesje demonstracyjne na koniec każdego sprintu. Koncentruje się na wykonalnym produkcie. Współpraca zespołowa. Różni ludzie na różnych etapach projektu, ograniczona interakcja. Wielofunkcyjny zespół ze stałą komunikacją między członkami zespołu i interesariuszami. Zarządzanie ryzykiem Śledzenie stanu na podstawie postępu fazy. Reaguje na ryzyko retrospektywnie, trzymając się planu. Koncentruje się na proaktywnym rozwiązywaniu zależności między zespołami i działaniami. Dostosowuje plan tak, aby wyeliminować przewidywane ryzyka. Ramy wdrożenia Tradycyjna metodologia. Wymaga dostosowania praktyk transformacyjnych do podejścia zwinnego. Obejmuje zmianę nawyków i sposobu myślenia.
Wybór ten zdefiniuje jednak kilka aspektów właściwości wykonania projektu.
#1. Wymagania projektowe i zarządzanie zmianami
Jednym z najważniejszych aspektów definiujących wybór jest sposób, w jaki zostaną spełnione wymagania użytkownika. A także, jaki jest proces, jeśli później konieczna będzie zmiana już uzgodnionych wymagań?
W przypadku projektu kaskadowego wszystkie wymagania są już na początku definiowane i podpisywane przez interesariuszy; jeśli pojawi się jakakolwiek zmiana tego stanu, projekt traktuje ją jako Żądanie Zmiany. Należy to ponownie zweryfikować, uzgodnić i potwierdzić.
Do wszelkich prac wykonanych do tego momentu należy powrócić i rozpocząć je od nowa. Należy ponownie skorygować koszty (ponieważ są to prace dodatkowe nieobjęte pierwotną umową). W najgorszym przypadku konieczne będzie wydłużenie nawet harmonogramu całego projektu.
W przypadku zwinnej konfiguracji zmiany są mile widziane. Zmiany traktujesz jak standardową, codzienną działalność. Zgadzasz się z interesariuszami (prawdopodobnie w wyniku najnowszego demo sprintu), że zmiany są kluczowe, aby utrzymać wizję projektu. Następnie od razu planujesz te zmiany na kolejne sprinty.
Wraz z tym zmieni się poprzednia zawartość i od tego dnia zespoły będą nadal pracować nad nowymi wymaganiami. Nie ma straty czasu ani kosztów. Po prostu od razu dostosowujesz się do nowej rzeczywistości i zastępujesz pierwotny plan nowym. Nie ma w ogóle potrzeby specjalnego zarządzania żądaniami zmian. Wszystko to jest częścią inicjatyw planowania sprintu.
#2. Planowanie i zakres projektu
Jak można się spodziewać, projekt kaskadowy na początku ustawia i naprawia cały zakres. W tym zakresie generujesz plan projektu. Następnie dzielisz czas trwania projektu na określone fazy (zazwyczaj analiza, projektowanie, rozwój, testowanie, wdrażanie, wsparcie i konserwacja) i ustalasz zespoły i zasoby wokół tych faz. Przez większą część harmonogramu projektu Twoim głównym celem jest trzymanie się pierwotnego planu pod względem kosztów i harmonogramu w jak największym stopniu.
Zwinny projekt ma wizję produktu końcowego, a nie twardy plan. Stan końcowy jest jasny, ale droga do osiągnięcia tego stanu może się zmieniać. Ponadto harmonogram projektu jest nadal definiowany i uzgadniany na podstawie wstępnego oszacowania zapotrzebowania i doświadczenia w zakresie obciążenia mocą zespołów pracujących nad projektem. Plan nie ma odrębnych etapów. Zamiast tego każdy sprint sam w sobie jest małą fazą zawierającą wszystkie działania potrzebne zespołowi do pomyślnego wypuszczenia produktu przyrostowego.
Podsumowując, projekt kaskadowy traktuje zmiany jako komplikację do rozwiązania (i szansę dla dostawców na zdobycie dodatkowych pieniędzy). Natomiast projekt zwinny traktuje zmianę jak zwykły biznes bez dodatkowych konsekwencji (poza lepszym, odpowiednim produktem końcowym).
#3. Śledzenie postępu projektu
Projekt wodospadu śledzi postęp planu w poszczególnych fazach projektu. Fazy projektowania nie można rozpocząć przed zakończeniem fazy analizy, testowania nie można rozpocząć przed ukończeniem całej kompilacji itd.
Opóźnienie w niektórych fazach będzie miało wpływ na postęp pozostałych faz projektu. Dlatego ważne jest sprawdzanie działań w każdej fazie i upewnianie się, że postępują liniowo w czasie. W przeciwnym razie zwiększasz ryzyko opóźnienia tego konkretnego etapu, a co za tym idzie całego projektu.
Zwinny projekt śledzi postęp, głównie dzięki sesjom demonstracyjnym odbywającym się na koniec każdego sprintu. Wykonalny produkt jest podstawową miarą postępu. Naturalnie chcesz mieć pewność, że każdy sprint zakończy się pełną treścią. Do kolejnych sprintów nie są przenoszone żadne historie lub tylko minimalne historie.
Ostatecznie znacznie łatwiej jest zobaczyć ogólny postęp projektu, jeśli możesz bezpośrednio wypróbować bieżący przyrost produktu i od razu wrócić do zespołu z bardzo konkretną informacją zwrotną.
#4. Praca drużynowa
Chodzi tu o ściśle odrębne działania wodospadu, a nie o ciągłą współpracę ze wszystkimi stronami zwinnego zespołu.
W projekcie kaskadowym zazwyczaj na różnych etapach projektu pracują różni ludzie. Mogą się w pewnym stopniu przenikać, ale nadal są to różne grupy ludzi. Można powiedzieć, że prawie silosy.
Definicja zwinnego zespołu opiera się na komunikacji i wartości. Musi to być także zespół interdyscyplinarny, zdolny do wykonywania wszystkich działań związanych z cyklem życia produktu. Silosy zespołów to coś, czego nie chcesz istnieć. Stała, wzajemna komunikacja pomiędzy zespołem a interesariuszami zewnętrznymi to podstawowa definicja udanego, zwinnego projektu.
#5. Zarządzanie ryzykiem
Oczywiście chcesz mieć proces śledzenia wszelkich zagrożeń, problemów lub wszelkiego rodzaju przeszkód, jakie projekt może pojawić się na osi czasu.
W przypadku projektu kaskadowego przekłada się to na śledzenie statusu aktualnej fazy projektu. Standardowe raportowanie stanu w formie semafora będzie wyświetlane na zielono (wszystko jest w porządku i zgodnie z planem), na żółto (istnieją pewne ważne problemy, ale nadal jest jasne, jak je rozwiązać) lub na czerwono (co oznacza, że projekt ma poważne problemy, które mogą mieć wpływ na pierwotne ramy czasowe lub budżet).
Zwinny projekt również jest tutaj inny. Tak naprawdę nie śledzisz postępu w kierunku celu. Zamiast tego rozwiązujesz zależności między różnymi zespołami i rodzajami działań. Celem jest upewnienie się, że żaden zespół nie będzie czekał na inny zespół z działaniami związanymi z postępem.
Naturalnie może pojawić się ryzyko, ale wtedy rozwiązanie musi zmienić plan na przyszłość, tak aby ryzyko zniknęło, zamiast szukać rozwiązania ryzyka, zachowując jednocześnie pierwotny plan.
Innymi słowy, zwinna konfiguracja projektu wykorzystuje wszelkie możliwe sposoby zmiany planu tak, aby nie stawić czoła przewidywanemu ryzyku, co oznacza, że zarządzanie ryzykiem jest proaktywne. W przypadku projektu kaskadowego reagujesz na ryzyka retrospektywnie i starasz się je rozwiązać w możliwie najkrótszym czasie, trzymając się pierwotnego planu.
#6. Ramy wdrożenia
Taktyka wdrożenia w przypadku projektów kaskadowych jest oczywiście mniej problematyczna niż w przypadku projektów zwinnych. Zwykle metodologia wodospadu to status quo, który ludzie praktykowali już od wielu lat.
Z drugiej strony projekty wymagają zwinnych praktyk transformacyjnych, aby zmienić nawyki, sposób myślenia i sposoby pracy. Jest to proces trudny, a często też dość długotrwały. Firmy inwestują znaczną ilość czasu i zasobów, aby nauczyć ludzi dostosowywania się do zwinnych procesów.
Korzyści w postaci szybkiego dostosowania się do zmieniających się potrzeb klienta są znaczne, jednak najtrudniejsza jest zmiana sposobu myślenia ludzi i ogólnego środowiska pracy.
W większości przypadków jest to także jedyny sposób na utrzymanie kompetencji na rynku, więc kompromisy są nagradzane wielkim sukcesem tych, którym się to uda.
Ostatnie słowa
Powiedzmy to jasno. Jeśli nie masz bardzo konserwatywnego klienta i nie masz dużej motywacji do szybkiego dostarczania wyników na produkcję (z jakichkolwiek powodów), najlepiej jest zacząć od samego początku modelować zwinne zespoły. W dzisiejszym świecie jest to dosłownie nie do pomyślenia. Dzieje się tak nawet w przypadku tradycyjnej konfiguracji systemów on-premise. Zwłaszcza jeśli zespół jest nowy lub zaczyna od zera z oryginalnymi ludźmi, nadal sensowne jest przekształcenie procesów w celu dostosowania ich do zwinnych metodologii.
Powiedziawszy to, wciąż widzę projekty, w których ludzie po prostu odmawiają stosowania tego rodzaju zwinnego procesu lub jakiejkolwiek innej konfiguracji, ale ściśle związanej z fazą organizacji pracy. Postępują według zwykłej ścieżki kontraktowania pracy na konkretny czas i budżet. Następnie oczekują, że projekt będzie realizowany według tej konfiguracji bez odstępstw od planu i pieniędzy (z różnymi wynikami, zwykle niezbyt dobrymi).
To decyzja, którą mają prawo podjąć, ale ostatecznie podejmując taką decyzję, decydują się także na pozostanie w przeszłości. Może to zadziałać na jakiś czas, ale to tylko kwestia czasu, kiedy przestanie działać.
Następnie zapoznaj się ze szczegółowym artykułem na temat cyklu życia testów Agile.