SAFe Methodology Tutorial: What is Scaled Agile Framework

Innehållsförteckning:

Anonim

Vad är en Scaled Agile Framework (SAFe)?

Scaled Agile Framework (SAFe) är en fritt tillgänglig online kunskapsbas som gör att du kan använda lean-agile metoder på företagsnivå. Det ger en enkel och lätt upplevelse för mjukvaruutveckling. Det är en uppsättning organisationer och arbetsflödesmönster som är avsedda att vägleda företag för att skala mager och smidig praxis. Den är indelad i tre segment som är Team, Program och portfolio.

SAFe- ramverket tillåter team för,

  • Implementera Lean-Agile programvara och system på företagsnivå
  • Det bygger på Lean och Agile principer.
  • Det ger detaljerad vägledning för arbete på företagets portfölj, Value Stream, Program och Team.
  • Den är utformad för att möta behoven hos alla intressenter inom en organisation.

SAFe utvecklades först inom fältet och utvecklades i Dean Leffingwells böcker och blogg. Version 1.0 är den första officiella versionen 2011. Den senaste versionen är 4.6, släpptes i oktober 2018. Den ger vägledning för att arbeta på företagsportfölj-, Value Stream-, program- och teamnivåer.

I denna SAFe Agile-handledning lär du dig-

  • Vad är Scaled Agile Framework (SAFe)
  • Varför använda Agile Framework
  • När ska du använda Scaled Agile Framework
  • Hur annorlunda än andra agila metoder
  • Fundament of Scaled Agile Framework
  • Agile Manifesto
  • Olika nivåer i SAFE
    • Lagnivå
    • Programnivå
    • Portföljnivå
    • Värde Stream-nivå

Varför använda Agile Framework

Det är en enkel och lätt ram men ändå kan den hantera behoven hos stora värdeströmmar och komplex systemutveckling. Genom att implementera SAFe agile ramverk har du följande fördelar:

Fördelar med att använda Agile Framework
  • Produktiviteten ökade med 20 - 50%
  • Kvaliteten ökade mer än 50%
  • Time to Market är snabbare än 30-75%
  • Ökat medarbetarengagemang och arbetsglädje.

Det detaljerade ramschemat finns på webbplatsen. Den visar alla nyckelroller, aktiviteter, leveranser och flöden. Det fungerar också som ett navigeringshjälpmedel för resten av webbplatsen.

Bilden nedan förklarar hur smidig process fungerar. Epics är ett stort arbete, som ytterligare delas upp i ett antal mindre berättelser eller subepos. Dessa underepos tilldelas laget som en berättelse. Varje team arbetar sedan med dessa berättelser eller programvarufunktioner i enlighet med detta.

Skalad Agile Framework Architecture

När ska du använda Scaled Agile Framework

  • När ett team är intresserat av att implementera ett smidigt tillvägagångssätt genom större program och portföljer med flera team.
  • När flera lag kör sitt eget sätt att agila implementeringar men regelbundet möter hinder, förseningar och misslyckanden.
  • När team vill arbeta självständigt.
  • När du vill skala Agile över hela organisationen men inte är säker på vilka nya roller som kan behövas eller vilka befintliga roller (dvs. ledning) som behöver ändras och hur.
  • När du har försökt att skala Agile över din organisation men kämpar för att uppnå enhetlig eller konsekvent strategi över affärsavdelningar från portfölj till program- och teamnivå.
  • När en organisation behöver förbättra sin produktutveckling ledtid och vill veta hur andra företag har lyckats skala Agile med SAFe.

Hur annorlunda än andra agila metoder

Nu i denna Scaled Agile Framework-handledning, låt oss se hur Scaled Agile framework skiljer sig från andra agila metoder,

  • Det är allmänt tillgängligt och gratis att använda.
  • Finns i en mycket tillgänglig och användbar form.
  • Det är lätta, praktiskt bevisade resultat och specifika för nivå.
  • Det ändrar / upprätthåller ständigt / regelbundet de vanligaste agila metoderna.
  • Erbjuder användbara tillägg till vanliga agila metoder.
  • Motiverar smidiga metoder i ett företagssammanhang.
  • Erbjuder en komplett bild av mjukvaruutveckling.
  • Synlighet eller öppenhet är mer på alla nivåer.
  • Fortsätter eller regelbunden feedback om kvalitet och förbättring.

Fundament of Scaled Agile Framework

Fundament of Scaled Agile Framework

Scaled Agile Framework (SAFe): Den står på grunden för dess

  1. Lean-Agile-principer
  2. Kärnvärderingar,
  3. Lean-Agile Ledarskap
  4. Lean-Agile Mind-set,
  5. Practices Communities (grupp människor som ständigt arbetar med SAFe-metoder)
  6. Implementering 1-2-3

SAFe Lean-Agile-principer

Dessa grundläggande SAFe Agile-principer och värden för SAFe måste förstås, visas och fortsättas för att uppnå önskat resultat.

  • Ta en ekonomisk syn
  • Tillämpa systemtänkande
  • Antag variabilitet; bevara alternativ
  • Bygg stegvis med snabba, integrerade inlärningscykler
  • Basera milstolpar på en objektiv utvärdering av arbetssystem
  • Visualisera och begränsa WIP, minska batchstorlekar och hantera kölängder
  • Använd kadens, synkronisera med planering över flera domäner
  • Lås upp kunskapsarbetarnas inneboende motivation
  • Decentralisera beslutsfattandet

SAFe Agile Core Värden

SAFe Agile-metoden bygger på dessa fyra värden.

Inriktning:

  • SAFe stöder anpassning.
  • Inriktning börjar kl.
    • Strategiska teman i portföljens eftersläp och
    • Flyttar ner till Vision och färdplan för Program Backlogs och sedan
    • Flyttar till Team Backlogs.

Inbyggd kvalitet:

  • Det säkerställer att varje inkrementell leverans återspeglar kvalitetsstandarderna.
  • Kvalitet är inte "läggs till senare" är inbyggd.
  • Inbyggd kvalitet är en förutsättning för Lean och dess obligatoriska

Genomskinlighet:

  • Öppenhet är möjliggör för förtroende.
  • SAFe hjälper företaget att uppnå transparens på alla nivåer - chefer, portföljchefer och andra intressenter.
  • Alla kan se in i portföljens eftersläpning / Kanban, programbacklogs / Kanban och Team Backlog / Kanban.
  • Varje nivå har en tydlig förståelse för PI-målen.
  • Tågprogram har synlighet i lagets eftersläpningar, liksom andra programunderskott
  • Team och program har synlighet i affärs- och arkitekturepics. De kan se vad som kan vara på väg mot dem.

Programutförande:

  • SAFe lägger stort fokus på arbetssystem och resulterande affärsresultat.
  • SAFe är inte användbart om lag inte kan utföra och kontinuerligt leverera värde.

Lean Agile Leaders:

Lean-Agile Leaders är livslånga elever och lärare. Det hjälper team att bygga bättre system genom att förstå och visa upp Lean-Agile SAFe-principerna.

Som en möjliggörare för lagen är det yttersta ansvaret antagande, framgång och kontinuerlig förbättring av Lean-Agile-utvecklingen. För förändring och kontinuerlig förbättring måste ledare utbildas.

Ledare måste anta en ny ledarstil. En som verkligen ger och engagerar individer och team för att nå sin högsta potential.

Principer för dessa Lean-Agile Leaders

  • Led förändringen
  • Känn vägen; Betona livslångt lärande
  • Utveckla människor
  • Inspirera och anpassa dig till uppdraget; Minimera begränsningar
  • Decentralisera beslutsfattandet
  • Lås upp den inneboende motivationen för kunskapsarbetare

Lean Agile Mind-Set:

Lean-Agile tänkesätt representeras i två saker:

  1. SAFe House of Lean
  2. Agile Manifesto

SAFe House of Lean :

SAFe härrör från Lean-tillverkningsprinciper och metoder. Baserat på dessa faktorer presenterar SAFe "SAFe House of Lean". Det är inspirerat av "house" of lean Toyota.

Målet med lean är oslagbart: Att leverera maximalt kundvärde på kortaste ledtid med högsta möjliga kvalitet till kunden

Nedanstående figur förklarar målet, pelarna och grunden för "SAFe House of Lean."

Mål och grunder för skalad agil ramverk

Agile Manifesto

Vi avslöjar bättre sätt att utveckla programvara genom att göra det och hjälpa andra att göra det. Genom detta arbete har vi kommit till värde:

Agile Manifesto

Därför, medan det finns ett värde i objekten till höger, värderar vi objekten till vänster mer.

Agile Manifesto

  1. Högsta prioritet är att tillfredsställa kunden genom kontinuerlig och tidig leverans av värdefull programvara.
  2. Anta de förändrade kraven, även sent i utvecklingen. Agile SAFe-metodik bearbetar förändringar i sele för kundens fördel.
  3. Leverera arbetsprogramvara ofta, från ett par veckor till ett par månader, med en preferens framför kortare tidsskala.
  4. Utvecklare och affärsmän måste arbeta tillsammans dagligen under hela projektet.
  5. Bygg projekt kring motiverade individer. Ge dem stöd och den miljö de behöver, och lita på dem att få jobbet gjort.
  6. Den mest effektiva metoden för kommunikation med ett utvecklingsteam är en konversation ansikte mot ansikte.
  7. Arbetsprogramvara är det primära måttet på framsteg.
  8. Agila processer främjar hållbar utveckling. Sponsorerna, utvecklarna och användarna bör kunna hålla en konstant takt på obestämd tid.
  9. Kontinuerlig uppmärksamhet på teknisk spetskompetens och god design ökar smidigheten.
  10. Enkelhet - konsten att maximera mängden arbete som inte utförts - är väsentlig.
  11. De bästa arkitekturerna, kraven och designen framgår av självorganiserande team.
  12. Med regelbundna mellanrum reflekterar teamet över hur man kan bli effektivare, ställer sedan in och justerar sitt beteende därefter.

Olika nivåer i SAFE

Det finns två olika typer av SAFe-implementering:

  1. SAFe 4.0 implementering
  2. SAFe 3.0-implementering
Nivåer av SAFe
  • I SAFe 4.0-implementeringen har vi 4-nivåer: Portfölj, Value Stream, Program och Team.
  • I SAFe 3.0-implementeringen har vi 3-nivåer: portfölj, program och team
  • 3-nivå SAFe är för mindre implementeringar med 100 eller färre personer. Program som inte kräver betydande samarbete.
  • 4-nivå SAFe är för lösningar som vanligtvis kräver att många hundra utövare utvecklar distribution och underhåll av programvara.

Lagnivå

Roller / lag evenemang Artefakter
* Agilt team * Sprintplanering * Lagbacklog
* Produktägare * Backloggrooming * Icke-funktionella krav
* Scrum Master * Daglig stand-up * Team PI-mål
* Avrättning * Iterationer
* Sprintdemo * Berättelser (arbetsprogramvara)
* Sprint retrospektiv * Sprintmål
* IP-sprints * Inbyggd kvalitet
* Spikar
* Team Kanban
  • Alla SAFe-lag ingår i ett eller annat Agile Release Train (ART).
  • SAFe-team är bemyndigade, självorganiserande, självhanterande, tvärfunktionella team
  • Varje lag är lika ansvarigt för att definiera, bygga och testa berättelser från deras Team Backlog i fasta längder
  • Lag planerar och utför två-veckors it-box-iterationer i enlighet med överenskomna Iterationsmål.
  • Team kommer att använda ScrumXP / Team Kanban-rutinen för att leverera högkvalitativa system för att producera en systemdemo varannan vecka.
  • Alla olika team i ART (Agile Release Trains) kommer att skapa ett integrerat och testat system. Intressenter kommer att utvärdera och svara med snabb feedback
  • De tillämpar inbyggda kvalitetsmetoder.
  • Varje ScrumXP-team kommer att ha 5-9 teammedlemmar, vilket inkluderar alla roller som är nödvändiga för att bygga ett kvalitetsstegvärde i varje Iteration.
  • ScrumXP-roller inkluderar:
    • Team (Dev + QA)
    • Scrum Master
    • Produktägare. Etc…
  • SAFe delar upp tidslinjen för utveckling i en uppsättning iterationer inom en PI (Program Increment).
  • PI-varaktighet är mellan 8-12 veckor.
  • Teamet kommer att använda berättelser för att leverera värdet. Produktägaren kommer att ha innehållsbehörighet över sin skapande och acceptans av berättelserna.
  • Berättelser innehåller kundens krav.
  • Team Backlog innehåller berättelser om användare och möjliggörare, som identifieras under PI-planering. När Product Management presenterar färdplanen, visionen och programmets eftersläpning.
  • Att identifiera, utarbeta, prioritera, schemalägga, implementera, testa och acceptera berättelserna är de främsta kraven för ledningsarbete på lagnivå.
  • Varje iteration ger:
    • Ett värdefullt ökat antal nya funktioner
    • Uppnå genom ständigt upprepande mönster
    • Planera iterationen
    • Engagera dig för vissa funktioner
    • Utför iterationen genom att bygga och testa berättelser
    • Demo den nya funktionaliteten
    • Retrospektiv
    • Upprepa för nästa iteration
  • Team stöder också System Demo i slutet av varje Iteration. vilket är den kritiska integrationspunkten för ART.
  • Större värdeströmmar kommer att ha flera ART.
  • Iterationerna Innovation and Planning (IP) utnyttjar lagen med en möjlighet till innovation och utforskning.

