Meny

SAFe Agile Tutorial: What is Scaled Agile Framework

  • Hoved
  • Annen
  • SAFe Agile Tutorial: What is Scaled Agile Framework

safe agile tutorial what is scaled agile framework

Prøv Instrumentet Vårt For Å Eliminere Problemer

programvare for å laste ned videoer fra nettsteder

Scaled Agile Framework SAFe Tutorial:

I den siste opplæringen introduserte vi deg for begrepet Tre Amigo-prinsipp som har vist seg å være veldig gunstig for å levere riktig løsning i raskere tempo med sterke tilbakemeldingsløkker.

Hvis du ikke allerede har gått gjennom det, sjekk ut veiledningen da det er et must for alle for å komme inn i det smidige rommet.

I dagens verden av førsteklasses teknologier og leveringsmekanismer er det veldig viktig å kunne tilpasse seg den skiftende verden. For å lykkes, må organisasjonen være i stand til å takle de raske endringene i måten de utvikler og leverer verdien til kundene sine.

safe_ skalerte smidige rammer

Med det meste av organisasjonen som går mot Agility, har det blitt veldig viktig å skalere og opprettholde et konkurransefortrinn. Dette er når Scaled Agile Frameworks kommer inn i inntrykket.

I denne SAFe-opplæringen skal vi diskutere Scaled Agile Framework i detalj. Vi skal også legge vekt på behovet for å få inn SAFe som for å forstå den overordnede problemstillingen, og til slutt vil vi se hvordan vi kan bringe SAFe i bevegelse.

La oss starte med ballen som ruller ...

SAFe står for Scaled Agile Frameworks. SAFe er levert av selskapet Scaled Agile. Den ble opprettet i 2011, med Dean Leffingwell som skaper og medstifter.

Det er laget for å hjelpe bedrifter med å skalere magre og smidige programvareutviklingsprosesser. I likhet med LeSS, DAD og Nexus, er SAFe også en av dem som prøver å finne en løsning på problemene som oppstod under oppskalering av teamet.

Hva du vil lære:

Før SAFe

Tidligere da vi brukte å bygge store og komplekse systemer, ble resultatet av resultatet at vi ikke klarte å levere i tide, og kvaliteten var ikke så god, og som et resultat var heller ikke kundeopplevelsen bra, noe som er veldig dårlig!

SAFe prøver å løse disse problemene, og selskaper som har vedtatt disse rammene har vist fantastiske resultater.

Hva er SAFe?

The Scaled Agile Framework er et rammeverk som gir fire forskjellige lag med smidig og magert adopsjon.

Det laveste nivået kalles TEAM-nivå der flere lag gjør på scrum, Kanban eller andre smidige metoder ved hjelp av grunnleggende XP-programmering, og gir verdi på teamnivå.

Nivå to som går fra topp til bunn er PROGRAM, det refererer til teamene som jobber sammen under ledelse av programledelsesteamet, og gir verdi i konseptet Agile release train.

Det nye laget som er lagt til i SAFe 4.0 er VALUE STREAM, det er ingenting annet enn en kombinasjon av programteam og smidige frigjøringstog som er ansvarlige for å gi en betydelig mengde verdi levert til kundene.

Og helt på toppen av det har vi vårt neste nivå kalt Porteføljenivå som er ansvarlig for å tilpasse og se hvordan verdien vil bli levert av de tre nivåene under porteføljen.

Safe støtter løsninger i mindre skala med 50 - 125 utøvere, samt komplekse systemer som krever tusenvis av mennesker.

Det avsløres fritt og er en online kunnskapsbase med dokumenterte suksessrekorder. Den brukes av mange organisasjoner som er involvert i kompleks programvareutvikling. SAFe snakker også om utfordringer i kompleks programvareutvikling, det snakker også om forskjellige roller, ansvar, gjenstander og ulike aktiviteter som er involvert i hvert lag.

Sikker

Hvorfor skalert smidig ramme?

I dag holder ny programvare og systemer maksimal oppmerksomhet på markedet overalt. Å få inn de innovative ideene og nye måter å jobbe veldig ofte på, er å støpe de tradisjonelle og eldre systemene.

Når det er sagt, vil organisasjonene som innser og forstår behovet for å gå videre og tilpasse endringen raskere, lykkes.

