Concilier vélocité et qualité en mode agile

On ne le dira jamais assez : les méthodes agiles ne font pas travailler plus vite, elles diminuent d’une part les temps d’attente entre les tâches et d’autre part le nombre de choses à refaire. Que l’on travaille en agile ou non, diminuer le niveau d’exigence permet de travailler plus vite, mais cela augmente le taux de rebut (et donc le nombre de retouches à faire)… et peut donc reculer la date de livraison finale. A l’inverse, aller trop loin et trop vite dans la qualité fera tomber la vélocité à des niveaux inacceptables pour l’avancée d’un projet. Il y a donc un optimum quelque part, pour chaque projet, et même pour chaque item d’un projet entre sous-qualité et sur-qualité pour livrer un produit acceptable le plus rapidement possible.

Mais indépendamment de cet arbitrage du quotidien entre qualité et vélocité, il existe aussi un certain nombre de pratiques qui permettent d’augmenter l’un des facteurs sans pénaliser l’autre. En voici 3 exemples méconnus (tirés de la communauté Scrum Plop) et pourtant redoutablement efficaces.

« Tous pour un ! » : le développement en série continue

« Tous pour le ticket #2130 ! »

Développer en « série », s’oppose à développer en parallèle : c’est à dire traiter les tâches les unes après les autres plutôt qu’en mener plusieurs de front. En effet, l’expérience montre que passer d’un sujet à l’autre diminue de manière significative la vélocité du fait de la « reconfiguration mentale » que cela nécessite. Malgré tout, laisser chacun avancer sur une tâche sans bénéficier de l’apport de son équipe ou d’un peu de souplesse dans son organisation va à l’inverse de la philosophie agile.

L’idée du « tous pour un » est donc de d’identifier en permanence une tâche de référence, celle que l’équipe juge la plus importante du moment pour l’avancée du projet en d’en confier la responsabilité à quelqu’un qui devient momentanément le « capitaine » de l’équipe. Personne ne doit perturber le capitaine dans son travail, mais celui-ci peut faire appel aux autres quand il en a besoin. On optimise ainsi en permanence l’avancée du sujet le plus critique du moment. Dès lors que la tâche de référence est terminée, c’en est une autre qui prend ce statut, avec éventuellement un nouveau responsable et donc un nouveau capitaine.

Jouer une première partie facile

Les biais psychologiques jouent un rôle considérable dans la gestion d’un projet. Quand les choses commencent à mal tourner, il est fréquent que des membres de l’équipe se mettent à ne plus croire dans la réussite du projet, croyance qui devient auto-réalisatrice. C’est en particulier vrai en début de projet. Si dès les premières échéances, les délais ne sont pas tenus, l’équipe aura tendance à penser que « le projet sera de toute façon en retard » et se détache progressivement de la tenue des objectifs des jalons suivants.

Jouer une première partie facile permet donc de mettre l’équipe en confiance sans prendre trop de risques sur la qualité produite (particulièrement importante en début de projet). Une fois ses marques posées, on pourra se fixer des objectifs de plus en plus ambitieux à mesure qu’avance le projet.

Taper la bête quand elle sort du trou

Chasse aux bugs en mode agile

Chasse aux bugs en mode agile

C’est le principe de ces jeux de foire où vous cognez avec un marteau les bestioles qui sortent de leur trou : dès qu’un bug pointe le bout de son nez, on l’extermine immédiatement. La raison en est simple : régler un problème au moment où il découvert évite d’avoir à le gérer (le déclarer dans un bug-tracker, le prioriser, en assurer le suivi, vérifier sa résolution) et l’empêche de provoquer des dégâts collatéraux : autres bugs générés par le premier, code construit entre-temps devant être refactoré, autres problèmes masqués par le bug.

Evidemment, pour ne pas couper les développeurs au milieu de ce qu’ils font, cela demande une certaine organisation. Cela peut prendre plusieurs formes : tests développeur plus intensifs au moment où une fonctionnalité est écrite, organisation de « chasses aux bugs » avec correction immédiate des problèmes trouvés, rôle de « debugueur » dédié tournant entre les différents membres de l’équipe… A vous de trouver celles qui vous conviendront le mieux : l’amélioration continue est votre amie !

Publicités

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion /  Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion /  Changer )

w

Connexion à %s