Programnivå

Roller / lag evenemang Artefakter
* DevOps * PI-planering (Program Increment) * Syn
* Systemteam * Systemdemonstrationer * Färdplan
* Släpphantering * Inspektera och anta workshop * Mätvärden
* Produktledning * Arkitektonisk bana * Milstolpar
* UEX-arkitekt * Släpp när som helst * Släpp
* Släpp tågingenjör (RTE) * Agile Release Train * Program Epics
* Systemarkitekt / ingenjör * Släpp * Program Kanban
* Företagsägare * Programbacklog
* Lean-Agile Leaders * Icke-funktionella krav
* Gemensamma praxis Viktat kortaste jobb först (WSJF)
* Delade tjänster * Program PI-mål
* Kund * Funktion
* Möjliggörare
* Lösning
* Value Stream-samordning
  • På programnivå levereras Value of SAFe av långlivade Agile Release Trains (ART). Iteration är för team och tåg är för programmet.
  • Agile Release Trains (ART) är det primära fordonet för värdetillförsel på programnivå. Det levererar en värdeström till organisationen.
  • Programinkrementen (PI) är 8 till 12 veckor.
  • ART består av 5 - 12 Agile Teams (~ 50 - 125+ personer) som inkluderar alla roller och infrastruktur som behövs för att leverera helt testad, fungerande programvara på systemnivå.
  • Varje PI är en tidsruta med flera ikoner. Under vilken en betydande, värdefull ökning av systemet utvecklas och levereras.
  • I varje PI kommer en "demo" och "Inspektera och anpassa" sessioner att hända, och planeringen börjar för nästa PSI.
  • På programnivå betonar SAFe principen om anpassning. Detta beror på att flera agila teaminsatser är integrerade för att skapa kundvärde.
  • SAFe-artefakthierarkin är Epics-> features-> användarberättelser .
  • På programnivå har Product Manager / Program Manager innehållsbehörighet. Han definierar och prioriterar programmets eftersläpning.
  • Programbacklog är en prioriterad lista med funktioner.
  • På programnivå kan funktioner ha sitt ursprung, eller de kan härledas från epik som definierats på portföljnivån.
  • Funktioner sönderdelas till användarberättelser och flyter till eftersläp på lagnivå.
  • Produktchef eller rollen Release Train Engineer kan hanteras av Program Manager / Senior Project Manager
  • Systemarkitektens roll på programnivå är att samarbeta med det dagliga arbetet. Det säkerställer att icke-funktionella krav uppfylls. De arbetar också med företagsarkitekten på portföljnivå för att se till att det finns tillräckligt med arkitektonisk bana för att stödja kommande användar- och affärsbehov.
  • Gränssnittsdesign, riktlinjer för användarupplevelse och designelement för lagen tillhandahålls av UX Designers.
  • Chief-Scrum Master-roll spelas av 'Release Train Engineer'.
  • Olika team (från marknadsföring, utveckling, kvalitet, drift och distribution) bildar 'Release Management Team'. De kommer att godkänna rutinutgivningar av kvalitetslösningar till kunderna.
  • Distribution av programvara i kundmiljöer och framgångsrik leverans sköts av DevOps team.

Portföljnivå

