Menu

SAFe Agile Tutorial: Hvad er Scaled Agile Framework

safe agile tutorial what is scaled agile framework

Prøv Vores Instrument Til At Fjerne Problemer

den bedste mobiltelefon spion software

Scaled Agile Framework SAFe Tutorial:

I den sidste vejledning introducerede vi dig til begrebet Tre Amigo-principper hvilket har vist sig at være meget gavnligt for at levere den rigtige løsning i hurtigere tempo med stærke feedback-sløjfer.

Hvis du ikke allerede har gennemgået det, tjek vejledningen da det er et must at læse for alle for at komme ind i det agile rum.

I nutidens verden af ​​førsteklasses teknologier og leveringsmekanismer er det meget vigtigt at være i stand til at tilpasse sig den skiftende verden. For at få succes skal organisationen være i stand til at klare de hurtige ændringer i den måde, hvorpå de udvikler og leverer værdien til deres kunder.

sikre_ skalerede smidige rammer

Da det meste af organisationen bevæger sig mod Agility, er det blevet meget vigtigt at skalere og opretholde en konkurrencemæssig fordel. Dette er når Scaled Agile Frameworks kommer ind i indtrykket.

I denne SAFe-vejledning skal vi diskutere Scaled Agile Framework i detaljer. Vi vil også lægge vægt på behovet for at bringe SAFe ind som for at forstå den overordnede problemangivelse, og til sidst vil vi se, hvordan vi kan bringe SAFe i bevægelse.

Lad os starte med bolden rullende ...

SAFe står for Scaled Agile Frameworks. SAFe leveres af virksomheden Scaled Agile. Det blev oprettet i 2011 med Dean Leffingwell som skaberen og medstifteren.

Det er lavet til at hjælpe virksomheder med at skalere magre og smidige softwareudviklingsprocesser. Ligesom LeSS, DAD og Nexus er SAFe også en af ​​dem, der prøver at finde en løsning på de problemer, der opstår under opskalering af holdet.

Hvad du lærer:

Før SAFe

Tidligere da vi brugte til at bygge store og komplekse systemer, blev resultatet af resultatet, at vi ikke var i stand til at levere til tiden, og kvaliteten var ikke så god, og som et resultat var kundeoplevelsen heller ikke god, hvilket er virkelig dårligt!

SAFe forsøger at løse disse problemer, og virksomheder, der har vedtaget disse rammer, har vist fantastiske resultater.

Hvad er SAFe?

Scaled Agile Framework er en ramme, der giver fire forskellige lag af adræt-lean-adoptioner.

Det laveste niveau kaldes TEAM-niveau, hvor flere hold laver på scrum, Kanban eller andre agile metoder ved hjælp af fundamentet i XP-programmering, hvilket giver værdi på holdniveau.

Niveau to, der går fra top til bund, er PROGRAM, det henviser til holdene, der arbejder sammen under ledelse af programledelsesteamet og leverer værdi i begrebet Agile release train.

Det nye lag, der er tilføjet i SAFe 4.0, er VALUE STREAM, det er intet andet end en kombination af programteam og agile release-tog, der er ansvarlige for at levere en betydelig mængde værdi leveret til kunderne.

Og lige øverst på det har vi vores næste niveau kaldet Porteføljeniveau, som er ansvarlig for at tilpasse og se, hvordan værdi vil blive leveret af de tre niveauer under porteføljen.

Safe understøtter mindre løsninger med 50 - 125 praktikere samt komplekse systemer, der kræver tusindvis af mennesker.

Det afsløres frit og er en online videnbase med dokumenterede succesrekorder. Det bruges af mange organisationer, der er involveret i kompleks softwareudvikling. SAFe taler også om udfordringer i kompleks softwareudvikling, det taler også om forskellige roller, ansvarsområder, artefakter og forskellige aktiviteter involveret i hvert lag.

Sikker

Hvorfor skaleret agil ramme?

I dag holder ny software og systemer den maksimale opmærksomhed på markedet overalt. At bringe de innovative ideer og nye måder at arbejde meget ofte på, er dermed at udgive de traditionelle og ældre systemer.

Når det er sagt, vil de organisationer, der er klar over og forstå, at det er nødvendigt at gå videre og tilpasse forandringen hurtigere.

