Artefakt. Wydarzenie. Rola. W naszej podróży po meandrach Scruma napotykamy czasami na słowa, nad których znaczeniem w ogóle się nie zastanawiamy. Prym wiodą tutaj zagadkowe Artefakty Scrum.
Artefakty Scrum
Słowo „artefakt” dobrze znane jest entuzjastom gier komputerowych i pewnie myśli części z Was powędrowały właśnie w tę stronę. Zejdźmy jednak na ziemię i sięgnijmy po naszego najlepszego przyjaciela, czyli Słownik Języka Polskiego.
„artefakt – coś, co jest dziełem ludzkiego umysłu i ludzkiej pracy w odróżnieniu od wytworów natury” – SJP PWN
W słownikowym znaczeniu tego słowa artefaktem będzie więc wszystko to, co powstało dzięki naszej pracy – czy to fizycznej, czy umysłowej. Jeżeli chodzi o metodykę Scrum, to nie odejdziemy daleko od tej definicji.
Artefakty Scrum to wszystkie namacalne produkty procesu scrumowego. Reprezentują one zarówno fizyczną pracę, jak i wysiłek intelektualny dający zysk w postaci transparentności, zadowolenia klienta czy okazji do inspekcji i adaptacji. Mówiąc krótko – wszystko, co zrobimy i co zostanie uwiecznione, będzie artefaktem.
Szczególnie podkreślaną cechą wszystkich tych produktów naszej pracy jest absolutna przejrzystość. Artefakty Scrum są jawne dla wszystkich uczestników przedsięwzięcia. Nie ma żadnych poziomów dostępu, uprawnień czy kontroli. Każdy może oglądać wszystko, co jest zapisane w obu backlogach, a także w pełni używać przyrostu powstałego w ostatnim Sprincie.
Do artefaktów, zgodnie z Podręcznikiem Scrum, zaliczamy Product Backlog, Sprint Backlog i Inkrement. Co ciekawe, w myśl zawartych tam definicji Definition of Done artefaktem nie jest, chociaż mogłoby się wydawać, że jak najbardziej jest to efekt naszej pracy, w dodatku wspierający podejście Inspect and Adapt. Autorzy Scrum Guide są jednak innego zdania.
Wydarzenia
Jeżeli chodzi o wydarzenia, to z definicją jest o wiele prościej. Do języka potocznego przeniknęło już przecież słowo „eventy”. Tak zresztą Wydarzenia Scrum nazywają się w oryginalnym (angielskim) Scrum Guide. Zawierają one zbiór wszystkich „stałych elementów gry”, które wykonujemy regularnie.
Wszystkie Wydarzenia Scrum mają określony maksymalny czas trwania, czyli tak zwany timebox. Znaczy to, że wydarzenie kończy się najpóźniej po upływie zadanego czasu, nawet jeśli jego cele nie zostały osiągnięte. Oczywiście, jeśli skończymy wcześniej, to nie siedzimy i nie patrzymy na zegarek odliczając kolejne sekundy. Po prostu rozchodzimy się w poczuciu dobrze spełnionego obowiązku.
Do zbioru wydarzeń należy aż pięć elementów: Sprint, Sprint Planning, Daily Scrum, Sprint Review i Sprint Retrospective. Każdemu z nich poświęciliśmy osobny tekst na naszym blogu, a także filmy na naszym kanale na YouTube.
Jeżeli chodzi o spójność wspomnianej grupy, to średnio pasuje tutaj sam Sprint. Nie może on przecież ulec skróceniu nawet, jeśli zrealizowaliśmy już wszystkie zadania ze Sprint Backlogu. Sprint obejmuje też sobą wszystkie pozostałe wydarzenia i prace na rzecz powstania przyrostu. To „serce Scruma”, które nadaje mu rytm. Jest więc on trochę inny w swoim charakterze od pozostałych wydarzeń.
Główna cecha scrumowych wydarzeń to ich regularność, która nadaje specyficzny rytm naszej pracy. Daily Scrum odbywa się codziennie, a pozostałe z nich – na początku i na końcu Sprintu. W dodatku każde z nich (znów, poza samym Sprintem) jest też okazją do Inspekcji i Adaptacji. Scrum wymusza na nas przyjrzenie się temu, jak pracujemy i poprawieniu niektórych elementów.
Wydarzenia Scrum wcale nie zajmują dużo czasu. Wspominaliśmy o tym przy okazji filmu „Ile trwają wydarzenia Scrum?„, gdzie zmierzyliśmy się z tą jakże trudną matematyką i wyliczyliśmy, że wszystkie razem zajmują 12% czasu przewidzianego na Sprint. Biorąc pod uwagę, ile one nam dają, nie jest to wysoka cena.
Role w Scrum
Aktorzy grają role w teatrze, a my wcielamy się w różne role w Scrumie. Niektórzy mówią „stanowisko”, ale mi się to słowo nie podoba. „Rola” lepiej brzmi w kontekście współdzielenia niektórych odpowiedzialności. Ponadto, „stanowisko” brzmi zbyt formalnie jak na metodykę agile, jaką jest Scrum.
Trzeba też zauważyć, że Scrum Guide nie zakazuje łączenia ról. Nie ma więc przeciwwskazań, żeby członek Development Teamu był także Scrum Masterem. Z całego serca odradzamy jednak łączenie ról Scrum Mastera i Product Ownera w jednej osobie. To nie tylko nie może się udać, ale będzie też wręcz szkodliwe i destrukcyjne.
We wstępie do Podręcznika Scrum wspomniane jest, że składa się on z ról, wydarzeń, artefaktów i zasad. Próżno jednak szukać rozdziału zatytułowanego „role”. Z jakiegoś powodu nazywa się on „The Scrum Team”.
Wymienione z nazwy role są cztery i znów jedna nam tu nie do końca pasuje. Mowa oczywiście o Scrum Team, na który składają się z trzy pozostałe role Scrum: Product Owner, Development Team i Scrum Master. Próżno też szukać chociażby jednego wystąpienia słowa „developer” w Scrum Guide. Członkowie Development Teamu nazywani są bowiem „profesjonalistami”.
Mamy więc samoorganizujący się i krosfunkcjonalny Scrum Team, odpowiedzialnego za backlog Product Ownera, budujący Inkrement Development Team i sprawującego pieczę nad samą metodyką Scrum Mastera. Ta krótka charakterystyka na pewno nie oddaje niuansów poszczególnych ról. Na szczęście poruszaliśmy już te tematy w poprzednich tekstach na naszej stronie.
Ten krótki wstęp w artefakty Scrum, wydarzenia i role miał na celu zarysowanie struktury frameworku Scrum i zachęcenie Was do jego zgłębiania przez lekturę Scrum Guide i naszego bloga. Tę tematykę poruszamy także bardziej szczegółowo na naszych szkoleniach Scrum. Znajdziecie tam propozycje zarówno dla nowych zespołów, jak i tych doświadczonych, a także nasze usługi wsparcia i konsultacji.
