Seznámení s jazykovou verzí DevOps

Dokončeno

Kultura je základním základem DevOps, protože vyžaduje růst a průběžné učení, aby bylo možné uspět. Podpora vedení je jedním z klíčových prvků úspěchu.

Než probereme, jak vypadá kultura DevOps, podívejme se na roli kultury ve schopnosti organizace přijmout DevOps. Podle Společnosti Gartner:

Kulturní odolnost a nízká úroveň procesní disciplíny vytvoří významné míry selhání pro iniciativy DevOps.

Gene Kim, autor phoenixového projektu a příručky DevOps, říká:

DevOps je cesta plná výzev a jen zřídka jsou tyto výzvy způsobené nesprávnými technologiemi nebo nesprávnými procesy. Největší a nejobtížnější překážky jsou ve skutečnosti kulturní. A pokud dostanete kulturu špatně, i když dostanete všechno ostatní správně, míříte k frustraci, dodatečným nákladům a pravděpodobnému selhání.

Co je kultura?

Pro naše účely je kultura sociálním dědictvím skupiny. Je to vzor zjištěných, vyvinutých nebo vynalezených odpovědí během historie řešení problémů, které vznikají z interakcí mezi členy a mezi nimi a jejich prostředím.

Jazyková verze určuje:

  • Co je přijatelné nebo nepřijatelné.
  • Co je důležité nebo nedůležité.
  • Co je správné nebo špatné.
  • Co je funkční nebo nepůjde.
  • Kdo najměte, vyhodíte a propagujete.

Proč iniciativy DevOps selžou?

Výzkum společnosti Apple ukazuje, že až do roku 2023 selže 90 % iniciativ DevOps z důvodu omezení přístupů správy používaných vedením.

Důležité

Hlavní odpovědností vedení je vytvoření prostředí, které umožňuje úspěšnou kulturu DevOps.

Lidé, kteří pracují v kreativních úsilích, nepotřebují "pivo v přestávkové místnosti", aby je motivovaly. Kreativní lidé místo toho potřebují zvládnutí, autonomii a účel.

Když se lidé ptají, co je nejdůležitější součástí úspěchu Microsoftu – je to vize, strategie nebo provádění? – Generální ředitel Microsoftu Satya Nadella řekl, že jsou všichni důležití, ale nakonec to byl jejich účel a růst myšlení.

12 příkladů myšlení DevOps

Tady je 12 příkladů myšlení DevOps: vedení myšlení, zaměření zákazníků, štíhlé myšlení, systémové myšlení, odstranění plýtvání, teorie omezení, zarovnání a autonomie, testování posunu doleva, zabezpečení myšlení, vývoj založený na hypotézách, živé weby a měření výsledků, ne myšlení aktivit.

Vedení myšlení

SpolečnostVádí následující doporučení:

  • Identifikujte transformační vedoucí pracovníky tím, že upřednostníte konkrétní charakteristiky chování nezbytné k vedení iniciativy DevOps, čímž se méně zvýrazní technické dovednosti.
  • Vyvinout transformační vedoucí pracovníky přijetím selhání jako příležitost učení.
  • Spravujte transformační vedoucí pracovníky tím, že jim umožníte rozhodovat se bez druhého odhadu a poskytnutím jasných cílů a klíčových metrik.

Vzhledem k tomu, že DevOps je transformativní, musí vedoucí pracovníci infrastruktury a provozu (I&O) identifikovat kandidáty, kteří jsou vizionáři, adaptivní, motivující, posílení a odpovědnost.

Myšlení zaměřené na zákazníky

Co znamená být zaměřeno na zákazníky?

  • Poslech a komunikace s našimi zákazníky
  • Měření, co je důležité
  • Obejmout červenou v produkčním prostředí
  • Sestavování, měření a učení
  • Použití přepínání funkcí pro řádné nasazení
  • Shromažďování dat v širokém rozsahu, ale pečlivě

Štíhlá mysl

Hodnota: Štíhlá mysl začíná podrobným porozuměním, jakou hodnotu zákazník přiřazuje k produktům a službám. Organizace se zaměřuje na odstranění plýtvání, aby zákazník mohl zajistit hodnotu, kterou zákazník očekává na nejvyšší úrovni ziskovosti.

Datový proud hodnot zahrnuje celý životní cyklus produktu, od surovin prostřednictvím použití zákazníka a případného odstranění produktu. Aby se zabránilo plýtvání, konečným cílem Leanu, musí být přesné a úplné pochopení hodnotového toku.

Tok: Pochopení toku je nezbytné k odstranění plýtvání. Pokud se datový proud hodnot v libovolném okamžiku zastaví, odpad je nevyhnutelné podle produktu. Princip štíhlé výroby toku spočívá v vytváření hodnotového řetězce bez přerušení výrobního procesu a toho, kde každá aktivita probíhá krok s ostatními.

