Development Team

Przeglądając napisane przez nas posty na blogu zauważyłem, że opisując role w Scrum nie opisaliśmy jeszcze wprost jednej. I to chyba tej najważniejszej. Dziś naprawiamy swój błąd! Pozwólcie, że przedstawię odcinek 127 naszego bloga, a w nim najbardziej zaangażowane grupa pracowników o nazwie Development Team.

 

Development Team

Zespół Deweloperski (ang. Development Team) to grupa bardzo mocno zaangażowanych ludzi. Powiedziałbym, że są osoby te są  niezbędne, aby wytworzyć nasz Przyrost. Bez nich nic się nie zadzieje. To właśnie Development Team wybiera elementy Backlogu Produktu, które na spotkaniu o nazwie Planowanie Sprintu prognozują, że dostarczą do końca najbliższego Sprintu.

No nie znaczy, że Development Team zrobiłby tyle samo bez zaplecza w postaci Product Ownera czy Scrum Mastera. Po prostu każda z ról w Scrum ma swój zakres odpowiedzialności i nie możemy powiedzieć, że któraś z nich jest zbędna.

Pomimo tego, z całą stanowczością możemy powiedzieć, że to właśnie ludzie tworzący Zespół Deweloperski są odpowiedzialni za pracę wytwórczą. I nie sposób się z tym stwierdzeniem nie zgodzić.

 

Cechy Zespołu Deweloperskiego

Podstawowymi cechami zespołu deweloperskiego są międzyfunkcjonalność (inaczej kross-funkcjonalność) oraz samoorganizacja. Nie różni się on tym samym od innej scrumowej roli, czyli Scrum Team. Trudno, żeby było inaczej skoro omawiany Development Team jest elementem wspomnianego Zespołu Scrumowego.

O międzyfunkcjonalności pisaliśmy już dużo przy okazji porównania dewelopera w kontekście całego zespołu. Oddajmy głos samemu Podręcznikowi Scrum:

“Zespoły Deweloperskie są międzyfunkcjonalne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu.” – Scrum Guide

Dla przypomnienia, jest to zestaw umiejętności pozwalających na zmianę każdego z elementów Backlogu Produktu w działające oprogramowanie. Zapewnienie powyższego jest kluczowe z punktu widzenia powodzenia projektu. Dzięki temu wiemy, że co pojawi się w backlogu, to zespół będzie w stanie to zrealizować.

Druga cecha charakterystyczną dla Development Teamu jest samoorganizacja.

“Nikt (nawet Scrum Master) nie może mówić Zespołowi Deweloperskiemu, jak przekształcać elementy Backlogu Produktu w Przyrosty gotowej do potencjalnego wydania funkcjonalności.” – Scrum Guide

Termin ten określa możliwość stanowienia Development Team o sobie. W szczególności zaś zespół sam wybiera sposób, w jaki wykona powierzone mu zadanie.

Nikt nie powinien ingerować w sposób pracy Zespołu Deweloperskiego ani w to, przy użyciu jakich narzędzi zrealizuje powierzone mu zadanie. Posiadamy w szeregach zespołu ludzi niezbędnych do zrealizowania każdego elementu backlogu. Pozwólmy im zrealizować wymagania (a nie zadania) zgodnie z potrzebami zgłoszonymi przez klienta (interesariusza).

 

Ilu profesjonalistów potrzebujemy?

Kiedyś mówiło się o nich “deweloperzy”, co było dość mylące. Dziś mówimy o profesjonalistach. W polskich warunkach nazwalibyśmy ich po prostu członkami Zespołu Deweloperskiego. Powinno być ich dokładnie tylu, żeby dostarczyć działający i potencjalnie wdrażalny Inkrement na koniec każdej iteracji.

Liczebność zespołu zależy od punktu widzenia. Według Scrum Guide powinno ich być od 3 do 9. Wg Jeffa Bezosa (twórcy Amazona) tyłu, aby najedli się dwiema pizzami. Wg amerykańskich naukowców – dokładnie 4,6. Wspominaliśmy o tych rozważaniach w tekście o wielkości zespołu. Ważne jest, aby pracowało się nam dobrze i wydajnie. Na tym polega siła Scrum.

Sam pracowałem kiedyś w zespole liczącym 23 osoby. Nie powiem, aby było to zgodne z metodyką, wypracowaliśmy jednak techniki pozwalające na osiągnięcie stawianych przed nami celów. Dostarczaliśmy na czas wysokiej jakości oprogramowanie.

Z perspektywy doświadczenia mogę powiedzieć, że dało się pracować inaczej. W tamtym momencie sposób ten wydawał się nam, jako zespołowi, najlepszy z możliwych.

 

Zespołów… kilka

Wszystko wygląda dobrze, kiedy na naszym projekcie mamy jeden czy dwa Development Teamy. Zabawa zaczyna się w sytuacji, kiedy liczba zespołów rośnie. Konieczność dostosowania liczności zespołów do wielkości projektu nazywamy skalowaniem. Proces ten ma na celu dostosowanie i optymalizację struktury organizacyjnej.

Posiadanie więcej niż dwóch Zespołów Deweloperskich nie wymusza na nas rezygnacji z ich zalecanej liczebności. Nie uciekajmy przed skalowaniem poprzez budowę “przerośniętych” zespołów, składających się z 10 członków i więcej.

Jeśli nie wiemy, jak w sposób efektywny zbudować nasz projekt, zapytajmy o to ekspertów! Tak się składa, że mamy w naszej ofercie szkoleniowej jednodniowy warsztat Skalowanie Scrum.

 

Jak zorganizować pracę?

Organizację pracy najlepiej powierzyć samym zespołom. W taki właśnie sposób powstały najlepsze metodyki i struktury organizacyjne, jak chociażby słynny “Model Spotify”. Zespoły same wiedzą, czego potrzebują aby w najwłaściwszy sposób przekuć wymagania na działające, wysokiej jakości oprogramowanie.

Jako skuteczni managerowie powinniśmy zadbać o to, aby stworzyć zespołom bezpieczne środowisko, w którym możliwe będzie osiągnięcie zakładanych celów (m.in. Celu Sprintu). Mam tu na myśli środowisko, które zapewni narzędzia do pracy, a jednocześnie nie będzie karać za chęć eksperymentowania nawet, jeśli eksperyment zakończy się klęską.

Jaki jest więc przepis na udany zespół? 5 osób, wspólny cel, wzajemne zrozumienie i gotowość do ciężkiej pracy. Odrobina wsparcia “z góry” również się przyda. Reszta przyjdzie sama.

Łukasz Bręk

13 lat doświadczenia w IT, 6 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

Leave a Reply: