Eh oui, malgré que le manifeste nous assène que « les hommes sont plus importants que les outils », cela ne nous empêche pas de faire le plein à une soirée exclusivement consacrée aux outils ! D’ailleurs j’en étais, mais je suis arrivé un peu en retard… Essayons de rattraper celui-ci !

Thomas Declercq, ou comment étendre TFS

Thomas est manager chez AXA, à Lille plus exactement. Ici, on utilise les outils Microsoft, donc TFS pour faire du développement en .NET ; rien que de très logique. Les grands comptes sont rarement sur les dernières versions des outils, on vient donc tout juste de passer de TFS 2010 à TFS 2013. Et l’outil montre ses limites pour suivre des métriques. Alors si l’on a pu fort logiquement commencer avec des exports de données puis du bricolage sous Excel, l’équipe a fini par se lasser de ce travail et a envisagé des outils se branchant sur les API de TFS. On parle ici de 3 outils internes.

Outil #1 : Le Kanban board

Il n’est pas beau, il a été développé entre la poire et le fromage, car l’équipe en avait besoin mais personne ne voulait payer pour … et il est très utilisé ! Ils en avaient besoin, car la solution initiale, c’était des extracts CSV de TFS injectés ensuite dans Excel. Un travail à la longue très fastidieux.

Donc, cette application faisant grand usage d’AngularJS s’adosse directement à TFS sans même posséder son propre modèle de données. Elle montre simplement les données de TFS sous forme Kanban (chaque équipe a son Kanban) et permet de calculer les temps de cycle, d’afficher le CFD, etc…

Un outil beaucoup utilisé par les Scrum Masters et les PO (les PO sont à Paris alors que l’équipe est à Lille).

Outil #2 : Project Report

Oui, malgré que l’on soit en mode agile, le management continue à demander des reports comme au bon vieux temps. Là aussi la motivation est de permettre de générer cela en économisant l’énergie à produire ces rapports, car tout comme dans l’outil précédent, les données sont directement issues de TFS.

Pour l’essentiel il s’agit de données agrégées des projets pour permettre d’avoir un indicateur global du projet en un coup d’oeil. Cet appréciation va même jusqu’à l’aspect budgétaire !

Outil #3 : Quality Report

Comme pour le second outil, il s’agit là d’avoir des vues synthétiques d’information. Mais cette fois ce sont des informations sur le code et les builds ! Cet outil semble moins pertinent avec la dernière mouture de TFS, mais son architecture lui permettrait d’être frontal d’autres outils comme Jira, car il est agnostique par rapport au back-end.

Et par rapport aux boards physiques ?

La position prise dépend des équipes. Pour Thomas, la bonne position consiste à utiliser … le board physique autant que possible. Il permet un niveau d’appréhension et de personnalisation que ne permettent pas aujourd’hui les outils électroniques. La plus grande plus-value de ceux-cis se situe à deux niveaux :

• La communication entre équipes distantes.
• La génération automatique d’indicateurs.

Jira Agile, par Basile Le Plessis

Basile est très à l’aise avec Jira Agile, un outil qu’il déploie très régulièrement dans des équipes. A l’origine, cet outil s’appelait Greenhopper. L’outil permet d’accéder à deux types de boards (qui sont en fait des vues vers les tickets Jira) :

• Un board Scrum
• Un board Kanban

Ces deux boards ne présentent pas les mêmes fonctions, et c’est en fait le board Scrum qui est le plus riche des deux. Par défaut l’outil proposera un board avec 4 colonnes qui correspondent à autant d’état du workflow Jira. Mais ces colonnes sont évidemment configurables (3 grands types : A faire, en cours, terminé), chaque colonne pouvant d’ailleurs représenter une conjonction d’états ! La flexibilité de cette configuration a un revers : si on se rate, on peut créer des tickets qui ne sont pas visibles sur le board !

Il est également possible d’ajouter des swimlanes, ainsi qu’un ensemble d’ajouts tels que des « filtres rapides » des couleurs associées à des sous-requêtes, etc…

Tout est configurable dans Jira, c’est sa grande force. Mais cela demande une bonne prise en main, car l’ergonomie tourne souvent au cauchemar sur tout ce volet configuration… D’ailleurs si Jira Agile est le successeur de Greenhopper, l’ergonomie semble estimée en retrait par rapport à la première mouture !

