Le plan de gestion de projet, partie 1 : une comparaison complète de Agile, Scrum, Kanban et Lean

Aperçu

De nombreuses méthodologies sont utilisées aujourd'hui dans le développement de logiciels. Vous avez peut-être entendu des mots à la mode tels que Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming, etc.

Dans cet article, je définirai ces termes, expliquerai comment ils sont liés les uns aux autres et comment ils diffèrent les uns des autres. Bon nombre des mots à la mode susmentionnés sont basés sur des concepts de Lean Manufacturing, qui était à l'origine basé sur le Toyota Manufacturing System (TPS), nous en parlerons donc d'abord.

Méthodologie Lean

Origines du Lean et du Lean Manufacturing

Le terme « Lean » a ses origines dans la fabrication où il a été inventé pour décrire un modèle de fabrication basé sur le système de production Toyota (TPS) développé à l'origine par Sakichi Toyoda, Kiichiro Toyoda et Taiichi Ohno, inspirés à l'origine par Henry Ford. TPS s'est concentré sur la philosophie de "l'élimination complète de tous les déchets" et a révolutionné la fabrication dans les années 1950 à 1970. TPS est devenu connu sous le nom de "Lean Manufacturing" en 1990 lorsque "La machine qui a changé le monde" a été publié.

TPS a identifié trois grands types de déchets chez Toyota :

• Muda : traduit par « déchets ». Il y avait sept types de muda identifiés chez Toyota et un huitième a été ajouté plus tard. Ceux-ci sont:
  • Défauts : effort nécessaire pour trouver et corriger les défauts
  • Surproduction : production en avance sur la demande
  • Attente : attente de la prochaine étape de production, interruptions, etc.
  • Talent non utilisé : capacités sous-utilisées, formation inadéquate, etc.
  • Transport : pièces mobiles ou produits qui ne sont pas nécessaires au traitement
  • Inventaires : inventaire fini et travaux en cours
  • Mouvement : bouger ou marcher plus que ce qui est nécessaire pour le traitement

  • Traitement excessif : d'un mauvais outillage ou d'une mauvaise conception du produit

• Muri : traduit par « mort-terrain ». Muri résulte généralement de mura mais peut résulter de muda. Muri se manifeste par des pannes, de l'absentéisme, des problèmes de sécurité, etc.
• Mura : traduit par « irrégularité ». Mura peut être trouvé dans la fluctuation de la demande des clients, les temps de traitement par produit ou la variation des temps de cycle pour différents opérateurs. Lorsque mura n'est pas réduit, on augmente la possibilité de muri et, par conséquent, de muda. Mura peut être réduit en créant une ouverture dans la chaîne d'approvisionnement, en modifiant la conception des produits et en créant un travail standard pour tous les opérateurs.

TPS s'est efforcé d'éliminer les déchets en appliquant ces deux concepts fondamentaux :

• Jidoka : librement traduit par « l'automatisation avec une touche humaine » stipule que « la qualité doit être intégrée au cours du processus de fabrication ! » ce qui signifie que lorsqu'un problème survient, l'équipement s'arrête immédiatement, empêchant la production de produits défectueux.
• Juste-à-temps : produire uniquement "ce qui est nécessaire, quand il le faut et dans la quantité nécessaire".

Au fur et à mesure de l'évolution de TPS, ces piliers et valeurs fondamentaux se sont appuyés sur les concepts de Jidoka et de JIT et se sont enracinés :

• Amélioration continue:
  • Défi : former une vision à long terme et relever les défis avec courage et créativité pour réaliser des rêves
  • Kaizen : amélioration continue des opérations commerciales, toujours à la recherche d'innovation et d'évolution, éliminant un muda à la fois
  • Genchi Genbutsu : pratiquer le genchi genbutsu, aller à la source pour trouver les faits pour prendre les bonnes décisions, établir un consensus et atteindre les objectifs à notre meilleure vitesse
• Respect des personnes :
  • Respect : respecter les autres et s'efforcer de se comprendre, prendre ses responsabilités et faire de son mieux pour instaurer une confiance mutuelle
  • Travail d'équipe : stimuler la croissance personnelle et professionnelle, partager les opportunités de développement et maximiser les performances individuelles et d'équipe
