Při přechodu na model DevOps vyvstává otázka metrik. Jak zjistit návratnost investic, jak alokovat zdroje a na co se zaměřit při dalších inovacích?
Komentář na toto téma napsali pro InformationWeek Tim Buntel (XebiaLabs) a Nicole Forsgrenová (Dora). Podle jejich názoru některé firmy vnímají DevOps jako zajímavý experiment a možnost zkusit si (nezávazně) něco nového, jiné zase za naprostou nutnost pro udržení konkurenceschopnosti (DevOps se pokládá za nutnou součást digitální transformace). V obou případech ale opomíjejí měření efektivity.
Kapacita, stabilita, udržitelnost
Existují ovšem nějaké doporučené metriky, tedy kromě známého poměru cena/výkon (investice do změny vs. očekávaná vyšší efektivita vývoje a nasazování softwaru)? Bruntel a Forsgrenová doporučují věnovat pozornost především následujícímu. Klíčovou metrikou je dle nich tzv. propustnost/průchodnost/kapacita (throughput) – tím se myslí, jak rychle v rámci modelu DevOps „protéká“ software systémem, tj. po jaké době ho v průměru lze nasadit do produkčního prostředí. Dále je třeba měřit stabilitu takto produkovaného softwaru – jak často vyžaduje změny, jak rychle se daří tyto změny v produkčním prostředí provést a kolik stojí související výpadky. A na třetím místě se nachází udržitelnost, která souvisí už i s lidským faktorem. Dokáží vývojáři a další členové týmu tímto způsobem fungovat i v delším časovém horizontu? Pokud při každém nasazování nového softwaru očekávají pohromu, je něco špatně. Nedostatek sebedůvěry a stres dříve nebo později skončí vyhořením nebo výpovědí. Rychlý vývoj samozřejmě je psychicky náročný (např. v rámci metodiky scrum dokonce existují speciální pozice, kde úkolem těchto lidí je de facto starat se o to, aby se programátoři nezhroutili), ale tento stav není cílem, naopak problémem; míra stresu přitom může být různá a lze ji měřit a snižovat.
Bruntel a Forsgrenová se navíc domnívají, že výše uvedené metriky nemusejí jít proti sobě (což se na první pohled nezdá – pokud se sníží rychlost tvorby aplikací, dalo by se čekat, že poklesne i stres vývojářů a testerů).
Co dál?
Podnik tedy vytvoří příslušné metriky a dokáže stav DevOps měřit. Jak nyní klíčové ukazatele zlepšovat? Zde už je odpověď obou analytiků celkem standardní: je třeba stejně tak maximalizovat automatizaci jako pracovat na změnách firemní kultury. Podnik by měl zrychlit zpětnou vazbu od zákazníků/uživatelů, zjednodušovat procesy a zpřístupňovat výsledky metrik co nejpochopitelnějším způsobem (grafické panely apod.).
Nicméně v reálném světě nejde dělat všechno najednou, takže je nutné stanovit si priority. DevOps a agilní prostředí současného podnikání obnáší neustálé změny. Nemá proto smysl usilovat o nějaký konečný ideální stav, který stejně nenastane (jde o proces, nikoliv stav, řečeno žargonem málem filozofickým), lépe je uvažovat způsobem: za čas X chceme parametr Y posunout na hodnotu Z, čehož hodláme dosáhnout tak a tak a víme, jak měřit úspěšnost tohoto procesu. Procesy/projekty, které ve skutečnosti nepřinášejí přidanou hodnotu, je třeba umět rychle ukončit – zde se nachází velká slabina řady podniků, přílišná setrvačnost.
Dokonce i úspěšné projekty je třeba umět uzavřít, když už se začínají soustředit jen na kosmetické změny, a nutně omezené zdroje vrhnout jinam. Tento přístup současně znamená, že i drobná zlepšení se počítají (a sčítají), pokud za sebou následují jako na běžícím pásu. I když se mluví o (celkové) digitální transformaci, konkrétní projekty v rámci DevOps vůbec vůbec nemusejí být komplexní a klást si velké cíle…