Roller / lag evenemang Artefakter
* Företagsarkitekt * Strategisk investeringsplanering * Strategiska teman
* Programportfölj Mgmt * Kanban Portfolio (Epic) Planning * Företag
* Episka ägare * Eftersläp i portföljen
* Portfölj Kanban
* Icke-funktionella krav
* Epic och Enabler
* Värde Stream
* Budgetar (CapEx och OpEx)
  • SAFe Portfolio är den högsta nivån av intresse / oro / engagemang / i SAFe
  • Portföljen tillhandahåller grundläggande block för att organisera Lean-Agile Enterprise-värdeflöde via en eller flera Value Streams.
  • Portföljen hjälper till att utveckla system och lösningar som beskrivs i strategiska teman (länkar en SAFe-portfölj till företagets föränderliga affärsstrategi).
  • För att uppnå strategiska mål inkapslar portföljnivån dessa element. Den tillhandahåller grundläggande budgeteringsmekanismer och andra styrmekanismer. På detta sätt säkerställer det att investeringen i värdeströmmarna ger den avkastning som krävs för företaget.
  • En portfölj är kopplad till verksamheten i två riktningar:
    • För att vägleda portföljen till de större förändrade affärsmålen ger den strategiska teman.
    • En annan riktning indikerar det konstanta flödet av portföljvärden.
  • Programportföljhantering fungerar som intressenter och de är ansvariga för att leverera affärsresultaten.
  • SAFe Portfolio Level innehåller människor, processer och nödvändiga byggsystem och lösningar som ett företag behöver för att uppfylla sina strategiska mål.
  • Value Streams är de främsta målen i portföljen, med vilken finansiering för människorna och andra resurser som krävs för att bygga lösningarna.
  • Viktiga nyckelbegrepp som används här är:
    • Anslutning till företaget,
    • Programportföljhantering,
    • Hantera flödet av portföljepos.

Värde Stream-nivå

Roller / lag evenemang Artefakter
* DevOps * Planering före och efter PI (Program Increment) * Syn
* Systemteam * Lösningsdemonstrationer * Färdplan
* Släpphantering * Inspektera och anta workshop * Mätvärden
* Lösningshantering * Agile Release Train * Milstolpar
* UEX-arkitekt * Släpp
* Value Stream Engineer (RTE) * Value Stream Epics
* Lösningsarkitekt / ingenjör * Värde Stream Kanban
* Delade tjänster * Värde Stream Backlog
* Kund * Icke-funktionella krav
* Leverantör Viktat kortaste jobb först (WSJF)
* Value Stream PI-mål
* Kapacitet
* Möjliggörare
* Lösningskontext
* Value Stream-samordning
* Ekonomisk ram
* Lösningens avsikt
* MBSE
* Set Baserat
* Agil arkitektur
  • Value Stream-nivån är valfri i SAFe.
  • Value Stream-nivån är ny i SAFe 4.0.
  • Value Stream-nivån är avsedd / utformad för företag / byggare / organisation som är:
  1. Stor i storlek
  2. Självständig
  3. Ha komplexa lösningar
  4. Deras lösningar kräver vanligtvis flera ART
  5. De har bidrag från leverantörer.
  6. De står inför de största systemutmaningarna
  7. För cyber-fysiska system
  8. För programvara, hårdvara, el och elektronik, optik, mekanik, fluidik och mer.
  • Att bygga denna typ av system tar ofta hundratals, till och med tusentals utövare, externa och interna leverantörer.
  • Om systemen är avgörande. Fel på lösningen, eller till och med ett delsystem, har oacceptabla ekonomiska och sociala konsekvenser.
  • Om företagen kan byggas med några hundra utövare behöver det kanske inte konstruktioner på denna nivå. I så fall kan de använda från ' kollapsad vy' som är 3-nivå SAFe.
  • Att bygga värdeströmslösningar i ett Lean-Agile-mönster kräver ytterligare artefakter, samordning och konstruktioner. Så denna nivå innehåller ett ekonomiskt ramverk för att tillhandahålla ekonomiska gränser för Value Stream
  • Den stöder kadens och synkronisering för flera ART och leverantörer. Det inkluderar planeringsmöten före och efter PI och lösningsdemo.
  • Det ger ytterligare roller som är: Value Stream Engineer, Solution Architect / Engineering och Solution Management.

Sammanfattning:

  • SAFe är en branschbeprövad, värdefokuserad metod för att skala Agile på företagsnivå.
  • Den svarar på frågorna som "Hur planerar vi?", "Hur budgetar vi?" Och "Hur blir vi tvärfunktionella i arkitektur och DevOps?"
  • SAFe Agile-ramverk hjälper stora organisationsteam att nå en organisations strategiska mål, inte bara enskilda projektmål.
  • Ramverket erbjuder förmågan att upprätthålla och skapa en centraliserad strategi för att leverera värde.
  • SAFe-modellen har tre / fyra nivåer som centraliserar en organisations strategiska teman.
  • Centraliserad strategi, kombinerat med det decentraliserade agila utvecklingsutförandet.

Referenser:

SAFe for Lean Enterprises 5.0:

http://www.scaledagileframework.com

Denna artikel har bidragit av Jyothi Rangaraj