• Andon : un indicateur visuel d'état ou de problème
• Heijunka : signifie nivellement ou nivellement de la production
• Hansei : signifie réflexion sur soi. Pour améliorer l'efficacité, les travailleurs doivent remettre en question les hypothèses sous-jacentes aux processus actuels pour en trouver de meilleures.
• Kanban : une enseigne utilisée comme outil visuel pour contrôler la production
• Poka-yoke : également appelé anti-erreur ou anti-erreur
• Système de traction : le matériau est tiré dans un poste de travail au moment où il est nécessaire
• Seiri : est le principe qui reflète les déchets. Seiri dicte que ce qui est inutile doit être supprimé. Cela englobe tous les sept déchets originaux de TPS
• Standardisation : organise tous les travaux autour du mouvement humain et crée une séquence de production efficace sans muda. Cela contribue à la qualité, à un rythme constant et permet une amélioration continue.

Le diagramme ci-dessous montre comment les concepts fondamentaux et les valeurs fondamentales sont liés les uns aux autres.

Gestion allégée

Le système de produits Toyota et le Lean Manufacturing ont évolué au fil du temps et ont été appliqués dans un certain nombre de domaines, y compris la gestion.

Le Lean Management a appliqué les valeurs fondamentales d'amélioration continue et de respect des personnes et les a distillées dans un ensemble de cinq principes prescriptifs Lean qui seraient répétés un certain nombre de fois pour s'améliorer en permanence et éliminer le gaspillage :

1. Identifier la valeur : spécifiez une valeur du point de vue du client final par famille de produits.
2. Cartographiez la chaîne de valeur : identifiez toutes les étapes de la chaîne de valeur pour chaque famille de produits, en éliminant autant que possible les étapes qui ne créent pas de valeur.
3. Créer un flux : Faites en sorte que les étapes de création de valeur se déroulent dans un ordre serré afin que le produit circule sans heurts vers le client.
4. Établir l'extraction : à mesure que le flux est introduit, laissez les clients tirer de la valeur de la prochaine activité en amont.
5. Chercher la perfection : Au fur et à mesure que la valeur est spécifiée, les flux de valeur sont identifiés, les étapes inutiles sont supprimées, et le flux et l'attraction sont introduits, recommencez le processus et continuez jusqu'à ce qu'un état de perfection soit atteint dans lequel une valeur parfaite est créée sans gaspillage.

Ces principes et d'autres aspects de la gestion Lean ont été formalisés lorsque Womack & Jones ont publié "Lean Thinking" en 1996.

Développement logiciel simplifié

Lean a depuis été appliqué à la gestion, au développement de logiciels et à d'autres domaines.

Dans les années 1980 et 1990, l'industrie du développement de logiciels approchait d'une crise alors que les projets exécutés à l'aide de méthodologies traditionnelles en cascade prenaient de plus en plus de temps. Cela entraînait souvent un décalage important entre l'identification d'un besoin métier et la livraison d'une solution logicielle. Parfois, ce décalage a été mesuré sur plusieurs années, voire sur des décennies dans certaines industries ayant des exigences spécifiques, comme l'industrie aérospatiale.

Au cours de ces périodes pluriannuelles, les exigences, les systèmes ou même des entreprises entières ont changé. Souvent, les projets étaient annulés en cours de route ou terminaient leur portée, pour découvrir que ce qu'ils avaient livré ne répondait plus aux besoins de l'entreprise tels qu'identifiés au début du projet.

La méthodologie Waterfall a récompensé les parties prenantes pour avoir pensé à tout alors qu'elles étaient contraintes de rédiger un contrat même si elles n'étaient probablement pas sûres de ce dont elles avaient besoin. La méthodologie Waterfall obligeait à prendre des décisions pendant la phase d'exigences ou de conception, et ces décisions étaient très difficiles à modifier sans modifier le contrat et ajouter des coûts au projet. Un pourcentage élevé de projets logiciels ont complètement échoué, ou ont été livrés en retard et hors budget, ou n'ont pas réussi à livrer ce qui était nécessaire.

Cette frustration générale a conduit divers leaders d'opinion à essayer d'améliorer Waterfall. Les premiers exemples incluent le développement rapide d'applications (RAD) qui s'est concentré sur la réduction des déchets en raccourcissant les exigences et les phases de conception via le développement rapide d'un prototype et la collaboration avec les entreprises pour développer davantage l'exigence. Il y a également eu un mouvement vers le développement itératif où un petit projet a été achevé et des fonctionnalités ont été ajoutées dans des itérations continues. Bien que ces méthodologies aient aidé, elles n'ont pas résolu les problèmes fondamentaux associés à Waterfall.

