S'il y a une tendance qui a dépassé Agile dans notre profession au cours des cinq dernières années, je dirais que DevOps serait un bon coupable. Comme nous avons vu une explosion d'outils pour implémenter CI / CD dans nos équipes Scrum, nous avons également vu certaines de nos pratiques Agile être contestées par cette nouvelle réalité.

Je dirais que ces pratiques sont les points d'histoire / estimation relative / planification de poker. Et je crois qu'il est plus que temps que nous examinions de nouvelles techniques pour les remplacer pour s'adapter à la nouvelle réalité des équipes Scrum qui sont fortement influencées par DevOps.

D'après mon expérience avec les points d'histoire et la vélocité, nous estimons un article de backlog de produit (PBI) basé sur l'effort qu'il nous faut pour fournir un morceau de fonctionnalité à notre propriétaire de produit. Nous essayons ensuite de tracer une vitesse basée sur un ensemble de PBI que nous prenons à chaque sprint.

Par exemple, dans l'image ci-dessous, nous visualisons un PBI valant 3 points d'histoire représentés avec une barre bleue. Cette barre bleue contient tout le travail prévu par l'équipe de développement pour compléter l'IBP.

Je trouve cette approche de moins en moins bénéfique à mesure que nous entrons dans un «Vous la construisez. Vous l'exécutez. »Mentalité. Comme nous pouvons désormais déployer des fonctionnalités plus rapidement et plus rapidement que jamais, cela apporte son lot de nouvelles responsabilités aux développeurs. Dans un tel contexte, je trouve que les équipes Scrum font plus de support client, résolvent les pannes, corrigent les bugs pour maintenir le code de production et surveillent les tableaux de bord opérationnels de leurs systèmes pour nommer quelques nouvelles tâches auxquelles elles doivent faire face.

Ce qui remet en question l'utilisation des récits, encore plus, est la difficulté de prédire les tâches opérationnelles de nos équipes Scrum. Pouvons-nous prédire avec précision le nombre d'ingénieurs commerciaux qui vous rappelleront au prochain sprint avec des problèmes clients? Peut-on prévoir que ces deux supports de rack sont sur le point de surchauffer parce qu'un technicien de service n'a pas fait son travail correctement?

Ainsi, alors que 3 points d'histoire ressemblaient à l'image ci-dessus lorsque nous fonctionnions dans un vide de développement pur, nous représentons nos nouvelles tâches imprévisibles avec des barres rouges, étendant ainsi nos 3 points d'histoire originaux.

Alors, quelle est la valeur de notre système de points d'histoire lorsque ces barres rouges continuent d'apparaître sur nos estimations originales? Si tel est votre cas, vous avez peut-être essayé de faire de meilleures estimations ou avez opté pour #noestimates. Si vous n'êtes toujours pas satisfait de ces options précédentes, je pense qu'il y a une troisième façon où le travail non planifié est intégré dans les mesures réelles.

Mesures Kanban

Je pense que nous sommes prêts à aller de l'avant et à adopter une troisième voie qui trouve ses racines dans l'empirisme. L'approche vient de la communauté Kanban. Ils sont appelés métriques Kanban (ou métriques de flux). Je trouve qu'ils constituent un excellent ensemble de pratiques pour le cadre Scrum, surtout lorsque votre contexte est plus proche de DevOps que du travail de développement pur.

Comme défini dans le Guide Kanban pour les équipes Scrum, les quatre mesures de flux de base sont:

Work in Progress (WIP): nombre d'éléments de travail démarrés mais non terminés. Notez la différence entre la métrique WIP et les politiques qu'une équipe Scrum utilise pour limiter le WIP. L'équipe peut utiliser la métrique WIP pour assurer la transparence de ses progrès vers la réduction de son WIP et l'amélioration de son flux.Temps de cycle: durée écoulée entre le début d'un élément de travail et la fin d'un élément de travail.Age de l'élément de travail: la quantité de temps entre le début d'un élément de travail et l'heure actuelle. Cela s'applique uniquement aux éléments qui sont encore en cours. Débit: nombre d'éléments de travail terminés par unité de temps.

Revoyons nos 3 points d'histoire ci-dessus et regardons-le du point de vue du temps de cycle. Disons que cela a pris 12 jours à partir du moment où nous avons commencé à travailler dessus jusqu'à ce que nous ayons terminé l'IBP, y compris toutes les barres rouges illustrées dans l'image précédente.

