SAFe (Scaled Agile Framework) veiledning

Hva er SAFe (Scaled Agile Framework)?

Scaled Agile Framework (SAFe) er en fritt tilgjengelig online kunnskapsbase som lar deg bruke lean-agile praksiser på bedriftsnivå. Det gir en enkel og lett opplevelse for programvareutvikling. Det er et sett med organisasjoner og arbeidsflytmønstre beregnet på å veilede bedrifter for å skalere lean og smidig praksis. Det er delt inn i tre segmenter som er Team, Program og portfolio.

Sikker rammeverket tillater teamet,

• Implementering av Lean-Agile programvare og systemer på bedriftsnivå
• Den er basert på Lean og Agile-prinsipper.
• Den gir detaljert veiledning for arbeid i bedriftens portefølje, verdistrøm, program og team.
• Den er designet for å møte behovene til alle interessenter i en organisasjon.

SAFe ble først utviklet i feltet og ble utviklet i Dean Leffingwell's bøker og blogg. Versjon 1.0 er den første offisielle utgivelsen i 2011. Den nyeste versjonen er 4.6, ble utgitt i oktober 2018. Den gir veiledning for å jobbe på bedriftsportefølje-, verdistrøm-, program- og teamnivå.

Hvorfor bruke SAFe Agile Framework

Det er enkelt og lett rammeverk, men det er i stand til å håndtere behovene til store verdistrømmer og kompleks systemutvikling. Ved å implementere SAFe agile rammeverk vil du ha følgende fordeler:

• Produktiviteten økte by 20 - 50%
• Quality økt mer enn 50%
• Time to Market er raskere enn 30 -75%
• økt ansattes engasjement og arbeidsglede.

Det detaljerte rammeskjemaet er tilgjengelig på nettsted. Den viser alle nøkkelrollene, aktiviteter, leveranser og flyter. Den fungerer også som et navigasjonshjelpemiddel for resten av nettstedet.

Bildet nedenfor forklarer hvordan smidig prosess fungerer. Epos er en stor mengde verk, som er ytterligere brutt ned i en rekke mindre historier eller underepos. Disse undereposene er tildelt teamet som en historie. Hvert team jobber deretter med disse historiene eller programvarefunksjonene deretter.

Når skal du bruke Scaled Agile Framework

• Når et team er interessert i å implementere en smidig tilnærming konsekvent på tvers av større programmer og porteføljer med flere team.
• Når flere team kjører sin egen måte for smidig implementering, men regelmessig møter hindringer, forsinkelser og feil.
• Når team ønsker å jobbe selvstendig.
• Når du ønsker å skalere smidig på tvers av organisasjonen, men ikke sikker på hvilke nye roller som kan være nødvendig eller hvilke eksisterende roller (dvs. ledelse) må endres og hvordan.
• Når du har forsøkt å skalere Agile på tvers av organisasjonen din, men sliter med å oppnå enhetlig eller konsistent strategi på tvers av forretningsavdelinger fra portefølje- til program- og teamnivåer.
• Når en organisasjon trenger å forbedre sin produktutvikling ledetid og ønsker å vite hvordan andre selskaper har lykkes med å skalere Agile med SAFe.

Hvor annerledes enn andre smidige praksiser

Nå i denne Scaled Agile Framework-opplæringen, la oss se hvordan Scaled Agile-rammeverket er forskjellig fra andre smidige praksiser,

• Den er offentlig tilgjengelig og gratis å bruke.
• Tilgjengelig i en svært tilgjengelig og brukbar form.
• Den er lett, praktisk talt utprøvde resultater og nivåspesifikk.
• Den modifiserer/opprettholder stadig/regelmessig de mest brukte smidige praksisene.
• Tilbyr nyttige utvidelser til vanlige smidige praksiser.
• Begrunner smidig praksis til en bedriftskontekst.
• Gir et komplett bilde av programvareutvikling.
• Synlighet eller åpenhet er mer på alle nivåer.
• Fortsatt eller regelmessig tilbakemelding på kvalitet og forbedring.

Foundations av Scaled Agile Framework

Scaled Agile Framework(SAFe): Det står på grunnlaget for sitt

