Spécifications avancées
Auteurs : Jim Coplien avec l'aide de Jeff Sutherland
Source : Enabling Specification (Published Patterns)
Traducteur : Fabrice Aimetti
Date : 15/02/2012
Traduction :
... le BACKLOG PRODUIT est en place et le Product Owner travaille sur les Eléments du Backlog Produit (PBI).
Des spécifications qui n'ont pas été mûries réservent des surprises désagréables.
Il est toujours facile de jeter des exigences par dessus le mur en déclarant : "Cette exigence est couverte." C'est même encore plus facile en Scrum. Les user stories suffisent. Et la culture Agile encourage le fait de reporter les décisions et d'avoir un client à disposition sur site durant le développement pour compenser certaines lacunes dans les spécifications. Scrum accepte l'émergence des exigences, et il est alors facile pour le métier de déclarer que les exigences réelles apparaîtront uniquement lorsqu'on les sollicitera pendant la phase de conception.
Il y a une parcelle de vérité dans cette observation. D'un autre côté, un développement mené tambour battant est une façon maladroite de faire émerger des exigences. Parfois, tout ce qu'il faut, c'est un peu de dialogue entre le métier et les développeurs, ou entre les utilisateurs finaux et le Product Owner. Les testeurs sont bien connus pour flairer les exigences incomplètes, qui seraient pourtant souvent faciles à traiter (en parlant avec les utilisateurs finaux ou les autres parties prenantes) une fois découvertes. Et plus vous allez loin dans le développement, plus il devient difficile de faire participer les utilisateurs finaux. Le métier a peut être jonglé avec de nombreux utilisateurs finaux, et a peut-être fait des concessions avec certains utilisateurs qui font des choses un peu moins attrayantes que les autres utilisateurs. Il est impossible de récupérer l'origine de ces décisions auprès des utilisateurs.
Une grande partie de Scrum dépend de l'équipe ayant une vélocité stable. Une fois qu'un système a été pensé, l'effort de développement peut généralement être prévu avec un degré de confiance élevé. Une fois l'analyse terminée, la conception et le développement peuvent se poursuivre sans trop de surprises. La plupart des surprises du calendrier proviennent de défaillances dans l'analyse. Puisque les estimations se focalisent sur ce qui se passe durant le sprint, il est important de déplacer l'incertitude de l'analyse en dehors du sprint, au niveau du Product Owner. Si vous ne le faites pas, les développeurs ne feront plus d'analyse. Cela ralentit considérablement la vélocité, et parce que l'équipe n'est pas experte que ce soit en analyse, en utilisateurs finaux ou en prospectives sur le marché, les exigences en souffrent également :
Par conséquent : le Product Owner doit fournir des spécifications avancées, assurant ainsi qu'il a fait le travail nécessaire d'exploration et de vérification dans le domaine des exigences.
"Spécifications avancées" signifie que la spécification est assez riche pour que quelqu'un de raisonnablement compétent dans la discipline concernée, puisse mettre en œuvre une solution sans devoir ensuite recourir à une étape significative de clarification.
Le fait que les spécifications soient écrites ou non à l'avance est beaucoup moins important que le fait que le Product Owner ait réellement fait son travail. Un Élément du Backlog Produit écrit témoigne dans une certaine mesure de cette activité de recherche. En fait, une grande partie de cette recherche peut entraîner des discussions avec l'équipe de développement, les fournisseurs et partenaires, ainsi qu'avec le marketing, les clients et bien sûr les utilisateurs finaux.