For å utvikle programvaresystemene må vi holde tritt med kompleksiteten og avhengigheten som oppstår i et sammenkoblet miljø. Og tingene blir enda mer komplekse når teknologier som Bigdata, sosiale medier, mobil osv. Kommer inn i bildet.

Organisasjonene forventes å holde tritt med at nye teknologier og systemer kommer inn, og også opprettholde de eldre systemene som har vært der i årevis.

I en tradisjonell verden brukte organisasjoner fossefallutviklingsmodellen for å utvikle programvaren.

Denne programvaren ble utviklet i en sekvensiell modus, dvs. neste fase kunne bare starte når den forrige fasen er fullført. Denne arbeidsmåten fungerte fantastisk i gamle tider, men den gir ikke lenger de ønskede resultatene for miljøet der innovasjon og utvikling er på nivå.

Dermed vil organisasjonene som jobber i sekvensiell modus kjempe for å skalere og vokse.

Noen av de vanlige utfordringene vi møter når vi utvikler en programvare i en fossmodell, er illustrert i bildet nedenfor:

utfordringer i en fossemodell

Legg merke til at disse problemene oppstår ved bruk av det dårlige systemet som den ansatte arbeider i, og på grunn av den ansattes ytelse.

Derfor, for å overvinne og slå disse veisperringene og for å oppnå større mål, bør vi ta med teknikkene for å bli slankere og mer lydhøre overfor endringer. Dermed anbefales det å adoptere SAFe på grunn av dets verdier, prinsipper og praksis.

SAFe-dannelse

La oss starte diskusjonen vår om Scaled Agile Framework og dens dannelse. Nå har vi tydelig formulert og forstått behovet for å ha en skalert smidig ramme i en organisasjon.

Konseptualiser nå et miljø der vi har flere team som jobber under lignende forhold for å oppnå samme mål. Det er på tide for oss å gå videre og se hvordan Agile Scaled Framework som Scaled Scrum fungerer i dette rommet.

  • Alle interessenter (internt eller eksternt) og ledelse kommer sammen for å lage et meget høyt nivå Portfolio Vision Document, som også kalles Portfolio Backlog. Portfolio Backlog består i hovedsak av flere forretnings- og arkitektoniske krav, også kjent som Epics. Disse forretnings- og arkitektoniske epikkene er tilpasset prioriteringene.

Episk

  • Basert på prioriteringene blir disse epikkene plukket opp av produktledere / leveringsledere. De lager et veldefinert veikart og et visjonsdokument. De gjør denne aktiviteten ved å diskutere utgivelsesplanen med Release Management Team for å justere veikartet med produksjonsutgivelsene.
  • Når veikart og visjonsdokument er opprettet, er produktsjefens neste trinn å opprette et etterslep av programetterslep. En programetterslep består av utgivelseselementer, funksjonelle biter og en pool av ikke-funksjonelle krav (NFR).
  • Release Management Team utarbeider en utgivelsesplan for å passe inn i funksjonene i utgivelsessyklusene.
  • Release Management Team jobber nå med funksjonsbitene for å oppfylle utgivelsesplanen og målene. De jobber også med å forberede arkitekturen og infrastrukturen for å muliggjøre jevne utgivelser.
  • Fra Programbackloggen beveger vi oss mot et individuelt Product Backlog som også er kjent som Team Backlog. Utgivelses- / systemteam har sitt eget produktetterslep, på samme måte vil alt Scrum-teamet som jobber med prosjektet ha sitt individuelle produktetterslep.
  • Product Backlog består av både funksjonelle og ikke-funksjonelle historier. Disse historiene er prioritert av produkteieren som jobber med det Scrum-teamet.
  • Vanligvis er det 5-10 Scrum Team som jobber i et skalert, smidig miljø. Hvert av Scrum-teamet har en produkteier, Scrum Master og et utviklingsteam. Rollene og ansvaret til hvert av Scrum-teammedlemmene i Scaled Scrum er de samme som i det normale Scrum-miljøet.
  • Scrum Teamet utfører alle Scrum-seremoniene og jobber med å utvikle Increment som skal leveres på slutten av hver sprint.

