DevOps: od simulácie k realite za 1 deň

Samotný priebeh DevOps simulácie

Tento intenzívny 1 denný workshop využíva reálne scenáre a učenia sa pomocou pochopenia pozitívnych vplyvov metodiky v každodenných situáciách. Zameriava sa na kultúru organizácie, interné i externé pracovníkov a procesy.

Dokonale Nasimulujeme vaše pracovné "flow" v organizácii. Nie je nutná predchádzajúca znalosť DevOps. V rámci dňa absolvujete 3 kolá. V nich sa zameriate na plánovanie, dodávku a kontrolu produktov a služieb. Poďme sa spoločne vydať na prvý krok k transformácii na DevOps.

Budete pracovať pre imaginárny organizáciu, ktorý má za úlohu implementovať nové funkcie do online systémov a zároveň spravovať životne dôležité systémy, ktoré spracovávajú transakcie so zákazníkmi.

Samotný vývoj aplikácií nie je súčasťou hry. Development prebieha len v digitálnych aplikáciách na manažérskej úrovni. Rovnako tak riešenie incidentov a ďalších operácií prebieha v simulátore - digitálnej aplikáciu, ktorá je cloudu.

Avšak výstupy z vašich manažérskych rozhodnutí sú zbierané do softvérovej aplikácie, ktorá zobrazuje online Dashboard a monitoruje vývoj aj dodávky v každom kole.

Nastavuje servisné incidenty a poskytuje dostatok informácií pre analýzu vašich krokov. Tieto reporty sú na konci každého kola vyhodnotené a následný rozbor sa sústredí na praktické tipy, ako s pomocou DevOps pracovať efektívnejšie, lepšie.

Ako celá simulácia prebiehala a čo na to hovoria absolventi? Podarilo sa odbúrať kultúrne i firemné bariéry okolo prechodu na DevOps?

Ideme formovať tím!

V simulácii rozdeľujeme manažérov do tímov, ktoré kopírujú organizačné rozdelenie. Nájdete tak tu všetko, čo potrebujete pre fungovanie každá organizácia: management, softvér inžinierov, Operations management a pracovníkmi DevOps.

Čo robí celú simuláciu ešte atraktívnejšie je fakt, že každý manažér dostane inú úlohu, než tú, ktorú bežne v organizácii zastáva.

V princípe nám ide o to, aby delegáti dostali šancu pochopiť výzvy a problémy, s ktorými ich kolegovia bojujú a čo vyžadujú, aby optimalizovali workflow a zvýšili hodnotu svojich služieb. Navyše sa takto odprostí od svojho pohľadu a budú musieť pracovať ako skutočný tím.

Po krátkom predstavení formujeme tieto oddelenia:

• Business: ktorého úlohou je prioritizácia úloh, ktoré potrebujete mať nasadené. A budete hlásiť incidenty na Service Desk.
• SCRUM Master / Product Owner: ten je poverený správou nevybavených úloh (Backlog), zabezpečuje dohľad nad ich vývojom a kvalitou.
• Development: v organizácii budú hneď 2 vývojové tímy, ktoré sú zodpovední za development nových funkcií.
• Testovanie: tu je to jasné, ich úlohou je kontrola, či nové funkcie, či opravy existujúcich aplikácií fungujú tak, ako majú
• Operations: oddelenie poverené nasadením nových funkcií, údržbou systémov a riešením incidentov
• Service Desk: ten je poverený správou hlásených incidentov, správou ticketov na ktorých sa pracuje

Round I.

Plán prvého kola

Všetky tímy dostali jasné inštrukcie, ktoré si tiež prečítali pred začiatkom doručenia. A ide sa na vec. Po 25 minútach zmätené činnosti, ktorú sprevádza záplava servisných incidentov (a dodávka nových funkcií) je načase dať si retrospektívu. Čo je zle a prečo ten chaos?

Review prvého kola

Business team pripustil, že uvádzal súčasne až príliš veľa nových požiadaviek do prevádzky. Product Owner a SCRUM Master nedokázali stanoviť priority a sledovať progres vývoja nových funkcií.

Development tímy? Ich pracovná záťaž bola nerovnomerne rozložená, chýbali im jasné priority. Dokonca ani jeden z tímov nevedel, na čom ten druhý pracuje.

Jeden z tímov dokonca vyvinul funkciu na platforme, o ktorej druhý tím vedel, že už nebude ďalej podporovaná a teda aj funkčné. Fakt, že tímy nekomunikovali nad rámec svojho "silá" znamená pre firmu stratu času, i peňazí.