For at udvikle softwaresystemerne er vi nødt til at holde trit med de kompleksiteter og afhængigheder, der opstår i et sammenkoblet miljø. Og tingene bliver endnu mere komplekse, når teknologier som Bigdata, sociale medier, mobil osv. Kommer ind i billedet.

Organisationerne forventes at holde trit med at nye teknologier og systemer kommer ind og også opretholde de ældre systemer, der har været der i årevis.

I en traditionel verden brugte organisationer vandfaldsudviklingsmodellen til at udvikle softwaren.

Denne software blev udviklet i en sekventiel tilstand, dvs. den næste fase kunne kun starte, når den forrige fase er afsluttet. Denne arbejdsmåde fungerede glimrende i de gamle tider, men den giver ikke længere de ønskede resultater for miljøet, hvor innovation og udvikling er på niveau.

Således vil de organisationer, der arbejder i sekventiel tilstand, kæmpe for at skalere og vokse.

Nogle af de almindelige udfordringer, vi står over for, når vi udvikler en software i en vandfaldsmodel, er illustreret i billedet nedenfor:

udfordringer i en vandfaldsmodel

Vær opmærksom på, at disse problemer opstår ved brug af det dårlige system, som medarbejderen arbejder i, og på grund af medarbejderens præstationer.

Derfor skal vi bringe teknikkerne til at blive slankere og mere lydhøre over for ændringer for at overvinde og slå disse vejspærringer og nå større mål. Således anbefales det stærkt at vedtage SAFe på grund af dets værdier, principper og praksis.

SAFe-dannelse

Lad os starte vores diskussion om Scaled Agile Framework og dens dannelse. På nuværende tidspunkt har vi klart formuleret og forstået behovet for at have en skaleret agil ramme i en organisation.

Konceptualiser nu et miljø, hvor vi har flere teams, der arbejder under lignende forhold for at nå det samme mål. Det er tid for os at komme videre og se, hvordan Agile Scaled Framework som Scaled Scrum fungerer i dette rum.

  • Alle interessenter (intern eller ekstern) og ledelse mødes sammen for at skabe et meget højt niveau Portfolio Vision Document, der også kaldes Portfolio Backlog. Portfolio Backlog består i det væsentlige af flere forretnings- og arkitektoniske krav, som også kaldes Epics. Disse forretnings- og arkitektoniske epos er tilpasset prioriteterne.

Episk

  • Baseret på prioriteterne bliver disse epos afhentet af Product Managers / Delivery Managers. De opretter en veldefineret køreplan og et visiondokument. De udfører denne aktivitet ved at diskutere frigivelsesplanen med Release Management Team for at tilpasse køreplanen til produktionsudgivelserne.
  • Når køreplanen og visionsdokumentet er oprettet, er Product Manager's næste trin at oprette et efterslæb af Program Backlog. En programbacklog består af frigivelseselementer, funktionelle bits og en pulje af ikke-funktionelle krav (NFR'er).
  • Release Management Team udarbejder en frigivelsesplan, der passer til funktionerne i frigivelsescyklusser.
  • Release Management Team arbejder nu på funktionsbitene for at opfylde frigørelsesplanen og målene. De arbejder også med at forberede arkitekturen og infrastrukturen for at muliggøre glatte udgivelser.
  • Fra Program Backlog bevæger vi os mod et individuelt Product Backlog, der også er kendt som Team Backlog. Release / System Team har deres egen Product Backlog, ligesom alle Scrum Team, der arbejder på projektet, vil have deres individuelle Product Backlog.
  • Product Backlog består af både funktionelle og ikke-funktionelle historier. Disse historier prioriteres af produktejeren, der arbejder på det Scrum-team.
  • Typisk er der 5-10 Scrum Teams, der arbejder i et skaleret agilt miljø. Hvert af Scrum-teamet har en Product Owner, Scrum Master og et Development Team. Rollerne og ansvaret for hvert af Scrum-teammedlemmerne i Scaled Scrum er de samme som i det normale Scrum-miljø.
  • Scrum Teamet udfører alle Scrum-ceremonierne og arbejder på at udvikle Increment, der skal leveres i slutningen af ​​hver sprint.

