Skálázási agilis eljárások implementálása

  • Cikk

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

A vállalati szervezetek számos okból fogadnak el agilis eljárásokat. Az alábbi okok közül a legfontosabbak a következők:

  • Rövidítse le a piacra szállítás idejét, gyorsítsa fel a termékkézbesítést
  • A szervezeti hatékonyság javítása a változó prioritások kezeléséhez
  • A szoftverminőség és a kézbesítés kiszámíthatóságának javítása
  • A projekt láthatóságának javítása és a projektkockázat csökkentése

A szervezet növekedésével skálázni szeretné a gyakorlatait, hogy agilis maradjon, és megfeleljen a változó céloknak. Ehhez vegye figyelembe ezt a két alapelvet:

  • Hogyan néz ki a siker Az Ön, a csapatai és a szervezete számára? Mi a legérdemesebb: Időben történő kézbesítés? Termékminőség? Kiszámíthatóság? Ügyfél-elégedettség?
  • Térjen vissza az első alapelvekhez, térjen vissza az Agile-kiáltványbanfelsorolt alapelvekhez és közös értékekhez, ahogy Ken Schwaber, a Scrum egyik alapítója megjegyezte:
    • "Az értékek és elvek méretezhető, de a gyakorlatok környezetfüggők."
    • "Tartsa meg az értékeket, tartsa meg az alapelveket, gondoljon magadra. Az Agile alapvető előfeltétele, hogy a munkát végző emberek azok, akik a legjobban ki tudják deríteni, hogyan kell csinálni."

Ritmus és folyamat létrehozása

A megosztott ütemezés és a rendszeres kommunikáció alkalmazásával folyamatos tevékenységáramlást hozhat létre a szervezet egészében. A nagyobb szervezeteken belüli ritmust és folyamatot segítő eljárások a következők:

  • Megosztott ütem: A rendszeres futamok és kiadások hozzák létre az üzlet ritmusát. Ha minden csapat közösen dolgozik, az segít minden koordinációs és együttműködési tevékenységben.
  • Sprint e-mailek: Annak érdekében, hogy a szervezet és az összes csapat értesüljön a funkciócsapatok előrehaladásáról és terveiről, minden funkciócsapat e-mailben elküldheti a korábbi futameredmények és az aktuális futamtervek összegzését.
  • Sprint demos: Egy gyors-2-3 perces videó, amely bemutatja a csapat által készített új funkciót. Az ilyen videókra mutató hivatkozások a sprint e-mailekben is megtalálhatók.
  • Értekezletek bemutatása: Ha más csapatokat szeretne tájékoztatni, és visszajelzést szeretne kérni a fejlesztés alatt álló szoftverekről, a csapatok bemutatják az elvégzett munkát. Ezeket az értekezleteket rendszeres időközönként, a projekt teljes életciklusa során tarthatja, és megnyithatja azokat az összes érdekelt fél számára.
  • Hibaösszesítő e-mailek: A termékminőséggel kapcsolatos megállapítások támogatásához és a hibafegyelem fenntartásához rendszeresen ossza meg a minőségi metrikákat a szervezettel. Ezek a metrikák a funkciócsoportonkénti aktív hibákat, a hibatrendeket és a mérnökökre jutó hibákat is tartalmazhatják.
  • Koordinációs értekezletek: Olyan értekezleteket tart, amelyek rendszeres időközönként vagy szükség szerint koordinálják a csapatokat az átfedésben lévő célok, függőségek és kockázatok kezelése érdekében.

Interakció az ügyfelekkel

Az ügyfelek bevonása a termék életciklusa során elsődleges Agilis alapelv. Minden csapat számára lehetővé teszi, hogy közvetlenül kommunikáljanak az ügyfelekkel a saját szolgáltatáskészleteiken.

  • Folyamatos visszajelzés: Build in customer feedback loops. Ezek a hurkok számos formát ölthetnek:
    • Ügyfélhang: Az ügyfelek egyszerűen adhatnak visszajelzést, ötleteket adhatnak hozzá, és szavazhatnak a következő generációs funkciókra. Visszajelzés küldése gyakran egy dedikált webhelyen keresztül történik.
    • Termékvisszajelzés: A terméken belüli visszajelzési gombok egy másik módja annak, hogy visszajelzést kérjenek a termék felületéről vagy adott funkcióiról.
    • Ügyfélbemutatók: A rendszeresen ütemezett demók, amelyek visszajelzést kérnek az ügyfelektől, segíthetnek a következő generációs termékek kialakításában, és nyomon követhetik az ügyfelek által használni kívánt alkalmazások létrehozását.
  • Korai bevezetési programok: Az ilyen programokat azzal a gondolattal kell fejleszteni, hogy minden csapat szeretne részt venni egy bizonyos ponton. A korai alkalmazók hozzáférhetnek a munkaszoftverek korai verzióihoz, amelyekről visszajelzést kaphatnak. Ezek a programok gyakran úgy működnek, hogy bekapcsolják a korai bevezetési lista funkciójelzőinek kiválasztását.
  • Adatvezérelt döntések: Olyan módszerek keresése, amelyekkel a termék hasznos adatokhoz juthat, és amelyek különböző hipotéziseket tesztelhetnek. Segítség a tanulást ünneplő kísérletbarát kultúrához.