Dans les années 1990 et au début des années 2000, plusieurs auteurs ont publié des livres sur l'application des principes Lean au développement de logiciels. Le Dr Robert Charette a publié « Lean Software Development » en 1993 et ​​« 12 Principles of Lean Software Development » en 2003.

Tom et Mary Poppendieck ont ​​publié "Lean Software Development: An Agile Toolkit" en 2003. Ce livre détaillait sept principes du développement Lean, qui sont directement liés aux sept formes de gaspillage dans le Lean Manufacturing. Les similitudes et les différences entre les deux différentes publications Lean et Agile (discutées dans la section suivante) sont présentées dans le diagramme ci-dessous.

Différences entre Lean et Agile

Selon le Dr Charette, l'une des principales différences entre Lean et Agile est qu'Agile est ascendant, tandis que Lean est descendant.

Cadre agile

Origines de l'Agile et du Manifeste Agile

À peu près au même moment où Charette et les Poppendieck ont ​​​​publié leurs livres, le cadre Agile a été créé pour aider à résoudre les mêmes problèmes. En février 2001, un groupe de pionniers Agile s'est réuni lors de la tristement célèbre réunion Snowbird à Snowbird, Utah, pour essayer de trouver une solution.

Le résultat a été le Manifeste Agile qui a défini un ensemble de valeurs et de principes pour une méthodologie qui tente de s'adapter à l'évolution des exigences et des besoins des clients, de réduire le gaspillage et de fournir des avantages plus rapidement en utilisant une approche incrémentielle et itérative.

Le Manifeste Agile se lit comme suit :

« Nous découvrons de meilleures façons de développer des logiciels en le faisant et en aidant les autres à le faire. Grâce à ce travail, nous avons appris à valoriser :

• Les individus et les interactions sur les processus et les outils
• Logiciel de travail sur une documentation complète
• Collaboration avec le client sur la négociation du contrat
• Répondre au changement en suivant un plan

Autrement dit, alors qu'il y a de la valeur dans les éléments de droite, nous apprécions davantage les éléments de gauche.

Les 12 principes du Manifeste Agile sont alignés sur les valeurs du manifeste :

« Nous suivons ces principes :

1. Notre priorité absolue est de satisfaire le client grâce à la livraison rapide et continue de logiciels de valeur.
2. Accueillez les exigences changeantes, même tardivement dans le développement. Les processus agiles exploitent le changement pour l'avantage concurrentiel du client.
3. Fournissez fréquemment des logiciels fonctionnels, de quelques semaines à quelques mois, avec une préférence pour les délais plus courts.
4. Métiers et développeurs doivent travailler ensemble au quotidien tout au long du projet.
5. Construire des projets autour d'individus motivés. Donnez-leur l'environnement et le soutien dont ils ont besoin, et faites-leur confiance pour faire le travail.
6. La méthode la plus efficiente et la plus efficace pour transmettre des informations à une équipe de développement et au sein de celle-ci est la conversation en face à face.
7. Le logiciel de travail est la principale mesure de progrès. Les processus agiles favorisent le développement durable.
8. Les sponsors, développeurs et utilisateurs doivent pouvoir maintenir indéfiniment un rythme constant.
9. Une attention continue à l'excellence technique et à une bonne conception améliore l'agilité.
10. La simplicité, l'art de maximiser la quantité de travail non fait, est essentielle.
11. Les meilleures architectures, exigences et conceptions émergent d'équipes auto-organisées.
12. À intervalles réguliers, l'équipe réfléchit à la manière de devenir plus efficace, puis ajuste et ajuste son comportement en conséquence. »

Les valeurs et principes ci-dessus sont des applications des principes Lean tels que Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka et la réduction des déchets.

Principes agiles appliqués au développement logiciel

Agile est un cadre parapluie qui s'applique à tout processus qui applique l'ensemble de valeurs et de principes Agile.

Quelques exemples sont:

• Programmation extrême
• Mêlée
• Kanban

Mêlée

Brève histoire de l'écume

Scrum est un framework qui applique les principes Agile qui a été inventé séparément par plusieurs personnes, dont plusieurs ont signé le Manifeste Agile :

