Klasycznie czy zwinnie? ... czyli rozterki kierownika projektów
W poprzednim artykule skupiliśmy się na sposobach optymalizacji zakresu projektu, tak by ograniczać zbędne koszty. Warto jednak pamiętać, że nie tylko to co jest realizowane, ale także sposób w jaki chcemy zrealizować projekt może wpłynąć na efektywność kosztową. Powszechnie znane są 2 typy metodyk realizacji projektów - metodyki klasyczne, tzw. waterfallowe (jak np. PRINCE2) oraz metodyki zwinne (tj. SCRUM, DSDM). Podejście klasyczne opiera się na precyzyjnym zaplanowaniu harmonogramu projektu, z wyraźnie wydzielonym etapem definiowania wymagań projektowych oraz analizy i projektowania rozwiązania, które jest następnie realizowane w ramach kolejnej fazy, testowane i w końcu wdrażane. Podejście zwinne opiera się na budowaniu przyrostowym i iteracyjnym, czyli wyodrębniane są krótsze cykle (np. Sprinty) w ramach których realizowana jest zarówno analiza, wytworzenie części produktu, testy i wdrożenie (niekoniecznie po każdym cyklu, ale dąży się do jak najczęstszych wdrożeń). Następnie cykle takie powtarza się wielokrotnie, tworząc kolejne części docelowego rozwiązania. Nie ma metodyki jednoznacznie lepszej od tej drugiej, wszystko zależy od specyfiki projektu oraz okoliczności w których realizowane jest dane przedsięwzięcie. Wiele już napisano artykułów porównujących metodyki waterfallowe i agilowe, więc chciałabym ująć ten temat w odrobinę inny sposób, a mianowicie z perspektywy oczekiwań klientów versus oczekiwania firmy typu softwarehouse.
Pierwszym oczekiwaniem klienta z którym ma do czynienia dostawca oprogramowania jest przedstawienie wyceny i harmonogramu wdrożenia projektu. Zrozumiałym jest, że każdy klient chce ograniczyć swoje ryzyko i oczekuje precyzyjnego określenia oraz wpisania do umowy ile będzie kosztował projekt. Z punktu widzenia dostawcy oprogramowania jest to trudne zadanie, w szczególności jeśli planowany system, jest systemem innowacyjnym, niepodobnym do wcześniej realizowanych projektów. Jeśli więc klient wymaga takiego podejścia, naturalnym jest, że dostawca potrzebuje listy wyspecyfikowanych wszystkich wymagań oraz przeprowadzenia analizy i projektowania systemu. W wielu przypadkach okazuje się, że mimo swojego przekonania, że wiedzą dokładnie czego potrzebują, klienci nie potrafią samodzielnie przygotować opisu wymagań na wystarczającym poziomie dokładności. Często otrzymujemy "specyfikację wymagań" do systemu, mieszczącą się na 1-2 stronach A4 z prośbą o wycenę. Taki poziom precyzji wymagań nie wystarcza by wyszacować, czy też zbudować cały system informatyczny, chyba że jest to bardzo prosty projekt. Taki dokument to dla nas tylko punkt wyjścia do ustalenia zakresu i wymagań projektu. Wielu klientów nie zdaje sobie sprawy, że żeby spisać szczegółowe wymagania w stylu metodyk waterfallowych do złożonego systemu informatycznego, należałoby spisać nawet kilkaset stron, a proces tworzenia i potwierdzania takich wymagań może trwać nawet kilka miesięcy. Dodatkowo, w takiej specyfikacji ciężko jest spisać wymagania w taki sposób, by były zawsze jednakowo rozumiane przez wszystkich uczestników projektu. Brak bieżącego doprecyzowania wizji produktu może skończyć się tym, że podczas prezentacji produktu ujawniają się znaczące różnice w interpretacji danego wymagania. Zdarzają się sytuacje, że pozornie proste wymaganie programista interpretuje wprost, a według klienta, który je spisał, powinno być interpretowane jako wiele różnych funkcjonalności powiązanych ze sobą, których nie opisał, bo dla niego było to oczywiste. Zwolennicy Agile często prezentują występowanie takich rozbieżności na przykładzie rysunków huśtawki na drzewie, w wizji klienta oraz poszczególnych członków zespołu projektowego (The tree swing analogy). Analogia ta może się wydawać wyolbrzymiona, ale kilka lat doświadczeń w pracy na styku biznesu i IT niestety udowodniło mi, że tak nie jest…
Dla każdego projektu należy rozważyć, czy warto zaczynać go od przeprowadzenia tak szczegółowej analizy, czy nie lepiej pójść w kierunku rozwiązań sugerowanych przez podejście zwinne, w ramach którego analiza prowadzona jest w ramach każdego cyklu wytwórczego (Sprintu) i skupiona jest na mniejszym zakresie funkcjonalności. Na początku spisywane są wymagania wyskopoziomowe, bez szczegółów i co najważniejsze porządkuje się je w taki sposób, by określić które wymagania są krytyczne dla realizacji podstawowych celów projektu, czyli stanowią jego MVP (więcej na ten temat w artykule „Czy należy bać się MVP?”). Następnie w ramach opracowywania poszczególnych funkcjonalności w kolejnych Sprintach wymagania są doprecyzowane przez Product Ownera (na ogół przedstawiciela klienta) i zespół wytwórczy. W podejściu takim klient nie ma gwarancji wdrożenia 100% pierwotnego zakresu, ale z drugiej strony ma większą elastyczność jeśli chodzi o wprowadzanie zmian wymagań w trakcie realizacji projektu. Zmiany takie często pojawiają jako efekt reakcji na dynamikę rynku, na którym operuje klient, ale także jako ulepszenie pomysłu, w trakcie stopniowego tworzenia rozwiązania. Gdy na bieżąco obserwuje się powstawanie produktu i ma się możliwość przetestowania jak działa on w rzeczywistości, o wiele łatwiej o szybkie informacje zwrotne, które pozawalają na udoskonalenie produktu. Oczywiście zmiany zakresu w projektach prowadzonych metodykami klasycznymi są również możliwe, zgodnie z określonymi procesami zgłaszania, analizy oraz akceptacji zmian. Większe zmiany mogą wymagać przeglądu całości spisanych wymagań oraz określenia wpływu zmiany na nie, dokonania korekt w analizie i harmonogramie. Ogólnie przyjmuje się, że projekty prowadzone zwinnie, pozwalają na łatwiejsze i szybsze, a przez to tańsze, reagowanie na zmiany. Jeden z moich współpracowników dla porównania reakcji na zmiany w obydwu metodykach użył „morskiej analogii”. Reakcja na zmiany w Agile można porównać do zwrotności motorówki, gdy zobaczy na swojej drodze przeszkodę, kilka szybkich zwrotów i można dalej podążać do celu. W przypadku metodyk klasycznych, czasami wprowadzenie zmiany wygląda jak próba wyhamowania i zmiany kierunku ciężkiego statku gdy na jego drodze pojawi się góra lodowa…
Mimo zalet podejścia Agile, klientom czasami ciężko jest pracować wg zasad najbardziej ekstremalnych podejść zwinnych, szczególnie jeśli dostawca jest firmą zewnętrzną, którą trzeba zakontraktować. Dlatego często proponujemy podejście hybrydowe, łączące te dwie metodyki. Na początek staramy się zrozumieć cel projektu i otoczenie zewnętrzne mające wpływ na jego realizację. Na tym etapie omawiamy również ze zleceniodawcą jaką ma wizję produktu, analizujemy wspólnie wymagania oraz doprowadzamy do ich priorytetyzacji. Dzielimy zakres na fazy/etapy wdrożenia, zaczynając od najbardziej kluczowych funkcjonalność. Duży nacisk kładziemy na to, by podzielić projekt w ten sposób, by możliwe było rynkowe uruchomienie produktu wcześniej w niepełnej wersji, ale ostateczna decyzja o wcześniejszym komercyjnym uruchomieniu zawsze należy do klienta i zależy od jego strategii. Staramy się, by początkowa faza analityczna nie była zbyt długa, raczej wystarczająca do tego by móc sprawnie rozpocząć proces wytwórczy oraz oszacować koszty projektu. Jako że proces wytwórczy realizujemy w dużej mierze wg podejścia zwinnego, analiza nie kończy się w tym momencie. W każdym Sprincie odbywa się analiza dotycząca poszczególnych elementów realizowanych w danym przyroście, jak również pracuje się nad przygotowaniem do realizacji zakresu planowanego na kolejny Sprint. Unikamy tworzenia rozległej i drobiazgowej dokumentacji wymagań, ale często we współpracy z klientem opracowujemy schematy procesów biznesowych, które będą realizowane z użyciem tworzonego systemu. Pozwala nam to dobrze zrozumieć jak powinien on działać oraz znaleźć te trudne obszary nietypowych sytuacji, na które musi być gotowy system, a o których Klienci często zapominają w swoich specyfikacjach. Wspiera to szukanie optymalnych rozwiązań i uproszczeń, ułatwia komunikację, szczególnie z przypadku złożonych procesów i często pozwala lepiej pokazać jak ma działać oprogramowanie. Istotnym etapem jest również zobrazowanie wizji systemu na makietach, ponieważ ułatwia zauważenie potencjalnych trudności które może napotkać docelowy użytkownik i wyeliminowanie ich na wcześniejszym etapie. Nie zawsze jest konieczność tworzenia pełnego zestawu makiet na początku, często zadanie to realizujemy również etapowo.
Etap wytwarzania oprogramowania jest obecnie w znaczącej części firm softwarehouse realizowany zgodnie z duchem Agile. Prace realizowane są w krótszych interwałach czasowych (Sprintach), zespoły realizują ceremonie agilowe tj. jak daily, retrospektywa czy też przegląd produktu (tzw. Demo), co poprawia efektywność pracy i wspiera ciągły rozwój zarówno produktu jak i procesu wytwórczego. Kluczowa w podejściu Agile jest bezpośrednia komunikacja między zespołem projektowym oraz przedstawicielem klienta (Product Ownerem), który odpowiada za realizowany produkt i jego funkcjonalność. Dostęp do Product Ownera jest kluczowy dla efektywnego działania zespołu wytwórczego, pozwala na szybkie ustalanie szczegółów produktu i jego optymalizację. Jeśli Product Owner po stronie klienta nie jest dostępny lub nie ma odpowiedniego umocowania do podejmowania szybkich decyzji zmniejsza to efektywność pracy w modelu Agile. Dlatego też jeśli klient nie może zapewnić takiej osoby, trzeba przeorientować projekt bardziej w kierunku metodyk klasycznych, dokładniejszej analizy i spisania wymagań wcześniej. Alternatywą jest oddanie części decyzji dostawcy, ale aby taki układ działał dobrze, musi być spora doza zaufania między Inwestorem i dostawcą. Dostępność klienta jest również ważna z punktu widzenia testów projektu. Oczywiście w dzisiejszych czasach testy automatyczne i jednostkowe są istotnym elementem każdego projektu informatycznego, ale trudno mi wyobrazić sobie wdrożenie z sukcesem nowego systemu bez realizacji testów funkcjonalnych. W podejściu Agile każda faza realizacji obejmuje testy, co pozwala na szybkie eliminowanie błędów oraz unikanie ich powtarzania na kolejnych etapach. Ciągłe testy i przeglądy produktu po każdym etapie pozwalają na pozyskanie informacji zwrotnych od klienta oraz dalsze ulepszanie produktu. Warto jednak zauważyć, że w podejściu Agile testy często stanowią istotny element kosztowy. W przypadku wdrażania skomplikowanych projektów oraz nowych funkcjonalności, poniesienie tych kosztów ma sens, ponieważ pozwala uniknąć wielu błędów, których wykrycie późno, mogłoby powodować konieczność dużej przebudowy systemu. W drugiej strony, jeśli tworzymy projekt mało skomplikowany lub oparty o funkcjonalność którą już budowaliśmy wielokrotnie z powodzeniem w podobnych projektach, warto zastanowić się nad zoptymalizowaniem ilości testów w trakcie realizacji.
Podsumowując, nie istnieje jedyna słuszna metoda realizacji projektów, która sprawdzi się w każdym przypadku. Każdy projekt ma swoją charakterystykę i okoliczności realizacji, które powinny być brane pod uwagę przy ustalaniu metodyki realizacji. Ogólnie zaleca się by projekty innowacyjne, realizowane w zmiennym środowisku były realizowane w metodykach Agile. Klasyczne podejście sprawdzi się lepiej dla projektów o bardzo dobrze zdefiniowanych wymaganiach, które muszą być realizowane zgodnie z rygorystycznymi regulacjami lub przepisami, dla których wymagana jest bardzo szczegółowa dokumentacja. W rzeczywistości w świecie IT przeważa obecnie wykorzystanie podejścia zwinnego lub różnego rodzaju podejść hybrydowych. Wynika to często z trudności związanych z kontraktowaniem oraz podpisywaniem umów między klientem a dostawcą. Im dłuższa współpraca i im więcej zaufania jest w tej relacji, tym łatwiej jest iść w kierunku podejścia bardziej zwinnego, mniej sformalizowanego. Wielu klientów dostrzega zalety takiego podejścia, ale oczywiście łatwo zrozumieć pewną ostrożność na początku współpracy z nowym dostawcą. Na końcu i tak okazuje się, że najlepszym podejściem jest to, które umożliwi wdrożenie projektu z sukcesem.
Autor: Alicja Polak
