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.
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:
Traitement excessif: d'un mauvais outillage ou d'une mauvaise conception du produit
TPS a travaillé pour éliminer les déchets en appliquant ces deux concepts fondamentaux:
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é:
Le diagramme ci-dessous montre comment les concepts fondamentaux et les valeurs fondamentales sont liés les uns aux autres.
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:
Ces principes et d'autres aspects de la gestion Lean ont été officialisés lorsque Womack & Jones a publié «Lean Thinking» en 1996.
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.
Selon le Dr Charette, l'une des principales différences entre Lean et Agile est que Agile est ascendant, tandis que Lean est descendant.
ButsDéveloppement logiciel Lean de Charette | Le Manifeste Agile | Maigre de Poppendieck |
---|---|---|
|
|
Développement logiciel Lean de Charette | Le Manifeste Agile | Maigre de Poppendieck |
---|---|---|
|
|
|
À 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:
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:
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.
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:
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:
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:
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):
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.
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.
Scrum a trois rôles:
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.
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:
La quantité totale de travail ou la portée engagée pour le sprint est mesurée en points d'histoire.
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:
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:
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.
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.
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:
Les avantages de l'estimation des points d'histoire sont:
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:
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.
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:
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.
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 |
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.
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.
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.
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.