DevOps: od simulace k realitě za 1 den 

Jak získat podporu pro DevOps transformaci? Docela lehce. Dá se říci, že pomoc je „na dosah“. DevOps konzultace, školení a simulační workshopy společnosti TAYLLORCOX pomáhají organizacím vytvořit si vlastní unikátní cestu k úspěchu a využití z DevOps přesně a jen toho, co vás v aktuální moment posune. 

Samotný průběh DevOps simulace

Tento intenzivní 1 denní workshop využívá reálné scénáře a učení se pomocí pochopení pozitivních dopadů metodiky v každodenních situacích. Zaměřuje se na kulturu organizace, interní i externí pracovníky a procesy. 

Dokonale nasimulujeme vaše pracovní „flow“ v organizaci. Není nutná předchozí znalost DevOps. V rámci dne absolvujete 3 kola. V nich se zaměříte na plánování, dodávku a kontrolu produktů a služeb. Pojďme se společně vydat na první krok k transformaci na DevOps.

Budete pracovat pro imaginární organizaci, který má za úkol implementovat nové funkce do online systémů a zároveň spravovat životně důležité systémy, které zpracovávají transakce se zákazníky.

Samotný vývoj aplikací není součástí hry. Development probíhá jen v digitálních aplikacích na manažerské úrovni. Stejně tak řešení incidentů a dalších operací probíhá v simulátoru - digitální aplikaci, která je cloudu.

Nicméně výstupy z vašich manažerských rozhodnutí jsou sbírány do softwarové aplikace, která zobrazuje online Dashboard a monitoruje vývoj i dodávky v každém kole.

Nastavuje servisní incidenty a poskytuje dostatek informací pro analýzu vašich kroků. Tyto reporty jsou na konci každého kola vyhodnoceny a následný rozbor se soustředí na praktické tipy, jak s pomocí DevOps pracovat efektivněji, lépe.

Jak celá simulace probíhala a co na to říkají absolventi? Podařilo se odbourat kulturní i firemní bariéry kolem přechodu na DevOps?

Jdeme formovat tým!

V simulaci rozdělujeme manažery do týmů, které kopírují organizační rozdělení. Najdete tak zde vše, co potřebujete pro fungování každá organizace: management, software inženýry, Operations management a pracovníky DevOps.

Co dělá celou simulaci ještě atraktivnější je fakt, že každý manažer dostane jinou roli, než tu, kterou běžně v organizaci zastává.

V principu nám jde o to, aby delegáti dostali šanci pochopit výzvy a problémy, se kterými jejich kolegové bojují a co vyžadují, aby optimalizovali workflow a zvýšili hodnotu svých služeb. Navíc se takto odprostí od svého pohledu a budou muset pracovat jako skutečný tým.

Po krátkém představení formujeme tyto oddělení:

• Business: jehož úkolem je prioritizace úkolů, které potřebujete mít nasazené. A budete hlásit incidenty na Service Desk.
• SCRUM Master / Product Owner: ten je pověřený správou nevyřízených úkolů (Backlog), zajišťuje dohled nad jejich vývojem a kvalitou.
• Development: v organizaci budou hned 2 vývojové týmy, které jsou zodpovědní za development nových funkcí.
• Testování: zde je to jasné, jejich úkolem je kontrola, zda nové funkce, či opravy stávajících aplikací fungují tak, jak mají
• Operations: oddělení pověřené nasazením nových funkcí, údržbou systémů a řešením incidentů
• Service Desk: ten je pověřen správou hlášených incidentů, správou ticketů na kterých se pracuje

Round I.

Plán prvního kola

Všechny týmy dostali jasné instrukce, které si také přečetli před začátkem doručení. A jde se na věc. Po 25 minutách zmatené činnosti, kterou doprovází záplava servisních incidentů (a dodávka nových funkcí) je načase dát si retrospektivu. Co je špatně a proč ten chaos?

Review prvního kola

Business team připustil, že uváděl současně až příliš mnoho nových požadavků do provozu. Product Owner a SCRUM Master nedokázali stanovit priority a sledovat progres vývoje nových funkcí.

Development týmy? Jejich pracovní zátěž byla nerovnoměrně rozložená, chyběli jim jasné priority. Dokonce ani jeden z týmů nevěděl, na čem ten druhý pracuje.

