Metodika DSDM

Velkou část dnešního čísla věnujeme jedné hybridní metodice spojující klasické vodopádové řízení s agilním. Agilní řízení je dnes buzzword, ale ne vždy a všude je tento styl vhodný. Ale zároveň platí – proč se nepoučit z agilních principů a proč je nevyužít? Metodika DSDM je jedna z prvních agilních metodik. Byla tu dokonce dřív, než se ukotvil termín „agilní“. Vznikla již v roce 1994 a vycházela částečně z RAD (Rapid Application Development), ve které projektovým manažerům přišla nedostatečná kontrola a disciplína. Tato metodika klade důraz na včasné dodání, což je dnes častý požadavek. Také klade velký důraz na to, aby se projekt podniku vyplatil z obchodního hlediska a aby bylo dosaženo co nejlepší ROI, ale i na dodržení rozpočtu. Pro dosažení těchto projektových cílů doporučuje používat tyto nástroje: workshopy, modelování a iterativní development, prioritizaci MoSCoW a timeboxing, neboli rozdělení na časové úseky. Podle průzkumu je metodika DSDM celosvětově z méně používaných. Na prvním místě je metodika Scrum, po ní následují metodiky Extreme Programming a Feature Driven Development a DSDM je s 4,166% trhu na čtvrtém místě, s metodikou Kanban ve velmi těsném závěsu. V české Republice není moc známá, ve světě se užívá především v korporátním prostředí.

Metodika DSDM je výjimečná tím, že jako jedna z mála agilních metodik popisuje průběh celého projektu a životního cyklu produktu. Metodiku lze také kombinovat vodopádovými s metodami jako je metodika PMI. Hlavní filosofií DSDM je „the best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people”. Toho je dosaženo, pokud všechny zainteresované strany jak uvnitř, tak mimo projekt, jsou plně zapojeny, mají možnost rozhodovat o věcech týkajících se jejich oboru, chápou vizi a cíle projektu, dodržují časový plán a akceptují, že během projektu může dojít ke změnám jak požadavků, tak způsobů řešení. S tím souvisí i parametry DSDM projektu. Obecně jsou hlavními parametry projektů náklady (finanční i časové), kvalita a užitné vlastnosti (features), které řešení nabízí. Tradiční projekty kladou důraz na dodané užitné vlastnosti, kde náklady se stanou proměnnými (jinými slovy cena i čas doručení se podřizují tomu, aby řešení mělo tyto vlastnosti). Pro DSDM metodiku jsou naopak nejdůležitější časové a finanční náklady a užitné vlastnosti jsou pouhou proměnou. Důraz je tedy na dodržení termínu dodání a finančního rozpočtu a tomu se podřizuje, jaké vlastnosti bude výsledné řešení mít, tak, aby byla zachována co nejvyšší možná kvalita a byly splněny cíle projektu. Právě to odpovídá požadavkům na projekt DMS.

DSDM metodika rozděluje projekt celkem do šesti fází. Čtyři hlavní fáze se nazývají Feasibility, Foundations, Evolutionary Development a Deployment. Před fází Feasibility se nachází ještě tzv. Předprojektová fáze a projekt je ukončen poprojektovou fází. Z Feasibility fáze, kde se ověřuje realizovatelnost záměru, přechází projekt do fáze Foundations, kde jsou vymezeny základní cíle celého projektu. Poté následuje Evolutionary Development, kde probíhá samotný vývoj aplikace. Když se rozhodne o nasazení aplikace, projekt přejde do fáze Deployment. Často (i dle doporučení metodiky) se aplikace nasazuje po částech, proto se fáze Evolutionary Development a Deployment mohou několikrát opakovat v iteracích. Pokud se v rámci fáze Deployment dojde k rozhodnutí, že je třeba přehodnotit požadavky na řešení, lze se vrátit i do fáze Foundations. V poslední iteraci je nasazen finální produkt a projekt je ukončen. Po jeho ukončení následuje tzv. poprojektová fáze.

Dle metodiky DSDM je důležité rozdělení rolí v týmu tak, aby každý člověk měl vymezenou část projektu, za kterou je zodpovědný. Nepočítá se tedy se sdílenou (týmovou) odpovědností, typickou např. pro metodiku SCRUM. Kvůli tomuto vymezení je velice důležitá komunikace mezi členy týmu a vzájemný respekt. Podle DSDM existuje dvojí dělení rolí – podle zaměření či podle postavení v rámci projektu. Role a jejich rozdělení v rámci projektu jsou detailněji popsány v následující kapitole.

Role

Role jde podle zaměření rozdělit do čtyř kategorií.

