Zespół Scrum (ang. Scrum Team) buduje produkt, który zostanie wykorzystany przez klienta przykładowo oprogramowanie lub witrynę. Może to być także aktualizacja oprogramowania. Zespół w Scrum jest „międzyfunkcyjny” – obejmuje całą wiedzę niezbędną dla dostarczenia w każdym Sprincie produktu będącego potencjalnym wynikiem sprintu – jest „samoorganizujący się” oraz posiada bardzo duży stopień autonomii i odpowiedzialności.
Zespół Scrum:
- Jest międzyfunkcyjny, z mniej więcej siedmioma członkami;
- Wybiera cel Sprintu i określa efekty pracy;
- Ma prawo do zrobienia wszystkiego w granicach wytycznych projektu, aby osiągnąć cel Sprintu;
- Sam organizuje siebie i swoją pracę;
- Demonstruje efekty pracy Właścicielowi Produktu.
Mariusz Charpko pisze „zespół scrumowy pracuje tylko z jednym Właścicielem Produktu” [4]. Jedna z ważniejszych rad, jakie kiedykolwiek słyszałem na temat pracy zespołu deweloperów a także zespołu analityków. Im mniej osób definiuje wymagania tym szybciej toczą się prace.
„W Scrumie zespół deweloperski musi wykonać całą niezbędną pracę, aby w każdym sprincie wytworzyć jeden lub kilka pionowych wycinków działającej funkcjonalności produktu. Wśród tych prac może znaleźć się projektowanie, programowanie, integracja i testowanie funkcjonalności. Dlatego też potrzebujemy zespołu posiadającego umiejętności wykonywania wszystkich tych zadań” [1].
Kenneth S. Rubin w „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” pisze, że działania zespołu scrumowego (deweloperskiego) to:
„Wykonanie sprintu
W trakcie wykonania sprintu członkowie zespołu deweloperskiego realizują kreatywną pracę projektowania, budowania, integrowania i testowania elementów rejestru produktu. Wynikiem tej pracy jest potencjalnie nadający się do wdrożenia fragment funkcjonalności. Aby osiągnąć ten cel, zespół organizuje się samodzielnie i wspólnie decyduje, jak zaplanować pracę, zarządzać i wykonać ją, a także jak komunikować swoje postępy Zespół deweloperski poświęca większość swojego czasu na wykonanie sprintu.
Codzienna inspekcja i adaptacja
Od każdego członka zespołu deweloperskiego oczekuje się uczestnictwa w codziennych działaniach scrumowych, podczas których cały zespół dokonuje inspekcji swojego postępu w kierunku celu sprintu i adaptuje plan na następny dzień pracy. Jeżeli ktoś jest nieobecny, zespół może nie dostrzec całościowego obrazu sytuacji i z tego powodu nie dać rady osiągnąć celu sprintu.
Pielęgnacja rejestru produktu
W każdym sprincie należy poświęcić trochę czasu na przygotowania do następnego sprintu. Przeważająca część tego czasu poświęcana jest na pielęgnację rejestru produktu, czyli tworzenie, precyzowanie, nadawanie ocen i ustalanie priorytetów dla elementów rejestru produktu. Zespół deweloperski powinien zarezerwować do 10% swojego dostępnego czasu w każdym sprincie na asystowanie właścicielowi produktu w tych działaniach.
Planowanie sprintu
Zespół deweloperski zaczyna każdy sprint od jego zaplanowania. Pracując wspólnie z właścicielem produktu pod przewodnictwem mistrza młyna, zespół deweloperski ustala cel następnego sprintu. Następnie zespół deweloperski wskazuje podzbiór elementów rejestru produktu o wysokim priorytecie, które należy zbudować, aby osiągnąć założony cel. W przypadku dwutygodniowego sprintu jego zaplanowanie zajmuje mniej więcej pół dnia. Czterotygodniowy sprint może wymagać poświęcenia pełnego dnia na planowanie.
Zwróć uwagę, że planowanie odbywa się w sposób iteracyjny. Zamiast skupiać się na bardzo dużym, niepewnym i zbyt szczegółowym planie na początku wysiłku deweloperskiego, zespół przeprowadza serię mniejszych, pewniejszych i bardziej szczegółowych planowań w samą porę na
początku każdego sprintu.
Inspekcja i adaptacja produktu oraz procesu
Pod koniec każdego sprintu zespół deweloperski bierze udział w dwóch aktywnościach inspekcyjno-adaptacyjnych: przeglądzie sprintu i retrospekcji sprintu. Podczas przeglądu sprintu zespół deweloperski, właściciel produktu, mistrz młyna, interesariusze, sponsorzy, klienci i zainteresowani członkowie innych zespołów przeglądają dopiero co ukończone w bieżącym sprincie cechy i omawiają najlepszą ścieżkę dalszego postępowania.„
Zaleca się by członkowie powinni byli pełnoetatowymi pracownikami, ale mogą istnieć wyjątki (np. administrator baz danych) Członkowie powinni zmieniać się wyłącznie między sprintami. W komunikacji zespołowi może pomóc Slack czy inne narzędzie do szybkiej i sprawnej komunikacji. Ważne jest także to, by zespół deweloperski eskalował w czasie Codziennego Scruma wszystkie napotkane problemy. Jedną z przyczyn niepowodzeń SCRUM jest ukrywanie sytuacji, iż jeden z członków zespołu nie umie poradzić sobie z danym zagadnieniem. Ukrywanie takiej sytuacji, gdy trwa zbyt długo, powoduje dość istotne opóźnienia całego zespołu. Innymi słowy, zespół deweloperski w scrum jest jak muszkieterowie: jeden za wszystkich wszyscy za jednego.
Podstawy Scrum (spis treści)
Scrum – role:
Scrum – produkty:
Scrum – czynności:
- Sprint Planning Meeting – Planowanie Sprintu
- Daily Scrum – Codzienny Scrum
- Sprint Review – Przegląd Sprintu
- Sprint Retrospective – Retrospekcja Sprintu
Więcej wpisów o Scrum znajdziesz pod adresem https://wolski.pro/kategoria/scrum/
- [1] „Scrum. Praktyczny przewodnik po najpopularniejszej metodyce agile” – Kenneth S. Rubin
- [2] „Zarządzanie projektami ze SCRUM. Twórz produkty, które pokochają klienci” – Roman Pichler
- [3] „Zwinne projekty w klasycznej organizacji” – Henning Wolf
- [4] „Scrum. O zwinnym zarządzaniu projektami. Wydanie II rozszerzone” – Mariusz Chrapko