Marta Żuchewicz

Scrum - iteracyjna i inkrementalna metodyka prowadzenia projektów, zaliczana
do metodyk zwinnych, zgodnych z manifestem Agile. W metodyce tej rozwój produktu
podzielony jest na mniejsze, trwające od tygodnia do miesiąca, iteracje zwane sprintami
następującymi bezpośrednio po sobie. Po każdym sprincie zespół pracujący nad rozwojem
produktu jest w stanie dostarczyć działającą wersję produktu. Scrum jest często stosowany
podczas tworzenia i rozwijania oprogramowania, nie jest jednak ograniczony tylko do tej
dziedziny. Ogólne założenia metodyki zostały zaprezentowane przez Hirotaka Takeuchi i
Ikujiro Nonaka w artykule The New Product Development Game, opublikowanym w Harvard
Business Review w styczniu 1986 roku. Pełna metodyka oraz definicja została
sformalizowana przez Kena Schwabera w 1986.
OGÓLNE ZASADY
Zespół pracuje w określonym przedziale czasowym zwanym przebiegiem (ang.
sprint). Efektem przebiegu za każdym razem powinno być dostarczenie użytkownikom
kolejnej działającej wersji produktu. Zasadą jest to, że zmiany wprowadzane w jednym
przebiegu muszą być namacalne dla użytkowników. Muszą wnosić wartość funkcjonalną.
Przebieg może trwać od 1 do 4 tygodni. Zaleca się stosowanie przebiegów o stałych
długościach.
Na początku pracy nad produktem zbierana jest lista wymagań użytkownika, są
one przeważnie gromadzone w postaci "historyjek" (ang. User Stories). Każda historyjka
opisuje jedną cechę systemu. Właściciel produktu (ang. Product Owner) jest też
zobowiązany do przedstawienia priorytetu wymagań oraz głównego celu pierwszego
przebiegu. Po tym formułowany jest rejestr wymagań (ang. Product Backlog). Cel przebiegu
jest zapisywany w widocznym miejscu w pokoju członków zespołu.
Następnie podczas planowania przebiegu (ang. Sprint Planning) wybierane są
zadania o najwyższym priorytecie, a jednocześnie przyczyniające się do realizacji celu
przebiegu. Szacuje się czas realizacji, pracochłonność, złożoność i ryzyko każdego zadania.
Lista zadań wraz z oszacowaną czasochłonnością nosi nazwę rejestru zadań przebiegu (ang.
Sprint Backlog).
Po planowaniu zespół przechodzi do realizacji przebiegu. W jego trakcie
właściciel produktu powinien cały czas pracować z zespołem nad jak najlepszym
zrozumieniem wymagań nie ingerując jednocześnie w sposób ich implementacji. Nie
powinno się także zmieniać zakresu sprintu.
Jako że zespół z założenia jest samoorganizującym się ciałem, nie ma mowy o
odgórnym przypisywaniu zadań do poszczególnych członków zespołu, lecz samodzielnie
dokonują oni wyboru realizowanych zadań, według wspólnych ustaleń, umiejętności czy
innych preferencji.
Naczelną zasadą metody jest przeprowadzanie codziennych (maksymalnie 15minutowych) spotkań (ang. Daily Scrum), na których omawiane są zadania zrealizowane
poprzedniego dnia, problemy występujące przy ich realizacji oraz zadania do wykonania w
dniu spotkania.
Sprint kończy się spotkaniem będącym przeglądem przebiegu (ang. Sprint
Review), na którym prezentowany jest wynik pracy zespołu, poprzez prezentowanie produktu
wykonanego podczas przebiegu. Powinni w nim uczestniczyć wszyscy zainteresowani
projektem. Na spotkaniu każdy członek zespołu może zabrać głos i wyrazić opinię o
produkcie. Po omówieniu produktu ustalany jest termin spotkania planistycznego do
następnego przebiegu.
Metodyka skupia się na:

dostarczaniu kolejnych, coraz bardziej dopracowanych wyników projektu,

włączaniu się przyszłych użytkowników w proces wytwórczy,

samoorganizacji zespołu projektowego.
ZESPÓŁ
Zazwyczaj zespół Scrum składa się z od 3 do 9 osób. Dobrze, gdy ma charakter
interdyscyplinarny i składa się z osób reprezentujących różne umiejętności. Osoby
uczestniczące w zespole nie mogą uczestniczyć w innych zespołach.
Główne role w projekcie grają: "Mistrz Młyna" (ang. Scrum Master), właściciel produktu
(ang. Product Owner) i członkowie zespołu (ang. Development Team).
Role główne:

Zespół - grupa osób, składająca się od trzech do dziewięciu osób, odpowiedzialna za
dostarczenie produktu