Pull: Štíhlý princip přijetí změn pomáhá zajistit tok tím, že zajistí, že se nic předem neprovedou, což vytvoří inventář pracovních procesů a zastaví synchronizovaný tok. Místo použití tradičního amerického výrobního přístupu, který je založený na prognóze a plánu, přístup k přijetí změn určuje, že se nic neprodá, dokud si ho zákazník objednává.

Dokonalost: Štíhlé praktičtí lékaři se snaží dosáhnout dokonalosti. Pochod směrem k dokonalému procesu se stává, protože průběžné vylepšování řeší původní příčiny problémů s kvalitou a plýtvání výrobou. Nechtěná snaha o dokonalost je to, co vede uživatele k hlubšímu prozkoumání, měření více a změnám častěji než jejich konkurenti.

Myšlení na systém

Systémový myšlení zdůrazňuje výkon celého systému, nikoli výkon určitého sila práce nebo oddělení.

Zaměřte se na všechny datové proudy obchodních hodnot, které jsou povolené IT. Jinými slovy, začíná, když jsou požadavky identifikovány firmou nebo IT integrovaným vývojem a pak se přenesou na IT operace, kde se hodnota pak doručí zákazníkovi jako služba.

Odstranění plýtvání myšlením

Štíhlá mysl se zaměřuje na identifikaci a odstranění sedmi smrtelných plýtvání, které nejsou pro zákazníka hodnotné:

  • Částečně dokončená práce
  • Další proces
  • Další funkce
  • Přepínání úkolů
  • Čekání
  • Pohybu
  • Vady

Teorie myšlení omezení

Teorie omezení je metodologie pro identifikaci a odstranění omezení (označovaných také jako kritické body), které omezují propustnost. V praxi začněte identifikací nejdůležitějšího faktoru, který představuje způsob dosažení cíle. Pokud chcete tento faktor minimalizovat, dokud se už nejedná o limitující faktor.

Diagram depicts the Theory of constraints: identify the constraint, exploit it, subordinate & synchronize to it, elevate the performance of the constraint, repeat the process

Vyvážení sladění a autonomií myslí

Je nutné dosáhnout rovnováhy mezi sladěním a autonomií. Příliš mnoho sladění vede k menším inovacím, menší motivaci a menší spolupráci. Příliš mnoho autonomie vede k většímu chaosu, zmatení a konfliktu, a zároveň vede k menší konzistenci.

Diagram explains aligned autonomy: if you get the organization, roles, teams, cadence, and architecture in alignment, then the plans and practices can function autonomously.

Testování myšlení s posunem doleva

Testování posunu doleva je přístup, který se používá k urychlení testování softwaru a usnadnění vývoje přesunutím procesu testování do dřívějšího bodu vývojového cyklu. Posun doleva je odkaz na přesunutí testování doleva na časové ose. Pomáhá vytvářet kvalitu a identifikovat problémy dříve, aby se snížil objem práce.

Testování s posunem doleva je navržené tak, aby bylo lepším modelem pro rychlý vývoj v pruhu, protože tradiční testovací modely, které čekají na pozdější fázi vývojového cyklu, můžou vývoj kritickým bodem.

Zabezpečení myšlení

Aby bylo dosaženo zabezpečení myšlení, týmy musí:

  • Zvyšte povědomí.
  • Definujte jejich zásady.
  • Žít podle jejich zásad.

Myšlení vývoje řízené hypotézou

Použití přístupu Štíhlého produktu k vývoji v kratších cyklech a použití vývoje založeného na hypotézách pomáhá vytvářet malé experimenty, které nám pomůžou získat zpětnou vazbu od našich zákazníků a rozhodnutí řízených daty.

Přístup založený na hypotézách:

  • Začíná z předpokladu – něco přijatého jako pravda bez důkazu
  • Vyjadřuje předpoklad, že se má testovat.
  • Provádí experimentování a testování.
  • Zkoumá důkazy – ukazatel výsledku

Live-site mindset

Pro tým DevOps neexistuje žádné místo, jako je produkce. Všechno, co dělají, je lepší prostředí zákazníků.

Pokud chcete vytvořit stabilní vysoce výkonnou lokalitu, využijte osvědčené postupy průběžného provozu v disciplíně a průběžném způsobu, jak udržovat lokalitu v pořádku.

Mezi klíčové faktory naší kultury živého webu patří:

  • Zjištění před tím, než zákazníci cítí bolest
  • Jednotka s daty
  • Hlavní příčinou je klíč.
  • Konfigurace jako kódu
  • Automatizovat a přežít
  • Buďte otevřeni a učit se

Měření výsledku, nikoli myšlení aktivit

Způsob, jakým měříte lidi, povede to, jak se lidé chovají. Měli byste měřit využití, rychlost a stav živého webu, ne řádky kódu, vypálení týmu a počet nalezených chyb.

Tip

Buďte opatrní s měřením, abyste mohli dosáhnout optimálního výsledku!