Le développement d'applications modernes est rarement un effort solitaire. La conception, le codage, le test et l'empaquetage des applications nécessitent une équipe interfonctionnelle composée de concepteurs, de développeurs, de testeurs et de graphistes travaillant en étroite collaboration. Ceci est rendu plus difficile par le fait que les tâches à faire sont le plus souvent inconnues ou incomplètes. Toutes ces compétences combinées permettent de développer des applications qui répondent aux attentes des utilisateurs. Ces applications sont de plus en plus stables et livrées dans les délais et les contraintes budgétaires du client. Depuis le début des années 1970, diverses méthodologies ont été créées pour surmonter ces difficultés et, au fil du temps, la plus populaire a été la méthode en cascade « waterfall model » qui est une approche de conception séquentielle relativement linéaire pour certaines zones de conception technique. Le problème avec ce modèle est que chaque phase doit être complètement achevée avant de passer à la phase suivante. Au fur et à mesure que la taille et la complexité des applications augmentaient vers les années 1980 et 1990, de nombreuses méthodes de développement ont vu le jour pour tenter de surmonter les problèmes rencontrés avec la méthode en cascade parmi lesquelles on peut citer Kanban et Scrum. Ces modèles reflètent à des degrés divers les principes définis par le Manifeste pour le développement agile de logiciels.
En effet, le Manifeste pour le développement Agile de logiciels est un texte rédigé par 17 experts du développement d'applications informatiques sous la forme de plusieurs méthodes dites agiles. Ces experts estimaient que le traditionnel cycle de développement en cascade ne correspondait plus aux contraintes et aux exigences des organisations en évolution rapide. Les méthodes agiles ne sont pas apparues avec l’Agile manifesto en 2001, mais celui-ci détermine leur commun dénominateur et consacre le terme d'« agile » pour les référencer. Les valeurs et principes du Manifeste agile sont défendus par l'Agile Alliance.
Les douze principes du Manifeste sont les suivants :
- satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée ;
- accueillir positivement les changements de besoins, même tard dans le projet ;
- livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts ;
- les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet ;
- réaliser les projets avec des personnes motivées et leur fournir l’environnement et le soutien dont elles ont besoin et leur faire confiance pour atteindre les objectifs fixés ;
- privilégier la colocation de toutes les personnes travaillant ensemble et le dialogue en face à face comme méthode de communication ;
- un logiciel opérationnel est la principale mesure de progression d'un projet ;
- les processus agiles encouragent un rythme de développement soutenable, ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant ;
- une attention continue à l'excellence technique et à un bon design ;
- la simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle ;
- les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées ;
- à intervalles réguliers, l'équipe réfléchit aux moyens possibles pour devenir plus efficace puis elle s'adapte et modifie son mode de fonctionnement en conséquence.
Qu'est-ce que Scrum?
Scrum est un schéma d’organisation de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible ». Il est considéré comme un groupe de pratiques répondant pour la plupart aux préconisations du Manifeste Agile. Son framework s'appuie sur le découpage d'un projet en boîtes de temps, nommées « sprints » qui peuvent durer entre quelques heures et un mois avec une préférence pour deux semaines. Il se base sur l'expérience du terrain et s'appuie sur trois piliers :
- transparence (même langage commun entre l'équipe et le management pour permettre à tout observateur d'obtenir rapidement une bonne compréhension du projet) ;
- inspection (à intervalle régulier, Scrum propose de faire le point sur les différents artéfacts produits, afin de détecter toute variation indésirable) ;
- adaptation (si une dérive est constatée pendant l'inspection, le processus doit alors être adapté. Scrum fournit des évènements durant lesquels cette adaptation est possible) ;
Le cadre du scrum consiste en la définition des rôles projets, activités ou artefacts, et réunions ou événements. Ceux-ci sont décrits dans le guide rédigé par les créateurs de la méthode.
La méthodologie scrum présente néanmoins quelques risques à savoir le flaccid scrum, un scrum master directif et la communication constructive laisse la place aux reproches.
Qu'est-ce que Kanban?
Kanban est un terme japonais qui signifie « étiquette ». C'est une méthodologie du Manifeste d'Agile qui a été formalisée en 2010 par David Anderson. Elle est basée sur le principe de la limitation du nombre de travaux à faire (TAF). L’objectif de Kanban est d’éviter le gaspillage en assurant l’amélioration continue du processus. L’équipe définit les limites du TAF pour chaque étape du processus Kanban. Le flux du travail est contrôlé visuellement et permet à l'équipe de suspendre le processus afin de résoudre un problème bloquant.
Les 4 phases d’une démarche Kanban sont les suivantes :
- la phase de conception ;
- la phase de mise en œuvre (l’équipe applique les pratiques de la démarche Kanban et utilise ses outils à l’identification du processus existant et la définition des éléments du travail et la mise en place des règles du système) ;
- la phase d’étude (ensemble, l’équipe et le concepteur étudient la réaction du système aux règles instaurées lors de la première phase de conception) ;
- la phase d’amélioration (en fonction des conclusions de la phase d’étude, l’équipe ajuste le système, stabilise le processus, réorganise les éléments et fixe les règles).
Qu'est-ce que Scrum et Kanban ont en commun ?
Il y a beaucoup de similitudes entre Scrum et Kanban. Scrum et Kanban permettent à la fois de décomposer et d'exécuter efficacement des tâches importantes et complexes. Tous deux accordent une grande importance à l'amélioration continue, à l'optimisation du travail et au processus. Et tous les deux partagent le même accent sur un flux de travail très visible qui tient tous les membres de l'équipe au courant des tâches exécutées et de celles qui suivent.
Qu'est-ce qui différencie Scrum et Kanban ?
il existe un certain nombre de différences dans la philosophie de l'application pratique de Scrum et Kanban. Bien que les différences individuelles soient nombreuses, elles peuvent être regroupées dans les trois catégories suivantes :
- Planification, itération et cadence
Les processus Scrum mettent fortement l'accent sur le calendrier. L'équipe de Scrum dispose d'une liste hiérarchisée de tâches à faire qui doivent être complétées pour livrer un produit livrable. L'équipe doit décider combien de points, selon elle, peuvent être complétés dans un sprint. Tout ce qui sort de la portée à laquelle ils s'engagent doit attendre le prochain sprint. Idéalement, une équipe Scrum efficace apprendra rapidement ses capacités au cours de plusieurs sprints et ses estimations s'amélioreront et seront optimisées au fil du temps. Ensuite, toutes les deux semaines (ou quelque soit la durée de leur sprint), l'équipe produit un produit livrable, effectue une rétrospective pour discuter de l'optimisation du processus et passe au sprint suivant. Ce processus itératif est conçu pour permettre des estimations précises du flux de travail et une gestion efficace de plusieurs projets.
Sur une équipe Kanban, il n'y a pas de boîtes de temps ou d'itérations requises. Bien que la méthode Kanban soit de nature itérative, on s'attend à ce que l'amélioration continue se produise de façon évolutive à mesure que le travail est continuellement complété. Les limitations imposées à diverses conditions dans le flux de travail seront réglées au début de l'utilisation de Kanban par une équipe (ou une organisation) jusqu'à ce qu'un ensemble optimal de limites soit atteint pour maintenir le flux régulier et efficace. - Rôles et responsabilités
Sur les équipes Scrum, il existe au moins trois rôles à attribuer pour traiter efficacement le travail: le propriétaire du produit « Product Owner », Scrum Master et les membres de l'équipe. Chaque rôle a son propre ensemble de responsabilités, et ils doivent travailler ensemble pour atteindre un équilibre ordonné et efficace. L'équipe de mêlée doit elle aussi être interfonctionnelle, c'est-à-dire qu'une équipe doit avoir toutes les ressources nécessaires pour compléter le travail du sprint.
Sous Kanban, aucun ensemble de rôles n'est prescrit. D'un point de vue pratique, il est logique que quelqu'un occupe un poste de chef de projet ou de superviseur, en particulier pour des projets Kanban plus importants et plus complexes, mais les rôles devraient théoriquement évoluer en fonction des besoins du projet et de l'organisation. Une équipe Kanban n'est pas obligée d'être interfonctionnelle puisque le flux de travail Kanban est destiné à être utilisé par toutes les équipes impliquées dans le projet. Par conséquent, une équipe de spécialistes et une équipe distincte de généralistes peuvent travailler sur différents aspects du même projet Kanban à partir du même conseil. - Les tableaux
Bien que très similaires, le tableau Scrum et le tableau Kanban sont très différents. Sur un tableau Scrum, les colonnes sont étiquetées pour refléter les périodes dans le flux de travail commençant avec le backlog de sprint et se terminant par tout ce qui les tâches à faire de l'équipe. Tous les historiques ajoutés au tableau au début de chaque sprint doivent être trouvés dans la dernière colonne à la fin de ce sprint ou le sprint n'a pas réussi. Après la rétrospective du sprint, le tableau est effacé et préparé pour le prochain sprint.
Sur un tableau Kanban, les colonnes sont également étiquetées pour afficher les états de flux de travail, mais avec une différence essentielle. Elles publient également le nombre maximum d'historiques autorisés dans chaque colonne à la fois. Cela renforce les limites déterminées par l'équipe que Kanban prescrit pour chaque condition. Étant donné que chaque colonne a un nombre limité d'historiques autorisés et qu'il n'y a pas de case horaire requise (comme la longueur du sprint), il n'y a aucune raison de réinitialiser le tableau Kanban au fur et à mesure que le travail progresse. Il continuera à circuler aussi longtemps que le projet se poursuivra, avec de nouveaux historiques ajoutés au fur et à mesure des besoins, et les historiques complétés seront réévalués si nécessaire.
Sources : Scrum Methodology, scrum guide, Cprime
Et vous ?
Entre les méthodologies Scrum et Kanban, laquelle préféreriez-vous et pourquoi ?Voir aussi
Testez vos connaissances sur kanban Scrum et les changements pendant un sprint 
Envoyé par kerauzen
