Pianificazione PI

Le attività future di sviluppo del prodotto non possono essere predeterminate. Distribuire la pianificazione e il controllo a coloro che possono capire e reagire ai risultati finali.

—Michael Kennedy, Product Development for the Lean Enterprise

Non c’è magia in SAFe . . . tranne forse per la pianificazione PI.

—Autori

La pianificazione dell’incremento del programma (PI) è un evento basato sulla cadenza che funge da battito cardiaco dell’Agile Release Train (ART), allineando tutti i team sull’ARTE a una missione e una visione condivise.

La pianificazione PI è essenziale per la sicurezza: se non lo stai facendo, non lo stai facendo al sicuro.

Il Manifesto Agile afferma: “Il metodo più efficiente ed efficace per trasmettere informazioni a e all’interno di un team di sviluppo è una conversazione faccia a faccia.”SAFe porta questo al livello successivo con la pianificazione PI.

Ove possibile ciò comporta la collocazione fisica, e questi eventi di pianificazione PI su larga scala si svolgono ora all’interno di molte imprese in tutto il mondo. Hanno chiaramente mostrato un reale ROI finanziario, per non parlare degli intangibili che si verificano quando il team di team agili crea un costrutto sociale che è personalmente e collettivamente gratificante.

Potrebbe non essere sempre pratico per l’intera ARTE collocare tuttavia, e nei nostri tempi attuali COVID-19 ha creato una situazione in cui questa non è un’opzione. Mentre la pianificazione fisica faccia a faccia ha i suoi vantaggi, la “regola” sicura non scritta è ” le persone che fanno il lavoro pianificano il lavoro.”Quando la presenza fisica non è possibile, la pianificazione in tempo reale, simultanea, virtuale, faccia a faccia ha ora dimostrato di essere efficace. Infatti molte arti hanno avuto successo nella creazione di una situazione ibrida in cui diverse squadre si uniscono in remoto, come mostrato di seguito in Figura 1.

L’articolo sull’argomento avanzato, Distributed PI Planning with SAFe, fornisce ulteriori indicazioni e considerazioni per gestire correttamente questi scenari.

PI Planning ha un’agenda standard che include una presentazione del contesto aziendale e della visione, seguita da sblocchi della pianificazione del team, in cui i team creano i loro piani di iterazione e obiettivi per l’imminente incremento del programma (PI). Facilitato dal Release Train Engineer (RTE), questo evento include tutti i membri dell’ARTE e si verifica all’interno dell’iterazione Innovazione e pianificazione (IP). Mantenere l’evento durante l’iterazione IP evita di influire sulla pianificazione o sulla capacità di altre iterazioni nel PI. La pianificazione PI si svolge nell’arco di due giorni, anche se questo è spesso esteso per adattarsi alla pianificazione su più fusi orari.

Vantaggi aziendali di PI Planning

PI planning offre molti vantaggi aziendali, tra cui:

• Stabilire faccia a faccia la comunicazione tra tutti i membri del team e le parti interessate
• Costruzione di una rete sociale in ARTE dipende
• Allineamento di sviluppo per gli obiettivi di business con il contesto aziendale, visione, e la Squadra e il Programma PI obiettivi
• Identificare le dipendenze e la promozione di cross-team e cross-ART collaborazione
• Fornire l’occasione per ‘la giusta quantita’ di architettura e Magra Esperienza Utente (UX) guida
• Corrispondente alla domanda di capacità ed eliminando l’eccesso di Work in Process (WIP)
• Veloce decisionali

Ingressi e Uscite di PI di Pianificazione

Ingressi a PI piani sono:

• contesto del Business (vedi “preparazione dei contenuti’ sotto)
• tabella di marcia e la visione
• 10 Funzioni principali del Programma Backlog

Un successo PI di pianificazione evento offre due uscite primarie:

• Impegnati di PI gli obiettivi – Una serie di obiettivi SMART che vengono creati per ogni squadra con il valore assegnato dai Proprietari di Affari.
• Scheda del programma-Evidenziando le nuove date di consegna delle funzionalità, le dipendenze delle funzionalità tra i team e le pietre miliari rilevanti.

Preparazione

