Aktywności i artefakty Scruma

Poniżej wyjaśnione zostały nie tylko najważniejsze aktywności i artefakty Scruma, ale także to, jak są one ze sobą powiązane.

Product Owner ma określoną wizję produktu. Ponieważ produkt może być bardzo złożony, w ramach tak zwanego Backlog Refinement jest on dzielony na mniejsze funkcjonalności (elementy), które są umieszczane na liście priorytetów – Product Backlogu.

Sprint rozpoczyna się od Sprint Planningu, obejmuje pracę rozwojową (Sprint Execution) w trakcie Sprintu i kończy się Review oraz Retrospektywą. Liczba elementów w Product Backlogu jest z reguły większa, niż zespół deweloperski byłby w stanie zrealizować w krótkim Sprincie. Dlatego na początku zespół deweloperski musi wybrać z Product Backlogu te elementy, które uważa, że jest w stanie ukończyć (Sprint Planning). Celem jest posiadanie na koniec Sprintu potencjalnie gotowego do wdrożenia przyrostu produktu.

Uwaga na temat aktywności w Scrumie

W 2011 roku zmiana w "The Scrum Guide" (Schwaber i Sutherland 2011) wywołała debatę na temat tego, czy odpowiednim terminem do opisania wyniku Sprint Planningu powinien być "forecast" (prognoza/oszacowanie) czy "commitment" (zobowiązanie). Zwolennicy terminu Forecast preferują to określenie, ponieważ nawet najlepsza ocena może się zmienić w wyniku pojawienia się nowych informacji w trakcie Sprintu. Istnieje również pogląd, że Commitment ze strony zespołu prowadzi do obniżenia jakości pracy, ponieważ zespół stara się za wszelką cenę dotrzymać wyznaczonego celu, lub też dlatego, że zespół może mieć tendencję do wyznaczania sobie zbyt niskich celów, aby na pewno móc je osiągnąć.

Nie ulega wątpliwości, że każdy zespół deweloperski powinien przedstawić oszacowanie tego, co uważa, że jest w stanie osiągnąć w ramach Sprintu. Jednak wiele zespołów deweloperskich mogłoby skorzystać na tym, gdyby na podstawie Forecastu wypracowały Commitment. Commitmenty prowadzą bowiem do silniejszego zaufania między Product Ownerem a zespołem deweloperskim, a także między poszczególnymi członkami zespołu. Ponadto Commitmenty ułatwiają planowanie krótkoterminowe i sensowne podejmowanie decyzji w organizacji. Gdy w rozwój produktu zaangażowanych jest kilka zespołów, Commitmenty pozwalają im lepiej koordynować swoje planowanie – jeden zespół może opierać swoje decyzje na Commitment innego zespołu. Commitment powinien jednak koncentrować się przede wszystkim na celu Sprintu, a nie tyle na otwartych taskach. Wraz z rosnącą wiedzą zespołom często udaje się osiągnąć cel Sprintu inaczej, niż pierwotnie zakładano. (W dalszej części najczęściej używany jest termin Commitment. Jeśli kontekst tego wymaga, stosowany będzie również termin Forecast.)

Aby upewnić się, że zespół deweloperski przedstawił sensowne Commitment, członkowie zespołu tworzą w trakcie Sprint Planningu drugi Backlog, zwany Sprint Backlogiem. W tym Sprint Backlogu za pomocą szczegółowych tasków (zadań) opisuje się, w jaki sposób zespół zamierza zaprojektować, rozwinąć, zintegrować i przetestować poszczególne elementy z Product Backlogu w trakcie danego Sprintu.

Kolejny krok to Sprint Execution, czyli realizacja Sprintu. Tutaj zespół deweloperski wykonuje niezbędne zadania, aby zrealizować wybrane funkcjonalności. W tej fazie codziennie odbywają się tak zwane Daily Scrumy, podczas których przeprowadzane są działania synchronizacyjne i kontrolne, a także adaptacyjne działania planistyczne. Dzięki temu członkowie zespołu są w stanie lepiej zarządzać swoimi procesami pracy. Na końcu Sprint Execution zespół wytwarza potencjalnie gotowy do wdrożenia Inkrement Produktu, który stanowi już część tego, co Product Owner sobie wyobrażał.

Zespół Scrumowy kończy Sprint przeglądem i dostosowaniem (inspect-and-adapt) produktu oraz procesu Scrum. Produkt jest oceniany podczas Sprint Review przez Zespół Scrumowy i Stakeholderów. Przegląd procesu Scrum, który jest wykorzystywany do tworzenia produktu, przeprowadzany jest przez członków zespołu w ramach wydarzenia zwanego Retrospektywą. W rezultacie mogą zostać wprowadzone zmiany w Product Backlogu lub w procesie deweloperskim.

