Les BoFs sont un évènement mensuel existant chez OCTO depuis sa création en 1998 mais sur lequel nous communiquons très peu. Devant cette constatation, j'ai pris le taureau par les cornes (ou l'oiseau par les plumes) et vous propose ce premier compte-rendu. Une BoF - pour birds of a feather, oiseaux aux mêmes plumes - est une réunion autour d'un sujet défini : une capitalisation de mission, une initiative personnelle, un débat d'éditeur... Un animateur apporte une partie du savoir et facilite les débats.

Les BoF sont à la fois enregistrées en vidéo et transmises en direct pour les consultants qui ne peuvent pas y assister en direct, mais la meilleure façon d'en profiter est encore d'y assister en direct.

Ce jeudi, j'ai assisté à 5 sessions. Ce que j'en retiens.

BDD avec rspec

Par Rémy-Christophe Schermesser

Nous nous sommes entraînés à écrire des tests BDD très lisibles avec le framework RSpec. La session a pris la forme d'un coding dojo au format randori : dans cet exercice de programmation collective, toute la salle partageait un ordinateur et un vidéoprojecteur, le clavier passant de main en main toutes les 5 minutes. Le niveau dans la salle était très varié, du codeur junior au vieux routard avec des centaines de milliers de lignes de code au compteur, du railer aguerri à la personne écrivant sa première ligne de Ruby. Cette diversité à contribué à la richesse de la discussion.

J'ai été impressionné par la puissance d'une factory_girl par rapport à DbUnit, et par l'expressivité d'un bon test RSpec, qui met l'accent sur le why de l'unité testée et fait passer le how au second plan. J'ai aussi vu des tests immondes, preuve s'il en fallait que l'outil ne rend pas les tests beaux à notre place, il ouvre simplement des possibilités. Au quotidien, je travaille en Java, pas en Ruby. Mes tests unitaires seront toujours un peu plus bruités que ce que j'aurai pu faire aujourd'hui, mais je ressors de cette session avec une envie renouvelée de faire du test limpide qui joue son rôle de documentation.

J'ai également redécouvert que l'abstraction était une arme à double tranchant : elle permet des raisonnements plus puissants à ceux qui se la sont appropriée, mais déroute ceux qui ne la maîtrisent pas encore. RSpec, avec son usage généreux des blocs de code, en a dérouté plus d'un, qui avaient besoin d'imaginer le mécanisme d'exécution derrière la syntaxe pour être confiants.

Le résultat de la session est visible sur GitHub.

Solutions MDM

par Samy Amirou

Je suis un béotien en gestion de données de référence, ou master data management (MDM) comme on dit bien souvent. Cette session m'a donc permis avant tout de comprendre quels besoins entraient dans le champ des solutions de MDM : des besoins d'harmonisation, de gestion de la cohérence, de versionnement et de traçabilité sur des données durables et transverses à l'entreprise.

La mise en place est généralement graduelle. On peut assez vite profiter des premiers bénéfices du MDM, puis progressivement devenir plus intrusif sur les applications du SI pour rendre le système de MDM plus performant et l'enrichir fonctionnellement. Cette mise en place doit aussi s'accompagner d'une vraie conduite du changement pour amener les utilisateurs de produits peu contraignants comme Excel à comprendre et accepter les contraintes d'intégrité amenées par le MDM.

Les nombreux éditeurs de solutions MDM proposent des solutions très variées par leurs philosophies et les vocabulaires employés. On peut grossièrement les ranger dans deux catégories : les solutions spécifiques à un domaine métier et les solutions génériques, plus souples mais moins optimisées. Malgré un marché en constante évolution, les solutions proposées par les éditeurs présentent aujourd'hui certaines faiblesses : fort couplage au modèle des IHMs et des flux des données, personnalisation douloureuse à cheval entre le développement et le paramétrage, schéma de base de données opaque.

Au sortir de la session, je reste un novice en gestion de données de référence, mais je comprends mieux les enjeux de ce type d'approche et les limites des solutions aujourd'hui proposées par les éditeurs.

iPad, BPMN et continuous delivery dans une compagnie aérienne

par Fabrice Robini, Nicolas De Nayer, Boris Charpentier, Wiliam Montaz, Nicolas Colomer

Retour d'expérience sur le projet de dématérialisation de documents et de processus dans une compagnie aérienne française, mené par OCTO du concept initial jusqu'à la réalisation. La même équipe assurait la maintenance du produit déployé, le support utilisateur, le développement des nouvelles fonctionnalités et l'infrastructure. Vous avez dit devops et product team ? Je veux !

