Az Agile méretezése nagy csapatokra

A nagy és az agilis szavakat gyakran nem használják ugyanabban a mondatban. A nagy szervezetek kiérdemelték a lassú mozgás hírnevét. Ez azonban változik. Számos nagy szoftvervállalat sikeresen átalakítja az Agile-t. Megtanulják skálázni az Agile-alapelveket olyan népszerű keretrendszerekkel, mint az SAFe, a LeSS vagy a Nexus.

A Microsoftnál az egyik ilyen szervezet az Agile használatával készíti el az Azure DevOps márkanév alatt szállított termékeket és szolgáltatásokat. Ez a csoport 35 funkciócsapatot tartalmaz, amelyek háromhetente jelenik meg éles környezetben.

Az Azure DevOps minden csapata az elejétől a végéig és azon túl is rendelkezik funkciókkal. Ők rendelkeznek ügyfélkapcsolatokkal. Saját termékhátreléket kezelnek. Kódokat írnak és ellenőriznek az éles ágban. Háromhetente telepítik a produkciós ágat, és a kiadás nyilvánosságra kerül. A csapatok ezután figyelik a rendszer állapotát, és kijavítják az élő webhely problémáit.

Az Agilis alapelvek szerint az autonóm csapatok hatékonyabbak. Egy agilis szervezet azt szeretné, hogy a csapataik irányíthassák a napi végrehajtásukat. De az egymáshoz igazítás nélküli autonómia káoszt eredményezne. Az önállóan dolgozó csapatok tucatjai nem hoznak létre egységes, kiváló minőségű terméket. Az összehangolás ad célt a csapatoknak, és biztosítja, hogy megfeleljenek a szervezeti céloknak. Igazítás nélkül még a legjobban teljesítő csapatok is kudarcot vallanának.

Az Agile méretezéséhez engedélyeznie kell a csapat önállóságát, és biztosítania kell a szervezettel való összhangot.

Az igazítás és az autonómia közötti kényes egyensúly kezeléséhez a DevOps-vezetőknek meg kell határozniuk egy osztályozást, meg kell határozniuk egy tervezési folyamatot, és funkciócsevegéseket kell használniuk.

Osztályozás definiálása

Egy Agilis csapatnak és a nagyobb Agile-szervezetnek, amelyhez tartozik, egyértelműen meghatározott hátralékra van szüksége a sikerességhez. A csapatoknak nehéz lesz a siker, ha a szervezeti célok nem egyértelműek.

Annak érdekében, hogy egyértelmű célokat tűzhessen ki, és meghatározhassa, hogy az egyes csapatok hogyan járulnak hozzá hozzájuk, a szervezetnek meg kell határoznia egy osztályozást. Egy egyértelműen meghatározott osztályozás létrehozza a szervezet nómenklatúrát.

Gyakori osztályozás az eposzok, funkciók, történetek és feladatok.

Eposzok

Az eposzok a szervezet sikeréhez fontos kezdeményezéseket írják le. Az eposzok számos csapatot és több sprintet igényelhetnek, de van végük. Az eposzoknak egyértelműen meghatározott céljuk van. Ha elérted, az eposz bezárul. A folyamatban lévő eposzok számának kezelhetőnek kell lennie a szervezet koncentráltsága érdekében. Az eposzok funkciókra vannak lebontva.

Features

A funkciók meghatározzák az epikus cél eléréséhez szükséges új funkciókat. A funkciók a kiadási egység; az ügyfél számára kiadott elemet jelölik. A közzétett kibocsátási megjegyzések a nemrég befejezett funkciók listájára épülhetnek. A funkciók több futamot is végrehajthatnak, de méretet kell adni ahhoz, hogy egységes értékáramlást biztosítsanak az ügyfél számára. A funkciók történetekre vannak bontva.

Történetek

A történetek növekményes értéket határoznak meg, amit a csapatnak teljesítenie kell egy funkció létrehozásához. A csapat növekményes részekre bontja a funkciót. Előfordulhat, hogy egyetlen befejezett történet nem nyújt értelmes értéket az ügyfél számára. Azonban egy befejezett feladat termelési minőségű szoftvert jelöl. A történetek a csapat munkaegységei. A csapat meghatározza a funkció elvégzéséhez szükséges történeteket. A történetek opcionálisan tevékenységekre bonthatóak.

Tasks

