Che cosa sono i piani di recapito?

  • 6 minuti

Man mano che le organizzazioni di sviluppo crescono, devono riorganizzarsi in team più piccoli in grado di gestire in modo efficiente unità di lavoro suddivise. In genere, questi team dispongono di pianificazioni, bacheche e altri processi di lavoro che soddisfano le loro esigenze specifiche nel contesto dei più ampi obiettivi dell'organizzazione. Nel corso del tempo, le organizzazioni talvolta scoprono che godono dei vantaggi della rete mediante il consolidamento dei processi in base a un framework coerente.

Un piano di recapito consiste nella visualizzazione di una o più pianificazioni di lavoro. e ha lo scopo di fornire ai team e alla gestione una vista complessiva del modo in cui ogni team sta pianificando la produzione e quando. Questa consente di prendere decisioni per ottimizzare gli investimenti nell'intera organizzazione.

È importante che i team rivedano periodicamente i piani di recapito per assicurarsi che la pianificazione del lavoro sia allineata alle pianificazioni di altri team. Queste revisioni dovrebbero affrontare domande quali:

  • Si è sicuri di poter recapitare gli elementi di cui è stato eseguito il commit nella pianificazione corrente?
  • Siamo certi che i team da cui dipendiamo forniranno i contenuti necessari in base alla pianificazione corrente?
  • La pianificazione prevede delle pause da usare per completare il lavoro?
  • Si sono verificati problemi di dipendenze all'interno di un team o tra team?

I piani di recapito aggiungono valore in qualsiasi punto del ciclo di vita di un progetto. Poiché vengono generati dinamicamente in base ai backlog del team, sono sempre aggiornati e offrono le informazioni più recenti.

Unisciti al team web di Tailspin nella loro discussione.

Andy: Ho appena avuto una riunione illuminante con la gestione del reparto tecnico. Ho illustrato il lavoro che stiamo facendo con Azure Boards e il team si è dimostrato entusiasta della possibilità di coinvolgere altri team.

Mara: Fantastico! Quando inizieranno?

Andy: Questa è la parte migliore. Lo hanno già fatto! Ieri sera, il responsabile del progetto del motore di gioco ha creato un team con alcuni sprint e ha iniziato ad aggiungere elementi di lavoro. Stamattina ho dato una rapida occhiata e sembra che proceda bene. Lascia che ti mostri a cosa stanno lavorando.

Andy passa alla bacheca dello sprint corrente del motore di gioco. Lui e Mara esaminano gli elementi di lavoro con grande interesse.

Andy: OK... Mi sono appena accorto che non si intende distribuire la versione beta entro la fine di questo sprint. Ma non dovremmo integrare il tabellone punteggi con il database beta durante il prossimo sprint? Non possiamo farlo se prima il team non ci invia la versione beta.

Mara: Hai ragione. Dipendiamo dal fatto che questo team completi il proprio lavoro per poter completare il nostro.

Andy: Questo avrebbe potuto influire negativamente sulla produttività nello sprint successivo. Li chiamerò per capire che cosa sta accadendo.

Sfortunatamente, strutture di team più sofisticate possono comportare gap o ritardi nelle comunicazioni. Quando un team è bloccato, potrebbe non essere in grado di produrre un elemento da cui dipende un altro team. Questo potrebbe non essere un problema rilevante per un piccolo gruppo di team che svolge riunioni giornaliere per tutti gli interessati. Tuttavia, man mano che i team crescono in termini di dimensioni e posizione, può diventare impossibile sapere sempre quello che accade ovunque. È a questo punto che le organizzazioni devono passare da un modello "push" puro (ad esempio, annunci di persona o mediante posta elettronica) a un modello "pull", in cui i team possono rivedere e tenere traccia delle pianificazioni altrui.

Andy: Ok, ho appena parlato con il responsabile dello sviluppo. Mi ha comunicato che il team è bloccato con la spedizione della versione beta fino a quando il team artistico non torna da Cliffchella.

Mara: Il festival della musica di montagna?

