Comment Microsoft planifie avec DevOps

Microsoft est l’une des plus grandes entreprises au monde à utiliser les méthodologies Agile. Au fil des années d’expérience, Microsoft a développé un processus de planification DevOps qui s'étend des plus petits projets jusqu'à des efforts massifs comme Windows. Cet article décrit de nombreuses leçons apprises et pratiques mises en œuvre par Microsoft lors de la planification de projets logiciels au sein de l’entreprise.

Changements instrumentaux

Les changements clés suivants contribuent à rendre les cycles de développement et d’expédition plus sains et plus efficaces :

• Promouvoir l’alignement culturel et l’autonomie.
• Changer l'orientation des individus vers les équipes.
• Créer de nouvelles stratégies de planification et d’apprentissage.
• Mettre en œuvre un modèle multi-équipage.
• Améliorer les pratiques d’intégrité du code.
• Favoriser la transparence et la responsabilisation.

Promouvoir l’alignement culturel et l’autonomie

Peter Drucker a déclaré : « La culture mange de la stratégie pour le petit déjeuner ». L’autonomie, la maîtrise et l’objectif sont des motivations humaines clés. Microsoft essaie de fournir ces facteurs de motivation aux PM, aux développeurs et aux concepteurs afin qu’ils se sentent habilités à créer des produits à succès.

Deux contributeurs importants à cette approche sont l’alignement et l’autonomie.

• L’alignement découle du haut vers le bas pour s’assurer que les individus et les équipes comprennent comment leurs responsabilités s’alignent sur les objectifs métier plus larges.
• L’autonomie se produit du bas vers le haut, pour s’assurer que les individus et les équipes ont un impact sur les activités et les décisions quotidiennes.

Il y a un équilibre délicat entre l’alignement et l’autonomie. Trop d’alignement peut créer une culture négative où les gens ne font que ce qu'on leur dit. Trop d’autonomie peut entraîner un manque de structure ou de direction, une prise de décision inefficace et une mauvaise planification.

Changer l'orientation des individus vers les équipes

Microsoft organise des personnes et des équipes en trois groupes : PM, conception et ingénierie.

• PM définit ce que Microsoft génère, et pourquoi.
• La conception est responsable de la conception de ce que Microsoft génère.
• L’ingénierie construit les produits et garantit leur qualité.

Les équipes Microsoft ont les caractéristiques clés suivantes :

• Interdisciplinaire
• 10-12 personnes
• Autogestion
• Charte et objectifs clairs pour 12 à 18 mois
• Salles de réunion physiques
• Propres fonctionnalités en déploiement
• Propres fonctionnalités en production

Viser des équipes verticales

Auparavant, les équipes Microsoft étaient horizontales, couvrant toutes les interfaces utilisateur, toutes les données ou toutes les API. À présent, Microsoft vise des équipes verticales. Les équipes possèdent leurs domaines du produit de bout en bout. Des directives strictes à certains niveaux garantissent l’uniformité entre les équipes à travers le produit.

Le diagramme suivant conceptualise la différence entre les équipes horizontales et verticales :

Autoriser les équipes auto-sélectionnées

Environ tous les 18 mois, Microsoft exécute un « exercice collant jaune », où les développeurs peuvent choisir les zones du produit sur lesquelles ils veulent travailler pour les deux prochaines périodes de planification. Cet exercice offre de l'autonomie, car les équipes peuvent choisir sur quoi travailler et l’alignement organisationnel, car il favorise l’équilibre entre les équipes. Environ 80 % des personnes participant à cet exercice font toujours partie de leurs équipes actuelles, mais elles se sentent responsabilisées parce qu’elles avaient le choix.

Créer de nouvelles stratégies de planification et d’apprentissage

Dwight Eisenhower a déclaré : « Les plans sont sans valeur, mais la planification est tout. » La planification Microsoft se décompose dans la structure suivante :

• Sprints (3 semaines)
• Plans (3 sprints)
• Saisons (6 mois)
• Stratégies (12 mois)

Les ingénieurs et les équipes sont principalement responsables des sprints et des plans. Le leadership est principalement responsable des saisons et des stratégies.

Le diagramme suivant illustre la stratégie de planification de Microsoft :

Cette structure de planification permet également d’optimiser l’apprentissage lors de la planification. Les équipes sont en mesure d’obtenir des commentaires, de découvrir ce que veulent les clients et de mettre en œuvre rapidement et efficacement les demandes des clients.

Mettre en œuvre un modèle multi-équipage

Les méthodes précédentes ont favorisé une « culture d’interruption » des bogues et des incidents sur le site en direct. Les équipes Microsoft ont trouvé leur propre façon de se concentrer et d’éviter les distractions. Les équipes s’organisent automatiquement pour chaque sprint en deux équipages distincts : Fonctionnalités (équipage F) et Client (équipage C).

L’équipage F travaille sur des fonctionnalités validées, et l’équipage C s'occupe des problèmes et des interruptions sur le site en direct. L’équipe établit une cadence de rotation qui permet aux membres de planifier plus facilement les activités. Pour plus d’informations sur le modèle multi-équipage, consultez Créer des équipes productives et axées sur les clients.

Améliorer les pratiques d’intégrité du code

Avant de passer à des méthodologies Agile, les équipes laissaient les bogues de code s’accumuler jusqu’à ce que le code soit terminé à la fin de la phase de développement. Les équipes ont ensuite découvert des bogues et travaillé sur leur correction. Cette pratique a créé une montagne russe de bogues, ce qui a affecté le moral et la productivité des équipes lorsque celles-ci devaient travailler sur des correctifs de bogues au lieu d’implémenter de nouvelles fonctionnalités.

