Pokud nechápete, co je DevOps, zde je krátká příručka. DevOps je soubor praktik, které snižují obavy inženýrů a zkracují počet výpadků při vývoji softwaru. Obvykle také zkracují čas uvedení na trh — období od nápadu po dodání konečného produktu zákazníkům, což umožňuje rychle provádět podnikatelské experimenty.
Jak začít DevOps transformaci? Stručně řečeno: vyberte službu, se kterou začneme proces, identifikujeme osoby, které se na službu vztahují, vytvoříme Value Stream Map, vytvoříme dočasný tým, který se bude prvních pár časů zabývat transformací, a stanovením úkolu. Cyklus opakujeme tolikrát, kolikrát je potřeba.
Podrobný plán DevOps transformace s příklady a pokyny je níže — v přepisu Andrej Alexandrov — inženýra ve společnosti Express42, která poskytuje poradenství v oblasti rozvoje DevOps a urychluje tento proces, protože již vytvořila mapu překážek. Pokud si myslíte, že transformaci nepotřebujete, nebo že máte takovou specifikaci, že DevOps praktiky nejsou vhodné, — použijte zprávu jako návod pro nalezení a odstranění překážek.
Pokud máte obavy ohledně otázky DevOps transformace, máte velkou firmu a je potřeba trochu škálovat tento proces na celou strukturu. Dokud existuje potřeba transformovat tým nebo odstranit nějakou překážku, lze níže uvedený algoritmus opakovat.
Výběr služby
Plán je nastíněn, začněme prvním krokem — výběrem služby. První kritérium — životnost: existují staré služby — legacy, a nové. Můžeme začít s oběma.
Je logické vybrat mladou službu. Je nová, dosud není ustálený proces práce v týmu, který se jí zabývá. Kolem ní není hromada technického dluhu, nemusíme ji neustále opravovat. Můžeme s ní dělat, co chceme.
V případě staré služby existují problémy spojené s tím, že změna je vždy obtížná. Již existuje určitý soubor závažných omezení, ale možná se o ně starají lidé, kteří jsou už připraveni vše předělat — unavili se a chtějí něco udělat jinak, protože mají bolesti.
Práce se starou službou vytváří silný precedent ve vaší společnosti — lze něco měnit. Pokud jste změnili novou službu, ta jede na produkci 100krát za hodinu, a všechno je v pořádku, lidé ve vaší společnosti mohou říct:
— To je přece nový servis! Zkuste s naší starou plečkou něco udělat.
Legacy službu má smysl vzít do transformace, když ji děláte s někým, například když pozvete externího konzultanta. Buďme upřímní, transformace otřese vším, co může.. Experimentujete a nevíte, kam dojdete, jaké technologie a proč budete používat, kde a jaké nástrahy v procesech se objeví. Proto je snazší měnit nový.
Pokud všechno děláte sami a ve firmě není silná odborná kompetence — vezměte nový servis. Pokud znáte externího konzultanta a máte prostředky — vyberte starý.
Existují služby, které představují jen rozhraní pro uživatele, například jednoduchá webová stránka nebo mobilní aplikace. Ale jsou zde vážné věci jako billing. Pokud s billingem něco nevyjde — bude obtížné se s tím vyrovnat. I tady máme na výběr.
Pracujeme buď s kritickou službou, ale už kvůli ní trpíme, vytváří omezení, nebo pracujeme s rozhraním. To je druhé kritérium výběru. Analogicky, existuje možnost přizvat zkušeného konzultanta — pracujeme s těžkou variantou.
Ale i v tomto případě bych to nedoporučoval, protože pokud není pochopení s čím pracovat a jakým směrem transformovat, brát kritickou věc a přetřásat ji — není dobrý nápad. Proto v tomto případě preferujeme pracovat s rozhraním, jehož porucha není kritická.
Dále se podíváme na tým služby. S těmi, kdo se touto službou zabývají, budeme muset neustále pracovat a spolupracovat ve velmi úzkém kontaktu.
Lidé v týmu se podmíněně dělí do dvou kategorií: konzervativci — žijí ve starém světě, nebo vůbec nic nevědí o DevOps, a inovátoři, kteří nám předávají všechny moderní praktiky. Druhý ze skupiny si ne vždy rozumí s tématem, ale alespoň jsou na to připraveni.
Na jedné straně konzervativci — zkušení lidé: dlouho ve firmě, rozumí všemu od a do z, ale nevědí, jaké praktiky fungují. Na druhé straně jsou inovátoři, kteří o něčem slyšeli, ale ve firmě pravděpodobně pracují ne příliš dlouho. S kým z nich je lepší spolupracovat?
S konzervativci se budeme muset potýkat, protože to je jejich služba. Budeme s nimi komunikovat, zjišťovat specifika služby, co lze udělat takto a co jinak. Jsme závislí na jejich konzultacích. Určitě budeme muset něco svěřit, protože oni svou službu znají lépe. Proto je důležité, s jakým týmem nakonec budeme mít kontakt.
Je logické vybrat do týmu inovátoři, protože konzervativci mohou nasadit klacek pod nohy.
V praxi se často ukazuje, že konzervativní lidé mají značné zkušenosti, ale nemají představu, jak žít dále. Bojí se, že po transformaci a přepracování služby budou propuštěni. Někdy jen kvůli nedorozumění toho, co se děje, sabotují práci.
Měl jsem případ, kdy kluk z týmu opravoval cokoliv, protože to prý bylo kritičtější než to, co teď děláme. Dáme úkol: realizovat dnes tento úsek — ne, na druhém konci světa hoří, jdeme ho opravovat. S takovými lidmi se těžko pracuje.
Lidé z konzervativního týmu často úkoly zanedbávají, nebo je odkládají na poslední chvíli. A pokud, nedej bože, uděláte chybu a přidělíte jim KPI na základě počtu splněných úkolů, a nějaká část se nějakým způsobem nezahrnuje do KPI, pak nebudou dělat vůbec nic. Vlastně budou mít pravdu, protože pak ztrácejí svou prémii.
S inovátory je to jednodušší — jsou loajálnější.Už o něčem slyšeli, chtějí někam směřovat, takže budou pomáhat. Potřebujeme lidi, kteří jsou ochotni prvních pár měsíců trpět: pokud se mění služba, tak všechny potíže a úskalí zažijí inovátory jako průkopníci. Inovátory chtějí to nejnovější a trendové a vydržet.
Konzervativce pak lze časem přetáhnout na svou víru. Když ukážete, že jste změnili kousek a všechno dobře funguje, pravděpodobně také budou chtít vyzkoušet a přijmou novou DevOps náboženství.
Shrneme to. Pokud provádíme celou transformaci ve společnosti sami, vybíráme: novou službu, ideálně s jednoduchým rozhraním, aby nás moc netrápilo, když se pokazí, a tým inovátorů.
Pokud je možné povolat externího konzultanta, místo nového — vezmeme starou službu, díky které už trpíme. Lidé, kteří se transformacemi zabývali dost dlouho v různých firmách, viděli různé případy a už chápou, jak správně postupovat a jakým směrem se vlastně ubírat.
Kdo je zapojen?
Musíme najít vůbec všechny, kdo mají nějaký vztah k službě: vývojáře, testery, administrátory, bezpečnostní odborníky, manažery a možná i Product Owners. I když Product Owners nejsou technici, vztahují se ke službě: činí rozhodnutí, stanovují úkoly.
Všechny, kteří přijímají jakákoli rozhodnutí a ovlivňují to, co se službou probíhá, je třeba najít, seznámit se s nimi a komunikovat.
Proč jsou nám potřební? Abychom věděli, s kým sjednávat dohody.. Během transformace, kdy se mění obvyklý způsob práce se službou, to bude i tak vždy narušené. Nějakou dobu budou problémy, dokud budeme testovat nové přístupy. Lidé by na to měli být připraveni a s tím souhlasit.
Dále bude třeba postavit Value Stream Map a bez těchto lidí ji nepostavíte, protože pouze oni všichni dohromady znají celkový obraz toho, co se děje. Jeden člověk nikdy neví všechno, co se se službou děje.
Oni doporučí lidi do týmu. Později probereme, proč je potřeba samostatný tým. Do něj bude nutné vzít lidi z existujících oddělení. Ti, kteří mají vztah ke službě, mohou doporučit kolegy, kteří myslí naším směrem, kteří nám mohou pomoci a mají kompetence v tom, co potřebujeme.
Dále shromáždíme všechny tyto lidi z různých oddělení do jedné místnosti a začneme stavět Value Stream Map.
Stavíme Value Stream Map
Value Stream Map — to je diagram nebo mapa, která ukazuje tok hodnoty k zákazníkovi.. To je celý proces od vymýšlení myšlenky až po její realizaci, včetně všech mezistupňů a toho, jak se hodnota nakonec dostává k našim klientům.
Value Stream Map je potřebná k tomu, aby vizualizovala všechny fáze vývoje, lokalizovala problémy pomocí měření, která existují v současném procesu, a začala tyto problémy odstraňovat, a stanovila počáteční cíl. To je místo, kde začneme něco skutečně dělat.
Metriky
V literatuře o Value Stream Map je popsáno mnoho různých metrik, ale pro začátek nám stačí celkem tři.
Lead Time — zpoždění/čekání — doba, kdy na něco čekáme. Například tester čeká, až se uvolní testovací stanoviště, a v této době nemůže nic dělat.
Value Added Time — čas užitečné práce — to, co jsme vynaložili v určité fázi k vytvoření konečné hodnoty pro uživatele. Například tester spustil svůj test a začal něco kontrolovat. To je čas užitečné práce, kdy skutečně něco děláme pro produkt. To je to, za co klienti platí — za kvalitní software.
%C/A — procento přijaté práce. Máme jednu fázi — vývoj, druhou fázi — testování. Kolik funkcionalit testeři přijali od vývojářů, a toto je procento.
Přibližně takto vypadá naše mapa.
Může vypadat jinak v závislosti na struktuře organizace, počtu oddělení a na tom, čemu se věnujete. Ale obecně na mapě budou dvě fáze: myšlenka a analytika. V této fázi se očekávají údaje, například Lead Time 2 týdny a Value Added Time 2 dny.
Metrikami pokrýváme naprosto všechny fáze.
Backlog — kolik úkolů leželo poté, co je analytici vymysleli.
Vývoj — kolik týdnů vývojáři čekali na upřesnění úkolů, stanovišť nebo vybavení — nezáleží na tom, ale něco čekají. Například 4 dny realizují funkcionalitu. Zde se objevuje metrika %C/A. Vývojáři vzali z Backlogu pouze 80 % úkolů. Domnívají se, že pro zbývajících 20 % není dostatečně jasný požadavek, a poslali je k přepracování.
Testování. Na schématu je LT nastaveno na 4 dny. Například testeři čekali na uvolnění testovacího stanoviště, VA 2 dny skutečně testují, a %C/A = 40 %. — pouze 40 % kódu nebo funkcionalit, které poslali vývojáři, testeři považovali za vhodné. Vše ostatní se jim z nějakého důvodu nelíbilo.
Nechci se podrobněji zabývat tím, jak tato měření provádět, na konci článku doporučím literaturu, ze které se o nich můžete dozvědět.
Jedna rada — nevěřte lidem, kteří s vámi budou vytvářet Value Stream Map. Ukazují, kolik času různé procesy zabírají, ale tyto odhady nejsou vždy správné, proto je lepší měřit si to sám.
Měli jsme případ, kdy jsme přišli na oddělení Operations a zeptali jsme se, jak dlouho trvá dodání nové funkce na produkci. Odpověděli nám, že 10 minut, a my jsme si pomysleli, proč jsme vůbec přišli do této společnosti? Ukázalo se, že 10 minut je doba, během které skript bere kód a dodává ho na server. Ale před tímto vydáním leží tři dny na serveru a jen se tam povaluje — v Backlogu leží úkol, který je třeba nasadit. Takže před fází nasazení existuje fáze čekání, kdy projekt jen leží. Kdybychom nešli s blokem, nezachytili úkol v Jira pohledem a nezačali ho sledovat krok za krokem, mysleli bychom, že je vše skvělé a není žádný problém.
Proto bude nutné měření provést sám, ideálně ne jednou, abyste získali co nejrealističtější představu. V závislosti na Value Stream Map budete rozhodovat, odkud začít a co opravit jako první.
Dočasný tým
Mnoho společností, které se rozhodly implementovat DevOps, vytváří tým, ale ne dočasný, nýbrž existující několik let. Pokud se obrátíte na službu DevOps apologize, která popisuje různé vzory budování organizační struktury v DevOps, pochopíte, že to je antipattern.
Když DevOps tým existuje trvale po několik let — je to velká chyba, protože DevOps je o komunikaci mezi odděleními, o rychlosti a efektivitě.
Pokud tým existuje mezi odděleními jen proto, aby něco jiného dělali odděleně a existuje dlouho, vytváří to zbytečnou překážku. Programátorovi nyní místo toho, aby se okamžitě obrátil na administrátora, aby vyřešil problém, musí nejprve kontaktovat oddělení DevOps, které to pak posune dál.
Proto, abyste začali, musíte vytvořit dočasný tým.Bude existovat podmíněně půl roku, maximálně rok, v závislosti na stanoveném úkolu, pouze za účelem odstranění jednoho omezení, které jsme zvolili. Poté zanikne. Pokud zvolíme další bod, kde nás něco silně bolí, a pochopíme, že k tomu také potřebujeme samostatný tým, znovu jej vytvoříme. Ale takové týmy by neměly existovat na "stálém" základě — pak jen narušují komunikaci a přebírají úplně odlišné úkoly, jen aby něco dělaly. Tyto úkoly nemusí být vůbec spojeny s DevOps a transformací. Proč bychom tuto úlohu neměli předat stávajícím oddělením?
Proč je potřeba dočasný tým
Konflikt s aktuálními procesy. Transformace DevOps je změna nejen technologií a nástrojů, které používáme, ale také samotného pracovního procesu, myšlení a hodnot. Pokud bude tým pracovat tak, jak je zvyklý, nebude mít šanci vyzkoušet jiné přístupy.
Tito lidé musí žít podle jiných pravidel: ignorovat všechny KPI ve firmě, protože se snaží pracovat jinak. Dočasné týmy nebudou podávat žádosti o server, ale přímo se obrátí na oddělení, které je spravuje, s požadavkem, aby jim prioritně poskytlo to, co potřebují, protože se jedná o prioritu a protože se snaží žít jinak. Tým má plný konflikt se všemi aktuálními procesy. Aby existující pracovní metody nyní nebránily jim a oni nebránili ostatním, tyto lidi izolujeme a vytvoříme z nich samostatný tým.
Vyhnutí se byrokracii v experimentech. V dočasných týmech neexistuje byrokracie, nevyplňují zprávy o pracovních hodinách, nehlásí se manažerům. To je naprosto oddělený svět, ve kterém lidé žijí a myslí jinak a zabývají se úplně jinými věcmi. Není potřeba je zbytečně rušit.
Nepřetržitá práce na službě. V prvním bodě jsme si zvolili něco, na čem budeme experimentovat. Experimenty a hledání způsobů, jak pracovat lépe, jsou dobré, ale také chceme vyvíjet nové funkce. Pokud se celý tým místo nových funkcí bude zabývat transformací, začneme ztrácet příjmy, chyby dlouho visí — to nechceme. Vytvoření dočasného týmu umožňuje experimentovat, aniž bychom zastavili práci na produktu.
Netrávit čas na pracovní úkoly. Je to opět o produktu. U týmu trvá hodně času vyzkoušet jiné nástroje a další věci. Aby lidé ovládli nástroje, začali je zavádět a používat správně, bude to trvat minimálně půl roku. Pokud se budou také věnovat produktu, těch šest měsíců se neúměrně prodlouží. Když se lidé věnují produktu, opět pracují se starými procesy — to nepotřebujeme.
Proto z různých oddělení vyčleňujeme lidi do samostatného týmu, který se zaměří na transformaci služby. Výsledkem je, že služba funguje, pokračuje ve vývoji a přitom na ní provádíme nějaké experimenty.
Dočasný tým se zabývá pouze DevOps transformací — odstraněním těch omezení, která jsme nalezli, a ničím jiným.
Tým se skládá z univerzálních lidí. To znamená, že jsme nevzali jen vývojáře. Nepřišli jsme do služby a neodnesli odtud půlku týmu — ne, vzali jsme lidi z různých oddělení. Před několika body jsme našli různá oddělení a různé zaměstnance, kteří mají vztah k transformované službě. Z těchto lidí skládáme tým, protože musí být univerzální — změníme jak proces testování, tak proces vývoje a proces údržby služby. Potřebujeme různé kompetence.
Obvykle si vezmeme vývojáře, testera a inženýra — každého po jednom, a společně s nimi vymýšlíme řešení, které umožňuje žít jinak.
Bylo by žádoucí, aby tito lidé měli autoritu v organizaci. Možná bude potřeba vzít jednoho konzervativce, i když se nám to moc nelíbí. Pokud máme velkou firmu, ne všichni uvěří naší myšlence a někteří mohou klást překážky, například nevyčlenit stanoviště. Tady bude potřeba autorita — respektovaná osoba s bohatými zkušenostmi, která si zasloužila dobrý vztah s kolegy. Autorita zaměstnance v týmu usnadní úkol a práci dočasného týmu. Lidé si budou myslet:
— Aha, ten skvělý chlapík, kterého všichni známe a máme rádi, se zapojil — zřejmě je na DevOps něco, co stojí za to vidět!
Stanovujeme cíl
Nashromáždili jsme lidi, vybrali službu, podívali se na omezení, určili, na které lidi máme vliv. Teď je potřeba stanovit cíl a ten by měl být přímo podle SMART — všechno, jak máme rádi.
Specifické — konkrétní.
Měřitelné — měřitelné. To je velmi důležitý bod SMART. Pokud něco nemůžete změřit, nemůžete to změnit a pochopit, co a jak jste udělali lépe či hůře.
Dosažitelné — dosažitelné. Upravte to podle své specifiky. Pokud jste enterprise společnost s dlouhou historií a velkým zatížením povinností, která vydává verzi produktu jednou za rok, nemůžete za půl roku dosáhnout toho, že nové verze produktu budou vycházet každou hodinu. To není možné. Proto si nastavte realistický cíl, který je dosažitelný ve smysluplném časovém rámci.
Relevantní — relevantní. Odstraňujeme pouze to omezení, které skutečně sleduje naše současné cíle.
Časově omezené — časově omezené. Pokud není termín — tým se bude věnovat čemukoli: zkoušení 15 technologií místo 3, psaní obrovských zpráv, provádění zbytečných výzkumů, vylepšování svého provedení do lesku, když už bylo cíle dosaženo.
Cíl formulujeme pomocí Value Stream Map — znovu shromáždíme všechny lidi a nakreslíme. Ale tentokrát na základě předchozí Value Stream Map nakreslíme to, co chceme získat.
Vybereme jedno omezení, které budeme odstraňovat právě teď — tím se tým zabývá. Například jsem vzal čekání od hotového vydání do jeho nasazení do produkce — to je nejčastější omezení, se kterým lidé přicházejí za konzultanty.
Na základě toho stanovíme úkol: chceme, aby čekání mezi hotovým vydáním a akcí bylo maximálně hodinu.
Příklady úkolů.
- Zkrátit dobu testování z 4 dnů na 1 hodinu.
- Zkrátit Value Added Time pro testování z 2 dnů na 3 hodiny.
- Zkrátit dobu nasazení z 5 hodin na 10 minut.
- Zvýšit C/A z 50 % na 95 %, tedy zvýšit počet funkcí, které přijímají testeři, jinými slovy, zlepšit kvalitu práce vývojářů.
Příklady úkolů nejsou odvozeny z nikoho — jsou založeny na měřeních, která jsme provedli, když jsme vyvíjeli Value Stream Map.
Stanovíme podobný úkol našemu týmu a časové omezení. V závislosti na tom, jak dobře to ve vaší společnosti funguje, stanovíte různé termíny. Obecně na odstranění omezení, pokud se tomu lidé věnují poprvé a ještě nevědí, jaké technologie budou konkrétně používat k řešení problému, obvykle trvá půl roku.
Krátké plánování
Takže, náš tým je vytvořen, má cíl a lidé začínají pracovat. Důležitý bod — to je krátké plánování práce: sprinty jedna až dvě týdnya ne déle, měřitelné zlepšení každý týden a úprava směru.
Například často používáme přístup moving-moving, kdy se celý tým sejde na začátku každého týdne, načrtnou do souboru, co každý bude dělat. Po týdnu si zapíšeme: co bylo hotové a co ne, pokud ne, tak proč, a přemýšlíme, co dělat dál.
Sprinty umožňují včas upravit směr.
Týden nebo dva něco zkoušíme: technologie, přístupy, pracovní metody, poté znovu změříte a podíváte se — s tímto přístupem je to lepší nebo horší? Pokud je to horší, znamená to, že jdeme špatným směrem, musíme upravit kurz: stanovit jiný úkol, vzít jinou technologii nebo něco jiného dělat. Krátké sprinty na 1-2 týdny umožňují manévrovat a včas se vyhnout špatným rozhodnutím.
Sdílíme úspěch
Tým dosahuje nějakých úspěchů, malých nebo velkých — na tom nezáleží, vždycky je nějaký výsledek. O tomto výsledku by měli vědět všichni: jak ti, co se podílejí na DevOps, tak sousední oddělení. V ideálním světě je žádoucí, aby to věděli vůbec všichni lidé ve firmě.
Proč? Pokud chceme transformovat nejen část firmy, odstranit ne jedno omezení, ale vše, aby se firma stala flexibilní, kód rychle dorazil k zákazníkovi a nic nepadalo, potřebujeme, aby všichni byli loajální k myšlence DevOps. Nemůžete aplikovat přístup na služby a týmy, které jsou kategoricky proti.
Aby se objevila loajalita, musíme všem říkat, co jsme zkusili — máme výsledek, zkuste také! To zvýší zájem a loajalitu k tomu, co děláme, lidé začnou zkoušet něco dělat hned. Jak ukazuje praxe, když říkáme, co jsme zkusili a čeho jsme dosáhli, ostatní týmy začnou ptát, jak a co jsme udělali. Sledují realizace, kód, dokumentaci, přicházejí s otázkami a snaží se něco změnit u sebe.
Mluvit o tom, co se vám podařilo — je důležité. Tak přesvědčíte přejít do vašeho tábora konzervativců, kteří chtěli všechno dělat po staru, a transformujete je na inovátory.
Celkem
Vybereme službu, jako základní bod — to místo, kde začneme změny ve firmě. Zjišťujeme, kdo má jakýkoliv vztah k službě a spolu s nimi vytváříme Value Stream Map, měříme a sledujeme, kde a jaká jsou omezení.
Zakládáme nový dočasný tým, který se bude zabývat daným úkolem. Na základě měření a Value Stream Map vykreslujeme novou mapu, kde vyčleňujeme to omezení, které budeme řešit. Na základě tohoto omezení stanovujeme úkol, kterému se bude tým věnovat. Úkol musí být nutně SMART — konkrétní, měřitelný, relevantní pro aktuální úkoly a časově ohraničený.
Opakujeme proces, dokud netransformujeme naprosto všechny naše služby do požadovaného stavu a neodstraníme všechna omezení.
Bonus. Užitečné materiály
Pro ty, kteří se rozhodli zabývat se DevOps sami.
Projekt „Fénix“
Originální název — „The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win“. Je to román o DevOps — příběh o tom, jak jednoho zaměstnance jmenovali do vedení oddělení, které neustále hořelo. Novému vedoucímu byla stanovena úloha:
— Máš několik let na to, abys všechno opravil, abychom konečně mohli rychle a efektivně dodávat náš produkt našim zákazníkům.
„Projekt ‘Fénix’. Román o tom, jak DevOps mění život k lepšímu“ — kniha pro všechny vedoucí pracovníky, protože právě tito lidé rozhodují o tom, co se děje ve společnosti. Pokud jste inženýr nebo programátor a chcete, aby ve vaší společnosti začal rozvoj a transformace — kupte knihu a darujte ji vedení. Tento román všechno vysvětluje a čte se rychle a snadno.
Příručka k DevOps
Kniha je složitější. Byla vydána před několika lety v angličtině pod názvem „The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations“, ale nyní je již k dispozici v ruštině. Je to skutečný handbook — praktická příručka: jak provádět měření, co je to Value Stream Map a k čemu slouží, kam se posunout, v jakém pořadí. Kniha je určena pro ty, kteří to chtějí dělat sami. Nejvíce důležité je, že obsahuje příklady zkušeností jiných firem.
Například se zde popisuje, jak jedna společnost vytvořila Value Stream Map a pochopila, že její omezení nespočívá v produktu, ale v tom, že pokladník chodí od obchodu do vedlejší kanceláře, aby tento produkt využil. Místo toho, aby řešili problém se softwarem, jednoduše koupili tablet svým prodejcům, a nyní nikdo nikam nechodí, ale všechny úkony se provádějí na pracovním místě. Výsledek: Value Stream Map lze aplikovat nejen na software, ale také na všechny procesy v organizaci.
Accelerate
Úplný název: „Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations“. Toto je další úroveň — hardcore. Kniha vyšla minulý rok, zatím pouze v angličtině a je o výzkumu. Autoři — Nicole Forsgren, Jez Humble a Gene Kim — po mnoho let aplikovali různé praktiky v různých společnostech a zkoumali, jaké praktiky, jak a na co mají vliv.
V druhé kapitole, která se věnuje měření, se zmiňuje Value Stream Map, metriky, které jsem nazval, a mnoho dalších, a také je podrobně popsán proces měření. Autoři provádějí měření pomocí dotazníků a sledování úkolů. Je podrobně popsáno, jaké metriky správně měřit, které ne, lidské chyby v měřeních. Pokud máte potíže s měřením, obraťte se na druhou kapitolu knihy „Accelerate“. Pokud má vaše tým spoustu praktik, ale není jasné, které aplikovat nyní, které později, které skutečně fungují a které ne — přečtěte si, v knize je to vše popsáno.
Transformace je otázkou na pomezí DevOps a řízení. Kdesi v této oblasti překrývání vývoje, provozu a testování se nacházejí témata, která se snažíme probírat na , stejná integrace je potřebná i pro vytváření kvalitního produktu – hlavního tématu . Řízení na festivalu je k dispozici — znamená, že za myšlenkami pro transformaci všichni tam. Připojte se 27. a 28. května, budeme se integrovat a transformovat.
Zdroj: habr.com
