Disciplined Agile Delivery

Disciplined Agile Delivery (DAD), doslovně ukázněná agilní dodávka, umožňuje zjednodušit procesní rozhodování při vývoji a správě software a dodávat řešení postupným a přírůstkovým způsobem. DAD staví na mnoha postupech agilního softwarového vývoje, jako je agilní metodika scrum, agilní modelování, Lean Software Development a další.

Biblí DAD je kniha Disciplined Agile Delivery,^[1] kterou napsali Scott Ambler a Mark Lines.

DAD se využívá zejména jako způsob jak rozvíjet metodu scrum.^[2] Bhuvan Unhelkar, starší konzultant fy Cutter, řekl, že „Nástroje DAD poskytují pečlivě navržený mechanismus, který urychluje práci v IT a hlavně umožňují škálování.“^[3]

Historie

DAD má životní cyklus založený na porovnání rizik a přínosů. Je řízený cíli, je škálovatelný a zohledňuje podnik.^[4]

Scott Ambler vyvinul Disciplined Agile Delivery v době kdy působil jako hlavní metodik pro IT ve společnosti IBM Rational (léto 2006 až léto 2012). DAD mělo vyplnit procesní mezery (záměrně) ignorované metodou Scrum, a doplnit nástroje pro vývoj na úrovni podniku. Podle Amblera existuje pro řešení projektu od jeho zahájení k dodání "mnoho agilních metodik - včetně Scrum, XP, AM, Agile data, Kanban aj." Dokud nebyla DAD, museli jste si pro svou práci vždy slepit vlastní agilní metodiku."^[5]

Framework DAD byl navržen podle případů, ve kterých byly agilní metody v daném měřítku úspěšné. Odráží zkušenosti zaměstnanců IBM s různými zákazníky, použití agilních metod na interních projektech a spolupráci s obchodními partnery.^[6] „DAD proces uznává nejen význam sítí mezi různými týmy, ale výslovně nabízí podporu pro škálování klíčových postupů v rámci komplexních pracovních prostředí pomocí technik, které propojují jednotlivé vývojové techniky do robustní dodávky software.“^[7]

Dílčí cíle Disciplined Agile Delivery

^[8]

Podstatné znaky

Lidé na prvním místě

Disciplined Agile Delivery říká, že faktorem, který nejvíce ovlivňuje úspěch při dodání projektu, jsou lidé a způsob jak spolu komunikují.

Zaměřený na učení

DAD podporuje myšlenku, že členové týmu by měli úzce spolupracovat a učit se od sebe navzájem. Tým by se měl snažit učit se z vlastních zkušeností a vylepšovat svůj přístup, a jednotlivci by měli dělat totéž.

Smíšený přístup

DAD přejímá a přizpůsobuje si z existujících metod osvědčené strategie jako například Scrum, extrémní programování (XP), agilní modelování, Unified Process (UP), Kanban, vývoj software metodou outside-in a jiné. DAD již má vyřešeno, které části těchto technik jsou vzájemně relevantní, takže údajně není nutno ztrácet čas přizpůsobováním jednotlivých metod.

Životní cyklus úplné dodávky

Na rozdíl od první generace agilních metod, které se obvykle zaměřují na budování systému, životní cyklus DAD řeší celý projekt od bodu zahájení kontinuálně do produkce a také poprodukční činnosti.

Řízený procesními cíli

Přístup DAD je spíše řízený cílem, než normativní. Na rozdíl od Scrum, který práci řídí pomocí fronty nevyřízených položek produktu (backlog), DAD navrhuje stanovení pracovních priorit založených na nejdůležitějších faktorech pro stakeholdery, ať už je to cokoliv.

Těmito faktory mohou být obchodní přínos, riziko, datum dokončení, závislosti na okolí nebo jakákoli jejich kombinace. DAD popisuje kompromisy spojené s každou strategií a popisuje životaschopnost každé z nich.