La pianificazione PI è un evento significativo che richiede preparazione, coordinamento e comunicazione. È facilitato dalla RTE e i partecipanti all’evento includono proprietari di aziende, gestione del prodotto, team agili, architetto/ingegnere di sistemi e soluzioni, team di sistema e altre parti interessate, che devono essere avvisate in anticipo per essere ben preparate. La partecipazione attiva degli imprenditori in questo evento fornisce un importante Guardrail sulla spesa di bilancio.

Per l’evento di successo, è necessaria una preparazione in tre aree principali:

• preparazione Organizzativa – allineamento Strategico e di squadre e treni di installazione
• preparazione dei Contenuti – Gestione e sviluppo di preparazione
• Logistica disponibilità – Considerazioni per l’esecuzione di un evento di successo

di Seguito si mettono in evidenza l’ARTE Prontezza lista di controllo. (La lista di controllo completa è fornita nel Toolkit di pianificazione PI sicuro, disponibile per gli SPCS).

Prontezza organizzativa

Prima di pianificare PI, deve esserci un allineamento strategico tra partecipanti, stakeholder e proprietari di aziende. Vengono assegnati ruoli critici. Per affrontare questo in anticipo, tuttavia, gli organizzatori di eventi devono considerare quanto segue:

• Ambito e contesto di pianificazione-È compreso l’ambito (prodotto, sistema, dominio tecnologico) del processo di pianificazione? Sappiamo quali squadre devono pianificare insieme?
• Allineamento aziendale – Esiste un ragionevole accordo sulle priorità tra gli imprenditori?
• Team Agili-Abbiamo team Agili? Ci sono membri del team dedicati e uno Scrum Master e Product Owner identificati per ogni team?

Content Readiness

È altrettanto importante garantire una visione e un contesto chiari e che i giusti stakeholder possano partecipare. Pertanto, la pianificazione PI deve includere:

• Executive briefing – Un briefing che definisce l’attuale contesto di business
• Prodotto visione briefing(s) – Briefing preparato da Gestione del Prodotto, tra cui la top 10 funzioni nel Programma Backlog
• visione dell’Architettura briefing – Una presentazione fatta dal CTO, Enterprise Architect, Architetto di Sistema o per comunicare nuovi Facilitatori, caratteristiche e Requisiti non Funzionali (NFRs)

Logistica Prontezza

Preparazione di un evento a sostegno di un gran numero di partecipanti non è banale. Per la pianificazione fisicamente collocato questo può includere la protezione e la preparazione dello spazio fisico. Per i partecipanti remoti, o per una pianificazione PI completamente distribuita, questo include anche gli investimenti nell’infrastruttura tecnica necessaria. Le considerazioni includono:

• Località – pianificazione deve essere preparato in anticipo
• Tecnologia e utensileria – accesso in tempo Reale alle informazioni e strumenti per supportare la progettazione distribuita o remoto partecipanti
• canali di Comunicazione – Primaria e secondaria di audio, video e presentazione canali deve essere disponibile

Standard Agenda

L’evento segue un ordine del giorno simile a quella in Figura 2. Le descrizioni di ogni elemento seguono. Per indicazioni su come adattare questa agenda per supportare la pianificazione su più fusi orari, fare riferimento all’articolo sull’argomento avanzato, Pianificazione PI distribuita con SAFe.

Agenda 1 giorno

• Contesto aziendale – Un imprenditore o un dirigente senior descrive lo stato attuale del business, condivide la visione del portafoglio e presenta una prospettiva su quanto efficacemente le soluzioni esistenti stiano affrontando le attuali esigenze dei clienti.
• Product/solution vision-Product Management presenta la visione corrente (tipicamente rappresentata dalle prossime 10 funzionalità in arrivo) e evidenzia eventuali modifiche rispetto al precedente evento di pianificazione PI, nonché eventuali traguardi futuri.
• Visione dell’architettura e pratiche di sviluppo-System Architect / Engineering presenta la visione dell’architettura. Inoltre, un senior Development manager può introdurre modifiche agili alle pratiche di sviluppo, come l’automazione dei test, DevOps, Integrazione continua e distribuzione continua, che vengono avanzate nel prossimo PI.
• Planning context and lunch-La RTE presenta il processo di pianificazione e i risultati attesi dell’evento.
• Team breakouts #1 – Nel breakout, i team stimano la loro capacità per ogni iterazione e identificano gli elementi di backlog di cui avranno probabilmente bisogno per realizzare le funzionalità. Ogni team crea i propri progetti di piani, visibili a tutti, iterazione per iterazione.

