Effectué et annulé

De Ken Schwaber et David Starr, Scrum.org

Janvier 2012

Fournir un incrément terminé est très difficile à effectuer avec un développement logiciel Agile.À l'aide d'exemples réels et théoriques, les auteurs montrent la différence entre la perception de « terminé » et la réalité de « terminé », ainsi que la manière dont cela affecte la réussite d'un projet.À l'aide de ces exemples, les auteurs présentent les outils et les stratégies pouvant aider les équipes à commencer avec une définition du terme « terminé » qui a du sens pour elles, ainsi que les méthodes pour aider les équipes à communiquer les dépendances, le statut et la signification de « terminé ».

S'applique à

Gestion du cycle de vie des applications ; Team Foundation Server

Dans cet article :

• Introduction

• Transparence perdue dans la société d'Anna

  • Ce que les personnes pensaient de ce qui s'était passé

  • Que s'est-il passé en réalité ?

  • La leçon

• Retard technique à Nanomedtronics AZ

  • Ce que les personnes pensaient de ce qui s'était passé

  • Que s'est-il passé en réalité ?

  • La leçon

• Un retard technique s'amplifie avec plusieurs équipes

• Plan de version à Datum Corporation

  • Ce que les personnes pensaient de ce qui s'était passé

  • Que s'est-il passé en réalité ?

  • La leçon

• Techniques à grande échelle pour les réalisations

  • Scrum de Scrums

  • Intégration continue

• Conclusion

Scrum est une infrastructure Agile itérative et incrémentielle.Les équipes l'utilisent pour fournir rapidement des incréments de « terminé », ou des fonctionnalités de logiciel potentiellement utilisables à chaque itération, ou Sprint.

« Terminé » est un mot simple mais souvent mal interprété.Pour moi, cela signifie terminé, finalisé et achevé.Avoir terminé signifie qu'il n'y a plus rien à faire.L'opération Terminer est simple à définir ; toutefois, livrer un index terminé reste l'une des spécifications fondamentales et plus évasives pour Scrum et en termes de souplesse.

L'agilité requiert la fourniture d'incréments de logiciel fonctionnel achevés et prêts à l'emploi dans chaque sprint.Et pourtant la plupart des équipes Scrum et agiles produisent des Increments partiellement faits et incomplets.Lorsque l'on demande à une équipe Scrum pourquoi les spécifications du journal des travaux en souffrance du produit n'ont pas été entièrement respectées dans un sprint, les membres de l'équipe répondent souvent, « Nous n'avons pas eu le temps. »

Ce document traite des problèmes liés aux incréments effectuées grâce à des exemples d'études de cas datant des débuts de Scrum.Les noms et les emplacements des personnes impliquées ont été modifiés mais je suis sûr que les personnes se reconnaîtront et reconnaîtront leur investissement.Tout au long de cet article, tous les sprints font l'objet d'une itération mensuelle, sauf indication contraire.

Transparence perdue dans la société d'Anna

Anna doit automatiser la réception des modifications de titre de propriété de son service.La société dans laquelle elle travaille construit et fait fonctionner des gazoducs un peu partout en Amérique du Nord.Son service a traité et payé des droits d'auteur aux personnes propriétaires de la terre traversée.Les informations de titre que le service d'Anna a reçu étaient des impressions ou des documents de modification de propriété.Le volume devenait trop important, c'est pourquoi Anna souhaitait automatiser les flux et le processus de paiement de droits.

Notre équipe de développement a proposé d'établir le système de redevance pour Anna à l'aide de Scrum.De cette manière, nous étions sûrs de pouvoir examiner un logiciel utilisable tous les mois.Elle avait également le droit de changer d'avis chaque mois sur ce que notre équipe allait faire ensuite.

À la fin du troisième sprint, nous avons reçu un flux de l'une des provinces et nous l'avons intégré à des données plus anciennes.Nous l'avons démontré à l'aide d'une solution SQL simple.Anna était contente, car la plupart du journal des travaux en souffrance du produit de son équipe émanait de cette province.

Elle voulait qu'on enseigne le SQL à son personnel afin qu'il puisse immédiatement commencer à utiliser le logiciel que l'équipe de développement a fourni.