Operations tím si neviedol na prvý pohľad zle. Rozdelil si prácu na Release a Incidenty. Každý mal priradený svojho manažéra a prácu koordinovali s pomocou Kanban Boardu. Čo však už nevedeli, koľko je riešenie incidentov stálo v konečnom dôsledku peňazí a najväčší incident sa rovnako nepodarilo vyriešiť.

Service Desk ako centrálny uzol všetkého chaosu je totálne preťažený. Dostáva a odovzdáva prácu bez priorít. Testovací tím nemá až do konca kola defacto vôbec žiadnu prácu. Trošku na neho ostatní zabudli.

Zhrnutie / záver 1. kola 

Chaos, ktorý sprevádzal celé prvé kolo sa odrazil v analýzach. Podarilo sa nasadiť iba 2 zo 7 nových funkcií. A katastroficky dopadli zákaznícke transakcie, kde sa podarilo úspešne doručiť iba 19 z 96 očakávaných.

Ďalšie čierne mory z prvého kola

• Firma vygenerovala iba 18 % očakávaných príjmov

• 5 zákazníckych SLA (Service Level Agreement) bolo porušené

• Dostupnosť bola 81 %, výrazne pod 99,9 % dostupnosťou, ktorú definuje ITIL

Game Leader TAYLLORCOX zhodnotil výkon 2 body z 10

Round II.

Poučení z predchádzajúcich nezdarov v prvom kole sa teraz všetky tímy rozhodli plánovať a vylepšovať. Padajú tu návrhy na to, ako sa lepšie organizovať, efektívnejšie spolupracovať a robiť svoju prácu lepšie.

Úlohy sa v 1. kole spracovávali vo veľkých dávkach a posielali k riešeniu "waterfall" spôsobom, čo nie je zas taký problém. Ale problém je, že medzi "silami" bola minimálna komunikácie.

V tomto kole sú všetci odhodlaní zlepšiť komunikáciu a riešiť potenciálne problémy aj rôzne obmedzenia čo najskôr.

Zástupcovia Biznisu oznamujú, že budú čo najzrozumiteľnejšie komunikovať svoje ciele, aby bolo možné lepšie definovať priority a každý pochopil, prečo je jeho práca tak dôležitá.

Product Owner bude definovať akceptačné kritériá, aby bolo jasné, ako má doručenie produktu vyzerať a fungovať.

V spolupráci so SCRUM Masterom bude Product Owner monitorovať všetky aktivity, incidenty a nové funkcie. Budú tak môcť včas reagovať na situáciu.

Pozor. Došlo k radikálnej zmene vo vývoji. Tímy sa zlúčili.

Operations bude tvori "code repository", tj. Osvedčené postupy, ktoré môžeme v budúcnosti znovu využiť a ďalej zlepšovať.

Service Desk dostáva posilnenú úlohu, bude svoju agendu viac zdieľať s ostatnými tak, aby tímy mohli lepšie uprednostňovať riešenie incidentov. V pláne je aj ďalšia automatizácia, ktorú nasadia pred koncom kola.

Tímy vyzerajú odhodlane, ale ako to dopadlo v skutočnosti?

Review druhého kola

Druhé kolo ukazuje takmer dokonalý príklad J- krivky z ekonómie. Tímy prvýkrát skúšajú nové procesy s spôsoby práce. A ukazuje sa, že to nie je úplne jednoduché. Prináša to horšie výsledky, než sa pôvodne očakávalo.

V tom reálnom svete, mimo túto simuláciu je presne toto moment, kedy sa organizácia vzdávajú a dochádza k záveru, že DevOps pre nich skrátka nie je.

Biznis si je teraz oveľa viac vedomý toho, aké potreby a schopnosti majú ich tímy a aké dopady na ne majú biznisová rozhodnutia.

Plánovanie je tu jedným z hlavných kameňov úrazu. Takže jednoduchšie úlohy s nízkou prioritou boli pripravené a nasadené skôr. Najdôležitejšie úlohy, kde sa plán pripravoval extrémne dlho sa nasadili až ako štvrté v poradí.

SCRUM Master a Product Owner má náročnú úlohu všetko sledovať, čo absolútne nestíha .. Niektoré položky im z agendy zmizli a iné, ktoré sledovali, až neskôr zistili, že sú dávno odhlásené a vyriešené.

Vývoj sa snažil prepracovať akceptačná kritéria o ktorých predpokladal, že sú zle. Až neskôr sa ukázalo, že pracujú so starou verziou dokumentácie.