En parlant de configuration, il y a quand même quelques contraintes, entre autre sur l’édition de workflow et la réversibilité des migrations (ok, j’en demande beaucoup).

Par contre, l’outil hérite des capacité d’extensibilité de comportements et de modules de Jira. Il est par exemple possible d’associer des comportements aux transitions d’état. Et les modules Jira sont déjà un écosystème très riche !

Agile Bee, par Laurène Vol

Bee, c’est essentiellement un tableau de bord pour les projets menés en Agile, un tableau de bord à même de montrer un portefeuille de projets et d’en donner une vue uniforme. Pourquoi ?

• Pour le décideur, pour lui donner de la visibilité sur les livraisons en extrapolant le « quand » on livre.
• Pour l’équipe, lui permettre de suivre les indicateurs opérationnels.

De mon point de vue, il semble s’adresser avant tout aux décideurs.

Maintenant, d’un point de vue pratique, comme cela marche-t-il ? Les données doivent être extraites de Jira ou de TFS, etc… en format CSV, puis intégrées dans Bee. C’est assez rustique. La connexion via des APIs devrait arriver dans une version ultérieure. La bête est hébergée sur Heroku, c’est donc avant tout un outil SAS, même s’il peut être déployé chez les clients (avec les difficultés de mise à jour que l’on connait).

L’outil rappelle un peu le « happy board » d’AXA, avec des indicateurs tels que :

• Atterrissage du backlog (via des extrapolations calculées sur 3 itérations).
• Suivi budgétaire on track / off track ; il permet également de déduire le coût moyen des stories. En pratique, ce suivi s’appuie simplement sur le nombre de stories réalisées dans l’itération et le « coût » d’une itération.
• Les Bugs, dont le ratio de bugs et le suivi des bugs ouverts et fermés.
• La Productivité (quand je vous disais que cela intéressait avant tout les managers…). Son suivi se base sur le flux et la cadence et son évolution au fil du temps.
• Feature matrix : une fonctionnalité permettant l’agrégation de stories par MMF.
• Calcul de la prédictibilité, en se basant sur une vision flux.

Le point réellement fort de cet outil est son ergonomie et la qualité de son rendu visuel. Tout est très bien fait jusque dans les moindres détails.

Kantree

C’est l’invité surprise de ce meetup ! Kantree est un  produit est développé par une petite société, le démarrage de ce projet étant surtout guidé par la passion ! L’outil s’inspire profondément de Trello, l’ergonomie respire de cette inspiration (si je puis dire). La grande différence est que Kantree permet une gestion de boards multi-niveaux : chaque carte peut elle-même devenir un board ! Chaque niveau de board peut par ailleurs avoir son propre workflow.

Au-delà des boards multi-niveaux, l’équipe travaille activement à des fonctions se différenciant de Trello : association d’une date à une tâche, synchronisation avec Github et personnalisation des attributs.

Cette sympathique équipe investit beaucoup sur le développement de cet outil dans le but de développer une activité d’éditeur autour. Cela me laisse dubitatif, car même s’il présente des particularités intéressantes, le marché est déjà bien occupé par des éditeurs avec une forte présence. De plus ce type d’outil est exposé à terme à une « comoditisation » et est destiné à perdre de la valeur. Du moins à mon avis.

Autour d’un verre

L’agenda de la soirée était plutôt riche et chargé, un style auquel le FKUG commence à être coutumier. Il est maintenant temps de tailler dans le saucisson et la canette de bière. J’en profite pour échanger avec Thomas Declercq à propos de la question « tableau physique versus tableau électronique ».

Thomas est un fervent du tableau physique : il permet une vue globale, d’embrasser l’ensemble du projet ou de se focaliser sur un point en particulier. On peut adapter l’affichage contextuellement pour attirer l’attention sur des points particuliers, etc. Le tout avec une souplesse que ne permettent pas les boards électroniques. Mais les boards électroniques sont pratiquement indispensables pour des équipes géographiquement dispersées et permettent la tenue à jour d’indicateurs, chose trop pénible en mode manuel. Des points de vue envers lesquels j’abonde.