Role w Disciplined Agile Delivery (DAD)

“Ludzie i interakcje ponad procesy i narzędzia”- przywołując sentencję z Agile Manifesto zwracamy uwagę na to, jak ważne w procesie wytwarzania są zespoły i ludzie. Idąc nieco dalej możemy zauważyć, że dla podnoszenia efektywności i jakości dostarczania niezbędnych jest kilka określonych ról. Kolejne frameworki prezentują mniej lub bardziej zbliżone do siebie odpowiedzialności, funkcje, stanowiska. Podobnie jest w przypadku Disciplined Agile (DA), a konkretnie Disciplined Agile Delivery (DAD), który proponuje zestaw ról dostosowany do swoich założeń. 

Ale zacznijmy u źródła.

Czym w ogóle jest DAD?

Zdecydowanie nie jest to kolejna metodyka, ale część zestawu narzędzi Disciplined Agile poświęcona zwinnemu dostarczaniu rozwiązań informatycznych. Uznając, że wybór jest dobry, DAD nie narzuca jednego sposobu pracy danemu zespołowi lub organizacji. W tym podejściu to zespół określa, z których procesów w ramach sześciu cykli życia będzie korzystać. DAD adresuje kluczowe problemy organizacji pokazując tym samym, w jaki sposób zwinne wytwarzanie (ang. agile development) działa od początku, aż do końca. Dzięki swojej elastyczności pozwala on na łatwy start i skalowalność. W praktyce oznacza to, że nie potrzeba “wielkiej rewolucji”, a wprowadzenie tego zwinnego hybrydowego podejścia może mieć swój początek w oparciu o istniejący sposób pracy i stopniowe udoskonalanie go.

Podobnie jak i w innych frameworkach również DAD wyróżnia kilka ról w procesie dostarczania produktów, jednak w odróżnieniu od innych podejść zwinnych nie narzuca konieczności ich istnienia, ale uznaje je za potencjalnie występujące w zespołach.

DAD wyróżnia dwie kategorie ról:

• Główne (ang. primary roles) – krytyczne dla skutecznego/efektywnego zespołu zwinnego,
• Wspierające (ang. supporting roles) – występujące kiedy zajdzie taka potrzeba.

Poniższa grafika przedstawia główne role sklasyfikowane wg. w/w kategorii:

Źródło grafiki: PMI.org

Porozmawiajmy o rolach…

Do ról głównych należy rola Interesariusza (ang. Stakeholder), a także tzw. role zespołowe: Lider Zespołu (ang. Team Lead), Członek Zespołu (ang. Team Member), Właściciel Produktu (ang. PO; Product Owner) i Właściciel Architektury (ang. AO; Architecture Owner).

Role wspierające to Specjalista (ang. Specialist), Niezależny Tester (ang. Independent Tester), Ekspert Dziedzinowy (ang. Domain Expert), Ekspert Techniczny (ang. Technical Expert), Integrator (ang. Integrator).

Wiele osób może zadać sobie pytanie, czy tych ról nie jest aby zbyt wiele? DAD koncentruje się na pełnym cyklu życia produktu i wszystkich aspektach jego dostarczenia, m.in. technicznych, które często są pomijane w popularnych frameworkach. To oznacza, że wraz ze zwiększonym zakresem pojawia się konieczność zdefiniowania ról technicznych, takich jak chociażby Właściciel Architektury (ang. Architecture Owner). Dla kontrastu warto przypomnieć, że znany większości Scrum nie skupia się bezpośrednio na architekturze, a w konsekwencji nie wyróżnia roli odpowiedzialnej za ten obszar.

Co ważne, w zespole DAD każda osoba pełni jedną lub więcej ról. Na przykład Jan może w danym momencie pełnić rolę członka zespołu i właściciela architektury, ale w przyszłym miesiącu przejąć rolę lidera zespołu, gdy Anna, dotychczasowy lider zespołu, będzie przebywać na urlopie. Zespół powinien tworzyć jedną drużynę, która dzieli się odpowiedzialnościami, i w której  role nie są tożsame ze stanowiskami w organizacji. Katarzyna może pełnić rolę interesariusza w projekcie, przy czym w organizacji może być zatrudniona na stanowisku dyrektora finansowego. 

