Megosztás:


Hogyan tervezi a Microsoft a DevOps-t?

A Microsoft a világ egyik legnagyobb vállalata, amely Agilis módszereket használ. A Microsoft több éves tapasztalata során kifejlesztett egy DevOps-tervezési folyamatot, amely a legkisebb projektektől kezdve a Windowshoz hasonló hatalmas erőfeszítéseken keresztül skálázható. Ez a cikk a Microsoft által a vállalaton belüli szoftverprojektek tervezése során alkalmazott számos tanulságot és gyakorlatot ismerteti.

Lényeges változások

Az alábbi főbb módosítások segítenek a fejlesztési és szállítási ciklusok egészségesebbé és hatékonyabbá tétele:

  • A kulturális igazodás és az autonómia előmozdítása.
  • Fókusz váltása egyénekről csapatokra.
  • Új tervezési és tanulási stratégiák létrehozása.
  • Többfős modell implementálása.
  • A kódminőségi gyakorlatok javítása.
  • Az átláthatóság és az elszámoltathatóság előmozdítása.

A kulturális igazodás és az autonómia előmozdítása

Peter Drucker azt mondta: "A kultúra stratégiát eszik reggelire." Az autonómia, a mesterség és a cél kulcsfontosságú emberi motiváció. A Microsoft megpróbálja biztosítani ezeket a motiváló tényezőket a projektmenedzsereknek, fejlesztőknek és tervezőknek, hogy képessé váljanak sikeres termékek létrehozására.

Ennek a megközelítésnek két fontos közreműködője az összehangolás és az autonómia.

  • Az igazítás felülről lefelé érkezik, hogy az egyének és a csapatok megértsék, hogyan igazodnak feladataik a szélesebb körű üzleti célokhoz.
  • Az autonómia alulról felfelé történik, hogy az egyének és a csapatok hatással legyenek a mindennapi tevékenységekre és döntésekre.

Kényes egyensúly van az összehangolás és az autonómia között. A túlzott összehangolás negatív kultúrát hozhat létre, ahol az emberek csak azt teszik, amit mondanak nekik. A túl sok autonómia a struktúra vagy irány hiányát, a nem hatékony döntéshozatalt és a rossz tervezést okozhatja.

Fókusz módosítása egyénekről csapatokra

A Microsoft három csoportba szervezi a személyeket és a csapatokat: pm, design és engineering.

  • A PM meghatározza, hogy mit és miért készít a Microsoft.
  • "A tervezőcsapat a Microsoft konstrukcióinak megtervezéséért felelős."
  • A mérnöki munka fejleszti a termékeket, és biztosítja azok minőségét.

A Microsoft-csapatok a következő főbb jellemzőkkel rendelkeznek:

  • Keresztdiszciplináris
  • 10-12 fő
  • Önálló menedzsment
  • Világos charta és célok 12-18 hónapra
  • Fizikai csapatszobák
  • Saját szolgáltatás üzembe helyezése
  • Éles környezetben saját funkciók

Függőleges csapatokra való törekvés

A Microsoft-csapatok korábban vízszintesek, lefedve az összes felhasználói felületet, az összes adatot vagy az összes API-t. A Microsoft most a vertikális csapatokra törekszik. A csapatok teljes egészében a termék területeiért felelnek. Bizonyos szintek szigorú irányelvei biztosítják a csapatok közötti egységességet a terméken belül.

Az alábbi diagram a vízszintes és a függőleges csapatok közötti különbséget foglalja össze:

Vízszintes és függőleges csapatstruktúrát ábrázoló diagram.

Önkiválasztási csapatok engedélyezése

A Microsoft körülbelül 18 havonta futtat egy "sárga öntetes gyakorlatot", ahol a fejlesztők kiválaszthatják, hogy a termék mely területein szeretnének dolgozni a következő néhány tervezési időszakban. Ez a gyakorlat önállóságot biztosít, mivel a csapatok kiválaszthatják, hogy min dolgoznak, és a szervezeti igazítás elősegíti az egyensúlyt a csapatok között. Az ebben a gyakorlatban részt vett személyek közül körülbelül 80% marad a jelenlegi csapatában, de úgy érzik, hogy nekik van választási lehetőségük.

