Sujet : process
-
DACI et RACI pour les décisions techniques : un seul approbateur, des contributeurs nommés
DACI désigne un pilote qui mène le processus de décision, un unique approbateur qui prend la décision, des contributeurs qui ont voix au chapitre mais pas de droit de vote, et des personnes informées du résultat ; RACI attribue aux tâches des rôles de responsable de l'exécution, de responsable devant rendre des comptes, de consulté et d'informé. Les deux conviennent aux décisions techniques lorsque les rôles sont consignés avant le début de la discussion.
-
La dette technique comme décision consciente et comptabilisée
La métaphore de Cunningham : du code pas tout à fait juste est un crédit, et chaque minute de travail supplémentaire qu'il entraîne en est l'intérêt. La métaphore ne tient que si la dette est contractée consciemment, notée et évaluée régulièrement ; comme terme fourre-tout pour tout ce qui est disgracieux, ou comme excuse à la négligence, elle ne vaut rien.
-
Rédiger un rapport de bug exploitable
Un rapport de bug est exploitable quand une personne extérieure peut reproduire le défaut sans poser de question : un titre précis, l'environnement avec ses versions, des étapes numérotées pour reproduire le problème, le résultat attendu et le résultat réel séparés, le message d'erreur littéral et un exemple aussi réduit que possible. Les hypothèses sur la cause figurent dans une section à part.
-
Suivre les actions issues des post-mortems jusqu'à leur clôture : tickets de suivi, responsable unique et revue par ancienneté
Le Site Reliability Workbook avertit que, sans processus de suivi formel, les actions issues des post-mortems sont souvent oubliées ; donner à chaque action un ticket de suivi, un seul responsable, un type et une priorité, revoir les actions ouvertes par ancienneté selon un calendrier, et traiter une action en retard comme une décision à prendre plutôt que comme une ligne à ignorer.
-
Les principes agiles comme accords de travail concrets
Les douze principes qui sous-tendent le Manifeste agile deviennent utiles une fois traduits en accords d'équipe vérifiables : cadence de livraison, communication directe, rythme soutenable, excellence technique et réflexion régulière.
-
Des comptes rendus de réunion avec une section décisions séparée réduisent la réouverture de décisions
Hypothèse : les équipes dont les comptes rendus de réunion listent chaque décision séparément (énoncé, options rejetées, responsable, date) et la recopient dans un journal de décisions durable rouvrent moins souvent des questions tranchées que les équipes aux comptes rendus narratifs, parce qu'une décision qu'on peut retrouver et citer a moins de chances d'être redébattue depuis le début.
-
Traiter une demande de personne concernée comme un processus d'ingénierie : export et suppression
Traiter la demande d'une personne pour obtenir une copie ou la suppression de ses données comme un job : prise en charge vérifiée, un exportateur par magasin dans la carte des données produisant un manifeste, livraison via un téléchargement authentifié à expiration, suppression via le pipeline, exemptions listées avec des codes de raison, et un test sur sujet synthétique selon une cadence fixe ; quelles demandes doivent être honorées et quand n'est pas traité ici.
-
Documentation d'intégration : le chemin d'une machine vierge jusqu'à une modification fusionnée
La documentation d'intégration est un unique parcours numéroté qui mène une personne nouvellement arrivée, humaine ou agent, d'une installation vierge jusqu'à une modification fusionnée, en n'utilisant que ce qui est écrit ; chaque nouvelle personne corrige ce qui l'a fait trébucher, et le parcours porte un propriétaire et une date de fraîcheur.
-
Un calendrier de changements et des fenêtres de maintenance pour une petite équipe opérations
Placer chaque changement planifié susceptible d'affecter les utilisateurs sur un calendrier partagé unique avec un propriétaire, une fenêtre, une ligne de retour en arrière et des règles de blackout ; le livre SRE de Google indique que l'équipe SRE a constaté qu'environ 70 % des pannes sont dues à des changements sur un système en production, si bien que « qu'est-ce qui a changé ? » est la première question de tout incident, et le calendrier est l'endroit où elle trouve réponse.
-
Rédiger un document de conception (RFC) permettant aux personnes qui le relisent de se prononcer
Un document de conception obtient la décision avant que le code n'existe : d'abord le problème, puis les objectifs et non-objectifs, une explication au niveau de l'utilisation et une au niveau de la référence, les solutions écartées avec leur justification, les inconvénients et une liste explicite de questions ouvertes. La structure suit ce qu'exigent la PEP 1, le modèle de RFC de Rust et la pratique des documents de conception chez Google.
-
Le triage des tickets pour un petit projet : un jeu d'étiquettes fixe et une passe régulière
Le triage consiste à décider, pour chaque nouveau ticket, ce qu'il est, s'il est exploitable et à qui revient le prochain geste. Un vocabulaire d'étiquettes réduit en trois familles (type, statut, domaine) associé à une brève passe à cadence fixe maintient l'honnêteté du gestionnaire de tickets ; les étiquettes par défaut de GitHub (parmi lesquelles bug, enhancement, documentation, duplicate, question, wontfix, good first issue et help wanted) constituent un point de départ exploitable.
-
Des rétrospectives qui produisent des changements plutôt que des listes
Une rétrospective justifie le temps qui lui est consacré lorsqu'elle se termine par un ou deux changements dotés d'une personne responsable, d'une échéance et d'un critère de réalisation reconnaissable ; le Scrum Guide exige que les améliorations les plus efficaces soient mises en œuvre le plus tôt possible, et la Prime Directive donne le ton qui permet de nommer les vrais problèmes.
-
Postmortems sans recherche de coupable : consigner le déroulé, les causes et les actions
Un postmortem décrit ce qui s'est passé pendant un incident, qui a été touché et pendant combien de temps, quelles circonstances l'ont rendu possible, et quelles actions rendent une répétition moins probable. L'absence de recherche de coupable n'est pas une politesse, mais la condition pour que les personnes impliquées rapportent des faits plutôt que de se défendre.
-
Concevoir une rotation d'astreinte et sa passation
Une rotation d'astreinte a besoin d'un titulaire principal et d'un remplaçant, d'une part bornée du temps de chaque ingénieur, de durées de garde et de règles d'échange sur lesquelles chacun peut planifier, d'un budget d'alertes (pager) qui déclenche un travail correctif en cas de dépassement, et d'une passation écrite à chaque changement de garde ; le livre SRE de Google et la documentation publique sur la réponse aux incidents de PagerDuty décrivent ces contraintes.
-
Notation RICE et ICE : ce que signifient les chiffres et où ils s'arrêtent
RICE multiplie la portée, l'impact et la confiance, puis divise par l'effort ; ICE abandonne la portée et conserve l'impact, la confiance et la facilité. Les deux méthodes sont utiles pour rendre les arguments de priorisation explicites et comparables, et toutes deux échouent lorsque les données saisies ne sont que des estimations déguisées en chiffres, ou lorsque les dépendances et la stratégie sont ignorées.
-
Estimer l'effort sous forme d'une fourchette avec un niveau de confiance indiqué
Donner une estimation sous forme de fourchette (meilleur cas, valeur attendue, pire cas) accompagnée du niveau de confiance que la valeur réelle s'y trouve ; caler la largeur sur les résultats de travaux comparables antérieurs plutôt que sur le plan, et la remettre à jour à des points fixes. Un chiffre unique dissimule précisément l'incertitude dont dépendent les décisions.
-
Cadence de publication pour un petit projet : trains à intervalle fixe contre publication à la demande
Un numéro de version indique ce qu'une publication promet ; une politique de cadence indique quand les publications ont lieu. Rust publie une version stable toutes les six semaines depuis un train nightly, beta, stable ; Python est passé à une publication annuelle de fonctionnalités avec la PEP 602 ; et Django publie ses versions de fonctionnalités selon un calendrier fixe, avec des correctifs publiés au besoin. Un petit projet peut reprendre cette structure : des publications de fonctionnalités sur un calendrier ou quand quelque chose de notable s'est accumulé, des correctifs dès qu'une réparation est prête.
-
Mener une revue de conception : période de commentaires, décideur nommé et décision consignée
Une revue de proposition a besoin d'une période de commentaires bornée, d'une personne ou d'un groupe nommé qui décide, d'une décision écrite (acceptation, rejet, report) avec ses raisons, et d'une règle de réouverture ; le processus RFC de Rust et le processus PEP de Python montrent la forme, et cette méthodologie l'adapte à une seule équipe.
-
Refuser une demande de fonctionnalité sans perdre le contributeur
Un refus qui s'appuie sur un périmètre écrit, arrive rapidement, propose une alternative et clôt le fil est plus bienveillant que le silence, et il permet de garder le demandeur comme contributeur. Les Open Source Guides notent que le fait d'écrire les choses facilite le refus, et qu'une réponse demande rarement plus d'une ou deux phrases.
-
Des critères d'acceptation par élément de travail transformables en tests
Rédiger les critères d'acceptation de chaque élément de travail sous forme d'exemples concrets comportant un état de départ, une action et un résultat observable, en suivant la structure Given/When/Then de Gherkin ou un équivalent, avec les cas limites nommés ; des critères qui ne peuvent être exécutés ni vérifiés par une autre personne que l'auteur n'en sont pas.
Lisible par machine : JSON