Agilní přístup k produktovému vývoji

.A občas se složitě řeší, čím po celou dobu trvání projektu zaúkolovat jednotlivé členy týmu. Na tyto nedostatky jsme všichni zvyklí a bereme je jako fakt – co kdyby ale existoval způsob, jak věci dělat lépe?

Agilní metody (nebo tzv. agile) začali před mnoha lety používat softwaroví vývojáři. Agile se vymezuje vůči tradičnímu způsobu vývoje a výroby a staví na častém dodávání dokončených úkolů, práci v mezioborových týmech a plánování na základě pevně daných termínů, nikoliv pevně dané specifikace. V širším kontextu je agile filozofií, kterou můžeme použít kdekoliv ve výrobě. Jádrem agilního vývoje je totiž pozitivní přístup ke změnám, vývoj v iterativních cyklech a průběžné zpracovávání zpětné vazby.

U softwaru a programování je agile oblíbený, protože týmům umožňuje snadno pracovat i řídit celý proces, a zároveň zpracovávat průběžně se měnící požadavky a úkoly na každý produkt. V digitálním a dynamickém světě softwarového vývoje tato metoda funguje výborně. Jak ji ale překlopit do strojírenství, které se od softwarového vývoje diametrálně liší?

Jak na agilní produktový vývoj

Existují různé metody a procesy agilního vývoje, všechny ale mají jedno společné: jejich jádrem je důraz na iterace a volný průběh celého procesu. Hojně používanou metodou, zejména při projektovém řízení ve strojírenství, je tzv. Scrum.

Při něm projekt rozdělíte na pravidelné cykly, kterým se říká sprinty. Sprinty obvykle trvají 7–14 dní a účastní se jich týmy o 5–9 lidech. Týmy se většinou řídí samy, jsou mezioborové a při každém sprintu se věnují konkrétnímu úkolu, který si daly za cíl. Úkoly se vybírají z tzv. produktového backlogu, což je jakýsi seznam cílů pro daný produkt, a sprint je završen dodáním funkčního řešení. Právě hotové řešení na konci každého sprintu je podstatou metody – ať už je tímto řešením zformulovaný nápad, užitečná simulace nebo hotová součást. Vývoj se tak dá rozdělit do iterativních cyklů, ve kterých se zpracovává zpětná vazba – a projekt se dlouhodobě ubírá správným směrem.

Produktový backlog se odchyluje od tradiční produktové specifikace, která se při produktovém vývoji obvykle používá. Nejde o žádný podrobný a neměnný plán, naopak: backlog obsahuje prioritní položky, které produktu přidávají hodnotu, dají se testovat a v neposlední řadě popisují, kdo, jak a proč úkol zpracuje. Přejit na tento dynamický a iterativní seznam úkolů si ale žádá zásadní změnu celého vývojového procesu. Je proto nezbytné, abychom pochopili hlubší podstatu celého konceptu.

Při tradičním vývoji produktů začínáte seznamem specifikací od klienta. Jde o arbitrární požadavky, například to, že produkt musí „unést 2,5 kg“ nebo „jít snadno zvedat“. Ať už s konkrétní specifikací přijde sám klient, nebo se na začátku projektu sepíše interně, slouží výsledný dokument jako přísně vymezené zadání toho, co musí návrh obsahovat. Ze specifikace poté vychází klasický vodopádový model, ve kterém na sebe navazují fáze vývoje, výroby a používání produktu. Scrum a produktový backlog překlápí vodopádový způsob práce na iterativní proces.

Při vodopádovém řízení projektu nejprve produkt vyvíjíte, potom ho vyrábíte, a nakonec se používá. Při metodě Scrum se ale mezi jednotlivými fázemi plynule přechází tam a zpět a pracuje se v uzavřených iterativních cyklech. Díky tomu můžete neustále postupovat kupředu a zároveň návrh produktu průběžně upravovat, předcházet problémům a generovat další a další nápady.

