Équipes logicielles : bugs, stories et sas de release

Les types qu'une équipe logicielle remplit réellement

Un bug demande une gravité (bloquant, majeur, mineur ou cosmétique), les étapes de reproduction et l'endroit où il a été trouvé. Une story demande des critères d'acceptation et des story points. Une epic demande un objectif et une date cible. Des champs personnalisés permettent de les enrichir selon les besoins de l'équipe.

La hiérarchie est intégrée : une epic contient des stories, une story contient des tâches. Cela s'affiche directement dans l'interface, au lieu de reposer sur une simple convention de nommage.

• Bug : gravité, étapes de reproduction, trouvé dans
• Story : critères d'acceptation, story points
• Epic : objectif, date cible

Quatre packs, un seul moteur

Le pack logiciel gère la réception, le tri, le travail en cours, la review de code, la QA et la validation de release, puis l'état terminé. La réception et le tri disposent chacun d'une fenêtre de 24 heures. Le travail en cours dispose de 72 heures. La review de code est une étape de review de 24 heures. La QA est un travail de 48 heures. La validation de release est une étape de validation de 24 heures, gérée par le produit, avec le travail en cours comme étape de correction.

Le pack sprint gère le backlog, la sélection, le travail en cours, la review de code, la QA et l'état terminé. Le sprint est également un objet du projet : un nom, un objectif, un début et une fin, un seul étant actif à la fois. Il n'y a volontairement pas de sas de validation sur ce pack : un sprint qui se termine est différent d'un changement qui doit être formellement approuvé. Le pack de correction de bugs gère le tri, la reproduction, la correction, la vérification et la release. Le pack de release gère le cut, le staging, la signature, la production et les notes, la signature faisant office de validation.

Des transitions qui bloquent

Une carte ne peut pas quitter la réception ou le tri tant que sa checklist n'est pas complétée. La review de code dispose d'un chemin de retour vers l'état en cours avec le label modifications demandées. La QA ne peut pas passer à la validation de release tant que le test d'acceptation n'est pas effectué. La validation de release ne peut pas passer à l'état terminé tant que la décision n'est pas enregistrée. Une demande de modifications à ce sas renvoie l'élément à l'état en cours.

C'est toute la différence entre un tableau où n'importe qui peut glisser une carte dans Terminé et un workflow où l'état Terminé doit être autorisé.

Ce qu'il manque encore, en toute franchise

Quatre des lacunes précédemment listées dans cette section sont désormais comblées. Un sprint est un objet doté d'un nom, d'un objectif, d'un début et d'une fin, avec un seul sprint actif par projet, et un backlog contenant tout ce qui se trouve en dehors ; la clôture d'un sprint transfère les éléments non terminés au suivant ou les renvoie dans le backlog, tout en enregistrant l'action choisie. Les labels sont associés à l'élément et filtrent chaque vue. Le temps est saisi sous forme d'entrées typées associées à un élément le jour où le travail a été effectué, et s'additionne pour donner un total hebdomadaire personnel et un total par projet par rapport aux estimations. Le lien entre deux tickets est typé : lié, doublon ou clone, le blocage étant géré par la dépendance que le workflow lit déjà.

Ce qui manque encore, c'est l'hébergement du code. Un reviewer peut marquer des lignes dans un diff ou un patch importé, et la note s'affiche à côté des lignes concernées. Il n'y a pas de panneau de code : rien dans Tasked ne montre de dépôt, de branche, de pull request ou de commit, et GitHub n'est pas intégré. Il n'y a pas non plus de diagramme de Gantt avec des flèches de dépendance. Tasked prend en charge un sous-ensemble limité de requêtes compatibles JQL sur les champs de tâches enregistrés. Les vues enregistrées continuent d'utiliser des arbres de filtres validés, et le produit n'implémente pas l'intégralité de la grammaire ou des fonctions de Jira.

L'API publique utilise des clés d'accès limitées. Les webhooks sont accompagnés d'un journal de diffusion. OpenAPI et une page dédiée aux développeurs décrivent l'interface. Ces fonctionnalités sont disponibles avec le forfait Business.