• První kategorie se sestává z rolí starajících se o zájmy podniku a obchodní pohled na řešení. Do této kategorie se řadí např. Obchodní Sponzor (Business Sponsor), který má mj. na starost financování projektu a dohled nad jeho směřováním v souladu s požadavky firmy, nebo Obchodní Vizionář (Business Visionary), který je zástupcem Obchodního Sponzora a jako takový komunikuje jeho požadavky napříč týmem a stará se o vizi celého projektu.
• Druhá kategorie rolí reprezentuje technický pohled na řešení. Jde především o Vývojáře, což jsou vývojáři řešení (softwaru), Testeři (Solution Testers – testeři kvality vyvíjeného řešení) nebo Technický koordinátor (Technical Coordinator), který je zodpovědný za technický stav projektu.
• V další kategorii jsou role managementu, které mají na starost řízení celého projektu. Projektový manažer (Project Manager), role zodpovědná za celý projekt, nebo Vedoucí týmu (Team Leader), zodpovědný za tým vývojářů.
• Poslední kategorií jsou procesní role. Některé role se mohou nacházet na rozhraní dvou kategorií a nemohou být jasně vymezeny, např. Obchodní Analytik, který je prostředníkem mezi managementem a vývojáři a řadí se proto jak do podnikových, tak do technických rolí.

Podle postavení se role dělí do tří kategorií – projektové role, tým vývojářů a podpůrné role.

• Projektovými rolemi se rozumí ty role, které rozhodují o směřování celého projektu a jsou za něj zodpovědné. Patří sem všichni manažeři a koordinátoři jako Projektový manažer, Technický Koordinátor nebo Obchodní Vizionář. Obchodní Analytik je na pomezí projektové role a týmu vývojářů.
• Tým vývojářů se skládá ze všech rolí, které se podílejí na dodání řešení, tedy kromě Vývojářů také např. Tester nebo Vedoucí týmu. Každý z týmu vývojářů je kompletně zodpovědný za svou část řešení. V rámci jednoho projektu se může vyskytnout i více týmů vývojářů.
• Do podpůrných rolí se řadí všechny ostatní role, např. poradci z různých oborů jako Obchodní poradci nebo Techničtí poradci.

Název	Popis
Obchodní sponzor	Je zodpovědný za Obchodní případ a rozpočet projektu, rozhoduje o obchodních problémech projektu
Obchodní vizionář	Stará se o dodržení obchodní vize v souladu s Obchodním případem, je prostředníkem mezi sponzorem a týmem
Technický koordinátor	Má na starosti technickou stránku projektu a zajišťuje to, že dodané řešení je z technického hlediska smysluplné a odpovídá nastaveným standardům; navrhuje systémovou architekturu
Projektový manažer	Vedoucí projektu, zodpovědný za projekt, jeho plánování a monitorování
Obchodní analytik	Prostředník mezi projektovými rolemi a týmem vývojářů, hlídá, aby směřování vývoje bylo v souladu s obchodními potřebami (a vizí) podniku
Vedoucí týmu	Vedoucí týmu vývojářů, zodpovědný za správné fungování týmu a dodržování plánu
Obchodní zástupce	Reprezentuje potřeby podniku v rámci týmu, má na starost především požadavky a jejich soulad s potřebami podniku, většinou není zapojený full-time
Vývojář (řešení)	Zodpovědný za dodání a otestování své části řešení, měl by mít právo rozhodovat o věcech své specializace
Tester (řešení)	Spolu s obchodními rolemi zpracuje testovací scénáře, testuje kvalitu a funkčnost řešení
Obchodní poradce	Nabízí svou expertízu a znalost oboru při řešení požadavků
Technický poradce	Nabízí svou expertízu a znalost oboru při řešení technické stránky projektu
Lektor workshopu	Připravuje, plánuje a vede workshop
Instruktor DSDM	Pomáhá vytěžit co nejvíce z metodiky, příp. jí přizpůsobit daným potřebám, ideálně by měl být certifikovaný

Metodika nerozporuje obsazení více rolí jednou osobou ani obsazení jedné role více osobami – v tom případě je ale podmínkou že musí úzce spolupracovat.

U některých rolí se zastavme, protože mohou být obecně chápány trochu jinak než v této metodice, nebo jejich vysvětlení pomůže objasnit principy vlastní metodiky.