Vraťme se zpátky k příkladu jasně dané produktové specifikace a podívejme se, jaké výhody Scrum má při vývoji hardwaru. Při vodopádovém způsobu práce produkt na základě specifikace vyvinete, vyrobíte a uvedete na trh, aniž byste měli ucelenou zpětnou vazbu od spotřebitelů nebo dodávali funkční řešení v měřitelných cyklech. To nahrává vzniku potenciálních problémů. Pokud se specifikace po nějaké době změní (nebo jen nepatrně upraví), vyhodili jste oknem dlouhé hodiny práce strávené plánováním a tvorbou koncepčního návrhu. Iterativní cykly metody Scrum a zapracovávání zpětné vazby vám naopak umožní mít neustále na paměti cíle produktu a snadno a efektivně návrh upravovat.

Proč je agilní vývoj potřeba?

Už jsme zmínili, že si agilním vývojem můžete ušetřit dlouhé hodiny zbytečné práce na nepoužitelných návrzích. Iterativní charakter celé filozofie zároveň vytváří podhoubí pro ustavičný pokrok v navazujících fázích inovačního kontinua. Zavedení agilního přístupu k produktovému vývoji tak má celou škálu přínosů, které vyplývají ze samotné podstaty této metody:

Při agilním vývoji se pracuje rychleji a na menších částech celého návrhu. Každý tým je složený z profesionálů různých oborů a dovede tak konkrétní dílčí úkol samostatně zpracovat od začátku až do konce. Na úkolech přitom může tým pracovat i bez schůzek o směřování projektu, kterých se účastní všichni vývojáři. Schůzky jsou kratší, úkoly se dokončují rychleji a práce je plynulejší. Z toho těží nejen vývojáři, ale i samo vedení.

Agilní vývoj podněcuje kritické myšlení a proaktivitu. Při tradičním vývoji si vytvoříte pevný a neměnný seznam úkolů a v maximální možné míře se ho držíte. Takový způsob práce sice může fungovat dobře, utvrzuje ale vývojáře v rigidním myšlení. Při agilním přístupu se naopak můžete mnohem hlouběji zapojit do řešení problémů v celém tvůrčím procesu a možná dokonce předvídat potenciální problémy. K aktivnímu kritickému myšlení samozřejmě dochází i při vodopádových procesech, agile ale jeho potenciál ještě násobí.

Agilní vývoj je podhoubím pro inovace. Každý vývojář (nebo vývojářský tým) se snaží nepřetržitě inovovat a posouvat tím projekt kupředu tak, aby klient dostal co nejlepší funkční řešení. K němu sice vede i statický vodopádový model, jenže při něm jsou vývojáři omezeni tím, s čím dovedli přijít při přípravě úvodní specifikace a postupu práce. Agile oproti tomu umožňuje produkt při celém vývoji nepřetržitě upravovat a vytváří tak ideální prostředí pro inovace.

Právě díky výše zmíněným přínosům i konkrétním výsledkům, které agile přináší, je tato metoda ve strojírenství tolik přínosná. Nestačí ale jen pochopit, jakými principy se agile řídí a proč je tak užitečný. V dalším kroku ho potřebujeme sami zavést.

Agilní metody pro strojírenství

Jelikož mají agilní metody svůj původ v softwarovém vývoji, existují samozřejmě jisté rozdíly mezi původní metodologií a tím, jak ji lze aplikovat ve strojírenství. Skvěle je to ilustrováno tím, co se považuje za hotové „řešení“ dodané na konci sprintu. V softwarovém světě můžou vývojáři za jeden sprint stihnout funkční kus kódu – ve strojírenství ale jen stěží bude výsledkem každého sprintu funkční díl. Proto je na místě přijít s hybridním přístupem pro strojírenství, který se agilním vývojem „inspiroval“.

Na produktový vývoj můžeme aplikovat asi nejpodstatnější součást metody Scrum, totiž iterování ve sprintech. Místo abychom produkt nejprve vyvíjeli, potom vyráběli, a nakonec uváděli na trh, bude přínosnější celý proces rozdělit na segmenty, které mezi všemi fázemi plynule přecházejí tam a zpět. V tomto smyslu se nabízí vzít nápady nebo koncepty, které k projektu máme, a každý z nich zpracovat v konkrétním sprintu. Při agilním přístupu je mnohem důležitější práci stihnout v daném časovém úseku než dokončit každý úkol, který se původně nabízel. Tím lze předejít tomu, aby se projekt výrazně zpozdil.

