Kim jest Scrum Master, właściciel produktu i zespół deweloperski?

Najpopularniejszą i najbardziej efektywną obecnie stosowaną metodyką zwinną jest bezsprzecznie Scrum. W Scrumie istnieją tylko trzy role: właściciel produktu, członek zespołu deweloperskiego i Scrum Master.

Właściciel produktu odpowiada, więc za zakres prac przyjętych do realizacji i czuwa nad jego wdrożeniem. Scrum Master czuwa nad przestrzeganiem zasad prowadzenia prac projektowych zgodnie z zasadami Scruma. Ostatnia z funkcji - członkowie zespołu deweloperskiego - są odpowiedzialni za wykonanie całej pracy związanej z wykonywaniem zakresu zadań w sprincie. Zgodnie z metodyką Scrum, w projekcie prowadzonym w taki sposób nie istnieją role analityka biznesowego, architekta rozwiązania czy testera.

Czy rzeczywiście tak jest?

W rzeczywistości wyeliminowanie tradycyjnego myślenia o podziale ról w zespole jest kluczową częścią przejścia na Scrum. Przywiązanie do korporacyjnych funkcji powoduje powstawianie wąskich gardeł oraz nieefektywności, ponieważ ludzie starają się przeliterować, co jest „moją pracą”, a co nie. Posiadanie ludzi w zespole, którzy nie chcą wykonywać niektórych zadań, jest nieoptymalne.

Ponadto, sposób w jaki tradycyjnie pracowali analitycy biznesowi czy inni specjaliści, jest sprzeczny ze sposobem działania zespołów Scrum. Analitycy biznesowi często ponoszą odpowiedzialność za wywiad z użytkownikiem i zbieranie wymagań. Kompilują je w długie, szczegółowe dokumenty i przekazują programistom. Umieszczenie wielu szczegółów w dokumencie i przekazanie go innym, to niezawodny sposób na zbudowanie niewłaściwej rzeczy.

Czy słuszne jest stosowanie nazw ról członków zespołu projektowych z przestarzałych metodyk kaskadowych przy prowadzeniu projektu w metodykach zwinnych?

Najłatwiej będzie ten temat przedstawić na przykładzie projektu zrealizowanego przez nas dla jednej z firm sektora finansowego. Chociaż był on prowadzony zgodnie z ramami opisanymi w Scurm, role zostały zdefiniowane według standardowego nazewnictwa stosowanego w projektach realizowanych metodykami kaskadowymi. Zatem projekt początkowo realizował zespół złożony z dwóch deweloperów oraz trzech analityków biznesowych. Jego celem była budowa struktury raportowej na potrzeby automatyzacji raportowania regulacyjnego.

Rolę właściciela produktu objął sponsor projektu, a zarazem właściciel biznesowy przygotowywanego rozwiązania. Scrum Master został dołączony do projektu, a deweloperzy i analitycy biznesowi mieli wspólnie tworzyć zespół deweloperski. Początkowo podczas przypisywania pierwszych zadań projektu, zostały one dobierane do roli zdefiniowanych według metodologii kaskadowej, czyli analitycy realizowali plan zbierania wymagań, podczas gdy deweloperzy przygotowywali środowiska testowe do budowania nowego produktu. Jednak w miarę trwania projektu analitycy biznesowi nie ograniczali się tylko do zbierania wymagań i „tłumaczenia” ich na techniczne, lecz brali czynny udział w testach kolejnych wersji rozwiązania, przeglądali jakość kodu pisanego przez programistów oraz proponowali rozwiązania kolejnych funkcjonalności. Im dłużej trwał projekt, tym bardziej cały zespół deweloperski ze sobą współpracował i wzajemnie się uzupełniał. Wypracowaliśmy model współpracy w 100% zgodny z przyjętą metodyką Scrum.

Co zaważyło o naszym sukcesie?

Po pierwsze, zespół deweloperski został bardzo dobrze dobrany profilowo. Przez profil mam tu na myśli doświadczenie dziedzinowe i specjalizację każdego z członków zespołu. W skład zespołu weszło dwóch programistów i trzech analityków, przy czym pierwszy programista specjalizował się w jednej dziedzinie, a drugi w dziedzinie programowania BI. Jeśli chodzi o dobór analityków, to sprawa miała się podobnie. Jeden z analityków posiadał szeroką wiedzę z zakresu budowania rozwiązania proponowanego klientowi, tymczasem drugi posiadał ogromną wiedzę tematyczną i regulacyjną z merytorycznego zakresu projektu. Okazało się to doskonałą kombinacją, w której każdy z członków zespołu deweloperskiego uzupełniał się wzajemnymi kompetencjami. W zespole deweloperskim, który został w ten sposób stworzony wszyscy zrozumieli biznes, dla którego realizowali projekt. Za analizę, projektowanie, rozwój i testowanie odpowiadał cały zespół. Zatem mimo początkowego podziału ról według standardów projektów kaskadowych udało się zachować i stosować zasady tworzenia zespołu deweloperskiego według manifestu Scrum.

Wspomniany przykład pokazuje pewną tendencję, która dla projektów prowadzonych w metodykach zwinnych stanowi istotną przewagę. To nie przypisana rola członka zespołu świadczy o jego zakresie zadań w projekcie, lecz jego kompetencje. Określenie roli może być dobrym sposobem na rozpoczęcie pracy w zespole projektowym, jednak w miarę wzrostu zaawansowania prac projektowych, granice pomiędzy rolami powinny się zacierać, a zespół deweloperski powinien tworzyć zgrany skład, zapewniający brak spadku efektywności podczas nieobecności któregokolwiek z jego członków.  

Przedstawione zasady pomogą utworzyć nie tylko efektywny zespół projektowy, ale również zapewnią podstawy do rozwoju każdego z jego członków, co pozwoli im czerpać wartość ze swojej pracy.

Podsumowując, dobrze zorganizowany i uzupełniający się zespół jest podstawą prawidłowego działania projektu. Bez dobrze rozumiejących się i kompetentnych członków zespołu nie uda się zbudować rozwiązania, jakiego oczekuje klient. Bardzo ważny jest umiejętny dobór osób do zespołu jeszcze przed rozpoczęciem prac projektowych, a ich zestaw kompetencji i profile będą stanowić o sukcesie lub porażce prowadzonych prac.