1erBilanRedmine201001

Merci à François Poulain pour ce 1er bilan (et à tous ceux qui y contribueront par la suite).

Un gestionnaire de tâches, pour quoi faire ?

Dès la création du groupe Animation en fin d'année 2008, utiliser un gestionnaire de tâche s'est imposé comme une réponse à différents problèmes, listés ici : Réflexions_au_sujet_d'un_système_de_gestion_de_tâches. Les fonctionnalités souhaités in fine sont les suivantes :

• Permettre à chacun de parcourir un ensemble de tâches regroupées logiquement, et d'y contribuer.
• Organiser le travail des membres actifs.
• Acquérir une meilleur expérience de l'investissement que requièrent les différents projets.

À cette fin, dès le début 2009 nous avons commencé à recenser les outils dédiés à ça, qui sont listés sur la page sus-citée. Lors d'une réunion à l'occasion de l'AG, notre choix se porte sur Bugzilla, car il offre l'opportunité d'être opérationnel à court terme, et reste un outil assez éprouvé. Ce fut fait au cours du printemps.

Bilan de l'utilisation de Bugzilla

Bugzilla a clairement été sous testé du fait des réactions urticantes qu'il a provoqué chez les non geeks. Certes, c'est un outil du siècle dernier, mais dans le cahier des charges il y a marqué « user friendly ». Un compte rendu de ces activités est disponible ici : http://www.april.org/wws/arc/animation/2009-07/msg00021.html. Voir aussi : Rapport_d'étude_Bugzilla.

Nous n'aurons pas été beaucoup plus loin, faute de tests. Globalement, l'outil est très puissant et très polyvalent. En théorie il est techniquement apte à fournir tous les paramétrages que l'on souhaite... Sauf en termes d'ergonomie. Nous avons tâché d'y travailler, mais le travail dans cette direction n'a pas été loin, essentiellement par manque de disponibilités.

Une des raisons à cela, est que Bugzilla adhère de très près aux besoins de développement logiciel ; et ce n'est pas précisément ce que nous avons besoin (typiquement: présence non optionnelle de champs comme « Plateforme » ou « Version »).

Étude de Flyspray

Un bénévole a étudié les possibilités offertes par flyspray. Un CR très détaillé est disponible ici : Compte_rendu_de_test_de_flyspray. Un test grandeur nature n'a pas été entrepris par manque de main d'oeuvre, mais ça à l'air d'être un outil intéressant, qui vaut le détour, même si l'interface reste un peu root. Flyspray semble lui aussi plutôt dédié à du développement logiciel.

Test de Redmine

Après avoir rassurées les personnes traumatisées par l'interface de Bugzilla, nous avons cherché un outil qui soit avant tout user-friendly, et nous nous sommes tournés vers Redmine. Contrairement à Bugzilla, Redmine est un gestionnaire de projets, mais pas au sens où l'entendra un manager qui gère des ressources de façon centralisée. De même, contrairement aux autres outils, Redmine est pensé pour être plus générique qu'un tracker de bug dédié au logiciel. Disons plutôt que ça ressemble de près à une forge, et contient différents modules : gestion de tâches, wiki, actualités, dépot de code, dépot de fichiers annexes et un forum de discussion. Une instance de test a été initialisée début décembre à l'adresse : https://redmine.april.org.

Les fonctionnalités offertes par Redmine sont énormes, et il y a eu beaucoup de tests de fait, mais assez peu de retour, en somme. Il va falloir clarifier ça. L'adéquation de l'outil par rapport à nos besoin a été plus ou moins passée en revue lors d'une réunion dont le compte rendu est ici : ReunionRedmine20091222 ; je vous invite à vérifier par rapport au premier lien donné en début de mail, et à questionner ce qui vous semble peu clair, incomplet ou manquant.

Un plan de test n'a pas été défini. La politique suivie a été globalement que chacun essaye de faire des trucs, et se plaigne au fur et à mesure qu'il n'y arrive pas, afin qu'on y remédie. C'est un peu le bordel comme tactique, il faut avouer. Si quelqu'un veut proposer un plan de test un peu plus clair, ça ne sera pas une mauvaise chose.

