Planning PI

toekomstige productontwikkelingstaken kunnen niet vooraf worden bepaald. Verdeel planning en controle aan degenen die de eindresultaten kunnen begrijpen en daarop kunnen reageren.

—Michael Kennedy, Product Development for the Lean Enterprise

er is geen magie in SAFe . . . behalve misschien voor PI Planning.

– auteurs

Program Increment (PI) Planning is een op cadans gebaseerde gebeurtenis die dient als de hartslag van de Agile Release Train (ART), het afstemmen van alle teams op de kunst om een gedeelde missie en visie.

PI-planning is essentieel om veilig te zijn: als u het niet doet, doet u het niet veilig.

het Agile Manifest stelt: “de meest efficiënte en effectieve methode voor het overbrengen van informatie naar en binnen een ontwikkelingsteam is een face-to-face gesprek.”SAFe tilt dit naar een hoger niveau met PI planning.

waar mogelijk gaat het om fysieke collocatie, en deze grootschalige PLANNINGSEVENEMENTEN vinden nu plaats in veel bedrijven over de hele wereld. Ze hebben duidelijk aangetoond echte financiële ROI, niet te vergeten de immateriële zaken die zich voordoen wanneer het team van Agile teams creëert een sociale constructie die persoonlijk en collectief de moeite waard.

het kan echter niet altijd praktisch zijn dat de hele kunst colloceert, en in onze huidige tijden heeft COVID-19 een situatie gecreëerd waarin dit geen optie is. Terwijl fysieke face-to-face planning zijn voordelen heeft, is de ongeschreven veilige ‘regel’ “de mensen die het werk plannen het werk.”Wanneer fysieke aanwezigheid niet mogelijk is, is real time, gelijktijdige, virtuele, face to face planning nu effectief gebleken. Veel Kunsten zijn er inderdaad in geslaagd een hybride situatie te creëren waarin verschillende teams op afstand samenwerken, zoals hieronder in Figuur 1 wordt getoond.

het advanced topic article, Distributed PI Planning with SAFe, biedt aanvullende richtsnoeren en overwegingen voor het succesvol beheren van deze scenario ‘ s.

PI Planning heeft een standaardagenda die een presentatie van de bedrijfscontext en visie omvat, gevolgd door teamplanning breakouts-waarbij de teams hun Iteratieplannen en-doelstellingen maken voor de aankomende programma Increment (PI). Gefaciliteerd door de Release Train Engineer (RTE), dit evenement omvat alle leden van de kunst en vindt plaats binnen de innovatie en Planning (IP) iteratie. Het houden van de gebeurtenis tijdens de IP-iteratie vermijdt het beïnvloeden van de planning, of de capaciteit van andere iteraties in de PI. PI Planning vindt plaats over twee dagen, hoewel dit vaak wordt uitgebreid om planning over meerdere tijdzones.

bedrijfsvoordelen van PI-Planning

PI-planning levert veel bedrijfsvoordelen op, waaronder:

• face-to-face communicatie tot stand brengen tussen alle teamleden en stakeholders
• het sociaal netwerk opbouwen de kunst hangt af van
• het afstemmen van ontwikkeling op bedrijfsdoelstellingen met de bedrijfscontext, visie en Team-en programma-PI-doelstellingen
• afhankelijkheden identificeren en samenwerking tussen teams en stakeholders bevorderen
• het bieden van de mogelijkheid voor ‘precies de juiste hoeveelheid’ architectuur en Lean User Experience (UX) begeleiding
• afstemming van vraag op capaciteit en eliminatie van overtollige work in process (wip)
• snel besluitvorming

Inputs en Outputs van PI-Planning

Inputs voor PI-planning omvatten:

• bedrijfscontext (zie ‘content readiness’ hieronder)
• Roadmap en visie
• top 10 kenmerken van het programma achterstand

een succesvolle PI-planningsevenement levert twee primaire outputs op:

• toegewijde PI doelstellingen-een set van slimme doelstellingen die worden gemaakt door elk team met de bedrijfswaarde toegewezen door de ondernemers.
• Programmabord-het benadrukken van de nieuwe feature leverdata, feature afhankelijkheden tussen teams en relevante mijlpalen.

voorbereiding

