The Scrum Guide is Dead — Long Live the Scrum Guide!

share

Ken Schwaber i Jeff Sutherland – autorzy Scrum – co kilka lat wydają kolejną wersję „Scrum Guide”, czyli przewodnika po Scrum. To dokument wyczerpująco opisujący ramy postępowania, z uwzględnieniem ról, zdarzeń, artefaktów i reguł. W listopadzie 2020 roku pojawiła się jego długo wyczekiwana aktualizacja. Nowa wersja przewodnika Scrum przynosi szereg bardzo ciekawych i dobrych zmian, które nadają całemu procesowi jeszcze większej elastyczności. 

Najpierw omówmy krok po kroku zmiany przedstawione na scrum.org.


1. Jeszcze mniej nakazów

Przewodnik Scrum obrósł z biegiem lat pewnymi nakazami. Wersja z 2020 r. miała przywrócić metodykę Scrum do postaci podstawowych ram postępowania – poprzez usunięcie postanowień nakazowych z treści przewodnika, a przynajmniej złagodzenie nakazów (i tak np. usunięto codzienne pytania Scrum, rozluźniono wymagania dotyczące atrybutów PBI oraz pozycji przeszłych (retro) w rejestrze zadań przebiegu (Spring Backlog), skrócono część anulowania przebiegu (sprintu) itd.).
>>
Co to znaczy?

Obecnie jest tyle implementacji Scrum, co produktów, w których Scrum wykorzystano jako podstawowe podejście SDLC. Omawiane zmiany czynią ramy postępowania Scrum nieco bardziej elastycznymi. Dlaczego? Przeanalizujmy to dokładnie:

  1. Nie trzeba bezwzględnie używać codziennych pytań Scrum. Ważne jest, by ludzie mogli wysłuchać innych, dzielić się opiniami i w razie potrzeby zasięgnąć pomocy. Rozmowę w zespole można stymulować na wiele sposobów, dlatego też nie powinniśmy się ograniczać pytaniami lub stwierdzeniami typu „co zrobiłem”, „co zrobię” i „jakie są przeszkody”.
  2. W przypadku PBI (pozycji rejestru wymagań – Product Backlog) dobrze jest zawsze zadbać o wystarczający poziom szczegółowości, wielkości, wartości itd. Jednakże pozycje takie powinny odpowiadać potrzebom i domenom biznesowym. Dlatego PBI nie ograniczają się wyłącznie do takich atrybutów. Złagodzenie wymagań wobec atrybutów PBI zwiększa elastyczność metodyki i pozwala uniknąć konieczności porządkowania.
  3. Pozycje przeszłe mają od teraz skróconą postać. Autorzy po prostu nakreślają kluczowe aspekty, które należy omówić podczas spotkania retrospektywnego. Istnieją dziesiątki narzędzi umożliwiających wybór takiego podejścia do retrospektywy, które najlepiej sprawdzi się w danym zespole. Ogólniej rzecz ujmując, znosi to nakazy określające, kto ma konkretnie co robić, a pozwala skupiać się raczej na wynikach prac.
  4. Skrócono inne zapisy przewodnika Scrum, przez co stały się bardziej czytelne – nie przytłaczają opisu procesu informacjami o oczywistych skutkach pewnych czynności, np. efektów odwołania przebiegu.


2. Jeden zespół pracuje nad jednym projektem

Celem tej zmiany było usunięcie koncepcji powoływania oddzielnej komórki w zespole projektowym, której obecność wymagała „przedstawiciela” lub podziału na „my i oni” między PO i zespołem developerów. Przewodnik obecnie zakłada istnienie jednego zespołu Scrum pracującego nad jednym i tym samym celem, z podziałem odpowiedzialności na trzy obszary: PO, SM i developerów.
>>
Co to znaczy?

W poprzedniej wersji przewodnika nie przewidziano podrzędnych zespołów, komórek w zespole developerów – w najnowszej wersji takie podejście objęło szczebel całego zespołu Scrum. Mentalność „my i oni” usunięto po raz pierwszy w wydaniu z 2011 r., rezygnując z porównania do „kur i prosiaków”. Logicznym krokiem było zatem, w obecnym wydaniu, usunięcie podziału na zespoły PO i developerów. Wielkość zespołu w obecnej wersji przewodnika odpowiada wielkości całego zespołu Scrum, nie zaś wyłącznie zespołu developerów. W wydaniu z 2020 r. zaleca się (choć zapis ten nie ma charakteru bezwzględnego), by zespół Scrum liczył nie więcej niż 10 osób, a także rozsądnie uzasadniono, dlaczego zespół mniejszy pracuje lepiej.

Celem tych zmian jest zwiększenie odpowiedzialności zespołu Scrum za produkt i proces. Im ściślej członkowie współpracują ze sobą, tym lepiej wychodzi im realizacja naprawdę wartościowych produktów.


3. Wprowadzenie pojęcia „celu produktu”

Przewodnik Scrum w wersji z 2020 r. wprowadza pojęcie „Product Goal”, czyli „celu produktu” – w założeniu ma ono skupić zespół Scrum na większym, bardziej wartościowym celu. Dlatego każdy przebieg (sprint) powinien zbliżać założony produkt coraz bardziej do ogólnego, znanego „celu produktu”.
>>
Co to znaczy?

Chyba najważniejszą z ostatnich zmian w ogólnej koncepcji ram postępowania Scrum jest pojęcie „celu produktu”. Metodyka Scrum trafiła do mnóstwa dziedzin wykraczających poza tworzenie produktów oprogramowania, z której przecież wyrosła. Produktem może być zatem usługa, fizyczny wyrób lub coś bardziej abstrakcyjnego. W zależności od oczekiwanych wyników – w rozumieniu różnych podejść – można za produkt uznać wynik pośredni tych produktów, których wartość dzieli się na etapy kluczowe („kamienie milowe”) lub wydania („release’y”).

