Afterwork Communauté SQL Server – Agilité décisionnelle

Le GUSS, Groupe des Utilisateurs SQL Server, organise un afterwork le 17 avril à 19h00 dans le 15ème à Paris.

Ce sera l’occasion de discuter de manière informelle sur les méthodes de gestions de projet et la philosophie agile, et l’outillage (ou absence d’outillage) qui va avec dans le monde SQL Server et Microsoft (tant côté ALM qu’outils de dév).

Ou juste boire une bière 😉

17 avril – 19h00
Charly-Birdy
1 place Etienne Pernet, Paris 15ème
Métro Commerce

Décisionnel Agile : Réaliser son Datawarehouse en itérations agiles

Ça y est, vous avez bien intégré les valeurs de l’Agilité et vous vous êtes décidés pour construire votre datawarehouse en utilisant une méthode Agile. Excellent !

Déjà vous allez devoir convaincre les gens autour de vous que c’est possible. En effet la réaction naturelle dès qu’on parle de construire une solution décisionnelle en mode Agile c’est l’incrédulité. Autant pour la partie reporting personne ne voit vraiment de problème, souvent c’est même le contraire, autant côté back end – l’ETL et le datawarehouse à proprement parler – les reproches fusent :

  • Les alimentations sont lourdes et compliquées, on ne peut pas les réaliser rapidement
  • L’entrepôt est monolithique, vu les volumes on ne pourra pas le faire évoluer facilement

Pourtant, dès 1998 Kimball (notre père à tous 😉 ) publie les 3 concepts de base (PDF) du cycle de vie du datawarehouse :

  1. Mettre l’accent sur l’ajout de valeur métier pour toute l’entreprise
  2. Délivrer les données à travers les dimensions
  3. Développer une solution de façon itérative, livrer des incréments compréhensibles, plutôt que de travailler en mode big bang.

Vous avez vu la 3 ? Et la 1 ? Quel talent ce Ralph, en 1998 il faisait déjà de l’Agilité 🙂

Si le pape du datawarehousing dit qu’il faut le faire – notez qu’il ne dit pas qu’on devrait le faire, mais qu’il faut le faire – c’est bien que c’est faisable non ! Le tout c’est de savoir comment.

Dilbert.com

Là encore on écoute Monsieur Kimball, qui applique parfaitement l’Agilité et qui nous donne le mantra du découpage (Slide 19) : « Meaningful but Manageable » – « Porteur de sens mais Gérable ».

Point de vue implémentation l’objectif devient d’identifier la plus petite fonctionnalité qu’on puisse livrer à l’utilisateur qui porte encore du sens par rapport à ses besoins. Si on suit la méthodologie Kimball, cela veut dire qu’on va se concentrer sur un seul processus métier à livrer à chaque fois. Autrement dit, une seule table de fait (ou une poignée de tables) et les quelques dimensions qui lui vont bien. Soit on livre ces tables et on les rend accessibles en SQL, donc exploitable par l’utilisateur, soit on les accompagne d’un petit rapport SSRS ou un petit cube SSAS tout simple généré en une demi-journée. Là on a une itération courte et qui apporte de la valeur.

Oui mais même une table de fait et 4 dimensions ça peut prendre bien plus que 2 semaines à fabriquer, recetter et livrer ! Si on a des problèmes de qualité de données, si on fait du multi-source…

Ok. Alors on va se concentrer sur une seule source de données (une seule instance, un seul applicatif source…), sur un seul périmètre de données dans une même source (la France parmi le monde…), pour réduire le périmètre métier de la fonctionnalité, tout en maintenant son intérêt pour l’utilisateur, jusqu’à obtenir quelque chose d’unitaire et de livrable.

Par exemple, dans le cas d’une solution décisionnelle RH, on commencerait par importer uniquement les données actuelles, sans reprise d’historique. On récupèrerait uniquement les effectifs, uniquement d’une source choisie et d’une seule instance de cette source. On ne ferait de la qualité de données que de bas niveau (unicité, validation des types…) en rejettant tout ce qui n’est pas conforme. On ne ferait que peu de transcodage (uniformisation des critères type sexe, situation familiale…). Et on arriverait à générer un premier rapport simple mais précis sur la situation actuelle des effectifs sur ce premier périmètre. A partir de là on pourra itérer pour améliorer la couverture et/ou la qualité de la solution, en fonction des priorités arbitrées par l’utilisateur. Parfait ! 😉

Ce qui est important, c’est qu’il faut découper son projet selon l’axe métier, le périmètre fonctionnel, et pas selon l’axe technologique. Il faut faire du bout en bout (de l’ETL au reporting) en traitant un sujet simple, plutôt que de faire tout l’ETL, avant de passer à une autre brique :

Découper son datawarehouse en itération agiles

