SAFe-metodologiaopas: Mikä on skaalattu ketterä kehys

Mikä on skaalattu ketterä kehys (SAFe)?

Scaled Agile Framework (SAFe) on vapaasti saatavilla oleva online-tietopohja, jonka avulla voit soveltaa kevyitä ja ketteriä käytäntöjä yritystasolla. Se tarjoaa yksinkertaisen ja kevyen kokemuksen ohjelmistokehityksestä. Se on joukko organisaatioita ja työnkulkumalleja, joiden tarkoituksena on ohjata yrityksiä keventämään ketteriä ja ketteriä käytäntöjä. Se on jaettu kolmeen segmenttiin, jotka ovat Tiimi, Ohjelma ja salkku.

SAFe- kehyksen avulla tiimi voi

• Lean-Agile-ohjelmistojen ja -järjestelmien käyttöönotto yritystasolla
• Se perustuu Lean- ja Agile-periaatteisiin.
• Se antaa yksityiskohtaiset ohjeet työskentelyyn yrityssalkussa, arvovirrassa, ohjelmassa ja tiimissä.
• Se on suunniteltu vastaamaan kaikkien organisaation sidosryhmien tarpeita.

SAFe kehitettiin ensin kentällä ja se kehitettiin Dean Leffingwellin kirjoissa ja blogissa. Versio 1.0 on ensimmäinen virallinen julkaisu vuonna 2011. Viimeisin versio on 4.6, julkaistiin lokakuussa 2018. Se tarjoaa ohjeita työsuhteeseen yritysportfolio-, arvo-virta-, ohjelma- ja tiimitasolla.

Tässä SAFe Agile -oppaassa opit

• Mikä on skaalattu ketterä kehys (SAFe)
• Miksi käyttää ketterää kehystä
• Milloin käyttää skaalattua ketterää kehystä
• Kuinka erilainen kuin muut ketterät käytännöt
• Skaalatun ketterän kehyksen perusteet
• Ketterä manifesti
• Eri tasot SAFE-tilassa
• Joukkueen taso
• Ohjelmataso
• Salkun taso
• Arvovirran taso

Miksi käyttää ketterää kehystä

Se on yksinkertainen ja kevyt kehys, mutta se pystyy vastaamaan suurten arvovirtausten ja monimutkaisen järjestelmäkehityksen tarpeisiin. Toteuttamalla SAFe-ketterän kehyksen sinulla on seuraavat edut:

• Tuottavuus kasvoi by 20-50%
• Laatu kasvoi yli 50%
• Aika markkinoille on nopeampi kuin 30-75%
• Lisääntynyt työntekijöiden sitoutuminen ja työtyytyväisyys.

Yksityiskohtainen kehyskaavio on saatavana verkkosivustolta. Se näyttää kaikki keskeiset roolit, aktiviteetit, suoritteet ja virrat. Se toimii myös navigointitukena muulle alueelle.

Alla oleva kuva selittää ketterän prosessin toiminnan. Eepos on suuri kokonaisuus, joka jaetaan edelleen pienempiin tarinoihin tai alaepeihin. Nämä osa-eepot kohdistetaan joukkueelle tarinana. Jokainen tiimi työskentelee sitten näiden tarinoiden tai ohjelmisto-ominaisuuksien parissa.

Milloin käyttää skaalattua ketterää kehystä

• Kun joukkue on kiinnostunut toteuttamaan ketterän lähestymistavan johdonmukaisesti suuremmissa, usean tiimin ohjelmissa ja salkkuissa.
• Kun useat joukkueet käyttävät omaa tapaansa toteuttaa ketterästi, mutta kohtaavat säännöllisesti esteitä, viivästyksiä ja epäonnistumisia.
• Kun tiimit haluavat työskennellä itsenäisesti.
• Kun haluat skaalata ketterää koko organisaatiossa, mutta et ole varma, mitä uusia rooleja saatetaan tarvita tai mitä nykyisiä rooleja (esim. Johtoa) on muutettava ja miten.
• Kun olet yrittänyt skaalata ketterää koko organisaatiossasi, mutta kamppailet yhdenmukaisuuden saavuttamiseksi yhtenäisen tai johdonmukaisen strategian saavuttamiseksi liiketoimintaosastoissa portfoliosta ohjelma- ja tiimitasoon.
• Kun organisaation on parannettava tuotekehityksen läpimenoaikaa ja haluavat tietää, miten muut yritykset ovat onnistuneet ketterän skaalaus SAFe.

