Podstawy Scruma W 5 Minut

Obszar zarządzania projektami jest dosyć mocno rozbudowany. Młoda i świeża osoba która wcześniej nie miała do czynienia z poszczególnymi metodami może czuć się zagubiona. I będzie w pełni usprawiedliwiona ponieważ odpowiedź na pytanie „Co będzie dla mnie najlepsze?” nie jest taka oczywista. Niestety, zarządzanie projektami to również biznes i grube budżety przeznaczone na działania marketingowe. Dlatego chcę przedstawić, w łatwo przyswajalnej pigułce, najpopularniejsze podejścia do zarządzania projektami. To nie jest tak, że coś jest gorsze, a coś lepsze. Po prostu są metody które sprawdzają się w danym środowisku. Nic więcej.

Poniższy tekst to pigułka informacji. Jeżeli chcesz ugruntować swoją wiedzę lub przygotowujesz się do egzaminu PSM I odsyłam Cię do oficjalnego „Przewodnika po Scrumie”.

Czym jest Scrum?

Już na pewno się domyśliłeś, Scrum ma dużo wspólnego z projektami. Stosuje się go w projektach, gdzie zastosowanie mają metodyki zwinne (Agile). Scrum wyrósł w środowisku IT i właśnie tutaj jest najczęściej stosowany. Jego sercem jest Sprint czyli określony przedział czasu (maksymalnie 4 tygodnie, nie więcej) podczas którego rozwijana jest użyteczna wartość produktu.

Aby zrozumieć Scruma należy poznać jego 4 główne elementy, czyli:

• Wartości
• Zespół
• Wydarzenia
• Artefakty

To teoria, a jak wygląda praktyka? Przede wszystkim Scrum to ludzie którzy w ustandaryzowany sposób budują określoną wartość. Scrum to również zestaw dobrych praktyk, standardów, ram postępowania i zachowań. Zdaje sobie sprawę, że sama definicja może wydawać się dosyć oszczędna. Pamiętajmy, że sam Scrum Guide (Przewodnik po Scrumie) liczy jedynie 13 stron, w porównaniu do podręcznika Prince 2 firmy Axelos który posiada 365 stron :). Daje to do myślenia. Dla twórców Scruma liczy się esencja i dodawanie wartości, a nie rozbudowana teoria która, w rzeczywistych warunkach, bywa ciężka do wdrożenia. Zresztą, już na pierwszej stronie Przewodnika możemy przeczytać, że Scrum jako ramy postępowania jest niekompletny i to celowo ponieważ celem jest budowanie relacji i kształtowanie interakcji, a nie szczegółowe instrukcje wyjaśniające każdy ruch.

Historia

W 1986 roku dwóch japońskich profesorów opublikowało artykuł o tytule „The New New Product Development Game”. Hirotaka Takeuchi i Ikujiro Nonaka, bo o nich tu mowa, wykazali jak bardzo tradycyjne podejście do zarządzania projektami jest nieefektywne. Podejście waterfallowe (inaczej kaskadowe), rozpropagowane przez NASA, było ogólnie przyjętym standardem zarządzania projektami. Jednak największe organizacje takie jak 3M czy Honda korzystały z innego modelu. Autorzy przeanalizowali styl pracy najefektywniejszych graczy na rynku. Wynikało z nich, że przewagę buduje się poprzez budowę autonomicznych zespołów, a nie centralizowanie decyzji. Kierownicy z kolei nie byli poganiaczami pracowników, a pełnili rolę służebną i torowali zespołom drogę do swobodnej pracy. W artykule użyto ciekawego porównania, otóż praca najlepszych zespołów projektowych była porównana do współpracy zawodników rugby w tzw. młynie (ang. scrum).

Po 7 latach artykuł trafił w ręce późniejszego autora metodologii Scrum. Był nim Jeff Sutherland. Szukał on alternatywy dla nieskutecznego w środowisku programistycznym modelu waterfallowego. Pomimo tego, że „The New New Product Development Game” dotyczył produkcji to J. Sutherland znalazł w nim to czego szukał. Dwa lata później wraz ze swoim kolegą, Kennem Schwaberem, opisał dokładnie na czym polega nowy sposób budowania oprogramowania. Panowie przedstawili swoje założenia na konferencji Association for Computing Machinery, pod nazwą SCRUM Development Process.

