Agile, Waterfall nebo NRE? Jak vybrat metodiku vývoje

Čtyři modely spolupráce, jeden rámec pro výběr toho správného

Souhr článku:

• Model spolupráce zvolený na začátku projektu často ovlivní jeho výsledek víc než následné technické rozhodnutí.
• Agile se hodí tam, kde se očekává vývoj požadavků, zákazník má vysokou míru kontroly, ale výsledek se formuje postupně, ne je předem daný.
• Agile Capped kombinuje agilní flexibilitu s pevným rozpočtem, což znamená průběžnou prioritizaci rozsahu, ne jeho garantované dodání v plné míře.
• NRE není metodika řízení projektu, ale způsob financování: zákazník financuje jednorázovou úpravu existujícího katalogového produktu ACRIOS, který zůstává součástí produktového portfolia.
• Waterfall funguje nejlépe s kompletní a stabilní specifikací, nabízí předvídatelný rozsah a termín, ale změny během projektu se do něj zapracovávají hůř.
• Model spolupráce není po celou dobu projektu neměnný. Může se posunout, například ze studie proveditelnosti do agilního prototypování a pak do plánovaných etap, jak se zpřesňují požadavky a technické poznatky

‍

Zakázkový vývoj nezačíná výběrem technologií ani prvními řádky kódu. Úspěch projektu často závisí na tom, jaký model spolupráce se zvolí hned na začátku. Kdy dává smysl Agile, Agile Capped, Waterfall nebo NRE, jaké jsou jejich výhody i omezení a podle čeho poznat, který přístup bude pro konkrétní projekt nejvhodnější?

Proč není správný model spolupráce jen formalita

Při plánování zakázkového vývoje zařízení se často řeší rozpočet, harmonogram nebo technické požadavky. Méně pozornosti už bývá věnováno tomu, jak bude projekt řízen. Přitom právě tato volba může zásadně ovlivnit jeho průběh.

Pokud se očekává, že se budou požadavky během vývoje měnit, bývá pevně definovaný postup zbytečně svazující. Naopak u projektů s přesně danou specifikací může příliš flexibilní řízení přinášet více administrativy než užitku. Podobně není vždy nutné vyvíjet nový produkt od začátku. V některých případech je rychlejší, ekonomičtější a méně rizikové upravit už existující řešení.

Neexistuje nejlepší model spolupráce. Existuje model, který nejlépe odpovídá konkrétnímu projektu, jeho cílům a míře připravenosti. Než přijde na řadu konkrétní technologie nebo architektura řešení, pomáhá odpovědět si na následující základní otázky. Odpovědi na ně obvykle napoví víc než samotný seznam funkcí.

• Je zadání kompletně definované, nebo se bude teprve upřesňovat v průběhu projektu?
• Vzniká zcela nový produkt, nebo jde o úpravu existujícího řešení? Ne každý projekt vyžaduje vývoj od nuly, úprava existující platformy může výrazně zkrátit dobu vývoje i snížit náklady.
• Co je nejvyšší prioritou, rychlost uvedení na trh, pevně stanovený rozpočet, nebo přesně definovaný rozsah?
• Očekávají se během vývoje změny? Pokud ano, je vhodné zvolit model, který s průběžnými změnami počítá.
• Je potřeba nejprve ověřit technickou proveditelnost? U složitějších projektů bývá efektivnější nejdřív ověřit architekturu, technologie nebo technická omezení, než se začne s plným vývojem.

Agile: nejrychlejší cesta od nápadu k výsledku

Agile funguje skvěle v projektech, kde je potřeba experimentovat, ověřovat hypotézy a postupně zpřesňovat zadání. Práce probíhá v kratších iteracích a každá končí reálným posunem, prototypem, funkcí nebo testem. Projekt tak přirozeně kopíruje realitu a lze reagovat na změny, aniž by se muselo přepisovat celé zadání. Agile bývá vhodný například tehdy, když:

• vzniká nový produkt nebo technologie,
• je potřeba technické řešení průběžně ověřovat,
• se očekává postupné zpřesňování požadavků,
• prioritou je rychlé získávání zpětné vazby.

‍

Zákazník má vysokou míru kontroly, ale výsledek je postupně formovaný, ne předem přesně nalinkovaný. Agile zároveň vyžaduje aktivní zapojení zákazníka, protože rozhodnutí se přijímají průběžně.

Agile Capped: agilní vývoj s mantinely

