SAFe (Scaled Agile Framework) oktatóanyag

Biztonságos keret lehetővé teszi a csapat számára,

• Lean-Agile szoftverek és rendszerek bevezetése vállalati szinten
• A Lean és Agile elveken alapul.
• Részletes útmutatást ad a vállalati portfólióban, az értékfolyamban, a programban és a csapatban végzett munkához.
• Úgy tervezték, hogy megfeleljen a szervezeten belüli összes érdekelt fél igényeinek.

A SAFe-t először a területen fejlesztették ki, és ben dolgozták ki Dean Leffingwells könyvei és blogjai. Az 1.0-s verzió az első hivatalos kiadás 2011-ben. A legújabb, 4.6-os verzió 2018 októberében jelent meg. Útmutatást ad a vállalati portfólió, értékfolyam, program és csapatszinten végzett munkához.

Miért használja a SAFe Agile Framework-et?

Egyszerű és könnyű keretrendszer, mégis képes kezelni a nagy értékáramok és a komplex rendszerfejlesztés igényeit. A SAFe agilis keretrendszer megvalósításával a következő előnyökkel jár:

• A termelékenység nőtt by 20 - 50%
• Minőség több mint 50%
• A piacra kerülési idő gyorsabb, mint 30 -75%
• Megnövekedett dolgozói elkötelezettség és a munkával való elégedettség.

A részletes keretdiagram elérhető a . Megmutatja az összes kulcsfontosságú szerepet, tevékenységet, teljesítést és folyamatot. A webhely többi részének navigációs segédeszközeként is szolgál.

Az alábbi kép bemutatja, hogyan működik az agilis folyamat. Az eposzok nagy mennyiségű alkotást jelentenek, amely további kisebb történetekre vagy alepikusokra bontható. Ezeket a részeposzokat történetként rendelik a csapathoz. Ezután minden csapat ennek megfelelően dolgozik ezeken a történeteken vagy szoftverfunkciókon.

Mikor kell használni a Scaled Agile Framework-et

• Amikor egy csapat érdekelt egy agilis megközelítés következetes megvalósításában a nagyobb, több csapatból álló programok és portfóliók között.
• Amikor több csapat az Agilis megvalósítás saját módját futtatja, de rendszeresen szembesülnek akadályokkal, késedelmekkel és kudarcokkal.
• Amikor a csapatok önállóan szeretnének dolgozni.
• Ha a szervezeten belül szeretné az Agilit skálázni, de nem biztos abban, hogy milyen új szerepkörökre lehet szükség, vagy milyen meglévő szerepköröket (pl. menedzsmentet) kell megváltoztatni és hogyan.
• Amikor megpróbálta skálázni az Agilit a szervezetében, de küzd az összehangolásért, hogy egységes vagy következetes stratégiát érjen el az üzleti részlegek között, a portfóliótól a program- és csapatszintig.
• Amikor egy szervezetnek javítania kell a termékfejlesztési átfutási idején, és tudni szeretné, hogy más vállalatoknak hogyan sikerült az Agilis SAFe-vel bővítése.

Mennyire más, mint a többi Agilis gyakorlat

Most ebben a Scaled Agile Framework oktatóanyagban nézzük meg, miben különbözik a Scaled Agile keretrendszer a többi agilis gyakorlattól,

• Nyilvánosan elérhető és ingyenesen használható.
• Rendkívül jól megközelíthető és használható formában kapható.
• Könnyű, gyakorlatilag bizonyított eredményekkel rendelkezik, és szintspecifikus.
• Folyamatosan/rendszeresen módosítja/karbantartja a leggyakrabban használt agilis gyakorlatokat.
• Hasznos kiterjesztéseket kínál a gyakori agilis gyakorlatokhoz.
• Az agilis gyakorlatokat a vállalati környezethez igazítja.
• Teljes képet nyújt a szoftverfejlesztésről.
• A láthatóság vagy az átláthatóság minden szinten fontosabb.
• Folyamatos vagy rendszeres visszajelzés a minőségről és a fejlesztésről.

Foundations Scaled Agile Framework

Scaled Agile Framework (SAFe): Az alapjain áll

