Vývoj software jako podhoubí agile má svá specifika, která se podepsala jak na agilních metodikách, tak i na agilních technikách. Firmy, které se rozhodují, zda adoptovat Agile i mimo vývoj software (tedy např. do vývoje Hardware). Já jsem už v několika firmách, které dělají Harware, agilní vývoj nasazoval.

S čím sem se setkal:

  • vyšší náklady – vyvíjet software je drahé. Vyvíjet hardware je ale mnohem dražší. Potřebujete více lidí různých odborností. Vyvinout něco, co bude pro zákazníka užitečné představuje řadu odborností. Subjektivně mám i pocit, že ve vývoji hardware jsou lidé méně produktivní. V praxi pak firma má víc co ztratit, když se něco nepovede.
  • vývoj testovacích desek – ve vývoji sw je běžné, že má každý vývojář svou vlastní kopii celé aplikace a na ní si pracuje. U hardware může být zdlouhavé a drahé udělat pro každého vývojáře jeho testovací desku s kompletním zapojením a ještě vývoj na desce synchronizovat mezi sebou. V praxi se pak více lidí střídá na 1 rozpracované vě­ci.
  • složité Continuous Integration – hardware musí být synchronizovaný s firmwarem. Co je v železe, je i v „mozku“ toho železa. Ale pak většinou ještě existuje nějaký obslužný software psaný ve vysokoúrovňovém jazyce, které zařízení na dálku ovládá, monitoruje. Vývoj takového softwaru se velmi těžko synchronizuje s vývojem hardware, obvykle se úkoly v SW dají rozbít do menších celků, které se dají vyvíjet průběžně – většinu času ale není HW k dispozici. A nebo se čeká, až je HW+FW hotov, jenže to všechno protáhne a zdrží. Takže v praxi běží vývoj HW+FW a SW přibližně paralelně a jednou za čas se setkají, ale neustále integrované části řešení nejsou. U jednoho zákazníka teď usilujeme, aby byl HW i SW synchronizovaný co 2 týdny.
  • nemožnost Continuous Delivery – to si takhle u AŽD školím a povídám, ať dělají časté releasy, ať se průběžně učí a získávají zpětnou vazbu. To bylo poprvé, co jsem na problém vývoje HW narazil. Dostala mě odzbrojící otázka: „To máme do těch kolejí každé 2 týdny znovu položit desítky kilometrů kabelů?“. Samozřejmě, že ne. V praxi to pak znamená, že doba, než půjdete s něčím ven je protažená do doby, kdy bude produkt řádově stabilnější. Znamená to, že budete víc testovat. Že budete usilovat o to, aby hardware byl udělaný správně a vše se dalo případně hasit pomocí upgrade firmware a software.
  • zadávání práce bez User Stories – napsat User Story tak, abyste se ve světě hardware dostali na potřebnou úroveň granularity, bývá často nemožné (a to rozpadat úkoly na menší opravdu umím). Situace, kdy: „Uživatel zapne mobilní telefon“ se ve výsledku může rozpadnout na dobrou stovku podúkolů. Ty nejsou businessové. Produkťák těžko věc zkontroluje, dlouho úkoly zůstávají čistě v kontrole vývojářů. To zvyšuje riziko, že se neudělá něco businessově správně.

Nechci tím ale říci, že agile se nehodí do vývoje hardware. Pořád má řadu věcí, které se použít dají.

Ve zkratce to je třeba PDCA (Plan-Do-Check-Act) přístup při vývoji a ověřování produktu. Technologická dema, kdy zákazníkům na testovací desce můžete předvádět produkty, budování multidiscipli­nárních týmů.

Výsledkem pak je, že je vývoj hardware rychlejší, pružnější, tým se rychleji učí a to jak ze směru businessu, tak ze směru technologie. Agilní vývoj se výborně doplňuje se štíhlou výrobou (nebo i agilní výrobou, která existuje už 20 let, ale k rozšíření agilní výroby na srovnatelnou úroveň s tou štíhlou nedošlo).