Bonne question souvent posée, mais souvent évitée... Essayons de voir ce qu'il en est.

Quelle est l'origine de cette question ? th_13668-tuxitecte.jpg kami23-tux-plombier-13669.png Dans les différentes DSI, on souffre souvent du clivage MOA/MOE. La MOA voyant le côté utilisation par l'utilisateur final d'un produit; La MOE souhaitant y apporter des améliorations techniques. La méthodologie Agile se veut fédératrice en amenant tous les intervenants à partager une vision produit. C'est pourquoi le backlog contient généralement des stories apportant une vision "utilisation finale" du produit. Mais pour définir un produit ne faut il pas se poser au moins deux questions : à quoi ça sert ? De quoi est-il fait ? En effet, son utilisation peut être optimisée si sa matière suit les avancées technologiques. Une raquette c'est fait pour jouer au tennis, mais c'est bien mieux en matériaux composites plutot qu'en bois...

Alors pourquoi hésite-t-on à mettre des stories techniques dans le backlog ? Tout simplement parce que l'on parle de "user stories" et que cette connotation de user est purement fonctionnelle. On pense immédiatement à l'utilisateur final du produit. Le développeur, le futur exploitant du produit ou simplement un batch peuvent pourtant être définis comme des users du produit. Ils ont dans ce cas pleinement leur place dans le backlog en tant que users. Dans une application, créer un service qui sera utilisé par un batch peut être considéré comme une storie technique, et elle doit bien figurée dans le backlog. On obtient alors : "En tant que batch bidule, je récupère les données blabla à l'aide du service truc afin de les agréger". Néanmoins, il faut conserver la vision produit et amélioration de celui ci. Une storie technique doit amener quelque chose en plus, que ce soit une facilité d'exploitation ou de maintenance. Par exemple, des états faits sous poi et/ou itext peuvent être refondus en Jasper, qui apporte, via eReports, une facilité d'utilisation et de l'indépendance en termes de design de l'état. Le backlog demeure la responsabilité du Product Owner et il s'agit de le convaincre de l'utilité de cette storie technique. Charge à lui de l'inscrire au backlog. Bonne négociation....