Agile, Scrum et Kanban : que signifient vraiment ces mots ?

Lorsqu'un développeur de logiciels entend parler d'un « nouveau framework JavaScript » ou d'un « nouvel IDE », il n'a pas besoin de poser plus de questions pour clarifier de quoi il s'agit. Mais s'il entend parler d'un « nouveau cadre agile », il fera probablement le signe de tête homéro-simpsonien, prétendant qu'il sait de quoi il s'agit, mais il aura une, et une seule, question : qu'est-ce que le « cadre agile » diable fait ? signifier?

Dans l'environnement de développement logiciel moderne, nous entendons de plus en plus des mots comme « agile », « scrum » et « kanban », et ils sont souvent utilisés de manière inappropriée. Dans cet article, je vais essayer d'expliquer et de clarifier certains de ces termes.

Agile

Si vous voulez être le malin de la foule, vous devez utiliser le mot "agile" dans toutes les autres phrases lorsque vous parlez du processus de travail. Il a une portée assez large, ne vous oblige pas à connaître grand-chose sur le sujet dont vous parlez, et c'est un adjectif ou un adverbe vraiment sympa : "penser agile", "approche agile", "selon des principes agiles". Mais que signifie vraiment « agile » ?

« Agile » fait référence au « développement logiciel agile », l'approche du développement qui suit les principes agiles. Mais qu'est-ce que c'est que les « principes agiles » ? Jetez un œil au Manifeste Agile et aux 12 principes de l'agile, qui posent les bases du développement agile. Extrait du Manifeste :

Les principes agiles encouragent la livraison continue de logiciels fonctionnels, une communication étroite entre les équipes et une grande adaptabilité aux besoins changeants. Si vous suivez ces valeurs et principes dans votre travail, vous pouvez dire que vous travaillez dans un environnement agile. Ainsi, le développement logiciel agile n'est pas une méthodologie, c'est juste un ensemble de méthodologies, de cadres et de techniques différents qui suivent les mêmes principes. On peut dire que "agile" est un cadre pour penser et prendre des décisions.

Mais pourquoi est-il si important de suivre ces principes dans notre travail ?

Le Manifeste et les principes sont le résultat de la recherche des meilleures solutions qui ont évolué au fil des décennies en réponse aux défis du développement logiciel. Tout au long des années 70, 80 et 90, différents développeurs et équipes du monde entier ont expérimenté des méthodes de travail et des approches de résolution de problèmes, inventant différents cadres et techniques (tels que scrum et Extreme Programming), et sont même arrivés au même idées en parallèle. Finalement, en février 2001, dix-sept développeurs se sont réunis et ont trouvé les dénominateurs communs à toutes ces idées et expériences diverses. C'est ainsi que le manifeste a été créé.

Mêlée

Si vous parlez de méthodes « agiles » sans savoir ce qu'elles veulent dire, vous risquez de vous tromper et de dire des choses qui vous démasqueront devant l'interlocuteur qui connaît le sujet : « Scrum et autres méthodologies agiles ».

Scrum n'est pas une méthodologie, même si nous l'avons tous entendu appeler ainsi plus souvent que le nombre de meurtres dans Game of Thrones . Scrum ne donnera pas de réponse à toutes les questions et ne vous fournira pas la procédure précise pour répondre à chaque situation à laquelle vous êtes confronté. Et probablement à cause de cette interprétation incorrecte, la plupart des implémentations de Scrum sont également fausses : les équipes n'obtiennent pas de valeur. Cela se traduit probablement par la déclaration la plus stupide à propos de Scrum : « Scrum ne fonctionne pas ».

Qu'est-ce que la mêlée ? Le Guide Scrum définit Scrum comme :

C'est donc un framework , et comme tout autre framework, il peut être, et est régulièrement, utilisé de la mauvaise façon. L'utilisation efficace de Scrum nécessite non seulement d'adopter la structure définie par Scrum, mais aussi d'avoir une compréhension et une appréciation approfondies des principes agiles dans toute l'équipe.

Scrum se compose des rôles suivants : Product Owner, Scrum Master, Development Team.

Il y a aussi quatre cérémonies Scrum : Planning Meeting, Daily Scrum, Sprint Review, Sprint Retrospective

Et les trois artefacts : Product Backlog, Sprint Backlog, Product Increment.

Les projets Scrum sont organisés en délais réguliers, que nous appelons des sprints. Ils durent généralement deux semaines.

