PI planlægning

fremtidige produktudviklingsopgaver kan ikke forudbestemmes. Distribuer planlægning og kontrol til dem, der kan forstå og reagere på slutresultaterne.

—Michael Kennedy, produktudvikling for Lean Enterprise

der er ingen magi i sikker . . . undtagen måske til PI-planlægning.

– forfattere

Introduktion til PI planlægning: Et hurtigt overblik

Program Increment (PI) planlægning er en kadence-baseret begivenhed, der fungerer som hjerteslag i Agile Release Train (ART), der tilpasser alle holdene på kunsten til en fælles mission og Vision.

PI planlægning er afgørende for sikker: hvis du ikke gør det, gør du ikke sikkert.

Find et kursus:

det Agile manifest siger, “den mest effektive og effektive metode til at formidle information til og inden for et udviklingsteam er en ansigt til ansigt samtale.”SAFe tager dette til det næste niveau med PI-planlægning.

hvor det er muligt, involverer dette fysisk samhusning, og disse store PI-planlægningsarrangementer finder nu sted inden for mange virksomheder rundt om i verden. De har tydeligt vist reel økonomisk ROI, for ikke at nævne de immaterielle ting, der opstår, når teamet af Agile teams skaber en social konstruktion, der er personligt og kollektivt givende.

det er måske ikke altid praktisk for hele kunsten at samle sig, og i vores nuværende tid har COVID-19 skabt en situation, hvor dette ikke er en mulighed. Mens fysisk ansigt til ansigt planlægning har sine fordele, er den uskrevne sikre “regel “” de mennesker, der udfører arbejdet, planlægger arbejdet.”Når fysisk tilstedeværelse ikke er mulig, har realtid, samtidig, virtuel, ansigt til ansigt planlægning nu vist sig at være effektiv. Faktisk har mange kunstarter haft succes med at skabe en hybrid situation, hvor flere hold deltager eksternt, som vist nedenfor i Figur 1.

den avancerede emneartikel, distribueret PI-planlægning med SAFe, giver yderligere vejledning og overvejelser til succesfuld styring af disse scenarier.

Figur 1. Ansigt til ansigt PI planlægning. Fjernhold planlægger på samme tid ved hjælp af videokonferencer.

PI planlægning har en standard dagsorden, der omfatter en præsentation af business kontekst og vision, efterfulgt af team Planlægning breakouts—hvor holdene oprette deres Iteration planer og mål for det kommende program Increment (PI). Faciliteret af Release Train Engineer (RTE) inkluderer denne begivenhed alle medlemmer af kunsten og forekommer inden for Innovation and Planning (IP) Iteration. At holde begivenheden under IP-iterationen undgår at påvirke planlægningen eller kapaciteten af andre iterationer i PI. PI-planlægning finder sted over to dage, selvom dette ofte udvides til at rumme planlægning på tværs af flere tidsområder.

forretningsfordele ved PI-planlægning

PI-planlægning leverer mange forretningsfordele, herunder:

  • etablering af ansigt til ansigt kommunikation på tværs af alle teammedlemmer og interessenter
  • opbygning af det sociale netværk kunsten afhænger af
  • tilpasning af udvikling til forretningsmål med forretningskonteksten, visionen og Team-og Program-PI-mål
  • identificering af afhængigheder og fremme samarbejde på tværs af team og cross-ART
  • tilvejebringelse af muligheden for ‘bare det, der sker i vejledning
  • tilpasning af efterspørgsel efter kapacitet og eliminering af overskydende arbejde i processen
  • hurtig beslutningstagning

input og output af PI-planlægning

input til PI-planlægning inkluderer:

  • forretningskontekst (se ‘indholdsberedskab’ nedenfor)
  • køreplan og vision
  • top 10 funktioner i programmet Backlog

en vellykket PI-planlægningsbegivenhed leverer to primære output:

  • forpligtede PI-mål – et sæt smarte mål, der oprettes af hvert team med den forretningsværdi, der er tildelt af virksomhedsejere.
  • program board – fremhæve den nye funktion leveringsdatoer, funktion afhængigheder blandt teams og relevante milepæle.

forberedelse

PI-planlægning er en vigtig begivenhed, der kræver forberedelse, koordinering og kommunikation. Det lettes af RTE, og begivenhedsdeltagere inkluderer virksomhedsejere, produktstyring, Agile Teams, System-og løsningsarkitekt/teknik, Systemteamet og andre interessenter, som alle skal underrettes på forhånd for at være godt forberedt. Den aktive deltagelse af virksomhedsejere i denne begivenhed giver en vigtig beskyttelsesramme for budgetudgifter.

