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.
Cały cykl artykułów na temat metodyki Scrum jest pod adresem: https://www.michalwolski.pl/tag/metodyka-scrum/ . Zapraszam do lektury.

Pisząc ten wpis korzystałem oraz umieściłem cytaty z następujących pozycji:
[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
Szczególnie polecam pozycje 1 i 4, które to moim zdaniem są bardzo dobrą literaturą. Podane linki są linkami afiliacyjnymi.

Zostaw odpowiedź

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Możesz użyć tych HTML tagów i atrybutów: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Close