Jeden z týmů dokonce vyvinul funkci na platformě, o které druhý tým věděl, že už nebude dále podporována a tedy i funkční. Fakt, že týmy nekomunikovali nad rámec svého „sila“ znamená pro firmu ztrátu času, i peněz.

Operations tým si nevedl na první pohled špatně. Rozdělil si práci na Release a Incidenty. Každý měl přiřazený svého manažera a práci koordinovali s pomocí Kanban Boardu. Co však už nevěděli, kolik je řešení incidentů stálo v konečném důsledku peněz a největší incident se stejně nepodařilo vyřešit.

Service Desk jako centrální uzel veškerého chaosu je totálně přetížený. Dostává a předává práci bez priorit. Testovací tým nemá až do konce kola defacto vůbec žádnou práci. Trošku na něj ostatní zapomněli.

Shrnutí / závěr 1. kola

Chaos, který provázel celé první kolo se odrazil v analýzách. Podařilo se nasadit pouze 2 ze 7 nových funkcí. A katastroficky dopadly zákaznické transakce, kde se podařilo úspěšně doručit pouze 19 z 96 očekávaných.

Další černé můry z prvního kola

•           Firma vygenerovala pouze 18% očekávaných příjmů

•           5 zákaznických SLA (Service Level Agreement) bylo porušeno

•           Dostupnost byla 81%, výrazně pod 99,9% dostupností, kterou definuje  ITIL

Game Leader TAYLLORCOX zhodnotil výkon 2 body z 10

Round II.

Plán druhého kola

Poučeni z předchozích nezdarů v prvním kole se nyní všechny týmy rozhodli plánovat a vylepšovat. Padají tu návrhy na to, jak se lépe organizovat, efektivněji spolupracovat a dělat svou práci lépe. 

Úkoly se v 1. kole zpracovávaly ve velkých dávkách a posílali k řešení „waterfall“ způsobem, což není zas takový problém. Ale problém je, že mezi „silami“ byla minimální komunikace. 

V tomto kole jsou všichni odhodláni zlepšit komunikaci a řešit potenciální problémy i různá omezení co nejdříve. 

Zástupci Byznysu sdělují, že budou co nejsrozumitelněji komunikovat své cíle, aby bylo možné lépe definovat priority a každý pochopil, proč je jeho práce tak důležitá. 

Product Owner bude definovat akceptační kritéria, aby bylo jasné, jak má doručení produktu vypadat a fungovat. 

Ve spolupráci se SCRUM Masterem bude Product Owner monitorovat veškeré aktivity, incidenty a nové funkce. Budou tak moci včas reagovat na situaci.

Pozor. Došlo k radikální změně ve vývoji. Týmy se sloučili. 

Operations bude tvoři „code repository“, tj. osvědčené postupy, které můžeme v budoucnu znovu využít a dále zlepšovat.

Service Desk dostává posílenou roli, bude svou agendu více sdílet s ostatními tak, aby týmy mohli lépe upřednostňovat řešení incidentů. V plánu je i další automatizace, kterou nasadí před koncem kola. 

Týmy vypadají odhodlaně, ale jak to dopadlo ve skutečnosti?

Review druhého kola

Druhé kolo ukazuje téměř dokonalý příklad J- křivky z ekonomie. Týmy poprvé zkoušejí nové procesy s způsoby práce. A ukazuje se, že to není úplně jednoduché. Přináší to horší výsledky, než se původně očekávalo.

V tom reálném světě, mimo tuto simulaci je přesně toto moment, kdy se organizace vzdávají a dochází k závěru, že DevOps pro ně zkrátka není.

Byznys si je nyní mnohem více vědom toho, jaké potřeby a schopnosti mají jejich týmy a jaké dopady na ně mají byznysová rozhodnutí. 

Plánování je zde jedním z hlavních kamenů úrazu. Takže jednodušší úkoly s nízkou prioritou byly připraveny a nasazeny dřív. Nejdůležitější úkoly, kde se plán připravoval extrémně dlouho se nasadili až jako čtvrté v pořadí. 

SCRUM Master a Product Owner má náročný úkol vše sledovat, což absolutně nestíhá.. Některé položky jim z agendy zmizely a jiné, které sledovali, až později zjistili, že jsou dávno odhlášené a vyřešené. 