Új tervezési és tanulási stratégiák létrehozása

Dwight Eisenhower azt mondta: "A tervek értéktelenek, de a tervezés minden." A Microsoft tervezése a következő struktúrára bontható:

  • Sprintek (3 hét)
  • Tervek (3 futam)
  • Évszakok (6 hónap)
  • Stratégiák (12 hónap)

A mérnökök és a csapatok többnyire a sprintekért és a tervekért felelősek. A vezetőség elsősorban az évszakokért és a stratégiákért felelős.

Az alábbi ábra a Microsoft tervezési stratégiáját mutatja be:

A Microsoft tervezési stratégiáját bemutató ábra.

Ez a tervezési struktúra a tervezés során is segít maximalizálni a tanulást . A Teams gyorsan és hatékonyan kaphat visszajelzést, megtudhatja, hogy mit szeretnének az ügyfelek, és gyorsan és hatékonyan implementálhatja az ügyfélkéréseket.

Többfős modell implementálása

A korábbi módszerek elősegítették egy olyan "megszakítási kultúra" kialakulását, amelyet a hibák és az élő webhely incidensek jellemeztek. A Microsoft csapatai saját módszert hoztak létre a fókusz biztosításához és a zavaró tényezők elkerüléséhez. A csapatok önállóan szerveződnek minden egyes sprintre két különálló csapatra: Funkciók (F-csapat) és Ügyfél (C-csapat).

Az F-legénység elkötelezett funkciókon dolgozik, és a C-legénység élő helyszínekkel kapcsolatos problémákkal és megszakításokkal foglalkozik. A csapat egy forgó ütemet hoz létre, amely lehetővé teszi a tagok számára a tevékenységek egyszerűbb megtervezését. A többfős modellről további információt a hatékony, ügyfélközpontú csapatok létrehozása című témakörben talál.

A kódminőséget javító gyakorlatok fejlesztése

Az Agile-módszertanra való váltás előtt a csapatok a kódhibák kiépítését tették lehetővé, amíg a kód a fejlesztési fázis végén be nem fejeződött. A Teams ezután észlelte a hibákat, és dolgozott rajtuk. Ez a gyakorlat a hibák hullámvasútját hozta létre, ami hatással volt a csapat moráljára és termelékenységére, amikor a csapatoknak hibajavításokon kellett dolgozniuk az új funkciók implementálása helyett.

A Teams most implementál egy hibakorlátot, amelyet a képlet # of engineers x 5 = bug capszámít ki. Ha egy csapat hibáinak száma meghaladja a futam végén lévő hibakorlátot, le kell állítaniuk az új funkciókon való munkát, és ki kell javítaniuk a hibákat, amíg a korlátjuk alá nem kerülnek. A csapatok most már folyamatosan csökkentik a hibatartozást.

Az átláthatóság és az elszámoltathatóság előmozdítása

Minden egyes futam végén minden csapat e-mailt küld arról, hogy mit ért el az előző futamban, és mit terveznek a következő futamban.

Célkitűzések és fő eredmények (OKRs)

A csapatok akkor a leghatékonyabbak, ha tisztában vannak a szervezet által elérni kívánt célokat. A Microsoft a célkitűzések és a fő eredmények (OKRs) révén egyértelművé teszi a csapatokat.

  • A célkitűzések határozzák meg az elérendő célokat. A célkitűzések jelentősek, konkrétak, cselekvésorientáltak, és ideális esetben inspiráló szándéknyilatkozatok. A célkitűzések a nagy ötleteket jelölik, nem pedig a tényleges számokat.
  • A fő eredmények meghatározzák a célkitűzések eléréséhez szükséges lépéseket. A fő eredmények számszerűsíthető eredmények, amelyek értékelik az előrehaladást, és egy adott időszakban a célkitűzésekhez viszonyított sikert jelzik.

Az OKR-ek a lehető legjobb eredményeket tükrözik, nem csak a legvalószínűbb eredményeket. A vezetők ambiciózusak és nem óvatosak. A csapatoknak a kihívást jelentő fő eredmények elérésére való kényszerítése felgyorsítja a célkitűzéseket, és rangsorolja a nagyobb célok felé irányuló munkát.