Il faut penser ses fonctionnalités comme les vertes, et pas comme les rouges!

Au départ cela peut paraître difficile, voir même contre-productif. Et ça le sera d’ailleurs certainement au début. Mais cela mène à une plus grande expertise, une plus grande maîtrise de la solution de bout en bout et à une bien meilleure satisfaction client. En 2 semaines on va pouvoir lui générer un premier rapport qu’il pourra effectivement employer pour améliorer son quotidien.

Evidemment il existe des cas particuliers. Si vous êtes à fond dans la qualité de données, on peut considérer qu’une table de transcodage propre, avec une petite interface d’administration en ASP.NET, c’est une fonctionnalité qui a de la valeur pour l’utilisateur. Dans ce cas on n’est pas obligé d’aller jusqu’au modèle dimensionnel pour avoir de la valeur.

Et une fois que votre datawarehouse sera monté et stable, vous pourrez faire des itérations facilement au niveau de SSAS, SSRS ou tout autre outil de haut niveau, là on retombe sur quelque chose de plus facile à gérer.

Un conseil important au niveau de l’ETL : perdez le réflexe de vouloir importer tous les champs de tous les fichiers ou tables sources. Il faut savoir minimiser la largeur (le nombre de colonnes) à importer après la collecte (Extract d’ETL) dans le phase de nettoyage/transformation (Transform d’ETL). Chaque colonne a un coup de maintenance, que vous l’utilisiez ou pas, elle a un impact sur les performances (largeur du buffer), sur la maintenabilité (les bugs qu’elle peut générer) et dans l’évolutivité (lourdeur des métadonnées à mettre à jour). Il faut savoir rester lean de bout en bout, même si nos instincts d’écureuils de la forêt nous encouragent à stocker toutes les noisettes qu’on peut trouver !

Une noisette pour les diriger toutes!

Si vous voulez stocker ces informations parce qu’elles sont périssables, utilisez ce type d’architecture comportant une base d’archivage des données au format source. Vous pourrez l’utiliser si besoin de reprise d’historique :

Archivage des données périssables

Enfin, tout cycle de développement Agile commence par une phase d’initialisation : rencontre des intervenants, découverte des premiers besoins, installation des produits, prototypage… qui ne sont pas à proprement parler des itérations. C’est normal, pas d’inquiétudes à avoir, la transition vers les itérations se fera naturellement quand on vous demandera la première date de livraison 🙂

Voilà, on a fait le tour de l’itération décisionnelle, n’hésitez pas à poser vos questions dans les commentaires. Mais notez tout de même que cela ne suffit pas pour avoir un vrai décisionnel Agile. La brique essentielle qu’il manque encore c’est le cycle d’amélioration continu, tant au niveau de l’équipe que du datawarehouse. Ça c’est un sujet pour un autre jour 😉

Gestion de projet décisionnel – Les valeurs de l’Agilité

La semaine dernière nous avons parlé choix de méthodologie projet pour un projet décisionnel. L’objectif était de déterminer un critère simple pour trancher entre développement itératif (méthodes agiles) et cycle en V (vive les spécifications). Pour ceux qui ne lisent pas les commentaires, un expert de l’agilité est venu apporter des précisions importantes (avec une forme désagréable certes, mais sur le fond plein de sagesse), la première étant qu’on ne devait pas partir sur de l’Agilité sans prendre en compte les valeurs. C’est vrai et nous allons commencer par là avant de voir comment cela impacte directement le découpage du Datawarehouse en itération.

Les valeurs de l’Agilité sont inscrites dans le Manifeste Agile – je vous laisse consulter Wikipedia si vous êtes intéressés par l’histoire de la chose. Ce sont en fait quatre relations de valeur qui doivent toujours guider le chef de projet agile :

Valeurs de l'Agilité

Notez bien que ces relations ne sont pas des oppositions, mais des axes de progression. Il faut le lire comme : « Il faut privilégier les individus aux processus ». Si vous entendez un chef de projet agile vous dire qu’il ne fera pas de documentation parce que ce n’est pas Agile, c’est qu’il n’a rien compris à l’histoire.

Pour moi l’Agilité repose vraiment sur ces relations. Ma méthodologie de projet agile (mes processus) n’est vraiment pas exemplaire, c’est un mini-SCRUM improvisé que je ré-invente à chaque projet. Par contre je bosse toujours d’abord sur les anomalies avant les évolutions, ma bonne relation avec le client passe avant l’exécution de toutes les clauses du contrat et j’adore quand un utilisateur propose de nouvelles idées – tant pis si on doit tout casser pour l’implémenter.

Evidemment fonctionner en mode Agile c’est une relation qui marche dans les deux sens. Tous les acteurs doivent jouer le jeu, les utilisateurs c’est évident, mais également l’acheteur par exemple, sans quoi vous risquez de mauvaises surprises en fin de mission (surtout si vous attendez des signatures de PV de livraison en fin de forfait, mais on parlera contractualisation plus tard)…