• Hirotaka Takeuchi et Ikujiro Nonaka ont initialement introduit le terme « scrum » dans un contexte de fabrication dans leur livre blanc « The New Product Development Game ». publié en 1986 dans la Harvard Business Review.
• Jeff Sutherland, John Scumniotales et Jeff McKenna ont mis en place Scrum chez Easel Corporation en 1993.
• Ken Schwaber a utilisé ce qui allait devenir Scrum dans son entreprise, Advanced Development Methods dans les années 1990 .

Schwaber et Sutherland ont collaboré tout au long des années 1990 pour développer et affiner le cadre dans un contexte de développement de logiciels, prenant la parole lors de diverses conférences. Schwaber a travaillé avec Mike Beedle pour décrire la méthode dans le livre "Agile Software Development with Scrum" en 2001.

Schwaber a ensuite créé les deux principales autorités de certification Scrum :

• Scrum Alliance : créée en 2001. Mise en place de la série d'accréditations Certified Scrum .
• Scrum.org : créé en 2009 après que Schwaber ait quitté la Scrum Alliance. Mettre en place la série parallèle d'accréditations Professional Scrum .

Au fil du temps, plusieurs cadres/organismes de certification ont été créés pour adapter le cadre Scrum à des équipes et des projets plus importants, car Scrum a été initialement conçu pour de petites équipes (7 plus ou moins 2 membres) :

• SAFe : cadre agile à l'échelle
• LeSS : Scrum à grande échelle
• Scrum@scale : Scrum à l'échelle créé par Jeff Sutherland

Valeurs Scrum

Selon la Scrum Alliance :

Scrum est un ensemble simple mais incroyablement puissant de principes et de pratiques qui aident les équipes à livrer des produits dans des cycles courts, permettant une rétroaction rapide, une amélioration continue et une adaptation rapide au changement.

Scrum est un cadre prescriptif, incrémental et itératif pour le développement de logiciels qui applique les principes Agile. Les valeurs et principes Scrum sont décrits dans les tableaux ci-dessous et sont largement alignés sur les valeurs et principes Lean et Agile.

Présentation de Scrum

Le travail est divisé en courtes itérations limitées dans le temps appelées sprints qui durent généralement de 1 à 3 semaines. Cela contraste fortement avec la planification approfondie de Waterfall. Le travail prévu pour le sprint en cours est choisi en haut d'un backlog hiérarchisé d'éléments de travail appelé Product Backlog (Pull System, Heijunka), et il est fixé une fois le sprint démarré. L'objectif est d'avoir un logiciel fonctionnel à la fin de chaque sprint, permettant un retour rapide.

À la fin du sprint, l'équipe se réunit pour passer en revue le travail accompli, comment s'est déroulé le sprint et pour planifier le prochain sprint. La longueur du sprint, ainsi que les rituels et la cadence du sprint, sont fixés pour chaque sprint.

Les sprints sont exécutés par des équipes interfonctionnelles contenant toutes les compétences nécessaires pour terminer le travail dans le sprint. La planification et le suivi quotidiens des progrès sont effectués à l'aide d'artefacts visuels tels que le tableau Scrum et les graphiques Burndown de sprint.

Le travail d'un sprint est extrait d'un backlog prioritaire. Le respect de ces méthodes permet d'adapter les exigences au fil du temps et encourage les commentaires constants des utilisateurs finaux.

Le schéma de la carte mentale ci-dessous décrit certains des principaux concepts de Scum qui seront abordés dans les sections à venir.

Rôles Scrum

Scrum a trois rôles :