Wartości Scruma

Scrum opiera się na pięciu wartościach. Są to:

• Zaangażowanie,
• Skupienie,
• Otwartość,
• Szacunek
• Odwaga

Nie wszyscy mogą od razu wiedzieć jak wyżej wymienione wartości objawiają się w codziennej pracy scrumowych zespołów. W dużym skrócie chodzi o to aby zespół wykorzystywał wszelkie możliwości i umiejętności (zaangażowanie) na drodze do osiągnięcia wyznaczonego celu. Poświęca również całą uwagę (skupienie) na pracy która dodaje wartość. Członkowie zespołu podchodzą w nieskrępowany sposób (otwartość) do nowych wyzwań i informacji zwrotnych. Praca w zespołach scrumowych jest intensywna ale pamiętajmy, że najważniejszy jest drugi człowiek dlatego podstawą we współpracy wewnątrz zespołu i z klientami jest wzajemny szacunek. Aby z sukcesem mierzyć się z problemami w projekcie konieczna jest odwaga by podważać status quo i pracować w nieszablonowy sposób.

Scrum został zbudowany na fundamentach empiryzmu i lean. Empiryzm oznacza to, że wszystkie decyzje opierane są o fakty, dane, doświadczenie i obserwacje. W żadnym wypadku o opinie. Lean z kolei wskazuje na to aby koncentrować się na tym co dodaje wartości i eliminować marnotrawstwa.

Empiryzm jest kluczem do zrozumienia pracy w Scrumie. Objawia się on za pomocą przejrzystości, inspekcji i adaptacji. Przejrzystość oznacza konieczność uwidocznienia pracy zarówno dla współpracowników jak i dla klientów. Skoro podejmujemy decyzję na podstawie faktów danych i obserwacji konieczna jest transparentność. Mówi się, że im częściej się mierzymy tym częściej mamy okazję do wprowadzenia udoskonaleń, o to właśnie chodzi w inspekcji. Im częściej poddajemy naszą prace merytorycznym przeglądom tym częściej możemy się udoskonalać. Adaptacja polega na jak najszybszym wprowadzeniu udoskonaleń naszej pracy lub produktu. Jeśli nasz cel nie jest osiągany, przekraczamy limity, mamy problemy z jakością to jak najszybciej musimy skorygować naszą pracę.

Wróćmy jeszcze na kilka chwil do wartości Scruma. Miejmy na uwadze różnice pomiędzy j. polskim i j. angielskim. Często podczas tłumaczenia jeden do jednego możemy stracić głębsze znaczenie. Najlepszym tego przykładem jest wyrażenie commitment czyli, przekładając na polski, zaangażowanie. Jednak nie jest to pełne znaczenie. Commitment w j. angielskim oznacza mieszanką zaangażowania i zobowiązania. Właśnie zobowiązanie jest kluczowe, jeśli rozmawiamy o wartościach w Scrumie. Zespół jest zobowiązany i zaangażowany w dostarczanie najlepszych rezultatów.

Scrumowy zespół

Scrumowy zespół liczy maksymalnie 10 osób, jest to natomiast rekomendacja nie twarda zasada. Większa ilość zaangażowanych osób zwiększa złożoność, a chodzi o to aby maksymalnie upraszczać to co jest możliwe.

W scrumowym zespole wyróżniamy trzy role. Są to:

• Developerzy
• Product Owner
• Scrum Master

Developerzy

Developerzy odpowiedzialni są za wytworzenie każdej części Incrementu (Increment to Artefakt, więcej o tym opowiem w dalszej części). Warto wspomnieć o tym, że zespoły te same planują swoją pracę czyli tworzą Sprint Backlog (Artefakt). Tutaj też możemy zaobserwować wpływ empiryzmu ponieważ deweloperzy koniecznie muszą dostosowywać plan i swoje działania aby osiągać cele Sprintu i sami egzekwują od siebie założone wyniki. Wszystko co developarzy wytworzą musi być zgodne z Definicją Ukończenia. Developerzy są odpowiedzialni za dopilnowanie tego.

Product Owner

