Rendre au workflow sa « fluidité »grâce aux limites WIP

Les limites du volume de travail en cours ne sont pas là pour limiter réellement votre progression. En fait, c'est plutôt le contraire.

Dan Radigan Dan Radigan

Que sont les limites WIP ?

Dans le développement Agile, les limites WIP déterminent la quantité de travail minimale et maximale autorisée pour chaque statut 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.

Pourquoi les limites du volume de travail en cours sont-elles importantes ?

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

Les limites du volume de travail 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 essentiellement la culture du « terminé ». Elles mettent surtout 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 que ces blocages ont été éliminés, le travail retrouve sa fluidité au sein de l'équipe. Grâce à ces avantages, les clients bénéficient plus tôt d'une valeur ajoutée accrue. Les limites du volume de travail 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é cette demande et commencer à travailler sur une autre ». Ouvrir deux demandes 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 une demande et accélérer sur une autre, ce n'est pas gratuit. Cela prend du temps et nuit à la concentration. Il vaut pratiquement toujours mieux terminer la première demande plutôt que de commencer, et ne pas achever, une nouvelle tâche. En d'autres mots, les limites du volume de travail en cours 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.

Pro Tip:

Les équipes qui découvrent les limites WIP peuvent ressentir une forme d'inconfort. Prenez le temps d'en discuter lors des premières itérations. Tâchez de comprendre quand et pourquoi l'équipe a atteint les limites WIP. Résistez à la tentation de les ajuster directement de façon arbitraire. Si une faille devient régulière, c'est le signe que la limite WIP est trop restrictive ou que le processus de l'équipe est inefficace. 

Utiliser les limites du volume de travail en cours dans les équipes agiles

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 statut. Nous vous conseillons de définir les limites WIP après avoir contrôlé, pour quelques sprints, le nombre moyen de tâches dans chaque statut. Vous trouverez, ci-dessous, un exemple de tableau Agile avec les limites WIP utilisées par une équipe de développement type. 

Limites WIP | Atlassian – Le coach Agile

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 au statut « Terminé », il n'y a pas besoin, dans ce cas, de limiter le volume de travail en cours. Dans le tableau ci-dessus, le statut « Prêt pour le développement » signifie que la user story a été minutieusement contrôlée par le responsable produit et par l'équipe. L'équipe de développement fait passer une tâche du statut « Prêt pour le développement » au statut « En cours » lorsqu'elle commence à travailler sur cette tâche. Au titre des bonnes pratiques, il est important de conserver suffisamment de tâches au statut « Prêt pour le développement » afin que chaque membre de l'équipe de développement reste pleinement occupé. En gardant juste ce qu'il faut de user stories au statut « Prêt pour le développement », le responsable produit n'anticipe pas trop sur l'élaboration des exigences. De plus, le programme devient davantage réactif au changement.

Le statut « 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 à ce statut. 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.

Le statut « 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 à ce statut 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 du volume de travail en cours évitent que le code non révisé ne s'accumule. 

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

Anti-patterns à surveiller :
  • Les limites du volume de travail en cours sont relevées au fil des besoins afin que l'équipe ne les atteigne plus (le « plafond d'endettement », ça vous parle ?).
  • Everyone has a large "background task" on their plate to mask times when they'd otherwise be idle.
  • Team members sit idle waiting for more work to pull in, rather than swarming on bottlenecks.
  • L'équipe préfère augmenter le nombre d'employés/heures en cas de goulots d'étranglement, plutôt que d'améliorer les pratiques d'ingénierie ou les processus de l'équipe. 

Quatre objectifs pour les équipes agiles qui appliquent les limites du volume de travail en cours

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. 

Pro Tip:

Lorsque les limites WIP fonctionnent pour l'équipe, le temps de cycle d'un ticket diminue radicalement. Le temps de cycle correspond au temps nécessaire pour achever un ticket. Consultez notre page dédiée aux métriques Agile pour en savoir plus. 

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 statut spécifique pour le travail du spécialiste. Si des goulots d'étranglement surviennent à ce statut, 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 statut 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.