Jira pas !

Pas de bugtracker si on a un backlog.

J'ai expliqué il y a quelque temps le processus de gestion des bugs pour le projet IceScrum. Les utilisateurs peuvent déposer des bugs et des demandes d'évolution dans un bugtracker,Jira. Cela avait été mis en place lorsque le backlog du projet était géré avec GoogleDocs. Depuis quelques mois, nous utilisons IceScrum pour le projet. Pour l'instant nous avons conservé le Jira, pour collecter les demandes et garder une trace.

Je viens de passer du temps à essayer de mettre à jour le Jira pour indiquer ce qui est pris en compte dans la nouvelle version IceScrum. C'est la galère ! C'est vraiment du gaspillage d'avoir un bugtracker sur un petit projet, lorsqu'on a un outil comme IceScrum, qui dispose d'un backlog sophistiqué et permet d'identifier les bugs (défauts) parmi les éléments du backlog.

Je vais proposer de ce pas à l'équipe d'abandonner le Jira pour passer à une pratique plus simple.

Commentaires

1. Le lundi 04 mai 2009, 08:41 par David

Bien dit ! Jira pas non plus !

2. Le lundi 04 mai 2009, 11:18 par David Andriana

Pourquoi ne pas faire alimenter automatiquement Jira par IceScrum ? Jira a de nombreuses fonctionnalités bien utiles, ce serait dommage de se les fermer.
En revanche ne pas perdre de temps à faire de la double saisie, ça, oui.

Importer, c'est intéressant une fois quand on a un passif. Non, je pense vraiment qu'un bugtracker est néfaste à une bonne application de Scrum : les fonctionnalités sont peut-être très bien pour suivre des bugs, mais pas pour appliquer Scrum.
3. Le lundi 04 mai 2009, 13:44 par Freddy Mallet

Claude, de manière générale j'apprécie tes prises de position sur ce blog car elles sont souvent empreintes d'une très bonne connaissance de la réalité des entreprises. Sur ce coup, je dois avouer que ton "Jira pas" me surprend énormément, tout comme le fait d'ailleurs de considérer Jira comme un simple outil de bugtracking. J'interviens chez plusieurs clients qui font un usage massif de Jira et je doute sérieusement (mais sans le connaître) que Ice Scrum puisse tout simplement remplacer Jira. Quid de la gestion multi-projets (dashboard consolidé), des pièces attachées, des fils de discussions, de la gestion des droits d'accès, de la puissance des mécanismes de requêtage (même si perfectible), ... A noter que je ne gagne rien à défendre Jira ;-). Aurais-tu cédé à la tentation du raccourcis trop rapide ?

Bonsoir Freddy. Tiens on commence à utiliser Sonar pour le code d'IceScrum (qui n'a pas la prétention de remplacer quoi que ce soit et n'est qu'un modeste outil Open Source). Je reconnais que j'ai cédé à la tentation pour le titre (le titre, c'est souvent le plus dur dans le billet) et que je ne connais pas bien Jira. Je vais me relire mais j'avais l'intention de parler de mon expérience, dans mon contexte à moi. Le propos plus général dans le cadre de l'agilité, c'est que s'il y a des bugs ils vont dans le backlog et qu'il faut les éliminer vite plutôt que les stocker.
4. Le lundi 04 mai 2009, 16:55 par Xavier

Bonjour,
Je rejoins Freddy (jettez un oeil sur Sonar http://sonar.codehaus.org !!!) sur son analyse.

C'est comme cela que GreenHopper a vu le jour.

5. Le lundi 04 mai 2009, 23:33 par Freddy Mallet

Entièrement d'accord avec toi Claude sur le fait que les bugs doivent rejoindre le backlog et qu'il faut les éliminer le plus tôt possible (tout comme d'ailleurs le paiement de la dette technique mais dans une moindre mesure ;-)). Si l'objectif du "Jira pas" était d'éveiller la curiosité alors c'est un très bon titre. Je persiste à penser que c'est tout de même une fausse note au regard du niveau général d'excellence de ton blog.

6. Le mardi 05 mai 2009, 09:28 par ervin

Comme Freddy et Xavier je m'étonne de cette prise de position. Toutefois j'ai une vision moins "jira centrée" de la question. Suivant le contexte du projet un bugtracker (quel qu'il soit) peut-être nécessaire voir même vital.

En effet, dans le cas d'un projet avec une base d'utilisateurs large, il est nécessaire de permettre à ces utilisateurs d'avoir un canal de communication pour faire leurs retours (la plupart du temps sous forme de rapports de bugs). Et afin de protéger les développeurs du flot incessant de requêtes il faut isoler les fonctions supports et développement... chaque requête ne peut plus directement entrer dans le backlog car elle nécessite vérification (s'agit il réellement d'un bug, ou d'un problème de déploiement, etc. se pose aussi la question des rapports en doublon).

Les outils de bugtrackers sont bien plus à même de faciliter cette fonction de support qu'un outil de planification agile. Bien entendu c'est d'autant mieux de pouvoir les coupler avec des outils de planification agile (ce qui est le cas de l'intégration Jira/GreenHopper). J'espère d'ailleurs qu'à terme IceScrum aura des fonctionnalités facilitant son interaction avec les bugtrackers les plus populaires.

7. Le jeudi 07 mai 2009, 20:52 par oaz

Je ne connais ni Jira, ni IceScrum mais, sur le principe, je rejoins la position de Claude concernant la place des bugs : dans le backlog et nulle part ailleurs.

Pour ce qui est de la fonction de support qui s'intercale entre les utilisateurs et les développeurs, je ne crois pas qu'un bugtracker soit l'outil adapté (ou alors il faut définir ce que l'on entend par bugtracker).
L'unité de travail d'un support, c'est l'appel client. L'outil adapté, c'est un outil de suivi des appels avec gestionnaire des contacts, historique des échanges, etc.

Un appel débouche parfois sur des résolution des problèmes spécifiques à un utilisateur qui n'ont rien à voir avec le développement.
Un appel peut aussi déboucher sur la découverte d'un bug ou sur une demande d'évolution. Bug ou évolution, les 2 ont leur place dans le backlog. La différence entre les 2 est d'ailleurs parfois assez mince et introduire un bugtracker dans la boucle ne fait que compliquer les choses.

8. Le jeudi 07 mai 2009, 21:23 par ervin

"L'unité de travail d'un support, c'est l'appel client. L'outil adapté, c'est un outil de suivi des appels avec gestionnaire des contacts, historique des échanges, etc."

Ca résume les fonctionnalités offertes par le moindre bugtracker digne de ce nom...