Tips og tricks

  • For alle Scrum Teams holdes Sprint start- og slutdatoer de samme som den samme varighed. Derfor er Sprint for alle Scrum Teams synkroniseret.
  • Da alle Scrum Teams arbejder på en enkelt mission, bør afhængighederne blandt dem være klart defineret, planlagt og tildelt for at minimere afbrydelsen af ​​produktleverancer. Afhængigheder mellem Scrum-holdene er et af de mest rutinemæssige problemer i Scaled Scrum Environment.
  • Hvert af Scrum Team forventes at levere en forøgelse i slutningen af ​​hver Sprint. Alle disse inkrementer, når de kombineres, udgør en potentielt frigørelig softwaretrin.
  • Mens du arbejder i Scaled Scrum, skal skift af teammedlemmer fra et hold til et andet gøres omhyggeligt. Teammedlemskift er ikke tilladt under Sprint, og der er ingen undtagelse fra denne regel.
  • Programmets samlede fremskridt måles ved at integrere Increments udviklet af alle Scrum Teams.
  • Når du arbejder i Scaled Scrum, gennemføres en ceremoni kaldet 'Scrum of Scrum' dagligt eller ugentligt, hvor en repræsentant (normalt Scrum Master) fra hvert af Scrum-teamet kaldes til at deltage. Dette møde er det samme som i Daily Standup, og målet forbliver også det samme: 'For at opretholde tilpasningen og synkroniseringen mellem flere hold'.
  • Hold altid kerneværdierne i Scaled Agile Framework (SAFe) intakte på alle niveauer.

Kerneværdier: Justering, indbygget kvalitet, justering og gennemsigtighed

Kerneværdi

  • Kommunikation og samarbejde mellem Scrum Teams er nøglen til en vellykket Scaled Scrum med hensyn til produktivitet, kvalitet og tid til markedet.

Et par tweaks her og der i en Scrum Framework kan føre til utrolige resultater i form af Scaled Scrum.

Hvorfor skal vi bruge denne ramme?

SAFe 4.0 har nu bevist track record for succes fra mange gigantiske organisationer, der implementerede denne ramme og forbedrede kundeoplevelsen ved at levere softwareprodukter på den korteste bæredygtige leveringstid ved at følge Lean-Agile måde.

Dybest set fungerer det baseret på den agile udvikling, systemtænkning og lean udvikling.

Det hjælper med:

  • Tilpasning af forretningsmæssige og tekniske mål for virksomheden.
  • At træffe beslutninger for at forbedre resultaterne.
  • Planlægning for levering til tiden.
  • Forbedring af kvaliteten af ​​løsninger.
  • Skalering af de smidige processer op til virksomhedsniveau.
  • Udnyttelse af medarbejdernes færdigheder effektivt.
  • Definition af effektive organisationsstrukturer
  • Måling af smidig holdpræstation
  • Og foreslå måder at motivere folk til godt arbejde og til at lære nye ting og tage risici.

Her er data fra virksomheder, der har implementeret dem med succes

data fra virksomheder, der har implementeret SAFe med succes

SAFe-konfigurationer

SAFe understøtter hele spektret af udviklingsmiljøer med fire konfigurationer,

SAFe-konfiguration

1. Væsentlig SAFe

  • Essential SAFe-konfigurationen er hjertet i Framework og er det enkleste udgangspunkt for implementering.
  • Det er den grundlæggende byggesten til alle andre SAFe-konfigurationer og beskriver de mest kritiske elementer, der kræves for at realisere størstedelen af ​​Framework's fordele.
  • Team- og programniveauerne danner en organisationsstruktur kaldet Agile Release Train (ART), hvor agile teams, nøgleinteressenter og andre ressourcer er dedikeret til en vigtig, løbende løsningsmission.

2. Portefølje SAFe

  • Portfolio SAFe-konfigurationen hjælper med at tilpasse porteføljekørsel til virksomhedsstrategien.
  • Organiseret omkring strømmen af ​​værdi.
  • Lean-Agile budgettering bemyndiger beslutningstagere.
  • Kanban-systemet giver porteføljesynlighed og WIP-grænser.
  • Virksomhedsarkitektur styrer større teknologibeslutninger.
  • Objektive målinger understøtter styring og forbedring.
  • Værdi levering via Epics.

