Les entreprises optent pour une transformation agile adéquate à leurs organisations, et pour répondre à ce choix il faut créer des méthodologies différentes et satisfaisantes aux entreprises. Parmi ces dernières existe la méthod Scrumban que j’ai l’habitude d’utiliser dans mon environnement de travail.
L’objectif de cet article est de présenter le Scrumban et de détailler le mix des deux « Scrum » et « Kanban » d’un point de vue théorique mais également d’un point de vue pratique en me basant sur mon expérience personnelle.
Histoire et définition :
Le Scrumban avait initialement été créé en 2009 pour proposer une méthode de transition de Scrum vers Kanban.
Aujourd’hui, le Scrumban est devenu un Framework agile à part entière ; il permet souvent d’aider les équipes à combler certains soucis rencontrés par les équipes Scrum ou l’appliquer pour optimiser le travail dans l’entreprise. Et son utilisation depuis quelque temps est assez fulgurante
Le Scrumban fonctionne sur une planification basée sur les demandes clients qui sont priorisées au fur et à mesure de l’avancement du projet.
Fonctionnement :
Kanban est une approche visuelle de la gestion de la charge de travail d’une équipe. Avec cette méthodologie, une équipe crée un tableau Scrumban pour afficher visuellement son flux de travail dans des colonnes, telles que “Backlog” “Dev Queue Bucket”, “Active dev” et “Dev Done Bucket ».
La première étape est de créer et ensuite d’affiner les tickets ou les User Story et les intégrer systématiquement dans le backlog.
Ensuite si le ticket est “done” (les critères d’acceptances sont vérifiés), ce dernier passe à la phase suivante « Dev Queue Bucket » (Sceau de file d’attente) pour le développement.
Lorsque les développeurs commencent à travailler sur le ticket ou User Story, ils déplacent le ticket de « Dev Queue Bucket » vers « Active dev ». Si un élément doit reculer, de « Active dev » à « Dev Queue Bucket », l’équipe de développement (ou notamment un responsable) peut déplacer ce ticket vers la colonne « Dev Queue Bucket » suite à différentes raisons (ajustement du ticket, ticket non adéquat avec le fonctionnement du produit, annulation de développement du ticket qui pourrait mettre en péril tout le produit …).
Le tableau de Scrumban permet à tout le monde de visualiser et de mettre à jour rapidement le statut de chaque projet.
Backlog | Liste des US et des tickets. Statu Ticket/Story : A Affiner, Affiner (Non assigné). |
Project x Dev Queue Bucket | Story ou ticket est « done » et requises pour le développement en X durée maximum (Limite de planification à court terme). Statu Ticket/Story : Affiné, A Faire (Non assigné). Note : – Chaque Story/ticket a une priorité et un temps critique pour la priorisation. – Les Story/tickets sont liés à EPIC. Les EPIC ont une planification permettant une priorisation de haut niveau. – La liste de priorité EPIC est définie par projet. – Arbitrage entre les projets lors de la priorisation. |
Active Dev (Kanban Board) | – Story/Tickets sélectionnées (liste des tâches) à développer dans les Jours+N en fonction de la priorité/capacité entre les projets. – Le test est réalisé dans cette phase. Statu Ticket/Story : A faire (Assigné), En Cours, A Tester Note : – Active Dev (Responsable des développeurs, Product Owner et Release manager peuvent définir le « Active Dev ») – La sélection des Story/Ticket est convenue avec les devs. Cela peut être confirmé lors de raffinement du backlog. – La limite WIP est ajustable (max de ticket en fonction de la charge des devs)
|
Project x Dev Done Bucket | Story/Ticket à passer par la phase de test et l’approbation du client jusqu’à la production. Statu Ticket/Story : Testé et prêt pour la production. |
1. Backlog :
Le backlog dans Scrumban ne se différencie pas par rapport aux autres méthodologies agiles, il est constitué principalement des Features (fonctionnalités), Epic et des User Story.
2. Dev Queue Bucket
La Dev Queue Bucket (file d’attente de seau) et une partie du backlog contiennent des tickets ou/et des US affiné par le PO ou autres personnes, ces tickets sont structurés selon les priorités ainsi que la complexité qui est estimée sur l’effort de développement.
Toutes les User Stories dans la Dev Queue Bucket doivent être estimées avant le commencement de dev selon ces critères :
A. Priorité :
La priorisation ou l’ordre d’importance d’un ticket sont déterminés selon différents critères.
Le premier critère de priorisation pour un Product Owner sera toujours la VALEUR ou business value, c’est à-dire le bénéfice que va apporter cette US à la solution.
Priorité | ||
Degré | Impact Ticket/US | Impact Bug |
Très élevé | Fonctionnalité très importante pour le client | Bug bloquant sur la prod |
Elevé | Fonctionnalité importante /indispensable pour l’utilisation | Bug bloquant dans l’environnement de test |
Moyenne | Fonctionnalité importante pour que le système soit utilisable dans de bonnes conditions. | Bug gênante pour le système |
Bas | Fonctionnalité pour faciliter l’expérience des utilisateurs | Bug gênante pour l’utilisateur |
Très bas | Fonctionnalité sans importance ou impact sur le produit | Pas d’impact sur le produit |
B. Temps de criticité :
Le temps de criticité d’un ticket se détermine généralement par le PO. Ce temps définit la durée maximale pour terminer le ticket et l’implémenter sur la prod. Cette valeur peut évoluer lors du développement (Active Dev) par une demande exceptionnelle du client ou les personnes du métier pour différentes raisons (Contraintes techniques, congés …).
Temps de criticité | |
Criticité | Durée pour max l’implémenter |
P1 | Prêt pour 2 semaines ou avant |
P2 | Prêt pour 2 semaines ou 1 mois |
P3 | Prêt pour 1 mois ou 3 mois |
P4 | Prêt pour 3 semaines ou 6 mois |
P5 | Prêt pour 6 mois ou plus |
C. Story point :
Le story point sert à estimer la charge de travail et les ressources à allouer à sa réalisation par jour/homme.
3. Active dev :
Ce sont les tickets et/ou les user stories en cours de développement par l’équipe de développement ou toute autre partie responsable sur le ticket (tâche, tâche technique). Le test fait partie de cette phase et ça vient successivement après le développement.
Les développeurs ou tous les acteurs sur une tâche doivent respecter les deadlines définies dans la précédente phase (Dev Queue Bucket) et s’engagent à fournir le travail selon le contenu de chaque ticket.
4. Dev done Bucket :
Le Dev Done Bucket contient les US et les tickets qui sont prêts pour la production. Ces tickets sont testés et validés par les testeurs ou les personnes du métier dans la précédente phase. Il ne restera qu’à le PO ou le release manager de pousser le développement sur la production.
Le flux du passage du ticket en prod passe en premier par le test « A tester » pour valider que les critères d’acceptations correspondent aux attentes demandées, puis « Testé ». Une fois le test d’acceptation fait, le ticket passe en « Prêt Pour Prod » pour pousser le ticket en Prod. Quand tout cela est aboutit, le statut du ticket passe en « Terminé ».
Conclusion :
La méthodologie Scrumban n’est pas non plus la bonne ou l’approche la plus parfaite pour chaque projet. Il vaut mieux examiner de prêt les avantages et les inconvénients de cette méthode avant de l’ajouter à votre culture d’entreprise. A mon avis, pour être à l’aise dans un environnement agile, chaque membre doit avoir des rôles et des responsabilités définis (Roadmap claire) et surtout un bon « mindset » !
This Domain Is Good！