Kuinka erilainen kuin muut ketterät käytännöt

Katsotaan nyt tässä skaalatun ketterän kehyksen opetusohjelmassa, kuinka skaalattu ketterä kehys eroaa muista ketteristä käytännöistä,

• Se on julkisesti saatavilla ja ilmainen käyttää.
• Saatavana helposti lähestyttävässä ja käyttökelpoisessa muodossa.
• Se on kevyt, käytännössä todistetut tulokset ja erityinen tasolle.
• Se muuttaa jatkuvasti / säännöllisesti yleisimmin käytettyjä ketteriä käytäntöjä.
• Tarjoaa hyödyllisiä laajennuksia yleisiin ketteriin käytäntöihin.
• Perustaa ketterät käytännöt yrityksen kontekstiin.
• Tarjoaa täydellisen kuvan ohjelmistokehityksestä.
• Näkyvyys tai läpinäkyvyys on enemmän kaikilla tasoilla.
• Jatkuva tai säännöllinen palaute laadusta ja parantamisesta.

Skaalatun ketterän kehyksen perusteet

Skaalattu ketterä kehys (SAFe): Se seisoo sen perustalla

1. Lean-Agile-periaatteet
2. Perusarvot,
3. Lean-ketterä johtajuus
4. Lean-Agile-mielisarja,
5. Harjoitteluyhteisöt (ryhmä ihmisiä, jotka työskentelevät jatkuvasti SAFe-käytäntöjen parissa)
6. Toteutus 1-2-3

SAFe-ketterät periaatteet

Nämä SAFe: n ketterät periaatteet ja arvot SAFe: lle on ymmärrettävä, esiteltävä ja niitä on jatkettava, jotta saadaan halutut tulokset.

• Ota taloudellinen näkemys
• Käytä järjestelmää ajattelua
• Oletetaan vaihtelevuus; säilytä vaihtoehdot
• Rakenna asteittain nopeilla, integroiduilla oppimissyklillä
• Perustavoitteet työjärjestelmien objektiiviseen arviointiin
• Visualisoi ja rajoita WIP: tä, pienennä eräkokoja ja hallitse jonojen pituutta
• Käytä poljinnopeutta, synkronoi verkkotunnusten välisen suunnittelun kanssa
• Avaa tietotyöntekijöiden sisäinen motivaatio
• Hajauta päätöksenteko

SAFe Agile -arvot

SAFe Agile -menetelmä perustuu näihin neljään arvoon.

Kohdistus:

• SAFe tukee kohdistusta.
• Kohdistus alkaa,
  • Strategiset teemat salkun myöhässä ja
  • Siirtyy kohtaan Visio ja etenemissuunnitelma ohjelmaa ja sitten
  • Siirtyy Team Backlogsiin.

Sisäänrakennettu laatu:

• Se varmistaa, että jokainen asteittainen toimitus heijastaa laatustandardeja.
• Laatu ei ole "lisätty myöhemmin" on sisäänrakennettu.
• Sisäänrakennettu laatu on Leanin edellytys ja sen pakollinen

Läpinäkyvyys:

• Läpinäkyvyys on luottamuksen mahdollistaja.
• SAFe auttaa yritystä saavuttamaan avoimuuden kaikilla tasoilla - johtajat, salkunhoitajat ja muut sidosryhmät.
• Jokainen voi nähdä salkun kanavan / Kanban, ohjelmakannat / Kanban ja Team Backlog / Kanban.
• Jokaisella tasolla on selkeä käsitys PI-tavoitteista.
• Juna-ohjelmilla on näkyvyys sekä tiimin, että muiden ohjelmassa
• Joukkueilla ja ohjelmilla on näkyvyys liiketoiminnan ja arkkitehtuurin eeposissa. He näkevät, mikä saattaa olla heidän suuntaansa.

