Każdy zespół, produkt i firma są inne. Dlatego Scrum nie narzuca jednego sposobu pracy nie biorącego pod uwagę ich kontekstu. Jego celem jest zebranie informacji zwrotnej na temat tego jak działamy (sposobu pracy) i co robimy (tworzonego produktu) oraz umożliwienie sprawnego reagowania na te informacje. Scrum to minimalny zbiór praktyk – składa się zaledwie z kilkunastu elementów podzielonych na Odpowiedzialności, Wydarzenia i Narzędzia. Wszystko inne, będące zależne od kontekstu jest traktowane jako dobra praktyka, która może być zastosowana jeżeli adresuje jakiś problem zespołu czy organizacji. Tak ograniczona ilość reguł w Scrumie powoduje, że sprawdza się w różnych obszarach, od tworzenia oprogramowania, przez zarządzanie sprzedażą i marketingiem aż do tworzenia sprzętu.
Odpowiedzialności (Role) w Scrumie
Scrum bazuje na niewielkim zespole nazywanym Zespołem Scrumowym (Scrum Team). W ramach tego zespołu wyróżniamy trzy odpowiedzialności, czyli Deweloperów (Developers), Scrum Mastera i Product Ownera. Jeszcze do niedawna, zamiast „odpowiedzialności” używane było słowo „role”, dlatego możesz je spotkać w materiałach na temat Scruma.
W Zespole Scrumowym nie ma formalnej hierarchi, chociaż oczywiście są w nim ludzie z różnymi doświadczeniami i różnymi umiejętnościami. Ważne jest, żeby posiadał wszystkie kompetencje, wiedzę i uprawnienia potrzebne do dostarczenia produktu, czyli był interdyscyplinarny. W te umiejętności wliczamy również współpracę z interesariuszami, badania, rozwój i utrzymanie produktu, oraz wszystko inne co okaże się potrzebne. Jego członkowie nie mają formalnych ról (poza rolą członka Zespołu Scrumowego). Nie ma więc analityków, testerów czy deweloperów. Są natomiast ludzie z różnymi umiejętnościami i specjalizacjami. Zespół Scrumowy jest też samo-zarządzający, sam ustalając, kto zajmuje się czym.
- Deweloperzy – To ludzie odpowiedzialni za dostarczenie kolejnych przyrostów (inkrementów) działającego produktu. W tym celu muszą ze sobą ściśle współpracować, dlatego często określa się ich mianem Zespołu (lub Zespołem Deweloperskim), co jednak utrudnia rozróżnienie z „Zespołem Scrumowym”. Jeżeli więc czytasz coś na temat Scruma, to zwróć uwagę na te dwie nazwy. Natomiast nie traktuj „Deweloperów” jako programistów, ale raczej jako ludzi potrzebnych do „developowania”, czyli tworzenia produktu. Taki Zespół:
- Musi umieć dostarczyć produkt. Do tego potrzebne mu są umiejętności niezbędne do jego stworzenia (analiza, architektura, testy, czy konkretne języki programowania), jak i znajomość różnych elementów systemu (komponentów). Jeżeli jakiś kompetencji brakuje, to Zespół powinien je zdobyć.
- Jest mały, żeby jego członkowie efektywnie ze sobą współpracowali. Rekomendowana wielkość to do 8 osób. W przypadku większych produktów Scrum zaleca stworzenie kilku interdyscyplinarnych Zespołów z jednym Product Ownerem i jednym Product Backlogiem.
- Sam dobiera narzędzia i procesy potrzebne do tworzenia produktu.
- Sam oszacowuje i mierzy postęp pracy w kierunku osiągnięcia celu.
- Jego członkowie stale współpracują i na bieżąco komunikują się ze sobą, Product Ownerem, Scrum Masterem czy interesariuszami. Dlatego rekomendowane jest, żeby cały Zespół był skolokowany, czyli siedział w jednym pomieszczeniu. Oczywiście po 2020 jest to dużo trudniejsze, ale to nie znaczy, że nie należy kłaść nacisku na efektywność komunikacji i współpracy.
- Rozwiązuje problemy, które są w jego zasięgu. Z pozostałymi zwraca się do Scrum Mastera i Product Ownera.
- Pomaga Product Ownerowi przygotować zakres prac do kolejnych Sprintów, zbierając od niego, interesariuszy, klientów i użytkowników oczekiwania i informację zwrotną.
- Jest w pełni dedykowany. Członkowie są przypisani na 100% do jednego Zespołu, a cały Zespół do jednego Backlogu Produktowego (i Product Ownera).
- Scrum Master (SM) – to coach Scrumowy. Pracuje zarówno z Zespołem, Product Ownerem jak i całą organizacją.
- Jest odpowiedzialny za efektywne wdrożenie i promowanie podejścia Agile.
- Rozumie i tłumaczy zasady Scruma i upewnia się, że są stosowane.
- Wspiera Zespół, Product Ownera i organizację w stosowaniu Scruma.
- Pokazuje im narzędzia pomocne w ich pracy i upewnia się, że efektywnie ze sobą współpracują, oraz że rozumieją cel oraz jak go osiągnąć. Nie narzuca jednak swoich rozwiązań, ale poprzez pytania pomaga Zespołowi odnaleźć jego własne.
- Chroni Zespół przed zewnętrznymi czynnikami i usuwa przeszkody stojące na jego drodze.
- Pomaga Zespołowi szukać sposobów ciągłego doskonalenia przez identyfikację rzeczywistych przyczyn ich problemów i możliwych rozwiązań. W tym celu obserwuje co się dzieje w i zwraca uwagę również na te elementy, które są niewidoczne na pierwszy rzut oka. Często działa jako lustro dzieląc się swoimi obserwacjami.
- Product Owner (PO) – skupia się na maksymalizacji zysku z inwestycji (ROI).
- Tworzy wizję produktu, którą przekształca w uszeregowaną listę oczekiwań (Backlog Produktowy – Product Backlog) z jasno wyznaczonym Celem Produktu (Product Goal).
- Musi mieć bardzo dobrą wiedzę na temat rynku(-ów) i stale go analizować w poszukiwaniu nowych oczekiwań w stosunku do produktu.
- Zbiera informację zwrotną na temat produktu. Na jej podstawie ustala kolejność elementów w Backlogu Produktu.
- PO na bieżąco współpracuje z Zespołem, i interesariuszami.
- Podejmuje decyzje na temat wydań (release), lub o zakończeniu prac nad produktem.
Każdy, kto nie jest członkiem Zespołu Scrumowego (a więc nie pełni żadnej z tych trzech ról) jest w Scrumie po prostu nazywany interesariuszem. W tą grupę wpadają nie tylko użytkownicy i klienci, ale również wszyscy pozostali pracownicy firmy, w tym managerowie.
Wydarzenia Scrum
Wszystkie wydarzenia w Scrumie są ograniczone czasowo. Tym samym Scrum zabezpiecza nas przed ciągnącymi się w nieskończoność dyskusjami na temat architektury, wymagań czy wyborem rozwiązania i zmusza do dostarczenia Przyrostu produktu co najmniej raz na miesiąc.
Wiele organizacji rozpoczyna pracę nad nowymi produktami do Warsztatów Odkrywania Produktów (Product Discovery Workshops) – krótkich (najczęściej kilkugodzinnych, maksymalnie kilkudniowych) sesji, w trakcie których ustalana jest wizja produktu, identyfikowane cele biznesowe, hipotezy do zweryfikowania, czy grupa docelowa klientów. Często mają one też na celu ustalenie minimalnego zakresu najbliższego wydania (release). Nie jest to jednak obowiązkowe spotkanie w Scrumie, w odróżnieniu od pozostałych elementów:
- Sprint – czyli Iteracja. To czas, kiedy Zespół będzie tworzył kolejny przyrost produktu. Sprint zawiera w sobie wszystkie inne wydarzenia i rozpoczyna się od Planowania Sprintu, a kończy Retrospektywą Sprintu. Każda Sprint posiada swój Cel, ustalany przy planowaniu. W trakcie Sprintu Zespół wykonuje wszystkie zadania niezbędne do osiągnięcia tego celu. Zespół też na bieżąco śledzi postęp pracy i w razie potrzeby prosi Product Ownera i Scrum Mastera o pomoc.
Czas trwania Sprintu jest stały i z góry uzgodniony przez Zespół z Product Ownerem, Zwykle jest to od tygodnia do czterech, choć najbardziej popularne są Sprinty dwutygodniowe.
Zobacz też co Zespół robi w trakcie Sprintu. - Planowanie Sprintu (Sprint Planning) – służy do ustalenia Celu i zakresu Sprintu. Spotkanie składa się z dwóch części, które wiele Zespołów Scrumowych wykonuje naraz.
W trakcie pierwszej ustala się „Dlaczego” i „Co” jest do zrobienia. Z Backlogu Produktu wybierane są najważniejsze elementy mające przybliżyć Zespół do osiągnięcia Celu Produktu, które Zespół będzie mógł dostarczyć w trakcie Sprintu. Zespół omawia z Product Ownerem te elementy i w razie potrzeby je uszczegóławia. Określa również Cel Sprintu, na którym się skupi w trakcie iteracji.
Druga część służy natomiast do dyskusji „Jak” zostanie wykonana ta praca. Bardzo często wymaga to ustalenia wstępnego planu prac i konkretnych zadań oraz kolejności ich wykonania.
Zespół powinien skończyć to spotkanie z realnym planem na obecny Sprint. Wszystkie wypracowane elementy (w tym Cel Sprintu, elementy wybrane z Produktu Backlogu, czy zidentyfikowane zadania) są umieszczane w Backlogu Sprintu (Sprint Backlog).
Dla dwutygodniowych iteracji całe spotkanie nie powinno zająć więcej niż cztery godziny. - Codzienny Scrum (Daily Scrum) – To krótkie (do piętnastu minut), codzienne spotkanie Zespołu mające na celu synchronizację pracy i sprawdzenie postępu w kierunku osiągnięcia Celu Sprintu. W śledzeniu postępu prac bardzo pomocne są proste narzędzia, takiej jak Tablica Zadań (Task Board) i Wykres Spalania dla Iteracji (Iteration Burndown Chart). Spotkanie jest przeprowadzane przez Zespół i dla Zespołu. Często polega na przeglądnięciu zadań związanych z elementami Product Backlogu zaplanowanymi na dany Sprint. Wynikiem spotkania są akcje potrzebne do osiągnięcia Celu Sprintu, plan na następne 24 godziny i zaktualizowany Backlog Sprintu.
- Porządkowanie Backlogu Produktu (Backlog Refinement) – W trakcie trwania Sprintu, Product Owner wraz z Zespołem porządkuje Backlog Produktu i uszczegóławia te elementy, które najprawdopodobniej znajdą się w następnej Iteracji, tak aby były gotowe na Planowanie Sprintu. W ramach porządkowania zmienia się również kolejność, oszacowuje, aktualizuje, czy wreszcie usuwa wybrane elementy w Baclogu Produktu.
Większość zespołów poświęca od 5-10% czasu całego Sprintu na tą czynność. Wiele organizuje również jedno lub kilka spotkań w trakcie trwania Sprintu na których omawia elementy Backlogu Produktu. - Przegląd Sprintu (Sprint Review) – pierwsze z dwóch spotkań na zakończenie Sprintu, mające na celu omówienie produktu. Najczęściej wiąże się to z zaprezentowaniem interesariuszom działającej funkcjonalności, zebraniem od nich informacji zwrotnej oraz dyskusją na temat możliwości dalszego rozwoju produktu.
Dla dwutygodniowych Sprintów na Review będziecie potrzebować do dwóch godzin. - Retrospektywa (Sprint Retrospective) – drugie spotkanie kończące Sprint, poświęcone sposobie pracy. Retrospektywy mogą się skupiać na różnych aspektach tej pracy, od procesów, przez komunikację z Product Ownerem, sposób zbierania wymagań czy informacji zwrotnej od klientów, aż do zasad i wartości ważnych dla członków Zespołu Scrumowego. Bardzo często zespół analizuje ostatni Sprint, szukając możliwości usprawnienia swojego sposobu działania. Zdefiniowane akcje znajdą się w następnym Sprincie.
Po dwutygodniowym Sprincie przeznaczcie na Retrospektywę około 1,5 godziny.
Narzędzia (Artefakty) Scrum
Narzędzia zwane Artefaktami reprezentują wynik pracy Zespołu Scrumowego. Tak jak cały Scrum narzędzia są bardzo proste, ale również bardzo efektywne. Każde z nich zawiera również „zobowiązanie” (commitment) pomagające zespołowi się skupić i zapewnić transparencję.
- Przyrost produktu (Increment) – jest tym co Zespół powinien dostarczyć na koniec Sprintu, czyli działającym produktem rozszerzonym o nowe możliwości (funkcjonalności) w stosunku do wersji z poprzedniego Sprintu.
Zobowiązaniem dla Przyrostu jest Definicja Ukończenia (Definition of Done, DoD), czyli lista kryteriów jakościowych, które musi spełniać przyrost produktu, żeby móc powiedzieć, że zespół skończył nad nim pracę. Najczęściej w skład DoD będą wchodziły takie elementy jak napisanie kodu, jego integracja, przetestowanie nowej i starej funkcjonalności, brak błędów itp. - Backlog Produktu (Product Backlog) – to uszeregowana lista potrzeb (wymagań, funkcjonalności, hipotez, czy eksperymentów). Product Owner jest odpowiedzialny za zarządzanie tą listą, natomiast Zespół za dostarczenie jej części w kolejnych Sprintach. Popularnymi elementami Backlogu Produktu są Historyjki Użytkownika (User Stories), ale można też tam umieścić funkcjonalności, Przypadki Użycia (Use Cases), błędy, czy zgłoszenia od klienta, a nawet zwykłą listę rzeczy do zrobienia (TODO list).
Zobowiązaniem dla Backlogu Produktu jest Cel Produktu, czyli co Product Owner chce osiągnąć w najbliższym czasie. Często realizacja takiego celu wymaga kilku Sprintów. - Backlog Sprintu (Sprint Backlog) – to lista elementów wybranych z Backlogu Produktu do Sprintu, czyli na przykład Historyjki, które chcemy zrobić w trakcie Sprintu, oraz plan jak je chcemy zrobić.
Zobowiązaniem dla Backlogu Sprintu jest Cel Sprintu pozwalający się skupić całemu Zespołowi na tym co jest najważniejsze w danej iteracji.
Dobre Praktyki Agile
Ron Jeffries powiedział kiedyś:
„Scrum jest lupą. Pracę wykonuje się pod lupą, a nie lupą”.
Scrum pokazuje problemy i możliwości jakie ma Twój zespół i organizacja i to do Was należy ich zaadresowanie. Praktycznie wszystkie Zespoły Scrumowe sięgają po różne praktyki Agile i Lean, zarówno typowo inżynieryjne (programowanie w parach, ciągła integracja czy TDD) jak i te związane z odkrywaniem produktu (Wizja Produktu, Persony, czy Historyjki Użytkownika), zarządzaniem wizualnym (Tablica Zadań, Wykresy Spalania) lub szacowaniem (Poker Planujący).
