L’importance de la valeur de l’apprentissage dans la priorisation des fonctionnalités
En Agile, la priorisation se fait toujours par rapport à la “valeur d’affaire”. Ce terme est souvent un terme vague, ou vaguement défini. Par ailleurs, Mike Cohn définit quatre facteurs essentielles qui doivent être considérés lors de la priorisation du développement des nouvelles fonctionnalités.
- La valeur financière d’avoir les fonctionnalités
- Le cout de développement des nouvelles fonctionnalités, et éventuellement de les supporter.
- Le niveau de risque enlevé en développant ces fonctionnalités
- La quantité et l’importance de l’apprentissage et les nouvelles connaissances créés lors du développement de ces fonctionnalités.
Le dernier facteur est souvent un facteur négligé dans la priorisation. La raison est généralement simple, les projets étant considérés au pour sauver ou générer de l’argent. Par contre, afin de prioriser optimalement, considérer l’apport de l’apprentissage est une activité aussi essentielle que critique.
L’apprentissage et les connaissances
Pratiquement dans tous les projets, les équipes de développement et l’équipe élargie de façon générale passent beaucoup de temps et font beaucoup d’effort pour acquérir de nouvelles connaissances. C’est normal, puisque nous ne pouvons pas tout connaitre au début du projet. La connaissance se divise généralement en deux niveaux : le quoi et le comment.
Le quoi définit le produit, ou encore les fonctionnalités qui vont composer le produit et ceux qui ne vont pas être considérées. Le mieux l’équipe connait le produit, le mieux ses décisions sur la nature des fonctionnalités du produit vont être.
Le comment définit le projet, ou en d’autre termes, comment le produit va être créé. Ceci inclut les technologies, l’architecture, le niveau des développeurs, l’harmonie de l’équipe de développement etc.
L’objectif de l’apprentissage est bien évidemment de réduire l’incertitude. Le plus nous avançons dans le développement du produit, le moins nous avons d’incertitude. L’incertitude est en fait réduite en acquérant plus de connaissance sur le produit.
L’essence de l’approche Agile
Pour réduire l’incertitude, l’approche traditionnelle en Waterfall essaye d’éliminer l’incertitude sur le “quoi” en amont. ce qui implique que le produit est complètement définit avant de commencer le développement, ce qui est généralement intatteignable. D’autre part, dans presque tous les cas, les client et les utilisateurs sont incertains de ce qu’ils veulent jusqu’à ce qu’ils voient “des parties” du produit. Ils déterminent par la suite leurs besoins successivement.
Les équipes agiles quand à elles, reconnaissent qu’il est impossible de connaitre la totalité du produit et vivent donc avec l’incertitude. Ils savent que pour y arriver, il faut développer des parties du système, recueillir du feedback des clients et raffiner les besoins. Bien que ces points prennent du temps, ils sont indispensable pour détérminer la façon de développer le produit. Cette approche résulte à réduire simultanément le quoi et le comment.
Remarquez comment l’approche Agile tend à réduire le plus tôt que possible le “quoi” (ce que Cohn appelle la fin de l’incertitude), pour se concentrer la la suite au comment, ou les moyens de l’incertitude. La raison de cet ordre est que le risque de développer un faux produit est beaucoup plus grand que de mal développer le bon produit.
Conclusion
Il est très important et même primordial pour toute entreprise qui adopte l’agilité de considérer fortement la valeur de l’apprentissage du domaine d’affaire ainsi que du produit à développer. Impliquer les équipes de développement comme partie intégrante dans tout ce qui concerne la définition et l’importance des fonctionnalités est une recette gagnante a tous les niveaux!