Le retour des spécifications dans un projet décisionnel lean

Au risque de me faire encore conspuer par nos camarades agilistes militants, je vais vous raconter comment j’ai contribué à la sortie d’un des projets auxquels je participe du mode Agile/Lean. Car oui, je l’avoue, j’ai fait du lobbying pour le retour du cycle en V…

Tout commence par un projet de migration Cognos vers SQL Server, avec une petite équipe de développeurs experts et un client qui fait confiance. Aucun frein à la productivité, les résultats sont immédiats et visibles à travers les premiers états livrés après seulement quelques semaines de travail. Point de vue gestion de projet, l’équipe fonctionne alors en mode cowboy, juste quelques todo lists priorisées, une réunion de suivi hebdomadaire, et tout le monde est bien content.

Les choses s’accélèrent, la migration avance à bon rythme, et le succès rencontré par la production des premiers rapports déclenche la demande de nouveaux rapports. Le client trouve sa place en tant qu’évangéliste de la solution, il identifie des utilisateurs potentiels, vend sa solution en interne et génère encore plus de besoins.

On avance de 6 mois, et… la migration n’est toujours pas terminée. En effet la recette des rapports est décalée en permanence car chaque revue déclenche une flopée d’évolutions. Les nouvelles demandes s’entassent et parfois même disparaissent puisqu’elles ne sont pas suivie d’une manière centralisée (pas de réel backlog) et que la priorité est attribuée aux derniers utilisateurs venus se plaindre dans l’open-space. Il n’y a ni planning, ni suivi du consommé, ni documentation, et même l’architecture technique commence à en souffrir (effet de bord d’une autre décision qui n’est pas le sujet du jour).

Le problème est identifié et c’est à ce moment-là que je rentre en scène. Ma mission est évidemment de remettre de l’ordre dans tout ça. Je reprends donc la longue liste des demandes, je clarifie les items, génère un backlog unique et accroche au mur un beau Kanban tout neuf.

 Dilbert - Méthodes Agiles

Pourquoi un Kanban ?

  • L’équipe fonctionne en livraison continue, sans itération, point positif à conserver
  • On lui reproche un manque de visibilité sur son activité en cours, il faut y remédier
  • Les priorités changent tous les 2 jours, il faut pouvoir s’adapter
  • L’équipe travaille sur trop de sujets à la fois, il faut rationnaliser

On est donc dans le cadre d’application idéal pour cette technique.

Et hasard des réorganisations, c’est justement le moment où un des utilisateurs principaux de la solution, directement en provenance du métier, passe officiellement business owner à temps plein.

S’en suivent 2 mois plutôt positifs, où une fois les process mis en place, le business owner et les utilisateurs constatent une amélioration du delivery en terme de rythme, de réactivité et de visibilité sur l’activité (par ce que oui, un développeur qui ne fait pas de réunion et qui n’envoie pas de mail c’est bien un développeur qui travaille, et pas le contraire). Le reproche éternel de la capacité à s’engager sur des dates est évidemment toujours dans l’air, mais on atteint une visibilité à 3/4 semaines qui à mon sens est la seule période vraiment réaliste.

Et là, c’est le drame…

Devant le regain de productivité de l’équipe, les demandes explosent à nouveau. Les développeurs reçoivent plus de 5 mails par jour des utilisateurs, avec ou sans le business owner en copie. Les règles de gestion évoluent sans cesse, les couleurs dans les rapports aussi, les sources de données changent considérablement, et la mauvaise habitude de donner la priorité au dernier qui a parlé réapparaît. A nouveau l’équipe s’enlise et la satisfaction des utilisateurs sombre.

Pour moi le problème est clair : l’équipe est en sous-capacité. Si nous étions capables de dépiler plus vite les tickets, nous arriverions à retrouver un flux optimal. Mais dans notre cas, même avec l’ajout d’un développeur, la situation persiste. Le delta entre besoin et capacité de production est vraiment trop important. Pas possible d’ajouter plus de ressources, d’un point de vue budget et praticité, nous sommes au maximum.

 Dilbert - Product Owner vs Développeur