1. Lean-Agile-prinsipper
2. Kjerneverdier,
3. Lean-smidig ledelse
4. Lean-Agile tankesett,
5. Praksisfellesskap (en gruppe mennesker som kontinuerlig jobber med SAFe-praksiser)
6. Implementerer 1-2-3

SAFe Lean-Agile-prinsipper

Disse grunnleggende SAFe Agile prinsippene og verdiene for SAFe må forstås, utstilles og videreføres for å oppnå de ønskede resultatene.

• Ta et økonomisk syn
• Bruk systemtenkning
• Anta variasjon; bevare alternativer
• Bygg trinnvis med raske, integrerte læringssykluser
• Baser milepæler på en objektiv evaluering av arbeidssystemer
• Visualiser og begrens WIP, reduser batchstørrelser og administrer kølengder
• Bruk kadens, synkroniser med planlegging på tvers av domener
• Lås opp den iboende motivasjonen til kunnskapsarbeidere
• Desentraliser beslutningstaking

SAFe Agile kjerneverdier

SAFe Agile-metodikken er basert på disse fire verdiene.

Justering:

• SAFe støtter justering.
• Oppretting starter kl.
  • Strategiske temaer i Portfolio Backlog og
  • Flytter ned til Visjon og veikart over programetterslep og deretter
  • Flytter til Team Backlogs.

Innebygd kvalitet:

• Det sikrer at hver inkrementell levering reflekterer kvalitetsstandardene.
• Kvalitet er ikke "legges til senere" er innebygd.
• Innebygd kvalitet er en forutsetning for Lean og det er obligatorisk

Åpenhet:

• Åpenhet er grunnlaget for tillit.
• SAFe hjelper bedriften med å oppnå åpenhet på alle nivåer – ledere, porteføljeforvaltere og andre interessenter.
• Alle kan se inn i porteføljebacklog/Kanban, programbacklog/Kanban og Team Backlog/Kanban.
• Hvert nivå har en klar forståelse av PI-målene.
• Togprogrammer har innsyn i teamets etterslep, så vel som andre programetterslep
• Team og programmer har innsyn i forretnings- og arkitektureposer. De kan se hva som kan være på vei.

Programutførelse:

• SAFe legger stort fokus på fungerende systemer og resulterende forretningsresultater.
• SAFe er ikke nyttig hvis team ikke kan utføre og kontinuerlig levere verdi.

Lean smidige ledere

Lean-Agile-lederne er livslange elever og lærere. Det hjelper team til å bygge bedre systemer gjennom å forstå og vise Lean-Agile SAFe-prinsippene.

Som en muliggjører for teamene er det endelige ansvaret adopsjon, suksess og kontinuerlig forbedring av Lean-Agile-utviklingen. For endring og kontinuerlig forbedring må ledere utdannes.

Ledere må ta i bruk en ny lederstil. En som virkelig styrker og engasjerer enkeltpersoner og team for å nå sitt høyeste potensial.

Prinsipper for disse Lean-Agile lederne

• Led endringen
• Kjenn veien; Legg vekt på livslang læring
• Utvikle mennesker
• Inspirer og samkjør med misjon; Minimer begrensninger
• Desentraliser beslutningstaking
• Lås opp den indre motivasjonen til kunnskapsarbeidere

Lean Agile Mind-Set

Lean-Agile tankesett er representert i to ting:

1. The SAFe House of Lean
2. Agile manifest

SAFe Lean-huset:

SAFe er avledet fra Lean-produksjonsprinsipper og -praksis. Basert på disse faktorene presenterer SAFe "SAFe House of Lean". Den er inspirert av "huset" til mager Toyota.

Målet med lean er uslåelig: Å levere maksimal kundeverdi på kortest mulig ledetid med høyest mulig kvalitet til kunden

Figuren nedenfor forklarer målet, søylene og Foundation av «SAFe House of Lean».

Agile manifest

Vi avdekker bedre måter å utvikle oss påping programvare ved å gjøre det og hjelpping andre gjør det. Gjennom dette arbeidet har vi lært å verdsette:

Derfor, mens det er en verdi i elementene til høyre, verdsetter vi elementene til venstre mer.

Agile manifest