Obchodní vizionář je fakticky plnohodnotný zástupce vlastníka, protože metodika správně předpokládá, že vlastník obvykle nemá dostatek času věnovat se projektu naplno. Slovem plnohodnotný se rozumí i vybavení odpovídající autoritou dovnitř organizace. Jedná se o seniorní vedoucí roli na úrovni projektu, kterou by měla mít alokovánu pouze jedna osoba, protože projekt potřebuje jednu jasnou vizi, aby se předešlo nejasnostem a nesprávnému vedení. Angažuje se aktivněji než obchodní sponzor, protože je obvykle vyčleněn na full time. Je odpovědný za interpretaci požadavků obchodního sponzora, jejich předání do týmu. Obchodní vizionář zůstává zapojen do celého projektu, poskytuje týmu strategický směr a zajišťuje to, že dodané řešení umožní dosažení přínosů.

Odpovědnosti

• Definování obchodní vize projektu
• Komunikace a propagace obchodní vize všem zúčastněným a / nebo dotčeným stranám
• Sledování průběhu projektu v souladu s podnikatelskou vizí
• Řešení širších důsledků jakékoli business změny z organizačního hlediska
• Přispívání ke klíčovým požadavkům, návrhům a revizím, zejména tam, kde jsou aspekty řešení považovány za klíčové prvky obchodní vize
• Identifikace a vlastnictví podnikatelského rizika
• Definování a schvalování změn požadavků na high-level, tzn. jakékoli změny, která ovlivňuje základní rozsah nebo významně mění rovnováhu priorit
• Zajištění spolupráce napříč oblastmi podnikání v rámci projektu
• Zajištění obchodních zdrojů je pro projekt k dispozici podle potřeby
• Propagace převodu obchodní vize do pracovní praxe, tj. Zajištění úplného obchodního přijetí řešení vytvořeného projektem
• Posílení obchodních rolí v rámci týmu pro rozvoj řešení na odpovídající úrovni v rámci jejich odpovědnosti
• Tam, kde se vývojový tým nemůže dohodnout, jedná jako arbitr.

Obchodní analytik je garantem konzistentnosti řešení z byznysového hlediska. Je aktivní v podpoře rolí na úrovni projektu. Obchodní analytik primárně řeší vztah mezi obchodními a technickými rolemi, zajišťuje přesné a vhodné rozhodnutí o vyvíjejícím se řešení na každodenní bázi. Obchodní analytik zajišťuje, že byznysové potřeby jsou správně modelovány a analyzovány a jsou správně zohledněny v pokynech, které tým potřebuje k vytvoření řešení. Aktivní zapojení koncových uživatelů do procesu vývoje řešení je životně důležité pro úspěch projektu DSDM. Proto je důležité zajistit, aby se Obchodní analytik nestal zprostředkovatelem mezi členy vývojového týmu, ale místo toho komunikaci mezi nimi podporoval a usnadňoval.

Odpovědnosti:

• Pomoc obchodnímu vizionáři při formulaci a propagaci podnikatelské vize
• Modelování současného a budoucího stavu z hlediska identifikace příležitostí, rizik a dopadů
• Spolupráce s obchodním vizionářem a s vývojovým týmem pro formulaci a komunikaci možností řešení
• Podpora a usnadnění jednoznačné a včasné komunikace mezi obchodními a technickými účastníky projektu
• Zajištění kvalitně definovaných požadavků a jejich řádná analýza a řízení
• Řídit vývoj, distribuci a základní schvalování veškerých komunikací souvisejících s obchodními požadavky a jejich interpretací, se zvláštním zaměřením na zajištění toho, aby seznam prioritních požadavků byl průběžně aktualizován, protože se detaily rozšiřují a vyvíjejí.
• Zajištění toho, aby obchodní a organizační důsledky každodenního vývoje řešení byly správně modelovány a promyšleny
• Zajištění dopadu obchodních rozhodnutí je posuzováno v kontextu projektu
• Zajištění toho, aby obchodní a technické složky řešení společně poskytovaly soudržný celek pro podnik
• Spojení s obchodním vizionářem při organizaci podpory řešení prostřednictvím implementace do živého provozu

Technický poradce podporuje tým tím, že poskytuje konkrétní a odborný technický vstup do projektu, často pohledem manažerů odpovědných za provoz, provozní podporu, průběžnou údržbu atd.

Lektor workshopu je zodpovědný za řízení vlastního procesu workshopu. Je katalyzátorem pro přípravu a komunikaci. Je to facilitátor odpovědný za organizaci workshopů, které účastníkům umožní dosáhnout cíle. Facilitátor workshopu by měl být nezávislý na výsledku, kterého má být v projektu dosaženo.

Nástroje metodiky

Zde jsou podrobněji rozepsány některé nástroje specifické pro tuto metodiku, ostatní jsou jen vyjmenovány.

1. Prioritizace MoSCoW