Właściciel produktu - osoba reprezentująca klienta. Właściciel produktu może być
członkiem zespołu, jednak nie jest zalecane, aby jednocześnie był Scrum Masterem

Scrum Master - osoba odpowiedzialna za usuwanie wszelkich przeszkód
uniemożliwiających zespołowi wykonanie zadania, oraz za poprawną implementację
procesu i metod.
WARTOŚCI W SCRUMIE
Scrum to inaczej proces o niepowtarzającym się przebiegu, szkielet dla reguł, ról
i zasad, które pomagają indywidualnym osobom i organizacjom stworzyć swój własny proces,
odpowiadający ich konkretnym potrzebom. Scrum tworzy prostą podstawę działania, która
zastępuje dotychczasowe procesy rozwoju produktu. Korzyści płynące ze Scruma są większe,
jeżeli uzupełni się je o usprawnione lub zmienione praktyki w zakresie wytwarzania,
zarządzania
produktem,
pracy
zespołu
czy
funkcjonowania
organizacji.
Zmiana
podstawowych założeń Scruma i nieprzestrzeganie jego reguł zatuszuje natomiast problemy i
ograniczy, a nawet wyeliminuje, korzyści płynące z podejmowania dodatkowych działań.
Fakt, że podstawowe wartości Scruma są mało znane i prawdopodobnie za słabo
podkreślane, wcale nie oznacza, że należy je pomijać. Mimo że nie zostały one opracowane
specjalnie na potrzeby Scruma i na jego wyłączny użytek, to jednak nadają one kierunek
pracy i wpływają na zachowania i działania. Podejmowane decyzje i kroki, sposób realizacji
procesu, poszerzanie Scruma o dodatkowe zadania, a także wszelkie czynności powinny
przyczyniać się do wzmacniania tych wartości, a nie je umniejszać czy podważać.
Zaangażowanie
Odwaga
Skupienie
SCRUM
Szacunek
Otwartość
Nawiązywanie do wartości w celu oceny wartości dodanej działań okazuje się
niezwykle przydatne. Stanowią one pomoc już na etapie samego rozważania, czy zastosować
reguły Scruma, czy nie.
Oto szczegółowe spojrzenie na wartości i na to, jak mogą one pokierować krokami i
zachowaniem w kontekście Scruma:
ZAANGAŻOWANIE
Zaangażowanie w kontekście Scruma jest powszechnie źle interpretowane. Bierze
się to stąd, że kiedyś oczekiwano od zespołów scrumowych zobowiązania się do
zrealizowania celu danego sprintu i wybranych elementów z rejestru produktu. Z powodu
przestarzałego, przemysłowego sposobu myślenia (które niestety zbyt długo pokutowało w
obszarach związanych z wytwarzaniem oprogramowania) oczekiwano dostarczenia całości za
wszelką cenę. „Zobowiązanie” zostało uznane za sztywny wymóg, choć miało ono znaczyć
tylko tyle, że zespół będzie maksymalnie przykładał się do swojej pracy w sprincie i
dostarczał przejrzystych informacji co do postępu prac. Zresztą w złożonym, kreatywnym i
nieprzewidywalnym świecie wytwarzania oprogramowania jakiekolwiek zobowiązania
odnośnie zakresu prac są po prostu niemożliwe.
Definicja słowa podana przez Oxford Dictionaries najlepiej oddaje jego
„scrumowe” pierwotne znaczenie:
Zaangażowanie – stan lub cecha bycia oddanym jakiejś sprawie, działaniu, etc.
A zatem poprzez „zaangażowanie” należy rozumieć aktywne uczestnictwo odnoszące się do
podejmowanych działań i włożonego wysiłku, a nie ostatecznego produktu.
W Scrum Guide zastąpiono słowo „zaangażowanie”, wynikające z planowania sprintu,
hasłem „prognoza”. Dzięki powiązaniu prognozy z zakresem prac unika się błędnej
interpretacji. Dodatkowo świetnie współgra ona z faktyczną naturą Scruma.
Zaangażowanie wciąż pozostanie jednak jedną z kluczowych wartości.
Członkowie zespołu angażują się:








w pracę zespołu, w podnoszenie jakości, we współpracę, w uczenie się nowych
rzeczy starają się wykrzesać wszystkie siły, by każdego dnia dawać z siebie wszystko
by osiągnąć cel sprintu i by działać profesjonalnie
w samo-organizację, dążenie do doskonałości i przestrzeganie zwinnych wartości
by stworzyć działające oprogramowanie
w poszukiwanie ulepszeń i przestrzeganie reguł Scruma
by spełnić definicję ukończenia, by działać zgodnie z wartościami i ukończyć pracę
w badanie rzeczywistości i dostosowywanie się do niej
dążąc do przejrzystości.
SKUPIENIE SIĘ NA NAJWAŻNIEJSZYM
Charakterystyczna w Scrumie praca w iteracjach, polegająca na dostarczaniu
kolejnych przyrostów, i narzucone ramy czasowe pracy pomagają się skoncentrować.
Członkowie zespołów skupiają się na:





