To guess or not to guess – Mon opinion sur le mouvement «No estimates»

Il existe beaucoup de situations dans lesquelles des estimations sont faites. Quel que soit le type d’estimation, ma conclusion restera la même: je pense qu’en matière de projets de développement logiciel nous ne devrions pas prendre de décisions en nous basant sur des estimations. Je vous explique quelles sont les alternatives.

Allons-nous livrer à temps?

Il s’agit là d’une des questions clés que se pose constamment une équipe de développeurs au début et tout au long d’un projet. Et elle est la raison principale qui pousse beaucoup de personnes à croire qu’il faut faire des estimations. Ce qui est discutable c’est que nous voulons obtenir une prévision fiable en faisant des estimations basées sur des hypothèses. Nous savons, ou du moins nous nous doutons, tous que ces chiffres sont généralement choisis librement. Au mieux, ils se fondent sur des expériences vécues dans le cadre de projets certes semblables mais jamais identiques. Le fait est que, la plupart du temps, nous ne connaissons pas encore la solution ou ne la comprenons pas. Nous essayons d’apaiser nos craintes en désignant nos estimations sous les termes «hypothèse raisonnée» ou «quick-and-dirty» afin de pouvoir justifier le fait que nous prenons des décisions importantes sur la base d’estimations.

Le développement logiciel est par nature imprévisible et non répétitif. Lorsque nous développons des logiciels, nous ne pouvons pas découper le travail en tâches toujours semblables et récurrentes comme lors de l’assemblage d’une chaise. Et, contrairement à une chaise, il faut attendre la fin du processus de développement pour savoir à quoi le produit logiciel fini ressemble. Une pièce de production logicielle ne ressemble à aucune autre. Le développement logiciel est un processus créatif et variable et les solutions apparaissent souvent seulement lors du développement. C’est pourquoi il est très difficile de définir l’étendue exacte d’un projet de développement. Si nous acceptons l’idée que la portée du projet doive être variable pour prendre en compte les exigences fluctuantes et «l’emergent design», nous devons également accepter que la date de livraison soit elle aussi une variable que nous essayons d’atteindre tout en livrant le projet dans le temps et le budget impartis.

Si les coûts et la durée nécessaires pour répondre à un certain nombre d’exigences concernant le développement d’un logiciel se basent sur des estimations et qu’il ne s’agit là pas de limites temporelles et budgétaires fermes, il est tout à fait acceptable que nous ayons besoin de plus de temps pour développer le logiciel que ce que nous avions estimé à l’origine. Il est aussi possible que nous soyons plus rapides. Ou que nous avancions à la vitesse estimée.

Finalement, il convient de se demander si l’exactitude de notre estimation était vraiment pertinente. Notre estimation a-t-elle une quelconque influence, négative comme positive, sur la qualité du produit ou son RSI?

La vision est décisive

Pour développer des logiciels, nous avons besoin d’une vision claire et d’une idée commune de ce à quoi le succès doit ressembler. Lorsque nous nous lançons dans un projet de développement logiciel, il nous faut d’abord des objectifs de haut niveau. Et non pas les détails indiquant comment nous atteindrons ces objectifs. En adoptant un procédé itératif classique, nous pouvons décider «juste à temps» comment notre produit peut être amélioré lors de la prochaine itération (backlog grooming).

J’affirme qu’essayer de prédire à l’aide d’estimations la durée de développement d’un logiciel afin d’atteindre ces objectifs de haut niveau est une approche discutable. Nous voulons que nos solutions et notre architecture prennent vie lors du développement. Nous souhaitons que les exigences changent pour offrir un avantage au client durant le développement du produit. Cette flexibilité ne peut par définition pas être fixée au préalable. Ces points sont des éléments clés du Manifeste agile et je pense qu’ils sont essentiels pour adopter une approche véritablement agile du développement logiciel.

Éliminer l’inconnu

