Pianificazione di Microsoft con DevOps

Microsoft è una delle aziende più grandi del mondo per l'uso di metodologie Agile. Nel corso degli anni di esperienza, Microsoft ha sviluppato un processo di pianificazione DevOps che si adatta dai progetti più piccoli fino a grandi sforzi come Windows. Questo articolo descrive molte delle lezioni apprese e le procedure implementate da Microsoft durante la pianificazione di progetti software in tutta l'azienda.

Modifiche strumentali

Le modifiche chiave seguenti consentono di migliorare l'integrità dei cicli di sviluppo e spedizione:

• Promuovere l'allineamento culturale e l'autonomia.
• Cambiare l'attenzione da singoli utenti a team.
• Creare nuove strategie di pianificazione e apprendimento.
• Implementare un modello multi-equipaggio.
• Migliorare le procedure di integrità del codice.
• Favorire la trasparenza e la responsabilità.

Promuovere l'allineamento culturale e l'autonomia

Peter Drucker disse: "La cultura mangia la strategia per la colazione". Autonomia, maestria e scopo sono motivazioni umane chiave. Microsoft tenta di fornire queste motivazioni a MACCHINE virtuali, sviluppatori e progettisti in modo da poter creare prodotti di successo.

Due importanti collaboratori a questo approccio sono l'allineamento e l'autonomia.

• L'allineamento proviene dall'alto verso il basso, per garantire che gli utenti e i team comprendano il modo in cui le responsabilità sono allineate agli obiettivi aziendali più ampi.
• L'autonomia avviene dal basso verso l'alto, per garantire che le persone e i team abbiano un impatto sulle attività e sulle decisioni quotidiane.

C'è un delicato equilibrio tra allineamento e autonomia. Un allineamento eccessivo può creare una cultura negativa in cui le persone eseguono solo come si dice. Un'autonomia eccessiva può causare una mancanza di struttura o direzione, un processo decisionale inefficiente e una scarsa pianificazione.

Cambiare l'attenzione da singoli utenti a team

Microsoft organizza persone e team in tre gruppi: PM, progettazione e progettazione.

• PM definisce le build di Microsoft e perché.
• La progettazione è responsabile della progettazione delle build di Microsoft.
• La progettazione costruisce i prodotti e ne garantisce la qualità.

I team Microsoft hanno le caratteristiche chiave seguenti:

• Disciplinari incrociati
• 10-12 persone
• Auto-gestione
• Carta e obiettivi chiari per 12-18 mesi
• Sale del team fisico
• Distribuzione di funzionalità personalizzate
• Funzionalità personalizzate nell'ambiente di produzione

Cercare team verticali

I team Microsoft sono stati usati per essere orizzontali, che coprono tutte le interfacce utente, tutti i dati o tutte le API. Ora Microsoft si impegna per i team verticali. Teams possiede le proprie aree del prodotto end-to-end. Linee guida rigorose in determinati livelli garantiscono l'uniformità tra i team nel prodotto.

Il diagramma seguente concettualizza la differenza tra team orizzontali e verticali:

Consenti team di selezione automatica

Circa ogni 18 mesi, Microsoft esegue un "esercizio giallo sticky", in cui gli sviluppatori possono scegliere quali aree del prodotto vogliono lavorare per i prossimi due periodi di pianificazione. Questo esercizio offre autonomia, in quanto i team possono scegliere cosa lavorare e l'allineamento dell'organizzazione, man mano che promuove l'equilibrio tra i team. Circa l'80% delle persone in questo esercizio rimangono sui loro team attuali, ma si sentono responsabili perché hanno avuto una scelta.

Creare nuove strategie di pianificazione e apprendimento

Dwight Eisenhower disse: "I piani sono senza valore, ma la pianificazione è tutto". La pianificazione Di Microsoft si suddivide nella struttura seguente:

• Sprint (3 settimane)
• Piani (3 sprint)
• Stagioni (6 mesi)
• Strategie (12 mesi)

I tecnici e i team sono principalmente responsabili di sprint e piani. La leadership è principalmente responsabile delle stagioni e delle strategie.

Il diagramma seguente illustra la strategia di pianificazione Microsoft:

Questa struttura di pianificazione consente anche di ottimizzare l'apprendimento durante la pianificazione. Teams è in grado di ottenere feedback, scoprire cosa vogliono i clienti e implementare le richieste dei clienti in modo rapido ed efficiente.

Implementare un modello multi-equipaggio

I metodi precedenti hanno favorito una "cultura di interruzione" di bug e eventi imprevisti del sito live. I team Microsoft hanno fornito il proprio modo di concentrarsi ed evitare distrazioni. Teams si auto-organizza per ogni sprint in due team distinti: Funzionalità (equipaggio F) e Cliente (equipaggio C).Teams self-organize for each sprint into two distinct crews: Features (F-crew) and Customer (C-crew).

L'equipaggio F lavora su funzionalità di cui è stato eseguito il commit e l'equipaggio C si occupa di problemi e interruzioni del sito live. Il team stabilisce una cadenza rotante che consente ai membri di pianificare più facilmente le attività. Per altre informazioni sul modello multi-equipaggio, vedere Creare team produttivi e incentrati sui clienti.

Migliorare le procedure di integrità del codice

Prima di passare alle metodologie Agile, i team usati per consentire la compilazione dei bug di codice fino al completamento del codice alla fine della fase di sviluppo. Teams ha quindi individuato i bug e ha lavorato per correggerli. Questa pratica ha creato un roller coaster di bug, che ha influenzato il morale e la produttività del team quando i team hanno dovuto lavorare sulle correzioni di bug invece di implementare nuove funzionalità.