PI planning is een belangrijke gebeurtenis die voorbereiding, coördinatie en communicatie vereist. Het wordt gefaciliteerd door de RTE en deelnemers aan het evenement zijn onder andere ondernemers, productmanagement, Agile Teams, systeem-en Solution Architect/Engineering, het Systeemteam en andere belanghebbenden, die allemaal van tevoren moeten worden geïnformeerd om goed voorbereid te zijn. De actieve deelname van ondernemers aan dit evenement vormt een belangrijke vangrail op de begrotingsuitgaven.

om het evenement succesvol te laten zijn, is voorbereiding op drie belangrijke gebieden vereist.:

• organisatorische paraatheid-strategische afstemming en teams en treinen
• inhoudelijke paraatheid-paraatheid voor Management en ontwikkeling
• logistieke paraatheid-overwegingen voor het uitvoeren van een succesvol evenement

hieronder zijn de hoogtepunten van de Checklist Art Readiness. (De volledige checklist is te vinden in de Safe PI Planning Toolkit, beschikbaar voor SPCs).

organisatorische gereedheid

voordat PI planning, er moet strategie afstemming tussen deelnemers, belanghebbenden en ondernemers. Kritische rollen worden toegewezen. Om dit van tevoren aan te pakken, moeten organisatoren van evenementen echter rekening houden met het volgende::

• Planning scope en context-is de scope (product, systeem, technologie domein) van het planningsproces begrepen? Weten we welke teams samen moeten plannen?
• aanpassing van het bedrijfsleven-Is er een redelijke overeenstemming over de prioriteiten tussen de ondernemers?
• Agile teams-hebben we Agile teams? Zijn er toegewijde teamleden en een geïdentificeerde Scrum Master en Product Owner voor elk team?

Content Readiness

het is even belangrijk om ervoor te zorgen dat er een duidelijke visie en context is en dat de juiste belanghebbenden kunnen deelnemen. Daarom moet de planning van PI:

• Executive briefing – Een briefing waarin de huidige business context
• Product visie briefing(s) – Briefings opgesteld door Product Management, met inbegrip van de top 10 functies van het Programma Achterstand
• Architectuur visie briefing – Een presentatie van het CTO, Enterprise Architect, of System Architect te communiceren nieuwe Factoren, kenmerken, en Niet-functionele Eisen (NFRs)

Logistiek Bereidheid

Voorbereiding van een evenement is voor een groot aantal van de deelnemers is niet triviaal. Voor fysiek gecoloceerde planning kan dit het beveiligen en voorbereiden van de fysieke ruimte omvatten. Voor deelnemers op afstand, of voor een volledig gedistribueerde PI Planning, dit omvat ook investeringen in de nodige technische infrastructuur. Overwegingen omvatten:

• locaties-elke planningslocatie moet vooraf worden voorbereid
• technologie en tooling-Real-time toegang tot informatie en tooling ter ondersteuning van gedistribueerde planning of deelnemers op afstand
• communicatiekanalen-primaire en secundaire audio -, video-en presentatiekanalen moeten beschikbaar zijn

standaardagenda

het evenement volgt een agenda die vergelijkbaar is met Figuur 2. Beschrijvingen van elk item volgen. Voor begeleiding bij het aanpassen van deze agenda ter ondersteuning van planning over meerdere tijdzones, verwijzen naar het advanced topic article, Distributed PI Planning with SAFe.

dag 1 Agenda

• bedrijfscontext-een ondernemer of senior executive beschrijft de huidige stand van zaken, deelt de Portefeuillevisie en presenteert een perspectief op hoe effectief bestaande oplossingen inspelen op de huidige behoeften van klanten.
• product/oplossing visie-Product Management presenteert de huidige visie (meestal weergegeven door de volgende top 10 komende functies) en belicht eventuele wijzigingen ten opzichte van de vorige PI planning evenement, evenals eventuele komende mijlpalen.
• Architecture vision and development practices-System Architect / Engineering presenteert de architecture vision. Ook, een senior development manager kan Agile-ondersteunende wijzigingen in de ontwikkeling praktijken, zoals test automation, DevOps, continue integratie, en continue Deployment, die worden gevorderd in de komende PI.
• Planningscontext en lunch – de RTE presenteert het planningsproces en de verwachte resultaten van het evenement.
• team breakouts # 1-in de breakout schatten teams hun capaciteit voor elke iteratie en identificeren ze de achterstand items die ze waarschijnlijk nodig zullen hebben om de functies te realiseren. Elk team maakt hun ontwerp plannen, zichtbaar voor iedereen, iteratie door iteratie.