Au lieu de nous appuyer sur l’exactitude des estimations de nos prédictions, nous pouvons essayer d’éliminer les coûts et délai de livraison inconnus en les explicitant. Le Product Owner peut par exemple définir la date de livraison à l’aide d’une limite budgétaire ou temporelle concrète (par exemple: 3 jours avant Noël pour une application en lien avec cette célébration ou «Nous disposons de 50 000 CHF, essayons d’obtenir le meilleur résultat possible»).

En respectant ce cadre, l’équipe peut définir des moments de livraison (p. ex. à la fin d’un sprint). Cela permet ainsi de se concentrer sur le développement produit itératif et d’avoir dans le même temps la possibilité de livrer plus tôt et/ou pour moins cher. Cette approche est également utile quand aucune limite temporelle ou budgétaire concrète n’a été fixée. Il faut aussi noter que plus une équipe connaît les méthodes de livraison continue, moins le besoin de définir explicitement des releases intermédiaires se fait sentir.

Estimer la vélocité du sprint est une perte de temps (gaspillage)

Il me paraît peu pertinent de donner une solution dès le début (ce qui est nécessaire pour faire une estimation de la durée) ou de prédire pour chaque sprint combien de story points ou de stories seront utilisé(e)s. Les équipes devraient seulement se contenter de développer le meilleur produit possible en respectant le temps et le budget impartis. Lorsque nous faisons une estimation et utilisons la vélocité pour planifier, nous émettons une hypothèse sur la quantité de travail que nous pouvons fournir durant une période donnée. Pour que cette information soit utile, nous devons déjà savoir ce que nous voulons faire globalement (c’est-à-dire avoir un backlog produit entièrement évalué). Je pense qu’il n’est pas absurde de considérer comme du gaspillage – au sens de l’approche lean – l’ensemble du temps passé à estimer des éléments de backlog qui ne sont ensuite pas du tout développés.

Qu’en est-il du temps passé à estimer les éléments de backlog qui sont développés? Pour répondre à cette question, j’en pose une deuxième: connaissez-vous un Product Owner qui a déjà priorisé une story sur une autre en raison de story points (coûts estimés) moins élevés? Si la réponse à cette question est «non», j’en conclus que l’ensemble de l’estimation réalisée dans ce contexte était du gaspillage. Car aucune décision n’a été prise sur la base d’une estimation (au lieu de cela, le Product Owner a priorisé la story la plus utile).

Si la réponse est «oui», alors l’estimation des coûts a servi de fondement pour prendre des décisions qui auraient dû l’être en fonction de l’utilité. Estimer le backlog au préalable et ensuite planifier la date de livraison sur la base de la vélocité est une approche fondée sur les coûts.

Faire des essais et non des estimations

Je pense que le développement itératif (agile) se fonde sur des décisions accès sur l’utilisation commerciale/des clients qui préfèrent l’empirisme aux estimations. Dans un tel scénario, les coûts doivent être définis en entretenant une équipe et en donnant clairement un cadre temporel (des moments de livraison fréquents et prévisibles plutôt que des dates limites). Lorsque nous connaissons les coûts et les moments de livraison, nous sommes rassurés, ce qui nous permet d’adopter une approche agile pour le développement du produit. Par ailleurs, avoir une date de livraison fixe ne signifie pas qu’à partir de cette date nous cessons de développer notre produit. Il se peut qu’à cette date nous ayons déjà terminé notre mission ou que nous décidions de continuer à travailler. Il est important que nous prenions en continu des décisions go/no-go en nous basant sur l’utilisation réelle ou potentielle du produit que nous développons et non sur les coûts estimés d’une solution spécifique.

Le nombre de stories ou de story points pouvant être livré(e)s par sprint est vraiment sans importance si l’équipe est capable de fournir aussi vite que possible aux clients des améliorations et des ajouts sur le produit. C’est, de mon point de vue, la raison pour laquelle les projets logiciels et les entreprises essaient de déployer l’approche agile.

Aussi longtemps que nous nous sentirons obligés de faire des estimations, nous serons probablement toujours quelque peu freinés dans notre objectif de fournir aux clients des logiciels vraiment exceptionnels.