Ohjelman toteutus:

• SAFe kiinnittää paljon huomiota toimiviin järjestelmiin ja tuloksellisiin liiketoiminnan tuloksiin.
• SAFe ei ole hyödyllinen, jos joukkueet eivät voi toteuttaa ja tuottaa jatkuvasti arvoa.

Lean ketterät johtajat:

Lean-Agile-johtajat ovat elinikäisiä oppijoita ja opettajia. Se auttaa tiimejä rakentamaan parempia järjestelmiä ymmärtämällä ja esittelemällä Lean-Agile SAFe -periaatteet.

Tiimien mahdollistajana lopullinen vastuu on Lean-Agile-kehityksen hyväksyminen, menestys ja jatkuva parantaminen. Muutosta ja jatkuvaa parantamista varten johtajia on koulutettava.

Johtajien on omaksuttava uusi johtamistyyli. Se, joka todella antaa ihmisille ja tiimeille mahdollisuuden saavuttaa suurin potentiaalinsa.

Näiden kevyiden johtajien periaatteet

• Johda muutosta
• Tunne tie; Korosta elinikäistä oppimista
• Kehitä ihmisiä
• Inspiroi ja sovi tehtävään; Pienennä rajoituksia
• Hajauta päätöksenteko
• Avaa tietotyöntekijöiden sisäinen motivaatio

Lean Agile Mind-Set -sarja:

Lean-Agile-ajattelutapa on esitetty kahdessa asiassa:

1. SAFe Leanin talo
2. Ketterä manifesti

SAFe Leanin talo :

SAFe on johdettu Lean-valmistusperiaatteista ja -käytännöistä. Näiden tekijöiden perusteella SAFe esittelee "SAFe Leanin talon". Se on innoittamana laihan Toyotan "talo".

Lean-tavoitteen saavuttaminen on lyömätöntä: Maksimoida asiakasarvo asiakkaalle mahdollisimman lyhyessä ajassa ja mahdollisimman laadukkaalla tavalla

Alla olevassa kuvassa selitetään SAFe House of Lean -tavoite, pilarit ja perusta.

Ketterä manifesti

Löydämme parempia tapoja kehittää ohjelmistoja tekemällä niitä ja auttamalla muita tekemään se. Tämän työn kautta olemme tulleet arvostamaan:

Siksi, vaikka oikeanpuoleisissa kohteissa on arvo, arvostamme vasemmalla olevia kohteita enemmän.

Ketterä manifesti

1. Tärkeintä on tyydyttää asiakasta toimittamalla arvokkaita ohjelmistoja jatkuvasti ja varhaisessa vaiheessa.
2. Ota huomioon muuttuvat vaatimukset, jopa myöhään kehityksessä. Ketterä SAFe-menetelmä käsittelee muutosten hyödyntämisen asiakkaan eduksi.
3. Toimita työohjelmisto usein, muutamasta viikosta pariin kuukauteen, mieluummin lyhyemmän aikataulun mukaan.
4. Kehittäjien ja liikemiesten on työskenneltävä päivittäin yhdessä koko projektin ajan.
5. Rakenna projekteja motivoituneiden ihmisten ympärille. Anna heille tukea ja tarvitsemaansa ympäristöä ja luota heihin työn tekemiseen.
6. Tehokkain tapa kommunikoida kehitystiimin kanssa on kasvokkain käytävä keskustelu.
7. Toimiva ohjelmisto on edistymisen ensisijainen mittari.
8. Ketterät prosessit edistävät kestävää kehitystä. Sponsorien, kehittäjien ja käyttäjien tulisi pystyä pitämään tasainen tauko loputtomiin.
9. Jatkuva huomio tekniseen huippuosaamiseen ja hyvään muotoiluun parantaa ketteryyttä.
10. Yksinkertaisuus - taiteen maksimoida tekemättömän työn määrä - on oleellista.
11. Parhaat organisaatiot, vaatimukset ja mallit syntyvät itseorganisoituvista tiimeistä.
12. Tiimi pohtii säännöllisin väliajoin, kuinka tulla tehokkaammaksi, virittää ja säätää käyttäytymistään vastaavasti.

