Posts Tagged 'Productivité'

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

Améliorer les conditions de travail pour améliorer la productivité ?

Imaginez un peu, s’il était possible d’améliorer la productivité des développeurs en changeant simplement leurs conditions de travail. Ce n’est pas le rêve d’un utopique mais bien le résultat de deux études -l’une du wall street journal, l’autre de Microsoft Research– selon lesquelles avoir un second écran ou un écran plus grand améliore la productivité des développeurs jusqu’à 50%.

Uu ROI rapide

Si l’on prend un peu de recul par rapport à cette étude, que l’on prend en compte le fait que les cartes graphiques à deux connecteurs se sont généralisées et que les écrans, désormais tous plats, se sont agrandis à prix constant, l’investissement à réaliser est modeste. Le retour sur investissement est donc extrêmement rapide.
Et que les managers se rassurent, ces mêmes études montrent que le choix d’un écran de 26 pouces n’apporte aucun gain de productivité supplémentaire par rapport à un modèle 24 pouces. De même, le passage à trois écrans n’apporte rien. Ouf, les développeurs ne coûteront pas trop chers…

Peut-on vraiment faire confiance à ces études ?

Ces études vont probablement être reprises par quelques commerciaux en mal de chiffres -comme ils le font avec l’étude du Standish group sur le Pair Programming- sans qu’ils comprennent en quoi ces pratiques améliorent véritablement la productivité des équipes. Je vais donc essayer de le leur expliquer en donnant quelques exemples dans lesquels l’utilisation de dual screen me semble apporter un gain de temps incontestable :

  • lors de la rédaction ou de la mise à jour de cas de tests, cela me permet d’avoir sous les yeux à la fois le document que je rédige  et l’exigence qui doit être développée, évitant ainsi de switché de l’un à l’autre
  • lorsque je développe, je peux à la fois avoir sous les yeux une classe dont je souhaite m’inspire et la classe sur laquelle je travaille, ou encore ma page web et le fichier de ressources dans lequel j’ajoute les traductions nécessaires au fur et à mesure. Je pourrai même avoir sous les yeux l’exigence pendant que je développe et ainsi vérifier régulièrement que je n’en ai pas oublié une partie
  • lorsque je lance les tests et qu’ils sont rouges, je peux à la fois voir la méthode de tests en cause et la cause de l’erreur
  • lorsque je débug, je peux avoir d’un côté la classe parcourue et de l’autre les variables, points d’arrêt et autres espions
  • lorsque je livre, je peux le faire en ayant sous les yeux le mode opératoire de livraison et ainsi éviter de trop nombreuses erreurs

Faisons confiance au feed-back

S’il fallait encore ajouter un argument, ce serait le feed-back de ceux qui ont essayé. La conclusion de Microsoft Research est simple : donnez un second écran à quelqu’un, laissez le l’utiliser quelque temps et essayer ensuite de le lui retirer. Cela n’arrivera pas. Personne ne voudra revenir à un seul écran.