Durante questo processo, i team identificano rischi e dipendenze e redigono i loro obiettivi iniziali di team PI. Gli obiettivi PI in genere includono “obiettivi non impegnati”, che sono obiettivi integrati nel piano (ad esempio, storie che sono state definite e incluse per questi obiettivi), ma non sono impegnati dal team a causa di troppe incognite o rischi. Gli obiettivi non impegnati non sono cose extra da fare nel caso in cui ci sia tempo. Invece, aumentano l’affidabilità del piano e danno alla gestione un allarme precoce degli obiettivi che l’ARTE potrebbe non essere in grado di fornire. I team aggiungono anche le funzionalità e le dipendenze associate alla scheda del programma, come mostrato in Figura 3.

• Revisione del progetto di piano-Durante la revisione del progetto di piano strettamente timeboxed, i team presentano i principali output di pianificazione, che includono capacità e carico, obiettivi di progetto PI, rischi potenziali e dipendenze. I proprietari di aziende, la gestione del prodotto e altri team e stakeholder esaminano e forniscono input.
• Revisione della gestione e risoluzione dei problemi: è probabile che i progetti di piani presentino sfide come ambito, vincoli di persone e risorse e dipendenze. Durante l’evento di risoluzione dei problemi, la gestione può negoziare modifiche dell’ambito e risolvere altri problemi accettando vari aggiustamenti di pianificazione. L’RTE facilita e mantiene insieme i principali stakeholder per tutto il tempo necessario a prendere le decisioni necessarie per raggiungere gli obiettivi raggiungibili.

In multi-ART Solution Trains, un evento simile può essere tenuto dopo il primo giorno di pianificazione per risolvere i problemi di cross-ART che sono emersi. In alternativa, gli RTES dei treni coinvolti possono parlare tra loro per sollevare questioni che vengono poi risolte nella revisione della gestione specifica di ogni ART e nell’evento di risoluzione dei problemi. La soluzione Train Engineer (STE) aiuta a facilitare e risolvere i problemi attraverso le arti.

Giorno 2 Agenda

• Aggiustamenti di pianificazione – Il giorno successivo, l’evento inizia con la gestione che presenta eventuali modifiche all’ambito di pianificazione, alle persone e alle risorse.
• Team breakouts #2-Le squadre continuano a pianificare in base alla loro agenda del giorno precedente, apportando le opportune modifiche. Essi finalizzano i loro obiettivi per il PI, a cui gli imprenditori assegnano valore di business, come mostrato in Figura 4.
  

  

• Revisione del piano finale e pranzo – Durante questa sessione, tutte le squadre presentano i loro piani al gruppo. Alla fine della fascia oraria di ciascuna squadra, la squadra dichiara i propri rischi e impedimenti e fornisce i rischi per l’RTE per l’uso successivo nell’esercizio di ROAMing. Il team chiede quindi agli imprenditori se il piano è accettabile. Se il piano viene accettato, il team porta il proprio foglio obiettivo team PI nella parte anteriore della stanza in modo che tutti possano vedere gli obiettivi aggregati svolgersi in tempo reale. Se i proprietari di imprese hanno preoccupazioni, i team hanno la possibilità di regolare il piano secondo necessità per affrontare i problemi identificati. Il team presenta quindi il piano rivisto.
• Rischi del programma-Durante la pianificazione, i team hanno identificato rischi e impedimenti del programma che potrebbero influire sulla loro capacità di raggiungere i loro obiettivi. Questi sono risolti in un contesto di gestione più ampio di fronte all’intero treno. Uno per uno, i rischi vengono discussi e affrontati con onestà e trasparenza, e quindi classificati in una delle seguenti categorie:
  • Risolto-Le squadre concordano sul fatto che il rischio non è più una preoccupazione.
  • Proprietà-Qualcuno sul treno assume la proprietà del rischio poiché non può essere risolto durante la pianificazione del PI.
  • Accettato-Alcuni rischi sono solo fatti o potenziali problemi che devono essere compresi e accettati.
  • Mitigato – I team identificano un piano per ridurre l’impatto del rischio.
• Voto di fiducia – Una volta che i rischi del programma sono stati affrontati, i team votano sulla loro fiducia nel raggiungimento dei loro obiettivi di team PI.

