Présentation
Qu'est-ce que DoR
Pourquoi avez-vous besoin d'un DoR?
Où utiliser DoR
Quand utiliser DoR
Modèle INVEST
Conclusion
Les références
Présentation
Vous avez sûrement entendu plus d'une fois, vous avez probablement même utilisé l'artefact Scrum - Définition de Terminé avec l'équipe, ci-après - DoD. Peut-être l'utiliser sans même s'en rendre compte. De nombreux articles en russe ont été écrits sur le DoD. Ils parlent de lui lors de conférences et de formations. Comprendre pourquoi cet artefact est nécessaire et trouver des exemples n'est pas difficile. Le DoD définit les critères selon lesquels chaque membre de l'équipe comprend que la tâche est fermée. L'objectif le plus profond est de synchroniser le concept de Terminé entre chaque membre de l'équipe. Au-dessus de ces critères, souvent, l'équipe travaille lors d'une rétrospective. Il existe un artefact similaire sur lequel, pour une raison quelconque, il n'y a aucune mention de Scrum dans les ressources russophones, et où cet artefact est mentionné, aucune explication n'est donnée sur ce qu'il est, pourquoi il est nécessaire et comment l'utiliser.
Très probablement, des phrases comme la vôtre ont sonné dans votre équipe: «Nous avons échoué l'objectif parce que nous avons mal évalué la tâche» ou «Notre bon de commande est revenu avec la tâche sans une description appropriée». Dans mon équipe, de tels «signaux» sont apparus plus d'une fois, et pendant longtemps j'ai cherché un moyen de résoudre ce problème.
Définition de Ready, ci-après dénommé DoR, je suis tombé par hasard sur un chat de profil dédié à Agile. En essayant de trouver des informations, je n'ai trouvé aucune mention dans RuNet sur ce sujet. Par conséquent, je suis allé lire et traduire des articles en anglais. Maintenant, je partage le résultat avec vous, j'espère que cela contribuera à rendre votre équipe encore plus cool et plus productive.
Qu'est-ce que DoR
Alors, qu'est-ce que DoR? Le traducteur Google vous dira qu'il s'agit d'une "définition de l'état de préparation". Si le DoD inclut des critères pour terminer une tâche, alors DoR - des critères pour la préparation d'une tâche à entreprendre. Autrement dit, si une tâche répond aux critères du DoR, l'équipe peut la prendre en charge pour la planification du travail. Cela semble simple, vous avez probablement déjà commencé à réfléchir à la manière dont, enfin, avec l'équipe, établissez une liste complète des exigences pour votre bon de commande afin qu'il commence à écrire une tonne de documentation, et que les autres membres de l'équipe puissent s'asseoir calmement devant leur ordinateur et écrire du code en silence. Ce n'est qu'un début et le DoR n'est pas ce qu'il semble à première vue.
Pourquoi avez-vous besoin d'un DoR?
Tout d'abord, nous répondons à la question: pourquoi cet artefact est-il nécessaire? Quel avantage apportera-t-il à l'équipe? DoR aidera l'équipe:
- Évitez de commencer à travailler sur des fonctionnalités qui n'ont pas de définition claire des critères d'achèvement. L'équipe comprendra quand la User Story est considérée comme terminée et ce qui doit être fait pour ce faire.
- Ne perdez pas beaucoup de temps en vain sur de longues discussions, des tâches mal pensées. Une tâche prétraitée fera gagner du temps à toute l'équipe. Calculez le temps qu'il faut pour discuter d'une «mauvaise» tâche, pour une personne. Maintenant, multipliez par le nombre de personnes dans l'équipe. Et maintenant, pour le nombre de ces tâches.
- Concentrez votre temps et votre énergie sur des choses aussi «sûres» que possible. L'un des démotivateurs les plus puissants est la fonctionnalité qui est jetée dans le bac.
- Faites participer chaque participant à la discussion des tâches. Tout d'abord, cela motive l'équipe. Deuxièmement, il permet de révéler chaque membre de l'équipe en tant que spécialiste. Troisièmement, les développeurs offriront leur propre vision du problème. Au cours de la discussion, d'autres solutions peuvent surgir qui différeront radicalement de l'idée originale.
Jetons un coup d'œil à la liste des problèmes qui résultent indirectement ou directement du manque de DoR:
- Des divergences dans la compréhension du problème apparaissent régulièrement entre les membres de l'équipe. À la fin du sprint, l'écart s'intensifie, ce qui entraîne des incidents lorsque des changements se produisent dans le processus de développement, ce qui est naturel. Mais étant donné que ces moments n'ont pas été enregistrés, seul celui qui les a rencontrés directement les connaît.
- Les exigences fonctionnelles changent plus rapidement que l'équipe ne parvient à les comprendre. Depuis que la tâche est entrée dans le sprint, avec une grande incertitude, au moment où la pièce est prête et la "fondation" est posée, de nouvelles informations apparaissent qui nécessiteront un retour au début. Plus la tâche est mauvaise, plus souvent une telle situation se produit au sprint. En fin de compte, cela conduira à un fakap.
- Souvent, il y a des problèmes pour évaluer le résultat obtenu à partir de la fonctionnalité, l'équipe ne sait pas comment collecter les métriques, ou pire encore, les a oubliées. Scrum concerne principalement les avantages pour le client, l'utilisateur ou l'acheteur. Si l'équipe n'évalue pas les avantages de la tâche, elle ne reçoit pas de commentaires et n'a pas la possibilité d'ajuster le cours du développement du produit. Cela peut conduire à un échec complet.
- De plus, le manque de DoR a un grand impact sur les tests, et au lieu des attentes de test de QA sur la User Story, il testera les attentes des développeurs. Le code peut fonctionner parfaitement, les autotests fonctionneront comme sur des roulettes, mais la fonctionnalité ne fonctionnera pas sur la production.
Au final, cela conduit à la sortie d'un produit qui ne fonctionne pas, inutile, ne résout pas le problème principal. Et c'est une perte de temps que tout le monde veut consacrer à des choses importantes. Dans l'un des articles, je suis tombé sur un excellent dicton: "Les ordures sont entrées, les ordures sont sorties."
Où utiliser DoR
Les DoR sont utilisés dans le raffinement du carnet de produit, ci-après dénommé PBR ou nom d'artefact plus connu: Grooming. Au cours de cette activité, les User Stories deviennent Ready - Ready. Cela signifie que le résultat de l'événement, dans le backlog de produit, est Ready US. Le DoR est nécessaire pour décrire l'état dans lequel les États-Unis peuvent être discutés sur la planification. C'est ce qu'on appelle Takin in - accepté par les États-Unis.
Pour aller plus loin, je fais attention à la façon dont Jeff Sutherland, l'un des fondateurs du manifeste Scrum et Agile, parle de DoR et DoD dans ses vidéos. Sutherland présente les concepts de Done-Done et Ready-Ready. Lorsqu'un membre de l'équipe dit qu'une tâche est prête ou terminée, il est entendu qu'elle répond aux critères définis par l'équipe dans DoD et DoR, respectivement. C'est un aspect important, chaque membre de l'équipe doit le comprendre et ne pas l'oublier. Sinon, des situations amusantes surviennent lorsque Petya dira au Quotidien que la tâche est déjà terminée, puis il se trouve que des tests doivent être ajoutés là-bas, et il serait bien de refactoriser le code, et la révision du code n'est pas encore terminée.
Ainsi, jusqu'à ce que les États-Unis atteignent l'état Ready-Ready, il n'existe pas et n'est pas discuté dans la planification. Le haut de l'arriéré doit être uniquement aux États-Unis, avec un état Prêt-Prêt. La meilleure façon d'y parvenir est de travailler aux États-Unis avec l'équipe. Cela nous permettra d'examiner le problème sous différents angles, d'impliquer chaque membre de l'équipe dans le processus et, par la suite, de développer la responsabilité collective pour la fonctionnalité publiée. Les développeurs seront eux-mêmes responsables du résultat et de la qualité s'ils réalisent que c'est le fruit de «leur» travail commun.
Quand utiliser DoR
Lorsque l'équipe comprend pendant le PBR que la tâche ne correspond pas au DoR et comporte trop d'incertitude, faites une liste de questions, choisissez un chercheur et repoussez la tâche jusqu'au prochain PBR. Dans mon équipe, cela s'appelait Research, mais plus tard nous sommes passés à Spike de XP, car nous pensions que cela apportait plus de résultats et de clarté sur les résultats de l'étude. Assurez-vous de limiter l'étude par le temps et de désigner le résultat que vous souhaitez obtenir à la fin. Pendant Spike, le chercheur peut attirer toute aide extérieure, par exemple des membres d'autres équipes, des méthodologistes, des OP, des architectes ... en général, toute personne qui le juge utile. Résultat - réponses aux questions, nouvelles données, prototype. S'il existe de nombreux User Stories, vous pouvez prendre 1-2 pointes dans chaque sprint pour la prochaine itération, assurant ainsi un flux constant de tâches prêtes.
Comme mentionné ci-dessus, DoR est un ensemble de critères. L'équipe peut essayer de composer elle-même ces critères. Parcourez ces «signaux» qui sont tracés dans les itérations. Discutez rétrospectivement de ces points, trouvez la cause profonde. Si vous ne voulez pas passer la prochaine rétrospective à ce sujet, utilisez des solutions toutes faites.
De nombreux articles décrivent le modèle INVEST, qui est similaire à SMART, mais plus adapté à la User Story. En plus des articles, ce modèle est également recommandé dans la littérature Agile. Par exemple, Roman Pichler dans le livre «Product Management in Scrum» ou Mike Cohn - «User Stories. Développement logiciel flexible. ”
Modèle INVEST
- Indépendance indépendante - Essayez d'éviter de créer des États-Unis qui dépendent les uns des autres. De telles dépendances posent des problèmes de hiérarchisation et de planification. Le client peut choisir les États-Unis avec une priorité élevée, qui dépend de la tâche avec une priorité inférieure. Les États-Unis dépendants doivent être fusionnés, divisés différemment ou en pointe.
- Négociabilité négociable - Les États-Unis ne sont pas une obligation ou une exigence contractuelle officielle. Les États-Unis ne sont pas une tâche technique. Pendant le sprint, ils peuvent et doivent être discutés et modifiés. Une fiche avec un historique, sous quelque forme que ce soit, est une brève description de la fonctionnalité, dont les détails doivent être clarifiés pendant le travail. Laissez des notes sur les fiches pour générer une discussion lorsque la tâche sera terminée. Il est important de trouver un terrain d'entente ici, car l'excès de notes, l'équipe le percevra comme une information exhaustive, et il n'y aura aucune discussion du tout. Mon équipe a découvert cela très rapidement. Les détails discutés deviennent des tests qui peuvent être écrits au dos du papier ou dans le commentaire de la carte électronique. Les tests d'acceptation sont simples et clairs pour tout le monde.
- Valeur précieuse pour l'utilisateur ou le client - «Chaque histoire doit avoir une certaine valeur pour l'utilisateur» - une déclaration incorrecte. Oubliez le plus constamment l'acheteur. Focus, selon votre entreprise: B2C, B2B, B2G. L'essentiel est d'éviter les histoires qui ne valent que pour les développeurs. Ces histoires doivent être reformulées afin que les avantages deviennent évidents et que le client puisse fixer des priorités. Pas besoin de jeter les tâches architecturales à la poubelle, d'expliquer au client les avantages d'une telle tâche et de la reformuler.
- Estimation estimable - les développeurs devraient être en mesure d'estimer la taille des États-Unis, c'est-à-dire le temps approximatif qu'il faudra pour mettre en œuvre. Il y a trois raisons principales pour lesquelles l'intensité du travail peut ne pas être mesurable:
- L'équipe manque de connaissance du sujet
- L'équipe manque d'expérience technique
- L'histoire est trop grande
Dans le premier et le deuxième cas, Spike vous aidera. Dans le troisième, les États-Unis doivent être décomposés en plus petits. - Petite compacité - beaucoup dépend de la taille des États-Unis, les États-Unis trop grands et trop petits sont difficiles à évaluer. Les épopées sont difficiles à travailler, car elles consistent en plusieurs États-Unis. Les épopées peuvent être divisées en deux types:
- Composé. Ici, tout est simple - on se décompose. Considérez le reste des points, la première chose que l'équipe suggérera probablement: divisez les États-Unis par type de couche architecturale: par les États-Unis en une base de données, backend, frontend, etc.
- Compliqué. La grande taille des États-Unis est due à leur essence même, soit ils ne sont pas décomposés, soit c'est très difficile. Dans ce cas, nous utilisons un pic.
- Testabilité testable - la confirmation que les États-Unis ont été développés avec succès, sert de test réussi. Si les États-Unis ne peuvent pas être testés, l'équipe ne saura pas quand la création sera terminée ou élaborera elle-même les critères. De plus, chaque membre de l'équipe sera différent.
Conclusion
En conclusion: en utilisant DoR, vous ne vous débarrasserez pas des lacunes qui s'infiltreront dans le sprint. Cela ne signifie pas non plus que pendant le sprint, il n'y a pas besoin de contact constant entre PO et les développeurs. Enregistrez constamment les résultats des discussions sous forme de tests d'acceptation, de sorte qu'aucune équipe ne perdra la compréhension de l'état de la tâche. Analyser et discuter avec l'équipe des problèmes actuels, peut-être liés au manque de DoR.
Le DoR est un artefact qui permettra à l'équipe de mieux réfléchir aux États-Unis, ce qui réduira finalement les risques et permettra à chaque membre de l'équipe de discuter constamment des tâches. Vous trouverez de nombreuses informations détaillées sur INVEST et User Story dans le livre «User Stories». Je recommande à chaque membre de l'équipe de lire ce livre, ou au moins de le lire vous-même et de partager des informations avec eux.
Écrivez dans les commentaires quels DoD et DoR sont utilisés dans votre équipe.
Les références
1) Roman Pichler «Gestion des produits dans Scrum»
2) Mike Cohn «Histoires personnalisées. Développement logiciel flexible »
3) agilealliance.org
4) linkedin.com
5) boost.co.nz
6) scruminc.com