La méthode Lean du Scrum

De David Starr. David Starr dirige le service de développement logiciel pour Scrum.org où il se concentre sur l'amélioration la profession de développement logiciel. Il a également fondé la communauté technique en ligne, ElegantCode.com.

Juillet 2012

Examinez les qualités Lean inhérentes au framework Scrum ainsi que différentes manières d'aider les équipes Scrum à améliorer leur utilisation du Lean Thinking.

S'applique à

Team Foundation Server

Overview

Seeing Scrum Through the Lean Lens

Toward Leaner Scrum

Conclusion

Les discussions récentes sur le développement du logiciel Agile incluent invariablement des outils Scrum, Lean et Kanban, trois outils de planification, d'analyse et d'exécution des activités de développement de logiciels. Ces outils sont souvent comparés et opposés par des adeptes d'Agile qui proclament que l'infrastructure Scrum et la méthode Lean Thinking fonctionnent bien ensemble, tandis que d'autres personnes considèrent ces outils comme des méthodes fondamentalement différentes pour fournir un logiciel.

Vue d'ensemble

Scrum est terriblement populaire. Parmi les équipes utilisant les méthodes de développement Agile, 92 % indiquent utiliser Scrum[1]. En ayant pris pour exemple le scrum réussi, de nombreuses équipes envisagent d'approfondir leur pratique au delà de l'infrastructure de scrum de base. Cet article explore l'extension de l'infrastructure Scrum avec les techniques Lean et Kanban, avec une mentalité de Kaizen, ou l'amélioration continue.

Scrum

L'infrastructure Scrum, présentée en 1995 par Ken Schwaber et Jeff Sutherland, permet aux équipes de travailler ensemble pour fournir un logiciel de manière itérative et de façon incrémentielle. Les équipes Scrum organisent le travail en tranches de temps appelés Sprints, qui durent un mois ou moins, et obtiennent un ensemble de fonctionnalités complètes et active dans chaque Sprint.

L'infrastructure Scrum est facile à comprendre. Elle est devenue très populaire auprès des équipes de développement de logiciels et auprès de leurs clients. Scrum promeut des équipes inter fonctionnelles et autonomes qui se concentrent tout au long du Sprint pour fournir un incrément de logiciel exécutable et pouvant être édité.

Scrum est codifié dans le guide de Scrum, qui documente les rôles, les artefacts, et les événements correspondants. Le guide Scrum est géré par les créateurs de Scrum. Il est disponible en ligne à l'adresse Scrum.org.

Lean

Lean Thinking permet d'approcher l'optimisation du système en se concentrant sur la réduction du gaspillage et en améliorant le flux de valeur global qui traverse un système. Lean a un riche passé dans la production et a gagné sa popularité dans des cercles de développement de logiciels ces dernières années.

Lorsqu'il est appliqué au développement de logiciels, Lean Thinking est représenté par les sept principes suivants, publiés à l'origine dans le manuel Lean Software Development: An Agile Toolkit[2].

1. Éliminez les déchets

2. Amplifier l'apprentissage

3. Décidez aussi tard que possible

4. Livrez aussi rapidement que possible

5. Autorisez l'équipe

6. Générer l'intégrité dans

7. Consultez l'intégralité

L'application de ces principes au travail permettant de fournir un logiciel n'est pas un but en soi. On ne dit pas qu'on fait du Lean mais plutôt qu'on utilise les principes Lean pour guider les prises de décision et choisir des techniques qui amélioreront l'ensemble d'un système. Par exemple, la pratique du développement piloté par test (TDD, Test-Driven Development) génère l'intégrité dans le logiciel en l'examinant au point de la création, d'où la prise en charge du concept Lean de génération d'intégrité lors du processus de création.

Kanban

Le Kanban[3] est une technique éprouvée du Lean Thinking. Elle utilise le Lean Thinking dans une méthode formelle qui se concentre sur la réduction du gaspillage, la livraison juste-à-temps et qui évite de surcharger ceux qui effectuent le travail. À la différence de Scrum, Kanban n'est pas une méthode itérative et incrémentielle ; au lieu de reposer sur des itérations, Kanban repose sur cinq activités principales.

1. Visualiser le flux de travail

2. Limiter le travail en cours (WIP)

3. Gérer le flux

4. Expliciter les stratégies de processus

5. Apportez des améliorations de manière collaborative

Les différentes équipes qui utilisent Kanban ont souvent des processus très différents. La méthode Kanban est simplement un ensemble de techniques pour gérer un processus, puis l'optimiser ensuite délibérément. Le système Kanban est facilement appliqué aux processus déjà en place, notamment le processus Scrum.

Scrum et Kaizen

Une fois que les incréments du logiciel fonctionnel sont régulièrement remis avec chaque Sprint, les équipes Scrum recherche de nouvelles façons d'améliorer leurs pratiques. Le cœur du Scrum effectif est le Kaizen, l'approche en termes d'amélioration continue. Les équipes Healthy Scrum utilisent certainement une myriade de pratiques dans leur focus sur Kaizen. Les techniques et les outils comme l'estimation relative, le développement par test initial, la génération automatisée et la programmation par paire sont adaptés au sein des équipes Scrum.

Non seulement les autres outils, techniques et pratiques fonctionnent bien pour compléter Scrum, mais il y a un modèle d'extension de Scrum décrit et géré sur le site scrum.org. Ce modèle d'extension à Scrum encourage l'investissement de la communauté dans la documentation de méthodes qui complètent Scrum et fonctionnent correctement avec l'infrastructure. Au moment de la rédaction, plusieurs extensions sont proposés pour appliquer spécifiquement les pratiques Lean dans Scrum.

Les avantages liés à l'application de la méthode Lean Thinking à Scrum sont indéniables. Comme on peut s'y attendre, de nombreux praticiens Scrum ont obtenu de meilleures performances et une meilleure qualité en appliquant la méthode Lean Thinking à leurs pratiques Scrum.

Observer le Scrum via le Lean