Un Product Owner est chargé de guider la direction du projet. Au fur et à mesure que de nouvelles tâches et fonctionnalités sont déterminées, le propriétaire du produit les ajoute à un backlog de produit. Un sprint commence par une réunion de planification au cours de laquelle l'équipe de développement sélectionne les tâches du backlog sur lesquelles travailler et planifie leur mise en œuvre. Vient ensuite le développement, au cours duquel l'équipe de développement utilise le backlog pour suivre les progrès et se réunit pour la réunion quotidienne afin de synchroniser les activités et d'ajuster le plan, si nécessaire. Le résultat du développement devrait être un incrément de produit, quelque chose qui peut être appliqué au produit et publié immédiatement. À la fin du sprint, l'incrément du produit est présenté au Product Owner lors de la revue de sprint, où le backlog du produit est augmenté si d'autres modifications sont nécessaires. Ensuite, toute l'équipe assiste à la rétrospective du sprint où ils parlent du processus de travail et comment il peut être amélioré.

Scrum est facile à apprendre et à comprendre, mais difficile à adopter. Il existe de nombreuses raisons pour lesquelles ce cadre peut ou non convenir à un projet. Cela nécessite souvent beaucoup de changements, non seulement dans le développement quotidien, mais aussi culturellement. Scrum convient le mieux au développement de produits complexes, ceux qui durent longtemps et qui impliquent différents types de spécialistes.

Pourquoi Scrum est-il si populaire et pourquoi a-t-il un avantage sur le modèle traditionnel en cascade ? En termes simples, car cela offre plus de valeur à un produit et à des clients. Avec des méthodes "lourdes" comme la cascade, les histoires d'horreur foisonnent dans lesquelles personne ne voit rien du projet pendant des mois. Avec Scrum, ce n'est pas possible.

Scrum est tout au sujet de la valeur qui est fournie aux utilisateurs finaux. Si vous utilisez vraiment Scrum, vous devez fournir quelque chose de valeur à chaque sprint. La valeur peut être mesurée, et l'équipe est également obligée d'inspecter les obstacles et de s'adapter, dans le but de fournir plus de valeur lors de la prochaine itération.

Dans la plupart des développements de logiciels, nous ne construisons pas un gratte-ciel ; nous n'avons pas besoin d'avoir tout le plan prêt avant de commencer et de nous en tenir à ce plan jusqu'à la fin. Nous développons des logiciels et nous avons la capacité de nous adapter à différentes situations et de modifier les exigences du produit au cours du développement. Pendant longtemps, de nombreux développeurs ont considéré cela comme le huitième péché mortel, mais du point de vue du produit, c'est un énorme avantage pour optimiser la prévisibilité et contrôler les risques. Scrum est développé autour de cette capacité, et sa mise en œuvre offre un moyen fiable et efficace de gérer les changements nécessaires.

De nombreuses techniques sont utilisées en conjonction avec Scrum : planning poker, programmation en binôme, développement piloté par les tests (TDD), développement piloté par le comportement (BDD) et autres. Ils ne font pas vraiment partie de Scrum, mais plutôt des techniques compatibles. Une méthode souvent mentionnée en même temps que scrum est le kanban, et il y a beaucoup de confusion sur ce que ces deux choses signifient l'une par rapport à l'autre.

Kanban

Lorsque vous parlez de scrum et de kanban, une question fréquemment posée par la foule sera : "Qu'est-ce qui est le mieux, scrum ou kanban ?" Et vous ne saurez pas quoi répondre parce que c'est comme comparer des pommes et des oranges, ou demander : « Qu'est-ce qui est meilleur, des pancakes ou de la bière ? Les deux sont meilleurs.

Kanban est une méthode simple qui vise une livraison juste à temps sans surcharger les membres de l'équipe. Il est similaire à Scrum en ce sens que l'objectif est de fournir une valeur maximale à la fin, mais il est beaucoup plus flexible que Scrum.

Kanban n'a pas été inventé par la communauté des développeurs de logiciels. En fait, il a ses origines dans les processus de fabrication de Toyota et il est largement utilisé dans d'autres domaines. Il n'y a pas de procédures strictes à suivre, ni de manière stricte de mettre en œuvre et d'utiliser le kanban ; il s'agit plutôt d'un ensemble de principes et de pratiques, et vous pouvez choisir parmi ces pratiques en fonction de vos besoins. Mais il existe une implémentation de kanban la plus souvent utilisée dans le développement de logiciels qui inclut l'utilisation d'un tableau kanban , composé de colonnes représentant les étapes de travail et les tâches.

Les colonnes représentent l'état d'une tâche dans le processus de développement. L'exemple le plus simple se compose de trois colonnes : "À faire", "En cours" et "Terminé". Ainsi, les tâches sont ajoutées à "À faire", déplacées vers "En cours" lorsque le développement démarre et considérées comme "Terminées" lorsqu'elles sont déplacées vers la dernière colonne. Mais bien sûr, cela pourrait être plus complexe :

