Agile

Scrum Team – role i obowiązki

Kwiecień 10, 2018 1
Podziel się:

Praca w Scrumie to dla osoby związanej z branżą IT chleb powszedni – planowanie, codzienne spotkania, iteracyjne działania w sprintach, itd.Wszystko to wygląda książkowo, gdy o tym opowiadamy. Czasem warto jednak swoją praktykę zestawić w porównaniu z teorią. Wyniki takiego porównania mogą być w przypadku pracy w Scrumie bardzo zróżnicowane.

Zgodnie z definicją Scrum jest frameworkiem, z wykorzystaniem którego możemy rozwiązywać złożone problemy. Jego równoległym założeniem jest produktywne i kreatywne dostarczanie produktów o możliwie najwyższej wartości. Pracując zgodnie z ramami postępowania jakie nakłada na nas Scrum, jesteśmy w stanie ciągle ulepszać nasz produkt, zespół oraz środowisko, w którym się znajdujemy.

Scrum team

Niewątpliwą zaletą Scruma jest jego „bycie na czasie” – cały proces jest dokładnie opisany, a także systematycznie rozwijany, co pozwala nadążać za zmieniającym się w błyskawicznym tempie rynkiem IT. We wspomnianym opisie znajdziemy informacje na temat tego, jak powinna być zorganizowana praca zespołu projektowego.

Scrum jest oparty na empirycznym sposobie kontroli procesu. Co to oznacza? Wiedza pochodzi z posiadanego doświadczenia, a decyzje podejmowane są na podstawie tego, co wiemy. W podejściu empirycznym nie potrafimy dokładnie przewidzieć wyników wykonania pracy w momencie jej podejmowania. Chcemy kontrolować uzyskane wyniki i zarazem utrzymywać wysoką jakość. Poszczególne kroki w procesie nie zawsze są powtarzalne. Aby podtrzymać zasady empirycznego podejścia do kontroli procesu w Scrumie zostały wprowadzone 3 filary: inspekcja, adaptacja i przejrzystość.

Inspekcja

Jej założenie jest proste – w trakcie sprintu sprawdzaj swoją pracę regularnie – pozwoli to odpowiednio wcześnie wykryć ewentualne niepożądane odchylenia. Nie należy jednak czynić tego zbyt często, aby owo sprawdzanie nie stawało na przeszkodzie w realizacji celów sprintu. Inspekcje są najbardziej efektywne wtedy, gdy rzetelnie wykonują je odpowiednio wykwalifikowane do tego osoby.

Adaptacja

Jeśli podczas inspekcji zostaną dostrzeżone czynniki, które w realny sposób przekraczają akceptowalne limity i mogą spowodować brak osiągnięcia założonego celu – należy w odpowiedni sposób dostosować trwający proces. Dostosowanie powinno być wykonane tak szybko jak to możliwe.

Scrum zaleca cztery formalne wydarzenia do inspekcji i adaptacji:

  • Sprint planning
  • Daily scrum
  • Sprint review
  • Sprint retrospective

Przejrzystość

Założeniami tego filaru są jednakowe rozumienie zagadnień przez wszystkie strony oraz jednakowe rozumienie „definicji zakończonej pracy”. Spełnienie obu postulatów pozwoli nam uniknąć nieporozumień i sytuacji, w których zainteresowane strony w procesie będą dochodziły swoich racji na podstawie własnych interpretacji wymagań.

Scrum Team

Scrum Team

Zespół Scrum składa się z Product Ownera, Development Teamu i Scrum Mastera. Zespoły Scrum są niezależne i wielofunkcyjne. Samoorganizujące się zespoły wybierają, w jaki sposób najlepiej wykonać swoją pracę – nie są przy tym kierowane przez osoby spoza zespołu. Wielofunkcyjność oznacza, że przez członków zespołu są posiadane wszystkie kompetencje potrzebne do wykonania pracy – bez uzależnienia od innych osób, które nie są częścią zespołu. Zastosowany w Scrum model zespołu ma na celu optymalizację elastyczności, kreatywności i produktywności.

Product Owner

Product Owner (właściciel produktu) jest odpowiedzialny za maksymalizację wartości produktu będącego efektem pracy zespołu deweloperskiego. Sposób osiągnięcia tego celu może różnic się dla poszczególnych organizacji, zespołów scrumowych oraz jednostek.

Jest to rola jednoosobowa. Może reprezentować zdanie wielu osób w rejestrze produktu (product backlog), jednak jakakolwiek zmiana (np. priorytetu) elementów rejestru produktu musi być zaakceptowana przez Product Ownera (w rezultacie Product Owner jest rozliczany ze swojej pracy jako pojedyncza jednostka).

Aby Product Owner pracował efektywnie jego decyzje muszą być respektowane wewnątrz organizacji, dla której pracuje. Decyzje te są widoczne w zawartości oraz kolejności elementów product backlogu.

Rejestr prowadzony przez właściciela produktu jest jedynym źródłem wymagań dla zespołu developerskiego. W zarządzaniu rejestrem produktu są zawarte:

  • Jasno sprecyzowane elementy rejestru produktu
  • Uporządkowanie elementów z rejestru produktu, by w jak najlepszy sposób osiągać potencjalne cele wyznaczane dla zespołu deweloperskiego
  • Optymalizację wartości pracy wykonywanej przez zespół deweloperski

Ponadto product backlog powinien pokazywać faktyczną informację na temat aktualnych prac Development Teamu (oraz ich stanu). Właściciel produktu powinien dbać o to, by elementy zawarte w rejestrze produktu były zdefiniowane w sposób przejrzysty, ułatwiający pełne zrozumienie ich treści przez zespół developerski.

