Projektowy młyn Klasyczne, ciężkie metodyki zarządzania projektami, oparte na dokładnym planowaniu wszystkich działań, niezbyt przystają do projektów o wysokim stopniu niepewności, do których należą projekty programistyczne. Tutaj bardzo ciekawym rozwiązaniem jest metodyka Scrum. Czy czujesz się na tyle lekki i zwinny, aby zagrać w rugby? Zespoły zajmujące się wytwarzaniem oprogramowania już dawno przekonały się, jak ważne jest wczesne dostarczanie kolejnych wersji systemu - być może mocno okrojonego, ale mimo wszystko działającego (wówczas odbiorca może ocenić, czy prace postępują we właściwym kierunku). Dlatego powstały iteracyjne techniki produkcyjne, takie jak metoda spiralna, wczesne prototypowanie czy programowanie ekstremalne (extreme programming, XP). Metody te są jednak ściśle związane ze specyficzną dziedziną wytwarzania oprogramowania, a ponadto nie obejmują pełnego cyklu życia produktu. Klasyczne sposoby zarządzania projektami są zbyt kaskadowe w przypadku przedsięwzięć o wysokim stopniu niepewności i innowacyjności, do jakich z natury rzeczy należą projekty programistyczne, koniecznym stało się opracowanie alternatywnych metodyk prowadzenia projektów, które byłyby bardziej odpowiednie dla tego typu przedsięwzięć. W ten sposób narodził się Scrum, który jest jedną z lekkich (zwinnych) metodyk zarządzania projektami, realizowaną zgodnie z zasadami The Agile Manifesto. Jest stosowany z powodzeniem od połowy lat 90-tych przez różne firmy zajmujące się wytwarzaniem oprogramowania, w tym przez Microsoft. Sam termin scrum wywodzi się z gry w rugby i oznacza młyn, czyli rodzaj rzutu wolnego, w którym dwie splecione ze sobą drużyny przepychają się nad leżącą na murawie piłką. Jak przystało na metodykę lekką, Scrum koncentruje się na dostarczaniu wyników projektu metodą kolejnych przybliżeń, bezpośrednim zaangażowaniu przyszłego użytkownika w proces wytwórczy oraz na samoorganizacji zespołu projektowego. 1
Zespół projektowy we młynie Ścisły zespół Młyna liczy zwykle od 5 do 9 osób (magiczne 7±2) i ma zwykle charakter interdyscyplinarny, to znaczy poza programistami może w nim uczestniczyć również kontroler jakości, dokumentalista, grafik, a także specjalista biznesowy lub psycholog. Wszyscy członkowie zespołu są zaangażowani w stu procentach i nie mogą uczestniczyć w żadnych innych pracach. Jedynym wyjątkiem mogą być pracownicy usługowi, np. administrator zajmujący się obsługą komputerów członków zespołu, który jest wzywany w miarę potrzeb. Co ciekawe, struktura taka odpowiada dokładnie zespołowi chirurgicznemu, postulowanemu ponad 30 lat temu przez Freda Brooksa w jego znanym Mitycznym osobo-miesiącu. Rolę kierownika projektu pełni Mistrz Młyna (Scrum Master), którego zadaniem nie jest jednak ani planowanie, ani przydzielanie, ani kontrolowanie wykonania zadań, lecz przede wszystkim usuwanie wszelkich przeszkód w pracy zespołu, a także zapewnianie zgodności wyników prac z celami biznesowymi sponsora projektu. Mistrz pilnuje również przestrzegania obowiązujących reguł gry (np. dba o samoorganizację zespołu, ale zwalcza kliki) oraz reprezentuje zespół na zewnątrz. Ważną rolę pełni odbiorca aplikacji, zwany też właścicielem produktu. W przypadku projektu realizowanego na zamówienie zewnętrzne będzie nim reprezentant klienta, natomiast w przypadku wewnętrznego projektu mającego na celu wytworzenie nowego produktu na rynek masowy, właścicielem jest zwykle ktoś z działu marketingu. Jednostką pracy zespołu projektowego jest przebieg (sprint), który trwa zwykle od 2 do 6 tygodni. Zaleca się jednak stosowanie przebiegów o stałym czasie trwania (np. 1 miesiąc), co pomaga zespołowi w wypracowaniu regularnego rytmu pracy. Naczelną zasadą pracy młyna jest to, że każdy przebieg musi dostarczyć użytkownikowi kolejną działającą wersję produktu, którą byłby w stanie dotknąć i ocenić. Nie jest przy tym ważne, jak wiele nowych funkcji systemu zostanie dodanych w ciągu miesiąca. Liczy się to, że każde kolejne wydanie musi dodawać nową wartość, którą daje się zweryfikować w praktycznym użytkowaniu, nie zaś na papierze. Do biegu... Każdy przebieg jest poprzedzony fazą przygotowawczą, w której uaktualniana jest lista wymagań użytkownika. Poprawniej byłoby zresztą mówić o liście życzeń, ponieważ wymagania gromadzone są w postaci historyjek (stories), mówiących o tym, jak właściciel wyobraża sobie swój przyszły produkt. Opowiadanie sensownych historyjek nie jest jednak wcale takie łatwe, w związku z czym wielu praktyków zaleca wcześniejsze szkolenie użytkowników w sztuce ciekawego opowiadania. Historyjki muszą być krótkie i treściwe najlepiej, aby z jednej historyjki wynikała wprost jedna cecha systemu. Pomysły użytkownika można gromadzić na zwykłych kartonikach, albo wpisywać je do kolejnych wierszy arkusza kalkulacyjnego. Zanim zespół przystąpi do pracy, właściciel produktu proszony jest jeszcze o ustalenie priorytetów wymagań oraz o wyznaczenie głównego celu przebiegu. 2
Jeśli chodzi o priorytety, to nie muszą być one ułożone według bardzo wyrafinowanej skali. W wielu przypadkach wystarczy wskazanie tych cech, bez których realizacja systemu w ogóle mija się z celem (must be), tych, których obecność bardzo ułatwiłaby pracę (should be) i wreszcie tych, których obecność sprawiłaby właścicielowi niekłamaną przyjemność (nice to have). Jak wiadomo, użytkownicy mają naturalną skłonność do początkowego zaliczania prawie wszystkich swoich pomysłów do najwyższej kategorii, w związku z czym tu także potrzebna jest odrobina treningu i negocjacji. Lista czekających na spełnienie życzeń wraz z ustalonymi priorytetami tworzy rejestr wymagań na produkt (product backlog). Konieczność dodatkowego wyznaczenia głównego celu przebiegu wynika z tego, że mechaniczne wybranie cech o najwyższym priorytecie mogłoby prowadzić do realizacji słabo skorelowanych, czy nawet wzajemnie sobie przeszkadzających zadań. Podobnie jak wymagania cząstkowe, główny cel przebiegu musi być krótki i jasny. Przykładowo, w dziedzinie usług finansowych mogłoby to być hasło zapewnić dostęp do bieżących notowań giełdowych w czasie poniżej 1 minuty, w dziedzinie badań psychologicznych stworzyć koncepcję badania samooceny działającego na telefonie komórkowym, czy też po prostu przenieść centralną bazę danych z platformy MS SQL Server na platformę Oracle. Jak widać, niektóre cele mogą mieć charakter czysto techniczny, wynikający z bieżącego stanu rozwoju systemu, są więc wówczas proponowane przez sam zespół wykonawczy. Cel przebiegu zaakceptowany wspólnie przez właściciela produktu i przez zespół powinien zostać wypisany dużymi literami i przymocowany na ścianie pokoju Młyna. Rysunek 1: Cykl Pracy Młyna 3
Gotowi... Teraz następuje kluczowy moment: zespół projektowy zdejmuje z wierzchu stosu dokładnie tyle wymagań, ile będzie w stanie zrealizować w czasie najbliższego przebiegu. Wybierane są zadania o najwyższym priorytecie, zgodne z wyznaczonym celem. Prawidłowe wykonanie tej czynności wymaga przejścia przez krótką - co wcale nie znaczy, że mało precyzyjną - fazę wewnętrznego planowania. Najpierw życzenia klienta zostają rozbite na bardziej elementarne czynności techniczne niezbędne dla ich realizacji. Pracochłonność każdej czynności jest szacowana z dokładnością do pojedynczej roboczogodziny, a zespół sam ustala, kto jest najbardziej odpowiedni do wykonania każdego z zadań. W przypadku uzyskania zbyt dużej lub zbyt małej łącznej liczby roboczogodzin, zespół dodaje lub zwraca wymagania do rejestru w ten sposób, by zmieścić się możliwie dokładnie w ramach czasu trwania przebiegu. Ostatecznie ustalona lista zadań wraz z szacowaną pracochłonnością nosi nazwę rejestru zadań przebiegu (sprint backlog). Do jego implementacji także wystarcza zwykły arkusz kalkulacyjny. W sumie, uaktualnienie rejestru wymagań oraz stworzenie rejestru zadań stanowią główne wyniki jednego wspólnego spotkania planistycznego, w którym uczestniczy zespół Młyna, właściciel produktu, doradcy biznesowi i techniczni, przedstawiciele wyższego kierownictwa, itd. Obecność sponsora projektu i innych przedstawicieli biznesu wpływa na określenie celu przebiegu, natomiast eksperci techniczni mogą pomóc w uściśleniu rejestru zadań i dokładniejszym oszacowaniu pracochłonności. Spotkanie planistyczne trwa zwykle kilka godzin, maksimum 1 dzień. Start! Zespół rzuca się do pracy. Każdy wykonuje swoje zadania z największą efektywnością, na jaką go stać, co wcale nie znaczy, że zespół ma pracować ponad siły. Przeciwnie w celu utrzymania na dłuższą metę wysokiej jakości wyników praca w nadgodzinach (podobnie jak w XP) traktowana jest jako wyjątek, którego należy unikać. W trakcie przebiegu właścicielowi produktu nie wolno wtrącać się do pracy zespołu, a w szczególności zmieniać wymagań lub ich priorytetu. Zabronione jest także zmienianie składu Młyna. Wszelkie zmiany koncepcji produktu i składu osobowego zespołu dozwolone są jedynie pomiędzy przebiegami. Podstawowym narzędziem kontroli postępów jest wykres spalania dla przebiegu (sprint burndown chart). Jednostką spalania są godziny pracy zespołu: na wykresie codziennie jest odnotowywana szacowana liczba roboczogodzin, jaka jeszcze pozostała do realizacji zadań. Za pomocą prostej aproksymacji liniowej ocenia się, czy dotychczasowa linia wykresu trafia w punkt zakończenia przebiegu. Jeśli przewidywany punkt przecięcia znajduje się poza dniem zakończenia, zespół ma prawo obciąć zakres prac przewidzianych dla przebiegu. I odwrotnie - jeśli przewidywana data całkowitego zakończenia prac wypada przed planowaną datą oddania wyników, zespół może dołożyć więcej wymagań z rejestru produktowego, 4
tak, aby nie siedzieć bezczynnie pod koniec przebiegu. Należy jedynie pamiętać o tym, że zarówno jedna jak i druga modyfikacja jest dozwolona tylko pod warunkiem, że końcowy efekt przebiegu będzie zamkniętą, nadającą się do oceny wersją produktu. Wykres spalania również powinien wisieć na honorowym miejscu w pokoju Młyna. Niektórzy nazywają go wręcz sygnaturą zespołu projektowego, ponieważ okazuje się, że już po kilku przebiegach każdy z zespołów wypracowuje sobie typowy styl obciążenia zadaniami, prowadzący do charakterystycznego kształtu wykresu. Jak widać, opisana metoda kontroli postępów bardzo się różni od metod śledzenia harmonogramu w ujęciu klasycznym. Interesująca jest natomiast analogia do wykresów zużycia buforów czasowych, które są podstawą kontroli projektu w metodzie łańcucha krytycznego. Rysunek 2: Przykładowy wykres spalania 5
Codzienne spotkanie Obowiązkowym elementem metodyki Scrum jest codzienne spotkanie całego zespołu, na którym każdy wstaje i odpowiada na podstawowe 3 pytania: Co robiłem wczoraj?, Co będę robić dziś? i Co mi przeszkadza w pracy?. Odpowiedź na trzecie pytanie stanowi ewidentne zadanie dla Mistrza Młyna. Dwa pierwsze są równie ważne, ponieważ pozwalają członkom zespołu zorientować się na bieżąco w postępie prac i w indywidualnych problemach każdego z kolegów. Ponadto, odpowiedź na pytanie Co będę robił dzisiaj? nosi cechy publicznej deklaracji wobec pozostałych członków zespołu, co bardzo mobilizuje do dotrzymania słowa na następnym spotkaniu. Zebranie nie służy natomiast do rozwiązywania problemów te omawia się poza kadrem. Wystarcza, że uczestnicy zorientowali się sytuacji i ustalili, kto danym problemem powinien się zająć. Odprawa powinna odbywać się codziennie o tej samej porze (najlepiej rano) i nie zajmować więcej niż 15 minut. Uświęconą tradycją odpraw Młyna jest podział uczestników na Prosiaki i Kurczaki. Prosiaki to ścisły zespół projektowy i tylko on ma prawo głosu. Kurczaki to wszyscy ci, którzy maja ochotę przyjść i posłuchać, ale nie mogą wypowiadać się na jakikolwiek temat. Nawet, jeśli na odprawie zjawi się Prezes Zarządu, to musi zrozumieć, że jest Kurczakiem i nie powinien zakłócać przebiegu spotkania kwadrans wyjęty z pracy zespołu jest zbyt cenny, aby go przeciągać w nieskończoność. Koniec przebiegu Ukoronowaniem przebiegu jest spotkanie przeglądowe, na którym zespół Młyna prezentuje kolejne wydanie swojego produktu. Ponieważ istotą spotkania jest demonstracja działającego systemu, zespół nie powinien poświęcać zbyt wiele czasu na przygotowania do prezentacji (maksimum 2 godziny) bowiem produkt powinien mówić sam za siebie. W spotkaniu przeglądowym uczestniczy rzecz jasna właściciel produktu, a także sponsor, przedstawiciele wyższego kierownictwa, koledzy z innych projektów. Tym razem prawo głosu mają wszyscy, a produkt zostaje poddany wszechstronnej ocenie zewnętrznej. Nie zastępuje to oczywiście standardowych testów i innych procedur kontroli jakości, które powinny były zostać uwzględnione w rejestrze zadań właśnie zakończonego przebiegu. Spotkanie przeglądowe trwa zwykle kilka godzin. W jego trakcie powinno się zmierzać do tego, by rozwiać wszelkie wątpliwości dotyczące najnowszego wydania produktu. Ostatnim punktem spotkania przeglądowego jest ustalenie terminu spotkania planistycznego dla następnego przebiegu. Zawodnicy młyna ponownie zwierają szeregi... 6
Zakres stosowalności metodyki W naszej skróconej prezentacji metodyki Scrum zabrakło miejsca dla takich jej elementów, jak analiza ryzyka, skalowalność ( młyn młynów ), czy specyfika zarządzania zespołem projektowym. Warto jednak zastanowić się nad szerszym kontekstem stosowalności tej metodyki. Po pierwsze, Scrum jest metodyką zarządzania projektami, a nie metodą wytwarzania oprogramowania, co odróżnia go w szczególności od XP, również wywodzącego się wprost z filozofii Agile. Każdy przebieg zamyka w sobie pełen cykl rozwoju oprogramowania od planowania, poprzez kodowanie i integrację aż po testowanie a Scrum nie zakłada z góry żadnej konkretnej metody wytwarzania oprogramowania, która będzie leżała pod spodem każdego z przebiegów. Ze względów kulturowych rzeczywiście często wybierane jest programowanie ekstremalne, jednakże niektóre jego cechy stoją wręcz w sprzeczności z zaleceniami Młyna. Przykładowo, w metodyce Scrum przyszły użytkownik jest pytany o zdanie tylko pomiędzy przebiegami, natomiast w XP niemalże śpi on w pokoju programistów. Jako szersza metodyka zarządzania projektami, Scrum znajduje zastosowanie nie tylko w IT, lecz również we wszelkich przedsięwzięciach o słabo zdefiniowanych wymaganiach, takich jak projekty badawczo-rozwojowe, a także usługi medialne (np. projektowanie kampanii reklamowych). Porównując Scrum z klasycznymi metodykami zarządzania projektami, takimi jak chociażby PMI/PMBOK czy PRINCE2, przekonujemy się, że metodyki lekkie wcale nie są mniej precyzyjnie zdefiniowane niż metodyki ciężkie po prostu gdzie indziej leżą ich priorytety. Zamiast koncentrować się na planowaniu i kontroli projektu w ramach potrójnego ograniczenia, czyli zakresu, harmonogramu i budżetu, metodyki takie jak Scrum koncentrują się na dynamicznym definiowaniu zakresu projektu, opartym na serii kolejnych eksperymentów, oraz na udrożnieniu kanałów komunikacyjnych - zarówno pomiędzy odbiorcą i dostawcą, jak i wewnątrz samego zespołu wykonawczego. Na pewno jednak stosowanie metodyk zwinnych nie powinno być zastępczą nazwą na brak stosowania jakiejkolwiek metodyki. Mimo, że wywodzą się one z teorii chaosu (a może właśnie dlatego!), ich stosowanie wymaga od uczestników nawet większej dyscypliny niż w metodach klasycznych. W dziedzinie metodyki Scrum można się zresztą certyfikować zawodowo (Certified Scrum Master), podobnie jak ma to miejsce z certyfikatem PMP czy PRINCE2 Practitioner. Nie można jednak zaprzeczyć, że metodyki lekkie posiadają również swoje ograniczenia. Nie nadają się dla zespołów słabo zintegrowanych oraz rozproszonych geograficznie codzienny bezpośredni kontakt jest jednym z kluczowych czynników sukcesu. Niektórzy twierdzą również, że Scrum nie nadaje się do tworzenia aplikacji o znaczeniu krytycznym. Z tą akurat opinią można polemizować uzyskanie aplikacji o wymaganym poziomie niezawodności może być sprawą leżącej na niższym poziomie technologii wytwarzania oprogramowania. Nikt przecież nie zabrania włączenia do każdego przebiegu Młyna sformalizowanych metod kontroli poprawności programu czy dowolnie zaawansowanych procedur testowych. 7
Umowa z klientem Oddzielnym problemem jest przekonanie odbiorcy do wytworzenia zamówionego systemu metodą kolejnych przybliżeń. Zwróćmy uwagę, że harmonogramu oczekiwanego przez większość klientów właściwie nie ma. Projekt prowadzony metodyką Scrum jest planowany każdorazowo w horyzoncie czasowym tylko jednego przebiegu, natomiast liczbę przebiegów ogranicza w zasadzie tylko cierpliwość inwestora. W przypadku projektów programistycznych prowadzonych na zewnętrzne zamówienie można próbować namówić klienta na kontrakt typu time & material zamiast ustalania stałej ceny, a jeśli się nie uda, to można po prostu zaproponować zadaną z góry liczbę przebiegów (czyli pseudo-harmonogram). Innym rozwiązaniem jest przejście z metodyki lekkiej na ciężką po uzyskaniu pierwszej wersji systemu, po której klient jest już w stanie precyzyjnie określić kierunek jej dalszego rozwoju. W przypadku wewnętrznych projektów programistycznych, których celem jest np. opracowanie nowego produktu na rynek masowy, również można ograniczyć całkowity horyzont czasowy prac (co sprowadza się do ograniczenia z góry liczby dopuszczalnych przebiegów), a także zarezerwować sobie prawo do przerwania projektu w przypadku braku zadowalających postępów. Istotne jest również planowanie co pewien czas tzw. przebiegów stabilizujących, których celem jest nie tyle dalsze rozwijanie funkcjonalności aplikacji, co wygładzenie kantów i doprowadzenie produktu do poziomu kolejnej beta-wersji. Przykładem jest rozszerzenie metodyki Scrum stosowane przez Microsoft, określane mianem synchronizuj i stabilizuj (synchronize and stabilize). Nazwa pochodzi stąd, że przebiegi stabilizujące służą zarazem do integracji wyników prac kilku równolegle pracujących zespołów. Drogi Czytelniku, czy ten artykuł przekonał Ciebie do zmierzenia się z Młynem? Scrum, podobnie jak rugby, jest ostrą grą dla dżentelmenów. Kto raz poznał jej smak, już nigdy nie powróci do żmudnego planowania przebiegu rozgrywki, której rezultatu i tak nie da się przewidzieć. Jarosław Milewski pracuje w Instytucie Społecznej Psychologii Informatyki i Komunikacji Wyższej Szkoły Psychologii Społecznej. Posiada tytuł doktora uzyskany w Instytucie Informatyki na Uniwersytecie Warszawskim oraz tytuł MBA Francuskiego Instytutu Zarządzania w Warszawie i certyfikat Project Management Professional (PMP). Członek-założyciel i sekretarz pierwszego zarządu warszawskiego oddziału Project Management Institute (PMI WPC). Praktyczne doświadczenia zdobywał w trakcie pracy w kilku firmach z branży IT. Artykuł ukazał się 1 sierpnia 2005 w COMPUTERWORLD nr 29-2005 8