Tradycyjne role, takie jak analityk biznesowy i kierownik projektu, nie pojawiają się w DAD bezpośrednio. Przyświecające im cele nie są pomijane, ale niejako rozproszone. Zrozumienie i uwzględnienie potrzeb/intencji interesariusza w odniesieniu do rozwiązania osiągane jest kolektywnie, a nie dzięki roli analityka biznesowego. Nie ma idealnego dopasowania pomiędzy rolą tradycyjną a rolą w DAD, ale dzięki lekturze Choose Your WoW! dowiesz się, że istnieją rozsądne strategie tranzycyjne. Najważniejszą rzeczą wymaganą przy odejściu od klasycznego zarządzania projektami lub produktami, jest to, że ponieważ zmienił się paradygmat i strategia, to aby odzwierciedlić podejście DAD powinno się zmienić funkcjonowanie tradycyjnych ról projektowych. 

Jakie są zatem odpowiedzialności poszczególnych ról w DAD?

• Lider zespołu (ang. Team Lead)  pełni rolę służebną wobec zespołu, tworząc i utrzymując warunki, które pozwalają zespołowi odnosić sukcesy. Lider zespołu jest także zwinnym trenerem, pomagającym zespołowi skupić się na dostarczaniu elementów pracy, wypełnianiu celów iteracji oraz zobowiązań podjętych wobec właściciela produktu. Pełni rolę prawdziwego lidera, ułatwiając komunikację, umożliwiając zespołowi samooptymalizację procesów, dbając o to, by miał on niezbędne zasoby, a napotkane przeszkody były usunięte  na czas. Dla samoorganizujących się zespołów kluczowe znaczenie ma skuteczne przywództwo. Ta rola może zostać wypełniona przez senior scrum mastera, właściciela produktu lub kierownika liniowego.
• Właściciel produktu (ang. Product Owner) jest nie tylko odpowiedzialny za  kontakt z interesariuszami w celu rozpoznania zadań, które należy wykonać, ale pomaga on zespołowi w zrozumieniu potrzeb interesariuszy oraz umożliwia efektywną interakcję z nimi. Jedną z wiodących metod jest priorytetyzacja pracy. Można powiedzieć, że stanowi on „jeden głos klienta”, który z jednej strony reprezentuje potrzeby interesariuszy przed zwinnym zespołem wytwórczym, z drugiej natomiast pracę tego zespołu na koniec każdej iteracji. Każdy zespół DAD, lub podzespół w przypadku dużych programów zorganizowanych w ramach zespołu zespołów (ang. team of teams), ma jednego właściciela produktu. 
• Właściciel architektury (ang. Architecture Owner) udziela zespołowi wskazówek dotyczących architektury i decyzji projektowych, ściśle współpracując w tym zakresie z liderem zespołu i właścicielem produktu. Architektura jest jednym z kluczowych źródeł ryzyk projektowych, dlatego DAD czerpiąc z Modelowania Zwinnego (ang. Agile Modelling) uwzględnia rolę jej właściciela. Jest on zazwyczaj starszym programistą w zespole, czasem znanym jako architekt techniczny, architekt oprogramowania lub architekt rozwiązań. Należy podkreślić, że nie jest to stanowisko hierarchiczne, któremu podlegają inni członkowie zespołu.Właściciel architektury jest liderem technicznym, reprezentującym interesy architektury w organizacji. Jest osobą, która podejmuje decyzje dotyczące architektury, ułatwia tworzenie i ewolucję ogólnego projektu rozwiązania.
• Członkowie zespołu (ang. Team Members) współpracują ze sobą, aby wypracować wspólne rozwiązanie. Często określa się ich mianem osób o wszechstronnych kwalifikacjach. Członkowie zespołu wykonują testy, analizy, współtworzą architekturę, programują, planują, szacują, czy wykonują wiele innych czynności. Warto pamiętać, że nie każdy członek zespołu musi posiadać kompletną wiedzą ze wszystkich tych obszarów, jednak powinien dążyć do zdobycia kolejnych umiejętności, by być w stanie podjąć się każdego postawionego przed nim zadania. 
• Interesariusz (ang. Stakeholder) to ktoś, na kogo praca zespołu bezpośrednio oddziałuje. Choć lista ta nie jest kompletna, mogą być to przykładowo bezpośredni użytkownicy końcowi, inżynierowie wspierający, załoga operacyjna, osoby odpowiedzialne za finanse, audytorzy, architekci przedsiębiorstwa, kierownicy wyższego szczebla. Najlepiej, jeśli zespoły DAD będą współpracować ze swoimi interesariuszami codziennie, przez cały czas trwania projektu.

Powyżej omówione zostały role główne. Przyjrzyjmy się teraz rolom wspierającym:

