Les fonctions d'un outil Scrum

Le groupe de discussion Scrum de Montréal s'interroge sur les outils pour Scrum. Je reprends leur compte-rendu en donnant mon point de vue d'utilisateur, de consultant et aussi de Product Owner d'IceScrum.

- On souhaite tout de même conserver le mode papier

Chaque fois que c'est possible il faut privilégier un tableau des tâches mural pour la gestion des tâches pendant le sprint. Je conseille aux utilisateurs d'IceScrum s'ils sont tous dans le même bureau de préférer les post-it sur le mur au backlog de sprint de l'outil. Mais je pense que ce n'est pas faisable pour le backlog de produit ni pour le reste. Et la double saisie papier outil, c'est du gaspillage.

- l’outil doit s’intégrer à l’existant (bug tracking, suivi roadmap, SVN, …)

L'existant est très variable et c'est difficile de s'intégrer à tout. Pour IceScrum, c'est une préoccupation actuelle, nous avons choisi de faire le suivi de roadmap et le plan de release dans l'outil, nous importons de Jira et nous avons un connecteur Mylyn permettant le couplage à Eclipse.

- l’outil doit contrôler le respect de la méthode en terme des artefacts Scrum

Oui, et c'est là que les outils dédiés à Scrum apportent une valeur ajoutée aux utilisateurs par rapport à un bête tableur.

- il doit aussi permettre le suivi des tâches et montrer les dépendances entre tâches

Les dépendances comme dans un Gantt ? Ca me paraît inutile, sachant que les dépendances sont traitées lors des scrums quotidiens.

- on doit pouvoir le “customiser” (nouveaux champs par exemple, changement de libellés)

Effectivement, et c'est quelque chose qu'IceScrum ne permet pas actuellement (on peut changer les libellés quand même)

- ce doit être un outil collaboratif

C'est la moindre des choses ! Et là aussi, c'est rédhibitoire pour Excel.

- il doit permettre une documentation interne et libre

Je ne vois pas trop ce que signifie interne et libre. IceScrum est très perfectible côté documentation, à l'heure actuelle il permet de produire du pdf en sélectionnant les parties à exporter.

- il doit permettre une recherche rapide en mode “plein texte” sur tous champs

Effectivement, c'est utile, notamment lorsque le backlog comporte plus de 50 éléments. Ca manque dans IceScrum (c'est dans le backlog en bonne position)

- l’outil doit fournir un portail pour le client

Oui, avec accès transparent aux stakeholders au backlog et surtout à tous les graphiques (burndown, burnup, vélocité, parking lot...).

- il doit permettre le suivi des items des retrospectives + “impédiment list” : tracking des impediments et des solutions …

C'est typiquement le genre de choses que je recommande de faire avec des post-it plutôt qu'avec un outil si l'équipe n'est pas distribuée. Dans IceScrum nous avons une liste d'impediments, qui est peu utilisée.

- une gestion des feuilles de temps restants + passées serait bien vu (pas très Scrum mais pratique tout de même)

Arggg, si on passe à Scrum, il faut revoir la façon dont on fait le suivi. Je me suis toujours opposé à ajouter le relevé du temps passé sur les tâches dans IceScrum, malgré de nombreuses demandes.

- l’accès à l’information doit être simple et efficace en fonction du rôle

Oui, les 4 rôles Scrum doivent être pris en compte, mais sans trop contraindre. Dans IceScrum nous avons fait le choix de rôles dynamiques.

- un reporting envoyé par email (programmation des rapports que l’on souhaite) serait bien - une annotation des stories par le PO (fil de discussion RSS des annotations) serait un plus - unjournal de bord des daily meeting (blog) serait un plus

Ce sont de bonnes idées.

- une gestion intégrée avec le QA - tests plan serait un atout

C'est une fonction essentielle si on veut aller un plus loin qu'avec un backlog sous forme de tableau dans lequel les éléments sont décrits en une ligne. Dans IceScrum nous avons ajouté l'association de cas de tests d'acceptation à une story et le suivi des résultats de tests par build, c'est décrit dans ce billet. La prochaine étape est le couplage à des outils de tests d'acceptation.

Commentaires

1. Le lundi 10 août 2009, 15:07 par xavier

Vous dites que la double saisie est du gaspillage, je suis bien d'accord!
Mais plus loin vous dites que l'outil Scrum doit disposer d'une interface web surtout pour les graphiques.
N'est ce pas antagoniste?
Si une équipe utilise le tableau mural, comment peut elle afficher le burndown chart dans son outil Scrum sans double saisie?

2. Le vendredi 28 août 2009, 12:07 par David

Excel rédhibitoire oui.
Mais Google Spreadsheet déjà moins. Et pas mal d'équipes s'en servent avec succès