Product Owner odpowiedzialny jest za Cel Produktu oraz Product Backlog (Artefakt). Oznacza to, że właśnie Product Owner decyduję o hierarchii elementów Product Backlogu, jest również odpowiedzialny za jego stworzenie, przejrzystość i zrozumienie. Przy okazji warto podkreślić, że Product Owner to jedna (!) osoba. W żadnym wypadku nie powinien to być zespół, komitet czy odpowiedzialność która spoczywa na większej ilości osób. Jeżeli interesariusze, klienci czy osoby wewnątrz organizacji chcą wpłynąć na kształt projektu – muszą rozmawiać z Product Ownerem, to on ma moc decyzyjną i od niego zależy ostateczny kształt Product Backloga.

Scrum Master

Rolą Scrum Mastera jest wsparcie organizacji, Product Ownera oraz zespołu Deweloperów. Punktem wyjściowym jego roli jest przeświadczenie, że tylko w pełni stosując reguły Scruma można osiągnąć zamierzone wyniki. Scrum Master stoi na straży tych reguł i pilnuje aby były stosowane. Nie jest to oczywiście policjant który wystawia mandaty za naginanie reguł, a raczej doświadczony opiekun który dba o dobro zespołu i produktu.

Warto aby Scrum Master był odpowiednio umiejscowiony w organizacji. Jego zadaniem jest torowanie drogi dla zespołu. Dlatego ważne aby miał realne możliwości i wpływ na rozwiązywanie problemów. Również tych na poziomie organizacji. Scrum Master to, podobnie jak Product Owner, jedna osoba. Jego funkcja jest wspierająca – szkoli, doradza, proponuje odpowiednie narzędzia w zależności od potrzeby.

Wydarzenia w Scrumie

Sercem i corem Scruma jest Sprint. Jest to nadrzędne wydarzenie które zawiera wszystkie inne wydarzenia czyli:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Sprint

Długość trwania Sprintu to maksymalnie 4 tygodnie. Im krótszy czas pracy w określonym Sprincie tym większa jest możliwość dostosowania pracy i celów do ciągle zmieniających się warunków i oczekiwań. Wydarzenia w Sprincie ułożone są tak aby zachować przejrzystość umożliwiającą inspekcję i adaptację. Sprint jest wydarzeniem które może przerwać tylko Product Owner i to tylko w wypadku kiedy Cel Sprintu został zdezaktualizowany.

Sprint Planning

Pierwszym krokiem, otwierającym serię wydarzeni w Sprincie jest Sprint Planning. Jak sama nazwa wskazuje jego celem jest rozplanowanie całej pracy w Sprincie, robi to cały scrumowy zespół. Na jego wniosek mogą zostać zaproszone inne osoby, wszystko po to aby jak najlepiej rozplanować pracę. Spora odpowiedzialność ciąży na Product Ownerze, który jest odpowiedzialny za to aby wszystkie założenia były dla każdego zrozumiałe.

Podczas Sprint Planningu zespół odpowiada na trzy główne pytania:

• Dlaczego ten Sprint ma wartość? Podczas tego pytania uczestnicy zastanawiają się jak stworzyć jak największą wartość oraz definiują Cel Sprintu.
• Co może zostać ukończone w tym Sprincie? Tutaj uczestnicy podejmują decyzję które elementy Product Backlogu wejdą w rany Sprint Backlogu czyli podejmowana jest decyzja nad czym będzie wykonywana praca.
• W jaki sposób zostanie wykonana praca? Tutaj uczestnicy planują swoją pracę. Jeżeli to koniecznie elementy dzielone są na mniejsze kroki.

Daily Scrum

Daily Scrum to 15 minutowe spotkanie odbywające się codziennie. Co ważne, to spotkanie zarezerwowane jest dla developerów. Oznacza to, że developerzy decydują w jakiej formie chcą przeprowadzić to spotkanie oraz kogo ewentualnie doprosić. Scrum Guide podkreśla aby spotkanie to odbywało się o tej samej porze i w tym samym miejscu by ograniczyć złożoność. Uważam jest to sensowna praktyka i nie ma sensu z niej rezygnować. Celem Daily Scruma (lub po prostu Daily) jest sprawdzenie postępów i dostosowanie najbliższych planów. Czyli wg. Scrum Guida, jest to miejsce na inspekcję i adaptację.

