Skip to main content

Comment les ingénieurs en logiciel peuvent utiliser la méthode Kanban - la muse

#35 Impossible de remettre en question Scrum : "Bien sûr qu'on est Agile !" - Scrum Life (Avril 2025)

#35 Impossible de remettre en question Scrum : "Bien sûr qu'on est Agile !" - Scrum Life (Avril 2025)
Anonim

Vous connaissez Scrum, non? Je suppose que oui étant donné que The Scrum Alliance compte plus de 400 000 membres, et parmi ceux-ci, la plupart l’utilisent avec succès dans leurs organisations.

Mais ce n’est pas le seul moyen de créer des logiciels de manière agile, sérieusement! Avez-vous entendu parler de Kanban?

Pour un peu d’arrière-plan, il s’appliquait à l’origine à la fabrication sans gaspillage afin de visualiser l’entrée et la sortie du travail lorsqu’il passait dans une usine. Cette visualisation a été présentée sur un tableau appelé «attendez-le», Kanban. Plus récemment et plus pertinent pour vous, il a été adopté comme méthode de gestion du développement logiciel.

Décrit pour la première fois par le neurologue David J. Anderson, il s’agit d’une manière d’organiser le développement et la planification de logiciels qui vous permet de détecter les problèmes de processus et d’apporter des améliorations importantes à votre produit, ce qui, je le sais, semble idéal. En termes simples, à tout moment, vous pouvez voir où le travail (représenté par des cartes) est en cours de développement.

Comment ça marche

Le tableau Kanban de base utilise six colonnes indiquant l'emplacement de chaque travail dans le cycle de développement du produit. Voici un exemple approximatif de ce à quoi il ressemble.

Voir cet exemple de tableau Kanban sur Trello.

Colonne 1: arriéré

La colonne Backlog doit contenir une liste priorisée d'idées, de bogues ou de besoins opérationnels. La carte n'a pas encore besoin d'une tonne de détails, mais elle devrait contenir suffisamment d'informations pour que les membres de votre équipe comprennent pourquoi elle est importante.

Colonne 2: Planification

Dans cette colonne, un chef de produit remplit une spécification pour la fonctionnalité en rencontrant des parties prenantes de l'entreprise, des ingénieurs et des concepteurs. Quand il sera prêt, il le déplacera dans la colonne «Prêt pour l’ingénierie».

Colonne 3: Prêt pour l'ingénierie

A ce stade, toutes les cartes doivent avoir des spécifications détaillées. Bien que vous ayez peut-être encore des questions sur les détails techniques, les exigences opérationnelles doivent être claires.

Colonne 4: en cours

Vous pouvez déplacer une carte vers «En cours» à tout moment. Ce système «tiré» autonome crée une culture de responsabilité personnelle et de curiosité.

Colonne 5: Test

Une fois que vous avez terminé de travailler sur la carte, déplacez-la sur «Testing» (Test) où un autre ingénieur (ou une personne de l'équipe d'assurance qualité) la prendra en charge.

Colonne 6: déployé

Une autre caractéristique est que le travail doit être fourni en permanence dans un environnement de transfert ou de production. Cette colonne permet à tous les membres de l’équipe de voir quels travaux ont été publiés récemment.

Les avantages et les compromis

Lorsque vous choisissez entre Kanban et une méthodologie plus courante telle que Scrum ou Waterfall, gardez ces avantages et défis à l’esprit:

Avantage: améliore la collaboration

Dans certaines équipes de développement avec lesquelles j'ai travaillé, les ingénieurs étaient des spécialistes. Chaque équipe aurait un couple d'ingénieurs frontend et des ingénieurs backend. Cela signifiait que le travail était souvent bloqué parce qu'un ingénieur était occupé à autre chose.

Le kanban, en revanche, limite les travaux en cours et décourage les blocages. Chaque membre de l'équipe ne peut travailler que sur un élément à la fois, et quiconque n'est pas occupé peut extraire du travail en haut de la colonne «Prêt pour l'ingénierie». Cela encourage les ingénieurs généralistes et la collaboration entre les membres de l'équipe.