1. Lean-Agile elvek
2. Alapértékei,
3. Lean-Agile Leadership
4. Lean-Agile gondolkodásmód,
5. Gyakorlati közösségek (Emberek csoportja, akik folyamatosan dolgoznak a SAFe gyakorlatokon)
6. Megvalósítása 1-2-3

SAFe Lean-Agile alapelvek

Ezeket az alapvető SAFe Agilis alapelveket és értékeket a SAFe számára meg kell érteni, fel kell mutatni és folytatni kell a kívánt eredmények elérése érdekében.

• Vegyen egy gazdasági nézetet
• Rendszergondolkodás alkalmazása
• Változékonyságot tételezzünk fel; opciók megőrzése
• Építsen fokozatosan gyors, integrált tanulási ciklusokkal
• Alapvető mérföldkövek a működő rendszerek objektív értékelésére
• Vizualizálja és korlátozza a WIP-t, csökkentse a kötegméreteket és kezelje a várólisták hosszát
• Alkalmazzon ütemet, szinkronizáljon a tartományok közötti tervezéssel
• Oldja fel a tudásmunkások belső motivációját
• Decentralizálja a döntéshozatalt

SAFe Agilis alapértékek

A SAFe Agile módszertana ezen a négy értéken alapul.

Jellem:

• A SAFe támogatja az igazítást.
• Az igazítás ekkor kezdődik,
  • Stratégiai témák a portfólióban elmaradás és
  • Lefelé lép a Programhátralékok jövőképe és ütemterve, majd
  • Átkerül a csapathátralékok közé.

Beépített minőség:

• Biztosítja, hogy minden növekményes szállítás megfeleljen a minőségi szabványoknak.
• A minőség nem „később hozzáadódik” be van építve.
• A beépített minőség a Lean előfeltétele és kötelező

Átláthatóság:

• Az átláthatóság a bizalom alapja.
• A SAFe segíti a vállalatot az átláthatóság elérésében minden szinten – vezetők, portfóliómenedzserek és egyéb érdekeltek.
• Mindenki láthatja a portfólió hátralékot/Kanbant, a programhátralékot/Kanbant és a Team Backlogot/Kanbant.
• Minden szinten világosan megértik a PI-célokat.
• A Train Programok betekintést nyújtanak a csapat lemaradásaiba, valamint egyéb programhátralékaiba
• A csapatok és a programok rálátást kapnak az üzleti és építészeti eposzokra. Látják, mi lehet az útjuk.

A program végrehajtása:

• A SAFe nagy hangsúlyt fektet a működő rendszerekre és az ebből eredő üzleti eredményekre.
• A SAFe nem hasznos, ha a csapatok nem tudnak végrehajtani és folyamatosan értéket szolgáltatni.

Lean Agilis vezetők

A Lean-Agile Leaders élethosszig tartó tanulók és tanárok. A Lean-Agile SAFe elvek megértése és bemutatása révén segít a csapatoknak jobb rendszereket felépíteni.

A csapatok számára a végső felelősség a Lean-Agile fejlesztések átvétele, sikere és folyamatos fejlesztése. A változáshoz és a folyamatos fejlődéshez a vezetőket képezni kell.

A vezetőknek új vezetési stílust kell elfogadniuk. Olyan, amely valóban felhatalmazza és bevonja az egyéneket és a csapatokat, hogy elérjék legmagasabb potenciáljukat.

A Lean-Agile vezetők alapelvei

• Vezesd a változást
• Ismerje meg az utat; Hangsúlyozza az egész életen át tartó tanulást
• Emberek fejlesztése
• Inspirálj és igazodj a küldetéshez; Minimalizálja a korlátozásokat
• Decentralizálja a döntéshozatalt
• Oldja fel a tudásmunkások belső motivációját

Lean Agile Mind-Set

A Lean-Agile gondolkodásmódot két dolog képviseli:

1. A SAFe House of Lean
2. Agilis manifesztum

A SAFe House of Lean:

A SAFe a Lean gyártási elvekből és gyakorlatokból származik. Ezen tényezők alapján a SAFe bemutatja a „SAFe House of Lean”-et. A karcsú Toyota „háza” ihlette.

