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:

Fordele ved at bruge Agile Framework
Fordele ved at bruge Agile Framework
  • 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.

Skaleret agilt ramme Architecture
Skaleret agilt ramme Architecture

Hvornår skal man bruge Scaled Agile Framework

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

Foundations af Scaled Agile Framework
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 (gruppe af mennesker, der konstant arbejder på SAFe-praksis)
  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

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."

Mål og Foundations af Scaled Agile Framework
Mål og Foundations af Scaled Agile Framework

Agilt manifest

Vi afslører bedre måder at udvikle software på ved at gøre det og hjælpe andre med at gøre det. Gennem dette arbejde er vi kommet til at værdsætte:

Agilt manifest
Agilt manifest

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
Forskellige niveauer i SAFE
Niveauer af SAFe
  • 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:
  • 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:
  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.

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:

http://www.scaledagileframework.com