Az OKR-keretrendszer bevezetése segíthet a csapatoknak a jobb teljesítményben az alábbi okokból:

  • Minden csapat igazodik a tervhez.
  • A csapatok a tevékenységek befejezése helyett az eredmények elérésére összpontosítanak.
  • Minden csapat rendszeresen felelős az erőfeszítésekért.

Az OKR-ek a termék különböző szintjein létezhetnek. Lehetnek például felső szintű termék OKR-k, összetevőszintű OKR-k és csapatszintű OKR-ek. Az OKR-ek igazítása viszonylag egyszerű, különösen akkor, ha a célkitűzések felülről lefelé vannak állítva. A felmerülő ütközések értékes korai mutatói a szervezeti eltérésnek.

OKR-példa

Célkitűzés: Erős és boldog ügyfélbázis létrehozása.

Főbb eredmények:

  • Növelje a külső nettó előléptetési pontszámot (NPS) 21-ről 35-re.
  • A dokumentumok elégedettségének növelése 55-ről 65-re.
  • Az új folyamat Apdex index pontszáma 0,9.
  • A feladatok várakozási ideje legfeljebb 5 másodperc.

Az OKR-ekkel kapcsolatos további információkért lásd: Üzleti eredmények mérése célkitűzések és fő eredmények használatával.

Válassza ki a megfelelő metrikákat

A kulcseredmények csak annyira hasznosak, mint a metrikák, amelyeken alapulnak. A Microsoft olyan vezető mutatókat használ, amelyek a változásra összpontosítanak. Ezek a metrikák idővel munkaképet készítenek a termék gyorsításáról vagy lassulásáról. A Microsoft gyakran a következő metrikákat használja:

  • A bevezetés havi növekedési ütemének változása
  • Teljesítménybeli változás
  • A tanuláshoz való idő módosítása
  • Az incidensek gyakoriságának változása

A csapatok elkerülik azokat a metrikákat, amelyek nem gyűjtenek értéket a célkitűzések felé. Bár lehetnek bizonyos felhasználási módjaik, a következő metrikák nem hasznosak a célkitűzések felé irányuló előrehaladás nyomon követéséhez:

  • Az eredeti becslések pontossága
  • Befejezett órák
  • Kódsorok
  • Csapatkapacitás
  • Csapatleégés
  • Csapat sebessége
  • A talált hibák száma
  • Kódlefedettség

Agile előtt és után Agile

Az alábbi táblázat összefoglalja a Microsoft fejlesztői csapatainak az Agile-gyakorlatok elfogadása során végrehajtott módosításait.

Előtte Utána
4–6 hónapos mérföldkövek 3 hetes futamok
Vízszintes csapatok Függőleges csapatok
Személyes irodák Csapatszobák és távoli munka
Hosszú tervezési ciklusok Folyamatos tervezés és tanulás
Projektmenedzser (PM), Fejlesztő (Dev) és Tesztelő (Test) PM, tervezés és mérnöki munka
Éves ügyfélkapcsolat Folyamatos ügyfélkapcsolat
Szolgáltatáságak Mindenki a főágban dolgozik
20 fős csapatok 8-12 fős csapatok
Titkos ütemterv Nyilvánosan megosztott ütemterv
Hiba felhalmozódás Nulla adósság
100 oldalas specifikációs dokumentumok PowerPoint-specifikációk
Privát adattárak Nyílt forráskódú vagy InnerSource
Mély szervezeti hierarchia Egybesimított szervezeti hierarchia
A telepítési számok határozzák meg a sikert A felhasználói elégedettség határozza meg a sikert
Szolgáltatások hajó évente egyszer A funkciók minden sprintben kiadásra kerülnek

Főbb elvitelek

  • Vegye komolyan az agilis tudományt, de ne legyen túlságosan előíró. Az agilis túl szigorú lehet. Hagyja, hogy az Agilis gondolkodásmód és kultúra növekedjen.
  • Az eredményeket ünnepelje, ne a tevékenységet. A funkciók üzembe helyezése meghaladja a kódsorokat.
  • Minden futamon szállítson, hogy ritmust és ütemet alakítson ki, és megtalálja az összes szükséges munkát.
  • Alakítson ki olyan kultúrát, amellyel elérheti a kívánt viselkedést.