Alors j’ai pratiqué ce que je prêche, et j’ai demandé au business owner, qu’on considérera désormais comme un chef de projet MOA, de commencer à écrire des spécifications fonctionnelles. Chaque demande d’évolution doit mettre à jour la spécification correspondante, chaque nouveau besoin doit être pensé et écrit dans le dur.

Mon objectif est clairement d’introduire une contrainte au niveau métier, pour stabiliser la génération des besoins (le rythme est sincèrement démesuré) et ainsi faire basculer au niveau MOA le goulet d’étranglement du flux.

Car à être trop disponible et réactive, l’équipe de développement était devenue une extension du cerveau du business owner, et de certains utilisateurs trop exigeants. Chacune de leurs pensées à demi digérée était rapidement écrite dans un mail et transmise en priorité 1, trop souvent en totale contradiction avec l’info précédante. J’espère que le fait d’avoir à se poser pour penser et écrire concentrera leurs idées et diminuera les changements d’avis. Le travail de réconciliation et d’harmonisation fonctionnelle doit définitivement être réalisé par le business owner, pardon, le chef de projet MOA.

Evidemment c’est une étape temporaire, une astuce qui donnera également à l’équipe le temps de souffler un peu et traiter les vraies priorités. Je compte bien retourner à nouveau dans un mode plus lean une fois l’orage passé. Et je provoque en parlant du retour du cycle en V, puisqu’on conserve bien la livraison continue et le fonctionnement en mode pull. J’impose juste une contrainte de documentation plus lourde côté utilisateur avant d’accepter les activités dans le backlog.

On en reparle dans quelques mois, pour voir si l’expérience porte ses fruits !

PS : Evidemment toute cette histoire se vit dans un contexte d’entreprise plus global, sur fond de guerre politique entre services, de rachat de sociétés et d’avancement de carrière des internes, qui expliquent beaucoup plus mais que je ne peux évidemment pas raconter ici 😉

Savoir rester lean dans son projet décisionnel

Vous vous demandiez peut-être à quoi je passais mon début d’année (plutôt que de vous écrire des articles de 3 pages de long) ? Et bien en dehors de ma récente promotion (une fois nos expérimentations d’organisation stabilisées je vous en parlerai, soyez patients), je le consacre à la finalisation d’un projet de plusieurs mois, réalisé par un padawan de talent et supervisé par mes soins.

Padawans en tenue

Sont pas beaux mes padawans? Tenue obligatoire en clientèle!

Entre 2 anomalies à corriger, nous rédigeons la documentation et préparons le voyage de l’application de l’environnement de développement, et de notre responsabilité, à celui de production, et à la responsabilité de l’exploitation. Au passage c’est toujours pendant ce genre de transition que l’idée du devops revient me faire des yeux doux. Ou encore le concept de livraison continue. Malheureusement ici je n’ai pas réussi à convaincre le métier et l’IT de bosser en mode Agile. Mais ce n’est pas le sujet du jour, revenons à nos moutons !

La documentation technique terminée, elle est relue par le directeur d’étude (respect, ce n’est pas souvent que ça arrive). Et ce dernier s’étonne : quasiment pas de règles de gestion, un schéma en étoile simpliste, un cube à la DSV vide, des dimensions sans surprises techniques. Ok on trouve bien quelques calculs MDX, et ok la partie ETL fait pas loin d’une centaine de packages, mais ce n’est que parce qu’on a fait un bon travail et bien tout découpé en flux de données unitaires. En dehors de ça la solution semble étonnement vide pour 3 mois de développement.

Un tout petit plat gastronomique dans une grande assiette

Minimaliste mais plein de goût, comme au resto gastronomique!

