Bonjour,
Je parcours un peu le forum et constate que vous privilégiez la simplicité et les bonnes pratiques agiles, conseillées par les grands guides.
Pour notre part (Je parle au nom d’une équipe de dev) le workflow a été personnalisé grace à 3~4 ans d’itérations sur l’adaptation de la méthode et il ressemble à ça :
* Todo
* Stucked. Cette colonne est la plus sujette à débat. Elle permet de savoir quels sont les équipes / clients / contacts à relancer pour être débloqué sur un sujet. La laisser à In progress nuirait à la lisibilité car certaines taches restent bloquées pour des raisons qui semblent à notre équipe parfaitement rationnelles et maitrisées. Si des taches saturent cette colonne alors le PO et le SM sont là pour veiller à ce que les relances soient faites.
* In progress.
* Waiting for validation.
* In validation.
Ces deux lignes sont là car nous pratiquons la recette croisée. Un dev ne peut merger qu’une tache d’un autre dev. Ce va-et-vient produit par l’audit croisé permanent doit être parfaitement lisible. La fluctuation todo ↔En attente de recette ↔ En cours de recette doit être parfaitement claire sans que les devs n’aient à penser à avertir qu’une tache est disponible pour de la recette ou revient en cours de recette.
* Waiting for delivery. Nous sommes presque en rolling-release mais nous ne pouvons pas nous permettre de délivrer à chaque feature. Nous faisons un lot d’US / de taches, petit si-possible qui lui est livré (environ 3~5 livraisons par sprint de 2 semaines). Pourquoi ne pas mettre ça dans la colonne « In Progress » : Parce que la lecture de cette colonne serait impossible. En trois ou quatre jour il est possible d’avoir bien trop de tache In-progress et c’est pour des raisons techniques d’infra que nous ne pouvons pas livrer en continue. Pourquoi ne pas mettre ça en done ? Car il faut identifier ce qui est livré de ce qui ne lest pas pour préparer des changelog au moment de la livraison
* Done.
Ce workflow « To do → In progress → Done » est pour nous une utopie, a été testé, et ne fonctionne pas chez nous. Pour utiliser IceScrum, nous devrions, j’imagine, utiliser des tricks avec des labels mais cela ne correspondrait pas à notre véritable workflow.
Je crois que c’est entre autre pour cette raison que nous avions migré d’Icescrum à VivifyScrum.
Je vous encourage donc à y songer.