1. Høyeste prioritet er å tilfredsstille kunden gjennom kontinuerlig og tidlig levering av verdifull programvare.
2. Omfavn de skiftende kravene, selv sent i utviklingen. Agile SAFe-metodikkprosesser utnytter endring til kundens fordel.
3. Lever fungerende programvare ofte, fra et par uker til et par måneder, med en preferanse til kortere tidsskala.
4. Utviklere og forretningsfolk må jobbe sammen daglig gjennom hele prosjektet.
5. Bygg prosjekter rundt motiverte individer. Gi dem støtte og miljøet de trenger, og stol på at de får jobben gjort.
6. Den mest effektive metoden for kommunikasjon med et utviklingsteam er en samtale ansikt til ansikt.
7. Fungerende programvare er det primære målet på fremgang.
8. Agile prosesser fremmer bærekraftig utvikling. Sponsorene, utviklerne og brukerne skal kunne opprettholde et konstant tempo på ubestemt tid.
9. Kontinuerlig oppmerksomhet på teknisk fortreffelighet og god design øker smidigheten.
10. Enkelhet – kunsten å maksimere mengden arbeid som ikke er utført – er avgjørende.
11. De beste arkitekturene, kravene og designene kommer fra selvorganiserende team.
12. Med jevne mellomrom reflekterer teamet over hvordan de kan bli mer effektive, og justerer og justerer oppførselen deretter.

Ulike nivåer i SAFE

Det er to forskjellige typer SAFe-implementering:

1. SAFe 4.0 implementering
2. SAFe 3.0 implementering

• I SAFe 4.0-implementering har vi 4-nivåer: Portefølje, verdistrøm, program og team.
• I SAFe 3.0-implementering har vi 3-nivåer: Portefølje, program og team
• 3-Level SAFe er for mindre implementeringer med 100 eller færre personer. Programmer som ikke krever betydelig samarbeid.
• 4-Level SAFe er for løsninger som vanligvis krever mange hundre utøvere for å utvikle distribusjon og vedlikehold av programvare.

Lagnivå

Roller/lag	Aktiviteter	Artifacts
Agilt team	Sprint Planlegging	Teamets etterslep
Produkteier	Backlog Grooming	Ikke-funksjonelle krav
Scrum Master	Daglig stand-up	Mål for team-PI
	Gjennomføring	Iterasjoner
	Sprint demo	Historier (fungerende programvare)
	Sprint Retrospective	Sprint Mål
	IP Sprints	Innebygd kvalitet
		Spikes
		Team Kanban

• Alle SAFe-team er en del av ett eller annet Agile Release Train (ART).
• SAFe-team er bemyndigede, selvorganiserende, selvadministrerende, tverrfunksjonelle team
• Hvert team er like ansvarlig for å definere, bygge og teste historier fra Team Backlog i gjentakelser med fast lengde
• Lag planlegger og utfører to ukers tidsrammede iterasjoner i samsvar med avtalte iterasjonsmål.
• Teams vil bruke ScrumXP/Team Kanban-rutinen for å levere systemer av høy kvalitet for å produsere en systemdemo på annenhver uke.
• Alle forskjellige team i ART (Agile Release Trains) vil lage et integrert og testet system. Interessenter vil evaluere og svare med rask tilbakemelding
• De bruker praksis for innebygd kvalitet.
• Hvert ScrumXP-team vil ha 5-9 teammedlemmer, som inkluderer alle rollene som er nødvendige for å bygge en kvalitetsinkrementell verdi i hver iterasjon.
• ScrumXP-roller inkluderer:
  • Team (utvikling + kvalitetssikring)
  • Scrum Master
  • Produkteier. osv..
• SAFe deler utviklingstidslinjen inn i et sett med iterasjoner innenfor en PI (Program Increment).
• PI-varighet er mellom 8-12 uker.
• Teamet vil bruke historier for å levere verdien. Produkteieren vil ha innholdsautoritet over deres opprettelse og aksept av historiene.
• Historier inneholder kundens krav.
• Team Backlog inkluderer bruker- og aktiveringshistorier, som identifiseres under PI-planlegging. Når produktledelsen presenterer veikart, visjon og programetterslep.
• Å identifisere, utdype, prioritere, planlegge, implementere, teste og akseptere historiene er de primære kravene til ledelsesarbeid på teamnivå.
• Hver iterasjon gir:
  • En verdifull økning av ny funksjonalitet
  • Oppnå via stadig gjentakende mønster
  • Planlegg iterasjonen
  • Forplikte seg til noe funksjonalitet
  • Utfør iterasjonen ved å bygge og teste historier
  • Demo den nye funksjonaliteten
  • Retrospective
  • Gjenta for neste iterasjon