3. Stor løsning SAFe

  • Stor løsning SAFe-konfiguration er til udvikling af de største og mest komplekse løsninger, der typisk kræver flere Agile release-tog og leverandører, men ikke kræver porteføljeniveauovervejelser.
  • Dette er almindeligt for industrier som luftfart, forsvar, bilindustri osv.
  • Solution Train-organisationskonstruktionen af ​​Large Solution Level hjælper virksomheder, der står over for de største udfordringer - at opbygge storskala, tværfaglig software, hardware og komplekse IT-systemer.
  • Opbygning af disse løsninger kræver yderligere roller, artefakter, begivenheder og koordinering.

4. Fuld SAFe

  • Fuld SAFe-konfigurationen er den mest omfattende version af Framework.
  • Det understøtter virksomheder, der bygger og vedligeholder store integrerede løsninger, der kræver hundreder af mennesker eller mere, og inkluderer alle niveauer af SAFe: team, program, stor løsning og portefølje.
  • I de største virksomheder kan det være nødvendigt med flere forekomster af forskellige SAFe-konfigurationer.

Fonden

Fonden indeholder de understøttende principper, værdier, tankegang, implementeringsvejledning og lederroller, der kræves for at levere værdien med succes i skala.

1. Lean-Agile ledere

Ledelse har det endelige ansvar for forretningsresultater. Ledere skal trænes og derefter blive undervisere af disse slankere måder at tænke og arbejde på. Til dette formål beskriver SAFe en ny ledelsesstil, der udstilles af virksomhedens ledere.

Lean-Agile ledere leder sin organisation i at opbygge bedre systemer gennem iterative og inkrementelle måder at lære, coache, udvikle mennesker og processer på.

SAFe Lean-Agile ledere

SAFe Lean-Agile Leaders er livslange lærere og lærere, der hjælper holdene med at opbygge bedre systemer gennem forståelse og udstilling af Lean-Agile Mindset og SAFe-principperne.

2. Kerneværdier

Fire kerneværdier definerer trossystemet for SAFe:

Programudførelse

  • Programudførelse er de vigtigste kerneværdier, da det sammenlignes med andre værdier, uden hvilke eksekveringsteamet ikke kan levere nogen værdi til kunden.
  • Primært fokuserer det på arbejdssoftware og god kundeoplevelse.
  • Kompleks softwareudvikling opnås ved hjælp af inspektion og dygtighed i slutningen og klarer sig bedre i hver PI.
  • Ikke kun holdene, men med hjælp fra Agile ledere kan lederteamet også udføre kundetilfredshed

Gennemsigtighed

  • På hvert niveau, dvs. team-, program-, værdistrøm- og porteføljeniveau, har vi en tavle, der viser information om projektforløb til enhver tid.
  • Holdet følger agil scrum, derfor stoler alle holdmedlemmer på hinanden og er frie til at træffe beslutninger, der fremmer innovationer.
  • Tilskynder til åben og ærlig kommunikation med alle interessenter.
  • Værdsætter produktivitet, kvalitet, gennemsigtighed og åbenhed over for intern politik.

Indbygget kvalitet

  • Indfør trinvist den indbyggede kvalitetspraksis for software, hardware og firmware. Forstå, undervise eller sponsorere udvikling af tekniske færdigheder til støtte for høj kvalitetskode, komponenter, systemer og løsninger.
  • Fremme praksisfællesskaber.
  • Forstå, support og anvend Agile Architecture and Lean User Experience (UX).

3. Lean-Agile tankegang

Lean-Agile Leaders er livslange lærere og lærere. De forstår og omfavner magre og smidige principper og praksis.

Lean-Agile tankegang

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

(i) Lean House:

House of Lean er det, du ser her.

Det har en række elementer:

Værdi, da målet med Lean er meget simpelt, har det den korteste bæredygtige leveringstid. Det opnås med søjlerne i respekt for mennesker og kultur , produktudviklingsflow, innovation - kritisk for langsigtet bæredygtighed - og ubarmhjertig forbedring. Og det understøttes af ledelse .

Det er den struktur, hvor vi har tendens til at tænke over det magre paradigme.

(ii) Agil manifest:

For det andet er det Adræt manifest , som har været hos os siden 2001. Det er et meget velskrevet dokument, og hvad det siger, er stadig sandt indtil i dag. Vi har brug for Agile Manifest, fordi det er nøglen til at låse op for motiverne og talentene hos de vidensarbejdere, der udvikler vores løsninger og software.