W tym momencie cykl Sprintu rozpoczyna się od nowa. Zespół deweloperski określa teraz kolejne Product Backlog Items, które jest w stanie ukończyć. Po odpowiedniej liczbie Sprintów wizja Product Ownera zostanie zrealizowana, a wynik będzie mógł zostać zaprezentowany.

W dalszej części każda z tych aktywności i artefaktów zostanie szczegółowo omówiona.

Product Backlog

W pracy ze Scrumem zawsze najpierw realizowane są najważniejsze zadania. Product Owner – we współpracy z zespołem deweloperskim i interesariuszami – jest ostatecznie odpowiedzialny za kolejność tych kroków i musi ją komunikować w postaci listy priorytetów, czyli Product Backlogu. Przy tworzeniu nowych produktów elementy Product Backlogu to początkowo po prostu funkcjonalności potrzebne do zrealizowania wizji Product Ownera. Przy dalszym rozwoju produktów Product Backlog może zawierać również nowe funkcjonalności, zmiany w już istniejących funkcjonalnościach, konieczne naprawy defektów, ulepszenia techniczne itp.

Product Owner współpracuje z wewnętrznymi i zewnętrznymi interesariuszami, aby zebrać i określić Product Backlog Items. Następnie musi zadbać o to, aby wszystkie elementy zostały ustawione we właściwej kolejności (pod względem wartości, kosztów, wiedzy i ryzyka), tak aby najbardziej wartościowe elementy znajdowały się na samej górze, a mniej wartościowe niżej w Product Backlogu. Product Backlog to nieustannie rozwijający się artefakt. Gdy zmieniają się okoliczności dla przedsięwzięcia lub gdy rośnie zrozumienie produktu przez Scrum Team (dzięki informacjom zwrotnym podczas Sprintów), Product Owner może dodawać, usuwać i przerabiać elementy.

Zasadniczo projektowanie, opracowywanie, szacowanie i priorytetyzowanie Product Backlog Items nazywane jest Backlog Grooming lub Backlog Refinement.

Zanim jednak można zakończyć priorytetyzację czy uporządkowanie elementów w Product Backlogu, należy najpierw poznać zakres poszczególnych elementów. Zakres określa koszty, a Product Owner musi je znać, aby móc ustalić priorytet danego elementu. Scrum nie narzuca przy tym żadnej konkretnej jednostki miary. W praktyce wiele zespołów korzysta z relatywnych jednostek miary, takich jak Story Points lub Ideal Days. Relatywna jednostka miary nie wyraża bezwzględnego zakresu elementu, lecz jedynie jego zakres w stosunku do innych elementów.

Sprinty

W Scrumie istnieją iteracje lub cykle trwające do jednego miesiąca, które nazywane są Sprintami. Ukończony Sprint powinien zawsze dostarczać coś o wymiernej wartości dla klienta lub użytkownika.

Dla wszystkich Sprintów ustalane są ramy czasowe (Timebox) z określonym terminem rozpoczęcia i zakończenia, które zasadniczo powinny mieć taką samą długość dla każdego Sprintu. Po zakończeniu jednego Sprintu natychmiast rozpoczyna się kolejny. Nawet jeśli pojawiają się zmiany zakresu prac lub składu zespołu, które mogłyby wpłynąć na cel i w zasadzie nie powinny być wprowadzane w trakcie Sprintu, ze względu na pewne potrzeby biznesowe czasami nie da się tego uniknąć.

Sprint Planning

Praca w Product Backlogu może trwać kilka tygodni lub miesięcy, co znacznie przekracza to, co można osiągnąć w pojedynczym, krótkim Sprincie. Podczas Sprint Planningu Product Owner, zespół deweloperski i Scrum Master ustalają, które elementy Product Backlogu są najważniejsze dla następnego Sprintu. W ramach tego planowania Product Owner i zespół deweloperski uzgadniają cel Sprintu, czyli definicję tego, co ma zostać osiągnięte w nadchodzącym Sprincie.

Na podstawie tych wytycznych zespół deweloperski przegląda Product Backlog i wskazuje najwartościowsze elementy, które zespół jest w stanie faktycznie zrealizować w kolejnym Sprincie. Tempo pracy, nazywane również Sustainable Pace, powinno być dobrane tak, aby można je było utrzymać przez dłuższy czas bez problemów.