À quoi faisait-elle allusion lorsqu'elle disait qu'elle souhaitait l'utiliser ?Qu'elle n'avait sûrement pas interprété avoir terminé avec un Sprint comme d'avoir terminé avec le logiciel !

Nous en avons informé Anna en prenant toutes les précautions possibles.Elle était furieuse.« Que voulez-vous dire par ce n'est pas terminé ?J'ai vu le premier incrément, le deuxième incrément et maintenant je souhaite commencer à l'utiliser.Déployez-le et enseignez-nous le langage SQL pour que nous puissions l'utiliser. »

Nous avons commencé à nous inquiéter.Nous avons indiqué à Anna que cela avait été fait.Toutefois, ce n'était pas ce type réalisé.Il a été effectué pour elle, mais des problèmes se sont produits qui ont dû être résolus pour permettre l'utilisation du logiciel :

• Certains enregistrements entrants n'ont pas pu être traités.Nous avions besoin d'un dispositif pour les stocker et les gérer, plutôt que de s'en débarrasser.

• Plusieurs des champs des enregistrements entrants semblent être utilisés à des fins autres que celles documentées.Qu'aurions-nous dû faire avec eux ?

• Les champs de la base de données existante contenaient des pointeurs ou des informations qui ressemblaient aux informations de référence.Toute la base de données était concernée.

• Alors que nous exécutions les flux entrants et interrogions la base de données, le système est tombé en panne plusieurs fois.C'est comme si les données avaient été corrompues pendant ces pannes.

Anna nous a demandé combien de temps cela allait durer avant que nous puissions rendre son type réalisé et utilisable.Nous avons estimé que deux sprints supplémentaires étaient nécessaires pour rendre les incréments utilisables.Elle nous a indiqué de démarrer l'opération et de la mettre à disposition de son service.Elle ensuite m'a « demandé » de la rencontrer le lendemain matin.

Le lendemain matin Anna, la responsable, et le responsable du développement étaient là.Ils ont exprimé leur déception sur l'absence de la transparence dont j'avais pourtant parlé.Ils avaient le sentiment que j'aurais dû traiter autrement les problèmes non résolus, plutôt que de les enregistrer comme des bogues.La progression reflétée dans les rapports d'avancement fournis était incorrecte, ce qui les dérangeait.

Après la réunion, notre mot d'ordre était :

1. rechercher et corriger les quatre bogues ;

2. Terminez et déployez les trois premiers incréments pour que le service d'Anna puisse commencer à l'utiliser.

3. Améliore nos compétences en ingénierie et automation des tests pour que notre définition de la fin soit identique à la définition d'Ariane (immédiatement utilisable par l'entreprise).

4. Modifiez le mode d'enregistrement des erreurs afin que la spécification ne soit pas considérée réalisée, sauf si elles ont été corrigées.

   Nous avons été informés que cela pouvait être une bonne opportunité d'apprentissage, si nous apprenions tous nos leçons.

Ce que les personnes pensaient de ce qui s'était passé

Lorsque nous avons développé un plan de base pour le système, il représentait le déroulement que les parties prenantes et Anna avaient à l'esprit.L'équipe de développement a signalé la progression comme si la version respectait les délais et que les personnes faisaient confiance au rapport.

L'équipe de développement pensait en fait qu'elle procédait de la bonne façon en indiquant que le travail se poursuivait comme prescrit dans le plan.

Que s'est-il passé en réalité ?

La rapidité correspond à la mesure et à l'historique de la productivité d'une équipe de développement par sprint.La rapidité est mesurée pour chaque sprint et utilisée pour générer des modèles de productivité.

Notre équipe de développement avait besoin d'une vitesse stockée de 8 unités complètes de travail pour chaque Sprint pour respecter le plan.Lorsque quelque chose menaçait de ralentir notre vitesse en dessous de 8, nous ne terminions pas tout le travail sur ces éléments.

Nous avons livré des fonctionnalités qui s'exécutaient assez bien, mais n'étaient pas suffisamment complètes pour être utilisées.Nous avons prévu de l'améliorer ultérieurement.Lorsque nous sommes revenus pour estimer le travail non effectué, 14 unités de travail supplémentaires avaient été ajoutés.

