Development Team

 

Zespół developerski (ang. Development Team lub krótko Team) - to liczący od 3 do 9 osób zespół osób posiadających wspólnie wszystkie kompetencje niezbędne, aby dostarczać co iterację (Sprint) kompletny, działający, gotowy produkt. Scrum nie narzuca ani nie zaleca żadnej

wewnętrznej struktury tego zespołu. Nie ma więc żadnych zdefiniowanych ról w zespole - wszyscy członkowie zespołu to developerzy (ang. developers), przy czym określenie stosowane jest także w stosunku do członków zespołu nie będących programistami. Innymi słowy jest to interdyscyplinarny, samoorganizujący się zespół.

 

Scrum Master

 

Scrum Master to osoba odpowiedzialna za proces. Scrum Master ma dbać o to, by Scrum był prawidłowo zrozumiany i stosowany zarówno w samym zespole jak i w organizacji. Scrum Master odpowiada także za zespół, jego produktywność i zaangażowanie. Dba o zespół, pomagając
mu w rozwiązywaniu problemów i usuwaniu przeszkód (w metodyce nazywanych impediments) oraz wspomagając jego samoorganizację. Nie jest jednak kierownikiem zespołu ani liderem technicznym, nie może bezpośrednio polecać członkom zespołu wykonania takiej czy innej
pracy, karać ich czy nagradzać ani określać jaką rolę będą pełnić w zespole.
Sposób działania Scrum Mastera jest w metodzie definiowany jako servant leadership, co można przetłumaczyć jako „przywództwo służebne”.

Nie stoi nigdy w świetle jupiterów, wycofuje się, pozwala innym działać, obserwuje sytuację. Czasami o coś zapyta, choć wcale nie po to, by się czegoś samemu dowiedzieć, ale po to, by zapytanym uświadomić, że coś być może im umknęło. Gdy trzeba, wytłumaczy, skąd w Scrumie są takie a nie inne zasady i czemu służą poszczególne elementy tej metody. Często pomaga w prowadzeniu spotkań, choć nie jako moderator – raczej jako facylitator wspierający moderatora. Bardzo rzadko, w sytuacji kryzysowej, coś faktycznie Zespołowi zarekomenduje lub będzie się czegoś od Zespołu domagał.

Wedle Scrum Guide, Scrum Master powinien zapewniać, że Scrum jest rozumiany i stosowany. Wymieniona jest tam lista usług, które Scrum Master świadczy dla Zespołu, Product Ownera i organizacji. Niektóre z tych zadań są bardzo konkretne, na przykład facylitacja zdarzeń Scrumowych czy usuwanie przeszkód, które utrudniają Zespołowi dostarczanie działającego produktu.

Sposób działania Scrum Mastera zależy od organizacji, w której funkcjonuje i od dojrzałości Zespołu. Na początku, gdy Agile i Scrum są nowością dla organizacji, a Zespół dopiero się formuje, Scrum Master może istotnie mieć pełne ręce roboty. Będzie walczył z ograniczającymi Developerów procedurami, organizował sale na spotkania, prezentował w praktyce niezbędne narzędzia i techniki, uczył Scruma (nie tylko Zespół, ale też managerów i wszystkich, którzy tego będą potrzebować).

Cały czas musi jednak pamiętać, że jego rolą nie jest uzależnienie Zespołu od omnipotentnego Scrum Mastera, który jak buldożer spycha wszystko z drogi zespołu zanim jeszcze w ogóle coś stanie się problemem. Chodzi o coś dokładnie odwrotnego.

 

Product Owner

 

Scrum Guide określa misję Product Ownera jako odpowiedzialność za wartość produktu i pracy zespołu developerskiego. Innymi słowy Product Owner odpowiada za to, by produkt był wartościowy a praca zespołu przeznaczona jedynie na rzeczy tę wartość podnoszące. Tak więc to Product Owner decyduje o kształcie produktu, odpowiada za to, czy produkt jest sensowny i dobrze pasujący do wymagań użytkowników/klientów, czy też nie. Product Owner realizuje swoją misję przede wszystkim poprzez zarządzanie backlogiem produktu, a więc wymaganiami oraz pracę z interesariuszami jak i Zespołem Developerskim. Ponieważ w Scrum decydowanie o kolejności odbywa się poprzez backlog, Product Owner jest osobą, która ma ostatnie słowo co do kolejności na backlogu produktu. To jest najważniejsza, niezbywalna niejako część tej roli. Pozostałe działania potocznie z nią wiązane - pisanie wymagań, negocjowanie z interesariuszami czy projektowanie rozwiązań - albo nie są jej częścią albo też mogą być przez Product Ownera delegowane do zespołu lub innych osób.

Product Owner nie musi więc być analitykiem biznesowym, nie musi też koniecznie rozumieć
dogłębnie tajników programowania. Musi natomiast rozumieć produkt i rynek, w którym on operuje, świetnie znać organizację i jej sytuację. Wszystko to jest mu niezbędne, by wiedzieć co jest w danej chwili dla produktu dobre, jakie zmiany w nim są potrzebne - a jakie nie. Zależnie od kontekstu produktu (przedsięwzięcia) rola ta będzie bliższa roli tradycyjnego Project Managera albo Product Managera.

Product Owner odpowiada wreszcie za komunikowanie takich informacji jak plany wydań, spodziewany zakres funkcjonalności w wydaniach itp. Innymi słowy, to Product Owner odpowiada na pytania w rodzaju „kiedy będzie funkcja X?” albo „co będzie w produkcie w następnym wydaniu?”.