PI planering

framtida produktutvecklingsuppgifter kan inte förutbestämmas. Distribuera planering och kontroll till dem som kan förstå och reagera på slutresultatet.

det finns ingen magi i SAFe . . . förutom kanske för PI-planering.

program Increment (PI) planering är en kadensbaserad händelse som fungerar som hjärtslag för Agile Release Train (ART), som anpassar alla lag på konsten till ett gemensamt uppdrag och Vision.

pi-planering är viktigt för säker: om du inte gör det, gör du inte säkert.

det Agila manifestet säger, ” den mest effektiva och effektiva metoden för att förmedla information till och inom ett utvecklingsteam är en konversation ansikte mot ansikte.”SAFe tar detta till nästa nivå med PI-planering.

om möjligt innebär detta fysisk samlokalisering, och dessa storskaliga pi-planeringshändelser äger nu rum inom många företag runt om i världen. De har tydligt visat verklig ekonomisk avkastning, för att inte tala om de immateriella tillgångar som uppstår när teamet av agila team skapar en social konstruktion som är personligen och kollektivt givande.

det kanske inte alltid är praktiskt för hela konsten att samlokalisera, och i vår nuvarande tid har COVID-19 skapat en situation där detta inte är ett alternativ. Medan fysisk ansikte mot ansikte planering har sina fördelar, är den oskrivna säkra ”regeln ”” de människor som gör arbetsplanen arbetet.”När fysisk närvaro inte är möjlig har realtid, samtidig, virtuell, ansikte mot ansikte planering nu visat sig vara effektiv. Faktum är att många konster har lyckats skapa en hybridsituation där flera lag går med på distans, som visas nedan i Figur 1.

den avancerade ämnesartikeln, distribuerad PI-planering med SAFe, ger ytterligare vägledning och överväganden för att framgångsrikt hantera dessa scenarier.

PI Planning har en standardagenda som innehåller en presentation av affärssammanhang och vision, följt av Team planning breakouts—där lagen skapar sina Iterationsplaner och mål för det kommande programmet Increment (PI). Underlättas av Release Train Engineer (RTE), denna händelse omfattar alla medlemmar av konsten och sker inom Innovation och planering (IP) Iteration. Att hålla händelsen under IP-iterationen undviker att påverka schemaläggningen eller kapaciteten hos andra iterationer i PI. PI-planering sker under två dagar, även om detta ofta utvidgas för att rymma planering över flera tidszoner.

affärsfördelar med PI-planering

PI-planering ger många affärsfördelar, inklusive:

• upprätta ansikte mot ansikte kommunikation över alla teammedlemmar och intressenter
• bygga det sociala nätverket konsten beror på
• anpassa utvecklingen till affärsmål med affärssammanhang, vision, och Team och Program pi mål
• identifiera beroenden och främja cross-team och cross-ART samarbete
• ger möjlighet för ’just nu rätt mängd’ av arkitektur och lean user experience (UX) vägledning
• matcha efterfrågan på kapacitet och eliminera överskott arbete i processen (WIP)
• snabb beslutsfattande

ingångar och utgångar för PI-planering

ingångar till PI-planering inkluderar:

• Business context (se ’content readiness’ nedan)
• färdplan och vision
• topp 10 funktioner i programmet Backlog

en framgångsrik PI planering händelse levererar två primära utgångar:

• engagerade PI-mål-en uppsättning smarta mål som skapas av varje team med affärsvärdet tilldelat av företagare.
• program board – belyser de nya funktionerna leveransdatum, funktion beroenden mellan lag och relevanta milstolpar.

förberedelse

pi-planering är en viktig händelse som kräver förberedelse, samordning och kommunikation. Det underlättas av RTE och evenemangsdeltagare inkluderar företagare, produkthantering, smidiga Team, System-och lösningsarkitekt/teknik, Systemteamet och andra intressenter, som alla måste meddelas i förväg för att vara väl förberedda. Företagsägarnas aktiva deltagande i detta evenemang ger ett viktigt skyddsräcke på budgetutgifterna.

för att evenemanget ska lyckas krävs förberedelser inom tre huvudområden:

• organisatorisk beredskap-strategisk anpassning och team och tåg setup
• Content readiness – Management and development preparedness
• Logistics readiness – överväganden för att köra ett lyckat evenemang

nedan är höjdpunkterna i Art Readiness Checklist. (Den fullständiga checklistan finns i SAFe Pi Planning Toolkit, tillgänglig för SPCs).

organisatorisk beredskap

innan PI-planering måste det finnas strategijustering bland deltagare, intressenter och företagare. Kritiska roller tilldelas. För att ta itu med detta i förväg måste evenemangsarrangörer dock överväga följande:

• planering omfattning och sammanhang-är omfattningen (produkt, system, teknik domän) av planeringsprocessen förstås? Vet vi vilka team som behöver planera tillsammans?
• business alignment – finns det rimlig överenskommelse om prioriteringar bland företagare?
• agila team – har vi agila team? Finns det dedikerade teammedlemmar och en identifierad Scrum Master och produktägare för varje lag?

