Discussion :

[Babas007]

Bonjour,

Je suis le Scrum Master d'une petite équipe de trois développeurs (dont moi) dans une start-up, et ceci est ma première expérience en tant que tel. Je récupère un projet qui a été développé pendant 1 an et demi par l'ancien Scrum Master. Suite à la passation de pouvoirs, je me suis aperçu qu'il y avait certainement un meilleur moyen de gérer notre équipe. Tout d'abord, nous utilisons principalement:

• Github
• JIRA Agile pour la création/suivi des user stories (bogue + évolutions)
• Wiki: Utilisés par: l'ensemble des développeurs (dont moi je rappelle), pour écrire les analyses avant d'attaquer le dév; par le Product Owner pour écrire ses demandes d'évolution, les bogues identifiés à chaque sprint, idées d'améliorations.

Ce qui me gêne le plus avec ce process, c'est d'avoir deux supports pour le report des bugs: wiki et JIRA. Chaque jour, je me focalise sur la storyboard de JIRA et j'en oublie le wiki sur lequel sont inscrit les bogues relevés à chaque sprint. Pensez-vous, vous aussi, que les bogues devraient être reportés à un seul endroit: JIRA? Merci de faire part de votre expérience et de vos conseils ;-)

[Logan Mauzaize]

JIRA est un tracker et à ce titre il permet :

• un listing complet
• un historique poussé
• Un suivi relativement précis

A mon sens, il doit être utilisé par les développeurs pour mettre à jour leur reporting (status, avancement, RAF, etc.) de manière "atomique". Néanmoins JIRA (et les trackers, en général) sont mauvais pour le reporting globable. Ils ne permettent que d'afficher une vue à l'instant T.
Pour avoir une vue générale à l'instant courant, il existe en général une floppée de plug-ins mais ca reste généralement limité au Burndown chart (ou temps cumulé restant). Si tes fainéants/pas trop doué, les outils les plus avancées doivent te permettre d'estimer une date de fin suivant le RAF cumulé et la force de travail. Pour le suivi au jour le jour c'est parfait mais pour le reste, c'est insuffisant je pense.

En tant que gestionnaire de projet et agiliste, tu te dois d'avoir une vue du passé et des problèmes en cours. JIRA ne t'aidera pas la dessus. Le seul outil que je connaissance, ce sont les follow-up (CR) ; je ne suis pas CP donc j'en connais pas d'autres. J'ai l'habitude d'utiliser Word pour cela mais un Wiki fait aussi parfaitement l'affaire et me semble plus adapté pour effectuer des recherches, des liens, l'écriture collaborative, le partage, etc.

[Pill_S]

Chaque jour, je me focalise sur la storyboard de JIRA et j'en oublie le wiki sur lequel sont inscrit les bogues

???

Pensez-vous, vous aussi, que les bogues devraient être reportés à un seul endroit: JIRA?

bah oui c'est fait pour... wiki sert éventuellement à mettre les release notes, à chaque releases, que l'on extrait de Jira, mais en tout cas pas à faire du bug reporting.

Chaque bug (business ou technique) doit avoir son Jira associé, Wiki c'est de la documentation. Si le business préfère mettre les bugs dans un wiki, alors t'es mal barré... Car faire changer les procédures du business, c'est pô facile...

[ovh]

As-tu essayé Redmine (outil de gestion de tickets) avec le plugin Backlogs pour gérer l'aspect scrum ? A ce moment-là tu peux créer des sprints qui sont un ensemble de tickets = stories, avoir la vue en tâche, tous les tickets non placés dans un sprint sont dans le backlog, etc.

[Logan Mauzaize]

As-tu essayé Redmine (outil de gestion de tickets) avec le plugin Backlogs pour gérer l'aspect scrum ? A ce moment-là tu peux créer des sprints qui sont un ensemble de tickets = stories, avoir la vue en tâche, tous les tickets non placés dans un sprint sont dans le backlog, etc.

JIRA Agile (anciennement GreenHopper) le fait déjà. Il permet même de créer des groupements de stories (EPIC).