samedi 16 novembre 2013

Dérive des estimations des développeurs

Lors de ma dernière animation Scrum, un des apprenants m'a posé une question : "Pourquoi lorsqu'un développeur nous dit que la tâche va prendre X jours, bien que je double systématiquement ses estimations, fréquemment elles sont dépassées. Dans les autres domaines, je ne trouve pas autant d'écarts." Sur le moment, je lui ai répondu deux choses: "Tout d'abord, il faut éduquer les développeurs, et donc les forcer à se faire des métriques sur l'existant. Avec Scrum cela est facilité : c'est intégré dans la méthode. Ensuite, il faut voir que les développeurs sont un peu comme des artistes, il y a un part de créativité dans ce qu'ils font". Je n'étais pas totalement satisfait de ma réponse, même si elle est vraie. Je me suis demandé un peu plus ce qui faisait la difficulté dans le développement pour avoir des estimations exactes par rapport aux autres disciplines. Ma réflexion m'a emmené là : Si, vous comparez l'activité de développement par rapport à l'activité d'un maçon. Le maçon est toujours obligé de tout produire, et en ça il refait des choses à l'identique. Pour le développeur, dès qu'il y a duplication, ce n'est pas bon (voir l'article sur la non duplication de code). L'idée même de l'informatique est d'automatiser. Le développeur qui répond à un besoin similaire va réutiliser ce qu'il a fait et se consacrer sur les différences. Alors, d'où vient la difficulté des estimations? Des différences, du fait que le projet à réaliser est forcément entièrement nouveau puisque ce qui ne l'est pas est réutilisé. Par conséquent les développeurs estiment le travail restant, et donc nouveau. Cette nouveauté est donc le point qui rend difficile l'estimation. Mais c'est aussi, le point qui permet aux "artistes/développeurs" d'arpenter des terres de codage encore vierges...