Pour faire face à la charge de responsabilités, l'équipe a dû se montrer créative. Elle a automatisé à outrance : par exemple un seul clic suffit pour déployer 4 applications, dont une sur iPad - merci au store Appaloosa et à son plugin Jenkins.

Mais surtout, l'équipe a su se réinventer plusieurs fois pour adapter ses processus aux difficultés rencontrés. Ma trouvaille favorite : le pattern mini-PO. Le product owner (PO) délègue la spécification et le suivi d'un scénario utilisateur à un équipier, qui devient mini-PO sur ce scénario. Le PO reste référent sur la cohérence fonctionnelle globale du soft. Le mini-PO peut développer sur son propre scénario quand c'est pertinent.

L'équipe manquait d'occasions d’interagir avec ses utilisateurs pour mieux comprendre leurs besoins et faciliter l’adoption car leur métier les amène à beaucoup voyager. Qu'à cela ne tienne, l'équipe a répondu en développant une vraie stratégie de marque : un nom, un visuel, un mantra martelés au fil des mails de livraison, des questionnaires de satisfaction... Les utilisateurs ont pris conscience de l’intérêt du projet et ont pris l’habitude d’aller voir l’équipe avec leurs attentes. Cette démarche a tellement bien pris que les utilisateurs se sont mis à coller des stickers sur leurs casiers pour marquer leur adhésion au produit.

REX Socle Mobile

par Cédrick Lunven et Jérôme Van Der Linden

Les auteurs d'une couche intermédiaire dans une pile logicielle sont-ils condamnés à l'obscurité ? Cédric et Jérôme étaient persuadés du contraire quand ils travaillaient sur ce socle mobile, qui fait office d'intermédiaire entre des services métier d'un côté et trois déclinaisons d'une application mobile de l'autre. Et des occasions de se montrer pro et d'apporter de la valeur visible aux responsables métier, ils en ont trouvé plein.

Ils avaient compris qu'étant donnés les délais, la mission ne pourrait réussir que si les points de blocage étaient rapidement détectés et corrigés. Ils ont profité de leur position charnière pour rendre visible sur un kanban board l'avancement des travaux dans les diverses équipes. Il est rapidement devenu clair que les équipes étaient régulièrement bloquées en attente de leurs fournisseurs. L'équipe socle y a remédié en fournissant, à cadence fixée, des bouchons pour les différents composants en cours de développement. Une livraison hebdomadaire sur des environnements hébergés OCTO a permis de réduire le temps de mise en recette de plus de 2 jours à 5 minutes environ.

Le plus grand succès de l'équipe est peut-être d'avoir mis en place un site de démonstration des fonctionnalités du socle mobile. Ce site était tourné à la fois vers les métiers et les développeurs mobile. Aux équipes mobiles, il permettait de tester en direct le fonctionnement du socle pour pouvoir l'intégrer plus facilement à leurs développement. Aux métiers, il permettait de se rendre compte de l'avancement des développements sans avoir à attendre les développements mobiles. La valeur métier ajoutée par le socle devenait évidente, personne ne risquait de le prendre pour un obscur morceau de tuyauterie. Ce dernier point, associé à des notes de livraison soignées et communiquées aux métiers, a permis de mieux impliquer les métiers dans le processus de développement.

Reinventing banking and trading on tablets

Jean-François Grang, Philippe Guicheney, Rémy Virin et Vincent Canuel

Retour d'expérience sur le développement d'une application iPad. Les fonctionnalités, bien que complètes, restent classiques : c'est par une présentation somptueuse et une expérience utilisateur (UX) totalement novatrice qu'elle se démarquera de la concurrence. J'aimerais pouvoir en dire plus mais la discrétion s'impose tant qu'elle n'est pas disponible dans les stores.

Cette session m'a montré la pertinence de l'approche Agile UX : itération rapide sur des prototypes papier, tests utilisateur le plus tôt possible, viser la cohérence des fonctionnalités plutôt que leur exhaustivité, démos internes fréquentes avec les décideurs. Le store Appaloosa a été mis à contribution pour pouvoir rapidement déployer les versions à tester.

J'ai été impressionné par l'application, et très fier du rôle joué par OCTO qui a proposé l'ergonomie, réalisé l'application et accompagné le client sur les tests utilisateur. Une belle victoire partagée avec le client, séduit par la démarche au point de créer un poste d'ergonome en interne et de reconduire les méthodes agiles pour ses prochains projets d'innovation. Et l'application pourra continuer à vivre puisqu'un développeur interne s'est formé auprès de l'équipe OCTO pour prendre la relève.

La prochaine fois

Pour les sessions de novembre, nous devrions avoir entre autres un guide du power user sous windows 8, un cas client d'analytics big data et un état de l'art du décisionnel big data. Voilà un bien bel oiseau qui s'annonce.