• Specjalistą (ang. Specialist) nazywamy kogoś, kto posiada nie tylko ogólną wiedzę, ale również szczególne kwalifikacje, które są nam w danej chwili potrzebne. Przykładem może być specjalista ds. bezpieczeństwa czy osoba odpowiedzialna za UX/UI. Może się zdarzyć, że w szczególnej sytuacji tym mianem określimy również analityka biznesowego, architekta przedsiębiorstwa, menedżera portfolio, inżyniera ds. reużywalnych rozwiązań, inżyniera operacyjnego i inne osoby które można określić mianem specjalisty w kontekście DAD. W dużych zespołach lub złożonych domenach do zespołu może dołączyć jeden lub kilku zwinnych analityków biznesowych, którzy pomogą w zbadaniu wymagań dotyczących budowanego obiektu. W bardzo dużych zespołach może być potrzebny kierownik programu, który będzie koordynował pracę kierowników zespołów na różnym szczeblu. 
• Niezależny tester (ang. Independent tester). Pomimo, że w większości (jeśli nie w całości) testowanie powinno odbywać się w ramach zespołu, może pojawić się potrzeba na większą skalę do wykorzystania równolegle działającego, niezależnego zespołu testerskiego. Powszechne scenariusze wymagające niezależnych testerów to: weryfikacja zgodności z przepisami wymagająca aby część testów odbywała się poza zespołem, jak również duży program (zespół zespołów) pracujący nad złożonym rozwiązaniem, w którym występują istotne wyzwania integracyjne.
• Ekspert Dziedzinowy (ang. Domain Expert) nazywany jest również ekspertem merytorycznym  (ang. Subject Matter Expert; SME). Jest to osoba o rozległej wiedzy w danej dziedzinie czy obszarze problemu. Często eksperci ci współpracują nie tylko z zespołami, ale wspierają także właścicieli produktu dzieląc się swoją wiedzą i doświadczeniem. Właściciel produktu reprezentuje szerokie grono interesariuszy, nie tylko użytkowników końcowych, dlatego nie należy oczekiwać, że będzie on ekspertem w każdej dziedzinie. Od czasu do czasu może zaprosić do współpracy ekspertów z danej dziedziny, na przykład eksperta podatkowego, który wyjaśni szczegóły wymagania, lub członka zarządu odpowiedzialnego za sponsoring, który wyjaśni wizję projektu.
• Ekspert Techniczny (ang. Technical Expert) to osoba posiadająca szeroką wiedzę techniczną, która pracuje z zespołem przez krótki czas, aby pomóc mu w rozwiązaniu konkretnego problemu technicznego. Przykładowo administrator baz danych (ang. Database Administrator; DBA) może współpracować z zespołem pomagając mu w tworzeniu, konfigurowaniu i poznaniu podstaw funkcjonowania bazy danych. Eksperci techniczni często pracują w innych zespołach odpowiedzialnych za kwestie techniczne na poziomie organizacji lub są po prostu specjalistami wypożyczonymi z innych zespołów.
• Integrator (ang. Integrator), zwany również integratorem systemu (ang. System Integrator), często podejmuje zadanie wsparcia niezależnych testerów, którzy zajmują się testowaniem integracyjnym systemu (ang. System Integration Testing; SIT) złożonego rozwiązania, a nawet kilku kompleksowych rozwiązań.  Im większy jest cały zespół, tym większy i bardziej skomplikowany jest budowany system. W takiej sytuacji w zespole może być potrzebna jedna lub kilka osób pełniących rolę integratora, odpowiedzialnego za zbudowanie całego systemu z jego różnych podsystemów. Integratorzy często ściśle współpracują z niezależnym zespołem testującym, jeśli taki istnieje, aby regularnie przeprowadzać testy integracji systemu w trakcie trwania projektu. Tak rozumiana rola  integratora jest zwykle potrzebna jedynie w przypadku złożonych rozwiązań technicznych.

Odpowiadając zatem na pytanie z początku niniejszego artykułu, czy DAD nie obfituje w przesadzoną ilość ról, warto zauważyć, że zostały one zaprojektowane w sposób zdyscyplinowany i uzasadniony. Każda z nich pełni ściśle określoną funkcję dostosowaną do konkretnego obszaru odpowiedzialności, zabezpieczając cały proces dostarczania, a eliminując jednocześnie role, które nie znajdują swojego zastosowania w DAD. 

? Jak Twoim zdaniem sprawdza się zaproponowany podział ról? Podziel się swoją opinią w komentarzu do artykułu.

Źródła:

? Ambler S.W., Lines M., Choose Your WoW! A Disciplined Agile Approach to Optimizing Your Way of Working, Second Edition, Project Management Institute, Pennsylvania 2022, Rozdział 3 i 4.

? People first: Roles in DAD