Augmentez les bénéfices: ne laissez pas les choses passer avant qu'elles soient prêtes

Kanban ne fonctionne que lorsque vous attendez que les cartes soient déplacées de la colonne suivante jusqu'à ce qu'elles soient complètement terminées. (Bonus: Cela minimise grandement les défauts.)

Défi: décourage le temps de réfléchir

Par défaut, il n'y a pas de sprints dans le temps avec des objectifs, des dates et des cycles de publication clairs. Au lieu de cela, considérez chaque carte comme une pièce indépendante pouvant être complétée et publiée à tout moment.

Avec ce flux continu de travail, il n'y a pas d'option «attendre jusqu'au prochain sprint». Vous devez vérifier en permanence le tableau, extraire l'élément suivant et déplacer les éléments terminés en aval. À moins que vous ne preniez suffisamment de temps pour les rétrospectives et les relèvements, il pourrait être difficile pour les membres de l'équipe de suivre leur rythme.

Se débrouiller: emprunter ce qui fonctionne de Scrum

J'ai utilisé les bilans quotidiens et les rétrospectives avec Kanban et j'ai constaté qu'ils apportaient une valeur ajoutée. S'il y a des réunions régulières ou des modèles qui fonctionnent pour votre équipe, ne les changez pas pour adhérer de façon dogmatique au Kanban. Prévoyez du temps pour parler des priorités et de leur évolution afin que tout le monde sache ce qui se passe dans le cycle de développement du produit.

Avantage: augmente la transparence

Chaque développeur doit prendre l’initiative de déplacer une carte dans la colonne «En cours». Cela signifie qu'à tout moment, le responsable de l'équipe peut déterminer qui est occupé, qui ne l'est pas et combien de temps un travail a été en cours.

Lorsque la production ralentit ou s’arrête, Kanban vous permet de voir exactement pourquoi. Que ce soit parce que l’équipe commerciale n’a pas classé les éléments de son carnet de commandes en ordre de priorité, que l’équipe produit n’a pas terminé les spécifications, que l’équipe de développement avance plus lentement que prévu ou que l’équipe d’assurance qualité n’a pas pu tester quelque chose; les goulots d'étranglement sont évidents.

Augmenter l'avantage: permettre au progrès d'être public

L'un des avantages est que Kanban est très visuel. Même les membres d’équipe non techniques peuvent consulter un tableau Kanban et indiquer où en sont les travaux. Utilisez ceci à votre avantage et permettez aux réalisations de l'équipe de briller en plaçant votre conseil dans un lieu public.

Défi: ne permet pas de planification à long terme

S'inquiéter des délais et des estimations n'est pas l'utilisation la plus productive de votre temps. Vous comprendrez donc peut-être que le Kanban concerne davantage la production quotidienne. Cela dit, il ne fournit pas à lui seul de système permettant d’élaborer un plan à long terme. Cela peut vous amener à travailler sporadiquement sur des projets plutôt que de vous concentrer sur une chose pendant longtemps. Il est difficile de passer une journée sur le projet A, puis une journée sur le projet B, puis de revenir au projet A.

Obtenez autour de lui: Utilisez-le lorsque vos priorités changeront probablement

Chaque colonne de votre tableau est indépendante des autres. Les membres de l’équipe peuvent donc déplacer des éléments à tout moment. Cela peut gêner les développeurs dans un paramètre Scrum (où les estimations pour le sprint sont faites au départ), mais Kanban prospère dans ce type d’environnement en évolution rapide.

Tout le monde veut être plus productif, mais il peut être difficile d'essayer quelque chose de nouveau si vous ne savez même pas par où commencer. J'ai trouvé Kanban utile et j'espère que vous le trouverez également utile pour votre flux de travail personnel (ou même pour toute votre équipe!).

Tweet moi si tu décides de tenter le coup!