.st0{fill:#FFFFFF;}

Deweloperzy, czyli po staremu Development Team 

 26 lutego, 2019

Tomasz Dzierżek

Deweloper w Scrum to źródło nieporozumień. Tym bardziej ma to miejsce na polskim rynku, gdzie bardzo często bywa utożsamiany z programistą. Tak jednak nie jest!

Ten tekst przeszedł wiele aktualizacji związanych ze zmianami w Scrum Guide w listopadzie 2020. Jego stan odzwierciedla aktualne rozumienie roli Deweloperów w tym dokumencie.

 

Kim jest Deweloper w Scrum?

Deweloper to każda osoba dewelopująca (rozwijająca) Produkt. Są to ludzie, którzy fizycznie wykonują pracę w Sprincie po to, żeby stworzyć kolejny Przyrost. Każdy, kto brudzi sobie ręce, czyli ma jakieś zadania do realizacji w danym Sprincie jest określany mianem Dewelopera.

Jeżeli scrumowo wykańczamy dom bądź remontujemy mieszkanie, to Deweloperami będą murarze, tynkarze, elektrycy, glazurnicy i tak dalej. W przypadku tworzenia oprogramowania Deweloperami będą programiści, architekci, testerzy, analitycy UI/UX designerzy, graficy i tak dalej, i tak dalej…

Trzeba podkreślić że jest to scrumowe rozumienie odpowiedzialności Dewelopera. Zawsze, kiedy mówimy o Deweloperach w kontekście Scruma, pamiętajmy, że nie znaczy to tylko i wyłącznie „programiści” (patrz też: zwinny deweloper). To każda osoba w naszym Scrum Teamie, która rozwija produkt i przykłada rękę do tego, żeby w bieżącym Sprincie powstał wartościowy Przyrost.

 

Deweloperzy czy Development Team?

Przed 2020 rokiem grupa osób realizująca prace nazywała się „Development Team”. W tamtych odległych czasach, Scrum Team składał się z jednego Product Ownera, jednego Scrum Mastera i jednego Development Teamu. Ten ostatni z kolei miał liczyć od 3 do 9 osób. Powodowało to pewne problemy w rozumieniu Scruma – jeden zespół (Scrum Team) składał się z drugiego zespołu czy też podzespołu (Development Team).

Po zmianach w Scrum Guide z 2020 roku mówimy tylko i wyłącznie o Product Ownerez, Scrum Masterze i Deweloperach. Przy okazji tej zmiany wyparowało także ograniczenie mówiące o limicie 3 do 9 osób w Development Teamie. To jednak nie znaczy, że będziemy budować Scrum Teamy składające się z 20 czy 30 osób.

 

Ilu Deweloperów potrzebujemy?

Zespoły Scrumowe powinny być tak małe, jak się tylko da, ale nie mniejsze. Oznacza to, że w większości przypadków lepiej jest mieć dwa sześcioosobowe zespoły, niż jeden dziesięcioosobowy Scrum Team. W tej matematyce oczywiście zakładam, że odpowiedzialności SM i PO byłyby współdzielone przez te same osoby w dwóch mniejszych zespołach.

Jeden z twórców Scruma od zawsze od samego początku mówił, że zespoły w których Development Team (bo tak to się wtedy nazywało) liczył siedem osób, jak najszybciej rozbijał na dwa mniejsze. Spotkamy się także z podejściem mówiącym o tym, że zespół powinien dać się wykarmić dwoma pizzami (Jeff Bezos, Amazon). Z kolei amerykańscy naukowcy policzyli, że idealny zespół liczy niecałe 5 osób (dokładniej 4,6). Scrum Guide wspomina, że Scrum Teamy „typowo” liczą do 10 osób, wliczając w to PO i SM.

Z mojego doświadczenia gorąco mogę polecić pracę w pięcio-sześcioosobowych zespołach, do których powinniśmy doliczyć jeszcze Product Ownera i Scrum Mastera. Więcej rozważań na ten temat znajdziecie w moim tekście o idealnej wielkości zespołu.

Wiele osób powie że w dzisiejszych czasach bardzo trudno jest zbudować kross-funkcjonalny zespół, który będzie potrafił wykonać pracę od początku do końca i dostarczyć jakąś wartość. Ludzie mają coraz węższe specjalizacje i znalezienie grupki pięciu-sześciu osób, która potrafi wytworzyć jakieś rozwiązanie informatyczne jest nie lada wyzwaniem.

Tu z pomocą przyjdą nam takie pomysły jak Feature Teamy, ale przede wszystkim dzielenie wymagań na mniejsze, tak aby mała grupa osób była w stanie zrealizować je end to end. Co więcej, dzielenie zespołów w sposób biznesowy ma dużo innych zalet. Doprowadzamy wtedy do sytuacji, w której nikt nie musi zajmować się jedną wielką kobyłą, ale mamy do czynienia z drobnymi wymaganiami i mniejsza liczbą zależności.

 

Cechy Deweloperów

Jeżeli mówimy o Deweloperach, to przede wszystkim powinni oni być samoorganizujący się i kross-funkcjonalni. Ta druga cecha mówi o tym, że wszyscy Deweloperzy wzięci razem powinni potrafić zrealizować stawiane przed nimi wymagania od początku do końca. Nie znaczy to oczywiście, że każdy w zespole powinien zrobić wszystko. Natomiast jak najbardziej znaczy to, że każdy powinien wspierać innych w taki sposób, w jaki potrafi.

Tu dochodzimy do „obrzydliwych” dla niektórych sugestii, że programiści powinni wesprzeć testerów czy analityków w sytuacji, w której wymaga tego potrzeba chwili. Jak najbardziej się z tym zgadzam! I nie jest to nic dziwnego, bo w każdym dobrze zgranym zespole zależy nam przede wszystkim na osiągnięciu celu, a nie na robieniu tylko i wyłącznie „swojego kawałka pracy”.

Ważne, żeby ten podział pracy i sposób organizacji naszych procesów wychodził z od samego zespołu (samoorganizacja). Agile mindset mówi nam, że to oni najlepiej wiedzą jak przebiega ich własna praca i gdzie są potencjalne problemy i szanse na pomoc. Świetnie mówił o tym „stary” Scrum Guide z 2017 roku:

„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

Zaufajmy Deweloperom, że najlepiej wiedzą jak zrealizować wymagania. Dajmy im wsparcie, środowisko i narzędzia do tego, żeby rozwinęli tę swoją kross-funkcjonalność i samoorganizację. Tu warto też dodać, że wszyscy w zespole powinni być zmotywowanymi profesjonalistami posiadającymi odpowiednie kompetencje twarde, a jednocześnie osobami, które potrafią i lubią pracować zespołowo. W Scrumie nie ma za bardzo miejsca na indywidualności.

 

Czy Scrum Master i Product Owner są Deweloperami?

Bardzo częstym pytaniem, szczególnie wśród osób dopiero poznających Scruma, jest pytanie o Product Ownera czy Scrum Mastera. Czy oni też są Deweloperami?

Na takie pytanie zwykle odpowiadam pytaniem: „Czy przykładają się oni jakoś do powstawania Przyrostu?”. Typową odpowiedzią jest, że tak bo przecież POpracuje nad Backlogiem Produktu, a SM nad procesem, w ramach którego go wytwarzamy. Nie o to jednak chodzi w moim odbijaniu piłeczki. Czy PO lub SM ma jakiekolwiek zadania do zrealizowania w bieżącym Sprincie? Czy jeżeli zajrzymy do Backlogu Sprintu, to znajdziemy tam pracę jawnie przypisaną do jednej bądź drugiej odpowiedzialności? Zwykle odpowiedź brzmi „nie”. W takiej sytuacji śmiało możemy stwierdzić, że PO i SM nie są Deweloperami. Co za tym idzie, nie powinni też pojawiać się na Daily.

Zdarzają się jednak sytuacje, w których ktoś jest na przykład „Scrum Masterem na 50%”, a poza tym też jest analitykiem czy testerką. Podobnie rola PO bywa czasami łączona z rolą architekta czy analityka biznesowego. W takich przypadkach mamy do czynienia z lekkim rozdwojeniem jaźni, bo czasami taka osoba będzie występowała jako Deweloper (na przykład na Daily), a czasami będzie realizowała swoją drugą odpowiedzialność.

Jeżeli jednak nasz PO lub SM traktuje swoją odpowiedzialność jako stanowisko i nie robi nic innego poza „scrummasterowaniem” czy „productownerstwem”, to odpowiedź brzmi: „nie, taka osoba nie jest Deweloperem”.

 

Zespołów… kilka

Kilkukrotnie w tym tekście padła sugestia, że duże zespoły powinny być dzielone na mniejsze. Idealnie byłoby, gdyby Deweloperów było zaledwie kilku. I to nawet jeżeli tworzymy skomplikowane produkty czy też zajmujemy się wielkimi i złożonymi systemami. Scrum działa świetnie do dwóch-trzech Scrum Teamów, szczególnie jeżeli mają one wspólnego Product Ownera i jeden Product Backlog.

Takie też rozwiązanie sugeruje Scrum Guide, który mówi, że zbyt liczne zespoły powinny zostać podzielone na mniejsze, z dokładnie tym samym PO i z jednym wspólnym Product Backlogiem. Oczywiście, w tej sytuacji mamy osobne Backlogi Sprintów, Sprinty i Wydarzenia Scrum. Warto tu jednak sięgnąć po lekcje chociażby z metodyki LeSS, która sugeruje wspólne Sprint Review i wspólną pierwszą część Planowania. Tu jednak wkraczamy w tematykę Skalowania Scruma, która jest o wiele bardziej skomplikowana niż mogłaby się wydawać na pierwszy rzut oka. Bo dwa-trzy Scrum Teamy nie wystarczą przecież do wspomnianych skomplikowanych produktów czy wielkich i złożonych systemów.

W tym temacie jak najbardziej polecam nasze warsztaty dotyczące skalowania, na których przedstawiamy sposoby na konstruowanie zespołów, a także omawiamy najpopularniejsze metodyki skalowania. Jesteśmy także dostępni jako konsultanci, jeżeli chcielibyście przeprowadzić takie skalowanie bądź transformację w waszej firmie bądź organizacji. Polecamy się!

Tomasz Dzierżek


18 lat doświadczenia w IT, 10 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}