Powiedziałem wyżej, że Daily jest spotkaniem dla developerów. Tak mówi Scrum Guide, oznacza to m.in, że management firmy nie może przyjść na spotkanie aby np. skontrolować postęp prac czy zadać kilka „ping-pongów”. Może natomiast przyjść na wyraźną prośbę developerów. Podobnie sprawa się ma z klientem. Świetnie ten temat poruszył Mateusz Żeromski w „Mapa Agile & Scrum” (kliknij tutaj). Realia są takie, że warto zapraszać klientów na Daily jednak należy również przemyślanie podchodzić do tego co klientowi możemy pokazać na danym etapie.

Sprint Review

Jest to wydarzenie w którym bierze udział cały Zespół Scrumowy oraz kluczowi interesariusze. Podkreślam słowo kluczowi, pytanie o to znalazło się w teście na PSM I w tym roku. Jego timebox, czyli maksymalny czas trwania to 4 godziny dla 4 tygodniowego Sprintu. Celem tego wydarzenia jest przegląd pracy wykonanej przez developerów. Innymi słowy jest to miejsce na inspekcję efektów i podjęcie decyzji co do dalszych kroków. Jest to również okazja do wprowadzenia zmian w Product Backlogu jeżeli w tzw. otoczenie biznesowe się zmieniło.

Sprint Review jest spotkaniem roboczym, unikajmy więc suchych prezentacji. Warto poświęcić ten czas na empiryczne podejście do wykonanej pracy.

Sprint Review jest przedostatnim wydarzeniem w Scrumie. Na teście PSM I może paść pytanie o to gdzie jest to wydarzenie jest umiejscowione i prawidłową odpowiedzią jest „At the end of the Sprint”. Może to być mylące ponieważ Sprint kończy się retrospektywą (Sprint Retrospective) jednak pamiętajmy o niuansach pomiędzy j. polskim i j. angielskim.

Sprint Retrospective

Retrospektywa Sprintu, w mojej opinii, jest ciekawym wydarzeniem. Cały Scrum Team przygląda się swojej pracy w obecnym Sprincie i usprawnia ją. Warto wspomnieć o tym, że nie przeglądany jest wynik pracy, a sam proces, relacje pomiędzy uczestnikami czy wykorzystanie narzędzi. Analizowane są problemy które wystąpiły i metody w jaki sposób sobie z nimi poradzono. Wybrane usprawnienia można włączyć w kolejny Sprint Backlog, ważne aby był wprowadzone bez zbędnej zwłoki.

Sprint Retrosepctive jest wydarzeniem w którym bierze udział cały Scrum Team i jest to wydarzenie dedykowane tylko dla nich. Oznacza to, ze nie ma na nie wstępu nikt z poza zespołu. W przeciwnym razie skutek może być taki, że spotkanie będzie nieefektywne, a uczestnicy nie będą komunikowali się w otwarty sposób. Timebox Retrospektywy to maksymalnie 3 godziny dla 4 tygodniowych Sprintów. Koniecznie muszę wspomnieć o tym, że zarówno Product Owner jak i Scrum Master biorą udział w tym spotkaniu na tych samych zasadach co reszta uczestników. Retrospektywa jest ostatnim zdarzeniem w Sprincie.

Artefakty w Scrumie

Dla osób grających namiętnie w gry RPG słowo artefakt nie będzie czymś nowym, dla reszty może okazać się dosyć kłopotliwe. Na potrzeby wpisu, najlepiej będzie sprawdzić jak egzotyczne wyrażenie „Artefakt” definiuje Słownik Język Polskiego PWN. Artefakt tłumaczony jest jako: „coś, co jest dziełem ludzkiego umysłu i ludzkiej pracy w odróżnieniu od wytworów natury”. Myślę, że taka definicja będzie pomocna w zrozumieniu tego czym są Artefakty w Scrumie.

W Scrumie Artefaktami nazywamy wytwory pracy zespoły. Ich zadaniem jest sprawienie aby kluczowe informacje były dla wszystkich jasne i przejrzyste. Są 3 Artefakty i dla każdego przypisane jest określone zobowiązanie:

• Product Backlog, zobowiązanie to Cel Produktu,
• Sprint Backlog, zobowiązanie to Cel Sprintu,
• Increment, zoowiązanie to Definicja Ukończenia.

Product Backlog

