Définition de Fini (DoD)

Une DoD complète pour une équipe produit SaaS inclut généralement : le code écrit et soumis via une pull request ; le code révisé par au moins un autre ingénieur ; les tests automatisés écrits et réussis (tests unitaires, tests d'intégration et scénarios de bout en bout pertinents) ; aucune défaillance de régression dans la suite de tests ; les critères d'acceptation vérifiés par le PM ou le QA ; les benchmarks de performance vérifiés (latence cible atteinte pour les chemins critiques) ; la revue de sécurité complétée si le changement implique l'authentification, l'accès aux données ou des entrées de données externes ; la documentation interne mise à jour (documentation API si applicable, enregistrement de décision d'architecture si une décision de conception significative a été prise) ; l'article du centre d'aide mis à jour ou créé (si le changement affecte une fonctionnalité visible par le client) ; et le feature flag configuré si un déploiement progressif est prévu.

Les organisations bénéficient d'une DoD minimale au niveau de l'organisation qui établit des standards de qualité non négociables (tests automatisés, revue de sécurité pour les changements sensibles, documentation) applicables à toutes les équipes. Les équipes individuelles peuvent étendre la DoD de l'organisation avec des critères supplémentaires pertinents pour leur domaine spécifique (par exemple, l'équipe de données pourrait ajouter « scripts de migration de données testés et annulés avec succès en staging » ; l'équipe mobile pourrait ajouter « testé sur les versions minimales d'OS supportées »). Le Product Ops travaille avec la direction de l'ingénierie pour définir la DoD au niveau de l'organisation, la documente comme une norme formelle et s'assure qu'elle est référencée dans les supports d'intégration pour les nouveaux ingénieurs et PMs.

L'application est plus efficace lorsqu'elle est automatisée ou intégrée au workflow plutôt que de dépendre de listes de contrôle manuelles. Application automatisée : pipelines CI/CD qui bloquent le merge en cas d'échec de test ou de violations de linting ; règles de protection de branche de dépôt qui exigent l'approbation de la PR avant le merge ; outils de balayage de sécurité automatisés qui signalent les vulnérabilités comme des vérifications CI. Application humaine : la DoD comme liste de contrôle dans l'ordre du jour de la revue de sprint (la revue de sprint elle-même est la porte — si les critères de la DoD ne sont pas remplis, le travail n'est pas accepté et est reporté) ; une brève étape de vérification QA avant que les stories ne passent de « Review » à « Done » sur le tableau. Le Product Ops effectue des audits périodiques de la DoD — échantillonnant les stories terminées et vérifiant que les critères de la DoD ont bien été respectés — pour éviter l'inflation des notes dans la vélocité de sprint.