Préparation (DoR/DoD)

DoR — Definition of Ready : ce qui doit être prêt pour que le travail commence. Elle existe pour en finir avec la demande qui passe en exécution et revient deux jours plus tard parce qu'il manquait l'accès, la donnée ou la décision.
DoD — Definition of Done : ce qui doit être fait pour que le travail soit considéré comme terminé. Elle existe pour en finir avec le « j'ai fini » qui n'a encore été ni testé, ni documenté, ni communiqué.

Les deux sont la même idée appliquée aux deux extrémités : écrire l'accord avant, pour ne pas en discuter après. Et les deux sont par ÉTAPE du tableau — chaque colonne peut avoir la sienne.

Deux listes que l'équipe convient une fois et utilise toujours : ce qui doit être prêt pour qu'une demande PUISSE commencer (Definition of Ready) et ce qui doit être prêt pour qu'elle soit considérée comme TERMINÉE (Definition of Done). C'est ce qui évite la demande qui entre dans le sprint sans périmètre et celle qui « est prête » mais que personne n'a testée.

Ici, vous enregistrez un élément de l'accord de préparation de l'équipe (DoR/DoD) : à quelle étape il s'applique, s'il est une condition pour ENTRER ou pour SORTIR de celle-ci, s'il ne vaut que pour un type de demande, le texte de l'accord, s'il bloque la sortie de l'étape, l'ordre d'affichage et s'il est actif. C'est la check-list qualité du flux, élément par élément.

Le champ « Entrer ou sortir » définit de quel côté de l'étape se situe l'accord. Un élément d'ENTRÉE est une Definition of Ready : ce qui doit être prêt AVANT que la demande n'entre dans cette étape (« critères d'acceptation rédigés », par exemple, avant d'entrer en exécution). Un élément de SORTIE est une Definition of Done : ce qui doit être fait pour que la demande SORTE de l'étape (« code review approuvée »). Le champ « Type uniquement » restreint l'élément à un type de demande — un accord de bug n'a pas besoin de s'appliquer à une amélioration.

Vous écrivez l'élément ici une seule fois ; il est copié dans la checklist de la demande elle-même quand elle entre dans l'étape, avec l'étiquette entre crochets (par exemple [DoD Em execução] testes automatizados verdes).

Remarquez qu'il n'y a pas de seconde liste à cocher : qui travaille coche au même endroit que d'habitude, dans la demande, et la vérification lit à partir de là. Une seconde liste signifierait, en pratique, une liste abandonnée.

C'est la partie la plus contre-intuitive. Quand vous faites glisser une carte d'une colonne à une autre, le système vérifie la DoD de la colonne qu'elle quitte — car la question est « peut-on considérer cela comme terminé ici ? ».

La DoR ne bloque jamais. Elle sert de vérification d'entrée, apparaît dans la checklist et fait office de rappel. Si vous cochez le blocage sur un élément de DoR, le système le désactive et prévient.

Trois issues possibles au déplacement : rien en attente, et la carte passe ; élément en attente sans blocage, et la carte passe avec un avertissement listant ce qui reste ; élément en attente avec blocage, et la carte revient à sa place. Un seul élément bloquant ouvert suffit à l'arrêter.

Un gate imposé avant l'accord produit des contournements, pas de la qualité : l'équipe apprend à tromper le tableau. Écrivez les éléments, laissez l'équipe vivre avec pendant quelques semaines et n'activez le blocage que sur ce qui est devenu une habitude et qui passe encore entre les mailles.

Deux limites honnêtes du gate, pour ne pas trop lui faire confiance : il n'agit que lors du glissement sur le tableau — changer le statut via le formulaire de la demande, en lot, ou par « terminer » ne passe pas par ici. Et, si la vérification échoue à cause d'une erreur technique, le mouvement passe. Un gate qui bloque l'activité à cause d'une panne d'infrastructure est pire que le problème qu'il évite.

L'élément et la coche se reconnaissent par le texte de l'étiquette. Si vous modifiez la description d'un accord (ou renommez l'étape, qui entre dans l'étiquette), le système ne reconnaît plus ce qui était déjà coché : l'ancienne coche reste visible dans l'historique de la demande et le nouvel élément arrive en attente.

C'est le bon comportement — la règle a changé, la vérification est refaite —, mais planifiez le changement : le faire en plein sprint renvoie des éléments en attente sur tout le tableau.

Quand vous enregistrez une vue avec le bouton Vues, elle garde quatre choses : le texte de recherche, les filtres appliqués, les colonnes affichées (et leur ordre) et la colonne de tri de la liste. Appliquer la vue restaure tout d'un coup — y compris en réinitialisant le tri et la page où vous étiez, pour que le résultat soit exactement ce que la vue décrit. Les vues enregistrées avant cette version restent valables : ce qu'elles ne gardaient pas ne change tout simplement pas à l'application.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

L'interrupteur « Bloque la sortie » sépare l'accord indicatif de l'accord contraignant : un élément bloquant retient la demande dans l'étape tant qu'il n'est pas rempli ; un élément non bloquant apparaît comme un rappel de l'accord de l'équipe, mais n'empêche pas d'avancer. Utilisez le verrou avec parcimonie — tout bloquer transforme le flux en bureaucratie et incite l'équipe à cocher des éléments sans regarder ; le blocage est pour ce qui ne peut vraiment pas passer sans vérification, comme « tests exécutés » avant de terminer.

Dans le panneau d'activité de l'enregistrement, chaque note propose « Transformer en demande ». Le clic crée un ticket avec le texte de la note, son auteur et le lien vers cet enregistrement — rien n'est ressaisi. Utilisez-le quand la note est une demande d'action (« quelqu'un doit revoir ceci ») ; la note reste où elle était. Le bouton n'apparaît qu'une fois l'enregistrement sauvegardé ; une session en lecture seule (démonstration) n'en crée pas.

Seulement si vous laissez le type vide — c'est alors une règle générale. En renseignant le type, l'élément ne vaut que pour ce type de demande (bug, amélioration, support...).

Attention à une subtilité : une demande sans type défini ne reçoit que les règles générales. Si votre DoD importante est liée à un type, la demande sans type y échappe.

Ouvrez l'enregistrement et regardez la Chronologie, à droite : elle montre chaque modification sous la forme « d'une valeur à une autre », avec la personne et la date. Quand il y a beaucoup de modifications, utilisez les deux filtres en haut de la chronologie — l'un par champ, l'autre par personne. La recherche se fait dans la base, donc une modification ancienne apparaît de la même façon. Vous pouvez aussi demander à Tenkai : « qui a modifié le contrat 482 ? ».