Eri tasot SAFE-tilassa

SAFe-toteutusta on kahta erilaista:

1. SAFe 4.0 -toteutus
2. SAFe 3.0 -toteutus

• SAFe 4.0 -toteutuksessa meillä on 4 tasoa: salkku, arvovirta , ohjelma ja tiimi.
• SAFe 3.0 -toteutuksessa meillä on 3 tasoa: salkku, ohjelma ja tiimi
• 3-tasoinen SAFe on tarkoitettu pienempiin toteutuksiin, joissa on enintään 100 henkilöä. Ohjelmat, jotka eivät vaadi merkittävää yhteistyötä.
• 4-tasoinen SAFe on ratkaisuille, jotka vaativat tyypillisesti satoja harjoittajia kehittämään käyttöönotto- ja ylläpito-ohjelmistoja.

Joukkueen taso

Roolit / joukkueet		Tapahtumat		Artefaktit
* Ketterä joukkue		* Sprintin suunnittelu		* Joukkueen myöhästyminen
* Tuotteen omistaja		* Hukkasiirto		* Ei-toiminnalliset vaatimukset
* Scrum Master		* Päivittäinen stand-up		* Joukkueen PI-tavoitteet
		* Suoritus		* Iteraatiot
		* Sprint-esittely		* Tarinat (toimiva ohjelmisto)
		* Sprint retrospektiivinen		* Sprintin tavoitteet
		* IP-sprintit		* Sisäänrakennettu laatu
				* Piikit
				* Kanban-joukkue

• Kaikki SAFe-tiimit ovat osa yhtä tai toista ketterää vapautusjunaa (ART).
• SAFe-tiimit ovat valtuutettuja, itseorganisoituvia, itsehallitsevia, toimivia
• Jokainen joukkue on yhtä vastuussa joukkueidensa kertomusten tarinoiden määrittelemisestä, rakentamisesta ja testaamisesta kiinteän pituisina iteraatioina
• Joukkueet suunnittelevat ja toteuttavat kahden viikon aikaruutuiset iteraatiot sovittujen iteraatiotavoitteiden mukaisesti.
• Joukkueet käyttävät ScrumXP / Team Kanban -rutiinia toimitettaessa korkealaatuisia järjestelmiä tuottaakseen järjestelmän esittelyn kahden viikon välein.
• Kaikki ART: n (ketterät vapautusjunat) eri ryhmät luovat integroidun ja testatun järjestelmän. Sidosryhmät arvioivat ja vastaavat nopealla palautteella
• Ne soveltavat sisäänrakennettuja laatukäytäntöjä.
• Jokaisessa ScrumXP-tiimissä on 5–9 tiimin jäsentä, joka sisältää kaikki tarvittavat roolit laadun lisäarvon muodostamiseksi jokaisessa iteraatiossa.
• ScrumXP-roolit sisältävät:
  • Joukkue (Dev + QA)
  • Scrum Master
  • Tuotteen omistaja. Jne…
• SAFe jakaa kehityksen aikajanan sarjaksi iteraatioita PI: ssä (Program Increment).
• PI-kesto on 8-12 viikkoa.
• Tiimi käyttää tarinoita tuottaakseen arvon. Tuotteen omistajalla on sisältövaltuudet tarinoiden luomisessa ja hyväksymisessä.
• Tarinat sisältävät asiakkaan vaatimukset.
• Team Backlog sisältää käyttäjä- ja käyttöönottotarinoita, jotka tunnistetaan PI-suunnittelun aikana. Kun tuotehallinta esittää etenemissuunnitelman, visio- ja ohjelmaa.
• Tarinoiden tunnistaminen, laatiminen, priorisointi, ajoitus, toteuttaminen, testaaminen ja hyväksyminen ovat johtotason ensisijaisia ​​vaatimuksia tiimitasolla.
• Jokainen iterointi tarjoaa:
  • Uuden toiminnallisuuden arvokas lisäys
  • Suorita jatkuvasti toistuvan mallin avulla
  • Suunnittele iterointi
  • Sitoudu tiettyihin toimintoihin
  • Suorita iterointi rakentamalla ja testaamalla tarinoita
  • Esittele uusi toiminto
  • Retrospektiivinen
  • Toista seuraava iterointi
