Dans le développement Agile, les limites WIP déterminent la quantité de travail minimale et maximale autorisée pour chaque état d'un workflow. Limiter la quantité de travail en cours facilite l'identification des problèmes d'efficacité dans le workflow d'une équipe. Les goulots d'étranglement dans le pipeline de livraison d'une équipe sont clairement visibles avant qu'une situation ne devienne désastreuse.

À présent, vous pensez : « Dites-m'en plus ! » (En tout cas, je l'espère.)

Les limites du travail en cours (WIP) améliorent le débit et réduisent la quantité de travail « pratiquement terminé » en obligeant l'équipe à se concentrer sur une série de tâches restreinte. Les limites WIP encouragent la culture du « terminé ». Mais surtout, elles mettent en évidence les bloqueurs et les goulots d'étranglement. Les équipes peuvent se pencher sur les tickets paralysants afin de les comprendre, de les implémenter et de les résoudre lorsque l'origine du goulot d'étranglement a été clairement identifiée. Une fois ces blocages éliminés, le travail au sein de l'équipe retrouve sa fluidité. Grâce à ces avantages, les clients bénéficient plus tôt d'une valeur ajoutée accrue. Les limites WIP sont donc un outil précieux dans le développement Agile.

Pendant le développement, il est facile de se dire : « Je vais laisser de côté ce ticket et commencer à travailler sur un autre ». Ouvrir deux tickets en parallèle implique un basculement de contexte entre deux tâches différentes ou un transfert de travail entre deux membres de l'équipe. Ralentir sur un ticket et accélérer sur un autre n'est pas sans conséquence.

Cela prend du temps et nuit à la concentration. Mieux vaut souvent terminer le premier ticket plutôt que de démarrer, et ne pas achever, une nouvelle tâche. En d'autres mots, les limites WIP nous dissuadent d'entraver notre propre flux. 

Enfin, les limites du volume de travail en cours signalent les points d'inactivité ou de surcharge chronique. Elles aident les membres de l'équipe à visualiser les inefficacités sur l'ensemble du processus, plutôt que le seul domaine sur lequel ils travaillent.

Maintenant que vous en connaissez l'intérêt, venons-en aux faits.

Lorsque vous déployez un nouveau workflow, définissez, en équipe, les limites WIP pour chaque état. Nous vous conseillons de définir les limites WIP après avoir contrôlé, pour quelques sprints, le nombre moyen de tâches à chaque état. Vous trouverez, ci-dessous, un exemple de tableau Agile avec les limites WIP utilisées par une équipe de développement type.

Ci-dessus, une limite WIP a été définie pour la revue du code. Étant donné que la colonne dépasse la limite, l'arrière-plan est passé au rouge.

Étant donné qu'il n'y a plus rien à faire lorsqu'un ticket est à l'état « Terminé », il n'y a pas besoin, dans ce cas, de limiter le volume de travail en cours. Dans le tableau Kanban ci-dessus, l'état « To do » (Àfaire) signifie que la user story a été entièrement approuvée par le Product Owner et par l'équipe. L'équipe de développement fait passer une tâche de l'état « To do » (À faire) à l'état « In progress » (En cours) lorsqu'elle commence à travailler sur cette tâche. Au titre des bonnes pratiques, il est important de conserver suffisamment de tâches à l'état « To do » (À faire) afin que chaque membre de l'équipe de développement reste pleinement occupé. En gardant juste ce qu'il faut de user stories à l'état « To do » (À faire), le Product Owner n'anticipe pas trop sur l'élaboration des exigences. De plus, le programme devient davantage réactif au changement.