En fonction du degré de complexité des flux de titre initiaux, nous avons retouché le plan entier pour refléter une planification sur à peu près 20 mois.Le service d'Anna a libéré des incréments environ tous les deux mois, ce qui permet d'activer de nouveaux flux.Les nouveaux flux automatisés ont permis de réduire le travail manuel global de façon si considérable que certains ont été déçus lorsque le système est devenu disponible vingt-deux mois après le début.

La leçon

La véritable transparence requiert que chaque personne consultant l'incrément voie et comprenne la même chose.L'inspection transparente de l'incrément aurait dû permettre à Anna de gérer les risques et de gagner en prévisibilité.Toutefois, étant donné que l'incrément n'était pas transparent, elle ne pouvait pas réaliser de planification efficacement.

Au début du projet, Anna a défini un objectif de version.Après le Sprint 1, elle a évalué la progression vers l'objectif en examinant ce qu'elle pensait être un incrément utilisable.Elle a pris une décision concernant l'utilisation du Sprint 2 basée sur la progression incrémentielle vers l'objectif.Si elle jugeait que notre avancement était insuffisant, elle aurait pu annuler le projet.

À la fin du sprint 3, Anna croyait que 3/10 du total avait été réalisé, ce qui était évidemment incorrect.

Malheureusement, notre avancement sur chaque incrément ne nous permettait pas d'offrir plus qu'une démonstration.Le travail non effectué a rendu les incréments inutilisables pour le service d'Anna et opaques à l'inspection.

Lors de l'examen d'un incrément, l'opacité consiste à couvrir un thermostat d'un gant de toilette froid et humide.Le thermostat n'indique par la température ambiante réelle et risque de démarrer le chauffage au lieu de refroidir.

Sans Increments transparents, les parties prenantes n'ont pas une compréhension correcte de ce qui se produit en réalité, et peuvent entreprendre des actions incorrectes qui n'ont aucun sens.

En résumé, sans transparence totale, la capacité des équipes à examiner et à s'adapter efficacement est perdue.

Retard technique à Nanomedtronics AZ

Un retard technique est le travail différé qui doit être terminé avant que le logiciel soit considéré comme terminé.Un retard technique prend beaucoup de formes, telles que la conception médiocre, la duplication de code et des fonctionnalités non testées.L'exemple suivant montre la cause et l'impact d'un retard technique en tant que travail annulé au cours d'un projet.

Nanomedtronics AZ était une petite société startup spécialisée dans les logiciels.Une équipe Scrum travaillait sur une nouvelle version de leur produit phare, un logiciel utilisé par des mini-robots pour déboucher les artères obstruées de patients souffrant d'hypertension.

Ce que les personnes pensaient de ce qui s'était passé

Lorsque l'équipe s'est lancée, on lui a demandé de sélectionner des éléments du journal des travaux en souffrance du produit et de les transformer en quelque chose de terminé (plus de travail restant, utilisable, potentiellement livrable) dans un sprint d'un mois.L'équipe de développement avait toutes les compétences pour développer complètement les spécifications dans un incrément terminé

Lorsque l'équipe Scrum a démarré le premier sprint, elle a remarqué qu'il y avait 80 unités de travail qui devaient être réalisées en 10 mois.Par conséquent, l'équipe de développement a soigneusement sélectionné 8 unités de travail dans chaque Sprint.D'après leurs calculs, s'ils parvenaient à 8 unités par Sprint, le travail serait terminé dans les 10 mois du mandat de la société.

L'équipe de développement a montré un incrément de travail à la fin de chaque Sprint.Visiblement d'ailleurs, Scrum fonctionnait et Nanomedtronics AZ respectait les délais pour fournir leur produit comme prévu.

Que s'est-il passé en réalité ?

Ce qui n'était pas clair, au delà de l'équipe de développement, c'était que chaque incrément contenait en fait de mauvaises implémentations, des bogues non critiques, une logique répétée et du code désordonné.De plus, les incréments n'avaient pas été entièrement testés parce que l'équipe de développement a interrompu les tests trop pressée par le temps au cours d'un sprint.L'équipe de développement s'est engagée à respecter la planification, et réduire la qualité était souvent la façon de rester dans la course.