L'infrastructure Scrum comprend les rôles, les artefacts et les événements suivants. Si vous êtes peu familier avec l'infrastructure de base Scrum, lisez le guide relatif au Scrum avant de continuer.

Rôles	Artefacts	Événements
Propriétaire du produit Scrum Master Équipe de développement	journal des travaux en souffrance (backlog) du produit Journal des sprints en souffrance Increment	Sprint Planification du Sprint Scrum quotidienne Révision du Sprint Rétrospective du Sprint

Le guide Scrum présente des règles sur la façon dont ces composants fonctionnent ensemble, mais la méthode Lean thinking fournit une infrastructure pour optimiser davantage l'interaction entre les rôles, les artefacts et les événements Scrum. Les équipes Scrum sélectionnent un sous-ensemble du journal des travaux en souffrance (backlog) du produit pour fournir chaque sprint, et se concentrent sur la remise d'un incrément avec la qualité et la fonctionnalité appropriées. Lean Thinking peut aider à lisser le flux de travail dans le Sprint et à réduire le gaspillage du flux de valeur global.

Scrum et Lean s'efforcent de conserver une qualité supérieure nécessaire à la réussite du travail global réalisé. Pour voir les principes partagés par le développement logiciel Lean et Scrum dans l'action, il vous suffit d'analyser les rôles, les artefacts et les événements Scrum à travers l'objectif de Lean Thinking.

Événements

À l'exception du Sprint, qui est un conteneur pour tous les autres événements, les événements Scrum sont véritablement uniquement des réunions. Lean thinking considère en général les réunions comme du gaspillage, et le gaspillage doit être soigneusement éliminé.

Certains pourraient ainsi conclure que les événements Scrum sont inutiles. Toutefois, chaque événement Scrum est soigneusement conçu pour éliminer d'autres réunions qui se produiraient malgré tout de manière interrompue (ou ad hoc). Les événements Scrum bien exécutés permettent de réduire le nombre de réunions et de passer moins à gérer les interruptions non planifiées.

Chaque événement Scrum est conçu pour inspecter et adapter des éléments. L'inspection prend en charge les principes du Lean en termes d'amplification de la formation et de génération d'une intégrité dans le processus de création. L'adaptation d'un plan, d'une spécification ou d'un autre artefact pendant un événement Scrum prend en charge les principes de Lean qui visent à différer les décisions et avoir une vue globale. Le tableau suivant affiche les événements Scrum et ce qui est examiné et adapté au cours de chaque.

Événement	Examiné	Adapté
Nettoyage du journal des travaux en souffrance (backlog)	journal des travaux en souffrance (backlog) du produit	journal des travaux en souffrance (backlog) du produit
Planification du Sprint	journal des travaux en souffrance (backlog) du produit Incréments précédents	Objectif du Sprint Journal des sprints en souffrance
Scrum quotidienne	Journal des sprints en souffrance Progression vers l'objectif du Sprint	Journal des sprints en souffrance Plan quotidien
Révision du Sprint	Le dernier incrément Le dernier Sprint journal des travaux en souffrance (backlog) du produit	journal des travaux en souffrance (backlog) du produit Autres plans à long terme
Rétrospective du Sprint	Le dernier incrément Le dernier Sprint L'équipe Scrum elle-même Pratiques techniques	Comportements d'équipes Scrum Pratiques techniques Méthodes de gestion du travail utilisées dans le Scrum

Artefacts

Les artefacts Scrum sont destinés à être aussi simples que possible sans être trop simples. Les spécifications, les plans, ainsi que le logiciel fourni par une équipe Scrum sont plus utiles lorsqu'elles incluent uniquement les détails nécessaires à l'accomplissement des tâches.

journal des travaux en souffrance (backlog) du produit

Dans un monde parfait, il serait inutile de créer des spécifications au delà des personnes parlant simplement. Idéalement, la personne qui demande le logiciel est parfaitement comprise par les créateurs du logiciel et aucune expression intermédiaire de la spécification n'est requise. Bien que cela soit possible dans les équipes très petites ayant des relations proches avec leurs clients, cela n'est simplement pas adapté. La création des spécifications préalable à la fourniture des fonctionnalités est nécessaire pour la planification. Lean voit les spécifications comme un inventaire, un gaspillage courant dans Lean Thinking et donc quelque chose à réduire.

Dans Scrum, les spécifications sont gérées dans le journal des travaux en souffrance (backlog) du produit, qui prescrit un très petit formulaire ou une très petite structure. Les éléments du journal des travaux en souffrance (backlog) du produit ne doivent pas obligatoirement être très détaillés ou parfaitement exprimés.

Même si le maintien d'un journal des travaux en souffrance (backlog) du produit et ses spécifications sont nécessaires pour planifier le travail, l'utilisation parfaite consiste à créer et affiner les éléments du journal des travaux en souffrance (backlog) du produit juste avant avant que l'équipe de développement les utilisent réellement. Les équipes Scrum efficaces évitent de créer des spécifications dans le journal des travaux en souffrance (backlog) du produit qui ne feront jamais l'objet d'un traitement.

Journal des sprints en souffrance

Dans un monde parfait, il serait inutile de créer une planification. Une équipe de développement peut prendre la requête de fonctionnalité suivante dans une file d'attente, en ignorant le contexte et le coût de la spécification. Bien que ce modèle simple pour traiter le travail soit très flexible, il ne tient pas compte du fait que le développement de logiciel est un effort fondamentalement complexe. Le développement du produit de complexité significative bénéficie d'avoir un plan, même si ce plan est simple et manque de détails.

Le guide Scrum définit le journal des sprints en souffrance comme sous-ensemble des éléments du journal des travaux en souffrance (backlog) du produit sélectionnés pour un sprint, et un plan pour les fournir. Le journal des sprints en souffrance montre un inventaire (déchets) de travail projeté pour le sprint, qui est affiné au moins une fois par jour. Cet affinement quotidien garantit que le plan n'est jamais une simple promesse et permet à l'équipe de développement de différer des décisions d'implémentation jusqu'au dernier moment raisonnable.