De ces 4 relations découlent 12 principes, qui donnent les grandes lignes sur comment implémenter l’Agilité. Les plus importantes :

  • Livrer de manière continue des fonctionnalités complètes, utiles et utilisables
  • Développer par itérations courtes (quelques semaines)
  • Etre adepte du changement, privilégier les solutions simples et adaptables
  • Rapprocher utilisateurs et développeurs
  • S’améliorer continuellement

Il existe plusieurs méthodes de gestion de projet Agile, toutes itératives, toutes intégrant des métriques de progression et un framework de processus et documentation pour bien mettre en place une relation Agile avec l’utilisateur, mais je ne suis pas vraiment la bonne personne pour en parler (moi je suis un peu de l’avis de Ted Dziuba ;))

Ce qui est important, c’est que dans le quotidien il ne faut pas oublier les 4 relations de valeur de l’Agilité, dont la première qui dit bien que les interactions avec les individus doivent être priorisées par rapport au processus. Il ne faut donc surtout pas être rigide avec ses processus Agile, ce serait le comble ! La seule exception à cet impératif – et encore, ça se discute – c’est qu’une fois une itération commencée, on essaye de ne pas toucher à son contenu. En effet, comment arriver à livrer quelque chose de valeur si on ne finit jamais rien?

Ok tout ça c’est cool, mais dans la vraie vie je suis en mission, je veux faire du développement itératif mais je ne connais pas encore mon client. Est-ce que je peux faire de l’itératif, du processus Agile, sans les valeurs ? Personnellement j’en doute. Enfin je ne doute pas que ce soit faisable, on peut tout faire, je doute juste que cela finisse bien. Augmenter le rythme du cycle de livraison et la disponibilité face aux demandes de changement, cela augmente la friction avec l’utilisateur. Si on n’encadre pas cette relation avec les boucles de feedback que sont les valeurs Agile, cette friction devient frustration qui dégénère en conflit. Il faut « l’huile » que sont ces valeurs pour que cela puisse fonctionner sur le long terme.

Et puis quand on y pense vraiment, ces valeurs ne sont rien d’autre qu’un gros concentré de bon sens non ?

Maintenant que le contexte est donné on va pouvoir continuer sur comment découper son Datawarehouse en itérations agiles.

Gestion de Projet Décisionnel – Méthodes Agiles ou Cycle en V ?

Après le choix de la technologie, je continue sur la réflexion lancée plus tôt autour du projet décisionnel. Cette fois-ci j’aimerais aborder la question de l’organisation du projet décisionnel, quelle méthodologie choisir, quel mode d’engagement, pour se garantir de réussir son datawarehouse (ou au minimum d’échouer avec élégance).

Avant de commencer, on peut se demander ce qui distingue un projet décisionnel d’un projet informatique classique. La réponse se limite en fait à un seul élément : la dépendance à une ou plusieurs sources de données externes. Cela peut paraître trivial mais c’est fondamental, car cela implique qu’un élément au cœur du projet n’est pas maîtrisé par les intervenants. Comment garantir un résultat, comment se prononcer sur des deadlines, quand un élément critique du projet n’est pas dans le domaine de responsabilité ? C’est la question qui doit rester dans la tête du chef de projet décisionnel quand il va choisir son organisation projet.

Au-delà de cette dépendance externe, il n’existe pas vraiment de différence avec un projet informatique classique. C’est un mythe qui a la peau dure, on aime tous se sentir un peu spéciaux, mais ça reste un mythe. En décisionnel on voit beaucoup les utilisateurs pour le design du reporting ? C’est pareil sur les applications qui disposent d’une interface – soient quasiment toutes. En décisionnel on gère de la complexité métier dans la modélisation ? C’est pareil pour les applications qui gèrent la production des flux métiers. En décisionnel on est déployé en petites équipes ? Ça arrive tout autant côté applicatif. En décisionnel on gère les sujets transverses de l’entreprise, ce qui est très politique ? Même combat au niveau des ERP, des CRM, du MDM… Non vraiment il n’existe pas vraiment d’autre différence.

Pour en revenir au sujet du jour, l’organisation du projet décisionnel, je vais tenter de faire court et organiser la réflexion autour de 3 questions :

  • Méthodes agiles ou Cycle en V… Comment arriver au but ?
  • Faire ou faire faire, faut-il appeler les consultants ?
  • Forfait ou régie, quel type de garantie fournir?

Pour ce premier article nous allons commencer par le choix de la méthode de gestion de projet : Méthodes agiles ou Cycle en V ?

La différence élémentaire entre les 2 vous la connaissez :

  • Les méthodes agiles sont itératives et participatives, on développe des petits morceaux d’application qui apportent de la valeur, qu’on fait valider par l’utilisateur avant de passer aux suivants. C’est l’utilisateur qui pilote au fur et à mesure le développement  à travers le choix des fonctionnalités qu’il souhaite voir développer. Un cycle de développement, une itération, prend 1 à 3 semaines.

Cycle de développement Agile

  • Le cycle en V repose lui sur un développement de bout en bout, c’est donc une délégation totale de la fabrication de l’application jusqu’à la livraison finale (lever de rideau !). Je veux un résultat, peu m’importe la route pour y arriver. Un cycle de développement prend plusieurs mois.Cycle de développement en V

Jusqu’à présent je pensais que cette dichotomie représentait bien l’écart entre les deux philosophies. Pourtant quand on y pense, et si on se concentre sur l’organisation projet et pas les valeurs que véhicule l’Agilité, une itération agile n’est rien d’autre qu’un mini cycle en V non ? On a une mini-spécification – la description de la fonctionnalité attendue – et toutes les phases classiques du cycle en V (conception, réalisation, recette, livraison). La différence entre les 2, encore une fois si on retire les valeurs de l’Agilité de l’équation, ne serait donc qu’un niveau de zoom sur l’échelle temporelle ?

Cette réflexion, et la réponse à cette question, m’est venue suite à la lecture de cet article d’un designer de 37 Signals : le dilemme de la documentation. L’idée principale de ce monsieur c’est que la volonté de créer, de changer, est un flux d’idées qui s’écoule comme une rivière. Si la productivité est suffisante, si la capacité à réaliser les idées est adaptée au volume du flux d’idées, tout va bien, la rivière s’écoule correctement. Par contre si la productivité est insuffisante, un goulet d’étranglement se forme, un lac de stockage apparaît.

Un océan de spécifications!

Deux possibilités existent alors :

  1. Soit on arrive à faire coïncider le volume du flux d’idées et la capacité de production pour retrouver un équilibre,
  2. Soit on stocke les idées sous la forme de documentation, de spécifications, dans l’attente de l’allocation de moyens de production.

Avec les méthodes agiles, on est dans la première possibilité. Le cycle en V correspond à la seconde.

Par rapport à votre projet, la vraie réflexion à avoir est donc : vais-je avoir une adéquation entre le flux de besoin et la capacité de production ?

Autrement dit : Mes utilisateurs sont-ils prêts à participer de manière active et régulière à mon projet ? Avec cette question on retombe sur nos pattes par rapport aux prérequis classiques de l’agilité. Les réponses :

  • Oui, je suis dans le cas 1, je peux faire de l’itération rapide sur le besoin > Méthode Agile
  • Non, je suis dans le cas 2, je vais devoir documenter mon besoin pour ne pas le perdre > Cycle en V

Un argument qui revient souvent en faveur du cycle en V, c’est que les spécifications sont un engagement sur le livrable qui permet de contourner le problème de confiance qu’on peut avoir avec l’exécutant. En effet : ne pas avoir confiance dans les moyens de production contribue au goulet d’étranglement, c’est un frein à l’innovation, le flux des besoins ne s’écoule pas correctement : il faut documenter pour stocker les idées.

J’ai déjà entendu que l’absence de maturité des utilisateurs était un obstacle à l’Agilité. Je ne suis pas d’accord, dans cette situation c’est le flux d’idées qui est contraint. J’aurai donc même tendance à penser l’inverse : un flux de besoin faible nécessitera une faible capacité de production, on pourra donc facilement arriver à une adéquation (solution 1). Par contre l’absence de maturité de l’équipe de développement est définitivement un frein à l’Agilité puisqu’on diminue la capacité de production, on rejoint le problème de confiance (solution 2).

Enfin, des sources de données de faible qualité sont un frein majeur à la capacité de production. Si vous savez que les auteurs des sources sont réactifs : privilégiez l’Agilité, dans tous les autres cas, commencez à spécifier…

D’une manière générale, chaque contrainte de votre projet doit être classée entre « frein à l’innovation » ou « frein à la capacité de production ». En fonction de l’équilibre vous saurez quelle méthode choisir.

Wow, j’écris sans trop regarder et je me rends compte que c’est déjà beaucoup trop long… Je coupe donc cet article ici, il me restera quelques points à traiter sur l’Agilité (les valeurs, comment découper son datawarehouse en fonctionnalités unitaires) et le cycle en V (positionnement MOA vs MOE), et on pourra passer aux questions suivantes :

  • Faire ou faire faire, faut-il appeler les consultants ?
  • Forfait ou régie, quel type de garantie fournir?

En attendant j’espère vous avoir donné une clef de lecture actionnable pour que vous puissiez répondre à la question : Cycle en V ou Méthodes Agiles pour mon projet décisionnel?