Releases

Qu’est-ce qu’une Release ?

Une release représente une version de votre produit. Elle répond à : “que livrons-nous, et quand ?”

Dans Sinra, une release est définie par son périmètre : l’ensemble des capabilities qu’elle inclut. Cela est décidé délibérément au moment de la planification, pas assemblé rétrospectivement à partir de ce qui était terminé avant le déploiement.

Release vs Cycle

Ces deux concepts sont souvent confondus. Ils sont indépendants :

Un seul cycle peut contenir des issues de plusieurs releases. Cela permet aux équipes de travailler sur un correctif de maintenance pour v1.2 en même temps que de nouvelles fonctionnalités pour v2.0, dans le même cycle.

Une Seule Règle : une Issue Prend la Release de sa Capability

Une issue prend la release de sa capability. Sans capability, on choisit sa release à la main.

Cette règle n’a aucune exception, quel que soit le type de l’issue (spécification, plan, tâche ou bug). La release d’une capability et celle de ses issues ne peuvent donc jamais diverger :

• Sur le formulaire d’une issue, la release et la release souhaitée sont en lecture seule quand l’issue est dans une capability. Elles nomment la capability dont elles viennent. Choisir ou changer la capability les met à jour avant l’enregistrement.
• Déplacer une capability vers une autre release déplace toutes ses issues, en une seule opération qui réussit ou échoue en bloc.
• Une issue sans capability, de n’importe quel type, choisit sa release librement. Détacher une issue de sa capability lui conserve la release qu’elle avait, et le champ redevient modifiable.
• La release souhaitée suit la même règle.
• Le formulaire affiche la release héritée en texte, avec un lien vers la capability dont elle vient. Toute demande qui change la release d’une issue restée dans sa capability, depuis l’interface ou l’API, est refusée avec un message (422 pour l’API).
• L’API refuse une issue qui est dans une capability avec une release différente, et l’accepte quand aucune release n’est envoyée : l’issue prend alors la release de la capability. Les imports CSV et de dépôt n’échouent jamais sur cette règle, la release est simplement reprise de la capability.

Sur la page d’une release, les issues qui sont dans une capability apparaissent sous leur capability. Le groupe Outside capability contient uniquement les issues sans capability, et les groupes totalisent toujours le nombre d’issues de la release. Vous ne pouvez ajouter une issue à la release ou l’en retirer directement que si elle n’a pas de capability : pour les autres, la page indique de déplacer la capability. Les modifications en masse de la release ignorent les issues qui suivent leur capability et vous en donnent le nombre.

Définir une Release

Quand vous créez une release, vous définissez :

• Nom et numéro de version : votre schéma de versionnage (sémantique ou basé sur le calendrier)
• Date de livraison cible : quand vous prévoyez de livrer
• Capacité cible : jours de travail budgétés pour cette release

Ensuite, en utilisant la vue Backlog, vous assignez des capabilities à la release. Chaque capability amène ses issues avec elle. C’est là que se prennent les décisions de périmètre.

Planification de la Capacité

Sinra calcule si votre release est réalisable en fonction de :

• Temps total estimé des tâches et des bugs de la release, issues sans capability comprises (la charge de développement)
• Capacité de l’équipe disponible sur les cycles qui livreront ces issues

Si la release est sur-capacité, Sinra le fait remonter avant que vous vous engagiez. C’est le changement fondamental que Sinra opère : confronter l’ambition à la réalité au moment de la planification, pas au moment de la livraison.

Lire la Charge d’une Release

La page d’une release a un bloc Charge : le développement face à la cible (« 39 / 40 j (98 %) »), le temps de spécification et de plan à part (« Spec/plan 27,5 j, hors capacité »), le nombre de tâches et bugs non estimés, et la comparaison entre la cible et la capacité des cycles. La carte du Backlog et le tableau de bord produit affichent le même développement.

Les indicateurs d’avancement portent le nom de ce qu’ils mesurent :

• Avancement du développement : l’avancement des tâches et des bugs pondéré par leur estimation, Σ(estimation × % du statut) / Σ estimations. Une spécification terminée ne le change pas ; une spécification affiche à part sa rédaction et la réalisation de ses tâches.
• Temps passé / estimé : temps passé divisé par temps estimé, tâches et bugs seulement. Ce n’est pas le calendrier.

Survolez un libellé pour lire sa formule.

États des Releases

Quand une release est livrée, Sinra crée automatiquement sa rétrospective.

Communiquer une Release

Un périmètre de release défini en capabilities se traduit directement en communication aux parties prenantes :

“v2.4 sera livrée en juillet. Elle inclut : notifications email, export CSV et gestion des rôles.”

C’est quelque chose que votre équipe commerciale, vos utilisateurs et votre support peuvent comprendre sans ouvrir le backlog.

Rétrospectives

Chaque release génère automatiquement une rétrospective quand elle se ferme. L’équipe remplit quatre catégories :

• Bien : ce qui a bien fonctionné
• Mal : ce qui n’a pas fonctionné
• Améliorations : changements de processus à essayer la prochaine fois
• Général : tout le reste

Les rétrospectives sont liées aux releases, pas aux cycles, parce que ce qu’on apprend concerne ce qu’on a livré, pas la durée pendant laquelle on a travaillé.

Lire les chiffres de charge

Survolez chaque chiffre du bloc Charge pour en lire la définition. Développement est le nombre de jours estimés des tâches et bugs de la release face à la capacité cible. Les jours de spec/plan sont comptés à part et jamais pris sur la capacité. La cible est la capacité avec laquelle la release a été planifiée, la capacité des cycles est la somme de la capacité des cycles qui la portent (un cycle partagé avec une autre release compte en entier dans chacune), et l’écart est la capacité des cycles moins la cible : positif = de la marge.