Cette intervention enregistrée en 2009. Elle reprend le propos développé par Jim Coplien et Gertrud Bjornvig dans leur livre : Lean Architecture.
Sans être révolutionnaire, il y a quelques idées intéressantes. Mais qualifier cette architecture de “lean” est un peu source de confusion pour moi. Bref, en ce qui me concerne, je ne suis pas encore convaincu…
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.
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…
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.
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 !
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” !
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 :
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 ?
Note : 8 ; Simple, puissant et très facile à lire !
A peine un livre, cette nouvelle prose est plutôt un livret de 70 pages. Et encore ! Nombre d’entre elles sont couvertes entièrement ou partiellement de figures pour non-voyants. Alors, comment prendre au sérieux un texte qui, entre nos mains, ressemble d’avantage à une plaquette publicitaire qu’à une prose solide, sérieuse et dense ?
La réponse est simple : il suffit de lire le livre ! Tout d’abord la technique elle-même est non seulement intéressante, elle est en train de devenir un grand classique de la définition des produits. Elle me rappelle en partie la pyramide de Leffingwell, mais projetée dans une réelle pratique agile, et m’évoque également le “start with a why” de Simon Sinek. L’autre aspect est la prose très épurée. On sent que l’auteur, loin d’avoir essayé de noircir du papier, à cherché à épurer sa prose. Au final, on obtient un texte très simple et court. Justement, le contenu, parlons-en !
Il est compose de 3 chapitres. Je les appelleraient “chapitres” même s’ils ne sont pas présents ainsi.
Le premier chapitre “what is an impact map” nous montre ce qu’est une “impact map” et l’illustre avec deux exemples. L’explication est très claire, mais le but de ce chapitre n’est pas d’indiquer comment on procède pour construire cet outil.
Le second chapitre “the role of impact map” fait le lien entre cette pratique et d’autres du monde agile : les user stories, le MVP du Lean Startup, le design thinking (une référence aussi importante que celle des users stories !). Ce chapitre donne de nombreuses références complémentaires, plusieurs à chaque page, en fait !
Enfin le troisième chapitre “creating an impact map” nous propose un processus complet de construction de la map en plusieurs étapes, dispensant de nombreux conseils pratiques au long du chemin. Ce chapitre se termine par différentes catégories d’anti-patterns, qui auraient mérité leur propre chapitre.
Vu la taille de l’ouvrage, celui-ci se lit très, très vite … et c’est tant mieux ! Notre temps est précieux et l’on appréciera l’auteur qui sait être concis et cependant nous livrer de la matière. La dernière page tournée, on pense quand même que l’auteur aurait pu donner un peu plus de corps à son propos. Par exemple, deux études de cas nous faisant vivre la construction de la map auraient donné un aspect plus concret à cette pratique. Je me dis aussi que les chapitres 2 et 3 auraient pu être intervertis avec profit (sauf les anti-patterns). Mais au final, je suis très satisfait par cette lecture.
Il s’agit là d’un investissement de temps extrêmement minime, n’en faites pas l’économie !
Référence complète : Impact Mapping : Making a big impact with software products and projects – Gojko Adzic – Provoking Thoughts Ltd. 2012 – ISBN : 978-0-9556836-4-0
Note : 4 ; L’agilité expliquée aux praticiens du décisionnel
Lorsque j’ai acquis ce livre, j’escompté en savoir plus sur l’adaptation et les spécificités de la mise en œuvre de l’agilité dans le monde du BI. Beaucoup de choses y sont différentes par rapport aux projets de développement : les outils, l’architecture et la cinématiques des applications, l’environnement et la culture. Pourtant, il m’apparaît évident qu’un mode de travail collaboratif et fortement itératif est particulièrement adapté aux projets décisionnels, alors que le mode de travail généralement admis dans le milieu emprunte au « cycle en V » avec sa litanie de phase de spécification, de modélisation et de recettage et sa structuration en MOA / MOE.
En fait, ce n’est pas l’angle du livre. Celui-ci s’adresse au praticien du projet décisionnel, justement celui qui est un habitué du projet mené à l’ancienne. Si, comme moi, vous êtres déjà un habitué des principes et pratiques agiles dans un projet classique mais êtes désireux de connaître comment celles-ci se déclinent dans le monde du BI, ce texte n’est pas pour vous !
Il n’en demeure pas moins que l’auteur connaît son affaire, aussi bien sur le volet agile que sur les projets décisionnels. Pour ce qui est du volet agile, ses deux mentors sont Jim Highsmith et Scott Ambler. J’approuve pour le premier, moins pour le second. Quoi qu’il en soit, ses sources d’inspiration sont très visibles au long de l’ouvrage. Mais il est temps de passer au livre lui-même.
Le texte compte environ 300 pages, divisées en 10 chapitres, eux-mêmes regroupés au sein de 2 parties : Mangement methods (140 pages) et technical methods (le reste).
Toute la première partie, constituée des 5 premiers chapitres, reprend les principes de base de l’agilité. On y trouve peu de matériel qui soit une déclinaison des principes agiles adaptés au monde du décisionnel. Le chapitre 1 qui compte 24 pages est une introduction qui répond à la question du « pourquoi » de l’application d’agile au monde du BI.
Le chapitre 2, long d’une trentaine de pages, traite de gestion de projets agile. Elle reprends pratiquement point pour point, les principes du même noms énoncés par Jim Highsmith dans « agile project management », avec notamment le cycle « envision / explore ». Le lecteur déjà familier avec la prose de Jim Highsmith ne sera pas perdu par le texte. Mais on peut aussi noter que Ken Collier possède bien son sujet et le traite fort bien.
Au chapitre 3 traite de la collaboration, qui n’est pas là non plus un sujet de première fraicheur pour les agilistes, mais les points importants y sont bien traités. J’ai bien aimé le modèle « doers / planners / customers » dans cette partie.
Ce sont les users stories et l’estimation qui forment la matière du chapitre 4. Le sujet n’est plus guère original, pas plus que je n’ai trouvé d’éléments d’adaptation au monde du décisionnel.
Cette première partie se conclut par le chapitre 5 consacré à l’auto-organisation des équipes. Parmi les éléments intéressants, j’ai relevé le « 6 hats of thinking » que j’emploierais à l’occasion pour mes rétrospectives. Le reste est bel et bien du classique. Cette première section me laisse bien sur ma faim, même si j’ai pu en picorer quelques éléments intéressants par ci par là…
La seconde partie est aussi formée de 5 chapitres et s’avère plus prometteuse sur le papier. On commence par le chapitre 6 « evolving excellent design » qui compte quand même 50 pages. L’auteur y expose son modèle d’architecture décisionnelle incrémentale basée sur du message queue. C’est intéressant mais on est hors sujet par rapport au livre ! L’auteur peut être certainement fier de sa réalisation, mais ne peut-on appliquer agile dans le BI que par le biais de cette architecture ?
Le TDD et le Data Warehouse est le sujet du chapitre 7. C’est hélas très abstrait et peut d’élément pour la mise en œuvre. Sauf peut-être une petite astuce technique avec Microsoft SQL Server Integration Services. Ca tombe bien, c’est mon ETL ! Mais comment font les autres ?
Nous arrivons au chapitre 8 qui traite du versionning. Il nous dit qu’il faut versionner (grande nouvelle), en utilisant … Subversion ! Après nous avoir expliqué qu’il faut versionner les sources et non les produits générés (ce que je sais depuis pas loin de 20 ans), eh bien on est arrivé au bout du chapitre !
On se rapproche doucement de la fin : le chapitre 9 traite de l’automatisation, mais là encore si on a un peu d’éléments sur ce qui est une séquence de build typique sur un projet BI, le reste traite d’outils qui ne sont plus de prime jeunesse … comme Ant !
L’ouvrage se termine au chapitre 10 avec des propos plus généraux comme la conduite du changement en milieu décisionnel.
Bref, ce livre m’a déçu, en grande partie parce que je n’étais pas le bon public. Cela se reflète sur la note, mais c’est la règle du jeu. Comme je l’ai dit au début, l’auteur connaît sa matière, ses matières devrais-je dire et il est parfaitement crédible pour traiter le sujet. La prose tend à tirer un peu trop en longueur, ce qui est dit sur 300 pages pourrait l’être sur 220 pages sans nécessiter de sacrifices sur le contenu. Le fil rouge du case study vécu est généralement rafraichissant, mais il est raté ici : les épiques sont trop longues et ne servent pas correctement le sujet.
Faites attention à être la bonne cible avent de débuter cette lecture. Sinon, celle-ci risque d’être frustrante.
Référence complète : Agile Analytics, a value-driven approach to business intelligence and data warehousing – Ken Collier – Addison Wesley / ASD series 2012 – ISBN : 978-0-321-50481-4
Chaque année, la conférence Agile France se déroule sur 2 jours, courant Mai. La conférence “pivote” et s’adresse désormais aux agilistes avancés !
Si vous avez un sujet qui aille dans ce sens, proposez votre session. Je vais certainement le faire…
J’avais évoqué l’arrivée de “Rupture Douce” en août sur Leanpub. C’est finalement sur Lulu que l’ouvrage est rendu disponible : deux éditions papier et une édition eBook (PDF). Des versions ePub et mobi (cette dernière pour le Kindle) sont à venir.
J’ai eu le plaisir de faire la relecture finale de quelques une des histoires comprises dans ce volume. Les éléments se sont un peu ligués contre moi pour que je puisse offrir une aide plus importante.
Une partie des royalties du livre sera versée à “La Courte Echelle Collège”, un projet qui vise à sensibiliser les filles de 3ème aux carrières techniques (dont l’informatique) avant qu’elles aient fait leurs choix d’orientation en les mettant au contact de marraines qui seront des “role model”, femmes ayant réussi dans des métiers traditionnellement plutôt masculins.
Pour ma part, ce sera une version papier, car je compte bien me faire dédicacer l’ouvrage par le “chief editor” et peut-être même par certains contributeurs…
In previous posts I talked about values and principles for fostering a healthy learning organization. In this post I’ll offer some practices. The balance between values, principles and practices is essential for any kind of knowledge work. Values inspire us, principles guide us, and…
Ce sera le 26 Octobre. J’y présenterais mon Lightining Talk “les vertues de l’émergence” , mais cette fois-ci en Anglais.
Cet article publié sur Betacodex traite de l’adéquation des organisations avec la complexité. En voici la version slideshow
Software Freethinker 