• Joukkueet tukevat myös järjestelmän esittelyä jokaisen iteraation lopussa. mikä on ART: n kriittinen integraatiopiste.
• Suuremmissa arvovirroissa on useita ART: ita.
• Innovaatioiden ja suunnittelun (IP) iteraatiot hyödyntävät tiimejä mahdollisuuden innovaatioihin ja etsintään.

Ohjelmataso

Roolit / joukkueet		Tapahtumat		Artefaktit
* DevOps		* PI (Program Increment) -suunnittelu		* Näkemys
* Järjestelmätiimi		* Järjestelmän esittelyt		* Tiekartta
* Julkaisujen hallinta		* Tarkasta ja hyväksy työpaja		* Mittarit
* Tuotehallinta		* Arkkitehtoninen kiitotie		* Virstanpylväät
* UEX-arkkitehti		* Vapauta milloin tahansa		* Tiedotteet
* Vapauta juna-insinööri (RTE)		* Ketterä irrotusjuna		* Ohjelmaepos
* Järjestelmäarkkitehti / insinööri		* Vapauta		* Kanban-ohjelma
* Yrityksen omistajat				* Ohjelman myöhästyminen
* Ketterät johtajat				* Ei-toiminnalliset vaatimukset
* Harjoitteluyhteisöt				* Painotettu lyhin työ ensin (WSJF)
* Jaetut palvelut				* Ohjelman PI-tavoitteet
* Asiakas				* Ominaisuus
				* Mahdollistaja
				* Ratkaisu
				* Value Stream -koordinointi

• Ohjelmatasolla SAFe: n arvo toimitetaan pitkäikäisillä ketterillä vapautusjunilla (ART). Iteraatio on joukkueelle ja juna ohjelmaa varten.
• Ketterät vapautusjunat (ART) ovat ensisijainen ajoneuvo arvon toimittamiseen ohjelmatasolla. Se toimittaa arvovirran organisaatiolle.
• Ohjelman lisäykset (PI) kestävät 8-12 viikkoa.
• ART koostuu 5 - 12 ketterästä joukkueesta (~ 50 - 125+ ihmistä), joka sisältää kaikki roolit ja infrastruktuurin, joita tarvitaan täysin testattujen, toimivien järjestelmätason ohjelmistojen toimittamiseen.
• Jokainen PI on usean iteraation aikaruutu. Sen aikana kehitetään ja toimitetaan merkittävä, arvokas järjestelmän lisäys.
• Kussakin PI: ssä tapahtuu "esittely" - ja "Tarkasta ja mukauta" -istunnot ja seuraavan PSI: n suunnittelu alkaa.
• Ohjelmatasolla SAFe painottaa yhdenmukaistamisen periaatetta. Tämä johtuu siitä, että asiakkaan arvon luomiseksi on integroitu useita ketteriä tiimityötä.
• SAFe-artefaktihierarkia on Epics-> ominaisuudet-> käyttäjätarinoita .
• Ohjelmatasolla tuotepäälliköllä / ohjelmapäälliköllä on sisältövaltuudet. Hän määrittelee ja priorisoi ohjelman myöhästymisen.
• Ohjelman myöhästyminen on priorisoitu luettelo ominaisuuksista.
• Ohjelmatasolla ominaisuudet voivat olla peräisin tai ne voivat johtua portfolion tasolla määritellyistä eepoista.
• Ominaisuudet hajoavat käyttäjäkertomuksiksi ja siirtyvät tiimitason myöhästymisiin.
• Tuotepäällikkö tai Release Train Engineer -rooli voidaan hoitaa ohjelmapäällikkönä / vanhempana projektipäällikkönä
• Järjestelmäarkkitehdin tehtävä ohjelmatasolla on tehdä päivittäistä yhteistyötä tiimien kanssa. Se varmistaa, että ei-toiminnalliset vaatimukset täytetään. Lisäksi he työskentelevät yritysarkkitehdin kanssa portfolion tasolla varmistaakseen, että arkkitehtonista kiitotietä on riittävästi käyttäjien ja liiketoiminnan tulevien tarpeiden tukemiseksi.
• UX Designers tarjoaa käyttöliittymäsuunnittelun, käyttökokemusohjeet ja tiimien suunnitteluelementit.
• Chief-Scrum Master -roolissa on 'Release Train Engineer'.
• Erilaiset tiimit (markkinoinnista, kehityksestä, laadusta, toiminnasta ja käyttöönotosta) muodostavat julkaisun hallintaryhmän. He hyväksyvät laaturatkaisujen rutiininomaiset julkaisut asiakkaille.
• DevOps-tiimi huolehtii ohjelmistojen käyttöönotosta asiakasympäristöissä ja onnistuneesta toimituksesta.