Adræt manifest

  1. Den højeste prioritet er at tilfredsstille kunden gennem kontinuerlig og tidlig levering af værdifuld software.
  2. Overtag de skiftende krav, selvom det er sent i udviklingen. Agile processer udnytter ændringer til kundens fordel.
  3. Lever arbejdssoftware ofte fra et par uger til et par måneder med en præference frem for den kortere tidsplan.
  4. Udviklere og forretningsfolk skal arbejde sammen dagligt gennem hele projektet.
  5. Byg projekter omkring motiverede individer. Giv dem støtte og det miljø, de har brug for, og stol på dem til at få arbejdet gjort.
  6. Den mest effektive metode til kommunikation med udviklingsteamet 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 skal være i stand til at opretholde et konstant tempo på ubestemt tid.
  9. Løbende opmærksomhed på teknisk ekspertise og godt design forbedrer smidighed.
  10. Enkelhed - kunsten at maksimere den mængde arbejde, der ikke er udført, og er meget vigtig.
  11. De bedste arkitekturer, krav og design fremgår af selvorganiserende teams.
  12. Med jævne mellemrum reflekterer holdet over, hvordan man bliver mere effektivt, og indstiller derefter og justerer dets adfærd i overensstemmelse hermed.

4. SAFe-principper

SAFe-praksis er baseret på ni principper, der syntetiserer Agile metoder, Lean-produktudvikling, systemtænkning og årtier med felterfaring.

  1. Tag et økonomisk syn
  2. Anvend systemtænkning
  3. Antag variabilitet, bevar valgmuligheder
  4. Byg trinvist med hurtige, integrerede læringscyklusser.
  5. Baser milepæle på en objektiv evaluering af arbejdssystemer
  6. Visualiser og begræns WIP, reducer batchstørrelser og administrer kølængder
  7. Anvend kadence, synkroniser med planlægning på tværs af domæner
  8. Lås op for den videnskabelige arbejdstagers iboende motivation
  9. Decentraliser beslutningstagning

5. Køreplan for implementering

Implementering af de ændringer, der er nødvendige for at blive en Lean-Agile teknologivirksomhed, er en væsentlig ændring for de fleste virksomheder. SAFe leverer en køreplan for implementering for at hjælpe eller vejlede organisationer på denne rejse.

Lad os endelig diskutere implementering. Vi beskriver det ved hjælp af vores Implementing SAFe 1-2-3 model.

Nummer 1 er at træne Lean-Agile forandringsagenter. Vi kalder disse SAFe-programkonsulenter. Med et tilstrækkeligt personale af Lean-Agile forandringsagenter på stedet og arbejder med dine partnere har du evnen til at træne ledere og ledere og ledere, der er de personer, der er ansvarlige for at styre de mennesker, der leverer værdi.

De vil så være i stand til at støtte lanceringen af ​​Agile Release Trains. Og med et tog ad gangen bygger du den Agile-portefølje.

6. SAFe-programkonsulenter (SPC'er)

SPC'er er forandringsagenter, der kombinerer deres tekniske viden om SAFe med en iboende motivation til at forbedre deres virksomheds software- og systemudviklingsprocesser.

Konklusion

Sikker er en ramme, der giver os tilpasning ikke kun med teamet (lavere niveau) og programniveau, men hjælper os også med at tilpasse os til organisationsstrategi (øverste niveau), og hvordan et teams arbejde med at tilføre værdi til kunder lige fra det øverste niveau.

Den fås i forskellige konfigurationer, og virksomheder kan drage fordel af det

Den kan bruges af en stor organisation, og den har fået en god feedback fra virksomheder, der er implementeret i den, den har fået den af ​​regler, værdier og principper, hvis den bruges korrekt, kan organisationen glæde kunden og producere software i den korteste bæredygtige ledelse tid, der tilføjer værdi.

Med denne vejledning er vi kommet til slutningen af ​​vores Agile Scrum-serien . Vi håber, at du havde det godt og nød at læse vores artikler om Agile.

Fortæl os også, hvis du tror, ​​vi måske har glemt noget emne i Agile Series. Vi går gerne en ekstra mil og dækker emnet for dig. Dernæst er en interessant Agile quiz for dig med svarene. Glem ikke at prøve det !!

Spørgsmål og svar til test af mobilapplikationer

PREV-vejledning | NÆSTE vejledning

Anbefalet læsning

^