Deweloperzy, czyli po staremu Development Team 

W odcinku 127 naszego bloga przedstawiamy najbardziej zaangażowaną grupę pracowników w Scrumie, czyli Deweloperów. Warto dodać, że ich sytuacja zmieniła się w 2020 roku. Wcześniej bowiem mówiliśmy o całym Development Team.

Proces Scrum został zaktualizowany wraz z opublikowaniem nowej wersji Scrum Guide w listopadzie 2020. Poniższy wpis uwzględnia zmiany wprowadzone w Podręczniku Scrum.

Deweloperzy, czyli…

Deweloperzy to ludzie, którzy są zaangażowani w dostarczanie jakiejkolwiek części działającego Przyrostu. Bez nich nic się nie zadzieje, to oni „robią robotę”. Jeżeli dotykamy się jakiegokolwiek aspektu wykonywania pracy nad naszym produktem, to jesteśmy Deweloperem, niezależnie od tego, jakie jest nasze stanowisko, funkcja czy rola.

Trzeba podkreślić, że słowo „Deweloper” nie oznacza „programistów”, ale po prostu „osoby pracujące nad produktem”. W tym kontekście angielskie słowo development tłumaczymy jako „rozwój”. To szerokie słowo zawiera w sobie wszystkie czynności wykonywane na elementach Backlogu bieżącego Sprintu.

Tutaj pojawiają się czasami wątpliwości, czy SM lub PO są Deweloperami. Spójrzmy więc na to, czy realizują Cel Sprintu. Bardzo często okaże się, że PO pracuje nad wymaganiami, ale przeznaczonymi na Sprinty kolejne. Można więc śmiało stwierdzić, że w takim przypadku PO nie jest Deweloperem. Refinement przecież nie dotyczy bieżącego Celu Sprintu, nie jest to więc development.

Powyższe wcale nie znaczy, że Deweloperzy zrobili tyle samo i tak samo bez zaplecza w postaci Product Ownera czy Scrum Mastera. Po prostu każda odpowiedzialność w Scrum ma swoje poletko i nie możemy powiedzieć, że któraś z nich jest zbędna. Natomiast pamiętajmy też, że to Deweloperzy odpowiedzialni są za realizowanie wymagań zaplanowanych w aktualnie toczącym się Sprincie.

Deweloperzy czy Development Team?

W Scrum Guide 2020 sekcja dotycząca poszczególnych odpowiedzialności została znacząco uproszczona. Wcześniej mieliśmy do czynienia ze Scrum Team, który zawierał wszystkie pozostałe role – PO, SM oraz Development Team. To powodowało pewne problemy ze zrozumieniem sytuacji w której mamy „zespół w zespole”.

Po nowemu Scrum Team składa się z PO, SM-a i Deweloperów. Jest to sytuacja o wiele prostsza i czystsza. Czy coś to zmieniło? Na pewno wymusiło to aktualizację wielu wpisów na naszym blogu. Różnica jednak nie jest tylko i wyłącznie w nazewnictwie.

Od listopada 2020 to Scrum Team jest tą podstawową i jedyną komórką organizacyjną pracy w Scrum. I to o nim mówimy, że jest samozarządzający się. Deweloperzy są fragmentem więcej całości, chociaż nadal z całą stanowczością możemy powiedzieć, że to właśnie oni są odpowiedzialni za pracę wytwórczą. Nie sposób się z tym stwierdzeniem nie zgodzić i w tym kontekście nic się w roku 2020 nie zmieniło.

Cechy Deweloperów

Kiedyś mówiliśmy, że podstawowymi cechami zespołu są międzyfunkcjonalność (inaczej krossfunkcjonalność) oraz samoorganizacja. Od ostatnich zmian mówimy o krossfunkcjonalności i samozarządzaniu, ale w kontekście całego Scrum Team. Trudno, żeby było inaczej skoro nie mamy już czegoś takiego jak „Development Team”. Jest Zespół Scrumowy.

Wymieniając najważniejsze odpowiedzialności Deweloperów zaczęlibyśmy od tworzenia planu na Sprint (Planowanie Sprintu) oraz tworzenia i zarządzania Backlogiem Sprintu. Ponadto, Deweloperzy odpowiedzialni są za bieżące aktualizowanie swojego planu mającego na celu osiągnięcie Celu Sprintu. Robią to co najmniej na Daily Scrum.

Deweloperzy tworzą grupę, która sama siebie trzyma w ryzach i zapewnia profesjonalizm oraz wysoką jakość, między innymi z wykorzystaniem Definition of Done. To wszystko oczywiście w kontekście ich głównej odpowiedzialności, czyli tworzenia działającego i gotowego produktu. To znaczy, że posiadają zestaw umiejętności pozwalających na zmianę każdego z elementów Backlogu Produktu w działające oprogramowanie. Zapewnienie tego jest kluczowe z punktu widzenia powodzenia projektu. Dzięki temu wiemy, że Deweloperzy będą w stanie zrealizować wszystko, co pojawi się w backlogu.

