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
- Lean-Agile principper
- Kernevรฆrdier,
- Lean-agilt ledelse
- Lean-Agile tankesรฆt,
- Praksisfรฆllesskaber (gruppe af mennesker, der konstant arbejder pรฅ SAFe-praksis)
- 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:
- The SAFe House of Lean
- Agilt manifest
The SAFe House of Lean:
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
- Den hรธjeste prioritet er at tilfredsstille kunden gennem kontinuerlig og tidlig levering af vรฆrdifuld software.
- Omfavn de skiftende krav, selv sent i udviklingen. Agile SAFe-metodeprocesser udnytter รฆndringer til kundens fordel.
- Lever fungerende software ofte, fra et par uger til et par mรฅneder, med en prรฆference til den kortere tidsskala.
- Udviklere og forretningsfolk skal arbejde sammen dagligt gennem hele projektet.
- 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.
- Den mest effektive metode til kommunikation med et udviklingsteam er en ansigt-til-ansigt samtale.
- Arbejdssoftware er det primรฆre mรฅl for fremskridt.
- 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.
- Kontinuerlig opmรฆrksomhed pรฅ teknisk ekspertise og godt design รธger smidigheden.
- Enkelhed โ kunsten at maksimere mรฆngden af โโikke udfรธrt arbejde โ er afgรธrende.
- De bedste arkitekturer, krav og design kommer fra selvorganiserende teams.
- 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:
- SAFe 4.0 implementering
- 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 | ||
|---|---|---|---|---|
| * Agile Team | * Sprint Planlรฆgning | * Team Backlog | ||
| * Produktejer | * Backlog Grooming | * Ikke-funktionelle krav | ||
| * Scrum Master | * Daglig stand-up | * Team PI-mรฅl | ||
| * Udfรธrelse | * Gentagelser | |||
| * Sprint Demo | * Historier (arbejdssoftware) | |||
| * Sprint Tilbagevirkende kraft | * Sprint Mรฅl | |||
| * IP Sprints | * Indbygget kvalitet | |||
| * Pigge | ||||
| * 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 (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.
- 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 workshop | * Metrics | ||
| * Produktledelse | * Architeknisk landingsbane | * Milepรฆle | ||
| * UEX Architect | * Frigiv nรฅr som helst | * Udgivelser | ||
| * Release Train Engineer (RTE) | * Agile Release Train | * Program Epics | ||
| * System Architect/ingeniรธr | * Slip | * Program Kanban | ||
| * Virksomhedsejere | * Programefterslรฆb | |||
| * Lean-Agile ledere | * Ikke-funktionelle krav | |||
| * Praksisfรฆllesskaber | * Vรฆgtet korteste job fรธrst (WSJF) | |||
| * Fรฆlles tjenester | * Program PI-mรฅl | |||
| * Kunde | * Funktion | |||
| * Aktiverer | ||||
| * Lรธsning | ||||
| * Koordinering af vรฆrdistrรธm |
- 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 | ||
| * Program Portfolio Mgmt | * Kanban Portfolio (Epic) Planlรฆgning | * Enterprise | ||
| * Episke ejere | * Portefรธljeefterslรฆb | |||
| * Portefรธlje Kanban | ||||
| * Ikke-funktionelle krav | ||||
| * Epic og Enabler | ||||
| * 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 | * Fรธr og efter PI (Program Increment) Planlรฆgning | *Vision | ||
| * Systemteam | * Lรธsningsdemoer | * Kรธreplan | ||
| * Release Management | * Inspicer og adopter workshop | * Metrics | ||
| * Lรธsningsstyring | * Agile Release Train | * Milepรฆle | ||
| * UEX Architect | * Udgivelser | |||
| * Value Stream Engineer (RTE) | *Vรฆrdistream-epos | |||
| * Lรธsning Architect/ingeniรธr | * Vรฆrdistrรธm Kanban | |||
| * Fรฆlles tjenester | * Value Stream Backlog | |||
| * Kunde | * Ikke-funktionelle krav | |||
| * Leverandรธr | * Vรฆgtet korteste job fรธrst (WSJF) | |||
| * Vรฆrdistrรธm PI-mรฅl | ||||
| * Evne | ||||
| * Aktiverer | ||||
| * Lรธsningskontekst | ||||
| * Koordinering af vรฆrdistrรธm | ||||
| * รkonomiske rammer | ||||
| * Lรธsningshensigt | ||||
| * MBSE | ||||
| * Sรฆt baseret | ||||
| * Adrรฆt 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:
- Stor i stรธrrelsen
- Independent
- Har komplekse lรธsninger
- Deres lรธsninger krรฆver typisk flere ART'er
- De har leverandรธrbidrag.
- De stรฅr over for de stรธrste systemudfordringer
- Til cyberfysiske systemer
- 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.
Resumรฉ
- SAFe er en brancheprรธvet, vรฆrdifokuseret metode til at skalere Agile pรฅ Enterprise-niveau.
- Den besvarer spรธrgsmรฅl som "Hvordan planlรฆgger vi?", "Hvordan budgetterer vi?", og "Hvordan bliver vi tvรฆrfunktionelle i arkitektur og DevOps?"
- SAFe Agile framework hjรฆlper store organisationsteams med at opfylde en organisations strategiske mรฅl, ikke kun individuelle projektmรฅl.
- Rammen giver mulighed for at opretholde og skabe en centraliseret strategi for at levere vรฆrdi.
- SAFe-modellen har tre/fire niveauer, der centraliserer de strategiske temaer i en organisation.
- Centraliseret strategi, kombineret med den decentraliserede agile udviklingsudfรธrelse.
Referencer:
SAFe for Lean Enterprises 5.0:

