SCRUM a metodyki prowadzenia projektów
Od kilku lat wśród programistów dużą popularnością cieszy się Agile Software Development, czyli zwinne wytwarzanie oprogramowania. Popularność tego zjawiska sprawiła, że w nomenklaturze projektowej pojawiło się Agile Project Management, czyli zwinne zarządzanie projektami. O ile pierwsze można z pewnością z powodzeniem zastosować do wykonywania oprogramowania i innych procesów wytwórczych (z dużym powodzeniem można stosować w marketingu), o tyle zwinne zarządzanie projektami jest sprawą dosyć umowną. Metodyki zaliczane do Agile Project Management, wśród nich m.in. Scrum, są mimo wszystko tylko sposobami samej realizacji projektu.
Analizując główne założenia Scruma pod kątem zarządzania projektem, dochodzimy do wniosku, że brakuje w nich wytycznych dotyczących inicjacji oraz zakończenia projektu. I są to elementy, przez które Scruma tak naprawdę nie powinno się stosować dla całego projektu. Scrum bowiem zakłada wykonywanie kolejnych zadań pochodzących z określonego zbioru, w mniejszym lub większym stopniu zdefiniowanych i gotowych do realizacji, w stałych cyklach realizacyjnych. Zazwyczaj na początku realizacji projektu liczba cykli jest znana, dzięki czemu można powiedzieć, że znany jest także czas i budżet takiego projektu. Scrum zakłada także pracę w grupie, której liczba pracowników jest z góry narzucona, a kompetencje pozwalają wykonać cały projekt. Podstawowe założenia realizacyjne Scruma odnoszą się więc do czegoś wcześniej przygotowanego.
Pojawia się więc pytanie, czy zwinne zarządzanie projektem jest tak naprawdę zarządzaniem projektem. Tradycyjne metodyki wyróżniają, w zależności od metodyki, minimum trzy etapy w projekcie. Faza inicjacji, faza realizacji i faza zakończenia – zgodnie ze sztuką prowadzenia projektów takie etapy (fazy) w każdym projekcie muszą się znaleźć. Czy są one w Agile Project Management? Nie, i wątpliwe jest czy można byłoby je w nim zaimplementować. Został on bowiem stworzony z zupełnie innym zamysłem, zupełnie inna idea mu przyświecała. Miał skutecznie poprawić efektywność projektów, miał sprawić, że projekty będą kończone z sukcesem, nie zaś zarzucane w trakcie realizacji bądź planowania. Agile Software Development był, jak się później okazało, w miarę dobrym narzędziem poprawy wydajności projektowej. Agile Project Management nie zawsze musi być skuteczny, jeżeli chodzi o wykonanie projektu jako całości.
Dlaczego więc mówimy o zwinnym zarządzaniu projektami, dlaczego zyskuje ono coraz większe grono zwolenników, które powoli wykracza już poza sferę informatyki i programowania? Odpowiedź na to pytanie znajdziemy w sposobie działania wielu firm wykonujących na zlecenie pewne usługi. Niech przykładem będzie firma świadcząca szeroki zakres usług marketingowych. Przychodzi do niej klient, który zamawia kampanię reklamową swojego produktu/usługi, do wykonania w określonym budżecie i określonym czasie (na określony moment w czasie). A więc inicjacja projektu za nami. Jeżeli po zakończonej kampanii klient będzie chciał tylko faktury, naprawdę niewiele trzeba, by zainicjować i zamknąć projekt. Kwintesencja takiego projektu, czyli realizacja kampanii marketingowej, może być już wykonana przy pomocy Scruma czy innej metodyki zwinnej. Z takim czymś poradzą sobie one z nawiązką.
WŁĄCZENIE INICJACJI I ZAKOŃCZENIA W SCRUMOWE ITERACJE
Czy istnieje sposób „naciągnięcia” założeń Scruma do objęcia nim całego projektu? Chyba najlepszym sposobem jest włączenie fazy inicjacji w cykle „produkcyjne” Scruma. Od samego początku Scrum Master wraz z trzonem zespołu powinien przygotowywać projekt, a efektami kolejnych cykli jego pracy powinny być dokumenty inicjujące projekt (ich liczba i zakres mogą być zaczerpnięte z jednej z tradycyjnych metodyk zarządzania). Także faza zakończenia, wymagająca zazwyczaj testów odbiorczych, może być włączona pod postacią ostatniego cyklu realizacyjnego.
Czy takie rozwiązanie sprawdzi się w rzeczywistości, zależeć będzie od umocowania Scrum Mastera w hierarchii zarządczej firmy oraz dopuszczeniu go do negocjacji z potencjalnym klientem. Duża korporacja, podzielona na działy, wydziały i oddziały pewnie nie będzie w stanie zrobić niczego takiego. W małej firmie natomiast będzie obawa o to, że Scrum Master będzie miał zbyt dużą władzę decydując o danym projekcie. Dobrym przykładem rozwiązania danego problemu byłoby uczynienie Scrum Masterem lub Product Ownerem osoby związanej z negocjacjami projektu z klientem zewnętrznym lub wewnętrznym. Rola Scrum Mastera dałaby jej władzę, Product Ownera kontrolę nad realizacją projektu. Nie jest także złą sytuacją, gdy Scrum Master (jako kierownik przyszłego projektu) będzie pełnił rolę doradczą w negocjacjach z klientem.
We włączeniu fazy inicjacji w cykle scrumowe można zauważyć jeszcze jedno niebezpieczeństwo, ale także ratunek dla projektu. Pracując z projektem, którego zakres jest zmienny i ściśle nieokreślony, będziemy mogli swobodnie pracować między kolejnymi iteracjami. Taka praca będzie dla nas nawet bardziej komfortowa. Inaczej będzie się miała rzecz, gdy klient będzie wymagał dokumentacji podobnej do tej, jaką zna z metodyk tradycyjnych. W tym wypadku należałoby zrezygnować ze Scruma.
Jest jeszcze jeden aspekt, o którym warto pamiętać, chcąc inicjować projekt scrumowo. Praca w Scrumie nastawiona jest na współpracę z klientem i zaspokojenie jego potrzeb. Inicjowanie projektu często musi zostać wykonane poza wiedzą i świadomością klienta. Tutaj może pojawić się konflikt. Ciężko sobie wyobrazić bowiem wspólną pracę nad dokumentami takimi, jak rejestr ryzyk czy plan komunikacji, w których jako ryzyko będziemy traktowali np. duże ryzyko niewypłacalności klienta, albo założymy, że o problemach ze specjalistami nie będziemy informować klienta. Wybierając to rozwiązanie trzeba będzie się z tym zmierzyć.
WŁĄCZENIE SCRUMA W FAZĘ WYKONANIA PROJEKTU
Rozwiązaniem alternatywnym będzie przygotowanie „pod Scruma” całego projektu, czyli przeprowadzenie fazy inicjacji projektu i potem zakończenia projektu przez niezależnych ekspertów, związanych z tradycyjnymi metodykami. Będziemy pewni, że projekt będzie przygotowany zgodnie z prawami sztuki zarządzania projektami, wszystkie dokumenty będą prawidłowe, a scrumowcom pozostanie tylko odpowiednie wykonanie projektu.
No właśnie, czy będzie to przygotowane dobrze dla osoby korzystającej z metodyk tradycyjnych czy dla osoby posługującej się Scrumem? Trzeba bowiem pamiętać, że wykonanie produktu projektu przy pomocy Scruma będzie wymagała odpowiedniego zainicjowania projektu, jak i jego zakończenia. W fazie inicjowania projektu realizowanego przy pomocy Scruma będziemy musieli uwzględnić takie elementy, jak zaangażowanie klienta (przedstawiciela klienta) w bieżące prace, konieczność przygotowania rejestru produktowego zawierającego krótkie opowieści będące podstawą prac zespołu, tworzenie zamkniętego i w miarę samowystarczalnego zespołu realizacyjnego, czy na końcu cykliczność dostarczania produktów i oceniania postępów prac. W fazie zakończenia trzeba będzie zwrócić uwagę na to, że cykliczne oceny wartości produktu dla klienta powinny znacząco skrócić fazę testów odbiorczych, a zmienny w czasie zakres projektu nie będzie pozwalał na porównanie efektu z zamierzeniem. Wymienione wyżej elementy są jedynie tymi, które w sposób zasadniczy rzutują na sposób przygotowania projektu.
Dla osoby tworzącej tradycyjne dokumenty uwzględniające zwinne rozwiązania jest to nie lada wyczyn. Bo jak tutaj przygotować harmonogram, gdy tak do końca nie wiadomo, co będzie robione w danej iteracji? Bo jak określić odpowiedzialność za poszczególne zadania, gdy każdy z członków zespołu może sobie je „wziąć” z tablicy? Dla każdego dobrego planisty będą to tylko kolejne elementy do zaplanowania w sposób, aby dało się je zrealizować. Najlepszy nawet planista nie zaplanuje jednej rzeczy – Kierownika Projektu, który stanie się Scrum Masterem, aby ponownie powrócić do roli Kierownika Projektu. Trudno wyobrazić sobie jedną osobę, która będzie pełniła obie funkcje, jeszcze trudniej, że którejś z nich nie będzie w realizowanym projekcie. Pozostaje więc zrównoleglenie tych ról projektowych na czas wykonania produktów projektu, aby zoptymalizować proces włączenia Scruma w tradycyjne metodyki zarządzania projektami.