A karcsúsítás célja verhetetlen: a lehető legrövidebb átfutási idő alatt maximális értéket nyújtani az ügyfelek számára, a lehető legmagasabb minőségben.

Az alábbi ábra bemutatja a célt, a pilléreket és Foundation a "SAFe House of Lean."

Agilis manifesztum

Jobb fejlesztési módszereket fedezünk felping szoftver csináld meg és helping mások is ezt teszik. E munka révén értékesnek tartjuk:

Éppen ezért , míg a jobb oldali elemek között van érték, a bal oldali elemeket nagyobbra értékeljük.

Agilis manifesztum

1. A legfontosabb prioritás az, hogy az értékes szoftverek folyamatos és korai kiszállításával az ügyfelek elégedettek legyenek.
2. Fogadja el a változó követelményeket, még a fejlesztés késői szakaszában is. Az agilis SAFe módszertani folyamatok a változásokat az ügyfél javára hasznosítják.
3. Gyakran szállítson működő szoftvert, néhány héttől néhány hónapig, a rövidebb időkeretet részesítve előnyben.
4. A fejlesztőknek és az üzletembereknek naponta együtt kell dolgozniuk a projekt során.
5. Építsen projekteket motivált egyének köré. Adja meg nekik a támogatást és a szükséges környezetet, és bízza rájuk a munka elvégzését.
6. A fejlesztőcsapattal való kommunikáció leghatékonyabb módja a személyes beszélgetés.
7. A működő szoftver a fejlődés elsődleges mércéje.
8. Az agilis folyamatok elősegítik a fenntartható fejlődést. A szponzoroknak, fejlesztőknek és felhasználóknak képesnek kell lenniük arra, hogy a végtelenségig állandó tempót tartsanak fenn.
9. A műszaki kiválóságra és a jó dizájnra való folyamatos figyelem növeli a mozgékonyságot.
10. Az egyszerűség – az el nem végzett munka mennyiségének maximalizálásának művészete – elengedhetetlen.
11. A legjobb architektúrák, követelmények és tervek önszerveződő csapatokból születnek.
12. Rendszeres időközönként a csapat átgondolja, hogyan válhat hatékonyabbá, majd ennek megfelelően hangolja és módosítja viselkedését.

Különböző szintek a SAFE-ban

Két különböző típusú SAFe megvalósítás létezik:

1. SAFe 4.0 implementáció
2. SAFe 3.0 implementáció

• A SAFe 4.0 megvalósításában 4 szint van: Portfólió, értékfolyam, program és csapat.
• A SAFe 3.0 megvalósításában 3 szint van: Portfólió, program és csapat
• A 3-Level SAFe kisebb, 100 vagy kevesebb fős megvalósításokhoz való. Olyan programok, amelyek nem igényelnek jelentősebb együttműködést.
• A 4-Level SAFe olyan megoldásokhoz való, amelyeknél általában sok száz szakemberre van szükség a szoftverek telepítéséhez és karbantartásához.

Csapatszint

Szerepek/csapatok		Események		Mesterséges
* Agilis csapat		* Sprint Tervezés		* Csapat lemaradás
* Terméktulajdonos		* Lemaradás ápolás		* Nem funkcionális követelmények
* Scrum mester		* Napi Stand-Up		* Team PI-célok
		* Végrehajtás		* Iterációk
		* Sprint Demó		* Történetek (működő szoftver)
		* Sprint Visszatekintő		* Sprint Célok
		* IP Sprints		* Beépített minőség
				* Tüskék
				* Kanban csapat

