SAFe (Scaled Agile Framework) vejledning

Hvad er SAFe (Scaled Agile Framework)?

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

Sikker rammer giver teamet mulighed for,

• Implementering af Lean-Agile software og systemer på virksomhedsniveau
• Det er baseret på Lean og Agile principper.
• Den giver detaljeret vejledning til arbejde i virksomhedens Portfolio, Value Stream, Program og Team.
• Det er designet til at opfylde behovene hos alle interessenter i en organisation.

SAFe blev først udviklet på området og blev udviklet i Dean Leffingwell's 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å virksomhedsportefølje-, værdistrøms-, program- og teamniveau.

Hvorfor bruge SAFe Agile Framework

Det er et enkelt og let rammeværk, men alligevel er det i stand til at håndtere behovene fra store værdistrømme og kompleks systemudvikling. Ved at implementere SAFe agile rammeværk vil du have følgende fordele:

• Produktiviteten steg by 20 - 50%
• Kvalitet steget mere end 50%
• Tid til marked er hurtigere end 30 -75%
• Øget medarbejderengagement og arbejdsglæde.

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

Billedet nedenfor forklarer, hvordan agil proces fungerer. Epos er et stort værk, som er yderligere opdelt i en række mindre historier eller undereposer. Disse undereposer er tildelt 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 multi-team programmer og porteføljer.
• Når flere teams kører deres egen måde at agil implementering på, men regelmæssigt står over for forhindringer, forsinkelser og fejl.
• Når teams ønsker at arbejde selvstændigt.
• Når du ønsker at skalere Agile på tværs af organisationen, men ikke er sikker på, hvilke nye roller der kan være nødvendige, eller hvilke eksisterende roller (dvs. ledelse) skal ændres og hvordan.
• Når du har forsøgt at skalere det agile på tværs af din organisation, men kæmper for at opnå ensartet eller konsistent 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 er lykkedes med at skalere Agile med SAFe.

Hvor anderledes end andre agile praksisser

Lad os nu i denne Scaled Agile Framework-vejledning se, hvordan Scaled Agile Framework er forskellig fra andre agile praksisser,

• Det er offentligt tilgængeligt og gratis at bruge.
• Fås i en yderst tilgængelig og brugbar form.
• Det er let, praktisk gennemprøvede resultater og niveauspecifikt.
• Det ændrer/vedligeholder konstant/regelmæssigt de mest almindeligt anvendte agile praksisser.
• Tilbyder nyttige udvidelser til almindelig agile praksis.
• Grundlægger agile praksisser til en virksomhedskontekst.
• Giver et komplet billede af softwareudvikling.
• Synlighed eller gennemsigtighed er mere på alle niveauer.
• Fortsat eller regelmæssig feedback om kvalitet og forbedringer.

Foundations af Scaled Agile Framework

Scaled Agile Framework(SAFe): Det står på grundlaget af dets

1. Lean-Agile principper
2. Kerneværdier,
3. Lean-agilt ledelse
4. Lean-Agile tankesæt,
5. Praksisfællesskaber (en gruppe af mennesker, der konstant arbejder med SAFe-praksisser)
6. Implementering af 1-2-3

SAFe Lean-Agile principper

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

• Tag et økonomisk synspunkt
• 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 videnmedarbejdernes iboende motivation
• Decentraliser beslutningstagning

SAFe Agile kerneværdier

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

Justering:

• SAFe understøtter justering.
• Opstilling starter kl.
  • Strategiske temaer i Portfolio Backlog og
  • Flytter ned til Vision og køreplan for programefterslæb og derefter
  • Flytter til Team Backlogs.

Indbygget kvalitet:

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

Gennemsigtighed:

• Gennemsigtighed er grundlaget for tillid.
• SAFe hjælper virksomheden med at opnå gennemsigtighed på alle niveauer - ledere, porteføljeforvaltere og andre interessenter.
• Alle kan se ind i porteføljebacklog/Kanban, programbacklog/Kanban og Team Backlog/Kanban.
• Hvert niveau har en klar forståelse af PI-målene.
• Togprogrammer har synlighed i teamets efterslæb såvel som andre programefterslæb
• Hold og programmer har synlighed i forretnings- og arkitektur-Epics. De kan se, hvad der kan være på vej.