Speciálním případem je FDD, vývoj řízený užitnými vlastnostmi daného software.^[zdroj?!]

Zaměřený na řešení

Disciplined Agile Development údajně posouvá pozornost od prosté produkce software k poskytování použitelných řešení, která poskytují skutečnou obchodní hodnotu pro zúčastněné strany. Přestože software je jednoznačně důležitou součástí předmětu dodávky, zaměřenost na řešení znamená holistický pohled na celkový problém. To může vést k návrhu změn v oblasti hardware, obchodních / organizačních procesů a celkové organizační struktury.

Stálé porovnávání rizik a přínosů

Životní cyklus DAD je řízený riziky a přidanou hodnotou. Rozšiřuje hodnotově řízený cyklus metody Scrum, která po každém cyklu/iteraci vytváří potenciálně dodatelný (shippable) software tak, že výslovně zahrnuje

• odlehčené milníky, pro zajištění konsensu zúčastněných stran v rané fázi životního cyklu,
• stabilizaci architektury strukturou vývojového kódu už na začátku životního cyklu,
• zajištění dostatečné funkcionality ještě před přechodem na další verzi a
• zajištění připravenosti do produkce ještě před uvolněním releasu.

Úroveň organizace

Podpora úrovně Enterprise je klíčovou vlastností DAD. DAD týmy pracují v rámci organizace stejně jako jakýkoli jiný tým. V ideálním případě DAD tým bude využívat stávajících zdrojů s cílem snížit celkový čas na dokončení a náklady a může pracovat souběžně s ostatními týmy v organizaci. Důležitým aspektem přizpůsobení firmě je, že DAD má explicitní DevOps postupy^[9] a strategie zabudované přímo do frameworku.

Role

Hlavní role

V rámci DAD je bez ohledu na velikost týmu typicky pět základních rolí.^[10]

• stakeholder / zúčastněná strana - Ten, na koho bude mít výsledek řešení podstatný dopad. Spíše než koncový uživatel je to někdo potenciálně ovlivněný vývojem a nasazením softwarového projektu.
• vlastník produktu - Osoba v týmu, která mluví jako "jediný hlas zákazníka", zastupuje potřeby komunity zúčastněných stran směrem k agilnímu dodavatelskému týmu.
• člen řešitelského týmu - Úkolem členů týmu je vytvořit řešení pro stakeholdery, včetně (ale nejen): testování, analýzy, architektury, designu, programování, plánování a
• vedoucí týmu - Tzv. týmový vedoucí je agilní kouč, který je zodpovědný za usnadňování komunikace, optimalizace procesů a zajištění, že tým má potřebné zdroje a pracuje bez překážek.
• vlastník architektury Dělá pro tým architektonická rozhodnutí a usnadňuje tvorbu a vývoj celkového designu.

Vedlejší role

Pro větší dodávky (problém škálování) jsou zavedeny tyto vedlejší role - někdy i na přechodnou dobu

• specialista - Ačkoli většina členů agilního týmu jsou obecně vzato specialisté, jsou v závislosti na potřebách projektu zapotřebí i další odborníci.
• doménový expert - Zatímco majitel produktu zastupuje širokou škálu stakeholderů, expert na věcnou problematiku / doménu je někdy zapotřebí v oblastech, které jsou složité na pochopení a mají mnoho zvláštností a nuancí.
• technický Expert - Pokud se narazí na zvláště obtížný problém, může být podle potřeby osloven technický odborník. To může být správce buildu, správce agilní databáze, návrhář prostředí (UX designer) nebo bezpečnostní odborník.
• nezávislý tester - I když většinu testování provádí členové DAD týmu, ve složitých oborech nebo technologiích může být paralelně k ověření práce přizván nezávislý testovací tým.
• integrátor - U složitých technických řešení může pomoci k vytvoření celého systému z jeho různých subsystémů integrátor (nebo více integrátorů).

Odkazy

Reference