Aby lepiej wyczuć, co jest wykonalne, wiele zespołów dzieli każdy element Product Backlogu na poszczególne taski. Te taski, wraz z powiązanymi elementami, tworzą drugi backlog – Sprint Backlog.

Następnie zespoły deweloperskie szacują nakład pracy potrzebny do realizacji każdego elementu (zazwyczaj w godzinach). Rozbijanie elementów Product Backlogu na taski to forma projektowania i planowania Just-in-Time w celu ukończenia poszczególnych funkcjonalności. Przy czasie trwania Sprintu od jednego do czterech tygodni, Sprint Planning powinien zająć od dwóch do ośmiu godzin – więcej czasu nie należy na to przeznaczać. Istnieją różne podejścia, a jedno z najpopularniejszych opiera się na prostym cyklu: wybiera się element Product Backlogu (jeśli to możliwe, kolejny element z listy priorytetów Product Ownera), dzieli go na taski i ocenia, czy dobrze pasuje do Sprintu (biorąc pod uwagę inne elementy zaplanowane na ten Sprint). Jeśli pasuje do Sprintu i zostaje jeszcze wystarczająco dużo czasu, proces powtarza się do momentu, aż możliwości zespołu zostaną w pełni wykorzystane.

W innym podejściu Product Owner i zespół ustalają wszystkie pożądane elementy Product Backlogu jednocześnie. Tylko zespół deweloperski dokonuje podziału na poszczególne taski, potwierdzając tym samym, że jest w stanie ukończyć wszystkie wybrane elementy.

Realizacja Sprintu

Gdy Scrum Team zakończy Sprint Planning i uzgodni zawartość kolejnego Sprintu, zespół deweloperski zabiera się za realizację pracy (na poziomie zadań) niezbędnej do ukończenia poszczególnych funkcjonalności. Ukończenie oznacza w tym przypadku, że wykonane zostały wszystkie prace potrzebne do dostarczenia funkcjonalności o wysokiej jakości.

Nikt nie narzuca zespołowi deweloperskiemu, jak i w jakiej kolejności ma realizować zadania ze Sprint Backloga na poziomie tasków. Dzięki temu członkowie zespołu mogą samodzielnie określać swoją pracę na poziomie zadań i organizować się w sposób, który ich zdaniem najlepiej służy osiągnięciu Celu Sprintu.

Daily Scrum / Daily Standup

Każdego dnia podczas Sprintu, najlepiej o tej samej porze i w tym samym miejscu, członkowie zespołu przeprowadzają spotkanie zwane Daily Scrum. Spotkanie to powinno trwać maksymalnie 15 minut. Ten proces Inspect-and-Adapt bywa również nazywany Daily Stand-Up, ponieważ w praktyce wszyscy obecni często pozostają na stojąco, aby spotkanie było krótkie.

Powszechną praktyką podczas Daily Scrum jest to, że poszczególni członkowie zespołu odpowiadają na trzy pytania, co jest niezwykle pomocne dla reszty zespołu.

• Co udało mi się osiągnąć od ostatniego Daily Scrum?
• Nad czym prawdopodobnie będę pracować do następnego Daily Scrum?
• Co dokładnie powstrzymuje mnie przed robieniem postępów?

Dzięki odpowiedziom na te pytania każdy uzyskuje przegląd tego, co się dzieje, jakie są postępy w realizacji celu Sprintu, jakie zmiany w planie są przewidziane na następny dzień i jakie problemy wymagają rozwiązania. Aby zespół mógł zapewnić szybki i elastyczny przebieg pracy w Sprincie, Daily Scrum jest niezbędny.

Problemy nie są rozwiązywane podczas Daily Scrum. Zamiast tego zespoły mogą po Daily Scrum spotkać się ze wszystkimi zainteresowanymi w małych grupach, aby omówić problemy. Spotkanie Daily Scrum nie jest też tradycyjnym spotkaniem statusowym, takim jak te zwoływane przez kierownika projektu w celu informowania go o aktualnym stanie projektu. Daily Scrum służy raczej do komunikowania statusu elementów Sprint Backloga w ramach zespołu deweloperskiego. Przede wszystkim Daily Scrum to aktywność obejmująca przegląd, synchronizację i adaptacyjne planowanie, dzięki czemu samoorganizujący się zespół może wykonywać jeszcze lepszą pracę.

Definicja Ukończenia

