Les équipes logicielles d'aujourd'hui sont, au moins dans leurs processus, plus agiles! Ils sont prêts à penser en dehors des paramètres définis pour suivre ce qui fonctionne pour eux. Ils sont désireux d'apprendre et d'adopter de nouvelles techniques de gestion de projet et de processus de projet.
Une méthode de gestion de projet appelée Kanban fait le tour de l'industrie du logiciel depuis plusieurs années et a gagné du terrain au cours des cinq dernières années. Avec les méthodologies Agile, l'adoption de la méthode Kanban a donné beaucoup de raisons aux entreprises.
Mais il y a aussi la critique selon laquelle Kanban n'est rien d'autre qu'une liste de choses à faire glorifiée. Alors de quoi s'agit-il? Découvrons-le.
Qu'est-ce que Kanban?
Si votre entreprise est prête à dépasser l'approche traditionnelle de gestion de projet logiciel, aujourd'hui, les techniques de gestion de projet ne manquent pas.
D'une part, il y a le système de gestion de projet Agile, qui se concentre sur les méthodes itératives non linéaires de développement de logiciels. L'utilisation de méthodes Agiles est évidente dans Scrum, qui se concentre sur une approche plus flexible de la gestion de projet.
Agile a également des liens avec d'autres cadres de gestion de projet tels que Kanban et Extreme Programming. Parmi ceux-ci, Kanban a atteint beaucoup de popularité. Après tout, qui ne veut pas d'un processus développé par les Japonais?
Kanban est un concept qui a évolué à l'usine de fabrication de Toyota pour atteindre une production juste à temps (JIT) qui réduit les coûts et permet une utilisation moindre des ressources. En son cœur, il suit le principe du «pull» du travail, ce qui signifie que les tâches ou les produits doivent être «tirés» par les exigences et la demande, et non «poussés» de haut en bas. Il a été développé pour assurer un meilleur stockage des composants automobiles dans les usines Toyota, en fonction de la demande. Cela signifiait qu'à mesure que la demande augmentait, les demandes seraient remplies.
Le concept a été adapté à l'industrie du logiciel avec quelques changements par David Anderson, dans son livre de 2010, Kanban . Depuis lors, il a été utilisé pour divers projets avec beaucoup de succès. Il peut être extrêmement utile dans des projets complexes qui ont le potentiel de souffrir d'une surcharge d'un côté du cycle de développement.
Fondamentalement, le système Kanban traite le processus de projet logiciel comme un pipeline. Supposons qu'un processus logiciel comporte trois types de tâches: analyse, développement, test et enfin, déploiement. Disons qu'il y a vingt tâches à accomplir.
Dans le cas d'un système de gestion de projet traditionnel si, par exemple,
- Il y a 25 histoires au total
- Les analystes sont capables de gérer cinq histoires par semaine
- Les développeurs sont capables de gérer cinq histoires par semaine
- Les testeurs sont limités à trois histoires par semaine
Dans cette situation, le travail s'accumule simplement du côté des testeurs. À la fin de la semaine 1, la situation sera la suivante:
- Seules trois histoires sont passées au déploiement.
- Les développeurs et les analystes travaillent sur trois histoires, car les testeurs ne peuvent pas prendre la sortie des développeurs et tester la même chose.
- Le travail s'accumule, laissant les développeurs et les analystes et le chef de projet, dans une correction.
Les analystes et développeurs peuvent maintenant simplement se tourner les pouces! Ou leur manager peut se rendre compte qu'ils sont inactifs et les réaffecter à un autre projet, où une situation similaire peut survenir. Il y a donc deux projets qui sont maintenant bloqués en phase de test!
Les problèmes dans une telle situation ne sont pas difficiles à voir. Quel est l'intérêt de développer dix histoires (ou morceaux de logiciel) alors qu'ils ne seront pas testés de si tôt?
Passons maintenant à la méthode Kanban.
La méthode Kanban est un concept extrêmement simple. Il suit une logique simple consistant à utiliser une «méthode d'extraction» pour éliminer d'abord les goulots d'étranglement et à limiter les travaux en cours (WIP) pour de meilleurs processus de travail.
Dans sa forme la plus simple, Kanban, littéralement, le «tableau visuel» aide en «retirant» les éléments d'une liste de tâches, plutôt que de travailler avec des lignes de temps. La méthode Kanban permet d'identifier les goulots d'étranglement afin de mieux gérer le flux de processus.
Un tableau Kanban de base contient une liste des tâches à effectuer, des tâches en cours et des tâches terminées.
Dans la gestion de logiciels, cependant, les tâches peuvent être un peu plus complexes. La plupart des projets Agile ont également un conseil d'administration similaire. Dans un tableau Kanban, les étapes du déploiement sont clairement marquées, ainsi qu'un numéro pour chaque colonne. Ce nombre représente le nombre maximal de tâches ou d'histoires qu'une étape particulière peut gérer.
Notre exemple sur un tableau Kanban ressemblerait à quelque chose comme ça, au début de la deuxième semaine. Cela signifie que les développeurs et les analystes ne travailleront pas sur le nombre optimal d'histoires cette semaine. Il est évident que le travail s'accumule du côté du testeur. Et les organisations peuvent s'assurer que les équipes travaillent ensemble pour effectuer les tests. Alternativement, ils peuvent examiner d'autres modèles de flux de processus afin que cela ne se produise pas.
Lorsque les projets sont gérés via le système Kanban, il y a moins de possibilités pour que le travail soit empilé. Les histoires sont reprises en fonction de la bande passante maximale disponible.
Dans une configuration Kanban typique, le travail sera repris en fonction de la bande passante disponible, et le travail sera tiré par les équipes, afin qu'elles soient toujours à leur capacité maximale. Le système permet également une accélération, pour les tâches urgentes, afin qu'elles se déplacent à travers la planche avec un minimum d'effort.
Jetez un œil à ce tableau Kanban.
Il est clair que toutes les étapes fonctionnent avec une efficacité maximale. Et la tâche qui est sur la «voie rapide» est également prise en compte.
Kanban n'est en aucun cas la seule méthode utilisée pour augmenter l'efficacité en limitant le WIP. Il existe d'autres systèmes qui atteignent le même résultat, par exemple les systèmes CONWIP (Constant Works in Progress) et DBR (Drum-Buffer-Rope), qui sont principalement destinés aux industries manufacturières.
Cependant, Kanban est le système qui a été le mieux modifié pour convenir à l'industrie du logiciel.
En quoi Kanban est-il différent des méthodologies agiles?
Au fond, Kanban est une méthodologie qui utilise certains éléments de la gestion de projet Agile. De nombreux projets dans le cadre Agile ont leurs racines dans les approches Lean. La différence entre la méthodologie Kanban et la gestion de projet Agile n'est pas aussi noire et blanche que les partisans des deux méthodes voudraient nous le faire croire. Ils ont plus en commun que les différences.
Le cadre Agile n'est pas un absolu. La question n'est pas de savoir si les équipes sont Agiles ou non. Les équipes ont souvent une agilité à des degrés divers. L'une des méthodes pour avoir plus d'agilité dans votre processus de développement logiciel est d'utiliser Kanban.
Il existe quelques différences entre les méthodologies Kanban et Agile. Certaines des fonctionnalités du développement Kanban, qui sont un peu différentes d'Agile, sont:
- Les délais ne sont pas un facteur significatif . Il s'agit d'un concept difficile à comprendre, car il semble très non intuitif. «Comment travaillez-vous sans délais?» Demandent souvent les gens. Mais si chaque membre de l'équipe est engagé à son maximum d'efficacité, alors le temps cesse d'être un facteur.
- Les histoires (tâches) sont plus volumineuses que dans les systèmes Agile typiques. En règle générale, la longueur et la complexité des histoires sont plus longues qu'avec un projet Scrum typique. Étant donné que l'accent n'est pas mis sur l'estimation du temps, mais simplement sur la poursuite du processus, Kanban peut se permettre de travailler sur des histoires plus importantes.
- Il n'y a pas de changement significatif dans les processus existants. Les principes de Kanban pour le développement de logiciels, tels qu'articulés par son fondateur, David Anderson, dans son blog, comprennent les principes de base suivants:
-
- Commencez par ce que vous faites maintenant
- Accepter de poursuivre un changement évolutif progressif
- Respecter le processus, les rôles, les responsabilités et les titres actuels
- Chaque histoire est mesurée en temps de cycle . Le projet est évalué non pas par le calcul Agile traditionnel de la vitesse (le nombre d'histoires achevées pendant un temps donné), mais par le temps de cycle. Cela signifie que Kanban met l'accent sur le temps qu'il a fallu pour terminer une tâche. Vous pouvez souvent voir un ticker sur de nombreux tableaux Kanban qui mentionne le nombre de jours que l'équipe prend pour terminer une histoire. Cette estimation alimente le cycle suivant.
Kanban: un conseil d'administration, mais quoi d'autre?
Donc, Kanban est un tableau qui nous montre comment les histoires sont organisées - est-ce que même si gros, beaucoup demandent. En fait, il y a beaucoup de discussions sur ce que Kanban est et peut faire.
Kanban est-il juste une méthode pour gérer le workflow? Ou est-ce quelque chose que l'on peut utiliser avec les méthodologies Agiles pour une efficacité maximale? Ou, peut-il s'agir d'une toute nouvelle façon de gérer le flux de travail?
Chaque équipe utilise Kanban comme bon lui semble, pour sa situation particulière. Quoi qu'il en soit, Kanban a le potentiel de fonctionner comme un mode de vie pour le développement de logiciels, s'il est utilisé à son niveau optimal.
Qu'il soit utilisé pour gérer le flux de travail ou comme un nouveau paradigme dans le développement de logiciels, il est indéniable qu'il aide à gérer les WIP.
Pour que Kanban fonctionne au mieux, il est important de le considérer non seulement comme la gestion des WIP, mais comme un cadre de gestion de projet. Certaines directives de base aideront le processus.
- Optimisez les équipes afin qu'aucune équipe ne commence quelque chose qu'elle ne peut pas terminer. Cela aide le processus.
- Ne résistez pas aux modifications du système Kanban d'origine. Si votre projet réussit bien avec les délais et les délais, incorporez-les comme vous le feriez. Cela crée un environnement de développement plus sain et plus robuste.
- Ne fuyez pas le travail d'équipe. Kanban peut sembler, mais n'est pas, un modèle basé sur des individus travaillant de manière isolée. Le travail d'équipe doit faire partie intégrante du développement du logiciel Kanban.
- Sortez des sentiers battus. Pensez aux changements dans le flux de travail. De nombreuses équipes optent désormais pour le développement piloté par les tests, avec le développement piloté par les tests d'acceptation, où les tests d'acceptation sont d'abord effectués avec des cas d'utilisation, qui déterminent ensuite les fonctionnalités requises et la nature du développement.
Hybrides
Comme de plus en plus d'entreprises utilisent les outils de gestion de projet les mieux adaptés à leur situation particulière, il n'est pas surprenant que deux des meilleures méthodologies de gestion de projet: Scrum et Kanban, aient été intégrées avec beaucoup de succès.
L'hybride, appelé Scrumban, fait des percées dans de nombreux projets.
Si une organisation utilise déjà Scrum, mais a du mal à maintenir le projet ensemble, que ce soit avec des sprints qui ne fonctionnent pas bien, ou que les tests ne soient pas hermétiques, il serait peut-être temps d'envisager Scrumban.
Pour l'expliquer simplement, Scrumban a impliqué de prendre une loupe pour les sprints. Il ne s'agit pas seulement des sprints dans le cadre du projet, il s'agit de ce qui se passe au sein des sprints. Scrumban aide à voir comment une histoire est traitée dans un sprint, et cela pourrait faire toute la différence.
Scrumban, ou l'une de ses variantes, est un changement minimal par rapport aux pratiques existantes. La beauté de l'utilisation de Kanban est qu'il peut être utilisé avec pratiquement n'importe quel type de modèle de gestion de projet: cascade, Agile ou quoi que ce soit entre les deux.
Premiers pas avec Kanban
Il est facile de démarrer avec le système Kanban. Il est également possible d'implémenter Kanban de manière minimale en tant qu'essai pour une partie particulière d'un projet.
- Cartographiez le processus de développement logiciel. Faites une carte claire de l'ensemble du processus. Comment le projet, de la conception initiale au développement, en passant par les tests, les changements de fonctionnalités, fonctionne-t-il dans la réalité?
- Énumérez les étapes où Kanban sera utilisé. Utilisez les étapes qui sont entièrement sous votre contrôle. Cela comprend généralement les phases d'analyse, de développement, de révision et de test.
- Travaillez sur des points importants tels que:
- Limites des travaux en cours pour chaque étape.
- Processus pour le travail accéléré / bloqué
- Estimations au verso de l'enveloppe en ce qui concerne le temps de cycle
- Fréquence de l'examen du tableau / processus / devis Kanban
- Achetez un tableau blanc et une pile de notes Post-It.
- Commencer
- Passez en revue au besoin.
- Répéter
Alors, allez-y et lancez-vous sur Kanban!
N'ayez pas peur si cela ne se passe pas comme vous l'aviez prévu au départ. L'idée derrière les méthodologies Agile est de s'adapter aux changements de personnes et de processus! Faites-nous part de vos expériences avec la méthode Kanban.
Articles recommandés
- 6 Bureau de gestion de projet (PMO) le plus utile
- 8 étapes utiles pour créer des Story Maps sophistiquées pour votre projet
- Les 5 valeurs importantes de la programmation extrême (puissant)