Salkun taso

Roolit / joukkueet		Tapahtumat		Artefaktit
* Yritysarkkitehti		* Strateginen investointien suunnittelu		* Strategiset teemat
* Ohjelmaportfolion hallinto		* Kanban-salkun (eeppinen) suunnittelu		* Yritys
* Eeppiset omistajat				* Salkun myöhästyminen
				* Portfolio Kanban
				* Ei-toiminnalliset vaatimukset
				* Eeppinen ja mahdollistava
				* Arvovirta
				* Budjetit (CapEx ja OpEx)

• Korkein kiinnostus / huolenaihe / osallistuminen / SAFe: een on SAFe-salkku
• Salkku tarjoaa peruslohkot Lean-Agile Enterprise -arvovirran järjestämiseksi yhden tai useamman arvovirran kautta.
• Salkku auttaa kehittämään järjestelmiä ja ratkaisuja, jotka kuvataan strategisissa teemoissa (linkittää SAFe-salkun yrityksen muuttuvaan liiketoimintastrategiaan).
• Strategisten tavoitteiden saavuttamiseksi salkutaso kiteyttää nämä elementit. Se tarjoaa perusbudjetoinnin ja muut hallintomekanismit. Näin se varmistaa, että sijoitus arvovirtoihin tarjoaa yritykselle tarvittavan tuoton.
• Salkku on kytketty liiketoimintaan kaksisuuntaisesti:
  • Salkun ohjaamiseksi suurempiin muuttuviin liiketoiminnan tavoitteisiin se tarjoaa strategisia teemoja.
  • Toinen suunta osoittaa salkun arvojen jatkuvan virtauksen.
• Ohjelmasalkun hallinta toimii sidosryhminä, ja he ovat vastuussa liiketoiminnan tulosten saavuttamisesta.
• SAFe Portfolio -taso sisältää ihmisiä, prosesseja ja tarvittavia järjestelmiä ja ratkaisuja, joita yritys tarvitsee strategisten tavoitteidensa saavuttamiseksi.
• Arvovirrat ovat ensisijaisia ​​tavoitteita Portfoliossa, jolla rahoitusta ihmisille ja muita resursseja tarvitaan ratkaisujen rakentamiseen.
• Tärkeitä tässä käytettyjä keskeisiä käsitteitä ovat:
  • Yhteys yritykseen,
  • Ohjelmasalkun hallinta,
  • Portfolioeposien virtauksen hallinta.

Arvovirran taso

