V čem se liší dostupnost testovacího prostředí pro agilní a tradiční vývoj?

V článku Kolik stojí agilní transformace? jsem se zmínil o tom, že jednou z položek, na kterou je potřeba se při agilní transformaci podívat, je i testovací prostředí. Následující obrázek ukazuje dostupnost testovacího prostředí v čase pro tradiční vývoj a potřebu dostupnosti testovacího prostředí při agilním vývoji.

Tradiční vývoj

Tradiční vývoj softwaru se obvykle odehrává ve fázích. Po dokončení fáze vývoje jsou nové verze jednotlivých systémů nasazovány na společné testovací prostředí. Během této doby většinou není testovací prostředí k dispozici. Navíc pokud vývojáři neměli možnost testovat integraci mezi systémy již během vývoje, může nedostupnost trvat déle. Testovací prostředí pak zůstává nedostupné i několik dní. Potom následuje fáze testování.

Po dokončení systémových testů přicházejí uživatelské akceptační testy. A v této době už není žádoucí dělat nové změny systémů na testovacím prostředí, abychom testovanou verzi nerozbili a neovlivnili jsme průběh testování. Na nasazenou verzi systémů na testovacím prostředí se nesmí často sahat ještě i po releasu, dokud není release stabilizovaný v ostrém provozu. Možnost využití testovacího prostředí pro nový vývoj je tak v této době buď omezená, nebo úplně nemožná.

Potřeba dostupnosti testovacího prostředí při Agilním vývoji

 Na spodní části obrázku vidíte, jaká je potřeba dostupnosti testovacího prostředí z pohledu agilních týmů. Vykřičníky nad jednotlivými sprinty ukazují, kde všude může mít agilní tým problém s dostupností testovacího prostředí. V každém sprintu agilní týmy provádějí analýzu, vývoj, ale také se snaží neustále průběžně integrovat a testovat. Proto potřebují k testovacím prostředí přístup prakticky nepřetržitě.

Pokud testovací prostředí není dostupné, zastaví se i dodávka v agilních týmech. Když se to stane jen občas, týmy se zaměstnají jinou prací. Ale když se to bude stávat často, povede to ke zbytečnému rozptylování pozornosti a ztrátě času týmu. Agilnímu týmu se pak pravděpodobně nepodaří dosáhnout cíle sprintu, který si stanovili.

Pokud agilní týmy pracují v rytmu nasazování na testovací prostředí tak jako je tomu při tradičním vývoji, může to vést ke zpomalení dodávky hodnoty vašim klientům. A pokud pomaleji dodává tým, dostane také později zpětnou vazbu. A tak se k plýtvání způsobeném nedostupností testovacího prostředí může přidat ještě plýtvání způsobené tím, že tým vyvíjí něco, co nikdo nechce. Proto pokud se chcete zabývat agilním vývojem, stojí za to věnovat pozornost i testovacímu prostředí a jeho dostupnosti , zda stále ještě vyhovuje požadavkům vývoje. A jak to máte s dostupností testovacích prostředí u vás?