Co to są artefakty Scruma, jaka jest ich definicja?

Czym są artefakty Scruma?

Słownik języka polskiego PWN opisuje artefakt jako „coś, co jest dziełem ludzkiego umysłu i ludzkiej pracy w odróżnieniu od wytworów natury”. Wielki słownik języka polskiego PAN podaje natomiast, iż artefakt to „coś, co powstało w wyniku fizycznej lub umysłowej pracy człowieka”.

Scrum Guide zbieżnie z definicją powszechnie przyjętą w języku polskim opisuje „Artefakty Scruma jako odzwierciedlające pracę lub wartość”. Używając prostszej nomenklatury, artefakty Scruma ukazują rzeczywistą pracę, jaką wykonaliśmy w projekcie, i jaką planujemy wykonać. W poniższym artykule postaram się wyjaśnić, czym tak naprawdę są i po co istnieją artefakty Scruma. Dla lepszego zrozumienia będę posiłkować się cytatami z najnowszej, opublikowanej w 2020 roku wersji Scrum Guide.

Artefakty a Agile, czyli: czym różni się Agile od Scruma?

Na początek jednak rozróżnijmy dwa pojęcia, które pomimo rosnącej popularności zwinnych metod pracy nadal bywają mylone. Uczestnicy szkoleń często zadają mi pytanie – czy potrzebujemy tych wszystkich artefaktów, aby być faktycznie zwinnymi? Pamiętajmy, że Agile jest raczej sposobem myślenia i ogólnym pojęciem określającym zwinne podejścia do wytwarzania oprogramowania. Scrum natomiast jest frameworkiem stworzonym i cały czas doskonalonym, aby ułatwić tworzenie wartości w złożonym świecie.

Jak nazywają się 3 artefakty scrumowe?

Scrum wyróżnia 3 artefakty: Backlog Produktu, Backlog Sprintu oraz Przyrost (Increment). Pomimo iż Cel Produktu, Cel Sprintu oraz Definicja Ukończenia (Definition of Done) są bezpośrednio związane z artefaktami poprzez zapewnienie przejrzystości i skupienia, to same artefaktami Scruma nie są.

Co to jest Backlog Produktu?

Scrum Guide mówi, iż „Product Backlog to ewoluująca, uporządkowana lista tego, co jest konieczne do ulepszenia produktu. To jedyne źródło pracy podejmowanej przez Scrum Team”. Mówiąc prościej, Backlog za pomocą zadań opisuje całą pracę, jaką należy wykonać podczas trwania projektu. Odpowiedzialność za zarządzanie Backlogiem ponosi Product Owner. Może to obejmować między innymi takie czynności jak:

• tworzenie nowych elementów Backlogu – czyli zadań,
• ustalanie priorytetu i porządkowanie elementów Backlogu Produktu – przyjęło się dla lepszej higieny i zrozumienia pracy, iż na górze znajdują się zadania o wyższym priorytecie, a niżej o małym znaczeniu lub te, które wymagają dalszego uszczegółowienia podczas Refinementu,
• zapewnienie dostępności i przejrzystości – czyli sytuacji, w której każdy zainteresowany wie, gdzie znajduje się Backlog oraz co tak naprawdę opisuje.

Product Owner (Właściciel Produktu) zarządzanie Backlogiem Produktu może przekazać lub zlecić innej osobie, lecz ostatecznie to on jest za ten obszar odpowiedzialny. Scrum Guide wskazuje także, co jest niezmiernie ważne, iż Product Ownerem jest jedna osoba, a nie komitet lub grupa osób.

Product Owner w swojej pracy powinien uwzględniać wymagania i oczekiwania interesariuszy i środowiska zewnętrznego, lecz ostatecznie decyzje dotyczące Product Backlogu podejmuje właśnie Product Owner. Dlaczego w codziennej pracy projektowej tak ważne jest podkreślenie tego, iż Product Ownerem jest jedna osoba? Pozwala to unikać rozproszenia odpowiedzialności i wewnętrznych walk o to, który obszar produktu jest ważniejszy.

Doskonalenie, czyli Refinement

Koniecznie wspomnieć muszę także o doskonaleniu, czyli Refinemencie. Potocznie uznaje się go za spotkanie, podczas którego omawia się, dzieli na mniejsze części oraz dookreśla elementy Backlogu Produktu. Jednak zgodnie z definicją jest to proces ciągły, niemający odzwierciedlenia w jednym tylko, konkretnym spotkaniu.

Z Backlogiem Produktu nierozerwalnie związany jest Cel Produktu, który opisuje przyszły stan produktu. Scrum Guide wskazuje, iż „Cel Produktu jest odzwierciedlony w Product Backlogu”. W praktyce jest wskazówką i drogowskazem dla developerów podczas procesu planowania, jak i samej pracy.

