Hva er et Scaled Agile Framework (SAFe)?
Scaled Agile Framework (SAFe) er en fritt tilgjengelig online kunnskapsbase som lar deg bruke lean-agile praksis på bedriftsnivå. Det gir en enkel og lett opplevelse for programvareutvikling. Det er et sett med organisasjoner og arbeidsflytmønstre ment for å veilede bedrifter for å skalere mager og smidig praksis. Den er delt inn i tre segmenter som er team, program og portefølje.
SAFe- rammeverket tillater team for,
- Implementering av Lean-Agile programvare og systemer på bedriftsnivå
- Det er basert på Lean og Agile prinsipper.
- Det 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 felt og ble utdypet i Dean Leffingwells bøker og blogg. Versjon 1.0 er den første offisielle utgivelsen i 2011. Den siste versjonen er 4.6, ble utgitt i oktober 2018. Den gir veiledning for å jobbe på enterprise Portfolio, Value Stream, Program og Team nivåer.
I denne SAFe Agile opplæringen vil du lære-
- Hva er Scaled Agile Framework (SAFe)
- Hvorfor bruke Agile Framework
- Når skal du bruke Scaled Agile Framework
- Hvor annerledes enn annen smidig praksis
- Fundament of Scaled Agile Framework
- Agile manifest
- Ulike nivåer i SAFE
- Lagnivå
- Programnivå
- Porteføljenivå
- Verdistrømnivå
Hvorfor bruke 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 med 20 - 50%
- Kvaliteten økte mer enn 50%
- Time to Market er raskere enn 30-75%
- Økt ansattes engasjement og trivsel.
Det detaljerte rammediagrammet er tilgjengelig på nettstedet. Den viser alle nøkkelrollene, aktiviteter, leveranser og strømmer. Det fungerer også som et navigasjonshjelpemiddel til resten av nettstedet.
Bildet nedenfor forklarer hvordan smidig prosess fungerer. Epics er en stor mengde arbeid, som videre brytes ned i en rekke mindre historier eller underepos. Disse undereposene tildeles teamet som en historie. Hvert team jobber deretter med disse historiene eller programvarefunksjonene tilsvarende.
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 flerlagsprogrammer og porteføljer.
- Når flere lag kjører sin egen måte å agile implementering på, men ofte møter hindringer, forsinkelser og feil.
- Når team ønsker å jobbe selvstendig.
- Når du vil skalere Agile på tvers av organisasjonen, men ikke er sikker på hvilke nye roller som kan være behov for eller hvilke eksisterende roller (dvs. ledelse) som trenger å endres og hvordan.
- Når du har forsøkt å skalere Agile på tvers av organisasjonen din, men sliter med å tilpasse deg for å oppnå enhetlig eller konsistent strategi på tvers av forretningsavdelinger fra portefølje til program- og teamnivå
- Når en organisasjon trenger å forbedre ledetiden for produktutvikling og vil vite hvordan andre selskaper har lykkes med å skalere Agile med SAFe.
Hvor annerledes enn annen smidig praksis
Nå i denne Scaled Agile Framework-opplæringen, la oss se hvordan Scaled Agile framework er forskjellig fra annen smidig praksis,
- Det er offentlig tilgjengelig og gratis å bruke.
- Tilgjengelig i en svært tilgjengelig og brukbar form.
- Det er lette, praktisk beviste resultater og spesifikke for nivå.
- Den endrer / vedlikeholder konstant / regelmessig de mest brukte smidige rutinene.
- Tilbyr nyttige utvidelser av vanlig smidig praksis.
- Begrunner smidig praksis i forhold til virksomheten.
- Tilbyr komplett bilde av programvareutvikling.
- Synlighet eller gjennomsiktighet er mer på alle nivåer.
- Fortsetter eller regelmessig tilbakemelding på kvalitet og forbedring.
Fundament of Scaled Agile Framework
Scaled Agile Framework (SAFe): Den står på grunnlaget for dens
- Lean-Agile prinsipper
- Kjerneverdier,
- Lean-Agile Leadership
- Lean-Agile Mind-set,
- Practices Communities (gruppe mennesker som kontinuerlig jobber med SAFe-praksis)
- Implementering 1-2-3
SAFe Lean-Agile-prinsipper
Disse grunnleggende SAFe Agile prinsippene og verdiene for SAFe må forstås, vises og fortsettes for å oppnå de ønskede resultatene.
- Ta et økonomisk syn
- Bruk systemtenking
- Anta variasjon; bevare alternativene
- 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 indre motivasjonen til kunnskapsarbeidere
- Desentraliser beslutningstaking
SAFe Agile Core Values
SAFe Agile-metoden er basert på disse fire verdiene.
Justering:
- SAFe støtter justering.
- Justering starter kl.
- Strategiske temaer i porteføljebackloggen og
- Flytter ned til Visjon og veikart over programbacklogs og deretter
- Flytter til Team Backlogs.
Innebygd kvalitet:
- Det sikrer at hver inkrementell levering gjenspeiler kvalitetsstandardene.
- Kvalitet er ikke "lagt til senere" er innebygd.
- Innebygd kvalitet er en forutsetning for Lean og dens obligatoriske
Åpenhet:
- Åpenhet er det som muliggjør tillit.
- SAFe hjelper bedriften med å oppnå gjennomsiktighet på alle nivåer - ledere, porteføljeledere og andre interessenter.
- Alle kan se inn i porteføljens etterslep / Kanban, programetterslep / Kanban og Team Backlog / Kanban.
- Hvert nivå har en klar forståelse av PI-målene.
- Togprogrammer har synlighet i lagets etterslep, så vel som andre programetterslep
- Lag og programmer har synlighet i forretnings- og arkitekturepics. De kan se hva som kan være på vei mot dem.
Programutførelse:
- SAFe legger stort fokus på arbeidssystemer og resulterende forretningsresultater.
- SAFe er ikke nyttig hvis lag ikke kan utføre og kontinuerlig levere verdi.
Lean Agile Leaders:
Lean-Agile Leaders er livslange lærere og lærere. Det hjelper team med å bygge bedre systemer gjennom forståelse og utstilling av Lean-Agile SAFe-prinsippene.
Som en muliggjør for lagene er det endelige ansvaret adopsjon, suksess og kontinuerlig forbedring av Lean-Agile-utviklingen. For endring og kontinuerlig forbedring, må ledere trenes.
Ledere må ta i bruk en ny ledelsesstil. En som virkelig styrker og engasjerer enkeltpersoner og team for å nå sitt høyeste potensial.
Prinsipper for disse Lean-Agile lederne
- Led forandringen
- Kjenn veien; Legg vekt på livslang læring
- Utvikle mennesker
- Inspirer og tilpass deg misjonen; Minimer begrensninger
- Desentraliser beslutningstaking
- Lås opp den indre motivasjonen til kunnskapsarbeidere
Lean Agile Mind-Set:
Lean-Agile tankesett er representert i to ting:
- SAFe House of Lean
- Agile manifest
SAFe House of Lean :
SAFe er avledet fra Lean produksjonsprinsipper og praksis. Basert på disse faktorene presenterer SAFe "SAFe House of Lean". Den er inspirert av "huset" til magert Toyota.
Målet med lean er uslåelig: Å levere maksimal kundeverdi på kortest mulig leveringstid med høyest mulig kvalitet til kunden
Figuren nedenfor forklarer målet, søylene og grunnlaget for "SAFe House of Lean."
Agile manifest
Vi avdekker bedre måter å utvikle programvare på ved å gjøre det og hjelpe andre med å gjøre det. Gjennom dette arbeidet har vi kommet til verdi:
Det er derfor, mens det er en verdi i elementene til høyre, verdsetter vi elementene til venstre mer.
Agile manifest
- Den høyeste prioriteten er å tilfredsstille kunden gjennom kontinuerlig og tidlig levering av verdifull programvare.
- Ta imot de skiftende kravene, selv sent i utviklingen. Agile SAFe-metodikk prosesser seleendring til kundens fordel.
- Lever arbeidsprogramvare ofte, fra et par uker til et par måneder, med en preferanse fremfor kortere tidsskala.
- Utviklere og forretningsfolk må jobbe sammen daglig gjennom hele prosjektet.
- Bygg prosjekter rundt motiverte individer. Gi dem støtte og miljøet de trenger, og stol på at de får jobben gjort.
- Den mest effektive metoden for kommunikasjon med et utviklingsteam er en ansikt til ansikt-samtale.
- Arbeidsprogramvare er det primære målet for fremgang.
- Agile prosesser fremmer bærekraftig utvikling. Sponsorene, utviklerne og brukerne skal kunne holde et konstant tempo på ubestemt tid.
- Kontinuerlig oppmerksomhet mot teknisk fortreffelighet og god design forbedrer smidighet.
- Enkelhet - kunsten å maksimere mengden arbeid som ikke er utført - er viktig.
- De beste arkitekturer, krav og design kommer fra selvorganiserende team.
- Med jevne mellomrom reflekterer teamet over hvordan man kan bli mer effektivt, og stiller deretter inn og justerer oppførselen deretter.
Ulike nivåer i SAFE
Det er to forskjellige typer SAFe-implementering:
- SAFe 4.0 implementering
- SAFe 3.0 implementering
- I implementeringen av SAFe 4.0 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-nivå SAFe er for mindre implementeringer med 100 eller færre personer. Programmer som ikke krever betydelig samarbeid.
- 4-nivå SAFe er for løsninger som vanligvis krever mange hundre utøvere å utvikle distribusjon og vedlikehold av programvare.
Lagnivå
| Roller / lag | arrangementer | Gjenstander | ||
|---|---|---|---|---|
| * Agilt team | Sprintplanlegging | * Lagetterslep | ||
| * Produkteier | * Forsinkelsespleie | * Ikke-funksjonelle krav | ||
| * Scrum Master | * Daglig stand-up | * Team PI-mål | ||
| * Henrettelse | * Iterasjoner | |||
| * Sprint Demo | * Historier (arbeidsprogramvare) | |||
| * Sprint Retrospective | * Sprintmål | |||
| * IP-sprints | * Innebygd kvalitet | |||
| * Pigger | ||||
| * Team Kanban |
- Alle SAFe-lagene er en del av ett eller annet Agile Release Train (ART).
- SAFe-team er bemyndiget, selvorganiserende, selvledende, tverrfunksjonelle team
- Hvert team er like ansvarlig for å definere, bygge og teste historier fra Team Backlog i gjengivelser med fast lengde
- Lag planlegger og utfører to-ukers tidsbokse-iterasjoner i samsvar med avtalt Iterasjonsmål.
- Teamene vil bruke ScrumXP / Team Kanban-rutinen til å levere høykvalitetssystemer for å produsere en System Demo 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 innebygd kvalitetspraksis.
- Hvert ScrumXP-team vil ha 5-9 teammedlemmer, som inkluderer alle rollene som er nødvendige for å bygge en økende kvalitetsverdi i hver Iterasjon.
- ScrumXP-roller inkluderer:
- Team (Dev + QA)
- Scrum Master
- Produkteier. Etc…
- SAFe deler utviklingstidslinjen 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 oppretting og aksept av historiene.
- Historier inneholder kundens krav.
- Team Backlog inkluderer bruker- og aktivatorhistorier, som blir identifisert under PI-planlegging. Når Product Management presenterer veikart, visjon og programetterslep.
- Å identifisere, utdype, prioritere, planlegge, implementere, teste og godta historiene er de viktigste kravene til ledelsesarbeidet på teamnivå.
- Hver iterasjon gir:
- En verdifull økning av ny funksjonalitet
- Oppnå via stadig gjentatt mønster
- Planlegg iterasjonen
- Forplikte seg til litt funksjonalitet
- Utfør iterasjonen ved å bygge og teste historier
- Demo den nye funksjonaliteten
- Retrospektiv
- Gjenta for neste iterasjon
- Lag støtter også System Demo på slutten av hver itterasjon. som er det kritiske integreringspunktet for ART.
- Større verdistrømmer vil ha flere ART-er.
- Innovasjon og planlegging (IP) Iterasjoner utnytter teamene med en mulighet for innovasjon og leting.
Programnivå
| Roller / lag | arrangementer | Gjenstander | ||
|---|---|---|---|---|
| * DevOps | * PI (Program Increment) Planlegging | * Visjon | ||
| * Systemteam | * Systemdemoer | * Veikart | ||
| * Slipp ledelse | * Inspiser og vedta verksted | * Beregninger | ||
| * Produktledelse | * Arkitektonisk rullebane | Milepæler | ||
| * UEX-arkitekt | * Slipp når som helst | * Utgivelser | ||
| * Slipp togingeniør (RTE) | * Agile Release Train | * Program Epics | ||
| * Systemarkitekt / ingeniør | * Utgivelse | * Program Kanban | ||
| * Forretnings eiere | * Programforsinkelse | |||
| * Lean-Agile Leaders | * Ikke-funksjonelle krav | |||
| * Community of Practice | Vektet korteste jobb først (WSJF) | |||
| * Delte tjenester | * Program PI-mål | |||
| * Kunde | * Trekk | |||
| * Enabler | ||||
| * Løsning | ||||
| * Koordinering av verdistrøm |
- På programnivå leveres verdien av SAFe av langlivede Agile Release Trains (ART). Iterasjon er for team og tog er for programmet.
- Agile Release Trains (ART) er det viktigste kjøretøyet for verdileving på programnivå. Det leverer en verdistrøm til organisasjonen.
- Programøkningstiden (PI-er) er fra 8 til 12 uker.
- ART består av 5 - 12 Agile Teams (~ 50 - 125+ personer) som inkluderer alle rollene og infrastrukturen som trengs for å levere fullstendig testet, fungerende programvare på systemnivå.
- Hver PI er en tidsbokse med flere ikoner. I løpet av hvilken en betydelig, verdifull økning av systemet utvikles og leveres.
- I hver PI vil en "demo" og "Inspisere og tilpasse" økter skje, og planlegging 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 Epics-> features-> brukerhistorier .
- På programnivå har produktleder / 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 dekomponerer til brukerhistorier og flyter inn i etterslep på teamnivå.
- Produktansvarlig eller rollen Release Train Engineer kan håndteres av programleder / senior prosjektleder
- Systemarkitektrolle på programnivå er å samarbeide det daglige arbeidet med teamene. Det sikrer at ikke-funksjonelle krav blir oppfylt. 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 kundene.
- Distribusjon av programvare i kundemiljøer og vellykket levering ivaretas av DevOps-teamet.
Porteføljenivå
| Roller / lag | arrangementer | Gjenstander | ||
|---|---|---|---|---|
| * Bedriftsarkitekt | * Strategisk investeringsplanlegging | * Strategiske temaer | ||
| * Programportefølje Mgmt | * Kanban Portfolio (Epic) Planlegging | * Bedriften | ||
| * Episke eiere | * Porteføljeetterslep | |||
| * Portefølje Kanban | ||||
| * Ikke-funksjonelle krav | ||||
| Epic og Enabler | ||||
| * Verdistrøm | ||||
| * Budsjetter (CapEx og OpEx) |
- SAFe Portfolio er det høyeste nivået av interesse / bekymring / involvering / i SAFe
- Porteføljen gir grunnleggende blokker for organisering av Lean-Agile Enterprise-strømmen av verdi via en eller flere verdistrømmer.
- Porteføljen hjelper til med å utvikle systemer og løsninger som er beskrevet i strategiske temaer (knytter en SAFe-portefølje til en virksomhets skiftende forretningsstrategi).
- For å oppnå strategiske mål innkapsler porteføljenivået disse elementene. Det 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 større endrede forretningsmål, gir den strategiske temaer.
- En annen retning indikerer den konstante strømmen av porteføljeverdier.
- Programporteføljestyring 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 porteføljen, som finansierer mennesker og andre ressurser som kreves for å bygge løsningene.
- Viktige nøkkelbegreper som brukes her er:
- Tilkobling til Enterprise,
- Programporteføljestyring,
- Administrere Flow of Portfolio Epics.
Verdistrømnivå
| Roller / lag | arrangementer | Gjenstander | ||
|---|---|---|---|---|
| * DevOps | * Pre-and Post PI (Program Increment) Planning | * Visjon | ||
| * Systemteam | * Løsningsdemoer | * Veikart | ||
| * Slipp ledelse | * Inspiser og vedta verksted | * Beregninger | ||
| * Løsningsadministrasjon | * Agile Release Train | Milepæler | ||
| * UEX-arkitekt | * Utgivelser | |||
| * Value Stream Engineer (RTE) | * Value Stream Epics | |||
| * Løsningsarkitekt / ingeniør | * Verdistrøm Kanban | |||
| * Delte tjenester | * Verdistrømforsinkelse | |||
| * Kunde | * Ikke-funksjonelle krav | |||
| * Leverandør | Vektet korteste jobb først (WSJF) | |||
| * Verdistrøm PI-mål | ||||
| * Evne | ||||
| * Enabler | ||||
| * Løsningskontekst | ||||
| * Koordinering av verdistrøm | ||||
| * Økonomisk ramme | ||||
| * Løsningens hensikt | ||||
| * MBSE | ||||
| * Settbasert | ||||
| * Agil arkitektur |
- Verdistrømnivået er valgfritt i SAFe.
- Value Stream Level er nytt i SAFe 4.0.
- Verdistrømnivået er beregnet / designet for bedrifter / byggherrer / organisasjoner som er:
- Stor i størrelse
- Uavhengig
- Har komplekse løsninger
- Deres løsninger krever vanligvis flere ARTer
- De har bidrag fra leverandører.
- De står overfor de største systemutfordringene
- For cyber-fysiske systemer
- For programvare, maskinvare, elektrisk og elektronikk, optikk, mekanikk, fluidikk og mer.
- Å bygge denne typen systemer tar ofte hundrevis, til og med tusenvis av utøvere, eksterne og interne leverandører.
- Hvis systemene er avgjørende. Svikt i løsningen, eller til og med et delsystem, har uakseptable økonomiske og sosiale konsekvenser.
- Hvis Enterprises kan bygges med noen hundre utøvere, trenger det kanskje ikke konstruksjonene på dette nivået. I så fall kan de bruke fra ' kollapset visning' som er 3-nivå SAFe.
- Å bygge verdistrømsløsninger i et Lean-Agile-mønster krever ekstra gjenstander, koordinering og konstruksjoner. Så dette nivået inneholder et økonomisk rammeverk for å gi økonomiske grenser for Value Stream
- Den støtter tråkkfrekvens og synkronisering for flere ARTer og leverandører. Det inkluderer planleggingsmøter før og etter PI og løsningsdemo.
- Det gir flere roller som er: Value Stream Engineer, Solution Architect / Engineering og Solution Management.
Sammendrag:
- SAFe er en bransjeprøvd, verdifokusert metode for å skalere Agile på bedriftsnivå.
- Den svarer på spørsmålene som "Hvordan planlegger vi?", "Hvordan budsjetterer vi?", Og "Hvordan blir vi kryssfunksjonelle i arkitektur og DevOps?"
- SAFe Agile framework hjelper store organisasjonsteam med å oppfylle organisasjonens strategiske mål, ikke bare individuelle prosjektmål.
- Rammeverket gir muligheten til å opprettholde og lage en sentralisert strategi for å levere verdi.
- SAFe-modellen har tre / fire nivåer som sentraliserer de strategiske temaene i en organisasjon.
- Sentralisert strategi, kombinert med de-sentralisert smidig utviklingsutførelse.
Referanser:
SAFe for Lean Enterprises 5.0:
http://www.scaledagileframework.com
Denne artikkelen er bidratt av Jyothi Rangaraj