Agile Capped kombinuje flexibilitu agilního vývoje s jasně stanoveným limitem rozpočtu. Je to vhodný kompromis ve chvíli, kdy je potřeba pracovat rychle a dynamicky, ale zároveň udržet investice pod kontrolou. Priority se určují společně se zákazníkem a nejdůležitější funkce se dostávají do sprintů jako první. Agile Capped je vhodný zejména tehdy, když:

• rozpočet projektu je pevně stanovený,
• zákazník chce průběžně určovat priority,
• není nutné dodat úplně všechny původně zamýšlené funkce,
• důležitější je maximální hodnota výsledku než pevně daný rozsah.

‍

Nejde ale o univerzální řešení. Pevný rozpočet neznamená automaticky pevný rozsah, pokud během vývoje přibývají nové požadavky, je potřeba jiné funkce odložit nebo přesunout do další fáze. Tam, kde firma potřebuje garantovaný kompletní výsledek, tento model nemusí fungovat dobře.

NRE: úprava katalogového produktu na míru

Ne každý projekt vyžaduje vývoj nového produktu, často stačí rozšířit nebo upravit řešení, které už existuje. V prostředí průmyslové elektroniky nebo IoT to může znamenat doplnění podpory nového komunikačního protokolu, úpravu hardwarového rozhraní, rozšíření firmwaru nebo přizpůsobení produktu konkrétním požadavkům zákazníka.

Právě pro tyto situace se používá NRE (Non-Recurring Engineering). Na rozdíl od Agile nebo Waterfall nejde o metodiku řízení projektu, ale o způsob financování jednorázových vývojových prací. Zákazník financuje konkrétní úpravu katalogového produktu ACRIOS, zatímco produkt i jeho další rozvoj zůstávají součástí produktového portfolia. NRE bývá vhodnou volbou například tehdy, když:

• je potřeba doplnit novou funkci do existujícího zařízení,
• je potřeba přidat podporu dalšího komunikačního rozhraní nebo protokolu,
• jde o přizpůsobení produktu konkrétní integraci,
• není ekonomické vyvíjet nový produkt od začátku.

‍

Než padne rozhodnutí pro vývoj úplně nového zařízení, stojí za to ověřit, zda stejného cíle nelze dosáhnout úpravou existující platformy. V ACRIOS tuhle cestu nabízíme v rámci zakázkového vývoje a OEM výroby, kde je NRE jednou z běžných forem spolupráce.

Waterfall: když je zadání pevně dané

Waterfall je lineární a předvídatelný přístup. Používáme ho tehdy, když je zadání kompletně popsané, nemění se a projekt lze rozdělit do jasných kroků: analýzy, návrhu, vývoje, testování a nasazení. Waterfall bývá vhodný například tehdy, když:

• existuje kompletní technická specifikace,
• požadavky jsou stabilní a neočekávají se významné změny,
• projekt podléhá přísným procesům nebo certifikaci,
• prioritou je předvídatelnost rozsahu, termínů a dokumentace.

‍

Výhodou je naprostá předvídatelnost, nevýhodou to, že jakákoliv změna během projektu celý proces zpomaluje. Pokud se přesto objeví nové požadavky, jejich zapracování bývá u Waterfallu náročnější než u agilních přístupů, proto je kvalitní příprava zadání na začátku obzvlášť důležitá.

Jak vybrat vhodný model spolupráce pro vývoj

Rozhodnutí závisí především na tom, jak dobře je projekt připravený, jak velký prostor zůstává pro změny a zda vzniká zcela nový produkt, nebo se rozvíjí řešení, které už existuje. Schéma níže shrnuje logiku výběru krok za krokem.

Schéma je orientační, správný model vždy závisí na konkrétním projektu, jeho cílech i technických omezeních. Existují i projekty, které kombinují víc přístupů, model spolupráce není neměnný a může se vyvíjet společně s projektem.

Model spolupráce se může během projektu změnit

Projekt není statický. Jak se postupně zpřesňují požadavky nebo se ověřují technická řešení, může se měnit i nejvhodnější způsob řízení. Typickým příkladem je projekt, který začíná studií proveditelnosti, po ověření technického konceptu pokračuje agilním vývojem prvního prototypu, a jakmile jsou požadavky stabilní a architektura ověřená, může přejít do přesně plánovaných etap.

Stejně tak se během analýzy může ukázat, že místo vývoje nového zařízení bude efektivnější upravit existující produkt pomocí modelu NRE. Model spolupráce by proto neměl být cílem sám o sobě, měl by projekt podporovat v každé jeho fázi. A jaké jsou časté omyly při výběru modelu spolupráce?