Les équipes Scrum génèrent des spécifications et des plans qui sont à peine suffisants, pour réduire leur coût. Cette approche Lean visant à réduire l'inventaire permet une prise de décision différée et autorise l'équipe à s'organiser elle-même dans le Sprint. Plutôt que de se concentrer sur les spécifications ou le plan, les équipes de Scrum se concentrent sur la valeur fournie dans chaque incrément.

Increment

Chaque sprint inclut la livraison d'au moins un incrément de logiciel fonctionnel. L'incrément du produit est le seul artefact Scrum qui n'est pas considéré comme un déchet dans la méthode Lean Thinking. Toutefois, l'incrément du produit peut y générer des déchets. Les déchets se présentent sous la forme de fonctionnalités inutilisées, de défauts, de fonctionnalités incomplètes, de code difficile à gérer ou de conceptions mal factorisées.

Les équipes Scrum très performantes éliminent impitoyablement les déchets dans le produit lui-même. Souvent cette opération est effectuée en examinant fréquemment les incréments tout au long du Sprint et en conservant une qualité supérieure à tout moment. Cela permet de concrétiser l'essence même du principe Lean visant à inclure l'intégrité.

Les équipes Scrum ont également l'avantage de conserver les principes Lean à l'esprit en fournissant l'incrément. L'infrastructure Scrum elle-même garantit que l'incrément est ouvert pour l'inspection au moment de la révision du Sprint. Recevoir des commentaires sur l'incrément au moment de la révision du Sprint est fondamental pour développer l'apprentissage.

Rôles

Les rôles prescrits par Scrum sont soigneusement équilibrés pour attribuer des pouvoirs à l'équipe Scrum et équilibrer les tensions dans l'équipe. Les Scrum Masters, les équipes de développement, et les propriétaires de produits travaillent en collaboration pour réussir, ce qui requiert que chacun s'implique pour consulter les perspectives des autres. Cette collaboration garantit que les membres de l'équipe Scrum consultent l'ensemble du système Scrum et rend transparent toutes les décisions qui sous-optimiseraient l'équipe Scrum en favorisant un rôle par rapport aux autres.

Le co-créateur de Scrum, Jeff Sutherland, indique que la base d'une implémentation Lean réussie est l'intelligence descendante, des utilisateurs en mesure de prendre des décisions et cela facilité par des gestionnaires. Les équipes de développement autonomes Scrum incarnent les employés habilités par la méthode Lean Thinking et qui peuvent apprendre au sein de l'organisation plutôt que d'avoir leur comportement dicté.

Le rôle de ScrumMaster est unique à Scrum. Il est décrit dans le guide Scrum comme suit :

Le Scrum Master est chargé de vérifier que Scrum est compris et mis en œuvre correctement. Les Scrum Masters effectuent cela en vérifiant que l'équipe Scrum adhère à la théorie, aux pratiques et aux règles de Scrum. Le Scrum Master est le leader de l'équipe Scrum.Guide Scrum, octobre 2011

L'une des compétences et activités principales des bons Scrum Masters est la facilitation. Dans la plupart des cas, les Scrum Masters facilitent les événements Scrum. Les Scrum Masters sont des directeurs (en dépit de l'adoption et de l'adhésion au Scrum) et non des employés.

Vers un Scrum plus léger

Utiliser Lean Thinking pour prendre en compte et corriger les problèmes exposés par Scrum produit souvent des retours élevés et est un bon moyen de privilégier la culture Kaizen. Les équipes Scrum apprennent encore à appliquer Lean au Scrum, mais de nombreuses méthodes deviennent populaires car elles s'avèrent rendre les équipes Scrum plus efficaces.

De nombreuses méthodes et techniques courantes sont utilisées dans le travail intellectuel qui soutient directement les principes Lean. Plusieurs de ces techniques sont explorées ci-dessous avec un œil vers la façon dont elles peuvent être complétées dans une équipe Scrum.

Ce qui suit n'est certainement pas une liste exhaustive de techniques, mais simplement des exemples de la façon dont certaines équipes Scrum peuvent mieux utiliser les techniques communes aux praticiens Lean. De plus, chaque technique peut être appliquée de plusieurs façons. Seules quelques techniques du Lean sont décrites ici. Les équipes Scrum peuvent avoir une approche différente des scénarios suivants de celle décrite dans ce document.

Élimination des déchets

La pratique de Lean la plus importante est peut-être l'élimination du gaspillage. Lean considère comme du gaspillage tout ce qui n'est pas strictement nécessaire à l'obtention du résultat voulu. Parmi les gaspillages courants dans le développement logiciel, citons :

1. Code ou fonctionnalités non utilisés

2. Erreurs qui requièrent un retravail

3. Délai ou temps écoulé à attendre un événement

4. Transferts d'une personne, équipe ou processus d'entreprise à un autre

5. Spécifications très détaillées

6. Spécifications insuffisantes

7. Communication lente ou médiocre

Certains gaspillages ne peuvent pas être évités et sont même nécessaires. Dans la définition la plus stricte, par exemple, les documents de spécification sont du gaspillage. Fiche représentant une spécification qui en fait n'est pas fournie au client. Cette fiche est donc un déchet. La carte de spécifications ne constitue pas les fonctionnalités de produit. Elle représente le travail qui doit être exécuté pour créer la fonctionnalité. La carte de spécifications est destinée à aider les développeurs à considérer tous les aspects de leur travail et à en effectuer le suivi. Alors que la plupart des équipes la voient comme une pratique nécessaire, elle est facilement identifiée comme une perte de temps.

Alors que certains déchets sont nécessaires, une grande partie d'entre eux peut être réduite, optimisée, voire supprimée. Certains gaspillages dans le flux de valeur de développement de logiciels (comme l'attente trop longue pour signer le code) sont facilement identifiés et éliminés. Un autre gaspillage constaté dans les équipes de développement de logiciels (comme la création de documents volumineux concernant les besoins avant le début du développement) est considéré comme culture et a besoin de beaucoup d'effort et de temps pour changer fondamentalement.

