Scrum Team czyli zespół do zadań specjalnych

Scrum scrumem, ale robota rzadko kiedy robi się sama. Aby przekuć elementy Backlogu Produktu zaplanowane do realizacji w Sprincie na potencjalnie wdrażalny inkrement musimy mieć zespół – Scrum Team.

 

Co to Scrum Team?

Zespół Scrumowy (ang. Scrum Team) jest samoorganizującym się i kross-funkcjonalnym ciałem dostarczającym produkt iteracyjnie i przyrostowo, tworząc i wykorzystując okazje do częstego zbierania informacji zwrotnych. A w najprostszych możliwych słowach i zgodnie z definicją ze Scrum Guide’a, Scrum Team to po prostu określenie na zbiór trzech ról:

“W skład Zespołu Scrumowego wchodzą: Właściciel Produktu (ang. Product Owner), Zespół Deweloperski (ang. Development Team) oraz Scrum Master.” – Scrum Guide

I tyle. Według Scrum Guide, aby Zespół Scrumowy zaistniał i był w stanie dostarczać potencjalnie wdrażalne Przyrosty oprogramowania muszą zaistnieć w nim 3 wymienione wyżej role. Z praktyki mogę powiedzieć, że jest to liczba całkowicie wystarczająca pod warunkiem, że są to odpowiedni ludzie na odpowiednich miejscach.

Warto w tym miejscu zaznaczyć jedną z najbardziej fundamentalnych rzeczy – Scrum Team i Development Team to nie to samo. Rozróżnienie powyższego, prócz przydatności podczas zdawania egzaminów na certyfikaty pozwoli również rozeznać się, która z grup bierze udział w poszczególnych spotkaniach scrumowych, np. podczas Daily Scrum Meeting.

Scrum Team to Product Owner, Scrum Master oraz właśnie Development Team. Ten ostatni to, według Scrum Guide, grupa od 3 do 9 osób pracujących wspólnie nad fragmentem listy wymagań. Ten ostatni jest podzbiorem tego pierwszego i to właśnie Development Team bierze np. udział w codziennym Scrumie.

 

Kompetencje i cross-funkcjonalność

Aby brać czynny udział w Product Backlog Refinemencie, szacować wymagania i realizować je podczas Sprintu, zespół musi posiadać do tego odpowiednie kompetencje. Scrum Guide pisze o nich w następujący sposób:

“Zespoły międzyfunkcjonalne posiadają wszelkie kompetencje niezbędne do ukończenia pracy, nie będąc zależnymi od osób nienależących do zespołu” – Scrum Guide

Powyższa definicja jest często utożsamiana z koniecznością posiadania kompletnego spektrum kompetencji przez każdego z członków Zespołu Scrumowego. Nic bardziej mylnego. Musimy jedynie zadbać, aby zespół jako całość posiadał wiedzę i umiejętności niezbędne do realizacji Backlogu Sprintu. Oznacza to, że musimy w nim posiadać ludzi, którzy będą w stanie ukończyć realizację wymagania od A do Z.

Natomiast nie znaczy to tego, że w składzie Zespołu Scrumowego są wyłącznie osoby, które znają się na wszystkich dziedzinach tworzonego systemu. Nie ma nic złego w byciu lokalnym ekspertem w ramach Scrum Team. Warto jednak zadbać o redundancję umiejętności, tak aby nie potknąć się o bus factor.

Przykład? Realizując wymaganie z zakresu budowy GUI dla systemu informatycznego będziemy potrzebowali: grafika, analityka, programisty i testera, przy czym nie jest powiedziane, że potrzebujemy konkretnie czterech osób, bo kompetencje często się łączy. Taki skład osobowy naszego zespołu pozwoli nam na skuteczną realizację wymagania.

 

Umocowanie Scrum Team

Niezwykle ważne z punktu widzenia metodyki jest umocowanie Zespołu Scrumowego (ang. empowering). Umocowanie Scrum Team ma umożliwić osobom w nim pracującym (Zespołowi Deweloperskiemu, Scrum Masterowi i Product Ownerowi) na samodzielną pracę.

Oczywiście może zdarzyć się sytuacja, w której Scrum Team nie będzie posiadał wiedzy w zakresie realizowanej funkcjonalności lub będzie potrzebował dodatkowych informacji. Z pomocą przyjdą wtedy osoby występujące w projekcie w roli interesariusza, których zadaniem jest dostarczenie brakujących lub wymagających wyjaśnienia wymagań.

Zespół Scrumowy nie potrzebuje nadzorcy, a tym bardziej osoby, która weryfikowała będzie postęp pracy i porównywała go z założonym na początku projektu wykresem Gantta. Z kolei Zespół Deweloperski, będąc w pełni świadomym ciałem procesu scrumowego, w oparciu o swoją wiedzę i doświadczenie prognozuje co będzie chciał dowieźć na koniec Sprintu.

Zespół Scrumowy powinien być przede wszystkim umocowany do określania priorytetów realizowania Product Backlogu, wyboru kolejności ich realizacji i do samodzielnego wybrania sposobu ich realizacji.

