O Scrumie na 90% słyszałaś, ale prawdopodobnie spotkałaś się też z jego nieprawidłowym użyciem. Dzisiaj przyjrzymy się bliżej tej metodyce. Być może nawet uda Ci się usprawnić pracę Twojego zespołu!
Wstęp
Zaczniemy od odrobiny teorii i kilku pojęć.
Czym jest Scrum?
Zadaliśmy podstawowe pytanie, stanowiące punkt wyjściowy szerokiego tematu. Scrum to framework sposobu pracy zespołu oraz, pośrednio, szkielet zarządzania projektem. Należy do tzw. metodyk zwinnych, czyli takich, które oddają idee manifestu Agile. Scrum zakłada proces iteracyjny, w którym produkt jest ‘działający’ (choć niekoniecznie funkcjonalny) już na bardzo wczesnych etapach. Później sukcesywnie usprawnia się wdrożone czynności. Dzięki temu scrum stosowany jest często w projektach innowacyjnych, przy współpracy zespołu posiadającego kompetencje techniczne z klientem (potencjalnym użytkownikiem produktu) Sprawdza się również w sytuacjach, gdy wykonawca zna potrzebę danej osoby, a niekoniecznie ma szczegółową specyfikację samego projektu.
Podstawowe pojęcia
Scrum jest zbudowany wokół kilku konceptów, które trzeba poznać ‘ogólnie’, abyśmy mogli przejść do szczegółów.
Backlog. Istnieją dwa backlogi: produktu i sprintu. Backlog produktu to lista user stories, które zamierzamy dostarczyć w ramach produktu. Backlog sprintu zawiera user stories, które planujemy dostarczyć w ramach sprintu, z podziałem na poszczególne taski.
Interesariusz. Osoba lub grupa, która będzie uczestniczyła w cyklu życia produktu (np. sponsor, użytkownicy — operatorzy, klienci itp.)
Product owner . Nazywany też głównym użytkownikiem. Jest to przedstawiciel użytkownika (lub grupy użytkowników), który bierze udział w procesach planowania i priorytetyzacji zadań, a także uczestniczy w demo.
Scrum board. Tablica, na której widoczny jest progress sprintu. Powinna być dostępna dla wszystkich interesariuszy (może być fizyczna lub online)
Scrum master. Członek zespołu, który dba o trzymanie się najlepszych praktyk w procesie Scrumowym i ciągłe usprawnianie procesu, nie jest to project manager!
Sprint. Krótki (zwykle tydzień lub dwa) przedział czasu, podczas którego dostarczamy wybraną funkcjonalność (lub funkcjonalności) — user story
Sprint review (nie do końca poprawnie nazywany też sprint demo) Spotkanie, podczas którego prezentowane są osiągnięcia ostatniego sprintu, omawiana jest jego zgodność z założeniami oraz sposób na usprawnienie.
User story. Historia użytkownika, czyli funkcjonalność z punktu widzenia użytkownika projektu, opisana w określony sposób (kto-co-dlaczego-jak — zobacz sekcję o pisaniu user stories)
Scrum, a ‘tradycyjne’ podejście do organizacji projektów
Poprzez pojęcie “tradycyjne” rozumiemy tutaj metodykę tzw. Waterfall , czyli taką, w której projekt jest szczegółowo planowany na początku oraz dokumentowany w najdrobniejszych szczegółach. Dopiero po tej fazie następuje rozpoczęcie realizacji. Weryfikacja następuje po realizacji całego produktu, a zmiany są wdrażane poprzez kolejne mini-projekty.
Największą różnicą pomiędzy takim podejściem, a Scrumem jest relacja z klientem. Standardowe podejście nastawione jest na relację zamawiający-wykonawca, w której wartością dla zamawiającego jest produkt, a dla wykonawcy wynagrodzenie zań otrzymane. Scrum nie tylko nie dzieli projektu i celu na dwie strony, ale wręcz wskazuje klienta jako partnera zespołu developerskiego. Ma miejsce swoista kooperacja na rzecz uzyskania najlepszych efektów końcowych (w rozumieniu funkcjonalnego produktu)
Takie podejście wygląda bardzo kusząco, ale niesie za sobą pewne zagrożenia. Przede wszystkim Scrum utrudnia (choć w żadnym wypadku nie uniemożliwia!) kosztorysowanie projektu w długim terminie. Z drugiej strony pozwala na dopracowanie produktu, także poprzez identyfikowanie tych potrzeb klienta, których nie był świadomy oraz znajdywanie optymalnych rozwiązań. Praktyka pokazuje jednak, że projekty realizowane w Scrumie kończą się szybciej, przy mniejszym budżecie oraz z większą satysfakcją dla klienta, niż realizowane w konwencjonalny sposób. Wynika to z faktu, że mając wspólny cel, zespół nie traci czasu i energii na ‘walkę’ z klientem, a korzysta z synergii swojego potencjału technicznego i domenowej wiedzy klienta.
Trzeba również powiedzieć, że bardzo wiele zależy od samego zespołu. Scrum prowadzony w niewłaściwy sposób może pogorszyć sytuację, zamiast ją poprawić i z pewnością nie jest panaceum na wszystkie problemy.
Kwestia wyboru sposobu realizacji projektu powinna być ostatecznie podjęta w organizacji. Nie jest błędem nie korzystanie ze Scruma, ale na pewno niewłaściwym podejściem jest nie branie go pod uwagę przy planowaniu nowego projektu.
Backlog produktu
Backlog produktu to spis historii użytkownika, które składają się na kompletny produkt końcowy. Powyższa lista nie jest zamknięta. Może być modyfikowana w trakcie realizacji projektu, w miarę identyfikowania nowych potrzeb oraz zmiany priorytetów.
Nie ma określonej formy prowadzenia backlogu — większość narzędzi pozwala po prostu grupować historie realizacji wg projektów, pozwalając na ich przenoszenie do sprintów w przyszłości. W praktyce może to być nawet notes, czy koperta z karteczkami (czego jednak nie polecamy, z uwagi na problemy z zarządzaniem takim zbiorem ;) ).
Historie użytkowników w konkretnym backlogu mogą (nie jest to niezbędne) być oszacowane pod względem czasowym. Muszą określać priorytet (z punktu widzenia klienta). Powinny zawierać kryteria akceptacji (choć i one są opcjonalne). Backlog produktu jest podstawą do dalszego planowania, a jednym z ważniejszych procesów z nim związanym jest backlog grooming.
Backlog grooming
W nazwie procesu ukryta jest jego istota. “Grooming” to z języka angielskiego dbać, wręcz ‘dopieszczać’, porządkować. Chodzi o to, aby przejrzeć backlog produktu pod określonym kątem. Usunąć z niego nieaktualne historie użytkownika, jak i poprawić estymacje. Jeśli mamy nowe informacje, uzupełnić o dodatkowo odkryte ścieżki, zweryfikować priorytety oraz podzielić zbyt duże historie na mniejsze. Proces ten powinien być wykonywany cyklicznie, względnie często i oczywiście z udziałem klienta.
Sprinty
Sprint to podstawowa jednostka czasu używana w planowaniu. Głównym założeniem projektu jest to, by efektem jednego sprintu (iteracji) był przyrost produktu. Oznacza to w praktyce, że po zakończeniu sprintu, produkt powinien zyskać nową funkcjonalność lub cechę, którą można zademonstrować klientowi. Nie musi to być skończona funkcjonalność (o ile oczywiście przyjmiemy odpowiednie kryteria akceptacji).
Podczas sprintu realizujemy historie użytkownika, rozbite na bardziej szczegółowe zadania. Historie powinny być realizowane w całości, w ramach jednego sprintu — przenoszenie historii pomiędzy sprintami powinno być ograniczone do minimum, ponieważ utrudnia wyciąganie wniosków o postępie i szybkości osiągniętej przez zespół.
Zakres prac realizowany w ramach sprintu jest określany przed każdym sprintem osobno, w procesie planowania sprintu.
Planowanie sprintów
Przygotowanie sprintu polega na tym, że z backlogu produktu przenosimy historie do backlogu sprintu, uprzednio szacując nasze możliwości. Następnie rozbijamy historie na bardziej precyzyjne zadania z dokładniejszą wyceną.
Proces wyboru historii do sprintu powinien odbywać się z uwzględnieniem priorytetów , określonych we współpracy z klientem. Każdą historię przeniesioną do sprintu dzielimy na zadania, które następnie szacujemy w procesie zwanym Planning poker.
Historie dobieramy do momentu, w którym mamy jeszcze możliwości pracy, tzw. capacity. Określamy je na podstawie dotychczasowych doświadczeń. Szerzej o tym zagadnieniu napiszemy w sekcji szybkość/velocity.
Planning poker
Planning poker to bardzo ważna część Scruma, która zapewnia efektywne szacowanie oraz powszechne rozumienie zakresu zadań. Zanim jednak przejdziemy do właściwego procesu, kilka słów o jednostkach.
Scrum nie narzuca jednostki planowania. Powinna być ona dopasowana do zespołu i projektu oraz odzwierciedlać realne potrzeby. Jednostki czasu bywają zbyt precyzyjne (np. godziny) lub zbyt szerokie (dni). Często wygodnym rozwiązaniem jest przyjęcie abstrakcyjnych jednostek planowania — przyjmując przykładowo, że pełny tydzień pracy to 15 jednostek. Ponieważ przyjmowanie podziałów czasowych stanowi indywidualne ustalenie zespołu, w dalszej części będziemy mówić po prostu o jednostkach. Jak sama się przekonasz, określenie ile czasu zajmuje dokładnie jedna jednostka, nie ma znaczenia.
Planning poker zaczynamy od wyboru zadania, które będzie odniesieniem. Może to być projekt z przeszłości, który każdy z członków zespołu dobrze zna. Co za tym idzie, możemy ocenić jego złożoność i oszacować czas na wykonanie określonej liczby podobnych zadań. “Podobnych” jest tutaj słowem-kluczem, ponieważ planowanie polega nie na ocenie czasochłonności realizacji przyszłego zadania, ale na porównaniu jego złożoności do punktu odniesienia — wybranego wcześniej projektu.
Do pokera najwygodniej używać kart, ale można też skorzystać z aplikacji mobilnej, czy po prostu pokazać konkretną wartość na palcach lub napisać ją na kartce. Istnieją dwa najpopularniejsze zestawy (oczywiście w zespole możecie przyjąć swój własny) Ciąg Fibonacciego oraz kwadraty kolejnych liczb. Idea jest taka, że złożoność zadań nie rośnie liniowo. Zadanie dwa razy bardziej złożone od ‘odniesienia’ prawdopodobnie będzie wymagało więcej niż dwa razy więcej czasu na realizację. Użyjmy kart z ciągiem Fibonacciego. Jeśli zadanie-odniesienie jest wycenione na dwie jednostki czasu i aktualnie szacujesz dwukrotnie bardziej złożony projekt, najbliższym odpowiednikiem na karcie jest liczba 5. Taki czas trwania zadania powinien zostać przyjęty. W pokerze, po opisaniu zadania czy historii przez jedną z osób, każdy sam dokonuje porównania z zadaniem odniesienia. Po tym wszyscy jednocześnie pokazują swoje szacunki. Następnym krokiem, o ile są różnice w ocenie, jest omówienie przez każdego podstaw swojej decyzji. Ponowne głosowanie ma miejsce do chwili, kiedy wszyscy będą jednomyślni lub zgodzą się na określoną ‘wycenę’. Powyższe podejście adresuje kilka kwestii:
- członkowie zespołu mogą mieć różne pojęcie zakresu zadania — podczas omawiania podstaw do szacunków różnice powinny się ujawnić, dzięki czemu można ustalić wspólne rozumienie
- członkowie zespołu mają różną wiedzę i doświadczenia — np. jedna osoba może wiedzieć, że praca z daną częścią systemu, czy technologią, wymaga więcej wysiłku i czasu, więc podczas omawiania różnic, może się podzielić taką informacją
- członkowie zespołu mają różne tempo pracy i są na różnych etapach rozwoju zawodowego — każdy sprint ma określoną pojemność (capacity), która nie jest wyrażona w czasie, ale w jednostkach pracy; każdy developer pomimo pracy na pełny etat może mieć inną ‘zdolność’, pojemność sprintu jest sumą dla wszystkich członków zespołu, a nie iloczynem jednej wartości i ilości osób
Początkowo taki sposób planowania zajmuje stosunkowo dużo czasu (kilka godzin w ciągu Sprintu) Jest to jednak czas, który bardzo szybko odzyskamy, dzięki lepszej organizacji pracy i większemu przepływowi informacji na etapie początkowym.
W internecie można pobrać lub kupić karty do planowania. Darmowy zestaw do wydrukowania dostępny jest np. tutaj.
Scrum board
Scrum board to tablica, na której są przedstawione postępy danego sprintu. Może ona mieć formę fizyczną lub elektroniczną, częstą praktyką jest prowadzenie jej w obu formatach.
Tablica ta jest macierzą, gdzie wiersze to historie użytkownika realizowane w konkretnym sprincie, a kolumny to ‘etapy’ realizacji (np. ‘backlog’, ‘w trakcie realizacji’, ‘w trakcie przeglądu’, ‘wdrażane’, ‘gotowe’) Każdy zespół może dostosować etapy do własnego stylu pracy i projektu. Poszczególne zadania są reprezentowane przez postity lub inne elementy, które po zmianie statusu zadania powinny być przeniesione w aktualne miejsce.
Scrum board jest świetnym narzędziem, które daje zarówno zespołowi, jak i innym interesariuszom wgląd w postępy realizacji oraz osoby odpowiedzialne za dany element.
Codzienne spotkania zespołu
Znane bardziej pod nazwą stand-upy, są jedną z możliwych form prowadzenia projektu. Ich celem jest poinformowanie całego zespołu o statusie aktualnie realizowanych zadań, problemach napotkanych od ostatniego spotkania i ewentualnych blokerach. Nie jest to moment odpowiedni na długie dyskusje techniczne, z założenia spotkanie powinno być krótkim status update. W jego trakcie każdy w kilku zdaniach odpowiada na pytania: co zrobił od ostatniego razu, jakie napotkał problemy / czy jest zablokowany z jakiegoś powodu oraz co planuje robić danego dnia.
Stand-upy polegają na tym, że zespół — na stojąco, aby niepotrzebnie nie przedłużać czasu, spotyka się i każdy po kolei odpowiada na kluczowe pytania przytoczone powyżej. To nie jest jedyna opcja. Spotkania te można prowadzić przez telefon, siedząc przy biurkach, przy lunchu, czy w dowolnej innej formie, realizującej powyższe założenia.
Sprint review (wraz z demo)
Częsty błąd polega na utożsamianiu Sprint review z demo, podczas gdy jest to tylko jeden z elementów spotkania. Ma ono na celu nie tylko zaprezentowanie wyników ostatniego sprintu. Równie ważna jest dyskusja nad realizacją założonych kryteriów, spełnieniem potrzeb klientów oraz ewentualnym umieszczeniem nowo zidentyfikowanych historii w backlogu produktu. Pojawia się także refleksja nad tym, co można było usprawnić. Demo samo w sobie, bez dyskusji, nie niesie dużej dodanej wartości.
Szybkość (velocity) i diagram burn-down
Wspominaliśmy już o ciągłym usprawnianiu procesu, ale kluczowe do jego usprawniania jest mierzenie efektywności. W Scrumie służy do tego tzw. Velocity — innymi słowy tempo pracy. Idea jest prosta, i polega na zliczeniu ilości zrealizowanych jednostek pracy w sprincie. Przy czym pomiaru dokonujemy z punktu widzenia zespołu, a nie indywidualnych jego członków. Większość dostępnych narzędzi mierzy velocity za nas, ale ręczne policzenie także nie powinno sprawiać problemów.
Narzędziem pomocniczym są tutaj diagramy — w tym najpopularniejszy burn-down. Diagram burndown pokazuje dwie linie — jedna to idealny postęp sprintu wyrażony w pozostałych do realizacja jednostkach pracy danego dnia (założeniem jest wykonywanie takiej samej ilości pracy każdego dnia roboczego), druga to rzeczywista wartość wykonanych jednostek pracy od początku sprintu do tego dnia włącznie. Obie linie powinny się pokrywać — zarówno sytuacja, w której ‘rzeczywistość’ jest nad ‘idealnym’ (oznacza, że niedoszacowujemy zadań), jak i sytuacja odwrotna (oznaczająca przeszacowanie) są sygnałami do usprawnienia procesu. Drugim w kolejności jeśli chodzi o popularność jest diagram burn-up — idea jest identyczna, z tym że obrazowana jest wykonana praca, a nie pozostała. W obu przypadkach chodzi jednak o ciągłą informacje ‘gdzie’ w sprincie jesteśmy, jaka jest nasza sytuacja.
Ciągłe doskonalenie i retrospektywy
W tym miejcu wiesz już, jak wygląda Sprint, znasz też narzędzia do badania jego efektywności. Po każdym sprincie (lub np. co drugi sprint) razem z zespołem zastanów się co poszło pozytywnie w sprincie, co się nie udało i co możecie jako zespół poprawić. Te spotkania mogą być częścią sprint review, mogą być zaraz po nim lub mogą być zupełnie osobne. Różnica pomiędzy nimi jest subtelna, ale bardzo ważna — o ile sprint review skupia się na produkcie i pracy, retrospektywa powinna skupiać się na procesie i jego realizacji. Jest to więc miejsce na dyskusje o wszelkich przeszkodach formalnych, pomijaniu ważnych elementów z jakiegoś powodu, pomysłach na usprawnienie, narzędziach pracy itp.
Obowiązki Scrum Mastera
Scrum Master pełni specjalną rolę w Scrumie, nie mającą odpowiedników w innych popularnych podejściach do realizacji projektów. Zadaniem Scrum Mastera nie jest prowadzenie projektu — zdecydowanie nie ma on obowiązków Project Managera. Osoba na tym stanowisku powinna dbać o to, aby procesy Scrumowe były poprawnie (czyli w sposób dopasowany i przynoszący efekty, a nie książkowy!) wdrażane w zespole oraz ciągle usprawniać zarówno procesy jak i sam zespół.
Scrum Master nie jest zatem rolą porządkową. Czynności takie jak: inicjowanie dziennych spotkań, prowadzenie Scrum boardu czy spotkań planningowych nie wchodzą w zakres jego codziennych obowiązków. Powinien za to dbać o poprawne wdrażanie założeń projektu, choć niekoniecznie musi być samodzielnie inicjatorem i liderem. Za powyższe działania odpowiedzialny jest cały zespół.
W przypadku tej roli częstą praktyką jest też rotacja osoby ją pełniącej. O ile nie jest to zjawisko negatywne samo w sobie, należy zawsze mieć na uwadze efektywność w usprawnianiu procesów, która przecież przychodzi z czasem.
Historie użytkowników — kto, co, dlaczego i jak
Historie użytkownika i ich zastosowanie to jeden z powodów, dla których Scrum pozwala dostarczać produkty dopasowane do potrzeb użytkowników. To nic innego jak forma zapisu wymagań w sposób, który pozwala uchwycić nie tylko cel, ale także kontekst. Dzięki temu na podstawie stosunkowo krótkiej informacji , zespół może wywnioskować wiele rzeczy i wybrać najlepsze rozwiązanie. Historia może wyglądać następująco:
Jako użytkownik aplikacji, chcę dodawać nowe zadania z poziomu ekranu głównego. Często są one efektem planowania i dodaję je ‘seryjnie’.
To, co odróżnia Scrum od innych metod, to uznanie takich właśnie historii jako podstawowej jednostki pracy. Dzięki temu projekty są skupione na wymaganiach użytkowników i znacznie lepiej dopasowane do ich potrzeb.
Kto jest aktorem historii
Mówiąc najprościej, aktorem historii może być dowolny interesariusz. Nie musi to być klient, czy użytkownik końcowy — user story. Ten opisuje wymagania z punktu widzenia osoby, która będzie w przyszłości utrzymywała, czy rozwijała system. Rozwiązanie jak najbardziej ok (oczywiście pod warunkiem, że sponsorzy projektu je akceptują). Przykładowo user story może się zaczynać:
Jako użytkownik systemu, …
Jako operator systemu, …
Jako administrator systemu, …
Jako osoba wdrażająca system u klienta, …
Jako wsparcie klienta, …
Jako sponsor projektu, …
Określenie klienta jest pomocne przy realizacji, ponieważ informuje o tym, kto będzie korzystał z tej funkcjonalności, a przez to także nada jej kontekst. Ułatwia też znalezienie osoby, u której można szukać bardziej szczegółowych informacji.
Co jest przedmiotem historii
Przedmiotem historii użytkownika może być dowolna funkcjonalność, proces lub czynność, którą aktor historii chce realizować. Przedmiot powinien być zwięzły i jasny. Odpowiada on na pytanie ‘Co, jako aktor historii, chcę, aby można było osiągnąć za pomocą produktu’(w ‘kilku słowach’ należy zawrzeć meritum lub podzielić je na kilka mniejszych historii).
Przykładami przedmiotów w historii użytkownika mogą być:
… , chciałbym zmienić język interfejsu na każdej podstronie, …
… , chciałbym dodać przedmiot na podstawie już istniejącego, …
… , chciałbym wygenerować plik PDF z podsumowaniem zamówień, …
Przedmiot historii jest bardzo ważny, ponieważ mówi nam, co dany użytkownik chce osiągnąć i jaki ma być tego efekt. Jest to więc najbliższy odpowiednik wymagań funkcjonalnych, w tradycyjnym podejściu do zarządzania projektami.
Dlaczego historia jest ważna, czyli uzasadnienie
Odpowiedź na pytanie ‘Dlaczego użytkownik chce mieć taką możliwość’ jest kluczowa, aby zrozumieć czego naprawdę potrzebuje klient. Pozwala też deweloperom zaproponować lepsze rozwiązanie, jeśli takie znają. Przykładami uzasadnień historii są np:
… , ponieważ operatorzy nie dysponują w tym momencie pełnym zestawem danych.
… , ponieważ obiekty dodawane są najczęściej w dużych partiach.
Uzasadnienie pomaga też priorytetyzować zadania i określać ich kolejność oraz szczegóły implementacji.
Jak zostanie ona wykonana — kryteria akceptacji
To element niejako opcjonalny — jeśli występuje, to najczęściej w postaci osobnej listy punktów czy kryteriów. Nie ma też standardowej formy opisu takich kryteriów. Kryteria akceptacji to nic innego jak doprecyzowanie, co zawiera się w danym przypadku użycia, a co jest z niego wykluczone. Innymi słowy — jaki stan rzeczy pozwoli uznać, że historia została zrealizowana i spowoduje akceptację klienta. Jest to o tyle ważne, że niekiedy pełna historia użytkownika jest zbyt złożona lub nawet niemożliwa do realizacji (z powodu zależności i innych modułów). Weźmy na przykład poniższą historię:
Jako użytkownik portalu XYZ, chciałbym wysłać wiadomość do innych użytkowników z załącznikami. Robię to w celu wymiany plików z dodatkową informacją i opisem, która powinna być archiwizowana.
Kryteria akceptacji mogą wyglądać następująco:
- Funkcjonalność pozwoli załączać dowolny typ pliku
- Rozmiar pliku nie może przekraczać 5MB
- Wyświetlana będzie jedynie nazwa przesłanego pliku
- Pliki nie będą weryfikowane pod kątem poprawności czy innych reguł
- Plików nie będzie można pobierać
Kryteria te mogą wynikać z najróżniejszych okoliczności i mogą mieć różną formę. W tym miejscu mieszczą się także makiety, szkice, notatki ze spotkań, odniesienia do funkcjonalności w istniejących systemach itp.
Ta sekcja jest krytyczna, w kwestii komunikacji z klientem, ponieważ często wyobrażenie o danej funkcjonalności jest inne z perspektywy developera i klienta. Dla developera podkreślanie słów kluczowych w treści może być ‘głupotą, którą doda się w 5 minut w ostatecznej wersji UI’, podczas gdy dla klienta może to być kluczowy element tej funkcjonalności. Kryteria te pozwalają także uniknąć dyskusji o treści ‘a ja myślałem, że…‘O ile historia użytkownika pozostawia spore pole do interpretacji, kryteria powinny precyzyjnie określać zakres prac realizowanych w jej ramach.
Dostosowanie Scrum’a oraz antywzorce
Jednym z głównych założeń Scruma jest jego dopasowanie do potrzeb organizacji i zespołu. Każda firma jest inna, podobnie jak projekty, które są realizowane. Założenie, że można prowadzić różnorodne prace tak samo jest bardzo ryzykowne i — najczęściej — nieprawdziwe. Dlatego Scrum nie narzuca żadnego elementu, a jedynie oferuje zestaw praktyk i narzędzi, które są pomocne. Jednocześnie jednak są od siebie niezależne. Wiele organizacji z sukcesem wdraża tylko część procesów, obserwując poprawę efektywności, a jednocześnie zachowując inne działania czy narzędzia, dostosowane do ich profilu działalności.
Niestety, niektórzy projektanci, z niewiedzy lub lenistwa, nie poświęcają wystarczająco uwagi na poprawne wdrożenie Scruma lub dostosowanie jego elementów. Prowadzi to do różnych antywzorców, które omówimy dalej.
Antywzorzec: PM = SM
Zadziwiająco częstą praktyką jest utożsamianie roli Project Managera z rolą Scrum Mastera, podczas gdy są to zupełnie różne role i nie powinny być łączone! Rolą PMa jest zapewnienie organizacyjnego zaplecza projektu, środków na jego realizację oraz pilnowanie harmonogramu i celów. SM z kolei jest odpowiedzialny za procesy Scrumowe w zespole i ciągłe ich usprawnianie!
Trochę inną, choć mniej destrukcyjną, formą tego antywzorca jest praktyka w zespole, że SM inicjuje i przewodzi np. dziennym spotkaniom. To może wynikać z niezrozumienia idei, ponieważ o ile SM może być inicjatorem i ‘kierownikiem’ takich spotkań, o tyle robi to jako członek zespołu. Jako SM jego rolą jest zapewnianie, że te spotkania się odbywają, dają efekt i prowadzą do poprawy efektywności, ale nie oznacza to, że musi nimi kierować.
Antywzorzec: Planowanie ‘osobowe’
Ta praktyka jest chyba najczęściej popełnianym ‘przestępstwem’ w ramach Scruma, i polega ona na tym, że członkowie zespołu ‘rezerwują’ pewne obszary systemu, skupiając się tylko na nich i przydzielają sobie wszystkie związane z tym zadania i historie już na początku Sprintu. To oczywiście upraszcza prace — pozwala skupić się tylko na wycinku — ale zaprzecza idei, która polega na samoorganizacji zespołu oraz wymianie wiedzy. Każda osoba w zespole powinna być w stanie zająć się dowolnym zadaniem z backlogu w dowolnym momencie sprintu — opisana wyżej sytuacja często prowadzi do sytuacji w których obciążenie pracą w zespole jest nierównomierne, a wiedza skupiona w osobach zamiast rozproszona w całym zespole.
Łatwo też przewidzieć skutki nagłej nieobecności członka zespołu — czy to przez chorobę czy też z racji zmiany pracy.
Najczęstszym objawem takiego sposobu planowania jest sytuacja, w której linie poziome na tablicy sprintu są opisane osobami (członkami zespołu), a nie historiami użytkownika.
Antywzorzec: Planowanie zadaniami
Pisanie historii użytkownika nie jest łatwe, ale jest kluczowe — tylko w ten sposób możemy opisać nie tylko funkcjonalność, ale i kontekst oraz zakres określonej funkcjonalności.
Niestety, ponieważ jest to czasochłonny i angażujący proces, dość łatwo wpaść w pułapkę planowania zadaniami — zamiast pisania historii użytkownika, pisania zadań do realizacji.
W określonych sytuacjach posiadanie konkretnych zadań w backlogu może nie być problemem (np. zadania związane z konfiguracją środowiska czy rzeczami formalnymi — choć często można je też zapisać w formie historii użytkownika), ale są to wyjątki. Niemal zawsze, a już szczególnie w kontekście funkcjonalności, historie użytkownika powinny być podstawową jednostką planowania.
Dla przykładu porównajmy dwa zapisy: “Jako księgowy firmy, chce osobno zapisane poszczególne stawki VAT dla faktur, ponieważ w bilansie muszę je sumować oddzielnie” oraz “Umożliwić oddzielne zapisywanie stawek VAT dla faktur”.
W pierwszym przypadku jest jasny cel — jeśli używana jest baza relacyjna, nie zmieni to za bardzo modelu danych, ale w przypadku przechowywania danych w rozwiązaniach NoSQL informacja, że celem jest ich sumowanie może znacząco wpłynąć na implementacje. Drugi zapis z kolei można zrozumieć jako osobne pole przy informacji o fakturze lub osobny widok do wprowadzania faktur i osobny do wprowadzania stawek VAT. Niby efekt ten sam, ale które rozwiązanie spowoduje, że klient będzie korzystał z produktu i przyniesie mu on wartość?
Antywzorzec: Pomijanie demo, sprinty bez wartości dodanej
Kolejnym częstym błędem jest traktowanie Sprintów jako abstrakcyjnej jednostki czasu, bez większego znaczenia. Prowadzi to do sytuacji, w której realizujemy zadania niemożliwe do prezentacji klientowi, a przez to niemożliwe do weryfikacji. Aby zobrazować problem, przedstawmy jakiś wycinek systemu w postaci poniższego diagramu:
W myśl założeń Scrum’a, prace powinniśmy podzielić ‘pionowo’ — tzn. w pierwszym sprincie zrealizować widok 1, serwis 1 (lub jego część) i bazę danych 1 (lub jej część). W praktyce odejście od regularnego Sprint review z udziałem klienta prowadzi do dzielenia pracy ‘poziomo’ — najpierw wszystkie ‘najniższe’ elementy, potem te o jeden krok wyżej, a na końcu wszystkie widoki. Tak, jest to łatwiejsze dla developera, ale niesie za sobą znaczące problemy:
- błędy w ‘dolnych’ elementach wykryjemy dopiero po 3 iteracjach, a koszt ich poprawy rośnie wykładniczo z czasem
- przez dwie iteracje nie będziemy mieli kontaktu z klientem, po czym zarzucimy go trzema funkcjonalnościami, utrudniając skupienie się na dopracowaniu każdej z nich
W efekcie ryzykujemy poniesienie większych nakładów pracy i dostarczenie funkcjonalności, która nie odpowiada potrzebom klienta.
Antywzorzec: Częsta rotacja Scrum Mastera
Wiele zespołów rotuje Scrum Mastera — wymieniając ku temu różne powody. Samo w sobie nie jest to błędem czy problemem, ale takim się staje, jeśli rotacja następuje zbyt często. Pamiętajmy, że rolą Scrum Mastera jest dbanie o procesy i ciągłe ich usprawnianie — zmiana osoby odpowiedzialnej może przeszkadzać we wdrażaniu zmian i podejmowaniu większych inicjatyw.
Co znaczy zbyt często? To zależy m.in. od długości sprintów, zgrania zespołu, czy projektów — nie ma jednoznacznej odpowiedzi na to pytanie. Warto jednak zastanowić się, co możesz zrobić w okresie, kiedy jesteś SM oraz czego zrobić się nie da — być może warto wydłużyć ten okres w Twoim zespole?
Antywzorzec: Scrum Scrum, i tylko Scrum
Skrajności są złe zawsze, i ma to miejsce także w przypadku Scruma — pamiętaj, że to tylko narzędzie, a nie panaceum na wszystkie problemy. Czasem Scrum nie jest właściwym podejściem, czasem nie wszystkie jego elementy pomogą w realizacji celu, a przede wszystkim — zawsze jest to tylko środek, a nie cel sam w sobie.
Wdrażając praktyki Scruma należy zawsze zapytać siebie i zespołu jak przełoży się to na sukces projektu, w jaki sposób mu pomoże — wdrażanie praktyk Scruma dla samego faktu ich wdrażania jest w najlepszym przypadku bezcelowe, a może wręcz zaszkodzić.
Więcej informacji, szkolenia i certyfikacje
Po więcej informacji odsyłamy przede wszystkim do źródła — czyli organizacji Scrum Aliance i publikowanych przez nią materiałów: http://scrum.org .
Organizacja ta prowadzi też certyfikację w różnych rolach (od członków zespołu, właścicieli produktów aż po Scrum masterów: https://www.scrum.org/Assessments .
Scrum nawiązuje do zwinnego sposobu realizacji projektów, dlatego niewątpliwie warto zapoznać się z Manifestem Agile, który daje podwaliny takiemu podejściu.
Niedługo opublikujemy także recenzję książki o Scrumie, która mamy nadzieję nieco przybliży Ci ideę tej techniki.
Podsumowanie
Jak widzisz, Scrum to nie tylko ‘stand-upy’ i sprinty, to filozofia realizacji projektów poprzez zmianę sposobu myślenia o relacji pomiędzy odbiorcą końcowym a zespołem. Z pewnością nie jest to rozwiązanie dla każdego, nie jest to też panaceum na wszystkie bolączki projektów, ale jest to warta rozważenia alternatywa i potężne narzędzie dla każdego zespołu. Jeśli Twój zespół pracuje w Scrumie, zastanów się, czy faktycznie korzystacie ze wszystkich jego dobrodziejstw, a jeśli nie — co zrobić, żeby to zmienić.