L'équipe a travaillé dur et généré le produit au cours des 10 mois.Le client était ravi et prêt à implémenter et utiliser le logiciel.Toutefois, l'équipe de développement avait accumulé 48 unités de travail annulées, représentées dans l'illustration suivante sous la forme d'un nouveau retard technique.

L'équipe de Nanomedtronics AZ n'a pas pris en compte toutes les activités et toutes les tâches qui doivent vraiment être réalisées.Ceci inclut des éléments que l'équipe n'a pas pris en considération, et n'est nullement exhaustive.De nombreux autres éléments pourraient être inclus.

• Analyse

• Conception

• Analyse de la dépendance

• Test de performances

• Test de stabilité

• Refactorisation

• Test de réponse immunologique

• Intégration avec le travail de toutes les autres équipes qui travaillent sur un produit

• Test d'intégration avec le travail de toutes les autres équipes pour que l'incrément constitue l'intégralité des contributions de l'équipe

• Notes de mise à jour

• Internationalisation dans les six cultures où le produit sera vendu

• Test d'acceptation utilisateur

• Test de régression

• Révisions du code

Les tâches ci-dessus doivent être exécutées pour créer un incrément complet, intégré à la fin du Sprint.Toutefois, la plupart des équipes de développement n'effectuent pas tous les travaux ci-dessus.À chaque Sprint, certaines tâches ne sont pas exécutées.Cela crée des incréments mal conçus, un code dupliqué, une logique trop complexe, une fonctionnalité ou une fonction non testée, ou toute autre forme d'inachèvement.Voici comment les équipes provoquent un retard technique du logiciel.

Nanomedtronics AZ a découvert que leur produit comprenait toutes les caractéristiques nécessaires pour le livrer aux clients, mais également de nombreux défauts, et ne présentait pas le conditionnement et le fini nécessaires pour sa commercialisation réelle.L'équipe de développement avait par inadvertance créé un journal des travaux en souffrance à propos d'une tâche supplémentaire qui prendrait encore 6 mois pour se terminer, en supposant une rapidité déjà incorrecte de 8 unités par Sprint.

Attendre 6 mois pour livrer le produit n'était pas concevable pour les dirigeants, et le produit fut livré avec du travail non effectué au bout de 3 mois seulement.Le potentiel perdu n'était pas simplement le retard de 3 mois dans l'expédition du produit, mais dans le ralentissement de la capacité à ajouter de nouvelles fonctionnalités à mesure que l'équipe de développement devait lutter avec un retard technique dans les futurs Sprints.

La leçon

Un retard technique masque la progression réelle et opacifie la transparence requise pour la prise de décision empirique par le propriétaire du produit et les parties prenantes.Un retard technique sera alors remboursé, soit en temps passé à résoudre les problèmes techniques, soit en perte en raison de l'expédition tardive ou de la mauvaise qualité.

Dans la plupart des cas, au moins 50% du travail non terminé reste dans les produits lorsqu'ils sont libérés.Par conséquent, le travail non effectué est institutionnalisé comme un retard en cours.Un retard technique provoque rapidement la fragilité du produit et peut finalement forcer des décisions économiques négatives, comme l'investissement dans un logiciel de réécriture ou l'abandon d'un produit.

Un retard technique s'amplifie avec plusieurs équipes

Une équipe de développement ne doit prendre que la quantité de travail qu'elle peut accomplir dans un Sprint.L'équipe de développement apprend tout ce que cela implique via l'expérience.Une équipe doit toujours utiliser des pratiques d'ingénierie modernes, comme la génération et le test de régression automatisés pour effectuer de nombreuses opérations.Si ceux-ci ne sont pas utilisés, le travail manuel tend à submerger une équipe par le quatrième ou le cinquième sprint.

Considérez une équipe de développement de trois programmeurs et de deux spécialistes en assurance qualité.Chaque jour les programmeurs contrôlent le code dans le système de code source.Il est testé et les bogues sont détectés et fournis au programmeur adéquat.Il s'écoule du temps entre la vérification d'un code, la détection et le signalement des défauts.Pendant ce temps, les autres programmeurs peuvent avoir archivé le code sur le code défaillant.L'effort requis pour résoudre le problème initial est maintenant plus important.Si l'équipe de développement avait une fonction de build et de test continue, l'erreur aurait été détectée immédiatement.Les personnes peuvent l'avoir étudiée, résolue, puis avoir repris.Le travail supplémentaire et les déchets ont pu être évités.