Programudførelse:

• SAFe sætter stort fokus på arbejdssystemer og resulterende forretningsresultater.
• SAFe er ikke nyttigt, hvis teams ikke kan eksekvere og konstant levere værdi.

Lean agile ledere

Lean-Agile ledere er livslange elever og lærere. Det hjælper teams med at bygge bedre systemer gennem forståelse og udstilling af Lean-Agile SAFe-principperne.

Som en muliggører for teamene er det ultimative ansvar vedtagelse, succes og løbende forbedring af Lean-Agile-udviklinger. For forandring og løbende forbedring skal ledere uddannes.

Ledere skal antage en ny ledelsesstil. En, der virkelig styrker og engagerer enkeltpersoner og teams til at nå deres højeste potentiale.

Principper for disse Lean-Agile ledere

• Led forandringen
• Kend Vejen; Læg vægt på livslang læring
• Udvikle mennesker
• Inspirer og afstem med mission; Minimer begrænsninger
• Decentraliser beslutningstagning
• Lås op for vidensarbejdernes iboende motivation

Lean Agile Mind-Set

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

1. The SAFe House of Lean
2. Agilt manifest

SAFe Lean-huset:

SAFe er afledt af Lean-produktionsprincipper og -praksis. På baggrund af disse faktorer præsenterer SAFe "SAFe House of Lean". Den er inspireret af "hus" af slank Toyota.

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

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

Agilt manifest

Vi afdækker bedre måder at udvikle påping software ved at gøre det og hjælpping andre gør det. Gennem dette arbejde er vi kommet til at værdsætte:

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

Agilt manifest

1. Den højeste prioritet er at tilfredsstille kunden gennem kontinuerlig og tidlig levering af værdifuld software.
2. Omfavn de skiftende krav, selv sent i udviklingen. Agile SAFe-metodeprocesser udnytter ændringer til kundens fordel.
3. Lever fungerende software ofte, fra et par uger til et par måneder, med en præference til den kortere tidsskala.
4. Udviklere og forretningsfolk skal arbejde sammen dagligt gennem hele projektet.
5. Byg projekter omkring motiverede personer. Giv dem støtte og det miljø, de har brug for, og stol på, at de får 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 bør være i stand til at opretholde et konstant tempo på ubestemt tid.
9. Kontinuerlig opmærksomhed på teknisk ekspertise og godt design øger smidigheden.
10. Enkelhed – kunsten at maksimere mængden af ​​ikke udført arbejde – er afgørende.
11. De bedste arkitekturer, krav og design kommer fra selvorganiserende teams.
12. Med jævne mellemrum reflekterer teamet over, hvordan man bliver mere effektivt, og tuner og justerer derefter sin adfærd i overensstemmelse hermed.

Forskellige niveauer i SAFE

Der er to forskellige typer af SAFe-implementering:

1. SAFe 4.0 implementering
2. SAFe 3.0 implementering

• I SAFe 4.0-implementering har vi 4-niveauer: Portefølje, værdistrøm, program og team.
• I SAFe 3.0-implementering har vi 3-niveauer: Portefølje, program og team
• 3-Level SAFe er til mindre implementeringer med 100 eller færre personer. Programmer, der ikke kræver væsentligt samarbejde.
• 4-Level SAFe er til løsninger, der typisk kræver mange hundrede praktiserende læger til at udvikle implementering og vedligeholdelse af software.

Holdniveau

Roller/hold	Events	Artifacts
Agilt team	Sprint Planlægning	Teamets efterslæb
Product Owner	Backlog Grooming	Ikke-funktionelle krav
Scrum Master	Daglig stand-up	Team PI-mål
	Udførelse	gentagelser
	Sprint Demo	Historier (fungerende software)
	Sprint Tilbagevirkende kraft	Sprint Mål
	IP Sprints	Indbygget kvalitet
		Spikes
		Team Kanban

