L'éternel débat des équipes agiles. Spoiler : ce ne sont pas les mêmes choses, et les confondre coûte cher.
La différence fondamentale
| Story points | Jours-homme | |
|---|---|---|
| Nature | Relatif et abstrait | Absolu et temporel |
| Varie selon la personne ? | Non | Oui |
| Reflète l'incertitude ? | Oui | Rarement |
| Usage recommandé | Planification agile | Contrats, reporting externe |
Le problème avec les jours-homme en agile
Les jours-homme créent une illusion de précision. Dire qu'une feature prend 5 jours-homme implique qu'on sait exactement ce qu'on fait, combien de temps chaque tâche prend et qu'aucun imprévu ne surviendra. En développement logiciel, c'est rarement le cas.
De plus, les jours-homme incitent les managers à traiter les développeurs comme des ressources interchangeables. « Si un dev fait ça en 3 jours, deux devs le font en 1,5 jour. » Sauf que non : c'est la loi de Brooks.
Loi de Brooks : Ajouter des personnes à un projet en retard le retarde encore plus.
Les story points, eux, permettent…
- D'estimer collectivement sans se disputer sur les capacités individuelles
- De mesurer la vélocité de l'équipe sprint après sprint
- D'identifier les tendances (l'équipe va-t-elle plus vite ? moins vite ?)
- De prioriser sans transformer les estimations en promesses contractuelles
Quand utiliser les jours-homme quand même ?
Dans certains contextes, les jours-homme restent utiles : contrats à prix fixe, reporting vers des parties prenantes non agiles, ou suivi comptable des projets. Dans ce cas, on peut convertir la vélocité en approximation temporelle, mais on garde les story points en interne.
