Partager via


Comment Microsoft planifie avec DevOps

Microsoft est l’une des plus grandes entreprises du monde à utiliser des méthodologies Agile. Au fil de ses années d’expérience, Microsoft a développé un processus de planification DevOps qui s'adapte aussi bien aux projets les plus petits qu'aux efforts gigantesques tels que Windows. Cet article décrit la plupart des leçons apprises et pratiques que Microsoft implémente lors de la planification de projets logiciels au sein de l’entreprise.

Changements instrumentaux

Les changements clés suivants aident à améliorer la santé et l’efficacité des cycles de développement et d’expédition :

  • Promouvoir l’alignement culturel et l’autonomie.
  • Passez du focus des individus aux équipes.
  • Créez de nouvelles stratégies de planification et d’apprentissage.
  • Implémentez un modèle multi-équipage.
  • Améliorer les pratiques de santé du code.
  • Favoriser la transparence et la responsabilité.

Promouvoir l’alignement culturel et l’autonomie

Peter Drucker a déclaré : « La culture surpasse la stratégie dès le début ». L’autonomie, la maîtrise et le but sont des motivations humaines clés. Microsoft tente de fournir ces motivations aux chefs de produit, aux développeurs et aux concepteurs afin qu’ils se sentent en mesure de créer des produits réussis.

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

  • L’alignement provient du haut en bas pour s’assurer que les individus et les équipes comprennent comment leurs responsabilités s’alignent sur des objectifs métier plus larges.
  • L’autonomie se produit du bas en 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.

Passer du focus des individus aux é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 chargée de la création de ce que Microsoft développe.
  • L’ingénierie construit les produits et garantit leur qualité.

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

  • Transdisciplinaire
  • 10 à 12 personnes
  • Auto-gestion
  • Charte et objectifs clairs pendant 12 à 18 mois
  • Salles d’équipe physiques
  • Propre déploiement de fonctionnalités
  • Propres fonctionnalités en production

S’efforcer d’établir des équipes verticales

Les équipes Microsoft étaient auparavant horizontales, couvrant toutes les interfaces utilisateur, toutes les données ou toutes les API. À présent, Microsoft s’efforce de promouvoir des équipes verticales. Les équipes sont responsables de leurs aspects du produit de bout en bout. Des directives strictes dans certains niveaux garantissent l’uniformité entre les équipes du produit.

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

Diagramme montrant les structures d’équipe horizontales et verticales.

Autoriser la sélection automatique d’équipes

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 une autonomie, car les équipes peuvent choisir ce qui fonctionne et l’alignement organisationnel, car elle favorise l’équilibre entre les équipes. Environ 80 % des personnes de cet exercice restent dans leurs équipes actuelles, mais elles se sentent responsabilisées parce qu’elles ont eu le choix.

Créer des 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 Microsoft :

Diagramme montrant la stratégie de planification Microsoft.

Cette structure de planification permet également d’optimiser l’apprentissage lors de la planification. Teams est en mesure d’obtenir des commentaires, de savoir ce que les clients veulent et d’implémenter rapidement et efficacement les demandes des clients.

Implémenter 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 moyen de fournir le focus et d’éviter les distractions. Les équipes s'auto-organisent pour chaque sprint en deux équipes distinctes : Fonctionnalités (équipage F) et Client (équipage C).

L'équipe F travaille sur des fonctionnalités prévues, et l'équipe C traite des problèmes de site en direct et des interruptions. 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 de santé du code

Avant de passer aux méthodologies Agile, les équipes avaient l'habitude de laisser les erreurs de code s'accumuler jusqu'à ce que le code soit finalisé à la fin de la phase de développement. Teams a ensuite découvert des bogues et travaillé sur la résolution de ces bogues. Cette pratique a créé des montagnes russes de bogues; ce qui a affecté le moral et la productivité des équipes lorsque les équipes devaient travailler sur des correctifs de bogues au lieu d’implémenter de nouvelles fonctionnalités.

Teams implémente 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, il doit cesser de travailler sur de nouvelles fonctionnalités et corriger les bogues jusqu’à ce qu’ils soient sous leur limite. Les équipes paient maintenant la dette de bug au fur et à mesure.

Favoriser la transparence et la responsabilité

À 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 significatifs, concrets, orientés vers l’action et idéalement inspirants énoncés d’intention. 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 la fin des activités.
  • Chaque équipe est responsable des efforts de manière 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 l’alignement des OKR est relativement facile, en particulier si les objectifs sont définis en haut. Les conflits qui se produisent sont des indicateurs précoces précieux de l’inalignation organisationnelle.

Exemple OKR

Objectif : développer une base de clients forte et heureuse.

Résultats clés :

  • Augmentez le score de promoteur net externe (NPS) de 21 à 35.
  • Augmenter la satisfaction liée à la documentation 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, consultez Mesurer les résultats métier à l’aide d’objectifs et de résultats clés.

Sélectionner les métriques appropriées

Les résultats clés sont uniquement aussi utiles que les métriques sur lesquelles elles sont basées. Microsoft utilise des indicateurs avancés qui se concentrent sur les changements. Au fil du temps, ces métriques construisent une vue d'ensemble 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 des performances
  • Changement dans la durée 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 terminées
  • Lignes de code
  • Capacité d’équipe
  • Burndown de l’équipe
  • Vitesse d’équipe
  • Nombre de bogues trouvés
  • Couverture du code

Avant Agile et après Agile

Le tableau suivant récapitule les modifications apportées aux équipes de développement Microsoft lors de l’adoption des pratiques Agile.

Avant Après
Jalons de 4 à 6 mois Sprints de 3 semaines
Équipes horizontales Équipes verticales
Bureaux personnels Salles d’équipe et travail à distance
Cycles de planification longs Planification et apprentissage continus
PM, Dev et Test PM, Conception et Ingénierie
Engagement client annuel Engagement continu des clients
Branches de fonctionnalités 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 InnerSource
Hiérarchie d’organisation approfondie Hiérarchie aplatie de l’organisation
Les numéros d’installation définissent la réussite La satisfaction des utilisateurs définit la réussite
Les fonctionnalités sont lancées une fois par an Les fonctionnalités sont livrées à chaque sprint

Points clés à prendre

  • Prenez la science Agile au sérieux, mais ne soyez pas trop prescriptive. Agile peut devenir trop strict. Laissez l’esprit agile et la culture croître.
  • Fêtez les résultats, et non l’activité. Le déploiement de fonctionnalités dépasse les lignes de code.
  • Expédier à chaque sprint pour établir un rythme et une cadence et trouver tout le travail qui doit être fait.
  • Cultivez la culture que vous souhaitez pour encourager le comportement que vous recherchez.