Et bien pour tout vous dire, j’en suis assez fier. Parce que pour arriver à cette apparente simplicité, ce « vide » dans la solution, cela nous a demandé des efforts considérables. Un projet informatique est soumis à une certaine forme d’entropie. Plus on avance, plus des éléments viennent se rajouter, des fonctionnalités, des données, des exceptions, des contournements, et si on n’y fait pas attention, sans rien toucher au périmètre initial de l’application, la solution est tout de même devenue un plat de spaghettis indémêlables avant même la livraison du lot 1.

Lutter contre cette tendance demande un effort constant. Dès qu’on se relâche, on se retrouve avec des règles de gestion implémentées dans des vues (ou pire, dans la DSV du cube), parce que c’est rapide, plutôt que de faire les choses proprement et d’ouvrir une énième fois l’ETL, modifier les métadonnées, les flux, et tout re-tester après.

Mais il ne faut pas se leurrer : tout ça c’est de la dette technique, et rien de pire pour une solution informatique de commencer sa vie encore plus endettée qu’un étudiant américain ! Alors ne relâchez pas la lutte, pensez marathon plutôt que sprint (rien à voir avec SCRUM ;)), pensez Lean, et faîtes un cadeau au vous de dans 6 mois qui devra bosser sur le lot 2 ou corriger une anomalie: laissez-lui une solution toute propre, il vous remerciera!

The Mythical Man-Month – Frederick P. Brooks, Jr.

J’ai profité de mes dernières vacances pour lire « The Mythical Man-Month » (Amazon) de Frederick P. Brooks, Jr. (un des ténors du génie logiciel).

C’est LE livre qui apparaît systématiquement dans les tops 10 des livres à lire pour les ingénieurs logiciels, chefs de projet, développeurs ou encore manageurs de développeurs.

Même si l’édition originale date de 1975, et l’édition anniversaire de 1995, la plupart du contenu reste entièrement d’actualité, puisqu’il s’agit principalement de bon sens. Enfin surement qu’à l’époque beaucoup des choses qu’il raconte étaient nouvelles. Aujourd’hui elles font partie – ou devraient faire partie – de la culture de base de l’informaticien au sens large

Je vous livre quelques idées du bouquin histoire de bien cerner l’ouvrage :

  • (p5,6) On peut étendre un programme en travaillant sur son industrialisation (généralisation, documentation, tests, maintenance…) ou sur son intégration (interfaçages à d’autres systèmes, intégration dans l’écosystème de l’IT), mais pas les 2 en même temps.
  • (p16-19) Ajouter des développeurs à un projet en retard le retardera encore plus, aussi connu sous « 9 femmes enceintes ne font pas un bébé en un mois ».
  • (p32-36) Il propose une méthode d’organisation pour les très gros projets : mettre en place N équipes de 10 personnes chacune centrées autour d’un lead programmer (le chirurgien, un mec ultra talentueux), son copilote (le même en un peu plus junior, qui apprend et vérifie), les 2 seuls à développer et une équipe de support.
  • (p45,46) Définition de l’architecte (il le sous-entend fonctionnel – la MOA quoi) : qui représente l’intérêt de l’utilisateur, qui doit indiquer quel est le résultat attendu mais pas comment cela doit être fait. Par opposition au constructeur (la MOE), qui lui prend en compte les contraintes et le ratio coût/performance, et conçoit  la solution. Ce qui amène un cycle de développement : Architecture (MOA – On définit la fonction d’une boîte noire) > Implémentation (MOE –  On établit le contenu de la boîte) > Réalisation (MOE – On fabrique la boîte). Ne vous offusquez pas sur son choix de vocabulaire, qui diffère de ce qu’on a l’habitude d’employer en France, l’important c’est le découpage des tâches et des responsabilités.
  • (p62) Les spécifications sont le manuel utilisateur.
  • (p116) Le mieux est de toujours commencer par un prototype, jetable ci-besoin, plutôt que de vouloir y arriver du premier coup, puisque la plupart du temps on recommencera plusieurs fois du début.
  • (p117) Tous les besoins utilisateurs ne doivent pas être pris en compte dans le design. Et plus on avance dans le projet, plus c’est vrai.
  • (p142) Il faut tester les spécifications : faire des maquettes, tester les règles de gestion, avant même de commencer le développement.
  • (p143) Le mieux est de faire des programmes modulaires, afin d’augmenter la capacité d’adaptation du système (En 1975 manifestement ce n’était pas évident ;)).
  • (p155) Les jalons sur le planning doivent être clairement identifiés (périmètre et date), afin de ne pas pouvoir se mentir à soi-même par rapport à l’avancement.
  • (p157) Un directeur de projet ne doit pas intervenir dès le premier retard d’un de ses chefs de projet, sans quoi ils arrêteront de rapporter les glissements pour fuir le micromanagement.
  • (p201) Le développement itératif c’est le top (En 1975 ! C’était révolutionnaire !)