Vzhledem k povaze DSDM projektu, který klade důraz na včasné dodání a kvalitu a proměnnou projektu jsou užitné vlastnosti, které bude mít dodané řešení, je důležité stanovit si priority, tj. jasně vytyčit, které vlastnosti dodávaného řešení jsou bezpodmínečně nutné a které jsou naopak pouze příjemným doplňkem. K tomu slouží právě priotizace MoSCoW, což je zkratka pro „must have, should have, could have, won’t have this time“. Prioritizace se používá v průběhu celého projektu –  ať už při tvoření cílů celého projektu, jednotlivých time-boxů či iterací. Díky tomu může docházet k přesunu požadavků z jedné kategorie do druhé – co během jedné iterace je zamítnuto a odsunuto do kategorie Won’t have this time může být v příští iteraci must have a naopak. Pokud se projekt ocitne v časovém skluzu, začne se upouštět od jednotlivých požadavků, aby byl dodržen termín dodání. V takovém případě se začíná „odspoda“, tj. nejprve se upouští od požadavků could have a pak až případně od should have požadavků.

Must have jsou minimální požadavky na dodané řešení, které musí být vždy splněny, bez kterých by řešení nebylo použitelné. Should have požadavky jsou ty, bez kterých by dodané řešení nemuselo být úplně komfortní, které jsou sice důležité, ale nejsou pro projekt životně důležité. Could have jsou požadavky takové, které jsou možné a mohly by být příjemným rozšířením, nicméně nejsou pro dodávané řešení tolik důležité. Nakonec won’t have this time (odložené) požadavky jsou požadavky, které nyní nebudou dodány. Je důležité si je uchovat, aby nebyly opakovaně navrhovány (a zamítány), což by znamenalo zbytečné plýtvání časem, anebo naopak pro případ, že by daný požadavek byl přehodnocen a přesunut do jiné kategorie.

• Timeboxing

Timeboxing je praktika, kdy se projekt (především ve fázi Evolutionary Development) rozdělí na menší časové úseky (timeboxy), které mají jasně stanovený cíl. Pro každý timebox je vhodné udělat MoSCoW prioritizaci, čímž se jasně vymezí, čím se bude tým v daném timeboxu zabývat a co naopak nyní řešit nebude. Jeden projektový inkrement se obvykle skládá z více timeboxů. Důležité je si uvědomit, že stejně jako sprint v metodice SCRUM timebox neskončí, když se dosáhne nastavených cílů (požadavků), ale když vyprší jeho čas. Pak se vyhodnotí úspěšnost timeboxu dle toho, kolik z naplánovaných požadavků tým stihl dodat. Doporučená délka timeboxu v DSDM projektu je dva až čtyři týdny.

Styly timeboxů jsou dva – strukturovaný DSDM styl a volný styl. Volba mezi styly závisí na povaze projektu a dodávaného řešení.

Strukturovaný DSDM timebox nabízí jasně dané fáze a revize, což napomáhá dlouhodobějšímu plánování (revize se budou opakovat pravidelně). Jednotlivé fáze se nazývají Investigation, Refinement a Consolidation. První a poslední fáze by měly každá zabrat okolo 10-20% celkového času timeboxu a zbylých 60-80% připadá na Refinement. Na konci každé této fáze je revize. Před první fází je kick-off, tedy Zahájení timeboxu, a na konci timeboxu je close-out (Zakončení).

Prosím povšimněme si, že na rozdíl od sprintu je zde jasně oddělena fáze nasazení do provozu a doladění na jejím základě (Refinement).

• Workshopy
• Modelování a prototypování
• User stories

Shrnutí

Autor nasadil tuto metodiku v projektu, který na základě požadavku zákazníka byl vyvíjen agilně, ale zároveň byl zasmluvněn smlouvou Fixed Time – Fixed Price. Obě strany kontraktu byly v určité době po startu značně nespokojeny se stavem, což vedlo k problémům a nedůvěře ve vzájemné komunikaci. Zavedení metodiky fakticky žádný velký průlom neudělalo, protože i tak se pracovalo intuitivně podobným způsobem. Ale pojmenování rolí a odpovědností, to, že jednotliví účastníci si byli vědomi svého úkolu, autority i omezení, ale i vyčištění backlogů (přinucení k pořádné prioritizaci) značně „vyčistilo vzduch“ a projekt se znovu rozběhl a běží ke spokojenosti obou stran.

Do podobné situace se může dostat kdokoliv. Nebo i se objeví stav, kdy se tato hybridní technika ukáže jako užitečný nástroj. Neváhejte se s ní proto seznámit, literaturu lze dohledat na internetu.