tym, co istotne tu i teraz, bez zastanawiania się na tym, co może stać się ważne za
jakiś czas
tym, co wiedzą w danej chwili bez analizowania zbędnych alternatyw
najbliższej przyszłości, ponieważ ta dalsza jest zbyt niepewna, a chcą uczyć się dziś,
aby zdobyć doświadczenie niezbędne do przyszłych zadań
pracy, by wykonać to, co do nich należy
najprostszych rzeczach, które mogą zadziałać.
OTWARTOŚĆ
Scrum wymaga przejrzystości i otwartości dlatego członkowie zespołów powinni być otwarci
na:







badanie rzeczywistości, aby móc się do niej przystosować w rozsądny sposób
krytykę, uwagi dotyczące ich pracy, dokonywanych postępów, sposobu uczenia się i
napotykanych problemów
ludzi i współpracę z nimi, postrzeganie innych jako rzeczywiste osoby, a nie zasoby,
roboty czy części większej machiny, które łatwo zastąpić – ostatecznie tworzenie
oprogramowania nadal pozostaje domeną człowieka
współpracę ze specjalistami z różnych dziedzin, posiadającymi różne umiejętności
współpracę z interesariuszami i szerszym otoczeniem
wzajemne uczenie się
zmianę, gdyż organizacja i rzeczywistość, w której funkcjonują, zmienia się ciągle w
sposób nagły i trudny do przewidzenia.
SZACUNEK
Członkowie zespołów powinni okazywać szacunek:










ludziom, ich doświadczeniu i pochodzeniu
różnorodności, która sprawia, że stają się silniejsi
odmiennym zdaniom, które pozwalają im się uczyć
sponsorom, nie tworząc funkcjonalności, z których i tak nikt nie będzie korzystał
poprzez nie marnowanie środków na coś, co jest nic niewarte lub nigdy nie będzie
wdrożone czy wykorzystane
użytkownikom, rozwiązując ich problemy
poprzez przestrzeganie zasad, którymi kieruje się Scrum
otoczeniu, nie zachowując się jak samotna wyspa
umiejętnościom, specjalistycznej wiedzy i intuicji innych
poprzez akceptację podziału ról w Scrumie.
ODWAGA
Zespoły scrum’owe charakteryzują się odwagą:











by nie tworzyć czegoś, czego nikt nie chce
przyznawania, że wymagania nigdy nie będą idealne oraz, że nawet najlepszy plan nie
uwzględni w pełni rzeczywistości i stopnia jej złożoności
by traktować zmianę jako źródło inspiracji i motywacji
by nie dostarczać oprogramowania, które nie jest skończone
by dzielić się wszystkimi informacjami (przejrzystość), które mogą pomóc zespołowi i
organizacji
przyznawania, że nikt nie jest doskonały
zmiany obranego kierunku
by informować się nawzajem o ryzyku i korzyściach
promowania Scruma oraz podejścia w procesie radzenia sobie ze skomplikowanymi
zadaniami
by wznieść się ponad zwodnicze pewniki przeszłości
by działać zgodnie z wartościami Scruma.
PODSUMOWANIE SCRUM W PUNKTACH:








jest opartym o empiryzm, zwinnym (ang. agile) sposobem planowania i kontrolowania
przebiegu prac projektowych
jest iteracyjnym i inkrementalnym sposobem wytwarzania oprogramowania
(szczególnie o wysokim stopniu złożoności i/lub ryzyka)
jest narzędziem porządkującym i kontrolującym interesy osób zaangażowanych w
realizację projektu
jest narzędziem porządkującym komunikację i maksymalizującym stopień współpracy
wewnątrz– i pozazespołowej
jest opartym o samoorganizację sposobem zwiększania produktywności zespołu
prowadzi do głębokich strukturalnych przemian organizacji mających na celu jej
uzwinnienie i wyszczuplenie
nie wprowadza nowych i nie interferuje z już stosowanymi praktykami inżynierskimi
(często stosowany w tandemie z eXtreme Programming Scrum nie traktuje o
praktykach inżynierskich, skupiając się na zagadnieniach związanych z organizacją
pracy)
jest skalowalny od pojedynczych zespołów do całych organizacji i przedsiębiorstw