A projekt láthatóságának javítása

Minél több betekintést kap Ön és csapata a munka céljába, elképzelésébe és előrehaladásába, annál jobb lesz a kockázatok csökkentése és a függőségek kezelése.

  • Csapatstruktúra: A szervezet méretétől függetlenül 6–9 skálás kis csoportok köré szervezheti a szervezetet. Vertikális, autonóm funkciócsoportokat hozhat létre portfóliókezelési területek szerint csoportosítva.
  • Munkalebontási struktúra: A nagy célok, funkciók vagy követelmények kisebbekre bontása stabil marad a projektvezetésben. A hasonló méretű feladatokra való bontással a csapatok jobb becsléseket készíthetnek, és azonosíthatják a kockázatokat és a függőségeket.
  • Konszolidált nézetek: Az online nyomkövetési eszközökkel összesítheti a munkát a csapatok közötti tudásszerzéshez. Irányítópultok készítése az előrehaladás és a trendek megjelenítéséhez.
  • Tapasztalatértékelések: Ezek az értekezletek, amelyeket a fejlesztés megkezdése előtt tartanak egy funkcióban, arra szolgálnak, hogy felkészítsék a vezetőséget a forgatókönyvekre és a prioritásokra, visszajelzéseket gyűjtsenek, elvárásokat állítsanak be, és feltárják a funkcióval kapcsolatos, csapatközi problémákat.

Hatékony munkaerő támogatása

Néhány konkrét Agile-gyakorlat, amely jól skálázható, és boldogabb, elkötelezettebb és eredményesebb alkalmazottakhoz vezet:

  • Beágyazott vezetés: Lehetővé teszi a szervezeten belüli csapatok és vezetők számára, hogy a lehető legnagyobb mértékben önszerveződjenek és felügyelhessék azokat. A csapat önállósága növeli a szervezeti agility csapat hatékonyságát. Győződjön meg arról, hogy a csapatok rendelkeznek a sikerhez szükséges vállalati szponzorálással.
  • Napi stand-upok: Vagy a Scrum-értekezletek segítenek a csapatoknak arra koncentrálni, hogy naponta mire van szükségük ahhoz, hogy maximálisan teljesíthessék a futamra vonatkozó kötelezettségvállalásaikat. A szervezetek növekedésével érdemes megfontolniuk az értekezletek megdöbbentő összevonását, hogy szükség esetén csapatközi részvételre is sor kerülhessenek.
  • Scrumok scrumjai: A különböző Agile-csapatok tagjai naponta találkoznak, hogy beszámoljanak a befejezett munkáról, a következő lépésekről, valamint a reprezentatív csapatokon belül felmerülő problémákról vagy blokkokról.
  • Csapatkommunikáció: Biztosíthatja és ösztönözheti a csapatokat, hogy megosszák gyakorlataikat és útmutatásaikat, amelyeket ők és más csapatok a vállalati hálózaton keresztül érhetnek el. Az erre a célra használt gyakori eszközök közé tartoznak a csapat wikii, a OneNotes vagy a Markdown-webhelyek.
  • Együttműködés: A csapaton belüli informális kommunikáció és együttműködés ösztönzése. Az olyan intézményesítési eljárások, mint a kódértékelések, a tervezési felülvizsgálatok, a specifikációk áttekintése nem csak a csapat együttműködését növelik, hanem segítenek az egyéni és általános vállalati kompetencia fejlesztésében.

A szervezeti kultúra fejlesztése