Ogni squadra conduce un’ pugno di cinque ‘ voto. Se la media è di tre dita o superiore, la direzione dovrebbe accettare l’impegno. Se sono meno di tre, la squadra rielabora il piano. Qualsiasi persona che vota due dita o meno dovrebbe avere l’opportunità di esprimere le proprie preoccupazioni. Questo potrebbe aggiungere alla lista dei rischi, richiedere qualche ri-pianificazione, o semplicemente essere informativo. Una volta che ogni squadra ha votato il processo viene ripetuto per l’intera ARTE con tutti che esprimono la loro fiducia nel piano collettivo, come illustrato nella Figura 5.

• Rielaborazione del piano-Se necessario, i team rielaborano i loro piani fino a raggiungere un elevato livello di confidenza. Questa è un’occasione in cui l’allineamento e l’impegno sono valutati più altamente che aderire a un timebox.
• Planning retrospective and moving forward-Infine, la RTE conduce una breve retrospettiva per l’evento PI planning per catturare ciò che è andato bene, cosa no e cosa può essere fatto meglio la prossima volta, come mostrato in Figura 6.

• Di solito segue una discussione sui prossimi passi, insieme alle istruzioni finali ai team. Ciò potrebbe includere:
  • Pulizia delle stanze utilizzate per la pianificazione.
  • Catturare gli obiettivi e le storie del team PI in uno strumento di gestione del progetto agile.
  • Rivedere team ed eventi ARTISTICI calendari.
  • Determinazione della pianificazione dell’iterazione e delle posizioni e dei tempi di stand-up giornalieri (DSU).

Al termine dell’evento di pianificazione, l’RTE e altri stakeholder dell’ARTE riassumono i singoli obiettivi PI del team in una serie di obiettivi PI del programma (Figura 7) e lo utilizzano per comunicare esternamente e per monitorare i progressi verso gli obiettivi.

Product Management utilizza gli obiettivi del programma PI per aggiornare la roadmap e migliorerà le previsioni per i prossimi due PI, in base a quanto appena appreso.

La scheda di programma viene spesso utilizzata durante la mischia di mischia per tenere traccia delle dipendenze. Può, o non può, essere mantenuto (manualmente) dopo la pianificazione è completa. Ciò dipende dagli strumenti di gestione del progetto agile in atto e dalle esigenze dell’ARTE.

I team lasciano l’evento di pianificazione PI con un backlog di iterazione precompilato per il prossimo PI. Prendono gli obiettivi PI del loro team, i piani di iterazione e i rischi nella loro normale area di lavoro. I rischi del programma rimangono con l’RTE, che assicura che le persone responsabili del possesso o della mitigazione di un rischio abbiano acquisito le informazioni e gestiscano attivamente il rischio.

Più importante, l’ARTE procede ad eseguire il PI, seguendo i progressi e adattandosi, se necessario, ai cambiamenti che si verificano man mano che emergono nuove conoscenze. L’esecuzione del PI inizia con tutti i team che conducono la pianificazione per la prima iterazione, utilizzando i loro piani PI come punto di partenza. Questo è un nuovo input per i processi di pianificazione dell’iterazione che seguono. Poiché i piani di iterazione creati durante la pianificazione PI non tenevano conto dei criteri di accettazione dettagliati a livello di storia, è probabile che siano necessarie modifiche al primo e al successivo piano di iterazione.

Soluzione Treno PI Pianificazione

Questo articolo si concentra sulle attività di pianificazione di un singolo ART. Tuttavia, grandi flussi di valore possono contenere più ARTI e fornitori. In questo caso, il Solution Train fornisce il coordinamento utilizzando un evento di pianificazione Pre-PI, che imposta il contesto e fornisce gli input per i singoli eventi di pianificazione ART PI. Un evento Post-PI Planning segue ART PI planning e viene utilizzato per integrare i risultati di pianificazione delle arti che contribuiscono alla soluzione.

L’articolo Innovazione e pianificazione iterazione fornisce un calendario di esempio per ospitare eventi di pianificazione pre e post – PI.

Per saperne di più

Leffingwell, Dean. Requisiti software agili: pratiche di requisiti snelli per team, programmi e aziende. Addison-Wesley, 2011. Kennedy, Michael. Sviluppo del prodotto per l’impresa Lean. Oaklea Press, 2003.

Ultimo aggiornamento: 12 agosto 2020