On m'a récemment posé la question : qu'est ce qu'une bonne DoD? Definition of Done. En Français: définition de fini.
Difficile à dire. Est-ce une liste à la Prévert? Ou un contrat implicite (0)?
Elle se doit en tous cas d'être unique à chaque équipe et à sa stack technique; elle dépend bien évidemment de son niveau de maturité.

Néanmoins il m'apparait clair qu'elle devrait être source de discussions et d'un accord clair entre toute l'équipe!
Car quand c'est fini, c'est fini. On ne revient plus dessus. Sinon on est "hors contrat".

On peut commencer par lire l'avis de JP Lambert sur le sujet:

On y apprend avant tout que "sa" DoD a été établie par Les équipes web du Player qu'il a accompagnées. Et que celle-ci a évolué avec le temps. C'est un des aspects cruciaux d'une DoD: c'est un objet vivant!

D'abord la DoD, c’est du sérieux, cela devrait être une revue que toute l’équipe fait à chaque fin de Sprint. Ce n’est pas une unique personne qui valide la DoD dans son coin! Il faut donc lui consacrer du temps et de l'attention.
Il me semble que les cérémoniaux Scrum ne prennent pas (assez) de temps pour passer en revue la DoD (à mon goût).

Une DoD est néanmoins quelque chose de très personnel à une équipe; et doit être le fruit d'une réflexion de groupe et de compromis. Elle peut éviter qu'un groupe au travail ne se perde au milieu de ses propres objectifs ou ne soit plus aligné avec les valeurs qu'il partage. En cela, elle est aussi un contrat social du "bien travailler ensemble".

Alors, que met-on dedans?

Je me permet de vous livrer des pistes, issues de ma propre expérience et d'équipes que j'ai pu accompagner. Ce ne sont que des exemples, à adapter à vos besoins.

Les basiques :

• Toute l’intégration continue a tourné depuis le dernier commit et tous les tests sont verts.
• Aucune user story ne reste ouverte d’un sprint à l’autre (si une reste ouverte, il faut la re-découper en deux, fermer ce qui est vraiment fait et préparer ce qu’il manque à faire en une nouvelle US en restant focus sur la valeur livrée) (1)
• Avoir des tests qui soient alignés avec les user stories et qui s'exécutent en permanence (soit par des Executable Acceptance Tests, soit par des matrices de traçabilités que l'on peut générer en taguant les tests unitaires et faire correspondre ces tags avec les exigences émergeant des U.S.) (2)

Documentation :

• Réclamer des fichiers d’enregistrement des choix techniques/d’architecture (ADR) https://github.com/joelparkerhenderson/architecture_decision_record
• pour le reste, il n'existe pas de "bonne documentation" (lisez les 6 lois); un crafter comme moi vous dira que la seule documentation qui vaille réside dans les tests (à condition qu'ils soient lisibles) et le code.

Pour le code propre

je mets personnellement des règles assez strictes, mais surtout des choses à vérifier manuellement. Les SonarQube et autres Linters / scanneurs de code me gonflent, même s'ils sont une aide utile pour les équipes qui cherchent l'uniformité ou qui n'arrivent pas à prendre assez de temps pour discuter de leur code entre eux; c'est un mal nécessaire et j'espère que ce n'est qu'une phase transitoire (3).
Quelques idées de règles possibles:

• Tout a été écrit en mode TDD (le test écrit avant le code : il compile et il est rouge. On écrit le code : le test devient vert. Cela oblige à écrire de tout petits tests, on refactore avant d'écrire un nouveau test). Ce n’est pas parce qu’on fait de l’infra/devOps qu’on ne peut pas faire de TDD ; la preuve : https://www.hashicorp.com/resources/test-driven-development-tdd-for-infrastructure
• Refactoring effectué // par exemple: Commentaires supprimés (les commentaires sont un bon indicateur de la faiblesse du code. Cf https://refactoring.guru/smells/comments )
• Pas de code dupliqué
• Limiter la complexité cyclomatique (peut se vérifier avec une règle Sonar, contraignant mais si on est un bon programmeur, on doit trouver les solutions)
• Pleins d’autres règles sur le Clean Code ont été posées partout sur les internets, personnellement j'adhère à https://refactoring.guru qui nous dit:
• Couplage trop fort : chercher les heuristiques
  • Trop de clauses imports en-tête de classe/module
  • Présence de « new » dans un constructeur d’une classe/module (couplage fort entre le code qui fait le new et la classe instanciée)
  • Usage d'un outil de calcul des dépendances,
  • et plein d'autres bonnes pratiques comme l'Injection de Dépendances et l'Inversion de Contrôle (DI et IoC).

Le souci c'est que cette liste va vite devenir longue et plus personne ne va la lire.
Et se pose toujours la question: est ce que tel bout de code en vaut la peine? Sera-t-il toujours là ou sera-t-il amené à disparaitre? Jusqu'où aller dans le refactoring?
Bien malin qui peut le dire. Le problème est que nous sommes tous à un moment donné sujet à l'amnésie. Le refactoring nous aidera juste à moins hurler "mais qui a écrit cette m**de" dans le futur (et bien souvent, celui qui avait écrit de la m, c'était moi!!!).

