niewygłoszone

Elastyczna metodyka SCRUM
Michał Giergielewicz
(iis2138, zaoczne PBD i OU)
Poniższa prezentacja ma za cel przedstawić metodykę projektowania SCRUM oraz opisać zasady
jej działania i efekty jakie przynosi. Ważnym aspektem jest również odniesienie się do różnic
między metodykami twardymi a elastycznymi.
Wstęp
Tworzenie oprogramowania jest procesem wysoce skomplikowanym i wymaga pewnego stopnia
formalizacji dla zachowania zasady "złotego trójkąta" czyli odpowiednich proporcji Kosztów,
Zasobów i Czasu w celu uzyskania Jakości.
W 99% przypadków oprogramowanie tworzone jest zespołowo, a tam gdzie zachodzi interakcja
grupy ludzi w celu osiągnięcia wspólnego celu, należy ustalić zasady współpracy. Inżynieria
oprogramowania zakłada istnienie różnych metodyk projektowych, ustalających sposób tworzenia
oprogramowania, zasady pracy, wyszczególnia konkretne etapy i opisuje w jaki sposób pracować
dla osiągnięcia wspólnego celu. Przez wiele lat na tym polu niepodzielnie rządziły techniki
"wodospadowe" takie jak PmBook, PMI czy PRINCE2. Zakładały one dość sztywne ramy formalne
w których wyszczególniono kilka podstawowych etapów takich jak inicjacja, planowanie,
wykonanie, monitorowanie, zakończenie. Te techniki, zwane ogólnie "twardymi" posiadają wady,
które uwidaczniały się stopniowo wraz z czasem. Niska odporność tradycyjnych technik na zmiany
w projekcie, czy to dotyczące specyfikacji, wymagań, terminów czy zakładanej konfiguracji
systemu powodowały dużą trudność utrzymania w ryzach "złotego trójkąta" w skutek czego
projekty były oddawane po czasie, przekraczały terminy lub były niskiej jakości.
Agile
Pierwsze działania zmierzające do zmiany dotychczasowych utartych zasad pracy, zostały podjęte
w 1995 przez Ken'a Schwaber'a pod postacią ogólnych założeń metodyki SCRUM, która była
pierwszą z tzw. "zwinnych" metodyk w tamtych czasach. Jednak prawdziwy wzrost popularności
"agile" datuje się na rok 2001 i ogłoszenie tzw. Manifestu Agile przez grupę uznanych naukowców i
1
działaczy świata IT (min. jeden z pomysłodawców Wikipedii, uznani twórcy metodyk
projektowych, programiści, naukowcy itp..). Waga manifestu jest ogromna i należy ją przytoczyć
dosłownie:
„We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”1
Podejście Agile zakłada przeniesienie punktu ciężkości na większości pól z „papieru” na człowieka
- ważna jest komunikacja, reakcje interpersonalne, współpraca. W takim podejściu celem jest
szybkie dostarczanie działających fragmentów aplikacji, pokazywanie klientowi przyrostu
funkcjonalności i oczekiwanie od niego akceptacji lub zmian. Takie podejście w założeniu
powoduje dużo większą zdolność adaptacyjną (ostatni punkt manifestu) i w efekcie pozwala w
szybszy sposób reagować na zmiany, które i tak są nieuniknione.
Podstawowe założenia AGILE:
•
Oprogramowanie wytwarzane jest szybko by zapewnić satysfakcję klienta
•
Działające oprogramowanie dostarczane jest w przyrostowy sposób i okresowo
•
Podstawową miarą realizacji jest działające oprogramowanie
•
Późne zmiany w specyfikacji nie mają destrukcyjnego charakteru na proces wytwarzania
oprogramowania
•
Kładzie się duży nacisk na współpracę na linii biznesu i IT, częste spotkania i
zaangażowanie każdego w proces wytwórczy
•
Bezpośredni kontakt jest najlepszą formą komunikacji.
•
Prostota jest podstawowym wyznacznikiem procesu
•
Zespoły są samozarządzalne
•
Zmieniające się wymagania wymuszają regularną adaptację
1 Źródło: http://agilemanifesto.org/
2
SCRUM jest bardzo wiernym oddaniem idei Agile w konkretnej metodyce. Jego podstawowa
zasada działania opiera się się w całości na 4 punktach manifestu.
Jak działa SCRUM
Ponieważ SCRUM wprowadza wiele nowych pojęć i określeń, zdecydowałem się na pozostawienie
ich w wersji oryginalnej tj w języku angielskim. W kilku przypadkach korzystam z przyjętych
polskich odpowiedników, ale tylko tam gdzie nie spowoduje to niejasności i złej interpretacji pojęć.
Poniżej ogólny schemat procesu:
Źródło: http://pl.wikipedia.org/wiki/Scrum
Scrum zakłada, że na początku (najlepiej jeszcze przed podpisaniem ostatecznej umowy)
powoływany jest zespół. Składa się on z Product Owner'a, Scrum Master'a i Team'u.
Product Owner (PO) jest przedstawicielem klienta w projekcie. Ma wiedzę i kompetencje
pozwalające mu zaprojektować produkt i odbierać efekty prac, oceniając je pod katem przydatności
i zgodności z wymaganiami. Product Owner w dużych firmach jest pracownikiem klienta, jednak
często stosuje się praktykę delegowania pracownika wykonawcy do tej roli, z uwagi na dość
specyficzne umiejętności i kompetencje które Product Owner musi posiadać.
3
Scrum Master (SM) jest specjalistą z dziedziny Scrum'a. Jego główną rolą jest szkolenie Product
Owner'a z metodyki scrum, wyjaśnienie mu jego obowiązków i uprawnień. Jest też odpowiedzialny
za projekt od strony zgodności z metodyką. Scrum Master dba by wszystkie elementy procesu były
przestrzegane i ma prawo ingerować w prace zespołu jeśli widzi odchylenia.
Team to wszechstronna grupa pracowników wykonawcy. Jej główną cechą jest to, że posiada
wszystkie kompetencje niezbędne do ukończenia danego produktu (najczęściej w skład team'u
wchodzą programiści, analitycy, graficy, projektanci interfejsów, administratorzy itp) Ważne jest też
to, że w team'ie nie ma podziału na stanowiska – zespół jest interdyscyplinarny i samoorganizujący
się, nie posiada kierownika lub lidera, a role w zespole są wymienne i „wyłaniają się” samoczynnie.
Oczekuje się, że każdy może wykonać każde zadanie jeśli ma takie kompetencje – nie jest więc
niczym dziwnym, że jedna osoba może jednego dnia projektować interfejs a drugiego pisać kod,
albo tworzyć szatę graficzną (wymagane są tylko umiejętności). Ideą jest tu jak najlepsze
wykorzystanie zasobów.
Zespół (w znaczeniu Team + SM + PO) zaczyna pracę od opracowania listy wszystkich
funkcjonalności tzw. User Stories (historyjek). Mają one postać kilkuzdaniowych opisów w
formacie:
Jako {rola} chciałbym {akcja} poprzez wykorzystanie {obiekt}
Na przykład:
Jako administrator chciałbym móc zablokować konto dowolnego użytkownika
korzystając z panelu zarządzania użytkownikami.
Początkowo takie historyjki mają postać bardzo ogólną i w późniejszym etapie zespół rozbije je na
bardziej szczegółowe elementy. Głównym dostawcą historyjek jest Product Owner, jako osoba
mająca największą wiedzę o potrzebach klienta. Część historyjek może być dostarczona przez
Team, jeśli wynika to z użytej technologii lub jest efektem burzy mózgów. Wszystkie historyjki
muszą być zatwierdzone przez Product Ownera. Dodatkowo do listy historyjek przygotowywane są
statyczne makiety interfejsów2 lub aktywne mockup'y3 całych stron produktu (tu dużo zależy od
2 Makieta – szkicowa reprezentacja graficzna prezentująca proponowany, ogólny wygląd projektowanego elementu.
3 Mockup – Interaktywny szkic elementów strony. Składa się z aktywnych formularzy, linków, tekstów i
przykładowych grafik. Zadaniem mockup'u jest prezentacja zachowania zaprojektowanego elementu.
4
wykorzystanych narzędzi i umiejętności Product Ownera). Tak przygotowana lista nosi nazwę
Product Backlog'u.
Product Backlog jest prowadzony i zarządzany przez Product Owner'a. Product Owner przypisuje
do historyjek priorytety, uwzględniając wymogi techniczne i opinię zespołu – jednak ostateczny
głos należy do niego. Następnie Team wycenia każdą historyjkę, jeśli trzeba dzieląc ją na mniejsze
historyjki, a te z kolei na konkretne zadania. Nie ma konieczności wyceny wszystkich historyjek z
taką samą dokładnością, historyjki których wykonanie jest oddalone w czasie (niski priorytet) mogą
być oszacowane z dużym przybliżeniem. Dokładna wycena obejmuje tylko historyjki z wysokim
priorytetem które będą wykonywane w najbliższym czasie. Każdemu zadaniu przypisywana jest
określona wartość punktowa, określająca stopień trudności i czasochłonność (wycena odbywa się w
sposób subiektywny przez każdego z członków team'u, często wykorzystuje się tu sprawdzone
sposoby jak choćby Planning Poker). Team posiada cechę nazywaną szybkością (velocity), która
określa optymalną ilość punktów, które mogą być zrealizowane podczas jednego Sprint'u (Sprint
czyli przebieg, to cykliczny element procesu Scrum podczas którego realizowane są historyjki.
Długość sprintu jest stała i określana na początku, najczęściej Sprint trwa 2 tygodnie). Podział,
wycena i uszczegółowienie historyjek i stworzenie Product Backlog'u powinno wydarzyć się na
spotkaniu inicjującym. Po zakończeniu tego etapu prac, Product Owner wybiera listę historyjek do
realizacji w pierwszym przebiegu. Suma punktów z tych historyjek nie może być wyższa niż
szybkość zespołu. Rozpoczyna się pierwszy Sprint.
Nad poprawnością całego procesu stale czuwa Scrum Master, który może wskazywać ew. błędy i
sugerować prawidłowy sposób postępowania (oczywiście tylko w zakresie metodologii). Zwłaszcza
spotkanie inicjujące jest narażone na nieprawidłowości ponieważ zespół nie zdążył się jeszcze z
sobą zżyć. W późniejszych etapach kiedy wykryte i usunięte zostaną najpoważniejsze błędy, rola
Scrum Mastera polegać będzie już głównie na monitorowaniu. Dodatkowo Scrum Master pełni rolę
kontrolera w codziennych pracach – pilnuje by wszystkie aspekty metodyki były przestrzegane i
implementowane w prawidłowy sposób. Pełni też rolę skryby, zapisując notatki z organizowanych
spotkań, notując uwagi nt. codziennych prac, które później przedstawi podczas podsumowania
sprintu.
5
Sprint
Każde zadanie (historyjka) z listy otrzymuje DoD (Definition of Done), które formułuje Product
Owner. DoD określa sposób potwierdzenia, że dana historyjka została poprawnie wykonana (np.
zadanie przetestowane, działające, w docelowej szacie graficznej, po testach na użytkownikach
docelowych, uruchomione na serwerze testowym itp). Wybrana przez Product Owner'a lista zadań
trafia na Sprint Backlog i do realizacji przez Team.
Na tablicy w widocznym miejscu zapisywany jest ogólny cel przebiegu (np. Uruchomienie
funkcjonalności forum). Wszystkie historyjki ze Sprint Backlog'u są umieszczane na tablicy w
formie karteczek, tak by przenosząc je w konkretne miejsca tablicy, można było wizualizować
postęp prac. Podczas przebiegu Product Owner, ani żadna inna osoba nie może wpływać na
przebieg pracy Team'u. Team realizuje kolejne historyjki samodzielnie wybierając kolejność,
przypisując osoby odpowiedzialne zgodnie z zasadą samoorganizacji, na bieżąco konsultując
problemy i niejasności z Product Owner'em. Sposób realizacji, użyta technologia, wybrane
algorytmy czy narzędzia leżą tylko w gestii zespołu.
Podczas przebiegu odbywają się Daily Scrum Meeting – mają one postać kilkunastominutowego
spotkania przy tablicy. Spotkanie prowadzi Scrum Master. Celem spotkania jest ustalenie
aktualnych postępów w pracy. Jest to potrzebne do wyrysowania Burndown Chart'u, czyli wykresu
spalania opisującego jak wiele pracy jeszcze pozostało. Pozwala to ocenić czy zespół pracuje
wydajnie i czy wyrobi się z pracą na koniec przebiegu. Spotkanie pozwala również na bieżąco
monitorować czy nie pojawiają się jakieś przeszkody natury technicznej bądź organizacyjnej
(rozwiązywanie takich problemów jest w gestii Scrum Mastera – jego zadaniem jest zapewnić
komfortowe warunki pracy Team'owi). W spotkaniu może uczestniczyć Product Owner, który ma
wtedy aktualny pogląd na stan prac, może też sugerować błędne ścieżki i wskazywać miejsca gdzie
team dokonał błędnej interpretacji zadania. Jeśli wykres spalania wskazuje na możliwe
niedotrzymanie założonych celów w wyznaczonym terminie, cały zespół może zdecydować o
wyrzuceniu z przebiegu jakiegoś zadania bądź zmianie DoD – takie decyzje muszą być jednak
zatwierdzone przez Product Ownera. Wyrzucone zadanie trafia na następny przebieg. Jeśli okaże się
że Team wyprzedza plan, jest możliwość dołożenia zadania z Product Backlog'u – to również
zatwierdza Product Owner.
6
Demo, retrospekcja
Przebieg kończy się zgodnie z przyjętym na początku terminem. Na koniec przebiegu wszystkie
zadania powinny spełniać DoD a główny cel powinien zostać osiągnięty. Potwierdzeniem przebiegu
jest Demo na którym zespół prezentuje Product Owner'owi (i Klientowi) działającą funkcjonalność,
opisuje ew. braki i zapisuje uwagi czy usterki zgłoszone przez Product Owner'a. Lista poprawek jest
następnie wyceniana i dołączana do następnego przebiegu (to oczywiście leży w gestii Product
Owner'a – on decyduje czy błędy poprawiać teraz czy później, albo czy je zignorować).
Po demie odbywa się jeszcze wewnętrzne spotkanie zespołu czyli retrospekcja, na którym
przedstawiane są błędy poczynione w ostatnim przebiegu, problemy które wynikły itp. Podczas
retrospekcji zespół stara się ustalić możliwe usprawnienia, notuje obszary krytyczne i sposoby
ominięcia podobnych błędów w przyszłości. Retrospekcja kończy przebieg i pojedynczy cykl
procesu Scrum. Product Owner dostarcza zespołowi nowy Sprint Backlog i rozpoczyna się
następny przebieg.
Powtarzalność etapów Scrum'a, daje możliwość wyłapywania błędów procesowych i ich korektę.
Adaptacja do zmieniającego się środowiska jest dużą korzyścią dla procesu wytwórczego. Ciągła
komunikacja między członkami Team'u, Product Owner'a i przy współpracy Scrum Master'a,
powoduje, że zespół angażuje się w projekt, nie tylko od strony technicznej ale także biznesowej.
Praktyka pokazuje że Product Owner, widząc sposób pracy zespołu i mając częsty wgląd w jego
postępy, jest w stanie elastycznie reagować na zmiany, dostosowując projekt niejako „na bieżąco”
do swoich potrzeb. Z kolei zespół mając ciągły kontakt z Product Owner'em jest w stanie szybko i
na miejscu wyjaśniać wszelkie problemy lub błędne interpretacje jakichś funkcji produktu. Scrum
Master zapewnia wszystkim członkom teamu wsparcie z zakresu metodyki czy dobrych praktyk
zarządzania zmianą. Całość daje bardzo widoczne efekty synergii.
Metodyka Scrum pozwala szybko zobaczyć efekty prac – poprzez swego rodzaju wymuszenie
komunikacji między biznesem (Product Owner) i IT (Team) daje obu stronom możliwość
aktywnego i prostego sterowania procesem wytwórczym. W rezultacie zwiększone są szanse
zachowania zasady trójkąta czyli dostarczenie produktu wysokiej jakości, w wyznaczonym czasie i
przy zakładanych zasobach.
7
Podsumowanie
Jak każda metodyka Scrum posiada także wady. Podstawowe założenia określają maksymalną
wielkość zespołu na 8-10 osób. Z tego powodu Scrum nie nadaje się dla dużych projektów, gdzie
wymagana jest koordynacja pracy kilkudziesięciu lub kilkuset ludzi. Duży problem pojawia się też
gdy klient konkretnych rezultatów w bardzo konkretnym terminie. W wypadku Scrum'a nie ma
dokładnych specyfikacji określających funkcjonalność produktu na przykład za pół roku. Prace
odbywają się w sposób przyrostowy, co dwa tygodnie prezentowane są postępy i omawiane dalsze
prace, często dochodzi do modyfikacji założeń. Z tego powodu klienci, którzy są nastawieni na
konkretny termin i mają ściśle sprecyzowane wymagania, nie są zadowoleni z formy prezentacji
wycen i proponowanych terminów.
W praktyce Scrum stosuje się do projektów, które nie mają ściśle określonych wymagań i tam gdzie
klient chce na bieżąco modyfikować założenia w ramach reakcji na to co zostało już wykonane.
Najczęściej wykonuje się tak projekty stratup'ów (firm wchodzących na rynek, które mają jakiś
pomysł na biznes bez gotowego produktu), aplikacji mobilnych, platform społecznościowych itp.
Produkty o wysokim stopniu skomplikowania czy specjalnych zastosowaniach (produkty bankowe,
finansowe, aplikacje dla rządu, wojska czy dużych korporacji) najczęściej stawiają wymagania,
którym Scrum nie może sprostać.
Metodyki tradycyjne wychodzą na przeciw oczekiwaniom klienta, opisując dokładnie co zostanie
stworzone i jak to będzie działać, już na etapie projektowania. Przygotowywana jest obszerna i
bardzo dokładna specyfikacja funkcjonalna i techniczna, uzgadniane są terminy realizacji i oddania
kolejnych etapów, warunki akceptacji itp. Tak szczegółowe opracowanie projektu niesie za sobą
pewne ryzyko. Jakakolwiek zmiana musi przejść pełen proces akceptacji (zgłoszenie zmiany,
przekazanie do działu projektowego, modyfikacja specyfikacji funkcjonalnych i technicznych,
modyfikacja terminów i warunków akceptacji, zebranie zgód od osób odpowiedzialnych). Cały
proces jest czasochłonny i w dużej mierze dzieje się poza zespołem odpowiedzialnym za
implementacje. To warunkuje duży bezwład i w konsekwencji zagraża niedotrzymaniem terminów.
Dodatkowo planowanie i projektowanie wszystkich szczegółów implementacji na samym początku
projektu, zakłada duże ryzyko niedoszacowania czasu, czy błędna ocenę funkcjonalną lub
techniczną. Oczekuje się w końcu od specjalistów umiejętności przewidzenia wszystkich
najdrobniejszych nawet niuansów danego produktu. Jakakolwiek pomyłka na etapie projektowania
prowadzi do problemów podczas implementacji a opisana wcześniej duża bezwładność i oderwanie
procesu akceptacji zmian od zespołu, kończy się na przekroczeniach terminów lub budżetu.
8
Scrum powstał głównie jako propozycja rozwiązań tych słabych punktów procesów klasycznych.
W Scrum'ies nacisk nie jest położony na jak najdokładniejszą i kompletną dokumentację – tu liczy
się ciągła komunikacja podczas realizacji projektu, a ponieważ wszystkie osoby decyzyjne są
zebrane w jednym zespole, nie występuje efekt bezwładności. Po każdym przebiegu propozycje
zmian są wręcz oczekiwane, i PO może bardzo szybko uzyskać komplet informacji od zespołu na
temat zaproponowanej przez niego zmiany i równie szybko zaplanować jej wdrożenie.
9