• Scrum Master : le Scrum Master est un serviteur leader de l'équipe Scrum. Ils sont le coach de l'équipe qui facilite la collaboration, supprime les obstacles, applique et protège le processus Scrum et protège l'équipe. Cela signifie généralement qu'ils organisent et facilitent les rituels de sprint, s'assurent que le propriétaire du produit dispose d'un backlog correctement hiérarchisé et soigné, s'assure que l'équipe n'est pas obligée de trop s'engager dans un sprint, s'assure que la portée n'est pas ajoutée à un sprint, garantit que la définition de terminé est respectée. Ils n'assignent pas de tâches aux membres de l'équipe (Genchi Genbutsu) et ils ne sont pas responsables de la livraison d'un projet
• Product Owner : le product owner est 'l'unique cou essorable' responsable de la livraison du produit. Le propriétaire du produit définit la vision de ce qu'il veut construire et transmet cette vision à l'équipe et à l'organisation. Le propriétaire du produit est propriétaire des exigences de l'entreprise et du marché et priorise tout le travail qui doit être fait en créant et en gérant le backlog de produit. Ils décident quelles fonctionnalités expédier quand. Ils travaillent avec l'équipe et les autres parties prenantes pour s'assurer que tout le monde comprend les éléments du backlog de produit. Ils acceptent ou rejettent le travail effectué lors d'un sprint lors de la démonstration de sprint.
• Membre de l'équipe : L'équipe Scrum est une équipe interfonctionnelle auto-organisée généralement composée de cinq à sept membres. Tout le monde sur le projet travaille ensemble et s'entraide et n'est pas nécessairement lié à des rôles distincts comme architecte, programmeur, concepteur ou testeur. Tout le monde complète l'ensemble de travail ensemble. L'équipe Scrum planifie la quantité de travail qu'elle peut effectuer à chaque sprint et possède le plan (Genchi Genbutsu).

Flux Scrum, activités et cérémonies

Comme discuté ci-dessus, Scrum a un flux défini et un ensemble de rituels et d'activités. Le déroulement d'un sprint est le suivant.

Planification des sprints :

Avant le début d'un sprint, le Scrum Master facilite une réunion avec l'équipe Scrum et le propriétaire du produit, appelée réunion de planification du sprint, où le propriétaire du produit identifie les objectifs du sprint à venir, et l'équipe planifie ensuite son travail en fonction des objectifs.

Cela se fait généralement avec les activités suivantes :

• Capacité du sprint : l'équipe détermine la capacité du sprint en tenant compte du nombre de jours, du nombre de membres de l'équipe, des vacances, etc.
• Objectifs du sprint : le propriétaire du produit identifie les objectifs du sprint. Il est essentiel que le carnet de produit soit hiérarchisé en fonction des objectifs (c'est-à-dire que les histoires pertinentes soient en haut) et soigné.
• Sélection du travail : les histoires ou les tâches sont extraites du haut du backlog dans le sprint jusqu'à ce que la capacité estimée soit atteinte. Au fur et à mesure que les histoires sont intégrées, le propriétaire du produit expliquera l'histoire et répondra aux questions de l'équipe, en mettant à jour l'histoire si nécessaire, jusqu'à ce que le propriétaire du produit et l'équipe Scrum aient une bonne compréhension commune de l'histoire. Une fois cette activité terminée, l'équipe a une proposition de périmètre de sprint initial.
• Répartition des tâches : l'équipe Scrum discute de chaque histoire en détail en mettant l'accent sur la planification de la manière dont elle terminera l'histoire et répondra à tous les critères d'acceptation et au DoD. Ils produiront une liste de sous-tâches nécessaires pour terminer l'histoire. Une fois la liste des sous-tâches terminée, l'estimation de l'histoire est revue et mise à jour si nécessaire.
• Engagement de sprint : une fois que toutes les histoires sont décomposées et que les estimations sont mises à jour, la portée initiale du sprint proposée est examinée. Les histoires peuvent être supprimées du sprint et remises dans le backlog et/ou des histoires supplémentaires peuvent être ajoutées. Une fois cela fait, SEULE l'équipe Scrum (et non le Scrum Master ou le propriétaire du produit) s'engage à terminer le travail dans le sprint, et le sprint est lancé.

La quantité totale de travail ou la portée engagée pour le sprint est mesurée en points d'histoire.

Exécution des sprints

Pendant le sprint, les membres de l'équipe extraient les éléments de travail (histoires d'utilisateurs, tâches, etc.) du haut de la liste des tâches du sprint pour travailler dessus. Divers membres de l'équipe travailleront sur les divers éléments de travail ou leurs sous-tâches. Ils mettront à jour le statut d'un élément le cas échéant en le déplaçant d'une colonne à la suivante (généralement À faire > En cours > Test > Terminé ou une variante de celui-ci) sur le Scrum Board jusqu'à ce qu'il soit terminé.