A felépíteni kívánt kultúra megtekintésével javíthatja a szervezeti hatékonyságot. A kulturális változások akkor fordulnak elő, ha az egyének, a csapatok és a szervezetek egy vagy több folyamatos fejlesztési gyakorlatot vezetnek be. Számos méretezhető Agile-eljárás:

  • Visszatekintők: Ha olyan kérdéseket tesz fel, mint például: "Mi ment jól?", "Mit tegyünk másképp?", és "Mit kell abbahagynunk?" segít a csapatoknak átgondolni, hogyan fejleszthetik folyamataikat és gyakorlataikat. A visszatekintők segítenek a csapatoknak feltárni, hogy mi működik jól, és mit kell javítani. A visszamenőleges vizsgálatok bármikor és bárhol végezhetők. Bizonyos visszatekintések rendszeres időközönkénti intézményesítése azonban elősegíti a folyamatos fejlesztési gyakorlatok intézményesítését. Példa:

    • A sprintvisszatekintések segíthetnek a csapatoknak a rendszeres ütemben fejlesztendő területek azonosításában.

    • A kiadási visszamenőleges verziók segíthetnek a szervezeteknek azonosítani a kommunikációs és belső gyakorlatok fejlesztésére szolgáló területeket, valamint az üzemanyag-fejlesztést a következő kiadáshoz.

    • Működési felülvizsgálatok: általában havonta kerülnek megrendezésre, és egy teljes értékáram képviselőit is magukban foglalják. A projektek és egyéb kezdeményezések portfoliójára kiterjedő, objektív, mennyiségi adatok felhasználásával ezeket a visszatekintéseket úgy tervezheti meg, hogy vitákat váltson ki a csapatok teljesítményét befolyásoló dinamikáról.

      Az Agile Retrospective Resource Wikiben talál ötleteket, tippeket és eszközöket a retrospektív tervezéshez és kivitelezéshez. Lásd még a Marketplace Retrospektívs bővítményt.

  • Fejlesztéskövető tábla: A folyamatok fejlesztésére vonatkozó jó ötletek bármikor felmerülhetnek. A folyamatfejlesztési erőfeszítések támogatásához kulcsfontosságú, hogy ezeket az ötleteket gyorsan megvitassák és eldöntsék, hogyan cselekedjenek velük.

    A fehér tábla bármilyen egyszerű és vizuális eszközt biztosít, amellyel ötleteket rögzíthet. Emellett létrehozhat egy fejlesztéskövetési csapatot, és rögzítheti az elektronikus Kanban-táblán nyomon követett ötleteket.

  • A megosztás intézményesítése: Az ajánlott eljárások megosztása és az ötletek kommunikálása segít a szervezeten belüli összes csapat növekedésében és fejlesztésében. A tanulási kultúra fejlesztése kulcsfontosságú e és egyéb folyamatos fejlesztési tevékenységek támogatásához. Néhány megfontolandó ötlet:

    • Házon belüli wikik

    • Házon belüli terjesztési listák

    • Hackathon hét vagy 10% hack idő

    • Belső agilis támogatási csapat az Agile-eljárásokat alkalmazó csapatok támogatásához

      A Kulturális játék jó erőforrást biztosít az Agilis vezetőknek, hogy segítsenek a csapatoknak az Agilis bevezetésében és az ajánlott eljárások megosztásában.

  • Gyakorlatközösségek: Belső általános szemléletek támogatása (például DBA-k, SW Architects, UX-tervezés)

Működő szoftver

"A munkaszoftverek gyakran, néhány héttől néhány hónapig, a rövidebb időskálát részesítik előnyben."
"A munkaszoftver a haladás elsődleges mértéke."
- Agilis kiáltvány

A szoftverek, funkciók és összetettség növekedésével olyan eljárásokat kell alkalmaznia, amelyek segítenek a hasznosítható megoldások előállításában.

  • Funkciójelzők: Funkciójelzők használatával engedélyezheti vagy letilthatja a különböző funkciókhoz való hozzáférést. Támogatást nyújt a funkciók korai alkalmazókhoz való bekapcsolásához, hogy visszajelzést kapjon a munkáról.
  • Vonatok felszabadítása: Adjon meg egy vagy több funkciót egy vagy több funkció más típusú ütemezésével. A szolgáltatáscsapatok tisztában lesznek az új funkciók kiküldésének előre megtervezett ütemezésével, és megfelelően terveznek. A kiadási vonatok megegyezhetnek a szervezet által megadott sprint cadence-értékekkel, vagy más ütemben is előfordulhatnak. A futamok beállításáról és a vonatok kiadásáról lásd a skálázott Agile-keretrendszert .
  • Folyamatos integráció: Olyan folyamatok bevezetése, amelyek megszüntetik a manuális munkát, és ehelyett automatizálják a szoftverfolyamatot a tesztelés, a buildelés és a ciklusok üzembe helyezése során.
  • Belső nyílt forráskód: Hozza a nyílt forráskódú szoftver közösségében kifejlesztett értéket és szellemiséget a belső fejlesztői csapatokhoz.

A fenti gyakorlatokkal együtt további útmutatást talál az Agile-eszközök skálázásával kapcsolatban az alábbi cikkekben:

Iparági erőforrások

Nem skálázható eljárások

  • Nagy kezdeményezések becslése: A vízesés projektmódszerek része az erőforrások és ütemezések becslése. Minél nagyobbak a kezdeményezések, annál kevésbé valószínű, hogy ezek a becslések bármilyen értéket képviselnek. A projektek növekedésével kockázatok és előre nem látható problémák és akadályok merülhetnek fel, ami számos becslést érvénytelenít.
  • Sebesség: Bár a csapatsebesség hasznos metrikát biztosít ahhoz, hogy betekintést nyerjen abba, hogy az egyes csapatok mennyi munkát végezhetnek el egy futamciklus során, nem adhat hozzá csapatszintű sebességeket, hogy értelmes vagy hasznos metrikákat nyerjen. Emellett a sok csapat által elért sebesség használata a hosszú távú előrejelzések megbízható végrehajtásához is problémás. A csapatok a munkájuk becslésétől függően változnak, és ezek a variációk idővel növekednek.
  • Felülről lefelé vonatkozó, előíró megoldások: Az egy méret nem felel meg az összesnek, és egy megoldás általában nem felel meg az összes csapatnak. A csapat önállóságának támogatása azt jelenti, hogy a csapatok saját megoldásokat találhatnak.