• Alle SAFe-hold er en del af et eller andet Agile Release Train (ART).
• SAFe-teams er bemyndigede, selvorganiserende, selvadministrerende, tværfunktionelle teams
• Hvert team er lige ansvarligt for at definere, bygge og teste historier fra deres Team Backlog i en fast længde iterationer
• Teams planlægger og udfører to-ugers time-boxede iterationer i overensstemmelse med aftalte iterationsmål.
• Teams vil bruge ScrumXP/Team Kanban-rutinen til at levere systemer af høj kvalitet til at producere en systemdemo på hver anden uge.
• Alle forskellige hold i ART (Agile Release Trains) vil skabe et integreret og testet system. Interessenter vil evaluere og reagere 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 kvalitetsinkrementelværdi i hver iteration.
• ScrumXP roller inkluderer:
  • Team (Udvikling + 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.
• Teamet vil bruge historier til at levere værdien. Produktejeren vil have indholdsautoritet over deres skabelse og accept af historierne.
• Historier indeholder kundens krav.
• Team Backlog inkluderer bruger- og aktiveringshistorier, som identificeres under PI-planlægning. Når produktledelsen præsenterer køreplanen, visionen og programefterslæbet.
• At identificere, uddybe, prioritere, planlægge, implementere, teste og acceptere historierne er de primære krav til ledelsesarbejde på teamniveau.
• Hver iteration giver:
  • Et værdifuldt tilskud af ny funktionalitet
  • Opnå via konstant gentagne mønster
  • Planlæg iterationen
  • Forpligt dig til noget funktionalitet
  • Udfør iterationen ved at bygge og teste historier
  • Demo den nye funktionalitet
  • Tilbagevirkende kraft
  • Gentag for næste iteration
• Teams understøtter også systemdemoen i slutningen af ​​hver iteration. som er det kritiske integrationspunkt for ART.
• Større værdistrømme vil have flere ART'er.
• Gentagelserne af innovation og planlægning (IP) udnytter holdene med mulighed for innovation og udforskning.

Program niveau

Roller/hold	Events	Artifacts
DevOps	PI (Program Increment) Planlægning	Vision
Systemteam	Systemdemoer	køreplan
Release Management	Inspicer og adopter værksted	Metrics
Product Management	Architeknisk landingsbane	Milepæle
UEX Architect	Udgiv når som helst	Udgivelser
Udgivelsestogingeniør (RTE)	Agile udgivelsestog	Program Epics
Systemkrav Architect/ingeniør	Slip	Program Kanban
Virksomhedsejere		Programefterslæb
Lean-Agile Ledere		Ikke-funktionelle krav
Practice of Communities		Vægtet korteste job først (WSJF)
Delte tjenester		Program PI-mål
Kunden		Feature
		Aktiverer
		Løsning
		Koordinering af værdistrømme

• På programniveau leveres værdien af ​​SAFe af langlivede Agile Release Trains (ART). Iteration er for hold og tog er for programmet.
• Agile Release Trains (ART) er det primære værktøj til værdilevering på programniveau. Det leverer en værdistrøm til organisationen.
• Program Increments (PI'er) varighed er på 8 til 12 uger.
• ART består af 5 – 12 agile teams (~50 – 125+ personer), som omfatter alle de roller og infrastruktur, der er nødvendig for at levere fuldt testet, fungerende software på systemniveau.
• Hver PI er en tidsboks med flere iterationer. I løbet af hvilken en betydelig, værdifuld stigning af systemet udvikles og leveres.
• 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->funktioner->brugerhistorier.
• På programniveau har Product Manager/Program Manager indholdsautoritet. Han definerer og prioriterer programefterslæbet.
• Program backlog er en prioriteret liste over funktioner.
• På programniveau kan funktioner stammer fra, eller de kan stamme fra epos defineret på porteføljeniveau.
• Funktioner nedbrydes til brugerhistorier og flyder ind i efterslæb på teamniveau.
• Rollen Produktchef eller Release Train Engineer kan varetages af Program Manager/Senior Project Manager
• Systemkrav Architect rolle på programniveau er at samarbejde dagligt med teamene. 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 bane til at understøtte kommende bruger- og forretningsbehov.
• Interfacedesign, retningslinjer for brugeroplevelse og designelementer til teamene leveres af UX Designers.
• Chief-Scrum Master-rollen spilles af 'Release Train Engineer'.
• Forskellige teams (fra marketing, udvikling, kvalitet, drift og implementering) danner 'Release Management Team'. De vil godkende rutineudgivelser af kvalitetsløsninger til kunder.
• Udrulning af software i kundemiljøer og vellykket levering varetages af DevOps-teamet.

Porteføljeniveau

Roller/hold	Events	Artifacts
Enterprise Architect	Strategisk investeringsplanlægning	Strategiske temaer
Programporteføljestyring	Kanban-porteføljeplanlægning (episk)	Enterprise
Episke ejere		Porteføljebacklog
		Portefølje Kanban
		Ikke-funktionelle krav
		Episk og muliggørende
		Værdi strøm
		Budgetter (CapEx og OpEx)

• Det højeste niveau af interesse/ bekymring / involvering/ i SAFe er SAFe Portfolio
• Portfolioen giver de grundlæggende blokke til at organisere Lean-Agile Enterprise værdiflowet via en eller flere værdistrømme.
• Porteføljen hjælper med at udvikle systemer og løsninger, som er beskrevet i strategiske temaer (knytter en SAFe-portefølje til en virksomheds skiftende forretningsstrategi).
• For at opfylde strategiske mål indkapsler 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 i to retninger:
  • For at guide porteføljen til de større skiftende forretningsmål, giver den strategiske temaer.
  • En anden retning indikerer den konstante strøm af porteføljeværdier.
• Program Portfolio Management fungerer som interessenter, og de er ansvarlige for at levere forretningsresultaterne.
• SAFe Portfolio Level indeholder mennesker, processer og nødvendige byggesystemer og løsninger, som en virksomhed har brug for for at opfylde sine strategiske mål.
• Værdistrømme er de primære mål i Portfolio, hvormed finansiering af de mennesker og andre ressourcer, der kræves for at bygge løsningerne.
• Vigtige nøglebegreber brugt her er:
  • Forbindelse til virksomheden,
  • Program Portfolio Management,
  • Håndtering af flowet af porteføljeepos.

Værdistrømsniveau

Roller/hold	Events	Artifacts
DevOps	Planlægning før og efter PI (programforøgelse)	Vision
Systemteam	Løsningsdemoer	køreplan
Release Management	Inspicer og adopter værksted	Metrics
Løsningsstyring	Agile udgivelsestog	Milepæle
UEX Architect		Udgivelser
Værdistrømsingeniør (RTE)		Værdistrømseposer
Løsning Architect/ingeniør		Værdistrøm Kanban
Delte tjenester		Værdistrømsefterslæb
Kunden		Ikke-funktionelle krav
Leverandør		Vægtet korteste job først (WSJF)
		Mål for værdistrøms-PI
		Capability
		Aktiverer
		Løsningskontekst
		Koordinering af værdistrømme
		Økonomisk ramme
		Løsningsintention
		MBSE
		Sætbaseret
		Agile Architecture

• Værdistrømsniveauet er valgfrit i SAFe.
• Value Stream Level er nyt i SAFe 4.0.
• Værdistrømsniveauet er beregnet/designet til virksomheder/byggere/organisationer, der er:

1. Stor i størrelsen
2. Independent
3. Har komplekse løsninger
4. Deres løsninger kræver typisk flere ART'er
5. De har leverandørbidrag.
6. De står over for de største systemudfordringer
7. Til cyberfysiske systemer
8. Til software, hardware, elektrisk og elektronik, optik, mekanik, fluidik og mere.

• Opbygning af denne slags systemer kræver ofte hundredvis, ja tusindvis af praktikere, eksterne og interne leverandører.
• Hvis systemerne er mission afgørende. Fejl i løsningen, eller endda et delsystem, har uacceptable økonomiske og sociale konsekvenser.
• Hvis Enterprises kan bygges med et par hundrede praktikere, behøver det muligvis ikke konstruktionerne på dette niveau. I så fald kan de bruge fra 'sammenbrudt 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 økonomiske grænser for værdistrøm
• Det understøtter kadence og synkronisering for flere ART'er og leverandører. Det inkluderer præ- og post-PI-planlægningsmøder og løsningsdemo.
• Det giver yderligere roller, som er: Value Stream Engineer, Solution Architect/Engineering og Solution Management.

Ofte Stillede Spørgsmål