Na koniec każdego Sprintu nie są ważne indywidualne wyniki albo fakt, że ktoś ukończył wszystkie swoje zadania. Miarą sukcesu w tym przypadku będzie zadowolenie klienta na którego rzecz pracujemy.  Dlatego tak ważne jest, aby zespół czuł się odpowiedzialny za całą swoją pracę – od początku do końca. Efekt ten osiągniemy właściwie go namaszczając.

 

Zakresy odpowiedzialności

Każda z ról w ramach Scrum Team ma określony zakres odpowiedzialności. Nie ma w tym nic złego i nic “mało zwinnego”. Zatrudniając osobę na stanowisku Product Ownera czy Scrum Mastera oczekujemy innych kompetencji i umiejętności, niż zatrudniając osobę na stanowisko dewelopera (w rozumieniu członka Development Team).

Nic nie stoi na przeszkodzie, aby programista czy tester pracowali w tej samej iteracji nad przekształcaniem elementów Backlogu Sprintu w działające oprogramowanie i jednocześnie pełnili rolę Scrum Mastera. Scrum Guide nie widzi nawet przeciwwskazań do jednoczesnego pełnienia roli Product Ownera oraz Scrum Mastera. My, ze względu na troskę o zdrowie psychiczne takiej osoby zdecydowanie tego nie polecamy.

Jeśli więc czujesz się na siłach, aby pełnić w ramach Scrum Team różne role i czujesz do tego powołanie, nie zastanawiaj się nad tym długo – po prostu to zrób. Uważaj jednak, aby żadne z Twoich obowiązków na tym nie ucierpiało.

 

Zespół Scrumowy

Zespół, niezależnie czy mówimy o tworzeniu oprogramowania czy np. wyścigach Formuły 1, to grupa ludzi pracująca nad osiągnięciem wspólnego celu. Różnicuje je powód, w jakim powstały i wizja, do której dążą.

W przypadku metodyki zwinnej, jaką jest Scrum, celem zespołu jest iteracyjne dostarczanie kolejnych Przyrostów produktu. Do tego zespół został powołany i to leży w zakresie jego odpowiedzialności. Tylko tyle, lub aż tyle, jak powiedzą niektórzy.

Pisząc ten artykuł celowo nie skupiałem się na żadnej z ról. Tylko wspólna praca wszystkich członków Zespołu Scrumowego zaowocuje sukcesem. Nie ma tutaj znaczenia, czy jesteś Product Ownerem, Scrum Masterem czy członkiem Zespołu Deweloperskiego. Wszyscy macie jeden, wspólny cel i wszyscy gracie do jednej bramki.

Nie ma też znaczenia, jakie stanowisko w ramach zespołu zajmujesz, ponieważ nie istnieje coś takiego jak hierarchia w Scrum. Każdy z nas ma określone zadania do wykonania. Wykonując je najlepiej jak potrafimy, ciągniemy projekt w stronę, której wszyscy oczekujemy – w stronę sukcesu.

 

Więcej o zespołach możecie przeczytać w tekście o idealnej wielkości zespołu.

Łukasz Bręk

14 lat doświadczenia w IT, 7 lat doświadczenia w Scrum, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy, trener Scrum

Click Here to Leave a Comment Below

Krzysztof - 22 listopada 2019

Bardzo klarowny materiał i… nie chciał bym zawracać głowy… ale mamy do zrobienia na studiach grupowy projekt z filozofii 🙂 I postanowiliśmy aby zrobić go w ramach treningu właśnie metodyką Scrumową. Grupa liczy 6 osób i będziemy pracować zdalnie nad projektem. Na tę chwilę udało mamy tablicę na Trello i dorzucamy tematy do Backloga. Na co powinniśmy zwrócić uwagę organizując taki projekt… Może jakieś słowo mentorskie 🙂

Reply
    Łukasz Bręk - 24 listopada 2019

    Cześć Krzysztof,
    Fajny pomysł, trzymam kciuki, żeby udało się zrealizować cel w 100%. Na co zwrócić uwagę? Przede wszystkim położyłbym duży nacisk na elementy Product Backlogu. Ich właściwe opisanie spowoduje, że wszyscy będzie rozumieli w jednakowy sposób co jest do zrobienia. Istotną rzeczą jest i będzie synchronizacja, która jak pewnie przeczytałeś na naszym blogu szczególnie w zespołach rozproszonych jest wyzwaniem. Pracując zgodnie z metodyką powinniście mieć Daily, dodatkowo na bieżąco powinniście mieć możliwość wymiany informacji (ale co to za problem w dzisiejszym, cyfrowym świecie). Zwróciłbym też uwagą na potrzebę (albo jej brak) osoby odpowiedzialnej za stosowanie zasad zgodnie z metodyką – jednym słowem mówiąc Scrum Mastera jak również osoby (jednej) odpowiedzialnej za elementy Backlogu Produktu (również za wizję produktu końcowego).
    Zainteresował mnie Wasz pomysł, dlatego mam propozycję :). Pisz do mnie na lukasz.brek@bialko.eu z każdym problemem, z którym się zetkniesz, a ja w zamian opiszę Waszą pracę w Scrum nad projektem z filozofii kiedy go skończycie. Deal?

    Pozdrawiam
    Ł.

    Reply
Leave a Reply: