Le système de capacité de Sinra rend visible l'équation fondamentale du projet : ce que vous voulez livrer vs ce que votre équipe peut réellement faire. Découvrez comment fonctionnent les taux de disponibilité, la capacité des cycles et les calculs de charge de travail.

L’idée Centrale

La plupart des outils de gestion de projet vous permettent d’ajouter des issues sans limite. Vous vous retrouvez avec un backlog plus grand qu’une équipe ne pourrait jamais livrer, et la planification devient du hasard.

Sinra fait le contraire. Chaque élément de travail a une estimation de temps. Chaque membre de l’équipe a un taux de disponibilité. Chaque cycle a une capacité calculée. Le système rend visible l’écart entre l’ambition et la réalité avant que vous vous engagiez.

Taux de Disponibilité

Chaque membre de l’équipe a un target_capacity entre 1% et 100%.

100% : temps plein sur le projet
50% : mi-temps (temps partiel, réparti sur plusieurs projets, etc.)
80% : prend en compte les réunions, revues de code et la surcharge

Ces taux sont définis dans la configuration de l’équipe et reflètent la réalité, pas les aspirations.

Calcul de la Capacité du Cycle

Quand un cycle est créé avec des dates de début et de fin, Sinra calcule automatiquement sa capacité :

Capacité du cycle = Σ (jours_membre × taux_disponibilité)
                    pour tous les membres de l'équipe
                    sur les jours ouvrés du cycle

Un cycle de 10 jours avec :

Alice à 100% : 10 jours
Bob à 50% : 5 jours
Carol à 80% : 8 jours

Donne une capacité totale du cycle de 23 jours.

Ce nombre est fixe. Vous ne pouvez pas planifier plus de travail dans un cycle que sa capacité ne le permet sans voir la surcharge.

Suivi de la Charge de Travail

Dans un cycle, Sinra suit la charge de travail par membre :

Estimé : total des estimations d’issues assignées à ce membre
Passé : temps réel enregistré
Restant : estimé moins passé

La vue de charge de travail du cycle montre tous les membres simultanément, rendant immédiatement visible si un développeur est surchargé pendant qu’un autre a de la capacité.

Composition d’un cycle

La capacité d’un cycle ne compte que les personnes de sa composition. Un manager ou un product owner qui ne développe pas est retiré de la composition du cycle : il ne dilue plus la moyenne de l’équipe, et une personne au-delà de 100 % se voit. Le pourcentage d’un membre reste compris entre 1 % et 100 % ; pour l’exclure, on le retire.

Les tâches et les bugs encore assignés à une personne hors composition comptent dans la charge du cycle, sans capacité en face. Ils sont signalés « hors composition » dans le panneau de charge et dans l’infobulle de la jauge.

Un nouveau cycle reprend la composition du précédent : une personne retirée d’un cycle reste exclue des suivants. Voir Cycles.

Charge d’une Équipe

La même règle s’applique un niveau au-dessus. La capacité d’une équipe est la somme de ce que ses membres lui apportent, et sa charge est tout ce qui est assigné à l’équipe ou à l’un de ses membres, rapporté à cette somme :

Capacité d'une équipe = Σ (jours ouvrables du cycle × disponibilité du membre)
                        pour chaque membre de l'équipe

Charge d'une équipe   = Σ (estimations assignées à l'équipe ou à ses membres)
                        ÷ capacité de l'équipe

Backend, sur un cycle de 10 jours, avec Thomas à 60 % et Jean à 100 %, dispose de 16 jours de capacité. Porter 16 jours d’estimations place l’équipe à 100 %, pas à 200 %. Le chiffre du cycle suit la même règle : les capacités des équipes qui y participent s’additionnent, elles ne se moyennent pas.

Les capacités s’additionnent à tous les niveaux. Les moyenner reviendrait à mesurer un membre moyen plutôt que le groupe, et une équipe exactement pleine afficherait 100 % multiplié par son nombre de membres.

Chaque ligne du panneau de charge se lit donc seule : un membre au-dessus de 100 % s’est engagé sur plus de jours qu’il n’en a, et une équipe au-dessus de 100 % également. Un membre en dépassement ne met pas forcément son équipe en dépassement, et c’est exactement l’arbitrage que l’écran de planification sert à instruire.

Charge de Développement et Charge de Rédaction

La capacité mesure l’implémentation : la charge qui lui est comparée ne compte donc que le temps estimé des tâches et des bugs. Cela vaut pour un cycle, par personne et par équipe, et pour une release.

Les spécifications et les plans restent planifiables dans un cycle ou une release et gardent leur estimation. Ce temps est affiché à part, par exemple “Spec/plan 2 j (hors capacité)”. C’est une information, pas une charge : ajouter une spécification à un cycle ne change pas son pourcentage de charge. Une capability composée uniquement de spécifications et de plans a une charge de développement nulle. La ligne est masquée quand il n’y a pas de temps de rédaction.

Capacité de la Release

Au niveau de la release, la planification de la capacité fonctionne sur plusieurs cycles :

Temps total estimé des tâches et des bugs de la release, issues sans capability comprises
Réparti sur les cycles où ces issues sont planifiées
Comparé à la capacité totale disponible de l’équipe dans ces cycles

Cela fait remonter la surcharge au niveau de la release, pas seulement au niveau du cycle. Vous pouvez voir, avant de commencer le travail, si le périmètre de la release est réaliste.

Lire les Chiffres

Tous les écrans lisent les mêmes chiffres : une release ou un cycle n’affiche jamais deux totaux différents.

Le développement est le temps estimé des tâches et des bugs. C’est le seul chiffre comparé à une cible ou à une capacité, affiché « 39 / 40 j ».
Spec/plan est le temps estimé des spécifications et des plans, affiché à part et libellé « hors capacité ».
Les non estimées comptent les tâches et bugs sans estimation (« 2 non estimées ») : elles ne pèsent rien tant que personne ne les estime.
Les durées suivent un seul format, avec une décimale au plus : « 17,5 j », « 18 j ».

Sur la page d’une release, le bloc Charge compare aussi la cible de la release à la capacité de ses cycles (les cycles qui contiennent au moins une de ses issues) et donne l’écart signé, par exemple « Cible 40 j · Capacité des cycles 51 j · Écart +11 j ». Un cycle partagé avec une autre release compte en entier dans chacune. C’est une information : rien n’oblige les deux chiffres à correspondre.

Un cycle affiche son propre total en tête du panneau de charge, par exemple « Développement planifié 17,5 / 18 j · 97 % de la capacité », puis chaque équipe avec ses jours et son pourcentage de la capacité de l’équipe. Le travail assigné à une équipe sans nommer de membre est libellé « Assigné à l’équipe, sans membre ». Quand un cycle n’a aucune capacité, la charge est affichée sans pourcentage et un message invite à définir la composition.

Pourquoi C’est Important

Le système de capacité est ce qui sépare la planification des vœux pieux.

Sans lui, vous découvrez le problème à la fin du sprint quand la moitié des tickets sont encore ouverts. Avec lui, vous voyez le problème pendant la planification et pouvez prendre une vraie décision : réduire le périmètre, ajouter de la capacité ou prolonger le délai. Le choix est explicite plutôt que découvert sous pression.

Gestion de la Capacité