for at begivenheden skal lykkes, kræves forberedelse på tre hovedområder:

  • organisatorisk beredskab-strategisk tilpasning og opsætning af teams og tog
  • indholdsberedskab – ledelses – og udviklingsberedskab
  • Logistikberedskab-overvejelser for at køre en vellykket begivenhed

nedenfor er højdepunkter i Art Readiness checkliste. (Den fulde tjekliste findes i SAFe PI Planning Toolkit, der er tilgængelig for SPC ‘ er).

organisatorisk beredskab

før PI-planlægning skal der være strategitilpasning blandt deltagere, interessenter og virksomhedsejere. Kritiske roller tildeles. For at løse dette på forhånd, imidlertid, arrangører skal overveje følgende:

  • planlægning omfang og kontekst-er omfanget (produkt, system, teknologi domæne) af planlægningsprocessen forstået? Ved vi, hvilke hold der skal planlægge sammen?
  • business alignment – er der rimelig enighed om prioriteter blandt virksomhedsejere?
  • Agile teams – har vi Agile teams? Er der dedikerede teammedlemmer og en identificeret Scrum Master og produktejer for hvert team?

Indholdsberedskab

det er lige så vigtigt at sikre, at der er en klar vision og kontekst, og at de rigtige interessenter kan deltage. Derfor skal PI-planlægningen omfatte:

  • udøvende briefing-en briefing, der definerer den aktuelle forretningskontekst
  • produktvisionsbriefing(er) – briefinger udarbejdet af produktstyring, herunder de 10 bedste funktioner i Programbeholdningen
  • arkitektur vision briefing – en præsentation foretaget af CTO, Enterprise Architect eller System Architect for at kommunikere nye Aktiverere, funktioner og ikke-funktionelle krav (NFRs)

Logistikberedskab

forberedelse af en begivenhed til støtte for et stort antal deltagere er ikke trivielt. Til fysisk samlokaliseret planlægning kan dette omfatte sikring og forberedelse af det fysiske rum. For fjerndeltagere eller for en fuldt distribueret PI-planlægning inkluderer dette også investering i den nødvendige tekniske infrastruktur. Overvejelser inkluderer:

  • lokationer – hver planlægningssted skal være forberedt på forhånd
  • teknologi og værktøj – realtidsadgang til information og værktøj til understøttelse af distribueret planlægning eller eksterne deltagere
  • kommunikationskanaler-primære og sekundære lyd–, video-og præsentationskanaler skal være tilgængelige

Standard dagsorden

begivenheden følger En dagsorden, der ligner en figur 2. Beskrivelser af hvert element følger. For vejledning om tilpasning af denne dagsorden for at understøtte planlægning på tværs af flere tidsområder, se artiklen avanceret emne, distribueret PI planlægning med SAFe.

figur 2. Standard to-dages pi planning agenda

dag 1 Agenda

  • forretningskontekst – en virksomhedsejer eller seniorchef beskriver virksomhedens aktuelle tilstand, deler Porteføljevisionen og præsenterer et perspektiv på, hvor effektivt eksisterende løsninger imødekommer aktuelle kundebehov.
  • Product/solution vision – Product Management præsenterer den aktuelle vision (typisk repræsenteret ved de næste top 10 kommende funktioner) og fremhæver eventuelle ændringer fra den tidligere PI planlægning begivenhed, samt eventuelle kommende milepæle.
  • arkitektur vision og udviklingspraksis – systemarkitekt/teknik præsenterer arkitekturvisionen. En senior development manager kan også introducere Agile-støttende ændringer i udviklingspraksis, såsom testautomatisering, DevOps, Kontinuerlig Integration og kontinuerlig implementering, som bliver avanceret i den kommende PI.
  • Planlægningskontekst og frokost – RTE præsenterer planlægningsprocessen og forventede resultater af arrangementet.
  • Team breakouts #1 – i breakout estimerer holdene deres kapacitet for hver Iteration og identificerer de backlog-elementer, de sandsynligvis har brug for for at realisere funktionerne. Hvert hold opretter deres udkast til planer, synlige for alle, iteration ved iteration.

