Adaptivní vývoj softwaru

Adaptivní vývoj softwaru (ASD – z ang. adaptive software development) je proces vývoje softwaru, který vyrostl z práce Jima Highsmithe a Sama Bayera a je založen na osvědčených postupech a vývojových životních cyklech Rapid Application Development (RAD). ASD je přechod k adaptivním praktikám a ponechání deterministických postupů v kontextu složitých systémů a složitých prostředí. Adaptivní vývoj softwaru se zaměřuje na spolupráci a učení jako metodu pro budování složitých systémů.

Metodika ASD je založena na kontinuální adaptaci – jiné filozofii a jiném životním cyklu – zaměřené na přijímání neustálých změn jako normy. V ASD je statický životní cyklus „Plan–Design–Build“, typický pro tradiční metodiky, nahrazen dynamickým cyklem „Speculate– Collaborate–Learn“. Jedná se o životní cyklus věnovaný neustálému učení a zaměřený na přizpůsobení změnám, které nastávají a přehodnocení do nejisté budoucnosti. ASD je velmi závislý na intenzivní spolupráci mezi vývojáři, managementem a zákazníky.

Životní cyklus adaptivního vývoje softwaru se zaměřuje na výsledky, nikoli na úkoly, a výsledky jsou identifikovány jako funkce aplikace.

Spekulace

Pojem plán je příliš deterministický a naznačuje přiměřeně vysokou míru jistoty ohledně požadovaného výsledku. Implicitní a explicitní cíl souladu s plánem omezuje schopnost manažera řídit projekt inovativními směry.

V adaptivním vývoji softwaru je termín „plán“ nahrazen termínem „spekulovat“. Při spekulacích tým neopustí plánování, ale uznává realitu nejistoty v komplexních problémech. Spekulace podporuje průzkum a experimentování a iterace s krátkými cykly.

Fáze spekulace se skládá z několika kroků, kde každý krok může být během fáze zahájení a plánování několikrát revidován. Zahájení projektu zahrnuje stanovení poslání a cílů projektu, porozumění omezením, vytvoření organizace projektu, identifikace a nastínění požadavků, provedení počátečních odhadů velikosti a rozsahu, identifikace klíčových rizik projektu. Dále je stanoven časový rámec pro celý projekt na základě rozsahu, požadavků na sadu funkcí, odhadů a dostupnosti prostředků, které jsou výsledkem prací na zahájení projektu. Třetím krokem je rozhodnout o počtu iterací a každému z nich přiřadit časový limit. U aplikací malé a střední velikosti se iterace obvykle liší od čtyř do osmi týdnů. Některé projekty fungují nejlépe s dvoutýdenními iteracemi, zatímco jiné mohou vyžadovat více než osm týdnů (i když je to vzácné). Celková velikost projektu a míra nejistoty jsou dva faktory, které určují délky jednotlivých iterací.

Po stanovení počtu iterací a harmonogramu pro každou z nich členové týmu vytvoří téma nebo cíl pro každou z iterací. Stejně jako je důležité stanovit celkový cíl projektu, každá iterace by měla mít své vlastní téma (je to podobné jako cíl Sprint ve Scrumu).

Vývojáři a zákazníci přiřazují funkce ke každé iteraci. Nejdůležitějším kritériem pro přiřazení funkcí je, že každá iterace musí zákazníkovi poskytnout viditelnou a hmatatelnou sadu funkcí. V procesu přiřazení se zákazníci rozhodnou o prioritizaci funkcí pomocí odhadů funkcí, rizik a informací o závislostech poskytnutých vývojovým týmem. Plánování podle funkcí odráží jedinečnost každého projektu.

Spolupráce

Složité aplikace nejsou vytvářeny, složité aplikace se vyvíjejí. Turbulentní prostředí má vysokou míru toku informací. Složité aplikace proto vyžadují, aby bylo shromážděno, analyzováno a aplikováno velké množství informací na existující problém. Výsledkem jsou rozmanité požadavky na znalosti, které lze zvládnout pouze týmovou spoluprací.

Spolupráce, akt společného stvoření, je podporována důvěrou a respektem. Sdílené vytváření zahrnuje vývojový tým, zákazníky, externí konzultanty a dodavatele. Týmy musí spolupracovat na technických problémech, obchodních požadavcích a rychlém rozhodování.

Učení

Část učení v rámci životního cyklu ASD je zásadní pro úspěch projektu.

Tým musí neustále zdokonalovat své znalosti pomocí postupů, jako jsou:

• Technické recenze
• Retrospektivy projektu
• Zaměřit se na zákazníka

Technické recenze by měly být prováděny po každé iteraci. Vývojáři i zákazníci zkoumají své předpoklady a pomocí výsledků každého vývojového cyklu se učí směr dalšího. Iterace musí být krátké, aby se tým mohl poučit z malých, nikoli velkých chyb.

