Points de fonctions ou points d’histoire ?

J’entends souvent des personnes comparer les estimations agile en Story Point (SP) avec les Points de Fonction (PF).

Cette comparaison peut sembler utile pour simplifier (vulgariser) la compréhension des estimations agiles par des néophytes, mais malheureusement, en dehors des arguments pour l’une ou l’autre des approches, il existe une différence fondamentale que je vais chercher à développer dans ce billet.

Points de Fonction

L’approche PF considère que la fonctionnalité est réalisé dans son ensemble, c’est à dire que le besoin est implémenté en même temps que les aspects techniques, en une seule opération qui conduit à un résultat de bonne qualité.

Il n’y a donc pas de place pour une reprise technique ultérieure de l’architecture ou du code, dans le sens ou ces modifications éventuelles ne sont pas chiffrées.

Il faut faire bien du premier coup, ce qui implique de réaliser une étude d’architecture « up-front » qui demande d’avoir des spécifications complètes, qui prend du temps … et qui ne garantit malheureusement pas qu’il ne faudra pas retoucher à l’architecture dans le futur.

L’approche Agile remet en cause le bien fondé de ces approches « up-front » qui permettent, soi disant, de définir tous les éléments nécessaires pour l’étape suivante.

Story Point

L’approche SF considère que la fonctionnalité sera réalisée durant une itération sur l’architecture en place. L’objectif est de pouvoir rapidement montrer la fonctionnalités aux utilisateurs pour prendre leurs feedbacks et vérifier que le projet se dirige toujours vers le bon objectif.

Si une reprise technique est nécessaire (modification de l’architecture), l’équipe de réalisation soumettra une Technical Story au Product Owner en lui expliquant la nécessité de cette opération et en argumentant pour que la priorité soit forte, si cette reprise est à faire rapidement.

Lorsque cette Technical Story sera implémentée, l’équipe pourra vérifier que le comportement du produit n’est pas modifié (grâce aux tests automatiques) et garantir une livraison de qualité.

Conclusion

Certains pourraient argumenter qu’une reprise d’architecture coûte chère et que pour l’éviter il faut y réfléchir beaucoup à l’avance, mais c’est typiquement un retour aux méthodes traditionnelles.

Ce que ces personnes n’ont pas compris, c’est que l’agilité fait gagner du temps sur l’ensemble du système (ce n’est pas une approche pour gérer le codage) et les gains sont très significatifs si elle est pratiquée avec discipline.