Agile
Le plan de gestion de projet, partie 1: une comparaison complète entre Agile, Scrum, Kanban et Lean
Aperçu
De nombreuses méthodologies sont utilisées dans le développement de logiciels aujourd'hui. Vous avez peut-être entendu des mots à la mode tels que Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming, etc.
Dans cet article, je vais définir ces termes, discuter de la manière dont ils sont liés les uns aux autres et en quoi ils diffèrent les uns des autres. Bon nombre des mots à la mode mentionnés ci-dessus sont basés sur des concepts de Fabrication au plus juste qui était à l'origine basé sur le Système de fabrication Toyota (TPS) nous en parlerons donc en premier.
Méthodologie Lean
Origines de la fabrication allégée et allégée
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 qui ont été à l'origine inspirés 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:
- Jeune: 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 impliqué dans la recherche et la correction des défauts
- Surproduction: production en avance sur la demande
- Attendre: en attente de la prochaine étape de production, des 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 pour le traitement
- Inventaires: inventaire terminé 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
- Dans: traduit par «surcharge». 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.
- Si: traduit par «inégalité». Mura peut être trouvé dans la fluctuation de la demande des clients, les temps de processus par produit ou la variation des temps de cycle pour différents opérateurs. Lorsque le 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 du produit et en créant un travail standard pour tous les opérateurs.
TPS a travaillé pour é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 pendant le 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: Faire seulement «ce qui est nécessaire, quand c'est nécessaire et dans la quantité nécessaire».
Au fur et à mesure que TPS évoluait, ces piliers fondamentaux et ces valeurs reposaient sur les concepts de Jidoka et JIT et s'est ancré:
- 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éliorer continuellement les opérations commerciales, toujours en quête d'innovation et d'évolution, en éliminant un muda à la fois
- Genchi Genbutsu: pratiquer le genchi genbutsu, aller à la source pour trouver les faits pour prendre les bonnes décisions, construire un consensus et atteindre les objectifs à notre meilleure vitesse
- Respect des personnes:
- Le respect: respecter les autres et faire tout son possible pour se comprendre, prendre ses responsabilités et faire de son mieux pour instaurer une confiance mutuelle
- Travail en équipe: stimuler la croissance personnelle et professionnelle, partager les opportunités de développement et maximiser les performances individuelles et d'équipe
- Et sur: un indicateur visuel d'état ou de problème
- Heijunka: signifie nivellement ou nivellement de la production
- Hansei: signifie auto-réflexion. Pour améliorer l'efficacité, les travailleurs doivent remettre en question les hypothèses qui sous-tendent les processus actuels pour en trouver de meilleures.
- Kanban: une enseigne utilisée comme outil visuel pour contrôler la production
- Poka-joug: Également appelé vérification des erreurs ou vérification des erreurs
- Système de traction: Le matériau est aspiré 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 n'est pas nécessaire doit être supprimé. Cela englobe tous les sept déchets d'origine 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 Lean
Le système de produits Toyota et la fabrication au plus juste ont évolué au fil du temps et ont été appliqués dans un certain nombre de domaines, y compris la gestion.
Gestion Lean a appliqué les valeurs fondamentales de l'amélioration continue et du respect des personnes et les a distillées en un ensemble de cinq principes prescriptifs Lean qui seraient répétés plusieurs fois pour améliorer et éliminer continuellement les déchets:
- Identifier la valeur: Spécifiez une valeur du point de vue du client final par famille de produits.
- Chaîne de valeur de la carte: 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.
- 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 en douceur vers le client.
- Établir Pull: Au fur et à mesure que le flux est introduit, laissez les clients tirer de la valeur de la prochaine activité en amont.
- Rechercher 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'extraction 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é officialisés lorsque Womack & Jones a publié «Lean Thinking» en 1996.
Développement de logiciels Lean
Le 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, car 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 énorme décalage entre l'identification d'un besoin commercial et la livraison d'une solution logicielle. Parfois, ce décalage était mesuré sur plusieurs années, voire sur des décennies dans certaines industries aux besoins spécifiques, comme l'industrie aérospatiale.
Au cours de ces délais de plusieurs années, 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 ils achèveraient leur portée, seulement pour découvrir que ce qu'ils ont livré ne répond plus aux besoins de l'entreprise tels qu'ils ont été identifiés au début du projet.
La Méthodologie de la cascade récompensé les parties prenantes pour avoir pensé à tout car elles ont été forcées 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 a forcé des décisions à être prises pendant la phase des exigences ou de la conception, et ces décisions étaient très difficiles à changer sans changer le contrat et ajouter des coûts au projet. Un pourcentage élevé de projets logiciels a échoué complètement, ou livré en retard et dépassé le budget, ou n'a pas réussi à fournir 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 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 avait également 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 le 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. Dr Robert Charette a publié «Développement de logiciels Lean» en 1993 et «12 principes de développement de logiciel Lean» en 2003.
Tom et Mary Poppendieck ont publié «Développement de logiciels Lean: une boîte à outils Agile» en 2003. Ce livre a détaillé sept principes du Lean Development, qui sont directement corrélés aux sept formes de déchets dans le Lean Manufacturing. Les similitudes et les différences entre les deux 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 que Agile est ascendant, tandis que Lean est descendant.
Buts| Développement logiciel Lean de Charette | Le Manifeste Agile | Maigre de Poppendieck |
|---|---|---|
|
|
| Développement logiciel Lean de Charette | Le Manifeste Agile | Maigre de Poppendieck |
|---|---|---|
|
|
|
Cadre Agile
Origines de l'Agile et du Manifeste Agile
À peu près au 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 progressive 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 en sommes venus à valoriser:
- Individus et interactions sur les processus et les outils
- Logiciel de travail sur une documentation complète
- Collaboration client sur la négociation de contrat
- Répondre au changement plus de suivre un plan
Autrement dit, même s'il y a de la valeur dans les éléments de droite, nous valorisons davantage les éléments de gauche. »
Les 12 principes qui sous-tendent le Manifeste Agile sont alignés sur les valeurs du manifeste:
«Nous suivons ces principes:
- Notre priorité absolue est de satisfaire le client grâce à une livraison rapide et continue de logiciels précieux.
- Accueillez les besoins changeants, même tard dans le développement Les processus agiles exploitent le changement pour l’avantage concurrentiel du client.
- Fournissez fréquemment des logiciels fonctionnels, de quelques semaines à quelques mois, avec une préférence pour les délais plus courts.
- Les professionnels et les développeurs doivent travailler ensemble au quotidien tout au long du projet.
- Construisez 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.
- La méthode la plus efficace et la plus efficace pour transmettre des informations à et au sein d'une équipe de développement est la conversation en face à face.
- Le logiciel de travail est la principale mesure du progrès. Les processus agiles favorisent le développement durable.
- Les sponsors, les développeurs et les utilisateurs devraient être en mesure de maintenir un rythme constant indéfiniment.
- Une attention continue à l'excellence technique et à une bonne conception améliore l'agilité.
- La simplicité - l'art de maximiser la quantité de travail non effectuée - est essentielle.
- Les meilleures architectures, exigences et des dessins émergent des équipes auto-organisées.
- À 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 général qui s'applique à tout processus qui applique l'ensemble de valeurs et de principes Agile.
Quelques exemples sont:
- Programmation extrême
- Scrum
- Kanban
Scrum
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 implémenté 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 logiciel, s'exprimant 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:
- Alliance Scrum : créé en 2001. Mettre en place le Scrum certifié série d'accréditation.
- Scrum.org : créé en 2009 après que Schwaber a quitté la Scrum Alliance. Configurer le parallèle Scrum professionnel série d'accréditation.
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é conçu à l'origine pour les petites équipes (7 membres plus ou moins 2):
- Sûr : Framework Agile mis à l'échelle
- Moins : Scrum à grande échelle
- [email protected] e: Scrum at Scale créé par Jeff Sutherland
Valeurs Scrum
Selon la Scrum Alliance:
Scrum est un ensemble de principes et de pratiques simples mais incroyablement puissants qui aident les équipes à livrer des produits dans des cycles courts, permettant un retour rapide, une amélioration continue et une adaptation rapide au changement.
Scrum est un cadre normatif, incrémental et itératif pour le développement de logiciels qui appliquent les principes Agile. Les valeurs et principes Scrum sont décrits dans les tableaux ci-dessous et sont en adéquation significative avec les valeurs et principes Lean et Agile.
Présentation de Scrum
Le travail est divisé en courtes itérations temporelles appelées sprints, qui durent généralement de 1 à 3 semaines. Ceci est en contraste frappant avec la planification approfondie de Waterfall. Le travail prévu pour le sprint en cours est choisi dans le haut d'un backlog priorisé d'éléments de travail appelé Product Backlog (Pull System, Heijunka), et il est corrigé 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 effectué, comment le sprint s'est déroulé 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 du sprint. La planification quotidienne et le suivi des progrès sont effectués à l'aide d'artefacts visuels tels que le tableau de mêlée et les graphiques de burndown de sprint.
Le travail dans un sprint est tiré d'un backlog priorisé. Suivre ces méthodes permet de changer les exigences au fil du temps et encourage un retour d'information constant de la part des utilisateurs finaux.
Le diagramme de carte mentale ci-dessous décrit certains des principaux concepts de Scum qui seront discutés dans les sections à venir.
Rôles Scrum
Scrum a trois rôles:
- Scrum Master : le Scrum Master est un leader serviteur de l'équipe Scrum. Ils sont le coach de l'équipe qui facilite la collaboration, supprime les obstacles, applique et sauvegarde 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 priorisé et soigné, s'assurent que l'équipe ne soit pas obligée de s'engager excessivement dans un sprint, s'assurent 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
- Propriétaire du produit : le propriétaire du produit est «le seul col essorable» responsable de la livraison du produit. Le Product Owner définit la vision de ce qu'il veut construire et transmet cette vision à l'équipe et à l'organisation. Le propriétaire du produit possède les exigences de l'entreprise et du marché et priorise tout le travail qui doit être effectué à travers la création et la gestion du 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 produit. Ils acceptent ou rejettent le travail effectué dans un sprint lors de la démo 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 l'architecte, le programmeur, le concepteur ou le testeur. Tout le monde termine le travail ensemble. L'équipe Scrum planifie la quantité de travail qu'elle peut accomplir à chaque sprint et possède le plan (Genchi Genbutsu).
Scrum Flow, 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 du sprint:
Avant le début d'un sprint, le Scrum Master facilite une réunion avec l'équipe Scrum et le Product Owner, appelée réunion de planification du sprint, où le Product Owner 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é de 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 product owner identifie les objectifs du sprint. Il est essentiel que le backlog de produit soit priorisé en fonction des objectifs (c'est-à-dire que les histoires pertinentes sont en haut) et soigné.
- Sélection de 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 tirées, le propriétaire du produit expliquera l'histoire et répondra aux questions de l'équipe, en mettant à jour l'histoire au besoin, 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 façon dont ils vont compléter l'histoire et aborder tous les critères d'acceptation et le DoD. Ils produiront une liste des 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é est revue. Les histoires peuvent être supprimées du sprint et replacées dans le backlog et / ou des histoires supplémentaires peuvent être ajoutées. Une fois que cela est 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 de sprint
Pendant le sprint, les membres de l'équipe extraient les éléments de travail (user stories, tâches, etc.) du haut de la liste des tâches du sprint pour travailler. Différents membres de l'équipe travailleront sur les différents éléments de travail ou leurs sous-tâches. Ils mettront à jour l'état d'un élément le cas échéant en le déplaçant d'une colonne à l'autre (généralement À faire> En cours> Test> Terminé ou une variation de celui-ci) sur le Scrum Board jusqu'à ce que cela soit fait.
La progression est suivie à l'aide d'un graphique de burndown qui montre la quantité de travail achevée et restante mesurée en points d'histoire. Les points d'étage restants sont affichés sur l'axe Y et le temps restant est indiqué sur l'axe X. Le graphique de 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 diagramme de burndown et d'autres statistiques Scrum
Standup quotidien
Au début de chaque journée du sprint, le Scrum Master facilite une brève réunion de 15 minutes avec l'équipe Scrum et le Product Owner pour planifier la journée et passer en revue la progression du sprint. Il s'agit d'une courte réunion où tout le monde est debout devant le Scrum Board 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 du sprint board:
- 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 tout le monde 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 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 l'histoire si tous les critères d'acceptation sont remplis ou rejettera l'histoire. Si une histoire est rejetée, les lacunes sont identifiées et l'histoire est remise dans le backlog du produit dans son ordre de priorité pour être complétée plus tard ou pas du tout. Souvent, les parties d’une histoire que le Product Owner n’accepte pas sont divisées en une ou plusieurs histoires séparées et l’histoire originale est fermée.
Le nombre total de points d'histoire terminés par sprint (Velocity) est calculé et le sprint est fermé. 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émo 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 n'a pas bien fonctionné afin de pouvoir améliorer continuellement et progressivement le processus. et la qualité au fil du 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 des discussions.
Une liste d'éléments d'action d'amélioration est produite et parfois ils aboutissent à l'ajout d'éléments au backlog produit, à des modifications du DoD ou de la charte d'équipe, etc.
Gestion du backlog de produits
Création de backlog produit
Avant qu'un sprint puisse être planifié ou exécuté, le propriétaire du produit doit créer un backlog de travail du produit. 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, avec le 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é.
Toilettage de l'arriéré
Une fois le backlog produit initial créé et priorisé, le processus de préparation du backlog en cours prend le relais. L'objectif est de toujours avoir, au minimum, suffisamment d'éléments principaux du backlog soignés et estimés afin qu'ils soient prêts à être entraînés dans un sprint lors d'une réunion de planification de sprint. Cela se fait généralement en organisant régulièrement des réunions de préparation de l'arriéré 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 revoir 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 autres détails de l'histoire sont revus et révisés jusqu'à ce que l'équipe, le product owner et 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 point d'histoire
Les points d'histoire sont une unité d'effort qui utilise une taille relative où les histoires sont comparées à des travaux antérieurs, connus et bien compris. Vous vous posez toujours la question «est-ce que cette histoire est plus grande, plus petite ou approximativement 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.-à-d., Une histoire en cinq points est plus ou moins deux fois grand comme une histoire en trois points). Parfois, d'autres écailles comme les tailles de T-shirt (XS, S, M, L, XL) ou même des 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 à une 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 la taille relative de l'histoire déterminée, une taille sur l'échelle est assignée comme estimation.
Les équipes se préparent au processus d'estimation des points d'histoire en établissant d'abord une base de référence 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 qui sont de plus en plus petites sont également choisies.
L'estimation des points d'histoire est effectuée lors des réunions de toilettage et parfois lors de la planification du sprint à l'aide de Planning Poker:
- Chaque membre de l'équipe / estimateur a un jeu de cartes.
- Les éléments du backlog sont discutés un par un, comme décrit ci-dessus.
- Une fois que l'item a été entièrement discuté, chaque estimateur choisit en privé une carte pour représenter son estimation.
- Lorsque tous les estimateurs ont fait leurs estimations, ils révèlent 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 des points d'histoire sont:
- Rapide: les estimations sont relatives aux éléments du carnet de commandes de produits déjà terminés.
- Assez précis: suffisamment précis pour donner un aperçu de la portée, planifier les travaux futurs, prioriser et gérer les attentes.
- Embrasse l'incertitude: Les points d'histoire spécifient une plage de temps inconnue. La sélection à partir d'une séquence de points d'histoire de type Fibonacci spécifique permet de capturer l'incertitude.
- Sport d'équipe: 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 vitesse 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, ils termineront 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 des points d'histoire est également utilisée dans un contexte de planification de version à l'aide de la technique suivante:
- Listez toutes les histoires à dimensionner
- 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 gros 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)
- Dimensionner les histoires
Les estimations d'histoires pour toutes les histoires d'une version combinées à la vélocité de l'équipe vous permettront d'estimer quand une version sera terminée et de suivre sa progression. Ceci est souvent montré dans un tableau de burn-up des versions.
Les artefacts et les termes Scrum
- Backlog 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
- Relâchez Burn-up: Un graphique graphique utilisé pour montrer la progression au niveau d'une version et pour prédire quand une version sera terminée en utilisant Sprint Velocity. Les points d'histoire terminés sont affichés sur l'axe Y et les sprints sur l'axe X.
- Backlog de sprint: 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 du sprint.
- Conseil Scrum: Un tableau de style table 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 état jusqu'à ce qu'ils soient terminés. Le tableau de mêlée est rempli pendant la réunion de planification du sprint et est réinitialisé à la fin d'un sprint.
- Burndown de sprint: Un graphique 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 d'étage restants sont affichés sur l'axe Y et le temps restant est indiqué sur l'axe X.
- Vitesse de sprint: Le nombre de points d'histoire qu'une équipe Scrum termine dans un sprint.
- Arriéré d'obstacles: Une liste des obstacles qui doivent être résolus 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 d'obstacles pour offrir une visibilité à l'équipe et à Scrum Master.
- Épique: Une épopée est un vaste corpus de travail composé de plusieurs user stories associées.
- Histoire de l'utilisateur: 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 permet de créer une description simplifiée d'une exigence et inclut des critères d'acceptation. Les user stories sont créées et gérées par le propriétaire du produit.
- Tâche: Une tâche est un travail saisi 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.
- Pointe: Un pic est un type spécial de tâche qui est utilisé lorsque vous avez besoin de rechercher, de prototyper et / ou d'architecter quelque temps 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 d'implémentation pour terminer une user story ou une tâche. Ils sont généralement inscrits par l'équipe lors d'une réunion de planification de sprint.
- Estimations des points d'histoire: Une échelle d'estimation du dimensionnement relatif 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 doit être complétée avant qu'un propriétaire de produit accepte une histoire comme étant terminée.
- Définition de Done (DoD): Une liste d'étapes ou de critères communs qui doivent être complétés avant qu'une histoire puisse être considérée comme terminée. L’équipe est d’accord sur ce point et le documente de manière à ce qu’il n’ait pas à être répertorié dans chaque article.
Avantages et inconvénients de Scrum
Le principal avantage de Scrum est l'application des valeurs et principes Agile 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 s'efforcer de s'améliorer continuellement. En se concentrant toujours sur les éléments les plus importants du backlog produit et en ne travaillant que sur de courtes itérations qui produisent toujours des logiciels fonctionnels, Scrum est plus axé sur le client et permet aux clients de voir ce qu'ils aiment (et n'aiment pas) et d'apporter les modifications nécessaires. Les frais généraux en termes de processus et de gestion sont plus faibles, ce qui conduit à des résultats plus rapides et moins chers.
Scrum est une excellente méthodologie pour les projets dont les exigences ne sont pas clairement connues et / ou susceptibles de changer. Cela s'applique à la plupart des projets. Scrum est également idéal pour les équipes expérimentées et motivées car il permet aux équipes d'organiser le travail elles-mêmes et offre visibilité, transparence et responsabilité pour les progrès et les problèmes. Tout cela permettra aux équipes de s'améliorer et de devenir plus productives au fil du temps.
Scrum présente certains inconvénients et n'est pas la meilleure méthodologie dans certaines situations:
- Transparence: Scrum augmente la transparence et la responsabilité, ce qui est à la fois un avantage et un inconvénient car les problèmes et les mauvaises performances à l'intérieur et à l'extérieur de l'équipe sont exposés. Cela peut être inconfortable et conduire à une résistance s'il n'est pas géré correctement dans le cadre de l'amélioration continue Scrum.
- Expérience et engagement d'équipe: Les équipes Scrum ou Scrum Masters inexpérimentés et / ou non engagés peuvent causer de sérieux problèmes en appliquant mal la méthodologie Scrum. Il n'y a pas de rôles définis dans l'équipe Scrum car tout le monde fait tout, donc cela nécessite des membres de l'équipe engagés avec une expérience technique pour suivre le processus Scrum et s'améliorer au fil du temps. Cela peut également être très préjudiciable si d'autres parties de l'organisation résistent à Scrum.
- Fluage portée: Il existe un risque de dérive de la portée, en particulier s'il n'y a pas de date de fin définie car les parties prenantes sont autorisées à ajouter à la portée. Pouvoir changer la portée et les priorités est l’un des principaux avantages de Scrum, mais cela peut aussi être un inconvénient si la discipline n’est pas utilisée.
- Travail mal défini: Des user stories ou des tâches mal définies et mal comprises peuvent entraîner des retouches, des estimations inexactes et une dérive de la portée. Bien que Scrum se concentre sur le logiciel de travail plutôt que sur la documentation, le propriétaire du produit doit être clair sur ce qu'il veut et être capable de le communiquer clairement dans les conversations et dans les user stories.
- Mise à l'échelle: L'adoption du framework Scrum dans les grandes équipes est un défi car Scrum est destiné aux petites équipes.
Kanban
Qu'est-ce que Kanban?
Kanban est un processus plus léger qui applique de nombreuses valeurs Lean et Agile ainsi qu'un sous-ensemble des valeurs et principes Scrum, mais il existe également des différences fondamentales. Kanban se concentre sur la visualisation, le flux et la limitation du travail en cours.
Kanban signifie «enseigne» ou «panneau d'affichage» en japonais. Les employés de la chaîne de Toyota ont utilisé un kanban (c'est-à-dire une carte réelle) pour signaler une capacité supplémentaire à diverses étapes de leur processus de fabrication. Dans le logiciel, cela se fait avec un tableau Kanban, qui est très similaire au tableau Scrum. Il existe un arriéré prioritaire d'éléments à faire et de colonnes verticales pour chaque statut qu'un élément de travail peut avoir. Comme Scrum, les éléments de travail sont déplacés d'un statut à un autre; cependant, dans Kanban, la quantité de travail en cours est strictement limitée à un nombre maximum d'éléments dans chaque statut en fonction de la capacité de l'équipe. Le nouveau travail ne peut pas être intégré tant que le travail existant n'est pas déplacé vers l'étape suivante du processus. Dans Scrum, le travail en cours est indirectement limité en contrôlant la quantité de travail prévue pour un sprint.
Dans Kanban, il n'y a pas d'itérations ou de sprints fixes, juste un flux constant où les éléments de travail sont tirés d'une étape à l'autre. Cela signifie que la carte Kanban n'est jamais réinitialisée. Cela signifie également que de nombreux rituels Scrum ne sont pas utilisés. Les équipes Kanban ont souvent des réunions debout quotidiennes mais elles ne sont pas prescrites. Il n'y a pas de réunions de planification de sprint, de démos de sprint ou de rétrospectives de sprint régulièrement planifiées, le processus est donc plus léger. Certaines des activités de ces rituels peuvent ou non être exécutées à un niveau informel. L'amélioration continue est réalisée en suivant et en analysant le flux d'éléments d'un état à un autre et en apportant des améliorations incrémentielles constantes en fonction des problèmes découverts.
Kanban ne prescrit pas non plus les rôles de Scrum. Le seul rôle nécessaire est celui du membre de l'équipe, cependant, il y a souvent chef de projet qui gère l'équipe et l'arriéré. Souvent, un seul tableau Kanban peut servir plusieurs rôles et / ou équipes basés sur des fonctions qui ne travaillent que sur des éléments d'un certain statut. Par exemple, une équipe de développement peut extraire des éléments de À faire vers En cours et les déplacer vers Test, et l'équipe de test peut tester des éléments dans Test et les déplacer vers Terminé.
De nombreuses activités de gestion de l'arriéré pour la hiérarchisation et la préparation des éléments de travail doivent encore être effectuées pour s'assurer qu'un élément de travail donné est bien compris et prêt à être travaillé, cependant, l'estimation des éléments de travail est prescrite comme facultative.
Kanban contre Scrum
Le tableau suivant compare Scrum et Agile:
| Kanban | Scrum |
|---|---|
| Livraison continue | Sprints temporisés |
| Moins de processus et de frais généraux | A prescrit des rituels et des rôles de Sprint |
| Se concentre sur la réalisation rapide d'éléments individuels | Se concentre sur la réalisation rapide d'un lot de travail |
| Mesure le temps de cycle | Mesure la vitesse de sprint |
| Se concentre sur un débit efficace | Se concentre sur la prévisibilité |
| Limite le WIP pour les articles individuels | Limite le WIP au niveau Sprint |
| Les éléments de travail individuels sont extraits | Le travail est tiré par lots à Sprint Planning |
| Aucun rôle prescrit | A des rôles prescrits (Scrum Master, Product Owner, Team Member) |
| Le Kanban Board peut être organisé autour d'une seule équipe interfonctionnelle ou de plusieurs équipes spécialisées | Scrum Board est organisé autour d'une seule équipe transversale |
| Des modifications peuvent être apportées à tout moment -> plus flexible | Les modifications ne sont autorisées que dans le Backlog produit. Les modifications dans un sprint ne sont pas autorisées |
| Nécessite moins de formation | Nécessite plus de formation |
| Idéal pour les équipes où seules des améliorations incrémentielles sont nécessaires | Bon pour les équipes où des changements fondamentaux sont nécessaires |
Résumé: la fin de la partie 1
Dans cette partie, nous avons passé en revue quelques-unes des méthodologies les plus populaires utilisées pour le développement de logiciels. Vous devez maintenant avoir une bonne compréhension de Lean, Agile, Scrum et Kanban et de leurs racines historiques dans le Lean Manufacturing et le TPS. Dans la prochaine partie de la série, nous continuerons d'examiner et de comparer d'autres méthodologies de développement logiciel telles que Cascade , JTBD , et Sûr (et d'autres cadres de mise à l'échelle), ainsi que des méthodologies hybrides, de sorte que vous les avez toutes expliquées de manière pratique en un seul endroit.
Comprendre les bases
Qu'est-ce que Agile?
Agile est un cadre général qui s'applique à tout processus qui applique l'ensemble de valeurs et de principes Agile. Certains des exemples sont: Extreme Programming, Scrum et Kanban.
Qu'est-ce que Scrum?
Scrum est un ensemble de principes et de pratiques simples mais incroyablement puissants qui aident les équipes à livrer des produits dans des cycles courts. 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.
Qu'est-ce que Kanban?
Kanban est un processus plus léger qui applique de nombreuses valeurs Lean et Agile ainsi qu'un sous-ensemble des valeurs et principes Scrum, mais il existe également des différences fondamentales. Kanban se concentre sur la visualisation, le flux et la limitation du travail en cours.