Tracons-le sur un graphique comme indiqué dans l'image suivante où notre article a été achevé le 6 mars 2018.

Tracons ensuite le reste de nos PBI terminés sur le graphique. Cela ressemble maintenant à ceci:

Dans le graphique ci-dessus, appelé diagramme de dispersion du temps de cycle, nous voyons nos PBI complétés par notre équipe Scrum. J'ai mis deux infobulles sur le graphique pour aider le lecteur à mieux le comprendre. Le 4 avril, l'équipe Scrum a complété 1 PBI où il a fallu 6 jours pour terminer. Le 25 février, l'équipe Scrum a réalisé 2 PBI, l'un en 2 jours et l'autre en 9 jours.

Les dernières informations à ajouter à ce diagramme de dispersion du temps de cycle sont des lignes de centile. Dans le graphique ci-dessous, j'ai ajouté un deuxième axe Y à droite avec des lignes de centile. Une ligne centile signifie qu'en dessous de la ligne, nous avons un pourcentage de tous les points tracés sur le graphique. Une ligne centile à 50% signifie que nous avons 50% de nos points sous cette ligne tandis qu'une ligne centile à 85% signifie que nous avons 85% de nos points sous cette ligne.

À l'aide du tableau ci-dessus, nous pouvons affirmer que 85% du temps, notre équipe Scrum réalise un PBI en 8 jours ou moins. Nous appelons cela notre attente de niveau de service (SLE) qui prévoit combien de temps il devrait prendre un élément donné pour circuler du début à la fin dans le flux de travail de l'équipe Scrum.

Donc, au lieu d'estimer nos PBI, en discutant si c'est 2 ou 3 points, nous pouvons nous demander s'il tombe en dessous de notre SLE. Si la réponse est non, nous avons une conversation sur le fractionnement (ou non) pour honorer notre LED. Si la réponse est oui, nous passons simplement au prochain PBI pour affiner. Nous avons toujours la conversation technique autour de l'IBP comme nous l'avons fait auparavant avec les points d'histoire. Nous ne faisons tout simplement plus la partie planification du poker.

Lors de la planification du sprint, nous avons soit des PBI inférieurs au SLE, soit des exceptions dont notre Product Owner a connaissance. Pendant le sprint, nous surveillons activement l'âge de nos PBI pour minimiser les chances qu'ils dépassent le SLE.

Le sommet de l'iceberg

Si ce post a suscité votre intérêt, nous ne touchons que la pointe de l'iceberg.

Les métriques Kanban peuvent également aider l'équipe de développement à prévoir le nombre de PBI nécessaires pour atteindre leur objectif de sprint. Dans un article ultérieur, je parlerai de la planification de sprint basée sur le débit. Nous utiliserons une autre mesure de débit, le débit, pour prévoir notre sprint en conjonction avec le diagramme de dispersion du temps de cycle. De nouvelles techniques telles que la prévision probabiliste, le dimensionnement à droite et les simulations Monte Carlo offrent une perspective nouvelle et fraîche pour déterminer les dates de livraison. SLE et le vieillissement des éléments de travail peuvent changer les conversations de votre Scrum quotidien autour du travail.

Pour une plongée profonde dans les mesures Kanban, je recommande fortement le livre de Daniel Vacanti Actionable Agile – Metrics pour la prévisibilité. Si vous souhaitez apprendre à appliquer ces métriques avec vos équipes Scrum, je vous encourage fortement à consulter la classe Scrum professionnel avec Kanban (PSK).

Oui, je dois admettre qu'il s'agit d'un plug sans vergogne pour le cours Professional Scrum with Kanban (PSK). En même temps, je crois fermement que le PSK aidera notre industrie avec une alternative aux points d'histoire qui, je crois, est plus appropriée avec notre nouvelle réalité DevOps. Comme notre industrie est passée de la cascade aux itérations au cours des 15 dernières années, je pense que les mesures Kanban deviendront la norme de facto lors de la gestion et de la prévision de notre travail dans un avenir proche.

Auteur: Louis-Philippe Carignan

Louis-Philippe Carignan a découvert Agile pour la première fois en jouant avec le développement piloté par les tests et l'intégration continue en 2004. Il a ensuite rencontré XP, Scrum et n'a jamais regardé en arrière. Avec 15 ans d'expérience Agile, Louis-Philippe est un formateur agile aguerri et consultant qui peut naviguer de l'agilité des affaires jusqu'à… Voir le profil complet ›