État des lieux de Redmine

Présentation générale

Redmine est un gestionnaire de projets. Il s'architecture donc autour de projets « racines » (qui peuvent aussi contenir des projets) indépendants, et pour chaque projet est instancié :

• Une page d'accueil qui montre une présentation et un aperçu de l'activité (généré automatiquement).
• Une page d'activité, générée automatiquement.
• Une page « Feuille de route », si des versions ont étés définies pour le projet.
• Une page « Demandes » recensant les tâches du projet.
• Une page « Annonces », qui agrège les actualités du projet présentées en page d'accueil.
• Une page « Documents » qui permet de stocker des documents et divers fichiers.
• Un wiki.
• Un forum.
• Un dépot de sources.

L'ensemble des champs textes se remplissent dans un formalisme de wiki, pour une mise en page structurée ; qu'il s'agisse des bugs, des commentaires, des annonces, etc.

Bref, ça fait du monde. Tous ces éléments sont activables projets par projets, par tout personne ayant les permissions suffisantes. Une activation globale est aussi possible. Ça risque d'être le cas du module « wiki », si on ne veut pas qu'il y ait double emploi avec le mediawiki de l'association, ou du module « forum ».

Redmine est par défaut architecturé par rapport à ces projets, mais un accès global à l'information est clairement possible (par exemple : lister toutes les tâches de tous les projets avec tel filtre.). Chaque projet peut donc configurer indépendamment :

• les modules qu'il utilise : wiki, dépot de code, etc.
• les trackers utilisés,
• une gestion locale des permissions, pour chaque utilisateur/groupe,
• une gestion de version (très utile pour les roadmaps),
• les catégories de demande,
• les configurations des modules (wiki, forum, dépot de code, etc.)

Dans ce qui suit je me restreints au gestionnaire de tâche, le reste étant soit assez simple et classique (dépot de source, de fichier), soit un service automatique pour lequel il n'y a pas grand chose à gérer.

Le tracker Redmine

On peut définir de façon globale autant de trackers que l'on souhaite. Chaque tracker est associé à un nom et un workflow différent ; de cette façon, on ne traite pas nécessairement de la même façon les tâches selon leur typologie (par exemple on ne traite pas une anomalie comme un tâche planifiée ou récurrente). Chaque projet peut utiliser les trackers de son choix. Chaque tracker peut recevoir autant d'états différents que l'on souhaite, avec la matrice de passage de notre choix. Donc de ce coté là, la flexibilité est totale. La définition de cette matrice est le workflow. C'est un travail assez complexe : on se retrouve avec différents trackers, chaque tracker dispose d'un nombre élevé d'état (entre 5 et 10) ; et la matrice de passage possède un nombre de configurations possible qui dépend (grossièrement) du carré de ce nombre. De plus, le workflow est à définir pour chaque type d'utilisateur. Un aperçu du wokflow testé est résumé ici : https://redmine.april.org/issues/19.

Lorsqu'une tâche a été instanciée, il est possible de changer le tracker auquel elle est associée.

Par défaut, une tâche possède les attributs suivants :

Statut

c'est ce qui est défini dans le tracker. Typiquement : « fait », « rejeté », « en attente », ...

Priorité

Assigné à

Catégorie

définies indépendamment pour chaque projet ; donne un champ transversal pour trier les tâches.

Version cible

lorsqu'une version est spécifiée, la tâche est utilisée pour déterminer la somme de travail qu'il reste à effectuer avant la sortie de la version.

Début

date de début.

Échéance

si spécifiée, est utilisée pour le calendrier et le Gantt. C'est aussi un moyen de relancer les gens (au moins manuellement).

% Réalisé

niveau d'avancement de la tache.

Temps passé

retient le temps passé, disposé sur des activités.

Ils sont bien sûr optionnels. Il est possible de les personnaliser, et d'ajouter des attributs personnalisé ; nous n'en avons pas encore eu besoin.

De plus, la tâche dispose des champs suivants :