Les progrès sont suivis à l'aide d'un graphique burndown qui montre la quantité de travail achevée et restante mesurée en points d'histoire. Les points de reportage restants sont affichés sur l'axe Y et le temps restant est affiché sur l'axe X. Le graphique burndown est mis à jour lorsque les histoires sont terminées.

Au quotidien, le Scrum Master se concentre sur :

• Facilite la réunion quotidienne pour planifier la journée et passer en revue les progrès (voir ci-dessous)
• S'assure que l'équipe a un plan pour la journée
• Supprime les barrages routiers
• Protège la portée du sprint et l'équipe des distractions
• Aide l'équipe à maintenir son burndown chart et d'autres statistiques Scrum

Stand-up quotidien

Au début de chaque journée du sprint, le Scrum Master organise une brève réunion de 15 minutes avec l'équipe Scrum et le propriétaire du produit pour planifier la journée et examiner la progression du sprint. Il s'agit d'une courte réunion où tout le monde se tient devant le tableau Scrum et chaque personne présente à la réunion répond aux questions suivantes en 2 minutes ou moins, en se référant à des éléments spécifiques sur le tableau de sprint :

• Qu'est-ce que vous avez fait hier?
• Que comptez-vous faire aujourd'hui ?
• Y a-t-il des obstacles qui vous empêchent de terminer votre travail?

Cela permet à chacun de voir sur quoi chacun travaille, de voir quels progrès sont réalisés ou non, et d'identifier les obstacles et/ou l'aide nécessaire.

Achèvement du sprint

Le Scrum Master facilite deux cérémonies pour clôturer le sprint avant de planifier le prochain sprint.

Démo de sprint

À la fin du sprint, le Scrum Master facilite une réunion de démonstration de sprint où chaque histoire terminée est présentée sur le logiciel de travail au propriétaire du produit et au reste de l'équipe. Le propriétaire du produit acceptera soit l'histoire si tous les critères d'acceptation sont remplis, soit il la rejettera. Si une histoire est rejetée, les lacunes sont identifiées et l'histoire est remise dans le carnet de produit dans son ordre de priorité pour être complétée ultérieurement ou pas du tout. Souvent, les parties d'une histoire que le propriétaire du produit n'accepte pas sont divisées en une ou plusieurs histoires distinctes et l'histoire d'origine est fermée.

Le nombre total de points d'histoire terminés par sprint (Vélocité) est calculé et le sprint est clôturé. La vitesse est utilisée pour suivre le niveau de sortie de l'équipe et est utilisée pour estimer quand les fonctionnalités ou les versions seront terminées.

Rétrospective Sprint

Après la démonstration de sprint mais avant la prochaine réunion de planification de sprint, le Scrum Master facilite une rétrospective de sprint où l'équipe réfléchit sur le sprint qui vient de se terminer et discute de ce qui s'est bien passé et de ce qui ne s'est pas bien passé afin qu'ils puissent améliorer continuellement et progressivement le processus. et la qualité dans le temps (Kaizen, Hansei). Il existe une pléthore de formats rétrospectifs ou d'exercices qui peuvent être utilisés pour aider l'équipe à générer une discussion.

Une liste d'éléments d'action d'amélioration est produite et entraîne parfois l'ajout d'éléments au backlog du produit, des modifications du DoD ou de la charte d'équipe, etc.

Gestion du carnet de produit

Création du carnet de produit

Avant qu'un sprint puisse être planifié ou exécuté, le propriétaire du produit doit créer un backlog de produit de travail. Le backlog commence généralement par des éléments de développement de fonctionnalités appelés histoires écrites par le propriétaire du produit et, au fil du temps, se remplit également de tâches de développement ou d'assurance qualité, de pics et de défauts, etc. potentiellement créés par n'importe quel membre de l'équipe. Tous les éléments du backlog sont classés par ordre de priorité.

Nettoyage du carnet de commandes

Une fois le backlog de produit initial créé et hiérarchisé, le processus de préparation du backlog en cours prend le relais. L'objectif est d'avoir toujours, au minimum, suffisamment d'éléments du backlog soignés et estimés afin qu'ils soient prêts à être intégrés dans un sprint lors d'une réunion de planification de sprint. Cela se fait généralement en organisant des réunions régulières de préparation du backlog avec le chef de produit et l'équipe animée par le Scrum Master.

