Zespół deweloperski

Zespół deweloperski
Polecane artykuły
Product owner Cechy zespołu Estymacja czasu trwania zadań Praca zespołowa Backlog sprintu Backlog produktu Epic Struktura zespołów projektowych Velocity

Zespól deweloperski jest jednym z podmiotów występujących w metodyce Scrum. Jego głównym zadaniem jest implementacja kolejnych przyrostów wspieranego produktu. Podczas prac nad rozwojem projektu, właściciel produktu przedstawia zespołowi Backlog produktu. Na jego podstawie zespół dobiera odpowiednią ilość wymagań, które jest w stanie zaimplementować w ciągu jednego sprintu. Deweloperzy są całkowicie niezależną jednostką co oznacza, że podział otrzymanych zadań, pomiędzy członkami zespołu, jest w całości autonomiczną decyzją zespołu. Pomimo podziału obowiązków, za efekty swojej pracy, zespół odpowiada w całości

TL;DR

Zespół deweloperski w metodyce Scrum jest odpowiedzialny za implementację kolejnych przyrostów produktu. Powinien składać się z 5-9 osób o różnych umiejętnościach. Zespół sam decyduje, jakie zadania zostaną wykonane w ramach sprintu. Praca w zespole jest samoorganizująca się, a wszyscy członkowie są traktowani na równi. W składzie zespołu nie powinno dochodzić do zmian podczas sprintu. Praca w zespole deweloperskim obejmuje planowanie sprintu, sprint review, retrospektywę i codzienne spotkania.

Cechy zespołu deweloperskiego

Zespół deweloperski powinien posiadać następujące cechy:

• w jego składzie znajduje się od pięciu do dziewięciu osób: jest to zakres gwarantujący to, że zespół posiada odpowiednio dużą liczbę osób do wykonania każdego większego zadania w odpowiednio krótkim czasie oraz posiada odpowiednią liczbę ekspertów. Limitacja liczebności zespołu do dziewięciu osób bierze się z tego, iż powyżej tego progu komunikacja i koordynacja zadań w zespole zaczyna być trudna i czasochłonna,

• każdy z członków zespołu posiada inny zestaw umiejętności: dzięki zróżnicowaniu umiejętności w zespole (architekci, programiści, testerzy) pojedyncza jednostka, jaką jest zespół, jest w stanie wykonać każde powierzone jej zadanie bez konieczności interakcji z osobami znajdującymi się poza zespołem. W swojej strukturze zespół deweloperski posiada ekspertów z każdego obszaru wiedzy potrzebnego do wykonania każdego powierzonego zadania, a każdy z członków jest w stanie w dowolnym momencie przejąć odpowiedzialność za zadania innych,
• wszyscy członkowie zespołu są sobie równi: pomimo faktu posiadania różnych umiejętności formalnie członkowie zespołu deweloperskiego mają to samo stanowisko dewelopera i są traktowani na równi. Zespół deweloperski nie posiada lidera.
• nie ma podzespołów: pomimo różnych zadań jakie wykonują członkowie zespołu, nie dzieli się on na mniejsze podzespoły,
• posiada możliwość odrzucenia wykonywania zadań: jeżeli Product owner przydzieli zespołowi naraz za dużo zadań do wykonania w ciągu jednego sprintu i z góry wiadomo, że nie uda się zaimplementować wszystkich wymagań, deweloperzy posiadają możliwość odrzucenia tych zadań i przesunięcia ich do następnej iteracji projektu,
• jest samoorganizujący się: to jakie zadania zostaną wybrane, w jaki sposób zostaną one podzielone oraz kto będzie odpowiadał za wykonanie poszczególnych części zadań jest całkowicie autonomiczną decyzją zespołu i nikt inny nie ma prawa narzucić zespołowi tego podziału. Podczas wyboru zadań zespół powinien przestrzegać hierarchii narzuconej przez Backlog produktu,
• wszyscy członkowie pracują blisko siebie: możliwość przebywania obok siebie podczas dnia pracy zacieśnia więzi w zespole i pomaga w szybkim rozwiązywaniu problemów, które pojawiają się podczas pracy każdego z członków. Dzięki wspólnej pracy łatwiej też być poinformowanym na bieżąco jak wygląda aktualny status pracy innych członków zespołu,
• skład zespołu powinien być niezmienny podczas sprintu: wszystkie zmiany w składzie osobowym podczas sprintu mogą skutkować zachwianiem podziału pracy wewnątrz zespołu, a co za tym idzie niewykonaniem pewnej części powierzonych zespołowi zadań.

Praca w zespole deweloperskim

Charakterystycznym dla zespołu deweloperskiego w metodyce Scrum jest "wciąganie" zadań. Oznacza to, że to nie Product owner "wrzuca" zadania do zespołu tylko deweloperzy sami decydują co będzie zrobione w danej iteracji (sprincie).

Pojedynczy sprint dla zespołu deweloperskiego składa się z:

• Sprint planningu: jest to spotkanie z Product ownerem, podczas którego zespół decyduje jakie zadania, znajdujące się w Backlogu produktu, wykona w danej iteracji,
• Sprint review: jest to spotkanie, na którym zespół podsumowuje swoją pracę z kończącego się sprintu oraz otrzymuje odpowiedź zwrotną na jej temat od Product ownera,
• Retrospektywa: po zakończonym sprincie zespół spotyka się, aby podsumować to, co w mijającym sprincie było pozytywne i negatywne oraz jakie można wyciągnąć z tego wnioski, aby poprawić jakość pracy zespołu w przyszłości,
• Daily scrum meeting: spotkanie odbywające się codziennie o tej samej porze, w tym samym miejscu. Celem tego spotkania jest to żeby każdy członek zespołu poinformował kolegów jaką pracę aktualnie wykonuje oraz co udało mu się już zrobić od ostatniego spotkania.

Bibliografia

• Pfahl D. (2014). Lecture 11: Agile/Lean Methods, s. 5
• Sachdeva S. (2016). Scrum Methodology, "International Journal Of Engineering And Computer Science", nr 5, s. 16797
• Schwaber K. (2013), Scrum Guide, Przewodnik do Scrumie: Reguły gry

Autor: Paweł Ciupek