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

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

Dan Radigan Dan Radigan
Browse topics

Que sont les limites WIP ?

Dans le développement Agile, les limites du travail en cours (Work in progress, 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.

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 WIP accélèrent la production et réduisent la quantité de travail « pratiquement terminé » en obligeant les équipes à se concentrer sur une série de tâches restreinte. Elles 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 que ces blocages ont été éliminés, le travail 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 coéquipiers. Réduire le tempo sur un ticket et l'accélérer sur un autre n'est pas sans conséquence. Cela prend du temps et nuit à la concentration. Mieux vaut souvent résoudre 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 WIP signalent les points d'inactivité ou de surcharge chronique. Elles aident les équipes à visualiser les inefficacités sur l'ensemble du processus, plutôt que le seul domaine sur lequel elles travaillent.

Conseil de pro :

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 vous avez atteint les limites WIP. Résistez à la tentation de les ajuster directement de façon arbitraire. Si une transgression se répète, 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 connaissez l'intérêt de ces limites, 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 montrant 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 de code. Étant donné que la colonne dépasse la limite, l'arrière-plan est rouge.

Puisqu'il n'y a plus rien à faire lorsqu'un ticket est à l'état « Terminé », inutile de définir une limite WIP. Dans le tableau ci-dessus, l'état « Prêt pour le développement » signifie que la story a été minutieusement contrôlée par le Product Owner et par l'équipe. L'équipe de développement fait passer une tâche de l'état « Prêt pour le développement » à l'état « En cours » lorsqu'elle commence à travailler dessus. Au titre des bonnes pratiques, il est important de conserver suffisamment de tâches à l'état « 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 stories à l'état « Prêt pour le développement », 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 chacun a du travail, mais que personne n'est en multitasking. Dans le tableau ci-dessus, la limite de tâches « En cours » est définie sur 4. Or, il y a actuellement 3 tâches à cet état. Cela indique que l'équipe est en mesure d'accepter une tâche supplémentaire. Au titre des bonnes pratiques, certaines équipes définissent une limite WIP maximale qui est inférieure à leur nombre de membres. 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 de code » désigne les 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 de 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 font un check-in du 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 être mergée dans la branche principale pour la livraison.

Les limites WIP é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 WIP sont relevées au fil des besoins afin que l'équipe ne les atteigne plus. (Le « plafond d'endettement », ça vous parle ?).
  • Chacun dispose d'une grande « tâche de fond » pour masquer ses moments d'inactivité.
  • Les membres de l'équipe attendent l'arrivée d'un plus gros volume de travail, au lieu de se ruer sur les goulots d'étranglement.
  • L'équipe préfère augmenter le nombre d'heures-personne en cas de goulots d'étranglement, plutôt que d'améliorer ses pratiques d'ingénierie ou ses processus. 

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

Comme toute nouvelle activité, les limites WIP peuvent, dans un premier temps, générer un peu d'inconfort. L'objectif est d'optimiser l'équipe à moyen terme. Et cet inconfort à court terme est, en fait, plutôt positif. Il incite l'équipe à identifier les difficultés dans son processus. Une fois que l'équipe aura utilisé les limites WIP pendant quelques semaines, ajustez-les, le cas échéant. Résistez à la tentation d'élever une limite WIP 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. 

Conseil de pro :

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

Objectif 2 : Mapper les limites WIP avec les 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 d'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.