A feladatok határozzák meg a szövegegység elvégzéséhez szükséges munkát.

Kezdeményezések

Ez az osztályozás nem egy mindenki számára megfelelő rendszer. Számos szervezet bevezeti a kezdeményezéseknek nevezett egy új szintet az eposzok fölött.

Az egyes szintek nevei testre szabhatók a szervezethez. A fent definiált nevek (eposzok, funkciók, történetek) azonban széles körben használatosak az iparágban.

Az autonómia vonala

A rendszerezés beállítása után a szervezetnek meg kell rajzolnia az autonómia vonalát. Az autonómia vonala az a pont, ahol a szint tulajdonjoga átkerül a vezetőségtől a csapatra. A menedzsment nem avatkozik bele a csapat tulajdonában lévő szintekbe.

Az alábbi példa az alábbi funkciókkal rajzolt autonómiasort mutatja be. A menedzsment rendelkezik eposzokkal és jellemzőkkel, amelyek összhangot biztosítanak. A csapatok saját történeteket és feladatokat birtokolnak, és önállóan hajtják végre a feladatokat.

Ebben a példában a felügyelet nem mondja el a csapatnak, hogyan bonthat le történeteket, tervezhet futamokat vagy hajthat végre munkát.

A csapatnak azonban gondoskodnia kell arról, hogy végrehajtásuk összhangban legyen a vezetőség céljaival. Bár a csapat a történetek hátralékával rendelkezik, a teendőlistát a hozzájuk rendelt funkciókhoz kell igazítania.

Planning

Az Agilis tervezés méretezéséhez a csapatnak szüksége van egy tervre az osztályozás minden szintjéhez. Fontos azonban a terv iterálása és frissítése. Ezt a folyamatot gördülőhullám-tervezésnek nevezzük.

A terv egy meghatározott időszakra vonatkozó irányt biztosít, és rendszeres időközönként várható kalibrációval rendelkezik. Egy 18 hónapos terv például hathavonta kalibrálható.

Íme egy példa az osztályozás egyes szintjeihez tartozó tervezési módszerekre: eposzok, funkciók, történetek, feladatok.

Képfelismerés

A víziót eposzok fejezik ki, és meghatározza a szervezet hosszú távú irányát. Az eposzok határozzák meg, hogy a szervezet mit szeretne végrehajtani a következő 18 hónapban. A vezetőség a terv tulajdonosa, és hathavonta kalibrálja azt.

A víziót egy állományértekezleten mutatjuk be. Mivel a jövőkép célja, hogy ambiciózus legyen, és sok minden változhat ezen időszak alatt, várhatóan a jövőkép körülbelül 60%-át érjük el.

Évszak

A szezon jellemzők által van leírva, és meghatározza a következő hat hónap stratégiáját. A funkciók határozzák meg, hogy a szervezet mit szeretne megvilágítani az ügyfelei számára. A vezetőség a szezonális tervet birtokolja, és egy mindennapos értekezleten mutatja be a jövőképet és a szezonális terveket. Minden csapattervnek igazodnia kell a vezetőség szezonális tervéhez. Várhatóan a szezonális terv 80%-át elérjük.

3-sprint terv

A három futamos terv meghatározza, hogy a csapat milyen történeteket és funkciókat fog befejezni a következő három futamon. A csapaté a terv, és minden futamot kalibrál. Minden csapat a funkciócsevegésen keresztül mutatja be a felügyeletre vonatkozó tervét (lásd alább). A terv meghatározza, hogy a csapat végrehajtása hogyan igazodik a 6 hónapos szezonális tervhez. Várhatóan a 3-sprint terv körülbelül 90%-át fogjuk megvalósítani.

Sprint terv

A sprintterv határozza meg, hogy a csapat milyen történeteket és funkciókat fog befejezni a következő futamban. A csapaté a sprintterv, és a teljes szervezetnek e-mailben küldi el a teljes átláthatóság érdekében. A terv tartalmazza, hogy a csapat mit ért el az elmúlt futamon, és a következő futamra összpontosítanak. Várhatóan a sprint terv körülbelül 95%-át valósítjuk meg.

Az autonómia vonala

Ebben a példában az autonómia vonala azt mutatja meg, hogy a csapatok hol tervezik az autonómiát.

