Le GUSS, c’est à dire le Groupe des Utilisateurs de SQL Server organisait cette rencontre pour évoquer un sujet qui m’est cher au sein d’une communauté pas franchement reconnue pour son adhésion à l’agilité. Franchement, je ne savais pas à quoi m’attendre !

Déjà un bon point pour le cadre de rencontre convivial, certainement à retenir pour de prochaines Scrum Beer !

Maintenant, arrivons-en au fond. Je ne vais pas laisser trainer le suspens : j’ai passé une excellente soirée !

L’agilité est un sujet jeune dans cette communauté, on n’y trouve pas la touche de suffisance que l’on croise par ici ou le regard blazé que l’on rencontre par là … L’enthousiasme est là, avec l’envie d’avancer , la soif de faire mieux et le questionnement sur ce que l’on fait.

En parlant de questionnement, j’ai été aussi surpris par l’ouverture d’esprit des personnes présentes. J’ai souvent été confronté dans ce milieu à des personnes prisonnières de leur paradigmes, empreintes de dogmes pour ne pas dire de certitudes. Rien de tel ce soir-là.

Il me serait difficile de vous faire un compte-rendu circonstancié des discussions, mais je vais évoquer quelques points qui m’ont marqué. Dans le désordre.

Les limites de l’outillage

On peut aimer les outils qu’on utilise et faire preuve de lucidité à leur égard. La difficulté principale rencontrée par les développeurs BI utilisant Integration Services semble être l’aspect monolithique des solutions SSIS qui rendent inopérants les fonctionnement en branches avec les merges que cela nécessite.

Le second point évoqué est le problème de la resynchronisation des métadonnées qui fonctionne manuellement et nécessite de repasser sur tous les packages. Si on souhaite travailler sur un modèle de manière itérative, on fait face à ce problème très rapidement, et c’est d’autant plus handicapant que le projet est gros…

Le future du BI agile n’est peut-être pas le cube

Travailler sur un cube de manière itérative n’est pas facile. Vraiment. D’abord si on souhaite faire des “sashimi”, on devrait travailler sur un modèle de données évolutif. Or la synchronisation des métadonnées de SSIS est un obstacle à cela.

D’un autre côté, il n’est pas possible de rajouter des dimensions à un cube une fois en production, car cela remet en cause la granularité des faits qui alimentent déjà le cube !

Mes observations et mes réflexions m’amènent à penser que l’avenir du BI et surtout du BI agile réside dans des solutions “sans schémas” adoptées de manière différentes par le monde des bases NoSQL, je pense surtout aux bases orientées colonnes comme Hadoop. Il s’agit là non seulement de la disparition du schéma explicite, mais d’un paradigme différent où la structuration de la données disparait au profit de la capacité à retrouver cette donnée et à la traiter, et souvent de manière scalable. Un aspect prépondérant quand le monde du BI est tiré vers le Big Data.

C’était mieux avant…

Une voix discordante s’est élevée au milieu de ces reflexions agiles.

“Lors d’une itération, on a oublié de décliner des règles métiers sur d’autres tables. Avec un cycle en V, la spécification détaillée aurait pris en compte cela et évité l’erreur.”

Bien sûr l’argument ne tient pas. Notre interlocuteur aurait dû au contraire se féliciter de n’avoir eu à attendre qu’une itération pour corriger un oubli que le cycle en V ne saurait pas plus garantir ! De toute évidence, la contre-argumentation est d’ors et déjà acquise pour nos DBA Agilistes. Que du plaisir !

La difficulté d’un résultat de sprint démontrable

Quand je demande à mes interlocuteurs de m’expliquer leurs découpage en sprint, j’entends un motif recourent : d’abord un sprint de modélisation de base, un ou plusieurs sprints d’alimentation de Sas, puid d’ODS, viennent enfin les sprints de construction de cube puis de présentation !

C’est le moment de prendre mon air horrifié : pourquoi ne pas construire les sprints verticalement, avec une tranche fine allant de la modélisation de la base à la présentation en passant par les différents étages d’alimentation ?

Nous avons donné la réponse plus haut : la difficulté de construire une table de fait dont la granularité se rafinerait au fur et à mesure de l’ajout de dimensions, la pénalité de SSIS aux changements de métadonnées, etc…

Seconde question, donc : mais alors, si vous n’allez pas au bout de la tranche, que démontrez-vous ?

La réponse est bien sûr : ce qu’on peut ! Dans le cas d’un sprint de modélisation, par exemple, ce sera le modèle de données. Sur papier !

Bref, Scrum c’est l’art du possible, mais il y a vraiment matière à progression de ce côté. On en est pas au “vrai Scrum” !

Le poids des cérémonies de Scrum

Autre point évoqué : 2 semaines, c’est court, et en plus il faut ménager du temps pour la démo, la rétro, le planning meeting. Sans compter que ce dernier se trouve souvent pénalisé par la découverte “in situ” des aspects fonctionnels, laissant la portion congrue de la réunion au découpage en tâches et à l’estimation.

Ces problèmes ne sont ni nouveaux, ni spécifiques au BI avec SQL Server. Ce sont des choses que j’ai rencontré avec des équipes de développement Java. De ce côté nous avions amélioré les choses avec quelques pratiques courantes ou non :

• Découpage en 2 (à quelques jours d’interval) du planning meeting : un volet découverte fonctionnel, et après 2 jours pour réflechir et assimiler, un pur planning meeting plus court.
• Des workshops de tests d’acceptance regroupant développeur, PO, client final (quand il est différent) et représentant de l’équipe de test (quand il y en a une).
• Et bien sûr des rétrospectives pour introduire des pratiques, alléger ou faire disparaitre celles qui paraissent inutiles.

En ensuite…

Pas mal d’échanges, l’envie d’aller plus loin … Le GUSS a émis l’idée d’une table ronde, elle me plait bien ! Tout le monde a l’air motivé, donc peut-être d’ici Juin ?