tijdens dit proces identificeren teams risico ‘ s en afhankelijkheden en stellen ze hun eerste team PI-doelstellingen op. De PI-doelstellingen omvatten doorgaans ‘uncommitted objectives’, Wat doelen zijn die in het plan zijn ingebouwd (bijvoorbeeld verhalen die zijn gedefinieerd en opgenomen voor deze doelstellingen), maar niet door het team worden vastgelegd vanwege te veel onbekenden of risico ‘ s. Niet-vastgelegde doelstellingen zijn geen extra dingen te doen in het geval er tijd is. In plaats daarvan verhogen ze de betrouwbaarheid van het plan en geven ze het management een vroege waarschuwing voor doelen die de kunst mogelijk niet kan leveren. De teams voegen ook de functies en bijbehorende afhankelijkheden toe aan het programmabord, zoals weergegeven in Figuur 3.

• concept plan beoordeling – tijdens de strak timeboxed concept plan beoordeling, teams presenteren belangrijke planning outputs, waaronder capaciteit en belasting, concept PI doelstellingen, potentiële risico ‘ s, en afhankelijkheden. Bedrijfseigenaren, productmanagement en andere teams en stakeholders beoordelen en leveren input.
• management review and problem-solving-het is waarschijnlijk dat de ontwerpplannen uitdagingen zoals omvang, mensen en resource beperkingen, en afhankelijkheden. Tijdens het probleemoplossende evenement, kan het management onderhandelen scope veranderingen en het oplossen van andere problemen door Akkoord te gaan met verschillende planning aanpassingen. De RTE faciliteert en houdt de primaire stakeholders bij elkaar zolang als nodig is om de beslissingen te nemen die nodig zijn om haalbare doelstellingen te bereiken.

In multi-ART Solution treinen kan een soortgelijke gebeurtenis worden gehouden na de eerste dag van de planning om cross-ART problemen op te lossen die zich hebben voorgedaan. Als alternatief kunnen de Rte ‘ s van de betrokken treinen met elkaar praten om problemen aan de orde te stellen die vervolgens worden opgelost in de specifieke management review en probleemoplossende gebeurtenis van elke kunst. De Solution Train Engineer (STE) helpt bij het faciliteren en oplossen van problemen in de Kunsten.

dag 2 Agenda

• aanpassingen van de Planning-de volgende dag begint het evenement met het presenteren van wijzigingen in de omvang van de planning, de mensen en de middelen.
• team breakouts # 2-Teams blijven plannen op basis van hun agenda van de vorige dag, waarbij de nodige aanpassingen worden aangebracht. Zij finaliseren hun doelstellingen voor de PI, waaraan de ondernemers bedrijfswaarde toekennen, zoals weergegeven in Figuur 4.
  

  

• Laatste plan review en lunch-tijdens deze sessie presenteren alle teams hun plannen aan de groep. Aan het einde van het tijdslot van elk team geeft het team hun risico ’s en belemmeringen aan en voorziet het de risico’ s van de RTE voor later gebruik tijdens de Roamingoefening. Het team vraagt vervolgens aan de ondernemers of het plan aanvaardbaar is. Als het plan wordt geaccepteerd brengt het team hun team PI-objectiefblad naar de voorkant van de kamer, zodat iedereen de gezamenlijke doelstellingen in real-time kan zien ontvouwen. Als de ondernemers zorgen hebben, krijgen teams de mogelijkheid om het plan aan te passen als dat nodig is om de geïdentificeerde problemen aan te pakken. Het team presenteert vervolgens hun herziene plan.
• Programmarisico ‘s-tijdens de planning hebben teams programmarisico’ s en belemmeringen geïdentificeerd die van invloed kunnen zijn op hun vermogen om hun doelstellingen te bereiken. Deze worden opgelost in een bredere managementcontext voor de hele trein. Een voor een worden de risico ‘ s met eerlijkheid en transparantie besproken en aangepakt en vervolgens ingedeeld in een van de volgende categorieën:
  • opgelost – de teams zijn het erover eens dat het risico niet langer een probleem is.
  • eigendom-iemand in de trein neemt eigenaar van het risico omdat het niet kan worden opgelost tijdens de planning van PI.
  • geaccepteerd-sommige risico ‘ s zijn slechts feiten of potentiële problemen die moeten worden begrepen en aanvaard.
  • beperkt-Teams bepalen een plan om de impact van het risico te verminderen.
• vertrouwen stemming-zodra programma risico ‘ s zijn aangepakt, teams stemmen op hun vertrouwen in het voldoen aan hun team PI doelstellingen.

