Flux de développement

Comment cela fonctionne

La mécanique de ce kit, sans détour — ce qui tourne et quand, où atterrissent les données, et ce que vous regardez.

• Synthèse de développement tourne en semaine, le matin · 8 h et tient à jour le tableau de bord Flux de développement. En semaine, le matin — à qui c’est le tour, et ce qui est resté en plan.
• Ce qui est capté arrive dans le jeu de données Journal des PR, rangé sous Data/PR Log dans votre coffre — à vous de l’ouvrir, d’y chercher et de le modifier comme n’importe quel autre fichier.
• Ce qui est capté arrive dans le jeu de données Journal de développement, rangé sous Data/Dev Log dans votre coffre — à vous de l’ouvrir, d’y chercher et de le modifier comme n’importe quel autre fichier.
• Ce qui est capté arrive dans le jeu de données Liste de dette technique, rangé sous Data/Debt List dans votre coffre — à vous de l’ouvrir, d’y chercher et de le modifier comme n’importe quel autre fichier.
• Le tableau de bord Flux de développement lit le jeu de données et montre d’un coup d’œil : pR au journal · fusionnées cette semaine · tickets à votre charge · revues que vous devez · à qui le tour · par repo · parcourir la liste de dette technique · la liste de dette technique, par état · livré et cassé, récemment · comment fonctionne ce tableau.

Le câblage, en un coup d’œil : Synthèse de développement écrit dans Journal des PR · Synthèse de développement écrit dans Journal de développement · Saisie des incidents écrit dans Journal de développement · Flux de développement affiche Journal des PR · Flux de développement affiche Journal de développement · Synthèse de développement tient Flux de développement à jour · Saisie des incidents est confié à Relay · Rétrospective de développement est confié à Relay · Suivi de la dette technique écrit dans Liste de dette technique · Flux de développement affiche Liste de dette technique · Notes et comptes rendus lit Journal de développement · Lecteur de la file est confié à Relay · Notes et comptes rendus est confié à Relay · Suivi de la dette technique est confié à Relay.

En tirer le meilleur

Un kit gagne sa place quand il change ce que vous regardez et ce que vous dites, pas quand il est installé. Voici le rythme qui le rend payant.

• Ouvrez Flux de développement avant d’ouvrir le moindre onglet. La synthèse a déjà trié chaque pull request ouverte selon à qui revient la main et depuis combien de temps elle attend, et compté les tickets qui vous sont assignés.
• N’attendez une carte que lorsque quelque chose s’enlise. La Synthèse de développement lit vos dépôts chaque matin en semaine et en émet une pour une relecture que quelqu’un attend depuis des jours, ou pour votre propre pull request dont personne ne s’est saisi ; une file calme n’envoie rien.
• Avant de relire, demandez à Relay ce que fait une pull request. Le Lecteur de la file dit ce qu’elle dit faire, ce qu’elle touche et sa taille, d’après la pull request elle-même ; la revue, et tout commentaire, restent les vôtres.
• Mentionnez incidents, déploiements et décisions en passant — « la prod est tombée vingt minutes, migration ratée », « api 2.14 est passée en production », « on a décidé d’abandonner l’ancien endpoint » — et Saisie des incidents les consigne. Une décision prise pendant la gestion d’un incident va au Journal des décisions de Réunions et actions si vous avez ce Kit, pour rester avec vos autres décisions ; sinon, elle va au journal de développement. Une fois un incident clos, demandez à Notes et comptes rendus un compte rendu sans recherche de coupable.
• Demandez à Notes et comptes rendus votre note de stand-up le matin, ou les notes de version de ce qui a été fusionné depuis le dernier déploiement. Les deux viennent de ce qui a été consigné et de ce que vous lui dites, jamais d’une supposition.
• Nommez la dette technique dès que vous butez dessus, et Suivi de la dette technique la garde dans vos mots. De temps en temps, appuyez sur « Parcourir la liste de dette technique » dans le tableau de bord et réévaluez chaque dette.
• Quand une dette est planifiée, remboursée ou ne vaut pas la peine d’être corrigée, dites-le et la ligne change d’état. La dette remboursée reste sur la Liste de dette technique comme trace de ce qui a été réparé. Demandez ce qu’elle contient et Relay vous la relit, de l’impact le plus fort au plus faible, avec ce que chacune vous coûte ; ce qu’il faut rembourser, c’est à vous de décider.
• Interrogez Rétrospective de développement quand le débat s’engage : « qu’est-ce qui est sorti en juin ? », « pourquoi a-t-on choisi cette base de données ? ». Dites à Relay quels dépôts comptent et au bout de combien de temps une PR traîne, et gardez en tête qu’il n’y a aucune vue sur la CI ici : le tableau de bord montre l’état des pull requests, rien de plus.