Teams implementa ora un limite di bug calcolato dalla formula # of engineers x 5 = bug cap. Se il numero di bug di un team supera il limite di bug alla fine di uno sprint, deve smettere di lavorare sulle nuove funzionalità e correggere i bug fino a quando non sono sotto il limite. Teams ora paga il debito di bug man mano che passano.

Promuovere la trasparenza e la responsabilità

Al termine di ogni sprint, ogni team invia un messaggio di posta elettronica a ciò che ha ottenuto nello sprint precedente e cosa prevede di eseguire nello sprint successivo.

Obiettivi e risultati chiave (OKR)

I team sono più efficaci quando sono chiari sugli obiettivi che l'organizzazione sta cercando di raggiungere. Microsoft offre chiarezza per i team tramite obiettivi e risultati chiave (OKR).

• Gli obiettivi definiscono gli obiettivi da raggiungere. Gli obiettivi sono significativi, concreti, orientati all'azione e, idealmente, dichiarazioni d'ispirazione di intento. Gli obiettivi rappresentano grandi idee, non numeri effettivi.
• I risultati chiave definiscono i passaggi per raggiungere gli obiettivi. I risultati chiave sono risultati quantificabili che valutano lo stato di avanzamento e indicano il successo rispetto agli obiettivi in un periodo di tempo specifico.

Gli OKR riflettono i migliori risultati possibili, non solo i risultati più probabili. I leader cercano di essere ambiziosi e non cauti. Spingere i team a perseguire risultati chiave impegnativi determina l'accelerazione rispetto agli obiettivi e assegna priorità al lavoro che si sposta verso obiettivi più grandi.

L'adozione di un framework OKR consente ai team di ottenere prestazioni migliori per i motivi seguenti:

• Ogni team è allineato al piano.
• I team si concentrano sul raggiungimento dei risultati anziché sul completamento delle attività.
• Ogni team è responsabile regolarmente degli sforzi.

Gli OKR potrebbero esistere a livelli diversi di un prodotto. Ad esempio, possono essere presenti OKR di prodotto di primo livello, OKR a livello di componente e OKR a livello di team. Mantenere allineati gli OKR è relativamente semplice, soprattutto se gli obiettivi vengono impostati dall'alto verso il basso. Eventuali conflitti che si verificano sono importanti indicatori iniziali del disallineamento dell'organizzazione.

Esempio di OKR

Obiettivo: crescere una base di clienti forte e felice.

Risultati chiave:

• Aumentare il punteggio del promotore netto esterno (NPS) da 21 a 35.
• Aumentare la soddisfazione dei documenti da 55 a 65.
• Il nuovo flusso della pipeline ha un punteggio Apdex pari a 0,9.
• Il tempo di coda per i processi è di 5 secondi o inferiore.

Per altre informazioni sugli OKR, vedere Misurare i risultati aziendali usando obiettivi e risultati chiave.

Selezionare le metriche corrette

I risultati chiave sono utili solo come le metriche su cui si basano. Microsoft usa indicatori principali che si concentrano sul cambiamento. Nel corso del tempo, queste metriche creano un quadro di lavoro dell'accelerazione o della decelerazione del prodotto. Microsoft usa spesso le metriche seguenti:

• Variazione del tasso di crescita mensile di adozione
• Modifica delle prestazioni
• Cambia nel tempo per imparare
• Modifica della frequenza degli eventi imprevisti

Teams evita le metriche che non accumulano valore per gli obiettivi. Anche se possono avere determinati usi, le metriche seguenti non sono utili per tenere traccia dello stato di avanzamento verso gli obiettivi:

• Accuratezza delle stime originali
• Ore completate
• Righe di codice
• Capacità del team
• Burn-down del team
• Velocità del team
• Numero di bug rilevati
• Code coverage

Prima di Agile e dopo Agile

La tabella seguente riepiloga le modifiche apportate dai team di sviluppo Microsoft man mano che hanno adottato procedure Agile.

Prima	Dopo
Attività cardine di 4-6 mesi	Sprint di 3 settimane
Team orizzontali	Team verticali
Uffici personali	Team rooms and remote work
Cicli di pianificazione lunghi	Pianificazione e apprendimento continui
PM, sviluppo e test	PM, progettazione e progettazione
Coinvolgimento annuale dei clienti	Impegno continuo dei clienti
Rami di funzionalità	Tutti lavorano nel ramo principale
20 team di persone	Team di 8-12 persone
Roadmap dei segreti	Roadmap condivisa pubblicamente
Debito bug	Zero debito
Documenti delle specifiche di 100 pagine	Specifiche di PowerPoint
Repository privati	Open source o InnerSource
Gerarchia dell'organizzazione profonda	Gerarchia dell'organizzazione bidimensionale
I numeri di installazione definiscono l'esito positivo	La soddisfazione dell'utente definisce il successo
Funzionalità spedite una volta all'anno	Le funzionalità vengono fornite ogni sprint

Punti chiave

• Prendere sul serio la scienza Agile, ma non essere eccessivamente prescrittivo. Agile può diventare troppo rigoroso. Lasciare crescere la mentalità e la cultura Agile.
• Celebrare i risultati, non l'attività. La distribuzione della funzionalità supera le righe di codice.
• Spedisci a ogni sprint per stabilire un ritmo e una cadenza e trovare tutto il lavoro che deve essere fatto.
• Creare le impostazioni cultura che si vuole ottenere il comportamento che si sta cercando.