Backlog → Définition des spécifications → Prêt pour le développement → Développement → Revue de code → Tests → Déployé (→ Personne ne l'utilise vraiment → Complètement supprimé).

Chaque colonne peut avoir des sous-colonnes ; par exemple, « Développement » peut être divisé en « Planification » et « Codage » ; Les "tests" peuvent être divisés en "tests unitaires" et "tests d'intégration", etc. Des colonnes pourraient être dédiées aux spécialistes, le cas échéant. L'équipe définit les colonnes et les étapes en fonction de ses besoins. Selon la philosophie « pull », les tâches ne doivent entrer dans le flux de travail que lorsque la demande est immédiate.

Le but de ce tableau est de visualiser le workflow , qui est la première pratique clé en kanban. En fait, le kanban peut se faire sans tableau du tout ! Il peut s'agir d'une simple liste de tâches dans une feuille Google avec différentes couleurs d'arrière-plan indiquant l'état de la tâche, ou il peut s'agir de diagrammes de Gantt, de diagrammes, de tableaux… Il peut même s'agir d'un ensemble de seaux dans votre bureau, où chacun représente l'état de la tâche et où les balles sont utilisées comme tâches. Visualisez simplement le flux de travail et assurez la transparence de l'ensemble du processus.

Un autre principe important consiste à réduire la taille du lot de vos efforts . Simplifié, cela signifie éviter le multitâche. Cela peut signifier réduire le volume de tâches sur lesquelles vous travaillez en même temps. Si vous avez trois concepteurs dans une équipe, l'équipe peut définir le nombre maximum de tâches dans la colonne "Conception" à trois.

Comme Scrum, Kanban considère également l'équipe comme la figure la plus importante du processus. Mais il ne suggère pas de rôles comme le fait Scrum, et vous pouvez conserver les rôles existants pour éviter d'apporter des modifications à votre processus existant. Il en va de même pour l'amélioration continue : Kanban vous encourage généralement à apprendre et à vous améliorer en continu, mais ne prescrit pas d'événement spécifique uniquement pour ce processus, comme le fait la rétrospective Sprint de Scrum.

Lequel dois-je utiliser ?

Scrum et kanban ne sont pas mutuellement exclusifs et pas vraiment comparables. Dans Scrum, il y a des rôles définis, tandis que Kanban dit : « Bon sang, gardez vos rôles et responsabilités actuels. Scrum vous forcera à changer votre façon de travailler ; kanban vous permet de démarrer avec votre processus existant. Dans Scrum, un calendrier clair des événements est prescrit par le cadre ; dans kanban, vous n'avez pas d'événements. Pourtant, ils présentent de nombreuses similitudes : les deux sont centrés sur les valeurs, les membres de l'équipe sont respectés en tant que « chefs » du système, et essentiellement, ils ont la même mission : éliminer en permanence le gaspillage et supprimer les obstacles.

Mais la question, "Que dois-je utiliser dans mon projet particulier et avec mon équipe particulière?" a beaucoup plus de sens. Kanban ne nécessite pas autant de processus et de changements culturels, et, dans la plupart des cas, il sera plus facile à adopter que Scrum. Scrum, d'autre part, offre beaucoup plus de structure pour guider le processus, ce qui peut éliminer beaucoup de frais généraux tant que tout le monde est sur la même longueur d'onde.

Mais la beauté des deux est qu'aucun n'est un ensemble de règles strictes. Rien ne vous empêche de choisir les meilleurs éléments Scrum pour vous, comme une réunion quotidienne ou un examen. Et il n'y a aucune raison pour que vous ne puissiez pas intégrer un tableau kanban dans Scrum.

Scrum s'est avéré être un cadre très efficace lorsque toute l'équipe le comprend bien. Cependant, d'après mon expérience, j'ai du mal à travailler en scrum avec certains clients. Le processus et les changements culturels requis pour une mise en œuvre correcte de Scrum peuvent être trop importants (surtout lorsqu'il s'agit de quelqu'un qui croit qu'il est en train de créer un nouveau Google !). D'un autre côté, le kanban est plus flexible et n'oblige pas les gens à changer. Certains auteurs disent également que le kanban est une bonne voie vers l'agilité et offre une mise en œuvre plus facile de Scrum. D'autres disent que l'utilisation de Scrum devrait conduire à un kanban à la fin.

La vérité est que chaque projet est différent et qu'il n'y a pas de solution unique. En tant que chef de projet, c'est à vous de déterminer ce qui fonctionne le mieux pour votre équipe.