Organisation et suivi du sprint
Kanban agile en 5 colonnes
À faire (tâches à prendre en début de journée) : Au début du sprint, toutes les tâches sont dans cette colonne.
En cours (tâches en cours de développement) : Elles doivent être terminées le soir (sinon, re-conception ou découpage envisagés)
En revue : Le code doit être approuvé par le référent technique avant de partir en test fonctionnel.
En test : Le code est testé par le chef de projet et/ou par le client.
En production : Le code est déployé pour usage.
Initialisation du sprint
Le product backlog est dépilé et chaque tâche choisie est notée sur un post-it placé dans la colonne 1 "TODO" (le product backlog est géré via l'outil de suivi de développement informatique Redmine)
Clôture du sprint
Normalement les post-it ont tous migré de la gauche (colonne 1 "À faire"), vers la droite (colonne 5 "En prod").
L'état des tâches est mis à jour dans Redmine et les post-it vont à la poubelle.
Flux continu tiré par les besoins du client
Les résultats des développements sont envoyés au fur et à mesure au client et non en fin de sprint (environ une mise en production par jour).
Le client peut changer d'avis en cours de sprint :
Si les changements sont mineurs, le sprint est adapté dynamiquement
Si les changements sont majeurs, le sprint est annulé (et un nouveau est démarré)
Le client est rencontré officiellement à la fin de chaque sprint de trois semaines :
Mais ce n'est pas une étape fondamentale pour lui (il est livré quotidiennement)
Les stakeholders (intéressés au projet) sont invités
Ces réunions servent de point de publicité du projet
Et de synchronisation avec les utilisateurs (détection de dérive du client)
Équipe multi-projets
Étant donné qu'il y a une seule équipe pour plusieurs projets, afin éviter les changements de contexte trop importants, pour chaque sprint :
80% des tâches correspondent à un projet (celui sur lequel on se concentre) ;
20% aux deux autres (pour qu'ils ne soient pas figés).
Le projet principal tourne à chaque sprint.