• Minden SAFe csapat tagja az egyik vagy másik Agile Release Train (ART) programnak.
• A SAFe csapatok felhatalmazással rendelkező, önszerveződő, önmenedzselő, többfunkciós csapatok
• Minden csapat egyformán felelős a csapathátralékból származó történetek meghatározásáért, felépítéséért és teszteléséért egy fix hosszúságú iterációban.
• A csapatok kéthetes időkeretes iterációkat terveznek és hajtanak végre az egyeztetett iterációs céloknak megfelelően.
• A csapatok a ScrumXP/Team Kanban rutint fogják használni, hogy kiváló minőségű rendszereket készítsenek, és kéthetente rendszerbemutatót készítsenek.
• Az ART (Agile Release Trains) különböző csapatai integrált és tesztelt rendszert hoznak létre. Az érintettek értékelik és gyors visszajelzéssel válaszolnak
• Beépített minőségi gyakorlatokat alkalmaznak.
• Minden ScrumXP-csapat 5-9 tagból áll, amely magában foglalja az összes olyan szerepkört, amely a minőségi inkrementális érték felépítéséhez szükséges minden iterációban.
• A ScrumXP szerepkörei a következőket tartalmazzák:
  • Csapat (Dev+QA)
  • Scrum mester
  • Terméktulajdonos. Stb..
• A SAFe a fejlesztési idővonalat egy PI-n (Program Increment) belüli iterációk halmazára osztja.
• A PI időtartama 8-12 hét.
• A csapat történeteket használ az érték biztosítására. A terméktulajdonos tartalomjoggal rendelkezik a történetek létrehozása és elfogadása felett.
• A történetek az Ügyfél követelményeit tartalmazzák.
• A Team Backlog felhasználói és engedélyezői történeteket tartalmaz, amelyeket a PI tervezés során azonosítanak. Amikor a termékmenedzsment bemutatja az ütemtervet, a jövőképet és a programhátralékot.
• A történetek azonosítása, kidolgozása, prioritások meghatározása, ütemezése, megvalósítása, tesztelése és elfogadása a csapatszintű vezetői munka elsődleges követelménye.
• Minden iteráció a következőket nyújtja:
  • Az új funkciók értékes növekedése
  • Végezze el folyamatosan ismétlődő mintával
  • Tervezze meg az iterációt
  • Vállaljon néhány funkciót
  • Hajtsa végre az iterációt történetek létrehozásával és tesztelésével
  • Az új funkció bemutatása
  • Visszatekintő
  • Ismételje meg a következő iterációhoz
• A csapatok minden iteráció végén támogatják a rendszerdemót is. amely az ART kritikus integrációs pontja.
• A nagyobb értékfolyamoknak több ART-ja lesz.
• Az innovációs és tervezési (IP) iterációk lehetőséget adnak a csapatoknak az innovációra és a felfedezésre.

Program szint

Szerepek/csapatok		Események		Mesterséges
* DevOps		* PI (programnövekmény) tervezés		* Látás
* Rendszercsapat		* Rendszerbemutatók		* Útiterv
* Kiadáskezelés		* Vizsgálja meg és fogadja el a műhelyt		* Mutatók
* Termékmenedzsment		* Archiszerkezeti kifutópálya		* Mérföldkövek
* UEX Archikivédik		* Kiadás bármikor		* Kiadások
* Vonatmérnök (RTE) felszabadítása		* Agilis Release Train		* Program Epics
* Rendszer Architect/Engineer		* Kiadás		* Program Kanban
* Üzlettulajdonosok				* Programlemaradás
* Lean-Agile vezetők				* Nem funkcionális követelmények
* Gyakorlati közösségek				* Súlyozott legrövidebb munka először (WSJF)
* Megosztott szolgáltatások				* A program PI céljai
* Ügyfél				* Funkció
				* Engedélyező
				* Megoldás
				* Értékfolyam koordináció