Scénario

Scrum est en place pour six mois. Les équipes de développement produisent des incréments de travail de logiciel avec chaque Sprint de deux semaines et tous les indicateurs de qualité mesurés ayant des tendances positives.

Méthode Lean

Les Scrum Masters se concertent afin que leurs équipes atteignent une productivité et une qualité plus élevées. Un Scrum Master propose d'éliminer les déchets comme indiqué dans la méthode Lean Thinking. Acceptant de tester l'idée, les Scrum Masters recherchent des exemples de déchets et les classent en deux listes : ceux qui peuvent être éliminés immédiatement et ceux nécessitant un temps de gestion.

La première liste contient le gaspillage à éliminer soit par les Scrum Masters eux-mêmes soit par les équipes de développement et ne requiert aucune autorisation ou attente. L'autre est étiqueté « Journal des déchets » et identifie les déchets dont tout le monde est conscient, mais pour lesquels un effort significatif et du temps afin de les modifier. Les exemples des deux listes sont affichés ci-dessous :

À traiter immédiatement

Journal des déchets

Certaines builds sont exécutées manuellement sur un ordinateur de build qui doit être mis à jour spécialement à cet effet. L'empaquetage de site Web est un processus ZIP manuel. Automatiser ceci. Les développeurs utilisent tous une base de données de développement partagée et les modifications appliquées aux données sont fréquemment un flux de développement d'interruption. Accédez à un modèle où chaque développeur a une base de données de développement dédiée. Les tests ne sont pas écrits tant qu'une fonctionnalité n'existe pas. Encouragez et enseignez les premiers tests pratiques dédiés aux spécialistes de tests.

Modèles UML créés avant le codage pour toutes les fonctionnalités. Communication empêchée par l'aménagement des bureaux qui impose aux membres de la même équipe de développement de passer d'un bureau à l'autre pour des discussions spéciales. Introduisez des programmes d'installation lorsque cela est possible afin que ce déploiement ne soit pas manuel dans les opérations. De nombreux champs du système de rapports de traçage de bogues sont obligatoires et rarement utilisés. En les rendant facultatifs, vous économisez le temps de création des données.

Avec ces listes, les ScrumMasters proposent à leurs équipes respectives des suggestions qui peuvent faire l'objet d'une action pour des améliorations immédiates. Bien que les Scrum Masters orientent leurs équipes vers des niveaux de qualité plus élevés, la nature autonome des équipes Scrum nécessite que les équipes elles-mêmes évaluent les modifications et créent un plan pour les décréter.

Le forum de rétrospective Sprint permet de partager des idées d'amélioration et de prise en charge. Les rétrospectives de sprint pertinentes ont souvent produit des plans pour décréter des améliorations, qui prennent en charge une culture Kaizen. L'élimination ou l'amélioration des déchets suivis dans le journal des travaux en souffrance (backlog) peut nécessiter un travail en dehors de l'équipe Scrum. C'est la responsabilité du Scrum Master, qui est notamment chargé d'améliorer l'utilisation de Scrum et d'encourager la souplesse à travers la société.

Limitation des travaux en cours

Scénario

Une équipe de développement composée de cinq membres a utilisé Scrum pendant 12 semaines, en effectuant trois Sprints de quatre semaines avec des résultats mitigés. Alors que les Increments produits possèdent une qualité plus élevée que le logiciel créé avant d'implémenter le Scrum, il semble que moins de travail soit effectué et que les membres de l'équipe de développement ne travaillent toujours pas de manière collaborative. Le Scrum quotidien fournit un rappel quotidien que chaque membre de l'équipe travaille de manière isolée sur ses propres tâches, même si la situation ne semble pas s'améliorer.

Pendant la planification de sprint, l'équipe de développement crée la liste des tâches « À faire » relatives au travail requis pour fournir chaque élément du journal des travaux en souffrance (backlog) du produit (PBI, Product Backlog Item) sélectionné pour le sprint. Cette technique crée un journal des sprints en souffrance pendant la planification de Sprint et un mécanisme pour suivre la progression de l'équipe de développement tout au long du Sprint.

L'équipe de développement utilise un tableau de tâches visible sur le mur dans la zone de travail de l'équipe de développement pour suivre sa progression dans tout le Sprint. Au cours du dernier sprint, le Scrum Master a pris des photos tous les jours du panneau avant le Scrum journalier. Certaines photos sont affichées ci-dessous.

Jour 1	Jour 4
Jour 9	Jour 14
Jour 17	Jour 20

Le Scrum Master a communiqué ces photos à l'équipe de développement. Certaines opérations étaient assez évidentes, par exemple :

• Normalement, le nombre de tâches en cours est supérieur au nombre de membres de l'équipe de développement.

• Le jour deux, un développeur a extrait toutes les tâches pour la fonctionnalité C à l'état « En cours » et les a laissées là pour la durée du Sprint.

• La fonctionnalité B n'a fonctionné qu'à la fin du sprint mais n'a pas atteint son terme.

• La fonctionnalité C a fonctionné tout au long du sprint mais n'a pas atteint son terme. Le développeur travaillant sur la fonctionnalité C a manqué d'aide lorsque des problèmes peu courants ont surgi. En dépit de son allusion subtile dans le Daily Scrums qu'elle apprécierait de l'aide, il n'y a jamais eu de matérialisation car d'autres membres de l'équipe étaient concentrés sur leur propre travail et ne se sentaient pas concernés par la fonctionnalité C.

• Les fonctionnalités ont été définies dans le journal des sprints en souffrance par ordre de priorité au cours de la planification de sprint et le propriétaire du produit a été extrêmement déçu que la fonctionnalité B n'ait pas abouti à son terme lors du sprint, car son ordre de priorité était plus élevé que les autres fonctionnalités fournies.

• Plusieurs fonctionnalités étaient en cours à la fois, provoquant la modification de parties très différentes du code simultanément. Pendant le sprint, la procédure a mené à plusieurs échecs et au retravail de build du fait que les développeurs ont exécuté sans le savoir chaque code.