Jaki jest „Development Team”?

W poprzedniej wersji Scrum Guide’a wspominaliśmy też o samoorganizacji. I chociaż teraz mówimy o samozarządzaniu, to warto przypomnieć też ten stary cytat, bowiem jego przesłanie wcale się nie zdezaktualizowało:

„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 2017

Chodzi tu o możliwość stanowienia Deweloperów o sobie. W szczególności to oni wybierają sposób, w jaki wykonają powierzone mu zadania. Nikt nie powinien ingerować w sposób pracy Deweloperów ani w to, przy użyciu jakich narzędzi zrealizują to, co sobie zaplanowani. Założeniem jest, że posiadamy w szeregach naszego zespołu wszystkich ludzi niezbędnych do zrealizowania każdego elementu backlogu. Pozwólmy więc im zrealizować wymagania (a nie zadania) zgodnie z potrzebami zgłoszonymi przez klienta (interesariusza) i zaufajmy, że zrobią to dobrze.

Ilu Deweloperów potrzebujemy?

Mówiąc o Deweloperach, myślimy o profesjonalistach potrzebnych do zrealizowania naszej pracy. 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 cały Scrum Team (razem z PO i SM) zwykle liczy 10 osób lub mniej. Wg. Jeffa Bezosa (twórcy Amazona) tylu, aby najedli się dwiema pizzami. Dla odmiany amerykańscy naukowcy policzyli, że idealny zespół liczy dokładnie 4,6 osoby. Wspominaliśmy o tych rozważaniach w tekście o wielkości zespołu. Najważniejsze jest, aby pracowało się nam dobrze i wydajnie. Na tym polega siła i elastyczność Scruma.

Mieliśmy okazję działać kiedyś w zespole liczącym 23 osoby. W tamtych czasach nie było to zgodne z metodyką, bo stary Scrum Guide ograniczał liczbę Deweloperów do maksimum dziewięciu (a minimum trzech). Nowy Scrum Guide nie zawiera twardych ograniczeń. I słusznie, bo nawet w tej sytuacji udało się wypracować techniki pozwalające na osiągnięcie stawianych przed nami celów.

Z perspektywy doświadczenia możemy powiedzieć, że zawsze da się pracować inaczej i mniejsze zespoły zwykle są bardziej efektywne. W tamtym momencie sposób ten wydawał się nam, jako zespołowi, najlepszy z możliwych. Nowy Scrum Guide daje nam czystą furtkę do zespołów większych niż „stare” 3-9 znane z poprzedniej wersji podręcznika. Warto jednak wiedzieć, jakie są wyzwania stojące przed większymi zespołami.

Zespołów… kilka

Sprawa z Deweloperami jest prosta, kiedy osób rozwijających dany produkt jest mało i możemy ich wszystkich zorganizować w jeden Scrum Team.  Zabawa zaczyna się w sytuacji, kiedy liczba zespołów rośnie. Konieczność dostosowania liczności zespołów do wielkości projektu nazywamy skalowaniem. Czysty Scrum nam w tym nie pomoże, ale to nie znaczy, że powinniśmy uciekać od tego tematu.

Zalecenia scrumowe są bardzo proste – jeżeli mamy jeden produkt, to mamy też jeden Backlog Produktu. Jeden Backlog Produktu, to jeden Product Owner. I z tym zamysłem możemy tworzyć dodatkowe zespoły, gdzie ten sam PO i ten sam Backlog Produktu są podstawą do prac w kilku różnych Scrum Teamach (patrz: „Co stanowi zespół?„). Jedyne, o co warto zadbać w tej sytuacji, to rozłączność poszczególnych Deweloperów.

Scrum Guide nie mówi nam, że Deweloperzy muszą być oddelegowani do zespołów na 100%, ale praktyka pokazuje, że jest to najlepsze rozwiązanie. Jeżeli już mamy kilka różnych zespołów, nie mieszajmy ich składami. 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 pod tytułem Skalowanie Scrum.

Jak zorganizować pracę?

Organizację pracy najlepiej powierzyć samym zespołom, pamiętając o tym, że Scrum mówi, że wszyscy Deweloperzy uczestniczą we wszystkich wydarzeniach Scrum. Zespoły same wiedzą, czego potrzebują aby w najwłaściwszy sposób przekuć wymagania na działające, wysokiej jakości produkty.

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). Mamy 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 nasz przepis na udany zespół? 5-6 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.