Innehållsberedskap

det är lika viktigt att se till att det finns en tydlig vision och sammanhang och att rätt intressenter kan delta. Därför måste Pi-planeringen innehålla:

• Executive briefing – en briefing som definierar det aktuella affärssammanhang
• produkt vision briefing (s – – Briefings utarbetats av Product Management, inklusive de 10 funktioner i programmet Backlog
• arkitektur vision briefing – en presentation gjord av CTO, Enterprise Architect, eller System Architect att kommunicera nya möjliggörare, funktioner och icke-funktionella krav (NFRs)

Logistikberedskap

att förbereda ett evenemang för att stödja ett stort antal deltagare är inte trivialt. För fysiskt samlokaliserad planering kan detta inkludera att säkra och förbereda det fysiska utrymmet. För avlägsna deltagare, eller för en fullt distribuerad PI-planering, inkluderar detta också investeringar i nödvändig teknisk infrastruktur. Överväganden inkluderar:

• platser – varje planeringsplats måste förberedas i förväg
• teknik och verktyg – realtidsåtkomst till information och verktyg för att stödja distribuerad planering eller fjärranslutna deltagare
• kommunikationskanaler-primära och sekundära ljud–, video-och presentationskanaler måste vara tillgängliga

Standard Agenda

händelsen följer en agenda som liknar figur 2. Beskrivningar av varje objekt följer. För vägledning om hur du anpassar denna agenda för att stödja planering över flera tidszoner, se artikeln avancerat ämne, distribuerad PI-planering med SAFe.

Dag 1 Agenda

• Business context – en företagsägare eller ledande befattningshavare beskriver företagets nuvarande tillstånd, delar Portföljvisionen och presenterar ett perspektiv på hur effektivt befintliga lösningar tillgodoser nuvarande kundbehov.
• produkt – /lösningsvision-produkthantering presenterar den nuvarande visionen (vanligtvis representerad av nästa topp 10 kommande funktioner) och belyser eventuella ändringar från föregående pi-planeringshändelse, liksom eventuella kommande milstolpar.
• Arkitekturvision och utvecklingspraxis – systemarkitekt/teknik presenterar arkitekturvisionen. En senior utvecklingschef kan också införa Agile-stödjande förändringar i utvecklingspraxis, såsom testautomatisering, DevOps, kontinuerlig Integration och kontinuerlig distribution, som avanceras i den kommande PI.
• Planeringskontext och lunch – RTE presenterar planeringsprocessen och förväntade resultat av evenemanget.
• Team breakouts #1 – i breakout uppskattar lagen sin kapacitet för varje Iteration och identifierar de backlog-objekt som de sannolikt kommer att behöva för att förverkliga funktionerna. Varje lag skapar sina utkast till planer, synliga för alla, iteration genom iteration.

under denna process identifierar Team risker och beroenden och utarbetar sina ursprungliga team PI-mål. PI-målen inkluderar vanligtvis ’obekräftade mål’ som är mål inbyggda i planen (t.ex. berättelser som har definierats och inkluderats för dessa mål), men som inte är engagerade i teamet på grund av för många okända eller risker. Otillåtna mål är inte extra saker att göra om det finns tid. Istället ökar de planens tillförlitlighet och ger ledningen en tidig varning om mål som konsten kanske inte kan leverera. Lagen lägger också till funktioner och tillhörande beroenden till programkortet, som visas i Figur 3.

• Draft plan review – under tätt timeboxed utkast till plan översyn, lag presenterar viktiga planeringsutgångar, som omfattar kapacitet och belastning, utkast PI mål, potentiella risker, och beroenden. Företagare, produkthantering och andra team och intressenter granskar och ger input.
• Management review och problemlösning-det är troligt att utkastet till planer presenterar utmaningar som omfattning, människor och resursbegränsningar och beroenden. Under problemlösningshändelsen kan ledningen förhandla om omslagsändringar och lösa andra problem genom att komma överens om olika planeringsjusteringar. RTE underlättar och håller de primära intressenterna tillsammans så länge som nödvändigt för att fatta de beslut som behövs för att nå uppnåbara mål.

i Multi-ART lösning tåg, en liknande händelse kan hållas efter den första dagen av planering för att lösa cross-ART frågor som har kommit upp. Alternativt kan de involverade tågens RTEs prata med varandra för att ta upp problem som sedan löses i varje konsts specifika ledningsgranskning och problemlösningshändelse. Solution Train Engineer (ste) hjälper till att underlätta och lösa problem inom konsten.

dag 2 dagordning

• Planeringsjusteringar – nästa dag börjar evenemanget med att ledningen presenterar eventuella ändringar av planeringsomfång, personer och resurser.
• Team breakouts #2 – lag fortsätter planera baserat på deras agenda från föregående dag och gör lämpliga justeringar. De slutför sina mål för PI, som företagare tilldelar affärsvärde, som visas i Figur 4.
  

  

• Final Plan review och lunch – under denna session presenterar alla lag sina planer för gruppen. I slutet av varje lags tidslucka anger laget sina risker och hinder och ger riskerna för RTE för användning senare i Roamingövningen. Teamet frågar sedan företagare om planen är acceptabel. Om planen accepteras tar laget sitt team PI – objektblad till framsidan av rummet så att alla kan se de sammanlagda målen utvecklas i realtid. Om företagare har problem, Team ges möjlighet att justera planen som behövs för att ta itu med de frågor som identifierats. Teamet presenterar sedan sin reviderade plan.
• programrisker – under planeringen har team identifierat programrisker och hinder som kan påverka deras förmåga att uppfylla sina mål. Dessa löses i ett bredare ledningssammanhang framför hela tåget. En efter en diskuteras riskerna och behandlas med ärlighet och öppenhet och kategoriseras sedan i en av följande kategorier:
  • löst-lagen är överens om att risken inte längre är ett problem.
  • ägs – någon på tåget tar äganderätten till risken eftersom den inte kan lösas under PI-planeringen.
  • accepterad – vissa risker är bara fakta eller potentiella problem som måste förstås och accepteras.
  • mildrade – Team identifierar en plan för att minska risken.
• förtroendeomröstning – när programrisker har tagits upp röstar lagen om sitt förtroende för att uppfylla sina team PI-mål.

varje lag genomför en fist of five-omröstning. Om genomsnittet är tre fingrar eller högre, bör ledningen Acceptera åtagandet. Om det är mindre än tre, laget omarbetar Planen. Varje person som röstar två fingrar eller färre bör ges möjlighet att uttrycka sin oro. Detta kan lägga till i listan över risker, kräva viss omplanering eller helt enkelt vara informativ. När varje lag har röstat upprepas processen för hela konsten med alla som uttrycker sitt förtroende för den kollektiva planen, som illustreras i Figur 5.

• planera omarbetningar-vid behov omarbetar Team sina planer tills en hög konfidensnivå kan nås. Detta är ett tillfälle där anpassning och engagemang värderas högre än att följa en timebox.
• planera retrospektiv och framåt – slutligen leder RTE en kort retrospektiv för Pi-planeringshändelsen för att fånga vad som gick bra, vad som inte gjorde det och vad som kan göras bättre nästa gång, som visas i Figur 6.

• vanligtvis följer en diskussion om nästa steg, tillsammans med slutliga instruktioner till lagen. Detta kan inkludera:
  • städa upp de rum som används för planering.
  • fånga team PI-målen och berättelserna i ett smidigt projekthanteringsverktyg.
  • granska team-och konstevenemang kalendrar.
  • bestämning av Iterationsplanering och dagliga stand-up (DSU) platser och tidpunkter.

efter att planeringsevenemanget är gjort sammanfattar RTE och andra KONSTINTRESSENTER de enskilda team PI-målen i en uppsättning program PI-mål (Figur 7) och använder detta för att kommunicera externt och för att spåra framsteg mot målen.

produkthantering använder programmet PI-mål för att uppdatera färdplanen och kommer att förbättra prognosen för de kommande två Pi: erna, baserat på vad som just lärt sig.

programkortet används ofta under Scrum av Scrums för att spåra beroenden. Det kan, eller kanske inte, underhållas (manuellt) efter att planeringen är klar. Detta beror på det smidiga projekthanteringsverktyget på plats och konstens behov.

lag lämnar PI-planeringshändelsen med en prepopulated iteration backlog för den kommande PI. De tar sitt lags PI-mål, iterationsplaner och risker tillbaka till sitt vanliga arbetsområde. Programrisker förblir hos RTE, som säkerställer att de personer som ansvarar för att äga eller mildra en risk har fångat informationen och aktivt hanterar risken.

viktigast, konsten fortsätter att utföra PI, spåra framsteg och justera vid behov till de förändringar som uppstår när ny kunskap uppstår. Genomförandet av PI börjar med att alla lag som planerar för den första iterationen använder sina PI-planer som utgångspunkt. Detta är ny ingång för iterationsplaneringsprocesser som följer. Eftersom iterationsplanerna som skapades under PI-planeringen inte tog hänsyn till detaljerade acceptanskriterier för historiknivå, är det troligt att justeringar måste göras till de första och efterföljande iterationsplanerna.

lösning tåg PI planering

denna artikel fokuserar på planeringsaktiviteter av en enda ART. Stora Värdeströmmar kan dock innehålla flera konstarter och leverantörer. I det här fallet tillhandahåller Lösningståget samordning med hjälp av en pre-PI-Planeringshändelse, som sätter sammanhanget och ger ingångarna för de enskilda ART PI-planeringshändelserna. Ett post-PI-Planeringsevenemang följer ART PI-planeringen och används för att integrera planeringsresultaten för konsten som bidrar till lösningen.

Innovation och planering Iteration artikeln ger ett exempel kalender för att ta emot Pre – och Post-PI planeringshändelser.

Läs Mer

Leffingwell, Dean. Agila programkrav: Lean Kravpraxis för Team, program och företag. Addison-Wesley, 2011. Kennedy, Michael. Produktutveckling för Lean Enterprise. Oaklea Press, 2003.

senaste ändring: 12 augusti 2020