Cel produktu opisuje przyszły stan tworzonego produktu, dlatego należy przede wszystkim podążać za ustalonym celem i tym samym, w sposób ciągły, sprawdzać, czy zespół Scrum tworzy wartościowe produkty. Jeśli w kolejnych przebiegach brakuje systematycznego dążenia do celu produktu, zespół Scrum może przysłowiowo zejść na manowce, skazując produkt na porażkę.


4. „Dom” celu przebiegu, „Definition of Done” (definicja ukończenia), a cel produktu

W poprzednich wydaniach przewodnika Scrum opisano cel przebiegu (Sprint Goal) oraz definicję ukończenia (Definition of Done), lecz tak naprawdę nie określono ich tożsamości, tj. czym konkretnie są. Nie były w pełni artefaktami, były pojęciami związanymi z artefaktami. Jednakże wraz z wprowadzeniem „celu produktu”, wersja na 2020 r. pozwala uściślić pozostałe dwa pojęcia. Tym samym od teraz wszystkie te trzy artefakty mają „zobowiązania” („commitment”) wobec nich. W przypadku rejestru wymagań (Produkt Backlog), zobowiązaniem jest cel produktu, w przypadku rejestru zadań przebiegu (Spring Backlog) jest to cel przebiegu, zaś dla przyrostu (Increment) jest to definicja ukończenia (Definition of Done – zauważmy, że zapisywana od teraz bez cudzysłowu). Zobowiązania wprowadzono, aby uściślić każdy z trzech omawianych artefaktów oraz by skupić się na postępach ich realizacji.
>>
Co to znaczy?

Zobowiązaniem jest chęć starannej pracy, włożenia wysiłku i poświęcenia czasu na jakieś zadanie lub czynność. Stworzenie artefaktu podyktowane powinno być chęcią osiągnięcia konkretnych celów. Dzięki „zobowiązaniom” możemy bezpośrednio powiązać pozycję rejestru wymagań (PBI) z pożądanym, oczekiwanym stanem naszego produktu. PBI staje się „przyrostem”, gdy spełni przesłanki zobowiązania „definicji ukończenia”. Zbiór przyrostów zgodnych ze zobowiązaniem „celu przebiegu” zbliża opracowywany produkt do jego stanu pożądanego, który z kolei nakreślono w zobowiązaniu „celu produktu”.


5. Samozarządzanie zamiast samoorganizacji

W poprzednich wydaniach przewodnika Scrum mówiono, że zespoły developerskie organizują się samodzielnie, określając niezależnie, kto ma wykonać daną pracę i w jaki sposób. Wydanie z 2020 r. skupia się raczej na zespole Scrum, a tym samym podkreśla istotność jego „samodzielnego zarządzania sobą samym” – wedle którego to zespół Scrum określa, kto ma wykonać daną pracę, sposób, w jaki ma ją wykonać, i nad czym będzie pracował.
>>
Co to znaczy?

Wprowadzenie właściciela produktu (PO, Product Owner) i developerów do jednego zespołu Scrum pozwala „wypłaszczyć” SDLC w taki sposób, aby lepiej uwzględnić aspekty do rozważenia podczas prac rozwojowych.


6. Trzy tematy planowania przebiegów

Poza tematami planowania przebiegu będącymi kwestiami „co?” i „jak?”, w przewodniku Scrum na 2020 r. skupiono się na trzecim zagadnieniu związanym z celem przebiegu – „Dlaczego?”.
>>
Co to znaczy?

To bardzo proste. Na etapie planowania przebiegu, PO (właściciel produktu) proponuje, w jaki sposób wartość produktu może wzrosnąć w ramach obecnego przebiegu. Następnie cały zespół Scrum pracuje nad ustaleniem celu przebiegu, który jest odpowiedzią na pytanie, dlaczego przebieg ma wartość dla osób nim zainteresowanych.

Kolejność planowania przebiegu: Dlaczego? -> Co? -> Jak?

Jest to jednocześnie kolejna okazja, by sprawić, że bieżący cel przebiegu zwiększy wartość produktu. W takiej metodzie planowania łączy się cel przebiegu z celem produktu.


Wnioski

Przewodnik „Scrum Guide” na 2020 r. napisano językiem uproszczonym, bardziej zrozumiałym dla szerszego kręgu odbiorców. Przede wszystkim usunięto w nim złożone, zbędne zapisy oraz resztki nawiązań do pracy typowej dla sektora IT (np. testowanie, system, budowa, wymagania itp.). Najnowszy „Scrum Guide” liczy mniej niż 13 stron.

Bieżące wydanie ma język o charakterze mniej nakazowym, ponieważ, ze względu na współczesne realia i powszechność metodyki Scrum, jej podstawowe elementy powinny odpowiadać kontekstowi i zależeć od konkretnych produktów lub uwarunkowań, zamiast stanowić kompleksowe rozwiązanie, które pasuje tylko do pewnych produktów, a do innych już nie.

Autor

Roman Shcherbak

Project Manager

Zobacz artykuły

Kategoria artykułu

Inne kategorie na blogu:

Popularni autorzy

Marcin Medyński

Marcin Medyński

Consultant

Patryk Siedlecki

Patryk Siedlecki

Software Engineer

Piotr Doskocz

Piotr Doskocz

Lead Software Engineer

Piotr Andrusiuk

Piotr Andrusiuk

Senior Project Manager

Monika Malucha

Monika Malucha

Senior Marketing Specialist