Avant la réunion, une liste d'histoires est envoyée à l'équipe afin qu'elle puisse examiner et préparer la réunion de préparation. Lors de la réunion de préparation, chaque élément est discuté en termes de critères d'acceptation, de complexité, de risque, de taille, de stratégie de mise en œuvre, etc. Les critères d'acceptation et d'autres détails de l'histoire sont examinés et révisés jusqu'à ce que l'équipe, le propriétaire du produit et le Scrum Master avoir une compréhension commune de l'histoire. À ce stade, l'histoire est estimée en points d'histoire à l'aide d'une technique appelée planning poker.

Estimation du story point

Les points d'histoire sont une unité d'effort qui utilise un dimensionnement relatif où les histoires sont comparées à des travaux antérieurs, connus et bien compris. Vous posez toujours la question « est-ce que cette histoire est plus grande, plus petite ou à peu près de la même taille » qu'une autre œuvre.

L'échelle de Fibonacci (1, 2, 3, 5, 8, 13, 21 ...) est l'échelle la plus couramment utilisée où chaque incrément est environ deux fois plus grand que le précédent (c'est-à-dire qu'une histoire en cinq points est plus ou moins deux fois plus grande). grand comme une histoire en trois points). Parfois, d'autres échelles comme les tailles de T-shirt (XS, S, M, L, XL) ou même les poissons (vairon, poisson rouge, truite, thon, baleine, etc.) sont utilisées. Toute échelle qui vous permet de comparer la taille de quelque chose par rapport à un autre fonctionnera.

Les points d'histoire représentent l'ensemble des efforts de l'équipe pour mettre en œuvre une histoire, y compris le développement, les tests, la conception et d'autres tâches diverses nécessaires à la définition de terminé. L'estimation tient compte de la quantité de travail, de la complexité et du risque. Une fois que la taille relative de l'histoire est déterminée, une taille sur l'échelle est attribuée comme estimation.

Les équipes se préparent au processus d'estimation des points d'histoire en établissant d'abord une ligne de base pour l'estimation en choisissant une histoire de taille "la plus moyenne" que toute l'équipe comprend comme une histoire de référence. Certaines histoires de référence supplémentaires, plus grandes et plus petites, sont également choisies.

L'estimation des points d'histoire se fait lors des réunions de préparation et parfois lors de la planification du sprint à l'aide de Planning Poker :

1. Chaque membre de l'équipe/estimateur a un jeu de cartes.
2. Les éléments de l'arriéré sont discutés un par un, comme décrit ci-dessus.
3. Une fois que l'article a été entièrement discuté, chaque estimateur choisit en privé une carte pour représenter son estimation.
4. Lorsque tous les estimateurs ont fait leurs estimations, ils dévoilent leurs cartes en même temps.
   • Si toutes les estimations correspondent, les estimateurs sélectionnent un autre élément de l'arriéré et répètent le même processus.
   • Lorsque les estimations diffèrent, les estimateurs discutent de la question pour parvenir à un consensus.

Les avantages de l'estimation du story point sont :

• Rapide : les estimations sont relatives aux éléments de backlog de produit déjà terminés.
• Suffisamment précis : suffisamment précis pour donner un aperçu de la portée, planifier les travaux futurs, hiérarchiser et gérer les attentes.
• Accepte l'incertitude : les points d'histoire spécifient une plage de temps inconnue. La sélection à partir d'une séquence spécifique de points d'histoire de type Fibonacci permet de capturer l'incertitude.
• Team Sport : Implique tout le monde (développeurs, designers, QA, chefs de produits). Utilise plusieurs perspectives pour déterminer la taille du travail, mais seuls les membres de l'équipe effectuant le travail peuvent estimer
• Mesure la vélocité de l'équipe : mesure la quantité de travail effectuée par une équipe dans un sprint par rapport au temps passé à effectuer le travail. Au fur et à mesure que l'équipe s'améliore, elle terminera plus rapidement des histoires de même taille, ce qui se traduira par une vitesse de point d'histoire plus élevée au fil du temps.

Estimation et suivi des versions

L'estimation du story point est également utilisée dans un contexte de planification de release en utilisant la technique suivante :

1. Lister toutes les histoires à dimensionner
2. Mettez-les dans l'ordre du plus petit au plus grand
   • Prenez la première et la deuxième user story.
   • Décidez lequel est le plus grand et mettez le plus grand ci-dessous
   • Ensuite, prenez le suivant et décidez où il se situe par rapport aux deux autres
   • Répétez le processus jusqu'à ce que toutes les histoires soient maintenant dans la liste (dans une séquence du plus petit au plus grand)
