Archive pour novembre 2011

L’important c’est d’être régulier

Ce soir, je vais enfoncer une porte ouverte avec ce billet, mais parfois ça fait du bien !

Il y a des jours ou l’on se rend compte que des années d’expérience ne nous mettent pas forcément à l’abris des erreurs les plus basiques.
Explications : lundi nous avons fait une grosse séance de refactoring avec ma paire : renommage de toutes les méthodes d’une classe, extraction de comportement commun dans une classe mère …

Nous étions un peu grisés et franchement contents du rythme auquel nous avancions. A tel point que nous n’avons pas pu commité lundi soir car nous fumes victimes de demandes de support arrivées lundi soir.
Résultat ce matin, après un jour férié, nous pensions qu’il nous suffirait de tester rapidement nos modifications puis de les commiter. Las, nous avons découvert quelques bugs et avons passé plus d’une demi-journée pour rechercher où étaient les erreurs parmi nos nombreuses modifications.

Finalement, nous avons fait un revert sur la majeure partie de notre travail de refactoring. Grosse frustration …
J’en tire une conclusion qui sonne comme un rappel : commiter régulièrement nous aurait éviter ce genre de mésaventures !

Publicités

Le mythe de la sur-qualité

Après quelques semaines de silence, voici un billet sur un thème qui me tient à coeur : les agilistes font-ils de la sur-qualité ?

Un lieu-commun

Il faut dire que l’argument est très souvent entendu dans la bouche de commerciaux qui, après avoir gagné un projet, souhaitent légitimement que celui-ci soit réalisé dans les coûts prévus initialement pour rassurer le client. Le problème pour le commercial, c’est qu’il ne peut modifier ni le périmètre, ni la taille de l’équipe, ni la date de livraison sur lesquels il croit s’être engagé. Il ne lui reste alors plus qu’à essayer de faire en sorte que la qualité devienne une variable d’ajustement du développement.

Un concept difficile à définir

Le concept même de sur-qualité nécessite d’être expliqué. En effet pour un commercial la sur-qualité peut être défini par le fait que l’équipe de développement passe trop de temps à améliorer la qualité de son code, à écrire des tests unitaires, ou à les ré-écrire, à refactorer. En un mot à passer du temps à écrire du code qui n’apporte pas de nouvelles fonctionnalités. Pour rassurer le commercial inquiet, il suffit de se tourner vers le client et de lui demander s’il est prêt a accepter d’avantage de bugs et de support pour une amélioration hypothétique de la productivité de l’équipe. Une expérience récente me fait dire que sur ce point nous pouvons faire confiance à la vision produit de nos clients. Lorsqu’ils recherchent des gains de productivité, ils raisonnent à qualité constante.
La deuxième possibilité, c’est de laisser l’agiliste définir ce concept. Il pourrait alors dire que la sur-qualité consiste à implémenter des fonctionnalités (utiles) mais non demandées. Ce risque est fortement limité par le fait que les processus agiles s’appuient sur un feed back régulier du client. Impossible donc de développer beaucoup de fonctionnalités non demandées.

Une vision de court terme

En conclusion, je crois que la sur-qualité est un mythe, une vue de l’esprit de personnes qui ne participent pas directement aux activités de développement. Il s’agit de plus d’une vision de court terme dans laquelle la qualité est vue comme un coût immédiat et non pas pour ce qu’elle est : un investissement qui permet de ne pas sacrifier la productivité future.

Sur le même sujet : l’Agilitateur


Mises à jour Twitter