• Team støtter også systemdemoen på slutten av hver iterasjon. som er det kritiske integreringspunktet for ART.
• Større verdistrømmer vil ha flere ART-er.
• Iterasjonene for innovasjon og planlegging (IP) utnytter teamene med en mulighet for innovasjon og utforskning.

Programnivå

Roller/lag	Aktiviteter	Artifacts
DevOps	PI (Programøkning) Planlegging	en visjon
Systemteam	Systemdemoer	Roadmap
Utgivelsesstyring	Inspiser og adopter verksted	Metrics
Product Management	Architeknisk rullebane	milepæler
UEX Architect	Utgivelse når som helst	Utgivelser
Utgivelsestogingeniør (RTE)	Agile utgivelsestog	Program Epics
System Architect/ingeniør	Slipp	Program Kanban
bedrifts~~POS=TRUNC		Programetterslep
Lean-Agile-ledere		Ikke-funksjonelle krav
Praksisfellesskap		Vektet korteste jobb først (WSJF)
Delte tjenester		Program PI-mål
Kunde-		Trekk
		Aktiver
		Oppløsning
		Verdistrømkoordinering

• På programnivå leveres Value of SAFe av langlivede Agile Release Trains (ART). Iterasjon er for team og tog er for programmet.
• Agile Release Trains (ART) er det primære kjøretøyet for verdilevering på programnivå. Det leverer en verdistrøm til organisasjonen.
• Programtilvekstene (PI-er) varighet er på 8 til 12 uker.
• ART består av 5 – 12 smidige team (~50 – 125+ personer) som inkluderer alle rollene og infrastrukturen som trengs for å levere fullstendig testet, fungerende programvare på systemnivå.
• Hver PI er en tidsboks med flere iterasjoner. I løpet av dette utvikles og leveres en betydelig, verdifull økning av systemet.
• I hver PI vil det skje en "demo" og "Inspiser og tilpass" økter, og planleggingen begynner for neste PSI.
• På programnivå legger SAFe vekt på prinsippet om justering. Dette er fordi flere smidige teaminnsatser er integrert for å skape kundeverdi.
• SAFe artefakthierarki er Epos->funksjoner->brukerhistorier.
• På programnivå har produktsjef/programleder innholdsautoritet. Han definerer og prioriterer programetterslepet.
• Programetterslep er en prioritert liste over funksjoner.
• På programnivå kan funksjoner stamme, eller de kan stamme fra epos definert på porteføljenivå.
• Funksjoner brytes ned til brukerhistorier og flyter inn i etterslep på teamnivå.
• Produktsjef eller rollen Release Train Engineer kan håndteres av programleder/senior prosjektleder
• System Architect rolle på programnivå er å samarbeide i det daglige arbeidet med teamene. Det sikrer at ikke-funksjonelle krav oppfylles. De jobber også med bedriftsarkitekten på porteføljenivå for å sikre at det er tilstrekkelig arkitektonisk rullebane for å støtte kommende bruker- og forretningsbehov.
• Grensesnittdesign, retningslinjer for brukeropplevelse og designelementer for teamene er levert av UX Designers.
• Chief-Scrum Master-rollen spilles av 'Release Train Engineer'.
• Ulike team (fra markedsføring, utvikling, kvalitet, drift og distribusjon) danner 'Release Management Team'. De vil godkjenne rutinemessige utgivelser av kvalitetsløsninger til kunder.
• Utrulling av programvare i kundemiljøer og vellykket levering ivaretas av DevOps-teamet.

Porteføljenivå

Roller/lag	Aktiviteter	Artifacts
Enterprise Architect	Strategisk investeringsplanlegging	Strategiske temaer
Programporteføljestyring	Kanban-porteføljeplanlegging (episk)	Enterprise
Episke eiere		Porteføljeetterslep
		Portefølje Kanban
		Ikke-funksjonelle krav
		Episk og muliggjørende
		Verdistrøm
		Budsjetter (CapEx og OpEx)

