SAFe Methodology Tutorial: Hvad er Scaled Agile Framework

Hvad er en Scaled Agile Framework (SAFe)?

Scaled Agile Framework (SAFe) er en frit tilgængelig online videnbase, der giver dig mulighed for at anvende lean-agile praksis på virksomhedsniveau. Det giver en enkel og let oplevelse til softwareudvikling. Det er et sæt organisationer og workflowmønstre, der er beregnet til at vejlede virksomheder i skalering af magert og smidig praksis. Det er opdelt i tre segmenter, som er Team, Program og portfolio.

SAFe- rammen tillader hold til,

• Implementering af Lean-Agile software og systemer på virksomhedsniveau
• Det er baseret på magre og smidige principper.
• Det giver detaljeret vejledning til arbejde i virksomhedens portefølje, Value Stream, Program og Team.
• Det er designet til at imødekomme behovene hos alle interessenter i en organisation.

SAFe blev først udviklet i marken og blev uddybet i Dean Leffingwells bøger og blog. Version 1.0 er den første officielle udgivelse i 2011. Den seneste version er 4.6, blev udgivet i oktober 2018. Den giver vejledning til at arbejde på enterprise Portfolio, Value Stream, Program og Team niveauer.

I denne SAFe Agile tutorial lærer du-

• Hvad er Scaled Agile Framework (SAFe)
• Hvorfor bruge Agile Framework
• Hvornår skal man bruge Scaled Agile Framework
• Hvor anderledes end andre agile metoder
• Fundament for Scaled Agile Framework
• Adræt manifest
• Forskellige niveauer i SAFE
• Teamniveau
• Programniveau
• Porteføljeniveau
• Værdistrømniveau

Hvorfor bruge Agile Framework

Det er enkle og lette rammer, men alligevel er det i stand til at håndtere behovene i store værdistrømme og kompleks systemudvikling. Ved at implementere SAFe agile rammer har du følgende fordele:

• Produktiviteten steg med 20 - 50%
• Kvaliteten steg mere end 50%
• Time to Market er hurtigere end 30-75%
• Øget medarbejderengagement og jobtilfredshed.

Det detaljerede rammediagram er tilgængeligt på hjemmesiden. Det viser alle nøgleroller, aktiviteter, leverancer og flow. Det fungerer også som en navigationshjælp til resten af ​​stedet.

Nedenstående billede forklarer, hvordan agil proces fungerer. Epics er et stort stykke arbejde, som yderligere opdeles i et antal mindre historier eller underepos. Disse undereposer tildeles holdet som en historie. Hvert team arbejder derefter på disse historier eller softwarefunktioner i overensstemmelse hermed.

Hvornår skal man bruge Scaled Agile Framework

• Når et team er interesseret i at implementere en agil tilgang konsekvent på tværs af større multiteam-programmer og porteføljer.
• Når flere hold kører deres egen måde til Agile implementering, men regelmæssigt står over for forhindringer, forsinkelser og fejl.
• Når hold ønsker at arbejde uafhængigt.
• Når du vil skalere Agile på tværs af organisationen, men ikke er sikker på, hvilke nye roller der kan være behov for, eller hvilke eksisterende roller (dvs. ledelse), der skal ændres, og hvordan.
• Når du har forsøgt at skalere Agile på tværs af din organisation, men kæmper for at få ensartet eller ensartet strategi på tværs af forretningsafdelinger fra portefølje til program- og teamniveauer.
• Når en organisation har brug for at forbedre sin produktudvikling ledetid og ønsker at vide, hvordan andre virksomheder har formået at skalere Agile med SAFe.

Hvor anderledes end andre agile metoder

Lad os nu se i denne Scaled Agile Framework-tutorial, hvordan Scaled Agile framework er forskellig fra andre agile fremgangsmåder,

• Det er offentligt tilgængeligt og gratis at bruge.
• Fås i en meget tilgængelig og brugbar form.
• Det er lette, praktisk gennemprøvede resultater og specifikke for niveau.
• Det ændrer / vedligeholder konstant / regelmæssigt de mest almindeligt anvendte agile metoder.
• Tilbyder nyttige udvidelser til almindelig agil praksis.
• Begrunder agil praksis i en virksomhedssammenhæng.
• Tilbyder komplet billede af softwareudvikling.
• Synlighed eller gennemsigtighed er mere på alle niveauer.
• Fortsat eller regelmæssig feedback om kvalitet og forbedring.

Fundament for Scaled Agile Framework