Operations až teraz zistil, že bola spustená služba, k o ktoré nevedeli a nemali tak informácie o tom, že ju musí prevádzkovať.

Asi najväčší problém nastáva u Operations. Ten akosi "zabudol" Biznis informovať, že jeden z incidentov, ktorý znížil výkon serverov bol v skutočnosti hackerské útoky. Takže vďaka tomu nebol prioritný na urgentnú riešenie.

Zhrnutie / záver 2. kola

Výsledky druhého kola boli len o niečo málo lepší ... Iba 22 z 96 transakcií s klientmi sa podarilo úspešne doručiť. Rozpočet na nové funkcie prekročil o 300.000 €. Niekoľko ďalších funkcií bolo spustené do produkcie, ale úzke hrdlo Testovacieho tímu je dôvod, prečo stále nie sú nasadené a funkčné.

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

Round III.

Plán na tretie kolo

V nadväznosti na predchádzajúce skúsenosti a problémy sa celý tím dohodol sa v záverečnom kole čo najviac zlepšiť. Takže prepracoval systém plánovania do kontinuálneho procesu, vrátane stanovenia priorít. V prípade incidentu musí byť všetko uprednostnené tomu, čo sa v súčasnosti pripravuje.

Operations a Test centrum bude aktívne spolupracovať, pánovi a pripravovať spoločne testovacie prostredie, vo ktorému budú funkcie implementované. Kým vývoj sa bude čo najviac automatizovať.

Adaptáciou Lean techník zmeníme systém riadenia tak, aby jednotlivé tímy na seba nevytvárali nátlak, ale skôr spolupracovali a snažili sa o hladký chod. Service Desk dostal viac právomocí tak, aby niektoré činnosti mohol riešiť sám.

Počas 1. a 2. kola sa objavili problémy, ktoré nám ukázali ďalšie systémové chyby v riadení a komunikácii. Takže Operations bude pracovať na upgradu služieb, riešiť Backlog a nevybavené požiadavky.

Review tretieho kola

Ako sa tímu darilo v 3 kole? Skvele!

Biznis začal lepšie plánovať a určovať priority.

Product Owner sa SCRUM Masterom cítili, že veci sú viac pod kontrolou a boli schopní sledovať prebiehajúcu prácu.

Úzka spolupráca medzi vývojom, testovaním a Operations skrátila revíziu požiadaviek na obyčajné jedno rekodifikácie.

Pomocou "Code of repository" sa akcelerovali práca na nasadenie nových funkcií. Operations získal dostatočný čas na upgrade služieb.

Na Service Dosku bolo rušno, ale na druhú stranu teraz mali informácie, ktoré potrebujú preto, aby hrali svoju kľúčovú úlohu dobre. Vrátane toho, že identifikovali opakujúce sa problémy, ktoré by mali byť systémovo vyriešené

Zhrnutie / záver 3. kola

Výsledok 3. kola je oproti predchádzajúcim ohromujúci. Bolo nasadených obrovské množstvo nových funkcií. Pritom sa darilo udržať prevádzku služieb, čo viedlo k výnosom 27mil € z maximálnych možných 35mil €.

Analýza ukázala, že vývoj trval síce rovnako dlho, ale výrazne sa skrátil čas na testovanie. Vďaka zvýšenej produktivite sa funkcie začali rýchlo zobrazovať v poradí podľa priorít a potrieb biznisu. Rýchlejšie sa tak dosahovalo ROI (návratnosti investície).

Game leader ohodnotil výkon celého tímu 9/10 V DevOps je vždy priestor na zlepšovanie!

Požiadali sme absolventov, aby vysvetlili, čo spôsobilo rozdiel medzi prvým a treťom kole. Identifikovali a na Boardu zapísali rad kľúčových DevOps prvkov, ktoré si osvojili. Vrátane lepšieho zdieľania informácií, budovanie spolupráce naprieč tímami, posilnenie komunikácie, kontinuálne plánovanie.

Od simulácie späť k realite 

TAYLLORCOX Game Leader zhrnul poznatky DevOps, poukázal na aspekty úspešnej transformácie na DevOps, vrátane cestnej mapy úspešného nasadenia. Oproti tradičným spôsobom, ktoré sú v drvivej väčšine firiem zakorenené prináša DevOps osvedčené postupy, ktoré si môžete aj bez znalostí metodiky otestovať a inšpirovať aj svoju firmu k úspechu.

Prihláste sa na ďalšie kolo DevOps simulácie!

DevOps simulácie