safe agile tutorial what is scaled agile framework
Scaled Agile Framework SAFe Tutorial:
I den senaste handboken introducerade vi dig till konceptet för Tre Amigo-principer vilket har visat sig vara mycket fördelaktigt för att leverera rätt lösning i snabbare takt med starka återkopplingsslingor.
Om du inte redan har gått igenom det, kolla in handledningen eftersom det är ett måste för alla för att komma in i det smidiga utrymmet.
I dagens värld av förstklassig teknik och leveransmekanismer är det mycket viktigt att kunna anpassa sig till den föränderliga världen. För att lyckas måste organisationen kunna hantera de snabba förändringarna i hur de utvecklar och levererar värdet till sina kunder.
Med det mesta av organisationens rörelse mot Agility har det blivit mycket viktigt att skala och upprätthålla en konkurrensfördel. Detta är när Scaled Agile Frameworks kommer in i intrycket.
I denna SAFe-handledning kommer vi att diskutera Scaled Agile Framework i detalj. Vi kommer också att lägga tonvikten på behovet av att ta in SAFe som att förstå det övergripande problemförklaringen och slutligen kommer vi att se hur man kan få SAFe i rörelse.
Låt oss börja med att bollen rullar ...
SAFe står för Scaled Agile Frameworks. SAFe tillhandahålls av företaget Scaled Agile. Det skapades 2011, med Dean Leffingwell som skapare och medgrundare.
Den är gjord för att hjälpa företag att skala mera och smidiga programutvecklingsprocesser. Liksom LeSS, DAD och Nexus är SAFe också en av dem som försöker hitta en lösning på de problem som ställs inför uppskalning av laget.
Vad du kommer att lära dig:
- Innan SAFe
- Vad är SAFe?
- Varför Scaled Agile Framework?
- SAFe-bildande
- Varför ska vi använda detta ramverk?
- SAFe-konfigurationer
- Slutsats
- Rekommenderad läsning
Innan SAFe
Tidigare när vi brukade bygga stora och komplexa system var resultatet av resultatet att vi inte kunde leverera i tid och kvaliteten var inte så bra och som ett resultat var kundupplevelsen inte heller bra, vilket är riktigt dåligt!
SAFe försöker ta itu med dessa frågor och företag som har antagit dessa ramar har visat fantastiska resultat.
Vad är SAFe?
Scaled Agile Framework är ett ramverk som ger fyra olika lager av agile-lean adoptions.
Den lägsta nivån kallas TEAM-nivå där flera lag gör på scrum, Kanban eller någon annan smidig metod som använder grunderna för XP-programmering, vilket ger värde på lagnivå.
Nivå två som går från topp till botten är PROGRAM, det hänvisar till de lag som arbetar tillsammans under ledning av programledningsgruppen och levererar värde i begreppet Agile release train.
Det nya lagret som läggs till i SAFe 4.0 är VALUE STREAM, det är inget annat än en kombination av programteam och agile release-tåg som ansvarar för att ge ett betydande värde som levereras till kunderna.
Och precis högst upp har vi vår nästa nivå som heter Portföljnivå som är ansvarig för att anpassa och se hur värde kommer att levereras av de tre nivåerna under portföljen.
Safe stöder mindre lösningar som sysselsätter 50 - 125 utövare, liksom komplexa system som kräver tusentals människor.
Det avslöjas fritt och är en online kunskapsbas med beprövade framgångsrekord. Den används av många organisationer som är involverade i komplex programvaruutveckling. SAFe talar också om utmaningar i komplex programvaruutveckling, det talar också om olika roller, ansvarsområden, artefakter och olika aktiviteter som är involverade i varje lager.
Varför Scaled Agile Framework?
Numera håller ny mjukvara och system maximal uppmärksamhet på marknaden överallt. Att ta in de innovativa idéerna och de nya sätten att arbeta väldigt ofta på är att casta de traditionella och äldre systemen.
Med detta sagt kommer de organisationer som inser och förstår behovet av att gå vidare och anpassa förändringen tidigare att lyckas.
För att utveckla mjukvarusystemen måste vi hålla takten med de komplexiteter och beroenden som uppstår i en sammanlänkad miljö. Och sakerna blir ännu mer komplexa när teknologier som Bigdata, sociala medier, mobil etc. kommer in i bilden.
Organisationerna förväntas hålla takten med att nya tekniker och system kommer in och även behålla de äldre systemen som har funnits där i flera år.
I en traditionell värld använde organisationer vattenfallsmodellen för att utveckla programvaran.
Denna programvara utvecklades i ett sekventiellt läge, dvs nästa fas kunde bara börja när den föregående fasen har slutförts. Detta arbetssätt fungerade utmärkt under antiken, men det ger inte längre de önskade resultaten för miljön där innovation och utveckling är i nivå.
Således kommer organisationerna som arbetar i sekventiellt läge att kämpa för att skala och växa.
Några av de vanliga utmaningarna som vi står inför när vi utvecklar en programvara i en vattenfallsmodell illustreras i bilden nedan:
Notera att dessa problem uppstår vid användning av det dåliga systemet där den anställde arbetar och på grund av den anställdas prestationer.
För att övervinna och slå dessa spärrar och för att uppnå större mål bör vi därför ta in teknikerna för att bli smalare och lyhördare för förändringar. Att rekommendera SAFe rekommenderas därför på grund av dess värderingar, principer och praxis.
SAFe-bildande
Låt oss börja vår diskussion om Scaled Agile Framework och dess bildande. Nu har vi tydligt formulerat och förstått behovet av att ha ett skalat agilt ramverk i en organisation.
Konceptualisera nu en miljö där vi har flera team som arbetar under liknande förhållanden för att uppnå samma mål. Det är dags för oss att gå vidare och se hur Agile Scaled Framework som Scaled Scrum fungerar i detta utrymme.
- Alla intressenter (internt eller externt) och ledningen kommer tillsammans för att skapa en mycket hög nivå Portfolio Vision Document som också kallas Portfolio Backlog. Portfolio Backlog består i huvudsak av flera affärs- och arkitekturkrav som också kallas Epics. Dessa affärs- och arkitektoniska epos är anpassade till prioriteringar.
- Baserat på prioriteringarna plockas dessa epiker av produktcheferna / leveranscheferna. De skapar en väldefinierad färdplan och ett visiondokument. De gör denna aktivitet genom att diskutera släppplanen med Release Management Team för att anpassa färdplanen till produktionsreleaserna.
- När färdplanen och visionsdokumentet har skapats är produktchefens nästa steg att skapa en eftersläpning av programbackloggen. En programbacklog består av släppobjekt, funktionella bitar och en pool av icke-funktionella krav (NFR).
- Release Management Team utarbetar en släppplan som passar in i funktionerna i release-cyklerna.
- Release Management Team arbetar nu med funktionsbitarna för att uppfylla Release Plan och mål. De arbetar också med att förbereda arkitekturen och infrastrukturen för att möjliggöra smidiga utgåvor.
- Från Program Backlog går vi mot en enskild Product Backlog som också kallas Team Backlog. Release / System Team har sin egen produktbacklogg, på samma sätt kommer alla Scrum-team som arbetar med projektet att ha sin individuella Product Backlog.
- Product Backlog består av både funktionella och icke-funktionella berättelser. Dessa berättelser prioriteras av produktägaren som arbetar med det Scrum-teamet.
- Vanligtvis finns det 5-10 Scrum Team som arbetar i en skalad, smidig miljö. Var och en av Scrum-teamet har en produktägare, Scrum Master och ett utvecklingsteam. Rollerna och ansvarsområdena för varje Scrum-teammedlem i Scaled Scrum är desamma som i den normala Scrum-miljön.
- Scrum-teamet utför alla Scrum-ceremonier och arbetar med att utveckla Increment som ska levereras i slutet av varje sprint.
Tips och tricks
- För alla Scrum Team hålls Sprint start- och slutdatum samma som samma varaktighet. Därför är Sprint för alla Scrum Team synkroniserade.
- Eftersom alla Scrum-team arbetar på ett enda uppdrag bör beroenden bland dem vara klart definierade, schemalagda och tilldelade för att minimera störningar i produktleveranser. Beroenden mellan Scrum-lagen är ett av de mest rutinmässiga problemen i Scaled Scrum Environment.
- Varje Scrum-team förväntas leverera ett steg i slutet av varje sprint. Alla dessa steg när de kombineras utgör en potentiellt frigörbar programvaruinkrement.
- När du arbetar i Scaled Scrum, bör du flytta teammedlemmarna från ett team till ett annat noggrant. Teammedlemmar är inte tillåtna under Sprint och det finns inget undantag från denna regel.
- Programmets övergripande framsteg mäts genom att integrera de steg som utvecklats av alla Scrum Teams.
- När du arbetar i Scaled Scrum genomförs en ceremoni som kallas 'Scrum of Scrum' dagligen eller varje vecka där en representant (vanligtvis Scrum Master) från vart och ett av Scrum Team kallas att delta. Detta möte är detsamma som för Daily Standup och målet förblir detsamma: ”För att upprätthålla anpassningen och synkroniseringen mellan flera lag”.
- Håll alltid kärnvärdena i Scaled Agile Framework (SAFe) intakta på alla nivåer.
Kärnvärderingar: Inriktning, inbyggd kvalitet, inriktning och transparens
- Kommunikation och samarbete mellan Scrum Teams är nyckeln till ett framgångsrikt Scaled Scrum när det gäller produktivitet, kvalitet och tid till marknaden.
Några justeringar här och där i ett Scrum Framework kan leda till otroliga resultat i form av Scaled Scrum.
Varför ska vi använda detta ramverk?
SAFe 4.0 har nu visat meritlista för framgång, från många gigantiska organisationer som implementerat detta ramverk och förbättrat kundupplevelsen genom att leverera programvaruprodukter på kortast hållbar ledtid genom att följa Lean-Agile-sättet.
I grund och botten fungerar det baserat på den smidiga utvecklingen, systemtänkande och mager utveckling.
Det hjälper i:
- Anpassa affärs- och tekniska mål för företaget.
- Att fatta beslut för att förbättra resultaten.
- Schema för leverans i tid.
- Förbättra kvaliteten på lösningarna.
- Skala de smidiga processerna upp till företagsnivå.
- Använda de anställdas färdigheter effektivt.
- Definiera effektiva organisationsstrukturer
- Mätning av smidig lagprestanda
- Och föreslå sätt att motivera människor för bra arbete och för att lära sig nya saker & ta risker.
Här är informationen från företag som har implementerat den framgångsrikt
SAFe-konfigurationer
SAFe stöder hela utbudet av utvecklingsmiljöer med fyra konfigurationer,
1. Viktig SAFe
- Essential SAFe-konfigurationen är kärnan i ramverket och är den enklaste utgångspunkten för implementering.
- Det är den grundläggande byggstenen för alla andra SAFe-konfigurationer och beskriver de mest kritiska elementen som krävs för att förverkliga majoriteten av ramverkets fördelar.
- Team- och programnivåerna bildar en organisationsstruktur som kallas Agile Release Train (ART), där agila team, viktiga intressenter och andra resurser ägnas åt ett viktigt, pågående lösningsuppdrag.
2. Portfölj SAFe
- Portföljens SAFe-konfiguration hjälper till att anpassa portföljekörningen till företagsstrategin.
- Organiserat kring värdet.
- Lean-Agile-budgetering ger beslutsfattare möjlighet.
- Kanban-systemet ger portföljens synlighet och WIP-gränser.
- Företagsarkitektur styr större teknikbeslut.
- Objektiva mått stöder styrning och förbättring.
- Värde leverans via Epics.
3. Stor lösning SAFe
- Stor lösning SAFe-konfiguration är för att utveckla de största och mest komplexa lösningarna som vanligtvis kräver flera Agile release-tåg och leverantörer, men som inte kräver portföljnivå.
- Detta är vanligt för industrier som flyg, försvar, bil etc.
- Solution Train-organisationskonstruktionen för Large Solution Level hjälper företag som står inför de största utmaningarna - att bygga storskalig tvärvetenskaplig programvara, hårdvara och komplexa IT-system.
- Att bygga dessa lösningar kräver ytterligare roller, artefakter, evenemang och samordning.
4. Full SAFe
- Full SAFe-konfigurationen är den mest omfattande versionen av Framework.
- Den stöder företag som bygger och underhåller stora integrerade lösningar som kräver hundratals personer eller mer, och inkluderar alla nivåer av SAFe: team, program, stor lösning och portfölj.
- I största företag kan flera instanser av olika SAFe-konfigurationer krävas.
Grunden
Stiftelsen innehåller de stödjande principer, värderingar, tänkesätt, implementeringsvägledning och ledarskapsroller som krävs för att leverera värdet framgångsrikt i skala.
1. Lean-Agile Ledare
Ledningen har det yttersta ansvaret för affärsresultaten. Ledare måste utbildas och sedan bli tränare för dessa smalare sätt att tänka och fungera. För detta ändamål beskriver SAFe en ny ledarstil som visas av företagets ledare.
Lean-Agile-ledare leder sin organisation för att bygga bättre system genom iterativa och inkrementella sätt att lära sig, coacha, utveckla människor och processer.
SAFe Lean-Agile Leaders är livslånga elever och lärare som hjälper teamen att bygga bättre system genom att förstå och visa upp Lean-Agile Mindset och SAFe-principerna.
2. Kärnvärden
Fyra kärnvärden definierar trossystemet för SAFe:
Programutförande
- Programutförande är de viktigaste kärnvärdena eftersom det jämförs med andra värden utan vilka exekveringsteamet inte kan leverera något värde till kunden.
- Främst fokuserar det på fungerande programvara och bra kundupplevelse.
- Komplex mjukvaruutveckling genomförs med hjälp av inspektion och skicklighet i slutet och fungerar bättre i varje PI.
- Inte bara lagen utan med hjälp av Agile ledare kan ledarskapsteamet också utföra kundnöjdhet
Genomskinlighet
- På varje nivå, dvs team, program, värdeström och portföljnivå, har vi en whiteboard som visar information om projektets framsteg när som helst.
- Teamet följer smidig scrum, alltså alla teammedlemmar litar på varandra och är fria att fatta beslut som främjar innovationer.
- Uppmuntrar öppen och ärlig kommunikation med alla intressenter.
- Värder produktivitet, kvalitet, öppenhet och öppenhet över intern politik.
Inbyggd kvalitet
- Anpassa stegvis de inbyggda kvalitetsmetoderna för programvara, hårdvara och firmware. Förstå, undervisa eller sponsra teknisk kompetensutveckling till stöd för högkvalitativ kod, komponenter, system och lösningar.
- Främja praktikgemenskaper.
- Förstå, stödja och tillämpa Agile Architecture and Lean User Experience (UX).
3. Lean-Agile Mindset
Lean-Agile Leaders är livslånga elever och lärare. De förstår och omfamnar Lean and Agile principer och metoder.
Vårt Lean-Agile tänkesätt representeras i två saker:
(i) The House of Lean:
House of Lean är det du ser här.
Den har ett antal element:
Värde, eftersom målet med Lean är väldigt enkelt har det den kortaste hållbara ledtiden. Det uppnås med pelarna i respekt för människor och kultur , produktutvecklingsflöde, innovation - avgörande för långsiktig hållbarhet - och obeveklig förbättring. Och det stöds av ledarskap .
Det är strukturen där vi tenderar att tänka på Lean-paradigmet.
(ii) Agilt manifest:
För det andra är Agile Manifesto , som har varit med oss sedan 2001. Det är ett väldigt välskrivet dokument, och det står fortfarande sant fram till idag. Vi behöver Agile Manifesto eftersom det är nyckeln till att låsa upp motivation och talanger hos kunskapsarbetare som utvecklar våra lösningar och programvara.
Agile Manifesto
- Högsta prioritet är att tillfredsställa kunden genom kontinuerlig och tidig leverans av värdefull programvara.
- Anta de förändrade kraven, även om det är sent i utvecklingen. Agile processer utnyttjar förändringar till kundens fördel.
- Leverera arbetsprogramvara ofta, från ett par veckor till ett par månader, med en preferens framför kortare tidsskala.
- Utvecklare och affärsmän måste arbeta tillsammans dagligen under hela projektet.
- Bygg projekt kring motiverade individer. Ge dem stöd och den miljö de behöver, och lita på dem att få jobbet gjort.
- Den mest effektiva metoden för kommunikation med utvecklingsteamet är en konversation ansikte mot ansikte.
- Arbetsprogramvara är det primära måttet på framsteg.
- Agila processer främjar hållbar utveckling. Sponsorer, utvecklare och användare ska kunna hålla en konstant takt på obestämd tid.
- Kontinuerlig uppmärksamhet på teknisk spetskompetens och god design ökar smidigheten.
- Enkelhet - konsten att maximera mängden arbete som inte utförts och är mycket viktigt.
- De bästa arkitekturerna, kraven och designen framgår av självorganiserande team.
- Med regelbundna mellanrum reflekterar teamet över hur man kan bli mer effektivt, ställer sedan in och justerar sitt beteende därefter.
4. SAFe-principer
SAFe-praxis bygger på nio principer som syntetiserar Agile-metoder, Lean-produktutveckling, systemtänkande och decennier av fälterfarenhet.
- 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
5. Färdplan för implementering
Att genomföra de förändringar som är nödvändiga för att bli ett Lean-Agile-teknikföretag är en betydande förändring för de flesta företag. SAFe tillhandahåller en färdplan för implementering för att hjälpa eller vägleda organisationer på denna resa.
Slutligen, låt oss diskutera genomförandet. Vi beskriver det med vår implementeringsmodell SAFe 1-2-3.
Nummer 1 är att utbilda Lean-Agile förändringsagenter. Vi kallar dessa SAFe-programkonsulter. Med tillräcklig personal av Lean-Agile förändringsagenter på plats och samarbetar med dina partners har du möjlighet att utbilda chefer och ledare och chefer som är de personer som ansvarar för att hantera de människor som levererar värde.
De kommer då att kunna stödja lanseringen av Agile Release Trains. Och med ett tåg i taget bygger du den Agile-portföljen.
6. SAFe-programkonsulter (SPC)
SPC: er är förändringsagenter som kombinerar sin tekniska kunskap om SAFe med en inneboende motivation att förbättra företagets programvara och systemutvecklingsprocesser.
Slutsats
Säker är ett ramverk som ger oss anpassning inte bara till teamet (lägre nivå) och programnivå utan också hjälper oss att anpassa oss till organisationsstrategi (toppnivå) och hur ett team fungerar för att skapa mervärde för kunderna direkt från toppnivån.
Den finns i olika konfigurationer och företag kan dra nytta av den
Den kan användas av en stor organisation, och den har fått god feedback från företag som implementerats i den, den har fått regler, värderingar och principer om den används korrekt, organisationen kan göra kundnöjd och producera programvara på kortast hållbart sätt tid som ger mervärde.
Med denna handledning har vi kommit till slutet av vår Agile Scrum-serien . Vi hoppas att du hade det bra och tyckte om att läsa våra artiklar om Agile.
Låt oss också veta om du tror att vi kanske har glömt något ämne i Agile Series. Vi går gärna en extra mil och täcker ämnet åt dig. Nästa är en intressant Agile quiz för dig med svaren. Glöm inte att prova !!
selen med c # intervjufrågor
PREV-handledning | NÄSTA självstudie
Rekommenderad läsning
- JIRA Agile Tutorial: Hur man använder JIRA effektivt för att hantera agila projekt
- Fördjupade förklaringar om förmörkelser för nybörjare
- Agile Scrum Online Quiz: Testa din kunskap om Agile Scrum
- Kanban vs Scrum vs Agile: En detaljerad jämförelse för att hitta skillnader
- Hur man levererar högvärdiga programvarufunktioner på kort tid med Agile Scrum Process
- Java Collections Framework (JCF) Tutorial
- Agile Manifesto: Förstå agila värden och principer
- Java Reflection Tutorial med exempel