Scaled Agile Framework (SAFe): Det står på fundamentet for dets

1. Lean-Agile principper
2. Kerneværdier,
3. Lean-Agile Lederskab
4. Lean-Agile Mind-set,
5. Practices Communities (Gruppe af mennesker, der konstant arbejder på SAFe-praksis)
6. Implementering 1-2-3

SAFe Lean-Agile-principper

Disse grundlæggende SAFe Agile principper og værdier for SAFe skal forstås, udstilles og fortsættes for at opnå de ønskede resultater.

• Tag et økonomisk syn
• Anvend systemtænkning
• Antag variabilitet; bevare muligheder
• Byg trinvist med hurtige, integrerede læringscyklusser
• Baser milepæle på en objektiv evaluering af arbejdssystemer
• Visualiser og begræns WIP, reducer batchstørrelser og administrer kølængder
• Anvend kadence, synkroniser med planlægning på tværs af domæner
• Lås op for den videnskabelige arbejdstagers iboende motivation
• Decentraliser beslutningstagning

SAFe Agile kerneværdier

SAFe Agile-metoden er baseret på disse fire værdier.

Justering:

• SAFe understøtter justering.
• Justering starter kl.
  • Strategiske temaer i porteføljebaglog og
  • Flytter ned til Vision og køreplan for Program Backlogs og derefter
  • Flytter til Team Backlogs.

Indbygget kvalitet:

• Det sikrer, at hver inkrementel levering afspejler kvalitetsstandarderne.
• Kvalitet er ikke "tilføjet senere" er indbygget.
• Indbygget kvalitet er en forudsætning for Lean og dens obligatoriske

Gennemsigtighed:

• Gennemsigtighed er muliggør tillid.
• SAFe hjælper virksomheden med at opnå gennemsigtighed på alle niveauer - ledere, porteføljeadministratorer og andre interessenter.
• Alle kan se ind i porteføljens efterslæb / Kanban, programbacklogs / Kanban og Team Backlog / Kanban.
• Hvert niveau har en klar forståelse af PI-målene.
• Togprogrammer har synlighed i holdets backlogs såvel som andre programbacklogs
• Hold og programmer har indblik i forretnings- og arkitekturepics. De kan se, hvad der kan være på vej mod deres vej.

Programudførelse:

• SAFe lægger stort fokus på arbejdssystemer og resulterende forretningsresultater.
• SAFe er ikke nyttigt, hvis hold ikke kan udføre og løbende levere værdi.

Lean Agile Leaders:

De Lean-Agile Leaders er livslange lærere og lærere. Det hjælper hold med at opbygge bedre systemer gennem forståelse og udstilling af Lean-Agile SAFe-principperne.

Som en muliggør for holdene er det endelige ansvar vedtagelse, succes og løbende forbedring af Lean-Agile-udviklingen. Til forandring og kontinuerlig forbedring skal ledere trænes.

Ledere er nødt til at vedtage en ny ledelsesstil. En der virkelig bemyndiger og engagerer enkeltpersoner og teams til at nå deres højeste potentiale.

Principper for disse magert-agile ledere

• Led forandringen
• Kend vejen; Fremhæv livslang læring
• Udvikle mennesker
• Inspirer og tilpas med mission; Minimer begrænsninger
• Decentraliser beslutningstagning
• Lås op for den videnskabelige arbejdstagers indre motivation

Lean Agile Mind-Set:

Lean-Agile tankegang er repræsenteret i to ting:

1. SAFe House of Lean
2. Adræt manifest

SAFe House of Lean :

SAFe er afledt af Lean-fremstillingsprincipper og -praksis. Baseret på disse faktorer præsenterer SAFe "SAFe House of Lean". Det er inspireret af "huset" af magert Toyota.

Målet med lean er uovertruffen: At levere maksimal kundeværdi på den korteste leveringstid med den højest mulige kvalitet til kunden

Nedenstående figur forklarer målet, søjlerne og fundamentet for "SAFe House of Lean."

Adræt manifest

Vi afdækker bedre måder at udvikle software ved at gøre det og hjælpe andre med at gøre det. Gennem dette arbejde er vi kommet til værdi:

Derfor, mens der er en værdi i varerne til højre, værdsætter vi varerne til venstre mere.

Adræt manifest

