Zespół Deweloperski

Kilka słów o Zespole Deweloperskim w Scrumie

Zespół Deweloperski stanowi – obok roli Product Ownera oraz Scrum Mastera – główny trzon Zespołu Scrumowego. Co ważne, mówiąc o nim “deweloperski”, mam tu na myśli wszystkie role, które są konieczne, aby zespół na koniec Sprintu mógł pokazać działający kawałek produktu. Innymi słowy, nieważne czy jesteś programistą, testerem czy analitykiem biznesowym – w Scrumie każdą osobę, niezależnie od roli, nazywamy Deweloperem.

Takie nazewnictwo wzmacnia fakt, iż każda osoba ma wkład w rozwój produktu oraz zmniejsza antagonizmy, które potrafią zrodzić się pomiędzy rolami. Zestawienie wielu różnych ról w jednym miejscu może być nowością dla kogoś, kto pracował w organizacji o strukturze silosowej (pracownicy zorganizowani są wokół konkretnych działów – np. Dział Testów, Dział Analizy Biznesowej itd.), natomiast jest naturalnym i preferowanym sposobem komponowania zespołów w środowiskach zwinnych.

Nie dość, że osoby z różnymi kompetencjami tworzą jeden zespół, to na dodatek zespół taki powinien charakteryzować się zdolnością do samoorganizacji. W odróżnieniu od klasycznie prowadzonych zespołów (tzn. istnieje ktoś, kto mówi zespołowi jak powinien pracować), zespoły w Scrumie uczą się, jak samodzielnie podejmować decyzje, zarządzać i organizować swoją pracę. W praktyce oznacza to, że zespół sam odpowiada na pytanie “jak to zrobić”, otrzymując od Product Ownera wyłącznie informację mówiącą o tym, co ten chciałby uzyskać na koniec Sprintu.



Poniżej kilka przykładów, jak może wyglądać samoorganizacja w Zespole Deweloperskim:

  • zespół sam przeprowadza Daily Scrum – nie jest konieczna moderacja Scrum Mastera, zdarzenie może przybierać różną formę w zależności od potrzeb zespołu, nikt nie musi przypominać zespołowi o tym zdarzeniu,
  • podczas Planowania Sprintu nikt nie przypisuje zadań konkretnym osobom w zespole – Zespół Deweloperski dokonuje tego we własnym zakresie, biorąc pod uwagę swoje aktualne możliwości,
  • zespół samodzielnie pielęgnuje Product Backlog, rozumie dlaczego warto poświęcić czas na ten proces, w zależności od kondycji Product Backlogu zmniejsza lub zwiększa ilość potrzebnych sesji per Sprint.

Warto zaznaczyć, iż samoorganizacja nie oznacza, że zespół funkcjonuje w próżni i nie dotyczą go żadne ograniczenia. Oznacza to raczej, że w obrębie określonych przez organizację ram, zespoły mogą podejmować pewne decyzje samodzielnie, nie naruszając przyjętych granic. Dla przykładu, firma może określić, że błędy produkcyjne muszą zostać obsłużone w czasie nie dłuższym niż 12h od zgłoszenia. Wybór sposobu, w jakim zespół podchodzi do rozwiązywania błędów (np. “jedna osoba od obsługi błędów ustalana na cały Sprint”, “codzienna rotacja” czy “osoba, która właśnie zakończyła zadanie ze Sprintu, rozwiązuje błąd o najwyższym priorytecie”) pozostaje po stronie zespołu. Kilka inspiracji związanych ze wzmacnianiem samoorganizacji zespołów, m.in. poprzez zwiększanie ich autonomii możecie znaleźć w artykule z przemyśleniami po lekturze “Drive” Dana Pinka.

Drugim istotnym atrybutem Zespołu Deweloperskiego jest jego interdyscyplinarność. Oznacza to, że zespół jest tak skonstruowany, że posiada wszelkie kompetencje potrzebne do wytworzenia działającego rozwiązania. Przykładowy zespół może się składać z kilku programistów, kilku testerów, administratora systemów oraz projektanta UX. Nie oznacza to jednak – wbrew powszechnie panującemu mitowi – że np. tester musi umieć programować, a projektant UX pisać testy automatyczne. Jeżeli zespół posiada wszystkie wymagane kompetencje, może niezależnie i bez zbędnych przestojów produkować funkcjonalności. Posiadanie wszystkich niezbędnych ról w zespole automatycznie zmniejsza też ilość zależności zewnętrznych, które niekorzystnie wpływają na przewidywalność zespołu.

Pomimo, iż chcemy mieć w zespole wszystkie potrzebne role, rozmiar zespołu w Scrumie nie jest nieograniczony. Scrum Guide określa go jako przedział: od 3 do 9 osób. Logika stojąca za tymi liczbami jest następująca – zespół z mniej niż trzema osobami może cierpieć na brak kompetencji, więcej niż 9 osób powoduje duży narzut komunikacyjny oraz zarządczy. W sieci dostępna jest masa artykułów dotyczących idealnego rozmiaru zespołu, w których autorzy próbują ustalić jedną, konkretną liczbę gwarantującą optymalną pracę. Inną, mniej “poważną” miarą wielkości zespołu jest popularna “Zasada 2 Pizz” Jeff’a Bezos’a, szefa Amazonu, który uważa, że jeśli nie nakarmisz zespołu dwoma pizzami, zespół jest za duży. Niezależnie od wiedzy dostępnej w książkach oraz internecie, sensowne wydaje się empiryczne podejście do ustalania rozmiaru zespołu, w zależności od zastanych okoliczności.

Bez względu na jego rozmiar, zespół jako całość – a nie pojedyncze osoby w zespole – jest odpowiedzialny za wykonaną pracę. Pomimo, iż niepowodzenia mogą mieć wiele źródeł (np. błędy w kodzie, nieszczelne testy, błędna analiza wymagań, błąd w konfiguracji środowiska produkcyjnego, “wrzutki” spoza Sprintu), to Zespół Deweloperski w całości jest odpowiedzialny za końcowy rezultat. Założenie takie wzmacnia zgranie zespołu oraz minimalizuje ryzyko “grania pod siebie” poprzez konkretne, wyspecjalizowane role w zespole.

Warto na koniec wspomnieć także o braku stałych podzespołów w ramach Zespołu Deweloperskiego. Szczególnie w organizacjach, które stosunkowo niedawno rozpoczęły proces transformacji w kierunki zwiększonej zwinności, może pojawić się pokusa tworzenia podzespołów. Przykładowo – może zostać zaproponowana propozycja stworzenia podzespołu programistów oraz podzespołu testerów. Ten pozornie logiczny podział kompetencyjny zwyczajowo źle wpływa na przepustowość oraz przewidywalność procesu deweloperskiego oraz zachęca do ograniczenia odpowiedzialności za efekt pracy Zespołu Scrumowego (np. “ja swój kawałek zrobiłem”). Zwykle tego typu podejście jest próbą zachowania starych przyzwyczajeń lub to po prostu zwykły brak wiedzy, która pozwoliłaby podjąć lepsze decyzje, dotyczące tworzenia i utrzymywania zespołów scrumowych.

Posłuchaj też odcinka #089 podcastu Porządny Agile Odpowiedzialności Zespołu Scrumowego na Refinemencie

Źródło zdjęcia: Bramley Phoenix 2XV v York 3XV 16112013-28.jpg via photopin (license)

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x