Lorsqu'il s'agit de choisir entre deux options, il y a toujours un risque d'être influencé par des opinions et des faits douteux. En choisissant n'importe quelle méthodologie ou approche de travail, nous nous efforçons d'éviter les erreurs et étudions autant de faits et de détails sur le sujet que possible pour faire le bon choix.
Dans le développement de logiciels Agile, ce choix est également difficile, surtout s'il s'agit de Scrum et Kanban.
Scrum vs Kanban: deux méthodologies, un choix
Avant d'arriver à une sélection aussi difficile, vous pourriez probablement être confronté à un autre dilemme préliminaire lié au choix entre
Waterfall vs Agile . Cependant, vous avez fait le bon choix et vous êtes maintenant confronté à deux voies indépendantes dans le monde du développement Agile.
Scrum et Kanban sont deux branches de la famille Agile (cependant, beaucoup de gens ne considèrent pas Kanban comme une méthodologie indépendante et la distinguent des autres méthodes). Les deux sont flexibles et itératifs.
Une
enquête a été menée en 2018 auprès de 101592 développeurs de logiciels du monde entier. Près de 86% d'entre eux utilisent Agile dans leur travail. Semble impressionnant, non?
Scrum ou Kanban: quel est le meilleur choix?
Scrum permet aux gens de résoudre des problèmes adaptatifs complexes, tout en fournissant de manière productive des produits de la plus haute valeur.
Le framework Scrum est léger et simple à comprendre mais peut être difficile à maîtriser. Il se compose de courtes itérations ou sprints, qui durent généralement 2-3 semaines.
La liste des fonctionnalités possibles pour l'itération est créée par l'équipe. Ensuite, ils commencent à courir un Sprint. En règle générale, les fonctionnalités qui sont travaillées pendant un sprint ne changent pas. Ce qui a commencé au début doit de toute façon être fait à la fin.
Scrum contient divers termes, concepts et artefacts. Pour les comprendre tous, lisez et étudiez et le
glossaire Scrum ou le guide ultime.
Kanban peut être présenté du point de vue du lieu où il a été créé - société Toyota.
Les lignes de convoyeurs de tous les jours produisent les composants des voitures. Une machine spéciale conçoit des rétroviseurs pour les voitures Toyota: rétroviseurs gauche, droit, arrière et rétroviseurs pour pare-soleil. Un seul clic sur un bouton, le mode est changé et ils obtiennent un nouveau produit.
Le moment clé ici est qu'ils peuvent changer de priorité à tout moment. Ils sont capables de basculer la machine dans un mode différent et c'est tout.
Cependant, si vous avez besoin de plus de théorie sur Kanban, vous pouvez le considérer comme un système visuel pour gérer le travail au fur et à mesure qu'il avance dans un processus. Il visualise le flux de travail et le travail réel passant par ce processus.
Kanban aide à identifier les goulots d'étranglement potentiels dans les processus et à les corriger pour fournir un flux rentable.
La principale différence entre Scrum et Kanban est la longueur de l'itération:
- Vous travaillez pendant 2 semaines dans Scrum.
- Dans Kanban, vous pouvez fournir aux développeurs des tâches même tous les jours.
Kanban est plus flexible. Imaginez que vous avez publié hier une nouvelle fonctionnalité sur le serveur de production avec quelques événements pour suivre les KPI de la fonctionnalité.
Avec l'aide de l'analytique, votre chef de produit comprend que quelque chose s'est mal passé. Il décide d'apporter quelques modifications à la logique de la fonctionnalité. Il met la tâche sur un tableau Kanban et la soulève dans une colonne. Dès que le programmeur est libre, il reprendra cette tâche et la libérera juste après le test. Cela prendra plusieurs jours pour tout.
Dans le cas de Scrum, vous devrez attendre un Sprint entier, soit 2-3 semaines.
Scrum nécessite une estimation de tâche avec des Story Points ou des Heures. Vous ne pourrez pas former un Sprint sans cette estimation. Et vous devez savoir exactement si vous terminerez toutes les tâches en 2 semaines.
Après 2 semaines, vous obtenez des statistiques précieuses sur le nombre d'histoires ou d'heures que votre équipe a réussi à terminer pendant un sprint. Avec l'aide de ces informations, un Scrum master prédira où l'équipe sera dans 2 semaines.
Dans Kanban, les gens peuvent également estimer, mais cela est facultatif. Il n'y a pas de vitesse d'équipe. Vous prenez en compte uniquement un temps moyen pour l'achèvement de la tâche et comptez-le dans un rapport de durée de cycle.
Temps de cycle de tâche = Temps passé à travailler sur une tâche - Heure de début de la tâcheImaginez simplement que l'objectif actuel dans Scrum est de terminer un sprint mais pour Kanban, vous devez terminer une tâche.
De la théorie à la pratique: comment nous procédons
Limitation du balayage
WIP est Work in Progress. Il est important de limiter le nombre de tâches sur lesquelles les spécialistes peuvent travailler en même temps. Oui, il n'y a pas de César et Napoléon parmi nous pour être célèbres pour leurs incroyables compétences multitâches.
C'est optimal lorsque les gens ne travaillent qu'à une seule tâche à la fois. Il faut généralement
15 minutes à un développeur pour passer d'une tâche à une autre.
Vous avez besoin de temps pour faire du thé, pour parcourir certains articles sur le Web, pour lire les exigences d'une nouvelle tâche, pour vous rappeler où vous avez fait une pause et trouvé cet endroit dans le code.
Assurez-vous que passer d'une tâche à une autre consiste à quitter un cheminement de pensées vers une autre et il n'est pas toujours facile de revenir en arrière.
Couloirs de natation
Personne n'est à l'abri des pannes et votre site peut ne pas fonctionner pendant les heures d'ouverture. Vous créez et attribuez une tâche pour la corriger immédiatement à votre ingénieur DevOps, par exemple.
Mais il fait une autre tâche et prévoit de l'achever demain pour le déjeuner. Que faire? Ce n'est pas une bonne idée de tourner autour de lui, de taper sur l'épaule et de mendier pour passer à un bloqueur. Vous pouvez le faire une fois, mais est-ce la bonne façon d'agir? Certainement non, c'est pourquoi nous utilisons Swimlanes.
Dans cet exemple, le "Blocker" Swimlane est la solution, obligeant le développeur à arrêter immédiatement sa tâche actuelle, à la mettre en pause et à commencer à bloquer les choses.
Nous utilisons également un couloir de navigation «un jour» qui couvre toutes les tâches que nous effectuerons probablement un jour sous ce bloc.
Le Swimlane permet de mettre de côté toutes les choses inutiles afin que les gens puissent se concentrer sur les tâches importantes.
Sous-colonnes
Il y a une colonne «Codage» et une «Test» juste après. Lorsque le développeur a terminé sa tâche, il la déplace vers le "Test". Vous pensez peut-être que le testeur a déjà commencé à travailler sur cette tâche, mais en fait, il en fait une autre. Une fois que le développeur a déplacé la tâche pour les tests, il perturbe la limite WIP pour le contrôle qualité. C'est un vrai défi!
En fait, le développeur est libre de ne pas déplacer cette tâche dans la colonne "Test" et la laissera dans la colonne "Codage". Ce n'est pas bon non plus car sa tâche restera dans la colonne "En cours", bien qu'il l'ait déjà terminée.
Néanmoins, comment entreprendre la prochaine tâche si les limites WIP ne doivent pas être dépassées? Les sous-colonnes aident. Le développeur déplace simplement la tâche terminée de la sous-colonne "Codage à faire" vers la "Codage terminé". Et le testeur, le moment venu, effectuera une nouvelle tâche de test dans la sous-colonne "Coding Done".
Réflexions finales
Pour résumer tous ensemble, définissons Scrum comme une méthodologie de développement flexible, mais nommerons Kanban encore plus flexible.
Scrum est plus esthétique au début du développement de produits car il permet de gérer plus facilement les délais. De plus, il y a suffisamment de communication dans les équipes. Ils discutent en détail de Sprint Backlog avant le début.
Ils discutent des tâches avec leurs créateurs. L'équipe estime les tâches selon le système Planning Poker. En fait, Scrum aide à comprendre le cœur du produit.
Cependant, après le lancement du produit, vous recevez des commentaires des utilisateurs et vous devez réagir rapidement. Vous commencez à mesurer et à optimiser les métriques du produit, tout casse votre cycle de développement en unités plus petites et vous commencez à faire de nombreuses petites tâches dans le chaos. C'est le bon moment pour rappeler Kanban parfait pour un tel cas.
Avez-vous appliqué les deux méthodologies? Quel est votre favori dans l'opposition Kanban vs Scrum?