Les équipes implémentent désormais une limite de bogue, calculée par la formule # of engineers x 5 = bug cap. Si le nombre de bogues d’une équipe dépasse la limite de bogues à la fin d’un sprint, elle doit cesser de travailler sur de nouvelles fonctionnalités et corriger les bogues jusqu’à ce qu’ils soient en dessous de son limite. Les équipes remboursent désormais leur dette de bogues au fur et à mesure.

Favoriser la transparence et la responsabilisation

À la fin de chaque sprint, chaque équipe envoie un message signalant ce qu’elle a accompli dans le sprint précédent et ce qu’elle envisage de faire dans le sprint suivant.

Objectifs et résultats clés (OKR)

Les équipes sont les plus efficaces lorsqu’elles sont claires sur les objectifs que l’organisation tente d’atteindre. Microsoft fournit une clarté pour les équipes grâce à des objectifs et des résultats clés (OKR).

• Les objectifs définissent les objectifs à atteindre. Les objectifs sont des déclarations d'intention significatives, concrètes, orientées vers l’action et idéalement inspirantes. Les objectifs représentent de grandes idées, pas des nombres réels.
• Les résultats clés définissent les étapes à suivre pour atteindre les objectifs. Les résultats clés sont des résultats mesurables qui évaluent la progression et indiquent la réussite par rapport aux objectifs dans une période donnée.

Les OKR reflètent les meilleurs résultats possibles, pas seulement les résultats les plus probables. Les dirigeants essaient d’être ambitieux et pas prudents. Pousser les équipes à poursuivre des résultats clés difficiles favorise l’accélération par rapport aux objectifs et hiérarchise les travaux qui se déplacent vers des objectifs plus importants.

L’adoption d’une infrastructure OKR peut aider les équipes à s’améliorer pour les raisons suivantes :

• Chaque équipe est alignée sur le plan.
• Les équipes se concentrent sur l’obtention de résultats plutôt que sur l'achèvement des activités.
• Chaque équipe est responsable des efforts sur une base régulière.

Les OKR peuvent exister à différents niveaux d’un produit. Par exemple, il peut y avoir des OKR de produit de niveau supérieur, des OKR au niveau du composant et des OKR au niveau de l’équipe. Maintenir les OKR alignés est relativement facile, surtout si les objectifs sont définis de haut en bas. Tous les conflits qui surviennent sont des indicateurs précoces précieux de désalignement organisationnel.

Exemple d’objectif et de résultats clés

Objectif : développer une clientèle solide et heureuse.

Résultats clés :

• Augmentez le score de promoteur net externe (NPS) de 21 à 35.
• Augmentez la satisfaction des documents de 55 à 65.
• Le nouveau flux de pipeline a un score Apdex de 0,9.
• Le temps de file d’attente pour les travaux est de 5 secondes ou moins.

Pour plus d’informations sur les OKR, voir Mesurer les résultats de l’entreprise à l’aide d’objectifs et de résultats clés.

Sélectionner les métriques appropriées

Les résultats clés sont aussi utiles que les métriques sur lesquelles ils sont basés. Microsoft utilise des indicateurs avancés axés sur le changement. Au fil du temps, ces métriques dressent un tableau fonctionnel de l’accélération ou de la décélération du produit. Microsoft utilise souvent les métriques suivantes :

• Changement du taux de croissance mensuel de l’adoption
• Changement de performances
• Changer de temps d'apprentissage
• Modification de la fréquence des incidents

Les équipes évitent les métriques qui n'apportent pas de valeur aux objectifs. Bien qu’elles aient certaines utilisations, les métriques suivantes ne sont pas utiles pour suivre la progression vers les objectifs :

• Précision des estimations d’origine
• Heures effectuées
• Lignes de code
• Capacité de l’équipe
• Burndown de l’équipe
• Vélocité de l'équipe
• Nombre de bogues trouvés
• Couverture du code

Avant Agile et après Agile

La table suivante récapitule les modifications apportées aux équipes de développement Microsoft lors de l’adoption des pratiques Agile.

Avant le	Après
Jalons de 4 à 6 mois	Sprints de 3 semaines
Équipes horizontales	Équipes verticales
Bureaux personnels	Salles de réunion et travail à distance
Cycles de planification longs	Planification et apprentissage continus
PM, Dev, et Test	PM, Conception, et Ingénierie
Engagement client annuel	Engagement client continu
Branches de fonctionnalité	Tout le monde travaille dans la branche principale
Équipes de plus de 20 personnes	Équipes de 8 à 12 personnes
Feuille de route secrète	Feuille de route partagée publiquement
Dette de bogue	Zéro dette
Documents de spécification de 100 pages	Spécifications PowerPoint
Référentiels privés	Open source ou Source interne
Hiérarchie organisationnelle profonde	Hiérarchie organisationnelle aplatie
Les nombres d’installation définissent la réussite	La satisfaction des utilisateurs définit la réussite
Les fonctionnalités sont expédiées une fois par an	Les fonctionnalités sont expédiées à chaque sprint

Points clés

• Prenez la science Agile au sérieux, mais ne soyez pas trop prescriptif. Agile peut devenir trop strict. Laissez l’état d’esprit et la culture Agile se développer.
• Célébrez les résultats, et non l’activité. Le déploiement des fonctionnalités l'emporte sur les lignes de code.
• Expédier à chaque sprint pour établir un rythme et une cadence et trouver tout le travail qui doit être fait.
• Générez la culture que vous souhaitez pour obtenir le comportement que vous recherchez.