Jak dostupnost testovacího prostředí ovlivňuje agilní dodávku vs tradiční vývoj

V jednom z předchozích článků 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í platforma 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í platforma 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 QA 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í platformy pro nový vývoj je tak v této době buď omezená, nebo úplně nemožná.

Potřeba dostupnosti testovací platformy při Agilním vývoji

 Na spodní části obrázku vidíte, jaká je potřeba dostupnosti testovací platformy 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í platformu 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í QA prostředí u vás?

Další praktické odkazy

• Jak získat Scrum certifikát – Přečtěte si článek o tom, jak získat Scrum Certifikát
• Scrum prakticky – Pokud se chcete naučit, jak Scrum prakticky použít, přihlaste se na naše školení
• Agile Performance – Podívejte se, jaké služby nabízíme v oblasti agility