Roolit / joukkueet		Tapahtumat		Artefaktit
* DevOps		* Pre- ja Post PI (Program Increment) -suunnittelu		* Näkemys
* Järjestelmätiimi		* Ratkaisudemot		* Tiekartta
* Julkaisujen hallinta		* Tarkasta ja hyväksy työpaja		* Mittarit
* Ratkaisujen hallinta		* Ketterä irrotusjuna		* Virstanpylväät
* UEX-arkkitehti				* Tiedotteet
* Value Stream Engineer (RTE)				* Value Stream -epos
* Ratkaisuarkkitehti / insinööri				* Arvo Stream Kanban
* Jaetut palvelut				* Value Stream -tapaus
* Asiakas				* Ei-toiminnalliset vaatimukset
* Toimittaja				* Painotettu lyhin työ ensin (WSJF)
				* Value Stream PI -tavoitteet
				* Kyky
				* Mahdollistaja
				* Ratkaisukonteksti
				* Value Stream -koordinointi
				* Taloudellinen kehys
				* Ratkaisun tarkoitus
				* MBSE
				* Sarjapohjainen
				* Ketterä arkkitehtuuri

• Value Stream Level on valinnainen SAFe-ohjelmassa.
• Value Stream Level on uusi SAFe 4.0: ssa.
• Value Stream -taso on tarkoitettu / suunniteltu yrityksille / rakentajille / organisaatioille, jotka ovat:

1. Suuri koko
2. Itsenäinen
3. On monimutkaisia ​​ratkaisuja
4. Niiden ratkaisut vaativat tyypillisesti useita ART: ita
5. Heillä on toimittajien osuus.
6. He kohtaavat suurimmat järjestelmähaasteet
7. Kyberfyysisiin järjestelmiin
8. Ohjelmistoille, laitteistoille, sähkö- ja elektroniikkalaitteille, optiikalle, mekaniikalle, fluidille ja muulle.

• Tällaisten järjestelmien rakentaminen vie usein satoja, jopa tuhansia ammattilaisia, ulkoisia ja sisäisiä toimittajia.
• Jos järjestelmät ovat tärkeitä tehtävän kannalta. Ratkaisun tai jopa alijärjestelmän epäonnistumisella on hyväksyttäviä taloudellisia ja sosiaalisia seurauksia.
• Jos yritykset voidaan rakentaa muutaman sadan harjoittajan kanssa, se ei ehkä tarvitse tämän tason rakenteita. Siinä tapauksessa he voivat käyttää ' tiivistetystä näkymästä', joka on 3-tasoinen SAFe.
• Arvovirtaratkaisujen rakentaminen Lean-Agile-mallissa vaatii lisää esineitä, koordinointia ja rakenteita. Joten tämä taso sisältää taloudellisen kehyksen, joka tarjoaa taloudelliset rajat Value Streamille
• Se tukee poljinnopeutta ja synkronointia useille ART: ille ja toimittajille. Se sisältää Pre-ja Post-PI Planning -tapaamiset ja Solution Demo.
• Se antaa lisärooleja, jotka ovat: Value Stream Engineer, Solution Architect / Engineering ja Solution Management.

Yhteenveto:

• SAFe on toimialalla todistettu, arvokeskeinen menetelmä ketterän skaalausyritykseksi yritystasolla.
• Se vastaa kysymyksiin, kuten "Kuinka aiomme suunnitella?", "Kuinka budjetoimme?" Ja "Kuinka meistä tulee monitoimisia arkkitehtuurissa ja DevOpsissa?"
• SAFe Agile -kehys auttaa suuria organisaatiotiimejä saavuttamaan organisaation strategiset tavoitteet, ei vain yksittäisten projektien tavoitteita.
• Kehys tarjoaa mahdollisuuden ylläpitää ja luoda keskitetty strategia arvon tuottamiseksi.
• SAFe-mallissa on kolme / neljä tasoa, jotka keskittävät organisaation strategiset teemat.
• Keskitetty strategia yhdistettynä hajautettuun ketterään kehitystyöhön.

Viitteet:

SAFe for Lean Enterprises 5.0:

http://www.scaledagileframework.com

Tämän artikkelin on kirjoittanut Jyothi Rangaraj