Vývoj se snažil přepracovat akceptační kritéria o kterých předpokládal, že jsou špatně. Až později se ukázalo, že pracují se starou verzí dokumentace. 

Operations až nyní zjistil, že byla spuštěna služba, k o které nevěděli a neměli tak informace o tom, že ji musí provozovat.

Asi největší problém nastává u Operations. Ten jaksi „zapomněl“ Byznys informovat, že jeden z incidentů, který snížil výkon serverů byl ve skutečnosti hackerský útok. Takže díky tomu nebyl prioritizován na urgentní řešení.

Shrnutí / závěr 2. kola

Výsledky druhého kola byly jen o něco málo lepší… Pouze 22 z 96 transakcí s klienty se podařilo úspěšně doručit. Rozpočet na nové funkce překročil o 300.000€.  Několik dalších funkcí bylo spuštěno do produkce, ale úzké hrdlo Testovacího týmu je důvod, proč stále nejsou nasazené a funkční.

Game Leader ohodnotil výkon celého týmu 5/10

Round III.

Plán na třetí kolo

V návaznosti na předchozí zkušenosti a problémy se celý tým dohodl se v závěrečném kole co nejvíce zlepšit. Takže přepracoval systém plánování do kontinuálního procesu, včetně stanovení priorit. V případě incidentu musí být vše upřednostněno tomu, co se v současnosti připravuje.

Operations a Test centrum bude aktivně spolupracovat, pánovat a připravovat společně testovací prostředí, ve kterému budou funkce implementovány. Zatímco vývoj se bude co nejvíce automatizovat.

Adaptací Lean technik změníme systém řízení tak, aby jednotlivé týmy na sebe nevytvářeli nátlak, ale spíše spolupracovali a snažili se o hladký chod. Service Desk dostal více pravomocí tak, aby některé činnosti mohl řešit sám.

Během 1. a 2. kola se objevili problémy, které nám ukázali další systémové chyby v řízení a komunikaci. Takže Operations bude pracovat na upgradu služeb, řešit Backlog a nevyřízené požadavky.

Review třetího kola

Jak se týmu dařilo ve 3 kole? Skvěle!

Byznys začal lépe plánovat a určovat priority.

Product Owner se SCRUM Masterem cítili, že věci jsou více pod kontrolou a byli schopni sledovat probíhající práci.

Úzká spolupráce mezi vývojem, testováním a Operations zkrátila revizi požadavků na pouhé jedno přepracovávání.

Pomocí „Code of repository“ se akcelerovali práce na nasazení nových funkcí. Operations získal dostatečný čas na upgrade služeb.

Na Service Desku bylo rušno, ale na druhou stranu nyní měli informace, které potřebují proto, aby hráli svoji klíčovou roli dobře. Včetně toho, že identifikovali opakující se problémy, které by měly být systémově vyřešeny.

Shrnutí / závěr 3. kola

Výsledek 3. kola je oproti předchozím ohromující. Bylo nasazeno obrovské množství nových funkcí. Přitom se dařilo udržet provoz služeb, což vedlo k výnosům 27mil € z maximálních možných 35mil €. 

Analýza ukázala, že vývoj trval sice stejně dlouho, ale výrazně se zkrátil čas na testování. Díky zvýšené produktivitě se funkce začali rychle zobrazovat v pořadí podle priorit a potřeb byznysu. Rychleji se tak dosahovalo ROI (návratnosti investice). 

Game leader ohodnotil výkon celého týmu 9/10 V DevOps je vždy prostor pro zlepšování!

Požádali jsme absolventy, aby vysvětlili, co způsobilo rozdíl mezi prvním a třetím kole. Identifikovali a na Boardu zapsali řadu klíčových DevOps prvků, které si osvojili. Včetně lepšího sdílení informací, budování spolupráce napříč týmy, posílení komunikace, kontinuální plánování. 

Od simulace zpět k realitě 

TAYLLORCOX Game Leader shrnul poznatky DevOps, poukázal na aspekty úspěšné transformace na DevOps, včetně roadmapy úspěšného nasazení. Oproti tradičním způsobům, které jsou v drtivě většině firem zakořeněné přináší DevOps osvědčené postupy, které si můžete i bez znalostí metodiky otestovat a inspirovat i svoji firmu k úspěchu.

Přihlaste se na další kolo DevOps simulace!

DevOps simulace