Rien n'est figé et tout processus, toute méthode devrait être suffisamment souple (sans sacrifier à ses valeurs) pour prendre en compte son contexte d'application. En bref, il faut être capable d’adapter, de manière raisonnable, toute pratique aux particularités de son environnement.
Pour le projet sur lequel je travaille en ce moment nous avions besoin d'une meilleure méthode de suivi et de partage des tâches. Notre équipe étant hybride, nous nous sommes appuyé sur le Kanban que nous avons saupoudré d'une petite dose de contexte.
Voici ce que cela donne pour nous
Contexte
Un projet eBusiness avec un développement offshore d'une dizaine de personnes utilisant la méthodologie Scrum.
La partie management locale, que nous appellerons équipe PO, gère plusieurs aspects :
- les PO puisqu'il s'agit d'un projet composé de plusieurs sous projets intiment liés;
- des ingénieurs infrastructures pour gérer l'infrastructure locale d'intégration, de pré-production et de production. Ils ne s'occupent pas de l'infrastructure délocalisée;
- des Business Analyst épaulant les PO pour le recueil des besoins, les validations user, la rédaction des user stories etc ...;
- des développeur en charge des tâches sensibles qui ne peuvent pas être réalisées en mode offshore. Ils ne fut pas les confondre avec les développeurs de l'équipe délocalisée;
- des content manager et UX en charge de la définition du design et de la création des objets relatifs à ce design.
Considérons les BA au même niveau que les PO, et nous avons alors 4 canaux qui composent l'équipe PO. Celle-ci est dirigée par une seul manager qui répond d'elle et du projet dans sa globalité face au top management de l'entreprise. C'est en parie pour aider le management direct dans sa gestion de ces tâches, de leurs dépendances et dans leur partage que nous avons "Kanbanisé"
Pourquoi pas le Scrum tout court ?
Notre tâche principale est de faire en sorte que les user stories soient complètes et au statut "Ready" lors du poker planning.
Nous n'avons pas vocation à travailler en suivant les même cycles que l'équipe de dev mais bien à avancer en parallèle et en avance de phase pour qu'eux puissent sereinement enchaîner les sprint.
La pratique
Nous courons après plusieurs but :
- Créer une réelle cohésion entre les différents canaux formant cette équipe;
- Obtenir facilement une bonne visibilité sur les tâches en cours, les tâches à venir et les backlog de ces quatre équipes.
Voici ce à quoi notre Kanban ressemble :
 |
| Kanban |
Quelques explications
 |
| Schéma Kanban |
Notre tableau de suivi est divisé en 4 zones, mais commençons par la fin :
Cette zone correspond est la partie
« Terminé » (Done) et donc aux taches terminées durant la
semaine. Cette zone est vidée au début de chaque semaine et n’a pas de limite.
La règle d’entrée dans cette colonne est le
faite qu’une tâche en cours soit maintenant terminé
Il s’agit de la zone inventoriant les tâches en cours de traitement par une personne de l’équipe.
Cette colonne est divisée horizontalement par individus eux-mêmes organisés par canal même si cette dernière organisation n’est pas clairement affichée.
Pourquoi une telle organisation ? Seuls les membres d'un même canal peuvent se partager la responsabilité des tâches de ce canal. Elles sont donc d’abord organisées par canal. En gros, une tâche appartient aux spécifications ou au design ou aux développements sensibles ou à la gestion des systèmes, mais très rarement à plusieurs en même temps.
Il va sans dire que de la sorte, la gestion visuelle du flux des tâches est grandement facilitée.
Les noms dans cette colonne sont organisés par canal. Cela aide à visualiser aussi les tâches imminentes par canal et donc la masse de travail à faire par branche.
Les règles d’entrées sont :
· Une tâche se trouvant dans le To do next ou hautement prioritaire et non encore commencée
· Pas plus de deux tâches par individus (WIP = 2)
Sauf cas de force majeure, toute tâche entrant dans cette colonne doit en sortir à l’état « terminé ». Cela évite de commencer plein de tâches mais de n’en jamais finir une seule.
To do next (2)
La zone 2 correspondant aux tâches à faire en suite dites « imminentes ». Elles sont placées là car elles correspondent aux nécessités du moment. Cette colonne peut être réorganisée régulièrement.
Si dans l’étape suivante le responsable de la tâche est clairement identifié, il ne l’est pas ici. Par contre, à ce stade on sait déjà clairement s’il s’agit d’une tâche de développement sensible, de spécifications, de design ou de gestion de l’infrastructure. Les individus sont interchangeables dans un même canal donc ici le responsable de la tâche n’est pas encore connu. C’est au passage à la prochaine étape (3) que la personne que l’une des personnes de ce canal recevra la responsabilité de celle-ci.
Si le WIP est de 2 tâches par individus, on ne bloque pas déjà les tâches par personnes pour se laisser la souplesse de les affecter à d’autres. Néanmoins, ce WIP posé par individus permet de limiter le nombre de tâches à venir pour un même canal et donc d’éviter le l’effet entonnoir.
Les règles d’entrées dans cette étape sont :
· La tâche existait dans le backlog du canal et était dans les prochaines à faire selon la timeline
· Urgence non prévue
· Maximum deux tâches imminentes par individus de la colonne In progress
Le backlog (1)
Organisé par activité (système, développement, spécification,design), il se compose donc de 4 grandes zones :
- SYS pour systèmes, là où le responsable systèmes entre leurs tâches pour les différentes infrastructures;
- DEV pour développements, ceux dédiés aux développements sensibles entre leurs tâches (ne pas confondre avec l'équipe offshore);
- DESIGN pour ... bah vous avez deviné, non ? Relatif à toutes les tâches UX;
- SPEC pour les spécifications. Cette zone concerne aussi bien les PO que les BA.
et nous essayons aussi d'organiser les priorités de ces tâches suivant une droite de temps. En gros, les
moins importantes sont sur la gauche dans le backlog et les plus importantes sont sur plus à droite (toujours dans le backlog). Ce n'est qu'une organisation temporaire et estimée.
Aucun commentaire:
Enregistrer un commentaire