Release Risk Self-Check

1.1 Nous pouvons citer nos trois priorités principales pour ce trimestre, et ce n’est pas « tout ».

1.2 Chaque élément de la roadmap a une justification écrite qui renvoie à un utilisateur.

1.3 Nous décidons de ce que nous développons ensuite sur la base de faits (données d’utilisation, volume du support, échanges avec les clients) plutôt qu’en écoutant celui qui parle le plus fort.

1.4 Nous définissons ce qu’est un succès avant de développer, et nous revenons le vérifier ensuite.

1.5 Au cours des six derniers mois, nous avons réduit ou abandonné une fonctionnalité prévue parce que les faits ne la justifiaient pas.

2.1 Quelqu’un pourrait dessiner de mémoire le système sur un tableau blanc en cinq minutes, et les autres ingénieurs le reconnaîtraient.

2.2 Nous disposons d’un schéma du système mis à jour au cours des six derniers mois.

2.3 Interrogés séparément, deux ingénieurs décriraient les composants principaux de la même façon.

2.4 Nous pouvons suivre notre transaction la plus critique de bout en bout et nommer chaque service qu’elle traverse.

2.5 Nous pouvons expliquer pourquoi chaque grand choix technologique a été fait, et par qui.

3.1 Nous pourrions expliquer en deux minutes ce que nous testons à chaque niveau, et pourquoi.

3.2 Notre combinaison de tests a été choisie délibérément. Ce n’est pas simplement ce qui s’est accumulé au fil du temps.

3.3 Nous savons où nos tests sont les plus faibles, et c’est un compromis assumé plutôt qu’un angle mort.

3.4 Nous savons à peu près combien de bugs sont arrivés en production le trimestre dernier, et si ce nombre augmente.

3.5 Nos tests découlent d’exigences ou de critères d’acceptation formulés, pas seulement du code qui a été écrit.

4.1 Les tests automatisés s’exécutent à chaque merge sur la branche principale, sans que personne n’ait à les déclencher.

4.2 Le retour du pipeline arrive en moins de quinze minutes.

4.3 Un test en échec bloque la release, et cette règle n’a pas été discrètement suspendue.

4.4 Nous savons lesquels de nos tests sont flaky, et nous les corrigeons au lieu de les relancer.

4.5 Quelqu’un remarquerait en moins d’une journée si la suite de tests cessait complètement de s’exécuter.

5.1 Nous pourrions retracer une fonctionnalité livrée le mois dernier, de l’exigence au code, puis au test et au déploiement, sans aucune lacune.

5.2 La mise en production est en grande partie automatisée et ne dépend pas des connaissances d’une seule personne.

5.3 Nous pouvons revenir en arrière sur une release défectueuse en moins de quinze minutes, et quelqu’un l’a réellement fait au cours des six derniers mois.

5.4 Nous pouvons désactiver une fonctionnalité sans déployer.

5.5 Quand la production tombe en panne en dehors des heures de travail, il existe une marche à suivre définie qui ne repose pas sur la mémoire d’une personne.