Faites-le vôtre

Rien ici n’est figé. Les pièces sont des agents, des routines, des jeux de données et des tableaux de bord ordinaires : tout ce que vous savez sur la façon de les façonner s’applique. Retirez ce qui ne rapporte rien.

Ce que les gens changent en premier, d’habitude

Dites n’importe laquelle de ces phrases en conversation, ou modifiez-les sur la page du kit dans l’application.

• Au bout de combien de jours une PR traîne, séparément pour les revues que vous devez et pour votre propre travail en attente.
• Les dépôts qu’elle surveille.
• L’heure de la synthèse, ou la désactivation des cartes pour ne garder que le tableau de bord.
• Ce qui mérite d’aller au journal de développement — certains n’y notent que les incidents, d’autres chaque décision.
• La façon dont votre note de stand-up est organisée, et les dépôts que couvrent les notes de version.
• Ce qui compte comme une dette à garder, et comment vous l’évaluez.

Votre première exécution

L’installation lance une courte conversation de mise en place — pas un formulaire. Répondez grossièrement, corrigez plus tard.

1. Ajouter le Kit propose aussitôt la première synthèse : une fois GitHub connecté dans l’écran Connecteurs, lancez-la d’une touche et Relay lit vos dépôts — chaque pull request ouverte que vous avez écrite ou qu’on vous a demandé de relire, à qui c’est le tour et depuis combien de temps elle attend. Vous préférez commencer sans ? Dites à Relay ce qui est sorti ou ce qui a cassé, et cela va au journal de développement.
2. Dans tous les cas, Relay part de ce que 1Presence sait déjà : votre mémoire, et les notes d’incident, notes de version ou listes de tâches de votre coffre. Il propose ce qu’il trouve pour que vous disiez oui avant que quoi que ce soit n’entre dans un registre, et ne demande que ce qui manque.
3. Quand la synthèse est terminée, Relay laisse une courte note et propose quelques minutes ensemble pour compléter ce que GitHub ne peut pas montrer : quels dépôts comptent, ce que vous jugez en souffrance, ce qui est sorti, a été mis en ligne ou a cassé récemment, une décision à garder, et la dette sur laquelle vous butez sans cesse.
4. Ce qui reste vide attend sur la page du Kit, avec un chemin pour revenir à Relay, et Relay le propose une fois à la prochaine conversation. Dites à Relay qu’une partie ne vous concerne pas, ou que vous avez fini de configurer, et il cesse de demander.
5. Elle ne vous signale que ce qui traîne vraiment. Une file en bon état ne produit aucune carte.
6. Mentionnez un incident, un déploiement ou une décision en passant et cela arrive au journal de développement, avec les mots que vous avez employés sur le moment.
7. Elle ne voit pas l’état des builds — le connecteur n’a aucun outil de CI — et ne dit donc jamais si un build est passé ou si main est au vert.

Regardez le premier passage, puis dites-lui ce que vous auriez fait différemment — cette correction lui apprend plus que n’importe quelle configuration.

L’essentiel

L’apprentissage, les préférences et le coût des exécutions fonctionnent de la même façon dans chaque kit — ils sont donc traités une fois, dans le guide des Kits.

Vivre avec un Kit — le guide des Kits →

← Tous les kits