Ahogy fentebb említettük, a vezetés nem hosszabbítja meg a tulajdonjogot az autonómia vonala alatt. A vezetőség útmutatást nyújt a vízió és a szezontervek használatával, majd önállóságot biztosít a csapatoknak a 3-sprint- és futamtervek létrehozásához.

Funkcióbeszélgetések: Ahol az autonómia találkozik az illeszkedéssel

A feature chat egy kevés formalitással járó értekezlet, ahol minden csapat bemutatja a három sprintből álló tervét a vezetőségnek. Ez az értekezlet biztosítja, hogy a csapattervek igazodjanak a szervezeti célokhoz. Emellett segít a vezetőségnek tájékozódni arról, hogy mit csinál a csapat. Bár a 3-sprint terv minden futamon kalibrálva van, a funkcióval kapcsolatos csevegések szükség szerint, általában minden egy-a-három futamon tartanak.

A funkciós csevegési értekezletek minden csapat számára 15 percet foglalnak le. 12 funkciócsapattal ezek az értekezletek körülbelül három óra időtartamra ütemezhetők. Minden csapat egy 3 diás prezentációt készít, a következő diákat tartalmazva:

Features

Az első dia azokat a funkciókat mutatja be, amelyeket a csapat a következő három sprintekben fog elérhetővé tenni.

Adósság

A következő dia bemutatja, hogyan kezeli a csapat a technikai adósságot. Az adósság bármilyen tétel, amely nem felel meg a vezetőség minőségi követelményeinek. A mérnöki igazgató meghatározza a minőségi normákat, amelyek minden csapat esetében azonosak (igazítás). A minőségi sávok közé tartozik például a hibák száma mérnökenként, az egységtesztek sikerességének százalékos aránya és a teljesítménycélok.

Problémák és függőségek

Az utolsó dián felsorolt problémák és függőségek minden olyan problémát tartalmaznak, amely hatással van a csapat előrehaladására, például olyan problémákra, amelyeket a csapat nem tud megoldani, vagy más, eszkalálásra szoruló csapatoktól való függőségek.

Minden csapat közvetlenül a felügyeletnek mutatja be a diákat. A csapat bemutatja, hogyan igazodik a 3 futamos tervük a 6 hónapos szezonális tervhez. A vezetőség tisztázza a kérdéseket, és irányváltást javasol. További értekezleteket is kérhetnek a mélyebb problémák megoldásához.

Ha egy csapat terve nem felel meg a vezetőség elvárásainak, a vezetőség kérheti az újratervet. Ebben a ritka eseményben a csapat újratervezi és ütemezi a második funkciócsevegés áttekintését.

Bizalom: Az összhangot és önállóságot összetartó ragasztó

Amikor az Agile-t nagyvállalati környezetben gyakorolják, a bizalom kölcsönös.

• A vezetőségnek bíznia kell a csapatokban, hogy helyesen cselekedjenek. Ha a vezetőség nem bízik a csapatokban, akkor nem adnak önállóságot a csapatoknak.

• A csapat bizalmat nyer azáltal, hogy következetesen magas színvonalú kódot szállít. Ha a csapatok nem megbízhatóak, a vezetőség nem ad nekik autonómiát.

A vezetőségnek egyértelmű terveket kell biztosítania, hogy a csapatok a tervekkel összhangban dolgozhassanak, majd bízniuk kell a csapataikban, hogy végrehajtsák a terveket. A csapatoknak a szervezethez kell igazítaniuk a terveiket, és megbízható módon kell végrehajtaniuk őket.

Mivel a szervezetek az Agile-t nagyobb forgatókönyvekre szeretnék skálázni, a legfontosabb az, hogy a csapatok önállóságot biztosítsanak, miközben gondoskodnak arról, hogy igazodjanak a szervezeti célokhoz. A kritikus építőelemek egyértelműen meghatározott tulajdonjogok és a bizalom kultúrája. Ha egy szervezet rendelkezik ezzel az alaptal, azt fogják tapasztalni, hogy az Agile nagyon jól méretezhető.

Következő lépések

Egy tetszőleges méretű csapatnak számos módja van arra, hogy a mai napon előnyöket láthasson. Tekintse meg ezeket a skálázási eljárásokat.

Ismerje meg az Azure DevOps funkcióit a portfóliókezeléshez és a csapatok közötti láthatósághoz.

A Microsoft a világ egyik legnagyobb Agile-vállalata. További információ a Microsoft DevOps-tervezésének méretezéséről.