MyProjectStuff
14ème épisode du roman d’entreprise du livre Kanban pour l’IT.
Dans le dernier épisode MyProjectStuff, c’est bientôt l’heure de la réunification des deux équipe Aldébaran et Véga : entre couloirs, classes de service et allocation de capacité.
Pour finaliser la réorganisation, Sophie, Pauline et Charles préparent leur réunion avec le marketing. Ils tombent d’accord sur le principe de proposer un temps de cycle d’un mois pour les cas d’utilisation.
Pour l’équipe Aldébaran cela représente deux sprints : un premier sprint pour le mûrissement dans le backlog et un second sprint pour la réalisation.
Pour l’équipe Véga, les résultats ramenés aux cas d’utilisation donnent une moyenne de 16 jours de délais avec une dispersion de 5 jours. En excluant les cas complexes, l’équipe peut se caler en confiance sur la cadence d’Aldébaran. Surtout qu’une réserve de capacité est allouée à la correction d’anomalies et au support. Ce point bloquait le passage de Véga à Scrum initialement.
La capacité des deux équipes réunies est d’une vingtaine de cas par mois. Cela représente à peu près 5 features, ce qui est cohérent avec les limites du tableau kanban du marketing. Ces informations sont suffisantes pour aller voir Marc.
Charles prend la parole :
– « Marc, il y a quelques mois, tu as remonté le besoin d’avoir une livraison mensuelle. C’est ce qui a déclenché tous ces changements d’organisation. Nous pouvons te proposer aujourd’hui de livrer tous les mois cinq features, soit une vingtaine de cas d’utilisation. La planification des cas est revue toutes les deux semaines. »
– « Merci, c’est une bonne nouvelle ! ça répond à mon attente. » répond Marc agréablement surpris. « Une question tout de même avant de fêter ça : lors de la séance de planification en milieu de mois, les cas que je choisis seront bien livrés en production deux semaines après ? »
– « Les features sont définies pour le mois. » répond Pauline. « Les cas d’utilisation peuvent être revus en partie pendant le mois lors de la séance de planification, si c’est possible. Mais nous étions d’accord sur le principe qu’une feature qui rentre est effectivement réalisée. »
– « Je comprends et je ne reviens pas là-dessus. Si j’ai demandé à avoir une livraison mensuelle, c’est parce que je ne sais pas toujours un mois à l’avance ce qui doit être fait. Pour l’essentiel des demandes c’est le cas. Mais comment je gère les demandes urgentes pour une conférence ou un salon ? Je rencontre des prospects qui me font des demandes au dernier moment, tu le sais bien Sophie. » répond Marc.
– « Cela arrive combien de fois par an ? » demande Charles.
– « 2 à 3 fois par an, surtout au printemps et à l’automne. » répond Marc.
Après concertation, ils proposent à Marc deux demandes à Date Fixe à la fois, si elles ne sont pas complexes, à réaliser dans le mois et si l’équipe est prévenue au moins dix jours à l’avance.
L’allocation de la capacité par classe est maintenant consolidée :
- 74% pour les standards.
- 16% pour les intangibles.
- 8% pour les dates fixes. Et s’il n’y a pas de date fixe, la capacité est reportée sur les standards.
Ces derniers échanges ont également montré que finalement, les cas d’utilisation pouvaient être répartis en deux sous-classes : complexe et pas complexe. Charles rappelle qu’au départ, les cas d’utilisation étaient utilisés uniquement pour les cas complexes. Cela va simplifier un peu plus le système et les estimations.
Timeline de MyProjectStuff
Dans le prochain et avant-dernier épisode, un débriefing de la réunification aura lieu. Il sera temps de découvrir le nouveau nom de la nouvelle équipe.
