Jak využít agilní vývoj při rozvoji podnikového informačního systému

V posledních deseti letech se v Česku dostalo v oblasti softwarového vývoje do popředí zájmu agilní projektové řízení, zejména metoda Scrum. V dnešním článku se podíváme, jak a kdy ho využít při rozvoji podnikového informačního systému a kdy se ho raději vyvarovat.

Co to je agilní vývoj

Agilní projektové řízení se datuje do roku 1986, kdy Hirotaka Takeuchi a Ikujiro Nonaka přišli s novou metodou projektového řízení, která by se dala elegantně využít v automobilovém průmyslu a při vývoji počítačového hardwaru. Ani v jednom z těchto odvětví se jejich metoda publikovaná v Harvard Business Review moc neujala. Zato o dvacet let později začala zajímat softwarové vývojáře u nás. Do oblasti softwarového vývoje ji přitom už v roce 1995 přenesl americký vývojář Ken Schwaber. Ten původní metodiku doupravil do dnešní podoby Scrumu (slovo pochází z ragbyového termínu scrum, česky skrumáž, kdy před prvním výhozem stojí oba kompletní týmy uprostřed hřiště těsně naproti sobě).

Agilní vývoj staví na jednoduché myšlence inkrementálního řízení projektu – tedy postupného zpracovávání úkolů po dílčích celcích, kdy jde vývoj kdykoliv zastavit, zrychlit, upravit apod. Potřebujete například rozšířit svůj ERP systém o procesy v HR oddělení? Nejprve pokryjete ty nejhlavnější v základních obrysech, pak začnete buď pokrývat další procesy, nebo detailněji rozpracovávat ty hlavní, již pokryté, a takto postupně jdete krok za krokem dál a dál. Těmto jednotlivým krokům se v agilním vývoji říká sprinty (termín pochází opět z ragby, kdy hráč s míčem se snaží doběhnout co nejdál, dokud ho někdo nezastaví).

Jak probíhá agilní vývoj

Agilní vývoj vychází z tzv. product backlogu, což je celkový seznam úkolů, které je potřeba udělat. Z nich si vývojáři spolu s vlastníky backlogu, v případě ERP systému s klíčovými uživateli, vyberou seznam úkolů pro další sprint. Ten je vždy striktně omezen délkou trvání; obvykle trvá jeden týden až jeden měsíc, přičemž nejčastější bývají dvoutýdenní sprinty.

Výstupem sprintu mají být fungující funkční celky, které byly zadány. Pod pojmem „fungující“ se přitom skrývá absolvování celého vývojového cyklu, od zadání přes programování po integraci, testování a dokumentaci. Tedy fungující celek připravený k okamžitému nasazení. Při délce sprintu to ovšem znamená, že zadávané celky jsou často opravdu dílčí, jako třeba v našem příkladě pokrytí hlavních procesů v rámci HR popsané výše. Klíčovým úkolem je proto správné rozplánování sprintu. I to je metodicky přesně podchyceno a měl by se ho účastnit celý vývojový tým.

Hlavní odlišností agilního vývoje od toho tradičního je však způsob řízení projektu, kdy vývojářský tým má obvykle každý den ráno scrum meeting, na němž si jednotliví vývojáři rozdělí dílčí úkoly, respektive si sdělí, jak se jim daří držet se plánu stanoveného den předtím. Na úkoly ze sprint backlogu, které mají zpoždění, je pak možné ad hoc přidělit další či jiné vývojáře, takže případné zpoždění se obvykle eliminuje do dalšího pracovního dne.

Součástí každého sprintu je i sprint review na jeho konci, kdy se zhodnotí, co bylo dokončeno, práce se odprezentuje vlastníkům product backlogu a určí se náplň dalšího sprintu, a také sprint retrospective, kdy se zhodnotí, jak probíhal předchozí sprint a co by bylo možné do budoucna, zejména po stránce vývoje a práce vývojářského týmu, vylepšit.

K čemu agilní vývoj v oblasti ERP využít

Agilní vývoj má v oblasti ERP systémů nepochybně své místo. Jak můžete vyčíst z jeho fungování výše, je doslova ideální pro rozvoj systému v podobě jednotlivých dílčích releasů. Výhody agilního vývoje spočívají hlavně ve schopnosti rychle doručit fungující celky, což v této fázi životního cyklu podnikového informačního systému je obvykle žádoucí. Jakmile je systém nasazen do ostrého provozu, rozvojové úkoly se často soustředí na rychle proveditelné úkoly jako nové formuláře, nové workflow, nové integrace, nové reporty apod.

Agilní vývoj se však hodí i tehdy, kdy si firma chce „vyzkoušet“ rozšíření stávajícího podnikového informačního systému do nějaké nové oblasti, kde si není příliš jistá náročností, výsledkem či finálním rozsahem využití systému a jeho funkcí. Právě pro oblast nejistoty je agilní vývoj velmi přínosný v tom, že umožňuje relativně málo nákladné a postupné rozšiřování funkcí. Tím, že základ může být hotový třeba za jeden sprint – tedy dva až čtyři týdny – dává možnost něco relativně rychle a levně vyvinout a uvést do provozu, pak to chvíli testovat a na základě zkušeností z reálného fungování rozhodnout, co a jestli dělat dál.

Proto je také agilní vývoj ideálním nástrojem pro podporu inovací. Pokud se ve firmě objeví nápad na inovaci, který potřebuje i zásah do ERP systému, může být agilní vývoj ideální pro pomoc s otestováním nějaké myšlenky. Velká část inovací totiž ve firmách končí na tom, že po stránce IS/IT by to bylo „příliš drahé“ a dlouho by to trvalo. 

Kdy se agilní vývoj moc nehodí

Při využívání agilního vývoje v oblasti podnikových informačních systémů je však potřeba myslet na to, že systém jako takový je jen nástroj, který je využíván zaměstnanci, obchodními partnery a zákazníky pro nějaký konkrétní účel. V případě ERP systémů tak samotný softwarový vývoj tvoří jen dílčí součást podstatně náročnějšího a komplexnějšího celku, kdy je potřeba mnohdy pomoci uživatelům vyvinuté části systému tuto část začít plně a správně využívat. Navíc většina změn ve firmě (a systému) nese své ovoce až s odstupem času, někdy i několika měsíců, či dokonce let (v případě např. sběru dat pro budoucí analýzu).

V oblastech fungování firmy, kde se jedná o změny zahrnující více oddělení ve firmě či o realizaci strategické změny ve firmě, se tedy agilní vývoj příliš nehodí. Kvůli svému tlaku na rychlé doručení fungujícího produktu či funkcionality totiž neskýtá dostatek prostoru pro mnohdy velmi časově náročnou spolupráci se stakeholdery (zejména externími, jako jsou zákazníci), protože není připraven na to, že nějaký proces trvá blíže neodhadnutelnou dobu (např. typicky získání zpětné vazby od reálných uživatelů), která je navíc mimo kontrolu projektového manažera (scrum mastera).

Obecně vzato tedy doporučujeme agilní vývoj spíše tam, kde je vývojovému týmu předáno konkrétní zadání ideálně dílčích celků, které je plně pod jeho kontrolou a nevyžaduje už žádné dodatečné externí vstupy a interakce s jinými subjekty mimo firmu. Pak může agilní vývoj fungovat velmi rychle a efektivně.