DAD – Role

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery (DAD) to nie jest kolejna metodyka, ale część zestawu narzędzi Disciplined Agile (DA) 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 przedstawionych z dostępnych 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 pozostałych 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.

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).

Źródło grafiki: https://www.pmi.org/disciplined-agile/process/introduction-to-dad/people-first-roles-in-dad-introduction

Jak rozumieć 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 i 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 zespół miał zasoby, których potrzebuje, oraz usuwając na czas wszelkie przeszkody dla zespołu (rozwiązywanie problemów). Gdy zespoły są samoorganizujące się, skuteczne przywództwo ma kluczowe znaczenie dla ich sukcesu. 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 odpowiedzialny za kontakt z interesariuszami w celu rozpoznania zadań, które należy wykonać, priorytetyzację pracy, pomoc zespołowi w zrozumieniu potrzeb interesariuszy oraz efektywnej interakcji z nimi.
  • 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. Jest liderem technicznym, reprezentującym interesy architektury w organizacji.
  • Członkowie zespołu (ang. Team Members) współpracują ze sobą, aby wypracować rozwiązanie. W idealnej sytuacji są oni wszechstronnymi specjalistami lub pracują nad tym, aby nimi zostać. Często określa się ich mianem osób o wszechstronnych kwalifikacjach. Rola członka zespołu koncentruje się na tworzeniu rzeczywistego rozwiązania dla interesariuszy.
  • 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.
  • Specjalista (ang. Specialist) – w tym przypadku nazywamy tak kogoś, kto posiada nie tylko ogólną wiedzę, ale również szczególne kwalifikacje, które są nam potrzebne w danej chwili. 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żynierowie ds. reużywalnych rozwiązań, inżynierów operacyjnych i inne osoby które można określić mianem specjalisty w kontekście DAD.
  • 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, co wymaga 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 często ekspertem merytorycznym (ang. Subject Matter Expert; SME). 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.
  • Ekspert Techniczny (ang. Technical Expert) to osoba posiadająca rozległą 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 operacyjnej bazy danych (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 do zespołu 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ń.

Źródło: 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.

X
X
X