Toutes ces observations renvoient à la pratique de l'équipe de développement consistant à travailler sur plusieurs choses en même temps. Le fait de basculer l'attention entre les tâches et essayer de se concentrer sur de nombreux éléments simultanément a fait que les membres de l'équipe de développement se sont sentis surchargés et accablés par le travail dans le journal des sprints en souffrance. Par conséquent, chaque membre de l'équipe s'est concentré sur son propre travail et a agi comme une personne plutôt que comme un membre d'une équipe.

Méthode Lean

Pendant la rétrospective du sprint, le Scrum Master a explicité l'idée de limiter le WIP à l'équipe de développement qui a décidé d'essayer la technique. L'équipe de développement a décidé d'implémenter trois nouvelles règles conçues pour réduire le WIP dans le Sprint suivant :

1. Les fonctionnalités du Journal des sprints en souffrance sont implémentées dans l'ordre de haut en bas.

2. 3 éléments au plus peuvent être en cours en même temps. Si un quatrième élément est en cours de progression, l'équipe interrompra son activité pour déterminer pourquoi il existe un goulot d'étranglement dans le système.

Le Scrum Master a pris de nouvelles photos pendant le sprint suivant. Plusieurs photos sont représentées ci-dessous.

Jour 2	Jour 8
Jour 12	Jour 20

Lors de la rétrospective du sprint, les photos ont encore été partagées avec l'équipe de développement qui a effectué les observations suivantes sur la modification des éléments lors du dernier sprint :

1. Les membres de l'équipe de développement ont travaillé ensemble sur plusieurs éléments complexes. Bien que les opinions diffèrent parfois sur la façon dont le travail doit être effectué, les différences ont été résolues et l'équipe a réalisé une progression globale rapide.

2. Les membres de l'équipe de développement ont commencé par en savoir plus sur les fonctionnalités du produit sur lesquelles ils ne s'étaient pas déjà concentrés. Chacun a fait part d'un sentiment de propriété collective pour le produit dans son ensemble. Ce fut un réel soulagement par rapport aux méthodes précédentes, lors desquelles chacun se concentrait uniquement sur les fonctionnalités qu'il avait compris.

3. La complexité de coordonner des modifications dans de nombreuses zones du code immédiatement a été considérablement réduite. Si bien que, la productivité de l'équipe de développement a considérablement augmenté.

4. Bien que la fonctionnalité E n'a pas été terminée dans le sprint, toutes les fonctionnalités fournies avaient une priorité plus élevée que la fonctionnalité E. Le propriétaire du produit était ravi et a décidé de transmettre l'incrément au client même sans cette fonctionnalité de priorité basse.

Bien que la création d'un journal des sprints en souffrance pendant la planification de sprint limite la taille de lot du travail sélectionnée pour le sprint, une nouvelle limitation de WIP dans le sprint peut aboutir à un débit plus rapide et à une plus grande productivité. Limiter le travail en cours pendant le Sprint augmente également la collaboration et réduit le risque d'avoir des spécialistes techniques dont le travail n'est pas compris par les autres.

Réduire les temps d'attente

Beaucoup de temps est consacré à attendre que les choses se passent dans le développement logiciel. Cette forme de déchets existe dans la plupart des équipes de développement. Les nouvelles équipes Scrum se trouvent en attente pour de nombreuses opérations pendant un Sprint, notamment :

• Autorisation d'effectuer une opération

• Long processus à terminer

• Transfert d'une autre équipe ou personne

• Tests à exécuter ou validation à exécuter

• Accéder à une ressource requise

• Coopération d'une personne à l'extérieur de l'équipe

Pire que les inefficacités d'attendre les équipes de Scrum, le temps que les clients et les entreprises passent à attendre l'intégration du logiciel, son conditionnement et son envoi. Ce problème s'intensifie à mesure que l'organisation de développement croît. Au fur et à mesure que des développeurs ou des équipes sont ajoutés à un projet, le coût d'intégration de leur travail dans un produit unique augmente.

Le plus long temps d'attente intégré dans Scrum est le Sprint. Être le conteneur pour tous les événements Scrum, la seule spécification de la durée du sprint étant un mois ou moins. Cela limite à un mois le temps d'attente d'un incrément de travail. La plupart des équipes Scrum fournissent des incréments de travail même plus fréquemment.

Scénario

Une société a six équipes Scrum qui travaillent sur un gros produit logiciel complexe. Chaque équipe Scrum se concentre sur une zone de fonctionnalité spécifique et un travail est coordonné via un journal des travaux en souffrance (backlog) du produit principal. Les Sprints durent trois semaines et incluent l'intégration du travail de toutes les équipes de développement.

Auparavant, les Sprints duraient deux semaines, mais au fur et à mesure du développement du produit, la complexité de la création a également augmenté. De nouvelles équipes Scrum ont été ajoutées qui ont eu besoin de plus de temps pour intégrer leur travail, de sorte que la longueur des sprints a été augmentée pour accueillir les activités d'intégration.

La semaine trois est maintenant appelée familièrement semaine d'intégration. L'intégration de nouvelles fonctionnalités dans la ligne de code principale est l'activité principale pendant la procédure. Une équipe d'intégration est mise en place chaque semaine d'intégration avec des représentants de chaque équipe de développement. Ils dirigent le travail des activités d'intégration.

L'équipe d'intégration n'accepte pas de nouvelles fonctionnalités au cours de la semaine d'intégration, même si elle demande de petites modifications pour répondre aux problèmes d'intégration. Cela entraîne un déferlement de modifications du code pendant la semaine d'intégration, en réponse aux besoins de l'équipe d'intégration.

Le graphique suivant illustre la gestion de la configuration standard pendant un Sprint. Les équipes de développement créent leurs propres branches de développement au début de chaque Sprint. Elles fusionnent leur code à la fin de la deuxième semaine. Pendant la semaine 3, les équipes de développement traitent les demandes de l'équipe d'intégration, si nécessaire.