Évidemment il y a plein d’autres choses très intéressantes, et à chaque fois il développe et justifie ses idées, mais pour moi le top est dans cette liste.

Vous faut-il le lire ?  Je dirais oui si :

  • Vous vous devez d’avoir de la crédibilité en tant que bloggeur qui ramène sa fraise sur la gestion de projet (mon cas ;)).
  • Vous êtes ou aspirez à devenir chef de projet et que vous voulez comprendre le pourquoi de ce que vous appliquez.

Dans le cas contraire, votre bon sens, l’expérience personnelle et suivre la « BI ça vous gagne » suffiront largement à faire votre culture 🙂

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?

Gestion de projet décisionnel : gardez vos utilisateurs proches de vous!

Entendu par un camarade consultant la semaine dernière dans l’open-space chez son client, c’est le directeur des études qui s’adresse à la chef de projet MOA : « Il faut arrêter de mettre tout le monde dans vos mails! Si vous parlez au métier, ne mettez pas la MOE en copie et inversement. Il ne faut pas qu’ils communiquent directement! ».

Mes dents grincent…

J’insiste lourdement sur ce point dans ma session sur la modélisation dimensionnelle, construire un datawarehouse sans les utilisateurs, sans les métiers, c’est le chemin direct vers les projets les plus frustrants qu’il soit.

Mais d’abord un peu de vocabulaire. Notez que ce ne sont pas des définitions absolues: c’est ma vision de la chose, et cela nous permettra juste de ne pas discuter pendant 3h pour se rendre compte à la fin qu’on était d’accord depuis le début:

  •  Côté Cycle en V (on spécifie un sujet de bout en bout, on développe tout d’un coup, on livre tout d’un coup – échelle temporelle : le mois)
  • Métier / Utilisateur : Au sens strict, les gens qui utiliseront le système. Donc ça exclut les sponsors, les acheteurs, et tous les gens qui passent leur temps en réunion mais qui ne produisent rien.
  • MOA : Maîtrise d’Ouvrage. Les métiers passent commande auprès de la MOA d’une solution à un de leurs problèmes. La MOA va écrire un cahier des charges qui décrit la solution le problème et les attributs essentiels de la solution (MàJ 26/12/11 – précision). Ils connaissent bien les problèmes que les métiers ont l’habitude de rencontrer et les solutions usuelles qui y répondent. Ils savent quelle(s) MOE impliquer pour chaque solution.
  • MOE : Maîtrise d’Œuvre. Réalise les solutions. Plusieurs MOE aux capacités distinctes peuvent intervenir sur une même solution.
  • AMOA : Assistance à la MOA. En informatique, unité spéciale de la MOE qui à force de réaliser des solutions commence à bien connaître les problèmes. Va filer un coup de main à la MOA quand les sujets deviennent complexes.
  • PMO : Projet Management Office. Les gens qui suivent les plannings et les budgets au niveau global. Ils ne produisent rien au niveau projet.
  • Côté Agile (on définit un besoin unitaire, on le développe, on livre uniquement la solution locale, on itère – échelle temporelle : la semaine), les termes correspondent ici à la méthodologie SCRUM:
  • Product Owner : Son nom est écrit sur le produit. Son activité principale c’est la bonne tenue du backlog au niveau produit – la liste ordonnée par priorité des fonctionnalités qu’on veut voir apparaître. Notez qu’il ne doit pas forcément écrire lui-même toutes les users stories (la description des fonctionnalités), mais il doit travailler à ce qu’elles soient le plus clair possible et que leur ordre corresponde effectivement à la valeur métier qu’elles apportent.
  • SCRUM Master (ou équivalent) : Garant de la bonne application de la méthodologie. Son but à terme c’est de ne plus avoir de boulot! En effet si tout le monde joue bien le jeu, plus besoin de lui 😉
  • Equipe de développement : Tous les contributeurs qui permettent la livraison des besoins unitaires.