Temat Product Backlogu już zdążyliśmy poruszyć. Jest to lista rzeczy które należy zrobić aby ulepszyć produkt. Jest to miejsce które jest źródłem pracy developerów. Lista rzeczy do zrobienia jest ułożona przez Product Ownera, to jest jego odpowiedzialność. Interesariusze mogą rzecz jasna wpływać na Product Ownera jednak to on podejmuje ostateczną decyzję w kwestii hierarchii.

Istotne jest to, że Product Backlog nie jest czymś raz zrobionym i zostawionym. Jest to element który zmienia i ewoluuje w czasie. Im dłużej pracujemy, tym wiemy więcej i nasze zapisy są bardziej szczegółowe.

Zobowiązaniem dla Product Backlogu jest Cel Produktu. Czyli, po prostu, przyszły stan produktu. Jest to drogowskaz który pokazuje, że team podąża w odpowiednim kierunku.

Sprint Backlog

Jest to plan pracy, stworzony przed deweloperów, na dany Sprint. Podobnie jak Product Backlog, nie jest stworzony raz i zostawiony. Jest uzupełniany w trakcie Sprintu, im Sprint jest bardziej zaawansowany tym więcej wiemy o jego poszczególnych elementach. Sprint Backlog jest również podstawą do oceny i estymacji pracy podczas Daily.

Zobowiązaniem dla Sprint Backlogu jest Cel Sprintu. Cel Sprintu jest niezmienny, jest to kluczowe zobowiązanie deweloperów, jednak już sposób w jaki cel zostanie osiągnięty jest dowolny. Najważniejsze aby nie rezygnować z jakości i aby wszystko było zgodne z Definicją Ukończenia.

Increment

Increment to mierzalny krok w stronę osiągnięcia Celu Produktu. Jest on spójny ze wcześniejszymi Incrementami. Jest również poddany szczegółowej inspekcji aby mieć pewność, że pasuje do wcześniejszych wersji.

Zobowiązaniem dla Incrementu jest wyżej wspomniana Definicja Ukończenia. Jest to opis standardów i kryteria jakościowe dla Incrementu. Oznacza to, że każdy Increment który tych standardów nie spełnia, nie może zostać wydany ani nawet pokazany szerszemu gronu. Jeżeli organizacja nie ma zbudowanej Definicji Ukończenia, musi to zrobić Scrum Team, zanim zacznie pracę nad produktem.

Teoria i praktyka Scruma

Pomimo tego, że Scrum Guide w jasny sposób opisuje podstawy, to pamiętajmy, że jest to tylko teoria. Zresztą, tak jak jest napisane w Scrum Guidzie, Scrum jest łatwy do zrozumienia ale ciężki do (nie przepadam za tym wyrażeniem) wdrożenia. Może się zdarzyć, że teoria rozmija się z praktyką. Dobrze o tym opowiedział Mateusz Żeromski w Mapa Agile & Scrum (kliknij tutaj). Książka opisuje podstawowe zagadnienia, nie ma tam za wiele tematów które będą interesujące dla zaawansowanych graczy, jednak będzie wartościowa dla osób które dopiero startują i chcą wiedzieć jak połączyć kropki.

Jeśli pracowałeś ze Scrumem i dopiero zastanawiasz się nad podejściem do PSM I to bądź czujny. Jak wspomniałem wyżej, teoria i praktyka Scruma to dwa osobne tematy. Nie wszystkie firmy pracują zgodnie ze Scrumem, pomimo tego, ze tak myślą.. Dlatego, nie opieraj swojej wiedzy na przypadkach ze swojej organizacji i skup na zrozumieniu Scrum Guida. Każde pytanie na teście filtruj przez Scrum Guida, nie własne doświadczenie.

Podsumowanie

Wpis jest częścią moich notatek które pomagały mi w przygotowaniu do zdania PSM I. Przeczytanie ze zrozumieniem Scrum Guida, zapisanie kluczowych informacji i narysowanie kilku map myśli było moją metodą przygotowawczą. Jeśli chcesz wiedzieć więcej o tym jak przygotować się do PSM I to lada moment pojawi się wpis „Refleksje po PSM I”. Opowiem w nim co mnie zaskoczyło bo nie wszystko było takie łatwe jak może się wydawać. Jeśli chcesz dowiedzieć się więcej, korzystaj ze sprawdzonego źródła. Scrum.org, tutaj znajdziesz wszystkie potrzebne informacje.

Chyba wyszło więcej niż 5 minut.