1. Den højeste prioritet er at tilfredsstille kunden gennem kontinuerlig og tidlig levering af værdifuld software.
2. Overtag de skiftende krav, selv sent i udvikling. Agile SAFe-metodologi behandler ledningsændring til kundens fordel.
3. Lever arbejdssoftware ofte fra et par uger til et par måneder med en præference frem for den kortere tidsplan.
4. Udviklere og forretningsfolk skal arbejde sammen dagligt gennem hele projektet.
5. Byg projekter omkring motiverede individer. Giv dem støtte og det miljø, de har brug for, og stol på dem til at få arbejdet gjort.
6. Den mest effektive metode til kommunikation med et udviklingsteam er en ansigt til ansigt samtale.
7. Arbejdssoftware er det primære mål for fremskridt.
8. Agile processer fremmer bæredygtig udvikling. Sponsorer, udviklere og brugere skal være i stand til at opretholde et konstant tempo på ubestemt tid.
9. Løbende opmærksomhed på teknisk ekspertise og godt design forbedrer smidighed.
10. Enkelhed - kunsten at maksimere mængden af ​​arbejde, der ikke er udført - er afgørende.
11. De bedste arkitekturer, krav og design fremgår af selvorganiserende teams.
12. Med jævne mellemrum reflekterer holdet over, hvordan man bliver mere effektiv, indstiller derefter og justerer dets adfærd i overensstemmelse hermed.

Forskellige niveauer i SAFE

Der er to forskellige typer SAFe-implementering:

1. SAFe 4.0 implementering
2. SAFe 3.0 implementering

• I implementeringen af ​​SAFe 4.0 har vi 4-niveauer: Portefølje, Value Stream, Program og Team.
• I implementeringen af ​​SAFe 3.0 har vi 3-niveauer: portefølje, program og team
• 3-niveau SAFe er til mindre implementeringer med 100 eller færre personer. Programmer, der ikke kræver væsentligt samarbejde.
• 4-niveau SAFe er til løsninger, der typisk kræver, at mange hundrede praktikere udvikler implementering og vedligeholdelse af software.

Teamniveau

Roller / hold		Begivenheder		Artefakter
* Agilt hold		Sprintplanlægning		* Teambacklog
* Produktejer		* Efterladtepleje		* Ikke-funktionelle krav
* Scrum Master		* Daglig stand-up		* Team PI-mål
		* Udførelse		* Iterationer
		* Sprint-demo		* Historier (arbejdssoftware)
		* Sprint retrospektiv		* Sprintmål
		* IP-sprints		* Indbygget kvalitet
				* Spikes
				* Team Kanban

• Alle SAFe-hold er en del af et eller andet Agile Release Train (ART).
• SAFe-hold er bemyndiget, selvorganiserende, selvstyrende, tværfunktionelle hold
• Hvert hold er lige så ansvarligt for at definere, opbygge og teste historier fra deres Team Backlog i faste gentagelser
• Hold planlægger og udfører to-ugers it-boks-iterationer i overensstemmelse med aftalte Iterationsmål.
• Hold vil bruge ScrumXP / Team Kanban rutine til at levere systemer af høj kvalitet til at producere en System Demo hver anden uge.
• Alle forskellige hold i ART (Agile Release Trains) opretter et integreret og testet system. Interessenter vil evaluere og svare med hurtig feedback
• De anvender indbygget kvalitetspraksis.
• Hvert ScrumXP-team vil have 5-9 teammedlemmer, som inkluderer alle de roller, der er nødvendige for at opbygge en kvalitetsinkrementel værdi i hver gentagelse.
• ScrumXP-roller inkluderer:
  • Team (Dev + QA)
  • Scrum Master
  • Produktejer. Etc…
• SAFe opdeler udviklingstidslinjen i et sæt iterationer inden for en PI (Program Increment).
• PI-varighed er mellem 8-12 uger.
• Holdet bruger historier til at levere værdien. Produktejeren vil have indholdsmagt over deres oprettelse og accept af historierne.
• Historier indeholder kundens krav.
• Team Backlog inkluderer bruger- og aktivatorhistorier, som identificeres under PI-planlægning. Når produktledelsen præsenterer køreplanen, visionen og programforsinkelsen.
• Identifikation, uddybning, prioritering, planlægning, implementering, test og accept af historierne er de primære krav til ledelsesarbejde på teamniveau.
• Hver iteration giver:
  • En værdifuld forøgelse af ny funktionalitet
  • Opnå via konstant gentaget mønster
  • Planlæg iterationen
  • Forpligt dig til nogle funktioner
  • Udfør iteration ved at opbygge og teste historier
  • Demo den nye funktionalitet
  • Tilbagevirkende kraft
  • Gentag for næste iteration