Le mieux à ce niveau étant peut-être d'admettre que l'équipe se doit d'être au meilleur niveau technique qui lui est possible et qu'elle doit sans cesse se former à cela (par le biais de Kata, de Mob Programming, de révisions régulière de tous les principe de Refactoring et Clean Code).

Le DoD pourrait dire:

Nous sommes satisfait de notre code (sachant tout ce que j'ai évoqué ci dessus), et nous avons fait en sorte d'être meilleurs à cette itération qu'à la précédente.

J'ai vu des équipes très tendues sur ces points là et la notion de qualité de code vraiment appréciée à des degrés très divers entre les développeurs. La qualité voulu par les uns constamment remise en question par les autres ou par le PO ("on n'a pas le temps"). C'est pourquoi la DoD devrait être écrite en dehors du cadre des Sprints, comme une volonté farouche d'arrêter de coder de la merde. Et d'en payer le prix plus tard. Et surtout d'être tous d'accord là dessus.

Tests

Ma conviction: ce ne sont pas les tests E2E qui garantissent que tout est ok; vraiment pas!
Utilisez du Contract Based Testing pour faire des intégrations propres entre vos différents services (je reviendrai là dessus).

Pour les équipes devOps, c’est également abordé dans cette vidéo de 30mn: https://www.hashicorp.com/resources/test-driven-development-tdd-for-infrastructure
Il y a plein d'Outils:

• open-policy-agent
• Goss
• Inspec
• Test-Kitchen
  • Plus de détails utiles sur https://github.com/joatmon08/tdd-infrastructure

Elements non fonctionnel

Quid de la performance du code? De la montée en charge? Des accès concurrentiels? Des failles de sécurité?
Mais là aussi, tout dépend de votre seuil de tolérance, et encore une fois d'une vision de l'avenir de votre produit.

La DoD est là pour nous dire combien est-on prêt à investir dans le futur.

Autres catégories

On peut aussi rajouter dans la catégorie Pérenne ou dans une autre catégorie, ce qu’on peut appeler : « Synchro »

• Etre sûr d'avoir dispensé, auprès des autres équipes concernées par les modifications résultantes de ce sprint, toutes les informations utiles (versionning, modèles communs, contrats, APIs et autres).

On s'aperçoit que c'est déjà, avec ces quelques bases, beaucoup de travail. Et que cet article est déjà beaucoup trop long ;)

Claude Aubry a depuis longtemps planché sur le sujet de la DoD, et il va au fond des choses, en proposant des niveaux dans les éléments de la DOD et cela a beaucoup de sens.

Les premières fois vous allez vous rater, forcément.
Ne vous découragez pas, et surtout ne laissez jamais tomber votre DoD.
Pour les POs zélés, ou les chefs de projets en mode "quand est-ce que vous aurez fini???", il faut vraiment miser sur la DoD dès le 1er jour du Sprint. Pour éviter qu'une dérive sur la qualité et la maintenabilité ne s'installe dès les premières itérations.
Il est très difficile de revenir en arrière ou perdre ses habitudes, tous agiles que nous soyons.

"Comment vais-je faire pour finir?", "Et si je commençais par finir?" devraient être les premières pensées qui animent votre travail.

Pour ne pas se laisser surprendre par la livraison et éviter l'effet panique, il vaut mieux commencer par la fin justement.
La vérification et la stabilisation de votre travail est la valeur ajoutée qu'il manquera toujours à celle du métier que l'on vous demande d'honorer.

Pour conclure, il semblerait que la meilleure DoD soit le consentement, éclairé et discuté, de l'équipe tout entière. La coucher par écrit permet d'abord la discussion et peut aussi rassurer vos parties prenantes.

(0) Evidemment je ne penche pas pour l'implicite à moins que l'équipe ne soit excessivement mûre et stable. "Making the implicit explicit" devrait s'appliquer aussi à la DoD.

(1) Si une telle situation se produit plusieurs fois, il faut réellement re questionner l’équipe sur son approche de l’agilité : est-on assez mûr pour faire des Sprints? Pourquoi laisser filer les US ouvertes ou ré-ouvertes ? Est-on sûr de la qualité de ce que nous produisons ? Savons-nous finir ce que nous commençons ? Savons nous en calculer la valeur ? Savons-nous garder les choses simples? Savons nous limiter notre WIP (Work In Progress)?

(2) C'est une immense problème que la vérification automatique d'une User Story. Le BDD pour écrire des tests End To End est une idiotie sans pareille sur laquelle je reviendrai dans un long article. Le BDD pour écrire des tests d'intégration ou de vérification métier est très utile. En fait, je ne fais pas de distinction entre BDD / TDD et TU.
Rien n'est facile en la matière mais la Vérification et Validation vaut toute documentation. Lire à ce sujet Cyrille Martaire https://leanpub.com/livingdocumentation

(3) Ce genre de pratique trop courante, car cédant à la facilité, est souvent corollaire de la présence d'un architecte tout puissant, qui dicte des règles à ces associés à travers un outil froid et des règles bétonnées. Rien ne vaut la pédagogie et la discussion, mais c'est plus long ;)