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.

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 pseudoharmonogram). 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, ile "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 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 (SPIK) w Szkole Wyższej Psychologii Społecznej (SWPS) w Warszawie, jest również partnerem zarządzającym w firmie doradczej HotHouse. Posiada m.in. tytuł doktora uzyskany w Instytucie Informatyki UW, MBA Francuskiego Instytutu Zarządzania w Warszawie oraz certyfikat Project Management Professional (PMP). Jest założycielem i członkiem zarządu stołecznego oddziału Project Management Institute (PMI WPC). Praktyczne doświadczenia zdobywał w kilku firmach IT w Polsce i Europie Zachodniej.