Même si l'intégration au cours du Sprint est nécessaire, un tiers de la capacité des six équipes Scrum est actuellement utilisé pour obtenir l'intégration. Pendant ce temps, une grande partie de la capacité des équipes est répartie en activités en dehors du sprint. Notez que dans l'exemple ci-dessus, l'équipe 5 n'avait aucun travail pendant la semaine d'intégration.

Ce qui augmente le coût de la semaine d'intégration est l'interruption du flux dans les équipes Scrum qui doivent souvent changer le contexte. Certaines équipes, en privé, branchent et répliquent des lignes de code afin de rester productives tout au long de la semaine, augmentant ainsi la complexité globale et modifiant considérablement la transparence requise pour prendre de bonnes décisions.

Méthode Lean

Les Scrum Masters des équipes se rencontrent pour se mettre d'accord. Un Scrum Master indique que son équipe a très bien réussi à limiter le travail en cours pendant les deux premières semaines de chaque Sprint. Les Scrum Masters savent que si chaque équipe limite le travail en cours à une fonctionnalité à la fois, elle est susceptible d'intégrer son travail à mesure que chaque fonctionnalité est terminée.

Si cette pratique était utilisée par toutes les équipes de développement, aucune équipe n'attendrait jusqu'à la fin de la semaine deux pour intégrer son travail. Au lieu d'attendre l'intégration de nouvelles fonctionnalités, chaque équipe peut désormais penser à effectuer une intégration dans la partie de ligne de code principale de la définition de Done1 pour chaque fonctionnalité sur laquelle elle travaille.

La définition du mot Terminé est un concept de Scrum dans lequel les équipes de développement s'accordent sur ce qui doit se vérifier pour chaque élément du journal des travaux en souffrance (backlog) du produit sélectionné pour le Sprint afin de considérer cet élément comme « terminé ». Pour plus d'informations sur la définition du mot « Terminé », consultez l'article MSDN Terminé et non terminé.

Au cours des rétrospectives de sprint suivantes, les équipes de développement s'accordent à tenter d'intégrer leur travail à mesure que chaque fonctionnalité est terminée. Ils établissent et s'engagent à respecter les règles nouvelles suivantes :

1. Chaque équipe de développement limite le WIP à une fonctionnalité à la fois.

2. Une fonctionnalité n'est pas terminée tant qu'elle n'est pas intégrée dans la ligne de code principale.

3. Avant de commencer à travailler sur une nouvelle fonctionnalité, les équipes de développement mettent à jour leurs lignes de code avec une copie à jour de leur ligne principale.

L'activité qui en résulte est représentée dans le graphique suivant :

Les nouvelles règles ont permis aux équipes de livrer les fonctionnalités de façon plus douce. Les équipes de développement ne sont plus contraintes de rester inactives et perturbées pendant la semaine 3 du Sprint car il n'existe aucune semaine d'intégration.

Dans un premier temps, le temps nécessaire pour intégrer des modifications pendant le sprint est important. À mesure que le modèle d'intégration continue devient plus familier, la productivité de chaque équipe de développement augmente. Avec le temps, les fonctionnalités ajoutées par Sprint augmentent.

Étant donné qu'une fonction est réalisée lorsqu'elle est intégrée dans la ligne de code principal, la question ne se pose plus de savoir si une fonctionnalité est réellement effectuée. La définition du mot Terminé inclut désormais l'intégration au code principal pour chaque fonctionnalité individuelle. Le risque d'échec d'intégration est diminue considérablement.

Enfin, la décision de réduire le temps qu'une équipe de développement doit attendre pour intégrer le code a permis d'accroître l'efficacité globale des équipes de développement et rendu la semaine d'intégration obsolète. Les équipes Scrum peuvent revenir à des sprints plus courts, ce qui permet au propriétaire de produit de distribuer plus souvent, selon les besoins.

Différer l'engagement

Différer l'engagement est l'un des principes Lean d'origine exprimés sous la forme d'une valeur de développement logiciel Lean. Ce principe est souvent décrit comme « attendre jusqu'au dernier moment raisonnable » pour prendre une décision.

On pense généralement qu'il y a peu d'intérêt, ou même aucun, à prendre une décision qui engage de façon prématurée une personne pour un plan d'action. Pourquoi ne pas attendre que la décision doive être prise, afin que le plus d'informations possibles sur le problème soient connues ? Cela limite le risque de prendre la mauvaise décision et permet d'obtenir plus de choix ou de possibilités d'actions.

Scénario

Pendant la planification de sprint, l'équipe de développement crée des plans détaillés pour l'implémentation du PBI sélectionné pour le sprint. Souvent, le plan change pendant le sprint car d'autres informations sont apprises. Ils remarquent que lorsque le travail attendu est plus vague, le plan évolue encore plus. Sachant que les spécifications inutilisées sont gaspillées, l'équipe souhaite éviter ces modifications de planification.

La validation d'un plan d'action requiert la suppression d'autres options. Cela amène souvent les personnes averties de l'engagement à abandonner des idées. Une fonction donnée peut être implémentée de différentes façons, mais lorsqu'un plan d'action a déjà été choisi, les développeurs peuvent cesser de réfléchir à d'autres manières de gérer un problème et le potentiel d'innovation décline.

Méthode Lean

L'équipe de développement décide d'autoriser des éléments plus larges et moins définis dans le journal des sprints en souffrance. En fait, il est déterminé qu'un élément de journal des travaux en souffrance (backlog) du produit peut être envoyé dans le sprint sans plan détaillé du tout.

L'équipe de développement attend désormais pour créer le plan détaillé plus tard lorsqu'elle aura plus d'informations. Pour eux, cela signifie segmenter le grand élément de journal des sprints en souffrance en plus petites parties lorsque le travail est réellement en démarrage ou en cours. La planification détaillée est ainsi différée jusqu'à ce qu'elle soit réellement nécessaire, ce qui permet à l'équipe de changer d'avis à propos de l'implémentation à un moment plus proche du point de travail. Cela permet également d'utiliser le meilleur plan possible au lieu au lieu d'exécuter un plan qui peut ne plus être valide.