Maintenant que c’est clair, on peut revenir au sujet du jour. L’étape n°0 pour la modélisation de son datawarehouse c’est identifier ses utilisateurs clefs, et se garantir un accès direct à leur calendrier. Pour moi c’est juste indispensable. C’est la raison pour laquelle j’aime beaucoup la philosophie Agile. Peu importe la méthodologie Agile choisie (la plupart du temps je n’utilise qu’un mini SCRUM à ma sauce), ce qui compte c’est de délivrer de la valeur, rapidement. Certes ça a un coût sur l’emploi du temps du Product Owner, mais on obtient des solutions qui répondent beaucoup mieux aux besoins des utilisateurs.

Mais quand on est en cycle en V, on n’accède pas directement aux utilisateurs, on doit passer par la MOA. Et là il faut que les rôles de chacun soient clairs : la MOA n’est pas là pour faire écran entre les métiers et la MOE.

Dans un premier temps, la MOA est là pour comprendre le besoin métier et choisir la MOE qui saura réaliser la solution.

Une fois ce choix fait, elle est là pour faciliter les échanges entre les métiers et la MOE. C’est un rôle d’interprète et de diplomate. Interprète pour que tout le monde se comprenne – expliquer le métier aux techniques et les contraintes techniques aux métiers. Diplomate pour faire coïncider les objectifs de tout le monde: un besoin théorique parfait pour les utilisateurs VS la dure réalité technique imparfaite de la MOE.

De la même manière qu’un interprète ne remplace pas un interlocuteur dans un dialogue, la MOA ne doit pas occulter la MOE. D’où mes dents qui grincent quand j’entends un directeur des études dire l’inverse…

En tant qu’architecte j’ai un problème supplémentaire pendant les cycles en V (en plus des problèmes habituels des architectes). Je m’occupe de l’architecture technique, activité clairement MOE, mais également de l’architecture fonctionnelle, à savoir la modélisation dimensionnelle à proprement parler. Je réponds entre autres aux questions suivantes:

  • Quelles sont mes dimensions?
  • Quelles sont mes mesures?
  • Quel processus métier modéliser dans la table de fait?

Et ça ce sont des questions qui ont souvent déjà des réponses dans le cahier des charges rédigé par la MOA. Si les MOA sont éclairées, les réponses sont bonnes, ou au minimum elles ne sont pas figées dans le marbre. Le problème survient quand les réponses ne sont pas optimales et qu’elles ont déjà été promises à l’utilisateur. Là pas de remède miracle à part une bonne dose de diplomatie et pédagogie.

L’autre problème c’est quand une technologie est choisie par la MOA: « Mon utilisateur veut un cube pour faire des tableaux croisés dynamiques sur les 500’000 clients dans les 100’000 portefeuilles et afficher le détail »… Pour ceux qui ne connaissent pas les technos, c’est l’équivalent de choisir un semi-remorque pour rouler en ville parce qu’on aime bien la taille du coffre. Le choix d’une technologie pour un projet décisionnel n’est pas une décision anodine. Inclure la MOE dans ce choix est une évidence qu’il faut malheureusement souvent rappeler.

Désolé pour le pavé, mais il fallait que ça sorte 😉

Prochains sujets : choisir la bonne gestion de projet pour son projet décisionnel (Agile vs Cycle en V), et choisir la bonne technologie dans l’écosystème Microsoft.