3. Dimensionner les histoires

Les estimations de story pour toutes les stories d'une release combinées à la vélocité de l'équipe vous permettront d'estimer quand une release sera terminée et de suivre sa progression. Ceci est souvent indiqué dans un tableau de combustion des versions.

Les artefacts et termes Scrum

• Backlog de produit : Une liste de backlog de tous les éléments de travail pour un produit donné qui peut inclure des fonctionnalités (histoires), des tâches techniques, des pics et des défauts
• Release Burn-up : un graphique utilisé pour montrer la progression au niveau d'une version et pour prédire quand une version sera terminée à l'aide de Sprint Velocity. Les story points terminés sont affichés sur l'axe Y et les sprints sont affichés sur l'axe X.
• Sprint Backlog : Une liste de backlog de tous les éléments de travail à terminer dans un sprint donné. Le contenu du backlog de sprint est convenu lors de la réunion de planification de sprint.
• Scrum Board : Un tableau de style tableau qui suit la progression du travail engagé pour le sprint. Les statuts sont affichés en haut dans des colonnes verticales et les éléments de travail sont déplacés dans chaque statut jusqu'à ce qu'ils soient terminés. Le tableau Scrum est rempli lors de la réunion de planification de sprint et est réinitialisé à la fin d'un sprint.
• Sprint Burndown : un graphique qui montre la quantité de travail achevée et restante mesurée en points d'histoire sur la durée du sprint. Les points de reportage restants sont affichés sur l'axe Y et le temps restant est affiché sur l'axe X.
• Vélocité du sprint : Le nombre de points d'histoire qu'une équipe Scrum complète dans un sprint.
• Backlog des obstacles : une liste des obstacles qui doivent être traités par le Scrum Master afin que l'équipe puisse continuer à travailler. Lorsqu'un membre de l'équipe est bloqué, il ajoute un élément au backlog des obstacles pour fournir une visibilité à l'équipe et au Scrum Master.
• Épique : une épopée est un vaste ensemble de travaux composé de plusieurs histoires d'utilisateurs connexes.
• User Story : Une user story est une description d'une fonctionnalité logicielle du point de vue de l'utilisateur final. La user story décrit le type d'utilisateur, ce qu'il veut et pourquoi. Une user story aide à créer une description simplifiée d'une exigence et inclut des critères d'acceptation. Les user stories sont créées et maintenues par le Product Owner.
• Tâche : une tâche est un élément de travail entré par le Scrum Master ou un membre de l'équipe qui peut être directement ou indirectement lié aux user stories. Ils sont généralement de nature technique et comprendront des critères d'acceptation.
• Spike : un spike est un type spécial de tâche qui est utilisé lorsque vous avez besoin de rechercher, de prototyper et/ou d'architecturer avant de pouvoir décider comment implémenter ou estimer une user story.
• Sous-tâche : une sous-tâche est une tâche qui est entrée en tant qu'étape de mise en œuvre vers la réalisation d'une user story ou d'une tâche. Ils sont généralement saisis par l'équipe lors d'une réunion de planification de sprint.
• Estimations de Story Point : Une échelle d'estimation de taille relative basée sur l'échelle de Fibonacci (1, 2, 3, 5, 8, 13, 21…)
• Critères d'acceptation : la liste des éléments testables spécifiques à une histoire inclus dans chaque histoire qui doivent être terminés avant qu'un propriétaire de produit n'accepte une histoire comme étant terminée.
• Définition de Terminé (DoD) : Une liste d'étapes ou de critères communs qui doivent être remplis avant qu'une histoire puisse être considérée comme terminée. L'équipe est d'accord sur ce point et le documente afin qu'il ne soit pas nécessaire de le mentionner dans chaque histoire.

Avantages et inconvénients de Scrum

Le principal avantage de Scrum est l'application des valeurs et principes Agiles ainsi que des concepts Lean tels que Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System et Iterations. L'application de ces principes permet aux équipes de projet de recevoir un retour d'information continu, de s'adapter rapidement à l'évolution des exigences et de l'incertitude, de réduire le gaspillage, d'augmenter la visibilité et la transparence et de rechercher une amélioration continue. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

Kanban

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.