Cela entraîne une meilleure compréhension des options d'implémentation au moment d'implémenter les fonctionnalités. L'équipe de développement en a découvert plus sur le produit pendant la durée d'implémentation des tâches précédentes du Sprint, et a laissé du temps pour les recherches si nécessaire.

Visualisation du flux de travail

La première étape de la méthode Kanban requiert de visualiser le flux de travail réel utilisé par une équipe. Le principe Lean qui consiste à « voir l'ensemble » est ainsi concrétisé. Cela implique que le flux de travail réel soit affiché, et non pas une version idéalisée demandée dans un document de processus d'entreprise ou un autre modèle préexistant. Une visualisation utile représente ce qui se passe réellement.

Lorsque la visualisation existe, le travail peut être suivi dans celle-ci. Un exemple de modèle d'un processus de développement classique à étapes ou de type Waterfall est illustré ci-dessous avec plusieurs fonctionnalités en cours.

Les équipes Scrum utilisent la visualisation de flux de travail depuis des années pour afficher les tâches du Sprint. La forme la plus répandue pour la visualisation du flux de travail dans les équipes de développement Scrum est le « Tableau de tâches » Scrum ou simplement « Tableau Scrum ». Cette visualisation est généralement plus simple que le modèle ci-dessus et peut ressembler au modèle suivant.

Cette forme standard de visualisation de flux de travail est fortement influencée par la prescription Scrum des équipes de développement interfonctionnelles. Le focus sur les équipes de développement interfonctionnel est une caractéristique de définition de l'infrastructure Scrum. Une équipe interfonctionnelle dispose de toutes les compétences dont elle a besoin pour fournir un incrément complet de logiciel fonctionnel dans chaque Sprint. Les membres de l'équipe ont de nombreuses activités de développement de logiciels en même temps.

Les équipes interfonctionnelles touchent à tout à mesure qu'ils implémentent ensemble une fonctionnalité. C'est très différent du modèle axé sur le plan, dans lequel les spécialistes se concentrent sur une seule activité à la fois. De plus, les membres des équipes interfonctionnelles peuvent avoir des spécialités, mais tous les membres de l'équipe travaillent régulièrement sur toutes les activités requises pour fournir le logiciel, que les activités entrent ou non dans les compétences de la personne. Les équipes de développement de logiciels interfonctionnelles ont tendance à surpasser les équipes de spécialistes dédiés.

Scénario

Une équipe de développement fournit des incréments de logiciel fonctionnel, mais la collaboration entre les membres de l'équipe ne se déroule pas correctement. Les codeurs travaillent sur les problèmes de manière isolée avant de transférer le code aux testeurs qui doivent se dépêcher de le valider vers la fin du sprint.

Cela laisse peu de temps pour les tests à la fin du Sprint, c'est pourquoi l'équipe de développement ignore parfois cette étape et fournit l'incrément avec des tests de régression incomplets. Les erreurs sont détectées en production et auraient pu l'être avant que le test de régression fonctionnel ne soit autorisé à se terminer.

Méthode Lean

Le Scrum Master travaille avec l'équipe de développement pour modéliser le flux de travail réel qui se produit dans chaque sprint. Bien que l'équipe utilise un panneau Scrum classique dans le Scrum quotidien, il devient bientôt évident que le flux de travail réel est un processus à étapes déclenché. L'équipe produit le modèle suivant pour refléter son flux de travail réel :

Le Scrum Master aide l'équipe à comprendre l'augmentation potentielle de la productivité obtenue grâce à un travail interfonctionnel. Bien que sceptiques, les membres de l'équipe acceptent d'essayer améliorer leur flux de travail pour le rendre plus interfonctionnel.

L'équipe de développement laisse la visualisation intacte et l'utilise pour surveiller le travail dans le Sprint, mais accepte de veiller à chaque possibilité de réduire les étapes. Autrement dit, l'équipe recherche des possibilités où deux étapes peuvent être combinées en une seule, remplaçant ainsi un transfert par la collaboration. Tout cela est progressif : des modifications délibérées permettent aux personnes de l'équipe de développement de travailler ensemble. À chaque réunion de rétrospective sprint, ils révisent le modèle en fonction des améliorations apportées par l'équipe.

D'abord, Arnie et Kyle acceptent de collaborer sur la fusion de la conception et des phases de codage. Ils essaient plusieurs techniques pour améliorer la collaboration et se rendent compte rapidement que leur flux de travail a été modifié comme suit :

Cette équipe de développement apprend rapidement à créer des tests de régression fonctionnels qui échouent avant l'implémentation du code, ce qui entraîne les modifications suivantes :

Au cours des mois suivants, l'équipe de développement va rechercher des possibilités pour réduire le nombre d'étapes dans le pipeline de livraison. La culture de l'équipe change en fait lorsque des spécialistes partagent leurs connaissances et que tout le monde participe pour faciliter la circulation du flux de travail au sein de l'équipe. Les membres de l'équipe se considèrent eux-mêmes comme « généralistes en cours de spécialisation » au fur et à mesure de la collaboration.

À mesure que la collaboration au sein de l'équipe augmente, les connaissances collectives sur le logiciel en cours de développement et les analyses des membres de l'équipe dans les responsabilités respectives s'améliorent. Cette collaboration réduit naturellement les étapes du travail pendant le Sprint et est reflétée dans une visualisation plus simple du flux de travail qui se produit dans le Sprint. L'équipe de développement est maintenant interfonctionnelle et affiche son flux de travail réel en conséquence comme indiqué ci-dessous.

La réflexion itérative de l'équipe concernant l'élimination d'étapes du processus a finalement abouti au flux de travail prescrit par Scrum en premier lieu, soit une seule phase de développement en cours. Cela indique de quelle manière un panneau Kanban entièrement optimisé est finalement affiché en tant que panneau Scrum traditionnel.

