Introduction
Cette première partie est consacrée aux retours sur la configuration des Workflows JIRA en agilité à large échelle (
Less.works). La 2ème proposera une approche novatrice d'analyse des Burndowns avec une proposition de Burndowns améliorés.
Workflows de développement
Il y a plusieurs écoles en ce qui concerne les Workflows de développement en Agilité/Scrum et les outils tels que JIRA Cloud supportent très bien la customisation et le choix des équipes.
Certaines personnes sont favorables aux
workflows les plus ouverts possibles, Todo, Active, Done avec l'ensemble des transitions possibles entre ces 3 états de base. Cela est certainement très intéressant dans une équipe d'experts dans une Startup, se connaissant bien, maîtrisant parfaitement l'agilité.
 |
| Workflow Agile "Ouvert" |
Déployant l'
agilité à une échelle plus large qu'une Feature Team, il nous paraissait intéressant d'avoir un processus bien huilé pour que chaque étape du cycle de vie de la User Story soit bien décomposée et que les
responsabilités soient clairement identifiées à chaque étape dans ce
processus collaboratif.
Sachant qu'un développeur réalise entre 3 à 4 User stories par sprint, cela fait au maximum 30 clics liés au respect du workflow, mais avec un avantage, celui de la scalabilité, notamment pour tous les nouveaux qui nous rejoignent (30 personnes en 1 an), pour ne rien oublier, ce qui au global fait gagner du temps à tout le monde.
Voyons dans cet article l'implémentation que nous avons choisi de faire et le feedback correspondant après plusieurs semestres d'utilisation :