De nombreuses organisations utilisent plusieurs équipes Scrum pour générer le logiciel.Lorsque cela se produit, le problème de retard technique décrit dans la section ci-dessus est considérablement amplifié.Les possibilités d'archivage du code sur le code défaillant sont considérablement supérieures.Le coût pour remédier à la fragilité croissante du logiciel augmente de façon exponentielle au fur et à mesure du travail.

Plan de version à Datum Corporation

J'ai récemment travaillé avec une autre société que j'appellerai Datum Corporation, un fournisseur de logiciels d'infrastructure.La ligne de produits principale utilise plus de 800 développeurs, notamment 250 programmeurs.L'infrastructure de développement était en partie automatisée et en partie manuelle.Les tests ont souvent décalé l'encodage de plusieurs jours.Le temps écoulé entre la vérification d'un code défaillant par un programmeur et sa détection et son signalement était souvent égal ou supérieur à dix jours.

Pour réduire la complexité d'un grand nombre de programmeurs, chaque équipe de développement a travaillé sur sa propre branche de code.Les gestionnaires de développement ont aidé à organiser les spécifications du journal des travaux en souffrance du produit afin de réduire les dépendances.Si chaque équipe de développement a fusionné son code dans la ligne de code principal chaque jour, la quantité de retravail potentiel est réduite.

Toutefois, la direction a pensé que cela prendrait trop de temps.Le service de gestion a décidé de fusionner toutes les branches de code dans la racine tous les trois Sprint.Les tests d'intégration vont trouver des défauts qui seront alors corrigés.Une version finale sera disponible à la fin de chaque trimestre.

Ce que les personnes pensaient de ce qui s'était passé

L'illustration suivante représente le calendrier de lancement et le cycle planifié.

Le plan d'origine utilisé par défaut :

• 9 sprints

• 3 versions finales puis une version complète

• Une organisation de développement de 800 personnes

Que s'est-il passé en réalité ?

Lorsque arriva la date de sortie pour cette organisation, après neuf sprints mensuels, le produit n'était pas prêt à être livré.La sixième version finale comportait plus de 5 000 erreurs et plus de 2 000 spécifications du journal des travaux en souffrance du produit étaient incomplètes.Nous nous sommes demandé comment cela avait pu arriver.Nous voyions une version finale tous les trois mois.Lorsque nous avons fait des recherches, nous avons découvert que la démonstration émanait de la branche de code de chaque équipe de développement.Aucune intégration ne s'est produite.Aucun test d'intégration ne s'est produit.

Pour maintenir la rapidité requise pour la date de sortie, les équipes de développement avaient différé tout travail d'intégration, créant ainsi un retard technique important.Le résultat est un décalage de huit mois par rapport à la date de sortie prévue.Les termes « version finale » n'avaient aucun sens.

L'illustration suivante montre le véritable projet plus le temps nécessaire à la stabilisation.

Les versions finales comportaient une fonctionnalité partiellement fonctionnelle pour les branches de code de chaque équipe.Cinq mois de « stabilisation » a été requis avant la version.Les « performances médiocres » constituaient l'un des problèmes les plus embêtants qui retardaient la distribution. Ce problème a été consigné dans le premier Sprint.

La leçon

Les différentes équipes qui travaillent sur le même logiciel fusionneront leur travail par la suite.L'intégration du logiciel pour garantir son fonctionnement réduit le risque des intégrations et doit souvent avoir lieu.

Attendre pour fusionner le travail de plusieurs équipes est tentant, dans la mesure où cela retarde le coût de la fusion.Ce coût final du retard dépend cependant du nombre d'équipes impliquées et du nombre de branches qui doivent être intégrées.

Techniques à grande échelle pour les réalisations

Il est difficile d'atteindre un état « terminé » dans plusieurs équipes.De nombreuses complexités sont impliquées.Les dépendances entre les équipes et entre des branches de code existent.Bien que cette complexité d'échelle ait un coût, elle est réalisable et offre une valeur considérable lorsque les équipes synchronisées travaillent de concert.