elk team heeft een ‘vuist van vijf’ stem. Als het gemiddelde drie vingers of meer is, dan moet het management de verbintenis accepteren. Als het minder dan drie is, herwerkt het team het plan. Iedereen die met twee vingers of minder stemt, moet de gelegenheid krijgen zijn bezorgdheid kenbaar te maken. Dit zou kunnen toevoegen aan de lijst van risico ‘ s, vereisen enige herziening van de planning, of gewoon informatief zijn. Zodra elk team heeft gestemd het proces wordt herhaald voor de hele kunst met iedereen uiten hun vertrouwen in het collectieve plan, zoals geïllustreerd in Figuur 5.

• Plan rework – indien nodig, teams herwerken hun plannen totdat een hoog betrouwbaarheidsniveau kan worden bereikt. Dit is een gelegenheid waar afstemming en betrokkenheid hoger worden gewaardeerd dan het vasthouden aan een timebox.
• planning retrospective and moving forward-ten slotte leidt de RTE een korte retrospective voor de PI planning event om vast te leggen wat goed ging, wat niet, en wat de volgende keer beter kan worden gedaan, zoals weergegeven in Figuur 6.

• meestal volgt er een discussie over de volgende stappen, samen met de laatste instructies aan de teams. Dit kan zijn:
  • het schoonmaken van de ruimten die voor de planning worden gebruikt.
  • het vastleggen van de doelstellingen en verhalen van team PI in een Agile project management tool.
  • kalenders voor team-en kunstgebeurtenissen.
  • bepalen van Iteratieplanning en daily stand-up (DSU) locaties en tijdstippen.

nadat het planningsevenement is gedaan, vatten de RTE en andere stakeholders de individuele team PI-doelstellingen samen in een set van programma PI-doelstellingen (Figuur 7) en gebruiken deze om extern te communiceren en de voortgang naar de doelen te volgen.

Product Management gebruikt de programmadoelstellingen om de routekaart bij te werken en zal de prognose voor de volgende twee Pi ‘ s verbeteren, op basis van wat zojuist is geleerd.

het programmabord wordt vaak gebruikt tijdens de Scrum of Scrums om afhankelijkheden bij te houden. Het kan, of niet, worden onderhouden (handmatig) na de planning is voltooid. Dit hangt af van de Agile Project management tooling in plaats en de behoeften van de kunst.

Teams verlaten de PI planning event met een vooraf bevolkte iteratie achterstand voor de komende PI. Ze nemen de PI-doelstellingen, iteratieplannen en risico ‘ s van hun team terug naar hun reguliere werkgebied. Programmarisico ‘ s blijven bij de RTE, die ervoor zorgt dat de mensen die verantwoordelijk zijn voor het bezitten of beperken van een risico de informatie hebben vastgelegd en actief het risico beheren.

het belangrijkste is dat de ART doorgaat met het uitvoeren van de PI, waarbij de voortgang wordt gevolgd en waar nodig wordt aangepast aan de veranderingen die zich voordoen wanneer nieuwe kennis naar voren komt. De uitvoering van de PI begint met alle teams die de planning voor de eerste iteratie uitvoeren, met hun PI-plannen als uitgangspunt. Dit is verse input voor de iteratie planning processen die volgen. Aangezien de iteratieplannen die tijdens de PI-Planning werden gemaakt geen rekening hielden met gedetailleerde acceptatiecriteria voor het story level, is het waarschijnlijk dat er aanpassingen moeten worden gemaakt aan de eerste en volgende iteratieplannen.

Solution Train PI Planning

dit artikel richt zich op de planningsactiviteiten van een enkel ART. Grote waardestromen kunnen echter meerdere Kunsten en leveranciers bevatten. In dit geval zorgt de Solution Train voor coördinatie met behulp van een pre-PI-Planningsevenement, dat de context bepaalt en de input levert voor de individuele Art PI-planningsevenementen. Een post-PI Planning event volgt ART PI planning en wordt gebruikt om de planningsresultaten van de kunsten die bijdragen aan de oplossing te integreren.

het artikel innovatie en Planning iteratie biedt een voorbeeldkalender voor de opname van pre-en Post-PI planning evenementen.

Meer Informatie

Leffingwell, Dean. Agile softwarevereisten: Lean Requirements Practices voor Teams, programma ‘ s en de onderneming. Addison-Wesley, 2011. Kennedy, Michael. Productontwikkeling voor de Lean Enterprise. Oaklea Press, 2003.

laatste update: 12 augustus 2020