Jegyzet
Az oldalhoz való hozzáférés engedélyezést igényel. Próbálhatod be jelentkezni vagy könyvtárat váltani.
Az oldalhoz való hozzáférés engedélyezést igényel. Megpróbálhatod a könyvtár váltásá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:
Ö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:
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.