W Scrumie wyniki Sprintów określane są jako potencjalnie gotowe do wydania inkrementy produktu. Oznacza to, że wszystko, co Scrum Team zamierzał osiągnąć, zgodnie z ustaloną Definition of Done (definicją tego, co można uznać za ukończone), zostało faktycznie ukończone. Ta definicja określa stopień, w jakim wynik pracy jest dobrej jakości i potencjalnie gotowy do wydania. Na przykład w przypadku tworzenia oprogramowania Definition of Done powinna jako absolutne minimum zakładać pełne ukończenie funkcji produktu, która jest zaprojektowana, rozwinięta, zintegrowana, przetestowana i udokumentowana.

Dzięki ambitnej Definition of Done firma może przy każdym Sprincie zdecydować, czy chce dostarczyć to, co zostało wytworzone, klientom wewnętrznym lub zewnętrznym.

Dla jasności: „potencjalnie gotowe do wydania" nie oznacza, że coś faktycznie musi zostać wydane. Jest to bowiem decyzja biznesowa, na którą nieustannie wpływają czynniki takie jak: „Czy mamy wystarczająco dużo funkcji lub czy wnieśliśmy wystarczający wkład w zadowolenie klienta?" albo „Czy nasi klienci zniosą kolejną zmianę, skoro dwa tygodnie temu już im coś dostarczyliśmy?".

„Potencjalnie gotowe do wydania" powinno być raczej postrzegane jako stopień tego, co faktycznie udało się osiągnąć w Sprincie. Oznacza to, że żadne istotne prace (takie jak ważne testy czy integracja itp.) nie pozostały nieukończone i nie muszą być najpierw dokończone, zanim wynik Sprintu mógłby zostać wydany. Definition of Done nie jest wyryta w kamieniu i powinna – tak jak wszystko inne – podlegać regularnej inspekcji i adaptacji. W praktyce wiele zespołów zmienia swoją Definition of Done z biegiem czasu.

Przegląd Sprintu

Na końcu każdego Sprintu odbywają się dwie kolejne aktywności Inspect-and-Adapt. Jedną z nich nazywamy Sprint Review.

Celem tej aktywności jest przegląd i dostosowanie pożądanego produktu. Istotnym elementem jest tutaj wymiana informacji między Scrum Teamem, interesariuszami, sponsorami, klientami i zainteresowanymi członkami innych zespołów. Główny nacisk kładzie się na przegląd właśnie ukończonych funkcjonalności w kontekście całego wysiłku rozwojowego. Każda obecna osoba otrzymuje jasny obraz tego, co się aktualnie dzieje, i ma możliwość wpływania na dalszy rozwój, aby umożliwić najlepsze rozwiązanie dla organizacji.

Udany Review skutkuje przepływem informacji w obu kierunkach. Osoby spoza Scrum Teamu mogą zapoznać się ze stanem produktu i wpływać na kolejne kroki. Jednocześnie członkowie Scrum Teamu mają możliwość lepszego zrozumienia aspektów biznesowych i marketingowych, ponieważ stale otrzymują feedback na temat tego, czy rozwój produktu zmierza w kierunku, który zachwyci klientów i użytkowników. Sprint Review stanowi więc zaplanowaną okazję do przeglądu i dostosowania produktu. Osoby spoza Scrum Teamu mogą przeprowadzać przeglądy funkcjonalności w trakcie Sprintu i przekazywać feedback, co z kolei pomaga Scrum Teamowi osiągnąć jego Sprint Goal.

Retrospektywa Sprintu

Drugą aktywnością Inspect-and-Adapt na końcu Sprintu jest Sprint Retrospektywa, która jest regularnie przeprowadzana po Sprint Review i przed kolejnym Sprint Planningiem. Podczas gdy Sprint Review służy do przeglądu i dostosowania produktu, Sprint Retrospektywa jest okazją do przeglądu i dostosowania procesu. Podczas Sprint Retrospektywy zespół deweloperski, Scrum Master i Product Owner spotykają się, aby omówić, co w praktyce ze Scrumem działa, a co nie. Nacisk kładziony jest na ciągłe doskonalenie procesu, dzięki któremu dobry Scrum Team może stać się świetnym Scrum Teamem. Na końcu Sprint Retrospektywy Scrum Team powinien zidentyfikować sensowną liczbę działań usprawniających, które następnie wdroży w kolejnym Sprincie.

Kiedy Sprint Retrospektywa się zakończy, cały proces zaczyna się od nowa – począwszy od nowego Sprint Planningu, podczas którego określane są najbardziej wartościowe prace, na których zespół powinien się skupić.