Et donc il est bon d’avoir une liste de conditions nécessaire à assurer la qualité de ce que l’équipe de développement fourni, mais pas à assurer la qualité de ce qu’un PBI représente ?
Oui
Je comprends totalement ton point de vue Samuel, mais pour moi on est vraiment sur 2 choses différentes.
D’un côté avec la DoR j’ai l’impression que l’on a le verrou pour accéder au travail de l’équipe, comme un contrat qui dirait « Vous n’avez pas fat un travail à la hauteur de nos attentes nous ne travaillerons pas pour vous ». Ca me semble vraiment matérialiser le silo. La paroi étanche entre les équipes (métier et technique).
Alors qu’avec la DoD on n’a pas une contrainte externe mais plutôt le cachet validant le fait que l’équipe valide elle-même la qualité du livrable. Il ne faut pas oublier que la « bande-passante » de l’équipe dépend aussi de la DoD. Si la DoD est énorme, l’output sera moins important mais surement très qualitatif.
Je reprends le Scrum guide :
The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
L’équipe est donc avant tout constituée pour transformer une partie du travail en incrément de valeur.
Le guide ne dit pas que le travail demandé soit explicit, implicit, prescriptif, ouvert, ou quoi que ce soit. En tout cas, les PBI qui peuvent être Faits dans un sprint sont donc jugés prêts à être sélectionné et réalisé :
Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.
Donc l’équipe juge que c’est prêt, mais rien n’oblige à suivre une check list comme une DoR.
J’ai des cas encore très récents où sur certains PBI qui plaisent au développeur et avec une certaine liberté de conception et de recherche de solution, les devs se jettent dessus avec enthousiasme et alors la DoR ils s’en foutent comme leur première couche
Et puis quand les sujets à faire sont inintéressants ça part dans un revival de la DoR d’il y a 2 ans pour te dire qu’il manque des critères d’acceptation, une maquette, des cas de tests ou je ne sais quoi
Et pourtant :
The Scrum Team members have the courage to do the right thing, to work on tough problems.
Pour savoir si c’est Fait, avec un F majuscule, il faut par-contre être plus strict sur ce qui définit le Fait. D’où une liste de critères :
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
J’en reviens au refinement qui doit servir de DoR en fait, mais en basant sur des échanges entre PO et devs, sur la collaboration et la communication :
Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.