Tips og triks

  • For alle Scrum-lagene holdes start- og sluttdatoene for Sprint på samme tid. Derfor er Sprint for alle Scrum Teamene synkronisert.
  • Siden alle Scrum-teamene jobber med ett enkelt oppdrag, bør avhengighetene blant dem være klart definert, planlagt og tilordnet for å minimere forstyrrelser i produktleveranser. Avhengighet mellom Scrum-teamene er et av de mest rutinemessige problemene i Scaled Scrum Environment.
  • Hvert av Scrum-teamet forventes å levere en økning på slutten av hver sprint. Alle disse trinnene når de kombineres, danner en potensielt frigjørbar programvaretrinn.
  • Mens du arbeider i Scaled Scrum, bør du skifte teammedlemmene fra ett lag til et annet nøye. Teammedlemskift er ikke tillatt under Sprint, og det er ikke noe unntak fra denne regelen.
  • Programmets samlede fremgang måles ved å integrere trinnene som er utviklet av alle Scrum Teams.
  • Når du arbeider i Scaled Scrum, gjennomføres en seremoni kalt 'Scrum of Scrum' daglig eller ukentlig hvor en representant (vanligvis Scrum Master) fra hvert av Scrum Teamet blir kalt til å delta. Dette møtet er det samme som Daily Standup, og målet forblir også det samme: ‘For å opprettholde justeringen og synkroniseringen mellom flere lag’.
  • Hold alltid kjerneverdiene i Scaled Agile Framework (SAFe) intakt på alle nivåer.

Kjerneverdier: Justering, innebygd kvalitet, justering og gjennomsiktighet

Kjerneverdi

  • Kommunikasjon og samarbeid mellom Scrum Teams er nøkkelen til en vellykket Scaled Scrum når det gjelder produktivitet, kvalitet og tid til markedet.

Noen få justeringer her og der i et Scrum Framework kan føre til utrolige resultater i form av Scaled Scrum.

Hvorfor skal vi bruke dette rammeverket?

SAFe 4.0 har nå vist suksess fra mange gigantiske organisasjoner som implementerte dette rammeverket og forbedret kundeopplevelsen ved å levere programvareprodukter på kortest bærekraftig ledetid ved å følge Lean-Agile-måten.

I utgangspunktet fungerer det basert på den smidige utviklingen, systemtenking og mager utvikling.

Det hjelper i:

  • Justere forretningsmessige og tekniske mål for selskapet.
  • Tar beslutninger for å forbedre resultatene.
  • Planlegging for levering i tide.
  • Forbedre kvaliteten på løsningene.
  • Skalering av smidige prosesser til bedriftsnivå.
  • Utnytte de ansattes ferdigheter effektivt.
  • Definere effektive organisasjonsstrukturer
  • Måling av smidig teamytelse
  • Og foreslå måter å motivere folk til godt arbeid og for å lære nye ting og ta risiko.

Her er dataene fra bedrifter som har implementert dem med hell

data fra bedrifter som har implementert SAFe med hell

SAFe-konfigurasjoner

SAFe støtter hele spekteret av utviklingsmiljøer med fire konfigurasjoner,

SAFe-konfigurasjon

1. Viktig SAFe

  • Essential SAFe-konfigurasjonen er hjertet i Framework og er det enkleste utgangspunktet for implementering.
  • Det er den grunnleggende byggesteinen for alle andre SAFe-konfigurasjoner og beskriver de mest kritiske elementene som kreves for å realisere de fleste fordelene ved Framework.
  • Team- og programnivåene danner en organisasjonsstruktur kalt Agile Release Train (ART), der Agile team, viktige interessenter og andre ressurser er viet til et viktig, løpende løsningsoppdrag.

2. Portefølje SAFe

  • Portfolio SAFe-konfigurasjonen hjelper til med å justere porteføljekjøring til bedriftsstrategien.
  • Organisert rundt verdistrømmen.
  • Lean-Agile budsjettering styrker beslutningstakere.
  • Kanban-systemet gir porteføljesynlighet og WIP-grenser.
  • Bedriftsarkitektur styrer større teknologibeslutninger.
  • Objektive beregninger støtter styring og forbedring.
  • Verdi levering via Epics.