• Høyeste nivå av interesse/ bekymring /engasjement/ i SAFe er SAFe-portefølje
• Porteføljen gir de grunnleggende blokkene for å organisere Lean-Agile Enterprise-verdiflyten via en eller flere verdistrømmer.
• Porteføljen bidrar til å utvikle systemer og løsninger som er beskrevet i strategiske temaer (knytter en SAFe-portefølje til en virksomhets endrede forretningsstrategi).
• For å oppfylle strategiske mål, innkapsler porteføljenivå disse elementene. Den gir grunnleggende budsjettering og andre styringsmekanismer. På denne måten sikrer den at investeringen i verdistrømmene gir den avkastningen som er nødvendig for bedriften.
• En portefølje er koblet til virksomheten toveis:
  • For å veilede porteføljen til de større skiftende forretningsmålene, gir den strategiske temaer.
  • En annen retning indikerer den konstante flyten av porteføljeverdier.
• Program Portfolio Management fungerer som interessenter, og de er ansvarlige for å levere forretningsresultatene.
• SAFe Portfolio Level inneholder mennesker, prosesser og nødvendige byggesystemer og løsninger som en bedrift trenger for å oppfylle sine strategiske mål.
• Verdistrømmer er de primære målene i Portfolio, med finansiering av menneskene og andre ressurser som kreves for å bygge løsningene.
• Viktige nøkkelbegreper som brukes her er:
  • Tilkobling til bedriften,
  • Programporteføljestyring,
  • Administrere flyten av porteføljeepos.

Verdistrømnivå

Roller/lag	Aktiviteter	Artifacts
DevOps	Planlegging før og etter PI (programøkning)	en visjon
Systemteam	Løsningsdemoer	Roadmap
Utgivelsesstyring	Inspiser og adopter verksted	Metrics
Løsningshåndtering	Agile utgivelsestog	milepæler
UEX Architect		Utgivelser
Verdistrømingeniør (RTE)		Verdistrøm-eposer
Oppløsning Architect/ingeniør		Verdistrøm Kanban
Delte tjenester		Verdistrøm-etterslep
Kunde-		Ikke-funksjonelle krav
Leverandør		Vektet korteste jobb først (WSJF)
		Mål for verdistrøm-PI
		Capability
		Aktiver
		Løsningskontekst
		Verdistrømkoordinering
		Økonomisk rammeverk
		Løsningsintensjon
		MBSE
		Settbasert
		Agile Architecture

• Verdistrømnivået er valgfritt i SAFe.
• Verdistrømsnivå er nytt i SAFe 4.0.
• Verdistrømnivået er beregnet/designet for bedrifter/byggere/organisasjoner som er:

1. Stor i størrelsen
2. Frittstående optiker
3. Har komplekse løsninger
4. Løsningene deres krever vanligvis flere ART-er
5. De har leverandørbidrag.
6. De står overfor de største systemutfordringene
7. For cyberfysiske systemer
8. For programvare, maskinvare, elektrisk og elektronikk, optikk, mekanikk, fluidikk og mer.

• Å bygge denne typen systemer krever ofte hundrevis, til og med tusenvis av utøvere, eksterne og interne leverandører.
• Hvis systemene er oppdraget avgjørende. Svikt i løsningen, eller til og med et delsystem, har uakseptable økonomiske og sosiale konsekvenser.
• Hvis Enterprises kan bygges med noen få hundre utøvere, trenger de kanskje ikke konstruksjonene på dette nivået. I så fall kan de bruke fra 'sammenslått visning' som er 3-nivå SAFe.
• Å bygge verdistrømløsninger i et Lean-Agile-mønster krever ytterligere artefakter, koordinering og konstruksjoner. Så dette nivået inneholder et økonomisk rammeverk for å gi økonomiske grenser for verdistrøm
• Den støtter tråkkfrekvens og synkronisering for flere ART-er og leverandører. Det inkluderer planleggingsmøter før og etter PI og løsningsdemo.
• Det gir tilleggsroller som er: Verdistrømsingeniør, løsning Architect/Engineering, og Solution Management.

Spørsmål og svar