Plusieurs techniques m'ont semblé utiles lorsque plusieurs équipes collaborent.

Scrum de Scrums

Lorsque de nombreuses équipes Scrum travaillent sur le même projet, elles ont besoin d'une technique pour coordonner leur travail.J'ai recommandé un « Scrum de Scrums ». Il s'agit d'un événement quotidien, maintenu immédiatement après le scrum quotidien de chaque équipe.Un technicien de chaque équipe est présent.Chaque représentant d'équipe décrit ce sur quoi son équipe a travaillé.Il/elle décrit ce qu'il/elle envisage de planifier pour le travail du jour suivant.Selon ces informations, les représentants essaient d'identifier les travaux supplémentaires nécessaires, les dépendances suivantes et tout travail qui doit être replanifié.

Le Scrum de Scrums a été utile à de nombreuses sociétés.Mais il est inapproprié.Les dépendances et le retravail peuvent ou ne peuvent être correctement identifiés, car les problèmes font l'objet d'une anticipation pour éviter qu'ils se produisent.Des dépendances imprévues ont provoqué un retravail et l'échec des tests.Certaines équipes passent plus de 50 % de chaque Sprint à toucher et retoucher les dépendances.

Intégration continue

Extreme Programming (XP) requiert l'intégration continue et le test d'intégration du travail d'une équipe.Pourquoi ne pas étendre cette opération à toutes les équipes ?Qu'il y ait deux ou cinquante équipes, les équipes sont requises pour produire un Increment intégré et dont l'intégration est testée à la fin de chaque Sprint.Pour cela, les équipes doivent souvent intégrer leur travail.Étant donné que tout travail non intégré peut éventuellement contenir des dépendances non résolues, l'intégration continue est la meilleure solution.

L'intégration continue de tout le travail s'apparente aux techniques de production Lean.Dans les lignes de production Lean, de nombreuses techniques sont utilisées pour évaluer la qualité d'un produit durant le processus de fabrication.Lorsque des écarts ou des problèmes de qualité se produisent, la chaîne de production est arrêtée.L'intégration continue et les tests d'intégration fournissent les mêmes techniques pour le développement de logiciels.

Aussi difficile qu'il soit, je recommande que chaque équipe et membre d'équipe cesse de coder si une build ou un test en continu échoue.Tout travail continue est généré potentiellement sur les erreurs, se répercutant en cascade sur les erreurs.Si l'intégration continue est utilisée, les équipes travaillent étroitement ensemble pour éviter des défaillances d'intégration.Les habitudes de travail s'améliorent, la quantité de déchets diminue et la qualité augmente.

La plupart des organisations qui adoptent Scrum ne commencent pas avec toutes les compétences et outils d'ingénierie pour générer un incrément achevé.Un programme rigoureux permettant de générer des incréments achevés doit être démarré et poursuivi.Les groupes de moins de cinquante personnes peuvent rapidement atteindre un état dans lequel ils traitent un incrément terminé au cours du sprint.Les organisations de plus de cinq cents développeurs ont souvent besoin de plusieurs années pour y arriver.

Les incréments annulés provoquent du gaspillage et empêchent les équipes d'atteindre une véritable souplesse.Le coût réel du travail non effectué est bien supérieur à l'absence d'une fonctionnalité ou d'une fonction dans l'incrément.Le coût inclut le gaspillage de la replanification et du retravail nécessaires lorsqu'un incrément n'est pas réellement effectué, ainsi que les coûts d'une prévisibilité inférieure et d'un risque plus élevé.

De nombreuses organisations souhaitent bénéficier des avantages de l'agilité et utilisent Scrum pour les obtenir.Fournir un incrément terminé est très difficile à effectuer avec un développement logiciel Agile.Les équipes doivent commencer par une définition de ce qui est logique pour eux, puis développer délibérément la définition dans le temps.Uniquement ensuite, ils pourront être véritablement souples.

Voir aussi

Concepts

Planification et itérations Agile

Effectuer une mise en route en tant qu'équipe

Créer un journal des travaux en souffrance ou y ajouter des éléments

Nettoyer et estimer le journal des travaux en souffrance

Exécuter une itération

Terminer une itération