– czyli zwięzły fundament, tego, co powinniśmy o nich wiedzieć
Czym jest artefakt? Gdy zadałam to pytanie w pokoju projektowym, usłyszałam w odpowiedzi “ale to zależy w jakim kontekście”. Słowo artefakt jest homonimem i w zależności od dziedziny ma różne znaczenie. I tak na przykład w świecie gier i fantastyki oznacza “cenny i trudny do pozyskania przedmiot o potężnych mocach”. Natomiast w informatyce jest to “wada będąca skutkiem ubocznym zastosowania poszczególnych algorytmów komputerowego tworzenia lub przetwarzania mediów”. Mamy więc dwa skrajne pojęcia, w jednej z dziedzin oznacza to coś potężnego, magicznego i pozytywnego natomiast w drugiej jest to wada, ubytek, a więc cecha negatywna. Czym są więc artefakty Scruma? Czymś pozytywnym czy negatywnym? Czymś bez czego proces nie może istnieć? Zgodnie z ogólną definicją, artefakt (łac. arte factum “sztucznie wykonane“) to zdarzenie, przedmiot będący wytworem ludzkim, a więc widoczna i namacalna rzecz.
Artefakty Scruma reprezentują pracę lub wartość niezbędną do utrzymania transparentności oraz umożliwiają dokonywanie inspekcji i adaptacji. Ken Schwaber i Jeff Sutherland spisali je w taki sposób, żeby zmaksymalizować dostępność i czytelność kluczowych informacji wśród zainteresowanych tak aby rozumieli dany element artefaktu tak samo. Artefakt nie jest magicznym przedmiotem, ale czymś bez czego proces Scrumowy nie może istnieć. Czym dokładniej są artefakty Scruma? O tym poniżej.
Backlog Produktu
Backlog Produktu to uporządkowana lista wszystkiego co powinno zostać wdrożone do produktu. Jest to jednocześnie jedyne miejsce, w którym powinny być trzymane wszystkie wymagania dotyczące zmian czy też usprawnień. Istnieje tak długo jak istnieje produkt, jest stale poszerzany o nowe elementy. Jest dynamiczny i jego zawartość zmienia się umożliwiając tworzenie funkcjonalnego produktu gotowego do wydania.
Właściciel Produktu (PO) jest odpowiedzialny za jego kształt, przy czym może sam tworzyć zadania lub zlecić to zadanie Zespołowi Developerskiemu (DT). Jednak to on ostatecznie odpowiada za zawartość, dostępność i priorytetyzację Backlogu Produktu (PB).
W praktyce wygląda to różnie. Czasem PO dostarcza wszystkie wymagania w postaci obszernej dokumentacji (co na to Manifest Agile?) i prosi o jej rozbicie na zadania pozostałych członków Zespołu Scrumowego. Sam PO jedynie wyjaśnia wątpliwości związane z brakami w dokumentacji. Innym razem Właściciel Produktu rozpisuje zespołowi zadania, które wspólnie omawiają na Refinemencie. Sposobów podejścia do tematu jest wiele, Scrum Guide nie nakazuje jednego. Każdy zespół powinien empirycznie wypracować swoją własną drogę do zrozumienia produktu.
Backlog Sprintu
Backlog Sprintu to lista zadań wybrana z Backlogu Produktu oraz plan na wytworzenie Przyrostu i realizację Celu Sprintu. To forecast, prognoza, a nie sztywna umowa pomiędzy PO i DT. Jego zawartość może się zmieniać w trakcie Sprintu na zasadzie negocjacji pomiędzy wyżej wymienionymi rolami. Przy jego tworzeniu można wykorzystywać różne metryki, m.in. analizować velocity. Podczas wspomnianych negocjacji nadrzędną wartością jest wspomniany wcześniej Cel Sprintu. Jest on niezmienny w trakcie trwania całego Sprintu i wszystkie zmiany w Backlogu Sprintu nie mogą negatywnie wpływać na jego realizację. Warto zawsze pamiętać, że Backlog Sprintu jest własnością Zespołu Developerskiego i tylko on może go modyfikować.
Aby Zespół Developerski mógł stale usprawniać swoją pracę, w Backlogu Sprintu powinno znaleźć się przynajmniej jedno, najważniejsze zadanie z Retrospektywy.
Przyrost
Jest sumą ukończonych elementów Backlogu Produktu podczas Sprintu i wszystkich przyrostów z poprzednich iteracji. Każdy element backlogu musi spełniać Definicję Ukończenia (DoD), która jest ustalana przez Zespół Scrumowy. Przyrost, który powstaje po Sprincie powinien być potencjalnie gotowy do wydania. Oznacza to, że po każdym Sprincie Właściciel Produktu powinien móc udostępnić produkt światu. Za dostarczenie Przyrostu odpowiada cały Zespół Scrumowy. Zespół Developerski jest odpowiedzialny za jego budowanie i jakość. Z kolei Scrum Master pomaga zespołowi w budowaniu tego produktu chociażby poprzez usuwanie przeszkód. Natomiast Właściciel Produktu dostarcza nie tylko poszczególne wymagania ale także ogólną wizję produktu.
Dlaczego “najważniejsze”?
Może zastanawialiście się dlaczego w tytule pojawiło się słowo “najważniejsze” skoro Scrum wyróżnia tylko trzy artefakty. Wzięło się ono z doświadczenia jakiego nabrałam przy próbie zrekrutowania kolejnego Scrum Mastera do organizacji. Jednym z pytań sprawdzających podstawowa wiedzą rekruta było właśnie wymienienie artefaktów. Zdziwiłoby Was jak przeróżne były odpowiedzi. Artefakty Scruma są trzy, żaden nie jest ważniejszy od drugiego, ale wszystkie są zależne od siebie. Cały Zespół powinien dbać o ich przejrzystość, która pomaga w codziennej inspekcji i adaptacji naszej pracy. Dzięki takiej kooperacji sprawiamy, że podwaliny Scruma istnieją nie tylko na papierze, ale i w świecie rzeczywistym. Pamiętajmy, że sami autorzy Scruma piszą o nim: Simple to Understand, Difficult to Master. Nikt nie mówi, że łatwo jest dbać i pielęgnować artefakty, jednak zgodnie z ideą powinniśmy próbować znaleźć najlepsze rozwiązanie dla naszego zespołu i wytwarzanego produktu.
Powyższy tekst to tylko pigułka, kilka dodanych słów do opisu z przewodnika. W kolejnych artykułach postaramy się zagłębić temat i pokazać więcej przykładów nadających sens całości.
Sprawdź nasze ostatnie wpisy:
- Scrum ewolucja I – czyli krótko o historii Scruma
- Trzy S jako narzędzie do oszczędzania i organizacji czasu
- Agile, jak zaczęła się nasza przygoda