under denne proces identificerer teams risici og afhængigheder og udarbejder deres oprindelige team PI-mål. PI-målene inkluderer typisk ‘uforpligtede mål’, som er mål indbygget i planen (f.eks. historier, der er defineret og inkluderet for disse mål), men som ikke er forpligtet af holdet på grund af for mange ukendte eller risici. Uforpligtede mål er ikke ekstra ting at gøre, hvis der er tid. I stedet øger de planens pålidelighed og giver ledelsen en tidlig advarsel om mål, som kunsten muligvis ikke kan levere. Holdene tilføjer også funktionerne og tilhørende afhængigheder til programkortet, som vist i figur 3.

figur 3. Program board viser funktioner og afhængigheder
  • udkast til plananmeldelse – i løbet af den tæt tidsboksede udkast til plananmeldelse præsenterer teams vigtige planlægningsoutput, som inkluderer kapacitet og belastning, udkast til PI-mål, potentielle risici og afhængigheder. Virksomhedsejere, produktstyring og andre teams og interessenter gennemgår og leverer input.
  • Ledelsesgennemgang og problemløsning-det er sandsynligt, at udkastet til planer præsenterer udfordringer som omfang, mennesker og ressourcebegrænsninger og afhængigheder. Under problemløsningsbegivenheden kan ledelsen forhandle om omfangsændringer og løse andre problemer ved at acceptere forskellige planlægningsjusteringer. RTE letter og holder de primære interessenter sammen, så længe det er nødvendigt for at træffe de beslutninger, der er nødvendige for at nå opnåelige mål.

i multi-ART Solution Trains kan en lignende begivenhed afholdes efter den første dag i planlægningen for at løse cross-ART problemer, der er kommet op. Alternativt kan rte ‘ erne for de involverede tog tale med hinanden for at rejse problemer, der derefter løses i hver kunsts specifikke ledelsesanmeldelse og problemløsningsbegivenhed. Solution Train Engineer (STE) hjælper med at lette og løse problemer på tværs af kunsten.

Dag 2 dagsorden

  • planlægningsjusteringer – den næste dag begynder begivenheden med, at ledelsen præsenterer ændringer i planlægningsomfang, mennesker og ressourcer.
  • Team breakouts #2 – hold fortsætter planlægningen baseret på deres dagsorden fra den foregående dag og foretager de passende justeringer. De afslutter deres mål for PI, som virksomhedsejere tildeler forretningsværdi, som vist i figur 4.
    figur 4. Et teams pi-målark med tildelt forretningsværdi
  • endelig plananmeldelse og frokost – under denne session præsenterer alle hold deres planer for gruppen. I slutningen af hvert holds tidsinterval angiver holdet deres risici og hindringer og giver risiciene for RTE til brug senere i Roamingøvelsen. Holdet spørger derefter virksomhedsejere, om planen er acceptabel. Hvis planen accepteres, bringer holdet deres team PI-målark foran i rummet, så alle kan se de samlede mål udfolde sig i realtid. Hvis virksomhedsejere har bekymringer, får teams mulighed for at justere planen efter behov for at løse de identificerede problemer. Holdet præsenterer derefter deres reviderede plan.
  • Programrisici – under planlægningen har teams identificeret programrisici og hindringer, der kan påvirke deres evne til at nå deres mål. Disse løses i en bredere ledelseskontekst foran hele toget. En efter en diskuteres og behandles risiciene med ærlighed og gennemsigtighed og kategoriseres derefter i en af følgende kategorier:
    • løst – holdene er enige om, at risikoen ikke længere er et problem.
    • ejet – nogen på toget tager ejerskab af risikoen, da den ikke kan løses under PI-planlægning.
    • accepteret – nogle risici er bare fakta eller potentielle problemer, der skal forstås og accepteres.
    • Mitigated – Teams identificerer en plan for at reducere virkningen af risikoen.
  • tillidsafstemning-når programrisici er blevet behandlet, stemmer holdene om deres tillid til at opfylde deres team PI-mål.

hvert hold gennemfører en ‘fist of five’ stemme. Hvis gennemsnittet er tre fingre eller derover, skal ledelsen acceptere forpligtelsen. Hvis det er mindre end tre, holdet omarbejder planen. Enhver, der stemmer to fingre eller færre, bør have mulighed for at give udtryk for deres bekymringer. Dette kan føje til listen over risici, kræve en vis omplanlægning eller blot være informativ. Når hvert hold har stemt, gentages processen for hele kunsten, hvor alle udtrykker deres tillid til den kollektive plan, som illustreret i figur 5.