Génération d'une intégrité

De nombreuses techniques de spécialistes des logiciels se concentrent sur la génération d'une intégrité dans le processus de création. Les modèles de conception de logiciels, les techniques de développement par test initial, la refactorisation et la programmation par paires : tous ces éléments cherchent à améliorer la qualité du logiciel lors de sa création. L'utilisation de techniques qui augmentent la qualité dans les premières étapes du processus de création garantit que les équipes ne comptent pas sur un contrôle qualité après coup pour « tester la qualité a posteriori ».

Scénario

Une équipe de développement a expérimenté les techniques de développement par test initial et utilise avec succès l'expression Given/When/Then des critères d'acceptation dans les tests unitaires créés par les développeurs pendant le développement.

Format des critères d'acceptation Given/When/Then
<contexte initial> donné Lorsque <some action occurs> Ensuite, <voici le résultat>

L'équipe dispose de bonnes suites de tests unitaires lisibles dont dépendent les développeurs pour guider la conception et tester fréquemment le code avec un atelier de test automatisé.

Bien que cette approche fonctionne au niveau du test unitaire, les spécialistes de test de l'équipe de développement utilisent toujours des documents Microsoft Word pour créer les critères d'acceptation du test fonctionnel. Ils sont validés manuellement après que les fonctionnalités sont encodées et terminées. Comme ces tests ne sont pas exécutées jusqu'à ce que les codeurs détectent qu'une fonctionnalité a été réalisée, un nombre important d'erreurs sont identifiés par les testeurs. Cela engendre des reprises pendant le Sprint et conduit parfois à l'inachèvement des fonctionnalités avant la révision du Sprint.

Méthode Lean

En traitant le flux de travail des critères d'acceptation à la rétrospective Sprint, l'équipe de développement décide d'essayer ce qui suit :

1. Les spécialistes des tests ne créent pas les critères d'acceptation en tant que documents Microsoft Word, mais en tant que tests automatisés qui échouent et qui ne sont pas implémentés en interne.

2. Les nouveaux tests automatisés s'exécuteront tous les jours, à 5 h et à 15 h, produisant un rapport des réussites et des échecs de test. Les tests nouvellement créés échouent toujours.

3. Lorsque les codeurs sélectionnent une nouvelle fonctionnalité sur laquelle travailler, ils commencent par implémenter la fonctionnalité du test d'acceptation ayant fait l'objet d'une opération stub.

4. Le test peut être affiné par l'auteur du code, mais cela doit être fait en collaboration avec le spécialiste de test qui l'a créé, afin que l'objectif d'origine soit préservé.

5. La fonctionnalité n'est pas terminée tant que le test n'est pas réussi.

6. Tous les tests doivent réussir d'ici la fin du sprint.

Après quelques Sprints à l'aide de cette technique, les défauts et les modifications ont diminué. L'équipe de développement surveille le rapport mis à jour par les séries de tests automatisés deux fois par jour et réalise que le passage et l'échec des tests peuvent être affichés sous forme de tendance. L'équipe crée un rapport qui est mis à jour lors de chaque série de tests automatisés. Les rapport indique les tendances des résultats de réussite et d'échec du test d'acceptation au cours du Sprint qui a duré deux semaines. Le graphique est illustré ci-dessous.

L'équipe de développement découvre qu'il est largement préférable d'examiner ce rapport lors de leur scrum quotidien que le graphique typique d'avancement. Le Scrum Master confirme que ce nouveau graphique peut agir comme un élément crucial du journal des sprints en souffrance.

Le guide Scrum spécifie que le journal des sprints en souffrance est l'ensemble des éléments du journal des travaux en souffrance (backlog) du produit sélectionnés pour le Sprint, ainsi qu'un plan pour les fournir. Pour cette équipe de développement, le plan est maintenant construit à partir de l'échec des tests d'acceptation et la progression de l'achèvement est suivi sur la base du nombre de réussites et d'échecs de tests. Comme pour l'utilisation des tâches dans le journal des sprints en souffrance, des tests peuvent être ajoutés, supprimés ou modifiés dans le Sprint. La création d'un test donné mène souvent à l'implémentation de la fonctionnalité correspondante d'autant de jours.

L'utilisation des tests automatisés réels comme spécifications et mécanisme de régression fonctionnelle signifie que les tests sont les spécifications. Cela permet également d'afficher les zones du Sprint comme une progression de la réussite des tests automatisés. Cette technique de développement par test initial a redéfini la façon dont l'équipe pense à utiliser Scrum et injecte la validation de spécification dans le processus de création lui-même, ce qui génère une intégrité dans le produit.

De nombreux aspects du très populaire Scrum Framework prennent en charge les principes Lean. Au fur et à mesure que les équipes Scrum murissent et s'améliorent, elles reconnaissent souvent que l'outil Lean Thinking est efficace pour trouver davantage de valeur dans le développement itératif et incrémentiel.

Alors que des techniques spécifiques peuvent arriver et disparaître, un soin permanent apporté à l'amélioration est primordial pour le maintien d'équipes de développement de logiciels efficaces. L'infrastructure Scrum est assez flexible pour appliquer les méthodes d'amélioration Lean comme celles de la méthode Kanban. L'affichage de Scrum d'affichage à travers l'objectif de Lean Thinking offre souvent une meilleure qualité, une productivité supérieure et un gaspillage plus restreint.

Optimiser délibérément l'implémentation d'une équipe de Scrum peut être délicat. Lorsque vous cherchez à effectuer des améliorations, n'oubliez pas que le mieux peut être l'ennemi du bien. La perfection du Scrum est beaucoup moins importante que de fournir un logiciel fonctionnel de qualité ayant de la valeur pour les clients. Concentrez-vous d'abord sur les éléments qui améliorent vraiment le produit.

Références

1. Occidental, D. (2011). XXXXX. Forrester Research

2. Poppendieck, M. P. (2003). Le développement logiciel Lean : un ensemble d'outils Agile. Addison-Wesley Professional.

3. Anderson, D. (2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press.