Andy: Sì, apparentemente si tratta di una grande opportunità per la community di progettazione e l'intero team si assenta un'intera settimana per partecipare. Il team del motore di gioco è piuttosto sconvolto perché ha previsto una pianificazione di tre settimane. Se avesse saputo cosa sarebbe successo, si sarebbe assicurato di ottenere gli artefatti necessari in anticipo. Si sono anche scusati per non averci informati prima. Non si sono accorti che saremmo rimasti in attesa della versione beta per presentare la nostra parte.

Mara: Almeno possiamo essere sollevati dal fatto che il team del motore di gioco pubblica i propri piani sprint. Questo ci ha aiutato a individuare il problema di dipendenza in tempo per modificare la pianificazione.

Andy: Vorrei solo che fosse possibile vedere questi potenziali rischi in modo più semplice. I nostri team hanno così tante dipendenze all'interno della società che non è possibile partecipare a ogni riunione e sottoscrivere ogni gruppo di distribuzione.

Mara: È necessario creare un piano di recapito in modo che sia possibile visualizzare gli sprint dei team affiancati. Questo consentirà a entrambi i team di capire più facilmente in che modo le pianificazioni influiscono l'una sull'altra.

Suggerimenti per la gestione di più team Agile

Un approccio Agile, assieme ad Azure DevOps, è in grado di migliorare notevolmente la trasparenza e la prevedibilità di un progetto. Tuttavia, i progetti possono portare alla luce problemi tradizionali, spesso correlati al personale o a una cattiva comunicazione. Di seguito sono riportati alcuni aspetti da considerare quando si ridimensionano i lavori Agile richiesti.

Crea fiducia nelle persone e nei processi

I primi detrattori delle implementazioni Agile sono spesso scettici sulla loro capacità di migliorare le prestazioni del team. È importante per i leader di pensiero all'interno dell'organizzazione creino una relazione di fiducia illustrando il modo in cui gli strumenti e i processi producono risultati. A volte questi risultati comportano dei miglioramenti alla produttività facilmente quantificabili. Tuttavia, non dimenticare di evidenziare i risultati del team che si verificano aggirando i potenziali problemi, ad esempio problemi di pianificazione o qualità evitabili. Quando si inizia ad associare i vantaggi al processo che ha permesso di ottenerli, l'entusiasmo aumenta.

Eleva l'organizzazione al di sopra del team (e del singolo)

Alcuni team e singoli utenti si trovano bloccati in ambito territoriale quando vengono proposti nuovi processi o criteri. Anziché definire nuovi criteri in modo da esporre negativamente le prestazioni di specifici team o singoli utenti, evidenzia in che modo la nuova trasparenza nell'organizzazione sia in grado di informare tutti sulle aspettative. Disporre di un'unica posizione in cui chiunque possa tenere traccia del modo in cui il proprio lavoro si rapporta all'organizzazione e soddisfa gli obiettivi permetterà di evidenziare l'importanza del proprio impegno nel processo.

Promuovi una cultura di trasparenza

Sfortunatamente, il termine "trasparenza" non gode della reputazione che invece meriterebbe. Nessuno chiede una maggiore trasparenza quando tutto va bene. Al contrario, la trasparenza (o la sua mancanza) viene spesso biasimata quando i team sono in difficoltà. Anche con tutte le opportunità di trasparenza garantita di cui godono i team Agile, questo aspetto dipende ancora dall'onestà di singoli utenti e team. Evidenzia che uno dei motivi della trasparenza consiste nella possibilità di identificare e risolvere potenziali problemi prima che sia troppo tardi. Tutti sanno che talvolta le persone si trovano in circostanze che impediscono loro di soddisfare le scadenze previste nella pianificazione. Tuttavia, se non si sentono a proprio agio nel segnalare novità deludenti fino all'ultimo momento, l'effetto può essere molto più distruttivo. La creazione di un livello di comfort tramite la trasparenza può iniziare ringraziando le persone per aver segnalato di ritardi previsti il prima possibile.