L'état « En cours » répertorie les tâches en développement actif. L'objectif des limites WIP, dans ce cas, est de s'assurer que tous ont du travail, mais que personne n'est en multitasking. Dans le tableau ci-dessus, la limite de tâches « En cours » est définie à 4. Or, il y a actuellement 3 tâches à cet état. Cela indique que l'équipe est en mesure d'accepter une tâche de plus. Au titre des bonnes pratiques, certaines équipes définissent une limite WIP maximale qui est inférieure au nombre de membres dans l'équipe. L'idée est de laisser de la place pour les bonnes pratiques Agile. Si un développeur termine une tâche, mais que l'équipe a déjà atteint sa limite WIP, le moment est venu d'éliminer quelques revues de code ou de contacter un autre développeur pour une programmation en binôme.

L'état « revue du code » désigne les user stories qui ont été complètement créées, mais qui doivent être révisées avant leur merge dans la base de code. Les revues du code ponctuelles constituent une bonne pratique. Elles définissent la qualité, accélèrent la commercialisation des innovations, facilitent les merges en réduisant les branches ouvertes et diffusent les connaissances au sein de l'équipe d'ingénierie. Les tâches à cet état doivent être traitées en urgence, et ce pour différentes raisons :

• Le code ne moisit pas pendant que les membres de l'équipe enregistrent un nouveau code

• Le développeur ne perd pas le contexte qu'il a acquis lors de la création du code original

• La fonctionnalité peut faire l'objet d'un merge dans la branche principale pour la livraison

Les limites WIP évitent que le code non révisé ne s'accumule. 

Remarque : dans le tableau ci-dessus, l'équipe a trop de revues de code. Pour le signaler, la colonne apparaît en rouge.

Comme toute nouvelle activité, les limites du volume de travail en cours peuvent, dans un premier temps, générer un peu d'inconfort. L'objectif ici est d'optimiser l'équipe à moyen terme. Et cet inconfort à court terme est, en fait, plutôt positif. Il incite l'équipe à ressentir les points douloureux dans son processus. Une fois que l'équipe aura utilisé les limites du volume de travail en cours pendant quelques semaines, ajustez-les, le cas échéant. Résistez à la tentation d'élever une limite du volume de travail en cours uniquement parce que l'équipe ne cesse de l'atteindre. Profitez de l'occasion pour augmenter les capacités, dans l'idéal en formant l'équipe et en fournissant à chacun de ses membres de nouvelles compétences ou en améliorant, même partiellement, l'efficacité du processus de développement.

Objectif 1 : dimensionner les différentes tâches de façon cohérente. Lorsque vous divisez les exigences et les user stories, il est important de limiter les différentes tâches à 16 heures de travail maximum. Vous augmenterez ainsi la capacité de l'équipe à réaliser des estimations fiables et éviterez les goulots d'étranglement. Rien ne ralentit plus une équipe et n'allonge plus les limites WIP qu'une tâche titanesque qui bouche le pipeline.

Objectif 2 : Associer les limites WIP aux compétences de l'équipe. L'exemple ci-dessus part du principe que les membres de l'équipe présentent des compétences similaires. Si votre équipe fait intervenir des spécialistes sur une tâche, les limites WIP peuvent varier lorsque l'un de ces spécialistes est impliqué. Créez un état spécifique pour le travail du spécialiste. Si des goulots d'étranglement surviennent à cet état, profitez de l'occasion pour former les autres membres de l'équipe afin d'augmenter les capacités correspondant aux compétences du spécialiste et améliorer le flux dans l'ensemble de l'équipe.

Objectif 3 : Réduire l'inactivité. Lorsqu'un membre de l'équipe a un peu de temps libre, encouragez-le à aider un collègue en amont ou en aval. Il contribuera ainsi à la productivité globale de l'équipe et en profitera pour apprendre quelque chose !

Objectif 4 : Préserver une culture d'ingénierie durable. Les limites WIP ne signifient pas que les développeurs doivent se précipiter dans le travail pour éviter les surcharges à un état donné. Elles ont pour but de favoriser les bonnes pratiques d'ingénierie Agile, lesquelles préservent la qualité du produit et l'intégrité de la base de code. 

Si votre équipe est prête à implémenter des limites WIP, utilisez notre modèle de tableau Kanban pour commencer gratuitement.