Na konci každé vývojové iterace tým se dozví čtyři obecné kategorie věcí:

• Kvalita výsledků z pohledu zákazníka
• Kvalita výsledků z technického hlediska
• Fungování vývojářského týmu
• Stav projektu

Získání zpětné vazby od zákazníků je u adaptivních projektů první prioritou. Doporučenou praxí společnosti ASD je zaměřit se na skupiny zákazníků. Odvozené od konceptu marketingových cílových skupin jsou tyto relace navrženy tak, aby prozkoumaly fungující model aplikace a zaznamenaly požadavky na změny od zákazníků. Jsou to usnadněné relace, podobné relacím JAD^[ujasnit], ale spíše než generování požadavků nebo definování plánů projektu, jsou zaměřeny na zákaznické skupiny, aby zkontrolovaly samotnou aplikaci.

Základní charakteristiky adaptivního vývoje softwaru

1. Mission driven. Obecně se u vývojového týmu zpočátku stává, že požadavky jsou nejasné a nejisté, ale celková mise, která tým vede, je správně vyjádřena. Na začátku tato mise funguje jako hranice průzkumu, který nemá pevný cíl, ale pomalu směruje vývojový tým k dosažení cíle splněním všech změněných požadavků a potřeb trhu.
2. Feature based. V ASD jsou všechny činnosti, které nejsou prováděny na základě úkolů, ale ty, které vycházejí z funkcí aplikace, zaměřeny na vývoj výkonného softwaru a dodání požadovaného produktu. V každé iteraci se k produktu přidávají požadavky zákazníků jako nové funkce. Ve výsledku se očekává dobrý produkt.
3. Iterativní. Adaptivní vývoj softwaru je založen na iteračních procesech. Nové funkce jsou přidány v každé iteraci. Ty se řídí zásadou neustálých změn a přehodnocení. Od prvního pokusu vývojový tým dostává zpětnou vazbu jako vstup a znovu od začátku nastavuje správný směr pro další rozvoj. Vývoj je tedy založen na procesu nepřetržitého přidávání funkcí s cílem iterativně vytvářet komplexní softwarové řešení, a nakonec přinášet výsledky.
4. Time boxed. Čas uvedený v procesu neznamená použít nesprávně stanovené časové lhůty a limity, ale spíše stanovení pevné minimální dodací lhůty pro iterace a projekty. Když jsou rychlosti změn tak vysoké a prostředí vypadá nejistě je důležité se výrazně zaměřit na dobrém pracovním prostředí pro dokončení práce.
5. Risk driven. V ASD v každé iteraci přicházejí nové výzvy a proces si klade za cíl rychle vyřešit vysoce rizikové položky / aktivity. V tomhle jsou adaptivní iterace hodnoceny, identifikovány a analyzovány s kritickými riziky.
6. Tolerance. Adaptivní vývoj softwaru je založen na neustálých změnách, přehodnocování a vyvíjení produktů s nenáročným plánováním a neustálým učením se. Tento proces tedy bere kontinuální změny jako výhodu a nedělá změny jako problémy, ale bere je jako nové výzvy.

Výhody a nevýhody

Výhody

• Užitečné pro rychlý a komplexní vývoj softwarových produktů.
• Snadné softwarové přírůstkové nastavení.
• Zaměřeni na koncové uživatele a splnění požadavků.
• Umožňuje včasné doručení s maximální spokojeností zákazníků.
• Poskytuje vysokou transparentnost mezi vývojáři a klienty.
• Snižuje chybovost, protože prochází vícenásobným testováním.

Nevýhody

• Práce v nejistém prostředí je náročná.
• Splnění misi vyžaduje široké zkoumání a neustálé zaměření.
• Vyžaduje vysokou účast uživatele / klienta, který se na vývoji přímo podílí.
• Vyžaduje testování každé iterace, což zvyšuje cenu.
• Časté změny procházejí s menší dokumentací.
• Vyžaduje přísný časový závazek mezi různými týmy zapojenými do projektu.

Odkazy

Reference

V tomto článku byl použit překlad textu z článku Adaptive software development na anglické Wikipedii.

Literatura

• Adaptivní vývoj softwaru: Kolaborativní přístup ke správě komplexních systémů, Highsmith, JA, 2000 New York: Dorset House, 392pp,ISBN 0-932633-40-4
• Agilní řízení projektů: Vytváření inovativních produktů, Addison-Wesley, Jim Highsmith, březen 2004, 277pp,ISBN 0-321-21977-5
• Softwarové inženýrství: přístup odborníka, Roger Pressman, Bruce Maxim.ISBN 978-0078022128
• Lev Virine & Michael Trumper (2007). Rozhodnutí o projektu: Umění a věda . Koncepty řízení. ISBN 978-1-56726-217-9

Externí odkazy

• Webové stránky společnosti IBM zabývající se RUP