Na tomto místě je nutné vysvětlit jednu věc: i když zavedete proces inspirovaný agilním přístupem s jasným časovým rámcem, neznamená to, že rezignujete na potřebnou funkcionalitu. Jde spíše o to, že se týmy zaměří nejprve na nezbytné funkce, a funkce doplňkové se přidají, když to čas dovolí. Na začátku projektu týmy často hýří nápady, jak projekt zlepšit – není ale nutné tyto myšlenky rovnou zapracovávat do projektového plánu. Striktní časový rámec vám umožní, že dosáhnete nezbytných výstupů a možná budete mít prostor na dodatečné vylepšování. Strojařům tento přístup umožňuje naplno soustředit energii tam, kde ji využijí nejlépe.

Se zavedením metody inspirované agilním vývojem se musí změnit i náš přístup k sestavování projektových týmů. Když se projektové úkoly rozdělí do zvládnutelných týdenních sprintů, mohou týmy pracovat soustředěněji, zároveň ale musí být různorodější. Celé roky jste nejspíš fungovali v rámci jednotlivých oddělení, teď ale potřebujete tým vybrat tak, aby zahrnoval různé úrovně vedení. Při Scrum metodě potřebujete team leadera, který vede daný tým, sprint leadera, který má pod kontrolou celý proces, a tým vývojářů, kteří budou úkol zpracovávat. Sprint leader i team leader se můžou podílet na vývoji, jejich hlavním cílem je ale vést příslušný sprint a směřovat vývojáře k funkčnímu řešení. Rozdělení rolí není nutně spojené s hierarchií pozic – role se můžou projekt od projektu lišit a být přiděleny vývojářům stejné úrovně. Cíl je jen jeden: mít přehled o tom, kdo pracuje na dílčích částech úkolu.

Když se s odstupem podíváte na to, jak v produktovém vývoji týmy obvykle fungují, uvědomíte si, že v nich znalosti existují izolovaně a že se v nich zadrhává nezbytná komunikace. Když vývoj pracuje odděleně od výroby, můžou v procesu vzniknout překážky pro komunikaci, a často také vznikají. Agilní týmy naopak umožňují v průběhu sprintu jednotlivým „oddělením“ komunikovat – i když dané oddělení reprezentuje jen jediný člen týmu.

Využití agilních metod také pomáhá lépe řídit fungování týmu a zároveň předcházet tomu, aby se toho na jednotlivé členy naložilo příliš. Když se větší projekt rozkouskuje na malé a dosažitelné cíle, můžou týmy lépe a dříve zpracovávat zpětnou vazbu a zvládat požadavky v mnohem konkrétnějším meřítku. Zabrání se tím tomu, aby byli vývojáři zahlcení seznamem projektových požadavků, a na druhé straně tento přístup předchází prokrastinaci nebo nepromyšlenému plánování.

Změna procesů v produktovém vývoji

Přístup inspirovaný agilními metodami vám může v produktovém vývoji ušetřit množství problémů při navrhování a pozitivně ovlivnit harmonogram projektu. Chcete i vy vyvíjet agilně? Stačí se zaměřit na uživatelské potřeby místo specifikací, sprintovat na krátké vzdálenosti namísto běhání maratonů, a nechat týmy pracovat na jasně vymezených dílčích úkolech.

Podrobnější analýza agilních metod ukazuje, že má jejich potenciální zavedení množství přínosů a jen velmi málo nevýhod. Jako vývojáři i projektoví manažeři bychom se měli sami sebe ptát, jak metody inspirované agilním vývojem implementovat v našich týmech a se zdroji, které máme k dispozici. Když rozdělíme zdroje do menších týmů a budeme denně pořádat Scrum meetingy, budeme lépe fungovat? Budeme umět přesněji předvídat budoucí vývoj? Když budeme iterovat v týdenních sprintech, budou projekty zvladatelnější? Budou přinášet lepší výsledky? Přesně tyto otázky si musíme položit, nebo je rovnou otestovat, až se k tomu naskytne vhodný projekt. My vývojáři neustále usilujeme o optimalizaci vývojového procesu a hledání inovací. Právě proto potřebujeme pečlivě prozkoumat, jak metody inspirované agilním vývojem fungují – a zavést je i ve vlastní společnosti.