• Description : c'est là que la tâche est initialement décrite.
• Les demandes liées : selon qu'elle soit liée à, qu'elle duplique, précède, ou bloque une autre tâche.
• Les observateurs : personnes en copies des interactions. Typiquement un référent sur le sujet, ou une liste de diffusion.
• Les commentaires : C'est là que l'essentiel de la discussion autour de la tâche est censé avoir lieu. Il est aussi possible de joindre des fichiers dans la discussion.

Points satisfaits par l'utilisation de Redmine

• Rendre visible une liste de tâche, centralisée ou non, définie par des critères précis.
• Proposer un workflow adapté aux besoin des activités des groupes de travail.
• Proposer une estimation du coût d'une tâche (temps à passer).
• Densifier les relations entres les bénévoles.
• Permettre de synthétiser l'activité et ainsi mieux valoriser le travail des bénévoles.
• Accessible par le Web.
• Permet à chacun de s'attribuer une tâche.
• Deux niveaux de hiérarchie des projets disponibles. Illimité à l'avenir (version 0.9).
• Offre des possibilités de projets non publics.
• Permet d'associer des tags ou des catégories à une tâche.
• Permet d'indiquer une durée et une échéance pour la tâche.
• Génère autant de vue que l'on souhaite, sur des critères de recherche.
• Recevoir des notifications par email.
• Possibilité de bilan statistique par projet.

Points à éclaircir concernant le fonctionnement de Redmine

• Héritage des permissions : la manière dont Redmine hérite les permissions n'est pas documentée. À tester, et clarifier en vue de doc (en cours par Rémi).
• Création de sous projets : quelles permissions nécessaires ? Dans le cas où un projet racine représente un groupe de travail ; un animateur de groupe doit disposer de la permission de créer un sous projet, et doit pouvoir déléguer cette permission. La façon de permettre ça n'est pas encore claire (en cours par Rémi).
• Accessibilité de Redmine : des actions semblent n'être accessible que par interface javascript ; par exemple l'édition multiple de bug. Il faudrait recenser quelles fonctionnalités ne sont pas accessibles sans javascript, et remonter le problème aux développeurs Redmine.
• Rappels automatiques (whine) Quid de ceci : http://www.redmine.org/wiki/redmine/PluginWhining ; est-ce maintenu et fonctionnel ?

Points gênants à régler

• Interfaçage avec le SI de l'April :
  • Créations et modifications de tâches par courrier rentrant.
  • Association à l'outil de bénévalo (wishlist).
  • Présenter une page simplifiée à l'extrême, sans avoir à chercher dans les mailing lists, et permettant simplement une auto assignation cochant un bouton du type "Ça m'intéresse !".
  • Authentification Single sign on.
• Séuriser notre déploiement : identifier un ou des développeurs référant qui pourraient nous conseiller ou nous aider, le cas échéant, en développement (ex : correction de bug).
• Remonter/corriger le bug d'affichage des images (#10).

Points bloquants à régler

• Interfaçage avec le SI de l'April :
  • Création des comptes synchronisée à la base d'adhérents.

Comparaison (rapide) entre Redmine et Bugzilla

• RM moins stable que BZ ; projet plus jeune.
• RM plus générique que BZ ; ce dernier est dédié au bugtracking logiciel.
• RM plus décentralisé que BZ ; ce dernier gère les fonctions phares de façon globale.
• RM plus user friendly que BZ ; ce dernier est une "foire à boutons" où l'on peut se perdre. L'incidence sur l'efficacité de l'utilisation de l'outil s'en ressent fortement.
• RM plus fonctionnel que BZ ; aucune fonctionnalité offerte par BZ ne semble innateignable par RM dans ce domaine, et sans effort de dev (sauf éventuellement le whining).
• RM aussi compliqué que BZ à interfacer au sein de l'April ; peut être la difficulté majeure est extérieure à l'outil.
• RM offre plus de fonctionnalités de bugtracking que Redmine ; notamment la possibilité de multiples trackers.
• RM offre plus de fonctionnalités pour suivre l'activité autour des groupes.
• RM est plus centré sur l'utilisateur, avec la possibilité de réaliser un tableau de bord personnalisé en quelques clics.