Nul n'est censé ignorer la définition de fini

La définition de fini c’est l’ensemble des critères que l’on se donne pour considérer en agile que les éléments sur lesquels on travaille sont finis, ou pas. Le fini est essentiel, car il permet d’avoir quelque chose de concret. on sort de l’hypothèse, on a quelque chose que l’on peut vendre, donner, proposer, essayer, etc, on va apprendre. Le feedback est toujours intéressant, même avant le “fini”, mais naturellement avec le fini il prend beaucoup plus de valeur. Et le fini nous permet d’aller chercher du feedback ailleurs (utilisateurs finaux, dehors dans le monde extérieur, etc.). Le fini est aussi binaire, c’est fini ou ce n’est pas fini. Cette polarité est franche et permet une vraie lecture simplifiée des réalisations en cours (ça, on l’a, ça on ne l’a pas), et ouvre vers des arbitrages plus judicieux. Avec cette notion stricte de fini (ou pas), on évite les “on a 80% de cette fonctionnalité et 70% de celle-ci” ce qui, vous le savez tous, ne veut rien dire dans la vraie vie. Quand les gens nous disent “on a 80% de cette fonctionnalité” bien souvent, ils expriment l’idée que 80% du temps alloué sur la réalisation de cette fonctionnalité a été consommé. Mais rien n’indique que les 20% restant ne prendront pas plus que les 80% précédent. Et donc on souhaite du feedback régulièrement et on souhaite des choses finies régulièrement pour apprendre, vendre, donner, essayer, etc, le plus tôt possible. Et donc on retombe dans un besoin d’exprimer des choses finies qui font sens (sur le plan fonctionnel, usuel, métiers, commercial) avec des éléments assez réduits (taille, effort de réalisation). Mais ce n’est pas le sujet de cet article mais plutôt de celui-ci.

Je reviens à cette définition de fini qui est un élément difficile, peut-être le plus difficile, dans la sphère agile pour les équipes, quelle forme prend-elle, que contient-elle, à quoi faut-il être vigilant ? …selon moi.

Accessibilité et intelligibilité de la définition de fini

Pourquoi la définition de fini est à mes yeux le plus difficile élément d’une équipe agile ?

Donc mes deux règles qui supplantent les autres, car elles vont bâtir notre comportement, notre culture, par rapport à cette notion de fini et de qualité :

Que contient-elle ?

Si je devais prendre un cahier des charges classiques et que je devais l’adapter à un contexte agile je dirais : prenez tous les éléments fonctionnels, métiers, et placez-les dans votre backlog, dans votre expression du besoin, prenez tous les autres éléments et placez les dans la définition de fini. On va y trouver des éléments techniques : il faut utiliser tel ou tel composant, ou outil ; on va y trouver des éléments de performances : cela doit marcher avec un million d’utilisateurs en simultané, avoir de la haute disponibilité, etc ; on va y trouver des éléments de méthodes : toutes les tâches réalisées doivent être revues par un autre membre de l'équipe, la validation se fait sur la plate-forme d’intégration, etc.

Mais cette liste est réduite à 7 (+2/-2) éléments. Ce n’est pas SI compliqué que cela. Plein de choix sont implicites et non pas besoin d'être intégré à la définition de fini. J’estime que vous avez deux options : soit ne pas réduire la liste, et qu’elle ne soit pas vraiment respecter. Soit vous faire un peu mal et la réduire à 9 éléments et que ceux-là au moins ne soient pas oubliés.

Qui décide de ce qu’elle contient ?

Hummm. Ben… tous les gens concernés par ce qui va être produit. Avec un arbitrage du métier, du product owner, et un accord sur la faisabilité par l'équipe. Encore une complication donc.

Quelle forme prend-elle ?

Une simple liste affichée au mur : nul n’est censé ignorer la définition de fini. Donc de 5 à 9 éléments (je vous rappelle que c’est mon point de vue et qu’il est minoritaire).

Voici un exemple sur un projet informatique (et elle doit être discutée à haute voix avec l'équipe et le product owner pour bien délimiter ce que les mots expriment):

Vous voyez malgré tout que des choses doivent être précisées (tests automatisés ? etc.). Mais c’est clarifié au sein de l'équipe. Cette liste est affichée et doit être respectée pour que les éléments (tâches ? Fonctionnalités ? User stories ? Release ?) soient jugés “fini”.

Peut-elle évoluer ?

À vos risques et périls. Si vous dîtes que ce n’est pas un million d’utilisateurs simultanés, mais finalement dix, vous comprenez que tout ce que vous avez jugé “fini” auparavant est potentiellement remis en question. Si vous ajoutez au milieu du gué : toute l’interface doit être en anglais ET en chinois, tout ce que vous avez réalisé auparavant est peut-être compromis. Mais elle peut évoluer naturellement.

Feedback

Nicolas

Tout à fait d’accord le définition de fini est un élément important et beaucoup d'‘équipes la néglige ou ne la respecte pas. J’ajouterai que c’est un élément de transparence et que chaque membre de l'équipe doit pouvoir l’expliquer aux différentes parties prenantes. D’autre part, la définition de fini donne le LA à l'équipe au moment de définir comment elle va s’y prendre pour réaliser le produit ou l’incrément. En ce qui concerne le nombre de critères, je te rejoins, cela n’est pas nécessaire de faire une liste à la Prevert, perso j’indique toujours de ne pas dépasser la dizaine. Après ce que contient la liste n’appartient qu'à l'équipe, une autre équipe dans la même organisation pourrait avoir une définition différente, car chaque équipe travaille différemment.


definitiondefini dod