3. Stor løsning SAFe

  • Large Solution SAFe-konfigurasjon er for å utvikle de største og mest komplekse løsningene som vanligvis krever flere Agile release-tog og leverandører, men som ikke krever porteføljenivå.
  • Dette er vanlig i bransjer som luftfart, forsvar, bilindustri osv.
  • Solution Train-organisasjonskonstruksjonen av Large Solution Level hjelper bedrifter som står overfor de største utfordringene - å bygge storskala, tverrfaglig programvare, maskinvare og komplekse IT-systemer.
  • Å bygge disse løsningene krever flere roller, gjenstander, arrangementer og koordinering.

4. Full SAFe

  • Full SAFe-konfigurasjonen er den mest omfattende versjonen av Framework.
  • Den støtter bedrifter som bygger og vedlikeholder store integrerte løsninger som krever hundrevis av mennesker eller mer, og inkluderer alle nivåer av SAFe: team, program, stor løsning og portefølje.
  • I største bedrifter kan det være nødvendig med flere forekomster av forskjellige SAFe-konfigurasjoner.

Stiftelsen

Stiftelsen inneholder de støttende prinsippene, verdiene, tankegangen, implementeringsveiledningen og lederrollene som kreves for å levere verdien på en vellykket måte.

1. Lean-Agile Ledere

Ledelsen har det ultimate ansvaret for forretningsresultatene. Ledere må trenes, og deretter bli lærere for, disse slankere måtene å tenke og operere på. For dette formål beskriver SAFe en ny stil for ledelse som utstilles av bedriftens ledere.

Lean-Agile-ledere leder organisasjonen sin i å bygge bedre systemer gjennom iterative og inkrementelle måter å lære, coache, utvikle mennesker og prosesser på.

SAFe Lean-Agile Leaders

SAFe Lean-Agile Leaders er livslange lærere og lærere som hjelper teamene til å bygge bedre systemer gjennom forståelse og utstilling av Lean-Agile Mindset og SAFe-prinsippene.

2. Kjerneverdier

Fire kjerneverdier definerer trossystemet for SAFe:

Programutførelse

  • Programutførelse er de viktigste kjerneverdiene, ettersom det sammenlignes med andre verdier uten at utførelsesteamet ikke kan levere noen verdi til kunden.
  • Hovedsakelig fokuserer det på fungerende programvare og god kundeopplevelse.
  • Kompleks programvareutvikling oppnås ved hjelp av inspeksjon og dyktighet på slutten og fungerer bedre i hver PI.
  • Ikke bare teamene, men med hjelp fra Agile-ledere, kan ledergruppen også utføre kundetilfredshet

Åpenhet

  • På hvert nivå, dvs. team-, program-, verdistrøm- og porteføljenivå, har vi en tavle som viser informasjon om prosjektfremdrift når som helst.
  • Teamet følger smidig scrum, derfor stoler alle teammedlemmene på hverandre og står fritt til å ta avgjørelser som fremmer innovasjoner.
  • Oppfordrer til åpen og ærlig kommunikasjon med alle interessenter.
  • Verdi produktivitet, kvalitet, gjennomsiktighet og åpenhet over intern politikk.

Innebygd kvalitet

  • Innfør trinnvis den innebygde kvalitetspraksisen for programvare, maskinvare og fastvare. Forstå, lære eller sponser utvikling av tekniske ferdigheter til støtte for høykvalitets kode, komponenter, systemer og løsninger.
  • Fostre praksisfellesskap.
  • Forstå, støtte og bruk Agile Architecture and Lean User Experience (UX).

3. Lean-Agile tankesett

Lean-Agile Leaders er livslange lærere og lærere. De forstår og omfavner Lean and Agile prinsipper og praksis.

Lean-Agile tankesett

Vårt Lean-Agile tankesett er representert i to ting:

(i) The House of Lean:

House of Lean er den du ser her.

Den har en rekke elementer:

Verdi, ettersom målet med Lean er veldig enkelt, har den den korteste bærekraftige ledetiden. Det oppnås med søylene i respekt for mennesker og kultur , produktutviklingsflyt, innovasjon - kritisk for langsiktig bærekraft - og ubarmhjertig forbedring. Og den støttes av ledelse .

Det er strukturen der vi pleier å tenke på det magre paradigmet.

(ii) smidig manifest:

For det andre er Agile manifest , som har fulgt med oss ​​siden 2001. Det er et veldig velskrevet dokument, og det står fremdeles sant frem til i dag. Vi trenger Agile Manifest fordi det er nøkkelen til å låse opp motivasjonene og talentene til kunnskapsarbeiderne som utvikler våre løsninger og programvare.