• Agile není vždy nejlepší volba
  • Pokud jsou požadavky od začátku jasně definované a neočekávají se změny, může být Waterfall efektivnější i předvídatelnější.

• Pevný rozpočet automaticky neznamená Waterfall
  • Projekt s pevně stanoveným rozpočtem lze úspěšně řídit i agilně, důležité je správně nastavit priority a počítat s tím, že se rozsah projektu může během vývoje měnit.

• Nový požadavek nemusí znamenat nový produkt
  • Pokud existuje vhodná platforma nebo katalogový produkt, může být jeho rozšíření rychlejší, ekonomičtější i méně rizikové než návrh zcela nového zařízení.

Proč se vyplatí začít studií proveditelnosti

Studie proveditelnosti bývá prvním krokem zejména u složitějších projektů nebo tam, kde zatím není jasné optimální technické řešení. Jejím cílem není vytvořit finální návrh produktu, ale ověřit, zda je zamýšlené řešení realizovatelné, jaká přináší rizika a jaký postup bude nejefektivnější. V rámci studie se typicky posuzuje:

• technická realizovatelnost navrženého řešení,
• vhodnost zvolených technologií,
• možná technická nebo legislativní omezení,
• potřeba certifikací nebo specifických norem,
• možnosti integrace s dalšími systémy,
• předpokládaná náročnost vývoje.

‍

Dobře připravená studie proveditelnosti často pomůže odhalit potenciální problémy ještě před zahájením vývoje, a ve výsledku tak může ušetřit čas, náklady i pozdější změny projektu.

Jak obvykle postupujeme v ACRIOS

Každý projekt je jiný, ale první kroky bývají podobné. Nejdřív je potřeba pochopit, čeho chce zákazník dosáhnout, teprve potom přichází na řadu technologie nebo způsob řízení projektu.

• Seznámení s projektem, cíle, požadavky a očekávání.
• Posouzení technické proveditelnosti, ověření možností, omezení a rizik.
• Doporučení vhodného modelu spolupráce podle charakteru projektu, ne podle jedné preferované metodiky.
• Návrh architektury a plánu vývoje.
• Realizace projektu podle zvoleného modelu.

Shrnutí

• Pokud se budou požadavky měnit, zvažte Agile.
• Pokud je potřeba flexibilita i pevný rozpočet, zvažte Agile Capped.
• Pokud se upravuje existující produkt, zvažte NRE.
• Pokud je zadání kompletní a stabilní, zvažte Waterfall.
• Pokud zatím není jasné technické řešení, začněte studií proveditelnosti.

‍

Zakázkový vývoj není jen otázkou technologií, stejně důležité je zvolit způsob spolupráce, který odpovídá charakteru projektu, jeho cílům i míře připravenosti. Agile, Agile Capped, Waterfall ani NRE nejsou konkurenční přístupy, každý z nich řeší jinou situaci.

Slovníček pojmů

• Agile – iterativní přístup k vývoji, kdy se zadání postupně upřesňuje a každá iterace přináší reálný výstup. Vychází z principů Agile Manifestu z roku 2001.
• Agile Capped – varianta agilního vývoje s předem stanoveným rozpočtovým limitem, v jehož rámci se prioritizují nejdůležitější funkce.
• NRE (Non-Recurring Engineering) – jednorázová úprava katalogového produktu ACRIOS na míru konkrétnímu zákazníkovi nebo projektu.
• Waterfall – lineární přístup k vývoji, kdy projekt postupuje v jasně oddělených krocích: analýza, návrh, vývoj, testování, nasazení.
• Studie proveditelnosti – úvodní analýza před zahájením projektu, která identifikuje technická omezení a nejvhodnější cestu k řešení.
• Sprint – krátké časově vymezené období v agilním vývoji, během kterého tým dodá konkrétní část funkcionality připravenou k ověření nebo dalšímu rozvoji.
• Iterace – opakovaný cyklus návrhu, vývoje, testování a vyhodnocení, který umožňuje průběžně zlepšovat výsledné řešení.
• Scope projektu – rozsah projektu, tedy soubor funkcí, požadavků a dodávek, které mají být v jeho rámci realizovány.
• Proof of Concept (PoC) – praktické ověření, že navržené technické řešení je realizovatelné, bez cíle vytvořit finální produkt.