• Hold understøtter også systemdemoen i slutningen af ​​hver gentagelse. hvilket er det kritiske integrationspunkt for ART.
• Større værdistrømme vil have flere ART'er.
• Innovation og planlægning (IP) -terationer udnytter holdene med en mulighed for innovation og udforskning.

Programniveau

Roller / hold		Begivenheder		Artefakter
* DevOps		* PI (Program Increment) planlægning		* Vision
* Systemteam		* Systemdemoer		* Køreplan
* Udgivelsesstyring		* Undersøg og vedtag workshop		* Metrics
* Produktstyring		* Arkitektonisk bane		Milepæle
* UEX-arkitekt		* Slip når som helst		* Udgivelser
* Slip togingeniør (RTE)		* Agile frigørelsestog		* Program Epics
* Systemarkitekt / ingeniør		* Slip		* Programmer Kanban
* Virksomhedsejere				* Programforsinkelse
* Lean-Agile ledere				* Ikke-funktionelle krav
* Practices Communities				* Vægtet korteste job først (WSJF)
* Delte tjenester				* Program PI-mål
* Kunde				* Funktion
				* Aktivator
				* Opløsning
				* Værdistrømskoordinering

• På programniveau leveres Value of SAFe af langlivede Agile Release Trains (ART). Iteration er for hold og tog er for programmet.
• Agile Release Trains (ART) er det primære middel til værdilevering på programniveau. Det leverer en værdistrøm til organisationen.
• Programinkrementer (PI'er) varer fra 8 til 12 uger.
• ART er fra 5 - 12 Agile Teams (~ 50 - 125+ personer), der inkluderer alle de roller og infrastruktur, der er nødvendige for at levere fuldt testet, fungerende software på systemniveau.
• Hver PI er en boks med flere gentagelser. I løbet af hvilken der udvikles og leveres en betydelig, værdifuld forøgelse af systemet.
• I hver PI vil der ske en "demo" og "Inspicer og tilpas" sessioner, og planlægningen begynder for den næste PSI.
• På programniveau lægger SAFe vægt på princippet om tilpasning. Dette skyldes, at flere agile teamindsatser er integreret for at skabe kundeværdi.
• SAFe artefakthierarki er Epics-> features-> brugerhistorier .
• På programniveau har Product Manager / Program Manager indholdsgodkendelse. Han definerer og prioriterer programforsinkelsen.
• Programbakke er en prioriteret liste over funktioner.
• På programniveau kan funktioner stamme, eller de kan stamme fra epos defineret på porteføljeniveau.
• Funktioner nedbrydes til brugerhistorier og strømmer ind i efterslæb på teamniveau.
• Produktchef eller frigivelsesteknikerrollen kunne håndteres af programleder / seniorprojektleder
• Systemarkitektrolle på programniveau er at samarbejde dagligt arbejde med holdene. Det sikrer, at ikke-funktionelle krav er opfyldt. De arbejder også med virksomhedsarkitekten på porteføljeniveau for at sikre, at der er tilstrækkelig arkitektonisk landingsbane til at understøtte kommende bruger- og forretningsbehov.
• Interface design, retningslinjer for brugeroplevelse og designelementer til holdene leveres af UX Designers.
• Chief-Scrum Master rolle spilles af 'Release Train Engineer'.
• Forskellige hold (fra marketing, udvikling, kvalitet, drift og implementering) danner 'Release Management Team'. De vil godkende rutinemæssige frigivelser af kvalitetsløsninger til kunder.
• Implementering af software i kundemiljøer og vellykket levering varetages af DevOps-teamet.

Porteføljeniveau

Roller / hold		Begivenheder		Artefakter
* Virksomhedsarkitekt		* Strategisk investeringsplanlægning		* Strategiske temaer
* Programportefølje Mgmt		* Kanban portefølje (episk) planlægning		* Virksomhed
* Episke ejere				* Porteføljebaglog
				* Portefølje Kanban
				* Ikke-funktionelle krav
				Epic og Enabler
				* Værdi strøm
				* Budgetter (CapEx og OpEx)

• SAFe Portfolio er det højeste niveau af interesse / bekymring / involvering / i SAFe
• Porteføljen giver de grundlæggende blokke til organisering af Lean-Agile Enterprise-strømmen af ​​værdi via en eller flere Value Streams.
• Porteføljen hjælper med at udvikle systemer og løsninger, der er beskrevet i strategiske temaer (forbinder en SAFe-portefølje med en virksomheds skiftende forretningsstrategi).
• For at opfylde strategiske mål indkapsles porteføljeniveau disse elementer. Det giver grundlæggende budgettering og andre styringsmekanismer. På denne måde sikrer det, at investeringen i værdistrømmene giver det nødvendige afkast for virksomheden.
• En portefølje er forbundet til forretning tovejs:
  • For at guide porteføljen til de større skiftende forretningsmål giver den strategiske temaer.
  • En anden retning angiver den konstante strøm af porteføljeværdier.
• Programporteføljestyring fungerer som interessenter, og de er ansvarlige for at levere forretningsresultaterne.
• SAFe-porteføljeniveau indeholder mennesker, processer og nødvendige byggesystemer og løsninger, som en virksomhed har brug for for at nå sine strategiske mål.
• Værdistrømme er de primære mål i porteføljen, hvormed finansiering til folk og andre ressourcer, der kræves for at opbygge løsningerne.
• Vigtige nøglebegreber brugt her er:
  • Forbindelse til virksomheden,
  • Programporteføljestyring,
  • Styring af Flow of Portfolio Epics.

Værdistrømniveau

Roller / hold		Begivenheder		Artefakter
* DevOps		* Planlægning før og efter PI (Program Increment)		* Vision
* Systemteam		* Løsningsdemoer		* Køreplan
* Udgivelsesstyring		* Undersøg og vedtag workshop		* Metrics
* Løsningsstyring		* Agile frigørelsestog		Milepæle
* UEX-arkitekt				* Udgivelser
* Value Stream Engineer (RTE)				* Value Stream Epics
* Løsningsarkitekt / ingeniør				* Værdistrøm Kanban
* Delte tjenester				* Efterspørgsel efter stream af værdi
* Kunde				* Ikke-funktionelle krav
* Leverandør				* Vægtet korteste job først (WSJF)
				* Value Stream PI-mål
				* Kapacitet
				* Aktivator
				* Løsningskontekst
				* Værdistrømskoordinering
				* Økonomisk ramme
				* Løsningens hensigt
				* MBSE
				* Sætbaseret
				* Agil arkitektur

• Value Stream-niveauet er valgfrit i SAFe.
• Value Stream Level er nyt i SAFe 4.0.
• Value Stream-niveauet er beregnet / designet til virksomheder / bygherrer / organisationer, der er:

1. Stor i størrelse
2. Uafhængig
3. Har komplekse løsninger
4. Deres løsninger kræver typisk flere ART'er
5. De har bidrag fra leverandører.
6. De står over for de største systemudfordringer
7. Til cyber-fysiske systemer
8. Til software, hardware, elektrisk og elektronik, optik, mekanik, fluidik og mere.

• Opbygning af denne type systemer tager ofte hundreder, endda tusinder af praktikere, eksterne og interne leverandører.
• Hvis systemerne er afgørende. Manglende løsning eller endog et undersystem har uacceptable økonomiske og sociale konsekvenser.
• Hvis virksomhederne kan bygges med et par hundrede udøvere, har det muligvis ikke brug for konstruktionerne på dette niveau. I så fald kan de bruge fra den ' kollapsede visning', som er 3-niveau SAFe.
• Opbygning af værdistrømsløsninger i et Lean-Agile-mønster kræver yderligere artefakter, koordinering og konstruktioner. Så dette niveau indeholder en økonomisk ramme til at give finansielle grænser for Value Stream
• Det understøtter kadence og synkronisering for flere ART'er og leverandører. Det inkluderer møder før og efter PI-planlægning og løsningsdemo.
• Det giver yderligere roller, som er: Value Stream Engineer, Solution Architect / Engineering og Solution Management.

Resumé:

• SAFe er en brancheprøvet, værdifokuseret metode til skalering af Agile på Enterprise-niveau.
• Det besvarer spørgsmålene som "Hvordan planlægger vi?", "Hvordan budgetterer vi?" Og "Hvordan bliver vi tværfunktionelle i arkitektur og DevOps?"
• SAFe Agile framework hjælper store organisationsteam med at opfylde en organisations strategiske mål, ikke kun individuelle projektmål.
• Rammen giver mulighed for at opretholde og skabe en central strategi til at levere værdi.
• SAFe-modellen har tre / fire niveauer, der centraliserer en organisations strategiske temaer.
• Centraliseret strategi kombineret med de-centraliseret udførelse af agil udvikling.

Referencer:

SAFe for Lean Enterprises 5.0:

http://www.scaledagileframework.com

Denne artikel er bidraget af Jyothi Rangaraj