MyProjectStuff
Treizième épisode du roman fil rouge du livre Kanban pour l’IT.
Dans le dernier épisode, l’équipe Aldébaran a analysé les diagrammes de flux cumulés du sprint 3 lors de la rétrospective.
Le dernier sprint de la version 4.0 est en cours. Ayant maintenant un peu plus de recul sur le Kanban, Sophie songe à l’étape suivante de réunification des deux équipes. C’est la vraie cible qu’elle souhaite mettre en place au démarrage de la prochaine version. Elle propose une réunion de travail avec Charles et Pauline.
Harmoniser le référentiel de travail
La première étape est d’harmoniser le référentiel d’éléments de travail : cas d’utilisation d’un côté et story de l’autre. Il est décidé de conserver les cas d’utilisation comme support des éléments Standard. Ainsi que la classification par taille d’éléments Complexe/Moyen/Simple. L’équipe Aldébaran s’adaptera facilement.
Les anomalies bloquantes sont traitées comme des Urgences. Les anomalies majeures et mineures sont traitées avec la classe Standard. Pour finir, les stories techniques sont classées comme Intangibles.
Classes de services de MyProjectStuff
Allocation de capacité par classe
Ils conviennent ensemble d’une allocation de l’effort par classe. Compte tenu des sprints précédents de l’équipe Aldébaran et de la dernière version de l’équipe Véga, la répartition suivante semble réaliste : 80% de l’effort dédié aux cas d’utilisation et 20% dédié aux tâches techniques. Les urgences sont traitées lorsqu’elles arrivent et sont limitées à une.
Pour l’équipe Aldébaran, cela représenterait 13 cas et 2 intangibles par sprint :
MyProjectStuff : Allocation de la capacité par classe de service pour l’équipe Aldébaran
Avec ce mécanisme, Pauline est maintenant d’accord pour que l’équipe puisse gérer son propre backlog technique.
Sophie et Charles continuent leurs réflexions pour pouvoir réunifier les deux équipes en une seule capable d’intervenir sur les deux projets.
Organisation par couloir
Leur idée est d’avoir un couloir par projet. Au démarrage chaque équipe continuera de travailler sur son propre projet. Mais chacun sera libre de fourmiller en dehors par du binômage, pour monter en compétence sur le domaine technique et fonctionnel des autres.
Sophie et Charles savent bien que le dispositif n’est pas suffisant. En complément, ils pensent proposer un turn-over hebdomadaire d’une personne par couloir. A terme, ils espèrent ainsi avoir une équipe généraliste intervenant sur les deux projets.
Les couloirs par produit pour MyProjectStuff
Mais parce que le métier a besoin d’avoir un point de contact stable et le support a besoin d’une expertise, Sophie et Charles pensent garder des points de contact par produit : un team leader et un développeur expérimenté.
Pour commencer Charles sera le point de contact sur MyWaterFallStuff et Sophie celui de MyAgileStuff. Mais pour minimiser les risques de spécialisation, les points de contact vont également tourner au rythme des versions. Des généralistes passeront spécialistes et des spécialistes deviendront généralistes.
Le troisième couloir est dédié au support car son processus est différent de celui des deux autres. Une personne y est affectée pour une semaine. Ils reprennent le principe mis en place par l’équipe Véga qui a fait ses preuves.
Dans le prochain épisode, une réunion a lieu avec le marketing pour finaliser la réorganisation: cadence, granularité et date fixe sont à l’agenda.