Co to jest Backlog Sprintu?

Twórcy Scrum Guide precyzyjnie określili, iż na „Sprint Backlog składają się Cel Sprintu (po co), elementy Product Backlogu wybrane do realizacji w Sprincie (co) oraz wykonalny plan dostarczenia Incrementu (jak).”

Warto dokładnie zrozumieć powyższą definicję. W potocznym i zarazem błędnym rozumieniu Backlog Sprintu określa się podczas sesji planowania na początku każdego Sprintu jako zdefiniowany zakres prac, którego realizacji podejmuje się Zespół Developerski. Tymczasem definicja dokładnie mówi, iż Backlogiem Sprintu są wybrane elementy Backlogu Produktu (co), a także Cel Sprintu (po co) oraz plan dostarczenia (jak).

Mówiąc obrazowo, Backlog Sprintu to swego rodzaju worek, w którym znajdują się zadania oraz plan ich dostarczenia. Za Cel Sprintu natomiast możemy uznać podpis, jaki znajduje się na samym worku.

Pamiętajmy, że Backlog Sprintu nie jest podpisanym krwią developerów cyrografem, ale żywym artefaktem, który wraz z postępem prac podczas trwania Sprintu może ewoluować. Z biegiem czasu i wraz z lepszym zrozumieniem pracy i wymagań, a także z powodu niespodziewanych zależności wewnętrznych i zewnętrznych (urlopów lub zwolnień lekarskich) może okazać się, że Zespół Developerski uaktualni Backlog Sprintu w taki sposób, aby osiągnąć Cel Sprintu. To Zespół Developerski jest odpowiedzialny za przygotowanie i realizację Sprint Backlogu.

Reasumując, ustalony podczas Planningu Cel Sprintu jest zobowiązaniem developerów, lecz pozostawia swobodę oraz elastyczność względem tego, co zespół powinien zrobić, aby niezmienny Cel Sprintu osiągnąć.

Czym jest Przyrost w Scrumie?

Przyrost, czyli Increment, możemy zobrazować jako klocek Lego, dzięki któremu dołożyliśmy kolejną cegiełkę do budowy naszego wymarzonego zamku. Tak samo jak używane przez nas klocki Lego muszą być dopasowane, tak samo Przyrost musi być dopasowany i zweryfikowany, aby w całości był użyteczny, czyli dostarczał wartość dla użytkownika lub klienta.

Podczas jednego Sprintu dostarczony może być więcej niż jeden Przyrost. Mimo iż Sprint Review wspiera podejście empiryczne, to nie można zakładać, iż tylko na spotkaniu poświęconym Review prezentuje się oraz dostarcza Increment. Wypracowany podczas Sprintu Przyrost może być większy niż jeden i może zostać dostarczony przed ukończeniem danego Sprintu. Zupełnie jak z klockami – możemy z wiaderka wybrać jeden duży klocek, ale możemy wziąć do ręki więcej mniejszych i starać się wznieść budowlę z większej liczby elementów.

Definition of Done a Przyrost

Z Przyrostem nierozerwalnie związana jest Definicja Ukończenia, czyli Definiton of Done. Jest to swego rodzaju zbiór warunków, które muszą zostać spełnione, aby uznać, że praca została faktycznie wykonana. Definiton of Done jest standardem, który wpływa na jakość i wartość wykonywanej przez developerów pracy. Jeśli jakiś z elementów Backlogu Sprintu nie spełnia warunków określonych w Definicji Ukończenia – nie może zostać pokazany klientowi i uznany za część Przyrostu.

Nic nie stoi na przeszkodzie, aby developerzy stosowali surowsze warunki niż te określone w Definicji Ukończenia. Dzieje się tak, gdy zespół chce jeszcze bardziej skupić się na dostarczanej wartości. Definiton of Done możemy uznać jako minimalne kryterium, względem którego można „równać w górę, lecz nigdy w dół”.

Definicję Ukończenia możemy uznać za gwarancję jakości dla interesariuszy lub klienta, która zapewnia, iż otrzymany przez nich Increment jest w pełni działający, a także spełnia jakościowe kryteria.

Jak zbudować zespół? Poznaj praktyczne wskazówki

W artykule znajdziecie praktyczne wskazówki, jak tworzyć efektywne, a przede wszystkim zgrane zespoły zwinne w IT.

Przeczytaj artykuł

Podsumowanie

Według Scrum Guide w obręb frameworka Scrum wchodzą: Zespoły Scrumowe (ang. Scrum Teams) oraz związane z nimi role, zdarzenia, artefakty i reguły. Wszystkie te elementy są ważne, a opisane przeze mnie artefakty Scruma pozwalają zadbać o przejrzystość, stwarzają okazję do adaptacji i inspekcji, a zatem sprzyjają umacnianiu filarów Scruma w projekcie.