Development Team

Zespół developerski składa się z profesjonalistów realizujących zadania z zakresu sprintu. Jego celem jest dostarczenie potencjalnie gotowego do wydania przyrostu skończonego produktu na koniec każdego ze sprintów. Tylko członkowie Development Teamu biorą udział w tworzeniu nowej wersji produktu (zwanej także przyrostem od angielskiego słowa increment).

Członkowie zespołów deweloperskich są dobierani przez organizację, dla której pracują. Wyselekcjonowane grupy specjalistów dostają od swych organizacji zielone światło do zarządzania swoją pracą we własnym zakresie.

Uzyskana w takim modelu pracy „synergia” ma w założeniu optymalizować ogólną efektywność i wydajność zespołu developerskiego.

Zespół developerski jest odpowiedzialny za wytworzenie ukończonego, potencjalnie gotowego do wydania produktu na zakończenie każdego sprintu. Podczas planowania prac zespół sam decyduje o ilości elementów możliwych do realizacji w danym sprincie oraz o planie na wykonanie wyselekcjonowanych zadań.

Niezależnie od kompetencji posiadanych przez poszczególnych członków Development Teamu nie powinno być w nim widocznych wewnętrznych podziałów (wynikłych np. ze stanowiska czy też innych czynników). Podczas przeglądu prac zespół jest rozliczany jako całość bez wyszczególniania dokonań pojedynczych jednostek.

Zgodnie z założeniami Scruma rozmiar zespołu developerskiego powinien się zamknąć w przedziale od 3 do 9 osób. Zbyt duże zespoły wymagają zbyt dużej koordynacji i generują zbyt dużą złożoność dla całego procesu organizacji pracy. Zbyt małe zespoły powodują obniżenie wewnętrznych interakcji między członkami oraz są narażone na potencjalne luki w umiejętnościach niezbędnych do osiągnięcia celu sprintu.

Scrum Master

Scrum Master jest odpowiedzialny za wspieranie członków Scrum Teamu w odpowiedniej implementacji Scruma (zgodnie z definicją w Scrum Guide). Scrum Master pomaga członkom zespołu scrumowego zrozumieć teorię i praktykę Scruma uwzględniając jego zasady i wartości.

Scrum Master dba o prawidłowy przebieg i zrozumienie procesu wytwórczego zgodnie z ramami postępowania nakreślonymi przez Scrum. Jest tzw. servant-leaderem dla członków zespołu – służy im wiedzą i umiejętnościami z zakresu Scruma, jednocześnie będąc liderem w kwestii przestrzegania i stosowania jego zasad oraz wartości. Ponadto Scrum Master dba o to, aby osoby spoza Scrum Teamu nie wpływały w żaden sposób na pracę wykonywaną przez zespół (w szczególności taką, która może mieć wpływ na wydajność poszczególnych członków zespołu i w rezultacie doprowadzić do narażenia osiągnięcia celu sprintu).

Obowiązki Scrum Mastera wobec Development Teamu:

  • Dzielenie się wiedzą w zakresie jego samoorganizacji oraz wielofunkcyjności
  • Usuwanie przeszkód
  • Ułatwienie przeprowadzania wydarzeń scrumowych, by ich egzekucja nie wpływała na marnowanie czasu oraz ogólnie pojętą wydajność zespołu
  • Udzielanie rad w kwestiach współpracy środowiska okołoprojektowego z zespołem

Obowiązki Scrum Mastera wobec Product Ownera:

  • Pomoc w zarządzaniu rejestrem produktu (np. przez wynajdywanie i sugerowanie efektywnych technik zarządzania)
  • Wyjaśnianie potrzeby jasnego i przejrzystego product backlogu
  • Dbanie o jednolite rozumienie zagadnień przez wszystkie strony procesu wytwórczego
  • Ułatwienie przeprowadzania wydarzeń scrumowych by ich egzekucja nie wpływała na marnowanie czasu oraz ogólnie pojętą wydajność zespołu

Obowiązki Scrum Mastera wobec organizacji:

  • Pomoc dla organizacji w kwestiach jej adaptacji do Scruma
  • Planowanie sposobu implementacji Scruma w organizacji
  • Zrozumienie i zarządzanie Scrumem oraz empirycznym procesem rozwoju produktu
  • Zwiększanie produktywności Scrum Teamu
  • Współpraca z innymi Scrum Masterami

Scrum w swoich założeniach jest lekki i łatwy do zrozumienia. Jego prawidłowa implementacja jest jednak bardzo trudna do wykonania. Czy po zapoznaniu się z powyższymi informacjami możecie nadal z całą pewnością powiedzieć, że na co dzień pracujecie w jedynym i prawdziwym Scrumie?

4.2 / 5
Kategorie: Agile
Mirosław Cis
Autor: Mirosław Cis
.NET developer w Sii Polska. Coraz szerzej rozwijający się w kierunkach związanych ze Scrumem oraz udoskonalaniem jego implementacji. Po godzinach pasjonat sportu, zwłaszcza piłki nożnej.

Imię i nazwisko (wymagane)

Adres email (wymagane)

Temat

Treść wiadomości

komentarze(1)

avatar'
szkolenia integracyjne
28 lutego 2019 Odpowiedz

Chciałabym osobiście spotkać autora i podziękować mu za tak ciekawy interesujący wpis. 3-maj się kimkolwiek i gdziekolwiek jesteś!

http://www.ideainventor.pl

Zostaw komentarz