• Program szinten a SAFe értékét a hosszú élettartamú Agile Release Trains (ART) biztosítja. Az iteráció a csapatnak, a tréning pedig a programnak szól.
• Az Agile Release Trains (ART) a programszinten az értékátadás elsődleges eszköze. Értékáramot biztosít a szervezet számára.
• A Program Increments (PI) időtartama 8-12 hét.
• Az ART 5-12 agilis csapatból áll (~50-125+ fő), amely magában foglalja az összes szerepkört és infrastruktúrát, amely a teljesen tesztelt, működő, rendszerszintű szoftverek szállításához szükséges.
• Minden PI egy többszörös iterációs idődoboz. Ennek során a rendszer jelentős, értékes inkremensét fejlesztik és szállítják.
• Minden PI-ben megtörténik a „demó” és az „Ellenőrzés és adaptálás” munkamenet, és megkezdődik a következő PSI tervezése.
• A program szintjén a SAFe hangsúlyt fektet az összehangolás elvére. Ennek az az oka, hogy több agilis csapatmunka integrálódik az ügyfelek értékének megteremtése érdekében.
• A SAFe műtermék-hierarchia az Eposzok->szolgáltatások->felhasználói történetek.
• Program szinten a termékmenedzser/programmenedzser rendelkezik tartalomjoggal. Meghatározza és rangsorolja a programhátralékot.
• A programhátralék a szolgáltatások kiemelt listája.
• Program szinten a funkciók származhatnak, vagy származhatnak a portfólió szintjén meghatározott epikából.
• A funkciók felhasználói történetekre bomlanak, és csapatszintű lemaradásokká alakulnak.
• A termékmenedzser vagy a kiadási képzési mérnök szerepkört a programmenedzser/vezető projektmenedzser kezelheti
• rendszer ArchiA program szintjén az a feladat, hogy napi szinten együttműködjenek a csapatokkal. Biztosítja a nem funkcionális követelmények teljesülését. Ezenkívül portfólió szinten együttműködnek a vállalati építészekkel, hogy megbizonyosodjanak arról, hogy elegendő építészeti kifutópálya áll rendelkezésre a közelgő felhasználói és üzleti igények kielégítésére.
• Az interfész kialakítását, a felhasználói élményre vonatkozó irányelveket és a tervezési elemeket a csapatok számára az UX Designers biztosítja.
• A Chief-Scrum Master szerepét a „Vonatmérnök felszabadítása” játssza.
• Különféle csapatok (a marketingtől, a fejlesztéstől, a minőségtől, az üzemeltetéstől és a telepítéstől) alkotják a „Release Management Team”-et. Jóváhagyják a minőségi megoldások rutinszerű kiadását az ügyfelek számára.
• A szoftver ügyfélkörnyezetbe történő telepítéséről és a sikeres szállításról a DevOps csapata gondoskodik.

Portfóliószint

Szerepek/csapatok		Események		Mesterséges
* Enterprise Architect		* Stratégiai beruházási tervezés		* Stratégiai témák
* Program Portfolio Mgmt		* Kanban portfólió (Epic) tervezés		* Vállalati
* Epic tulajdonosok				* Portfólió elmaradás
				* Kanban portfólió
				* Nem funkcionális követelmények
				* Epic és Enabler
				* Értékfolyam
				* Költségkeretek (CapEx és OpEx)

• A SAFe iránti érdeklődés/aggodalom/bevonás/ legmagasabb szintje SAFe Portfólió
• A portfólió biztosítja az alapvető blokkokat a Lean-Agile Enterprise értékáramlás megszervezéséhez egy vagy több értékfolyamon keresztül.
• A portfólió segít olyan rendszerek és megoldások fejlesztésében, amelyek stratégiai témákban vannak leírva (kapcsolja a SAFe portfóliót egy vállalkozás változó üzleti stratégiájához).
• A stratégiai célok elérése érdekében a portfóliószint ezeket az elemeket tartalmazza. Alapvető költségvetési és egyéb irányítási mechanizmusokat biztosít. Ezáltal biztosítja, hogy az értékáramokba való befektetés a vállalkozás számára szükséges megtérülést biztosítsa.
• Egy portfólió kétirányúan kapcsolódik az üzlethez:
  • Annak érdekében, hogy a Portfóliót a nagyobb változó üzleti célokhoz irányítsa, stratégiai témákat kínál.
  • Egy másik irány a portfólióértékek állandó áramlását jelzi.
• A Program Portfolio Management érdekelt felekként jár el, és felelősséggel tartoznak az üzleti eredmények elérése érdekében.
• A SAFe Portfolio Level olyan embereket, folyamatokat és szükséges összeépítési rendszereket és megoldásokat tartalmaz, amelyekre egy vállalatnak szüksége van stratégiai céljainak eléréséhez.
• Az értékfolyamok a Portfolio elsődleges céljai, amelyekkel a megoldások kiépítéséhez szükséges embereket és egyéb erőforrásokat finanszírozzák.
• Az itt használt fontos kulcsfogalmak a következők:
  • Csatlakozás az Enterprise-hoz,
  • Program portfóliókezelés,
  • A Portfolio Epics áramlásának kezelése.

