Zespół Deweloperski
Zespół Deweloperski (ang. Development Team) składa się ze specjalistów, odpowiedzialnych za dostarczenie, na koniec każdego Sprintu, ukończonego i gotowego do potencjalnego wydania Przyrostu (ang. Increment) produktu. Przyrost jest akceptowany podczas Przeglądu Sprintu (ang. Sprint Review). To właśnie członkowie Zespołu Deweloperskiego tworzą Przyrost.
Zespół Deweloperski jest samoorganizujący się i interdyscyplinarny. Co to oznacza? Samoorganizujący się oznacza iż jest on uprawniony przez organizację do samodzielnego organizowania własnej pracy i zarządzania nią. Rezultatem takiego postępowania jest synergiczne zwiększenie wydajności i efektywności Zespołu. Interdyscyplinarny (ang. cross-functional) oznacza iż członkowie zespołu mają łącznie wszystkie kompetencje, niezbędne do wytworzenia przyrostu produktu. Nie oznacza to oczywiście iż każdy członek zespołu musi umieć wszystko, ale że Zespół jako całość ma kompetencje wystarczające do dostarczenia przyrostu. W zespole nie wyróżnia się poszczególnych ról (np. programista, tester, projektant itp.). Każdy z członków zespołu jest deweloperem. Cały zespół jest odpowiedzialny za osiągnięcie wspólnego celu.
Jak duży powinien być Zespół Deweloperski? Powinien być on na tyle liczny by móc wykonać założoną pracę, ale jednocześnie na tyle mały, aby pozostać zwinnym. Mniej niż trzech członków zespołu oznacza mały stopień interakcji i niższą produktywność. Łatwiej też w takim zespole o braki kompetencyjne. Jednocześnie więcej niż dziewięciu członków zespołu to spore nakłady na koordynację pracy. W dużych zespołach złożoność wzrasta na tyle, że stosowanie procesu empirycznego przestaje być użyteczne. Osoby Właściciela Produktu i Scrum Mastera nie wliczają się do tego ograniczenia.
Zespół pracuje nad elementami Rejestru Produktu i musi się ze sobą komunikować. Dlatego niezwykle istotne jest, aby zespół gdy tylko jest to możliwe – pracował w jednej lokalizacji. I mowa tu o wspólnym pokoju, a nie tylko budynku. Dzięki wspólnej przestrzeni łatwiej wymienia się informacje, buduje zaufanie i tożsamość zespołu. Nie oznacza to oczywiście iż nie można tworzyć rozproszonych zespołów, ale należy przyjąć że ich praca – utrudniona przez konieczność stosowania dodatkowych, najczęściej elektronicznych środków komunikacji – może być mniej efektywna.
Publikacja “Scrum w pigułce” opracowana została npdst. “Scrum Guide“.
©2017 Ken Schwaber i Jeff Sutherland. Dokument publikowany jest na licencji Creative Commons Uznanie autorstwa-Na tych
samych warunkach. Uproszczona treść licencji w języku polskim: https://creativecommons.org/licenses/by-sa/4.0/deed.pl, pełne
brzmienie licencji w języku angielskim: https://creativecommons.org/licenses/by-sa/4.0/legalcode. Korzystając z publikacji “Scrum w pigułce” potwierdzasz fakt zapoznania się i wolę przestrzegania treści tej licencji.