figur 5. Tillid stemme for en kunst
  • Planlæg omarbejde-om nødvendigt omarbejder holdene deres planer, indtil et højt konfidensniveau kan nås. Dette er en lejlighed, hvor tilpasning og engagement værdsættes højere end at overholde en tidsboks.
  • planlægning retrospektiv og bevæger sig fremad – endelig fører RTE en kort retrospektiv for PI-planlægningsbegivenheden for at fange, hvad der gik godt, hvad der ikke gjorde, og hvad der kan gøres bedre næste gang, som vist i figur 6.
figur 6. Pi planlægning retrospektiv
  • typisk følger en diskussion om de næste trin sammen med de endelige instruktioner til holdene. Dette kan omfatte:
    • oprydning af de rum, der bruges til planlægning.
    • indfange team PI mål og historier i et agilt projektstyringsværktøj.
    • gennemgang team og kunst begivenheder kalendere.
    • bestemmelse af Iterationsplanlægning og daglige stand-up (DSU) placeringer og tidspunkter.

når planlægningsbegivenheden er afsluttet, opsummerer RTE og andre Art-interessenter de enkelte team PI-mål i et sæt program PI-mål (Figur 7) og bruger dette til at kommunikere eksternt og til at spore fremskridt mod målene.

produktstyring bruger programmet PI-mål til at opdatere køreplanen og vil forbedre prognosen for de næste to Pi ‘ er baseret på det, der lige blev lært.

programkortet bruges ofte under Scrum of Scrums til at spore afhængigheder. Det kan, eller måske ikke, opretholdes (manuelt), når planlægningen er afsluttet. Dette afhænger af det Agile projektstyringsværktøj på plads og kunstens behov.

hold forlader PI-planlægningsbegivenheden med en forudbefolket iterationsefterslæb for den kommende PI. De tager deres teams PI-mål, iterationsplaner og risici tilbage til deres almindelige arbejdsområde. Programrisici forbliver hos RTE, der sikrer, at de personer, der er ansvarlige for at eje eller afbøde en risiko, har fanget oplysningerne og aktivt styrer risikoen.

vigtigst, kunsten fortsætter med at udføre PI, spore fremskridt og justere efter behov til de ændringer, der opstår, når ny viden opstår. Udførelsen af PI begynder med, at alle holdene planlægger den første iteration ved hjælp af deres PI-planer som udgangspunkt. Dette er nyt input til de iterationsplanlægningsprocesser, der følger. Da iterationsplanerne oprettet under PI-planlægning ikke tog højde for detaljerede acceptkriterier for historieniveau, er det sandsynligt, at der skal foretages justeringer af de første og efterfølgende iterationsplaner.

Figur 7. Program PI mål

Solution Train PI planlægning

denne artikel fokuserer på planlægning aktiviteter af en enkelt kunst. Store værdistrømme kan dog indeholde flere Kunstarter og leverandører. I dette tilfælde giver Løsningstoget koordinering ved hjælp af en pre-PI Planlægningsbegivenhed, der sætter konteksten og giver input til de enkelte ART PI planlægningsbegivenheder. En post-PI Planlægningsbegivenhed følger ART PI planlægning og bruges til at integrere planlægningsresultaterne for den kunst, der bidrager til løsningen.

figur 8. Pre og Post-PI planlægning

Innovation og planlægning Iteration artiklen giver et eksempel kalender for at imødekomme Pre – og post-PI planlægning begivenheder.

Lær Mere

Leffing, Dean. Agile krav til programmer: Lean krav praksis for Teams, programmer og virksomheden. Addison, 2011. Kennedy, Michael. Produktudvikling til Lean Enterprise. Oaklea Press, 2003.

sidste opdatering: 12 August 2020

oplysningerne på denne side er kr. 2010-2021 Scaled Agile, Inc. og er beskyttet af amerikanske og internationale love om ophavsret. Hverken billeder eller tekst kan kopieres fra denne hjemmeside uden udtrykkelig skriftlig tilladelse fra indehaveren af ophavsretten. Scaled Agile rammer og SAFe er registrerede varemærker tilhørende Scaled Agile, Inc. Besøg ofte stillede spørgsmål om tilladelser og kontakt os for tilladelser.

Forfattere

  • Dean Leffing –

Skriv et svar

Din e-mailadresse vil ikke blive publiceret.