Értékfolyam szintje

Szerepek/csapatok		Események		Mesterséges
* DevOps		* Elő- és utáni PI (programnövekmény) tervezés		* Látás
* Rendszercsapat		* Megoldási bemutatók		* Útiterv
* Kiadáskezelés		* Vizsgálja meg és fogadja el a műhelyt		* Mutatók
* Megoldáskezelés		* Agilis Release Train		* Mérföldkövek
* UEX Archikivédik				* Kiadások
* Value Stream Engineer (RTE)				* Value Stream Epics
* Megoldás Architect/Engineer				* Value Stream Kanban
* Megosztott szolgáltatások				* Value Stream hátralék
* Ügyfél				* Nem funkcionális követelmények
* Támogató				* Súlyozott legrövidebb munka először (WSJF)
				* Value Stream PI-célok
				* Képesség
				* Engedélyező
				* Megoldás kontextusa
				* Értékfolyam koordináció
				* Gazdasági keret
				* Megoldási szándék
				* MBSE
				* Beállítás alapú
				* Agilis Architectúra

• Az értékfolyam szintje nem kötelező a SAFe-ben.
• A Value Stream Level új a SAFe 4.0-ban.
• Az Értékfolyam-szintet olyan vállalatoknak / építőknek / szervezeteknek szánják/tervezték, akik:

1. Nagy méretű
2. Független
3. Legyenek komplex megoldásai
4. Megoldásaik általában több ART-t igényelnek
5. Szállítói hozzájárulással rendelkeznek.
6. Ők néznek szembe a legnagyobb rendszerkihívásokkal
7. Kiberfizikai rendszerekhez
8. Szoftverekhez, hardverekhez, elektromos és elektronikai eszközökhöz, optikához, mechanikához, fluidikához és egyebekhez.

• Az ilyen rendszerek felépítése gyakran több száz, sőt több ezer szakembert, külső és belső beszállítót igényel.
• Ha a rendszerek kulcsfontosságúak a küldetésben. A Megoldás, vagy akár egy alrendszer kudarca elfogadhatatlan gazdasági és társadalmi következményekkel jár.
• Ha a Vállalkozásokat néhány száz gyakorlóval meg lehet építeni, akkor lehet, hogy nincs szüksége ilyen szintű konstrukciókra. Ebben az esetben használhatják a "összecsukott nézet' amely 3 szintű SAFe.
• Az értékfolyam-megoldások Lean-Agile mintában való felépítése további műtermékeket, koordinációt és konstrukciókat igényel. Tehát ez a szint tartalmaz egy gazdasági keretrendszert, amely pénzügyi határokat biztosít az Value Stream számára
• Támogatja a ritmust és a szinkronizálást több ART és beszállító számára. Tartalmazza a PI-tervezés előtti és utáni megbeszéléseket és a megoldás bemutatóját.
• További szerepköröket biztosít, amelyek a következők: Value Stream Engineer, Solution Architect/Engineering és Solution Management.

Összegzésként

• A SAFe egy iparágban bevált, értékközpontú módszer az Agile vállalati szintű skálázására.
• Választ ad az olyan kérdésekre, mint „Hogyan tervezünk?”, „Hogyan készítünk költségvetést?” és „Hogyan válhatunk keresztfunkcionálissá az építészetben és DevOps?"
• A SAFe Agile keretrendszer segít a nagy szervezeti csapatoknak a szervezet stratégiai céljainak teljesítésében, nem csak az egyéni projektcélok elérésében.
• A keretrendszer lehetőséget kínál egy központosított stratégia fenntartására és létrehozására az értékteremtés érdekében.
• A SAFe modellnek három/négy szintje van, amelyek központosítják a szervezet stratégiai témáit.
• Központosított stratégia, kombinálva a decentralizált agilis fejlesztés végrehajtásával.

Referenciák:

SAFe for Lean Enterprises 5.0:

http://www.scaledagileframework.com