Agile manifest

  1. Den høyeste prioriteten er å tilfredsstille kunden gjennom kontinuerlig og tidlig levering av verdifull programvare.
  2. Ta imot de skiftende kravene, selv om det er sent i utviklingen. Agile prosesser seleendring til kundens fordel.
  3. Lever arbeidsprogramvare 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 kommunikasjonsmetoden med utviklingsteamet er en ansikt til ansikt-samtale.
  7. Arbeidsprogramvare er det primære målet for fremgang.
  8. Agile prosesser fremmer bærekraftig utvikling. Sponsorene, utviklerne og brukerne skal kunne holde et konstant tempo på ubestemt tid.
  9. Kontinuerlig oppmerksomhet mot teknisk fortreffelighet og god design forbedrer smidighet.
  10. Enkelhet - kunsten å maksimere mengden arbeid som ikke er gjort og er mye viktig.
  11. De beste arkitekturer, krav og design kommer fra selvorganiserende team.
  12. Med jevne mellomrom reflekterer teamet over hvordan man kan bli mer effektivt, og stiller deretter inn og justerer oppførselen deretter.

4. SAFe-prinsipper

SAFe-praksis er forankret i ni prinsipper som syntetiserer Agile metoder, Lean produktutvikling, systemtenking og tiår med felterfaring.

  1. Ta et økonomisk syn
  2. Bruk systemtenking
  3. Anta variasjon, bevare alternativer
  4. Bygg trinnvis med raske, integrerte læringssykluser.
  5. Baser milepæler på en objektiv evaluering av arbeidssystemer
  6. Visualiser og begrens WIP, reduser batchstørrelser og administrer kølengder
  7. Bruk tråkkfrekvens, synkroniser med planlegging på tvers av domener
  8. Lås opp den indre motivasjonen til kunnskapsarbeidere
  9. Desentraliser beslutningstaking

5. Implementering veikart

Å implementere endringene som er nødvendige for å bli en Lean-Agile teknologifirma er en betydelig endring for de fleste selskaper. SAFe gir en implementeringskart for å hjelpe eller veilede organisasjoner på denne reisen.

Til slutt, la oss diskutere implementering. Vi beskriver det ved å bruke vår implementerings SAFe 1-2-3-modell.

Nummer 1 er å trene Lean-Agile endringsagenter. Vi kaller disse SAFe-programkonsulentene. Med tilstrekkelig stab av Lean-Agile endringsagenter på stedet og samarbeid med partnerne dine, vil du ha muligheten til å trene ledere og ledere og ledere som er personene som er ansvarlige for å administrere menneskene som gir verdi.

De vil da være i posisjon til å støtte lanseringen av Agile Release Trains. Og med ett tog om gangen vil du bygge den smidige porteføljen.

6. SAFe Program Consultants (SPCs)

SPC er endringsagenter som kombinerer sin tekniske kunnskap om SAFe med en egen motivasjon for å forbedre selskapets programvare og systemutviklingsprosesser.

Konklusjon

Sikker er et rammeverk som gir oss tilpasning ikke bare med teamet (lavere nivå) og programnivå, men som også hjelper oss å tilpasse oss til organisasjonsstrategi (toppnivå) og hvordan et team fungerer for å tilføre verdi til kundene rett fra toppnivået.

Den er tilgjengelig i forskjellige konfigurasjoner, og bedrifter kan dra nytte av den

Den kan brukes av en stor organisasjon, og den har fått gode tilbakemeldinger fra selskaper implementert i den, den har regler, verdier og prinsipper hvis den brukes riktig, organisasjonen kan glede kunden og produsere programvare i kortest mulig bærekraftig ledelse tid som gir verdi.

Med denne veiledningen har vi kommet til slutten av vår Agile Scrum-serien . Vi håper at du hadde det bra og likte å lese artiklene våre om Agile.

Gi oss også beskjed hvis du tror vi kanskje har glemt noe emne i Agile Series. Vi vil gjerne gå en ekstra mil og dekke temaet for deg. Neste er en interessant Agile quiz for deg med svarene. Ikke glem å prøve det !!

angularjs intervju spørsmål og svar for erfaren pdf

PREV Opplæring | NESTE veiledning

Anbefalt lesing

^