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.
- 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.
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.
Deux possibilités existent alors :
- Soit on arrive à faire coïncider le volume du flux d’idées et la capacité de production pour retrouver un équilibre,
- 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?
La BI ça vous gagne! 
Merci pour cette première étape. On attend la suite avec impatiente… Notamment le « comment découper son datawarehouse en fonctionnalités unitaires », surtout en début de projet lorsqu’il est question d’initialiser la modélisation et l’alimentation.
Merci Alexandre pour ce retour 🙂
Désolé de la jouer en mode série américaine, avec un teaser qui fait trépigner, j’essaye de poster la suite en début de semaine prochaine.
Non ! Les itérations agiles ne sont pas des mini cycles en V !
Ce sont des découpages temporels qui définissent les moments auxquels une application partielle mais fonctionnelle sera déployable. Gérer une itération comme une succession de phases conception/codage/recette, c’est le plus sûr moyen pour ne rien avoir de déployable en fin d’itération.
Pour le reste, quand je lis des phrases telles 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 », je préfère m’abstenir de tout autre commentaire.
Chouette, du débat 🙂
D’abord je vous remercie d’avoir pris le temps de répondre, j’apprécie sincèrement l’effort!
Je vous rassure tout de suite, vous avez raison, j’ai fait un gros raccourci en disant que les itérations agiles étaient des mini cycle en V.
Maintenant je pense qu’il faut savoir prendre du recul sur les mots qu’on utilise. On ne peut pas nier que réaliser une fonctionnalité ça passe par s’entendre sur ce qu’est cette fonctionnalité, la réaliser et la livrer pour qu’elle soit validée par le product owner. Conception, réalisation, livraison, recette. Cela demande peut-être un peu d’imagination, mais on arrive à faire coïncider ces activités entre les 2 méthodologies. Ces mots sont peut-être pour vous remplis de connotations ou sous-entendus propres au cycle en V, cependant avant cela ils représentent des activités qui sont toujours réalisées au cours d’un projet.
Par contre vous mettez le doigt sur un point important que j’aurai du préciser: l’itération agile est plus qu’un zoom temporel au minimum par le fait qu’elle découpe un besoin complet en fonctionnalités qui apportent de la valeur à l’utilisateur. C’est une précision importante et je compte me rattraper la semaine prochaine quand j’aborderai le découpage du DWH.
Pour le reste, c’est dommage que vous ne souhaitiez pas nous en dire plus, je suis certain que vous avez des choses très intéressantes à partager! Rendez moi juste un petit service: essayez de calmer le jeu 😉
Bon… Je vais essayer de préciser ce que je reproche globalement à cet article.
Si le titre avait été « Gestion de Projet Décisionnel – Développement itératif ou Cycle en V ? » et qu’il n’était fait nulle part référence à des « méthodes agiles », je n’aurais probablement rien eu à dire sur l’article (et d’ailleurs je ne l’aurais peut être jamais lu)
Le problème de fond, c’est que les méthodes agiles c’est 4 valeurs et 12 principes.
Pour les personnes peu informées « méthodes agiles = développement itératif » alors que l’aspect itératif n’est qu’un infime détail des méthodes agiles abordé partiellement dans le 3ème principe sans parler d’itération (on ne parle que de livraisons fréquentes).
Alors, après ça, on peut discuter des mérites comparés de divers processus et phasages de développement logiciel mais je ne trouve pas cela très intéressant si c’est juste pour implémenter un « workaround » sur des problèmes beaucoup plus fondamentaux tels que la compétence des personnes ou la confiance entre les personnes.
Là encore je suis d’accord avec vous: pour moi aussi l’Agilité c’est avant tout des valeurs – comme le Lean IT d’ailleurs.
Je me suis étonné de votre réaction puisque je précise lourdement dans l’article que je parle processus et pas valeurs:
> « et si on se concentre sur l’organisation projet et pas les valeurs que véhicule l’Agilité, »
> « encore une fois si on retire les valeurs de l’Agilité de l’équation ».
Mon erreur c’est sans doute d’avoir traité les processus avant de parler des valeurs. Chronologiquement j’aurai du commencer par là.
Cela dit si vous faîtes un tour sur ce blog, vous verrez que si je ne suis pas aussi pointu que vous sur l’Agilité, les valeurs c’est un sujet que je suis loin de négliger.
Enfin, pour le titre, oui il est mauvais si on est coach agile, ScrumMaster « certifié » ou chef de projet expérimenté sur les méthodes agiles, mais ce n’est pas l’audience de ce blog. Dans le décisionnel, l’Agilité c’est une nouveauté, et on essaye encore de comprendre comment correctement l’appliquer. Cet article c’est de la vulgarisation, les distinctions que vous faîtes sont encore trop pointues pour nous.
M. Oaz,
Je pense que vous êtes un peu trop à cheval sur les mots.
Ethymologiquement, agile = souple et rapide. L’article parle bien d’agilité dans un projet BI.
Je fais de l' »agile » depuis 2001 (en BI et en dev.) et jamais je ne me suis préoccupé de savoir si j’étais dans la droite ligne du Manifeste Agile…
Agile = 4 valeurs et 12 principes ? C’est très réducteur je trouve (même si les valeurs et principes sont bons).
Plutot que de philosopher sur le meilleur terme (itératif ou agile), je préfère féliciter la métaphore de Florian sur les facteurs d’agilité (ou d’itérativité) : flux vs. capacité. Une belle refléxion sur la problématique.
Pour finir je citerai Descartes qui déjà au 17eme siècle proposait une méthodologie :
« Le bon sens est la chose du monde la mieux partagée; car chacun pense en être si bien pourvu que ceux même qui sont les plus difficiles à contenter en toute autre chose n’ont point coutume d’en désirer plus qu’ils en ont. En quoi il n’est pas vraisemblable que tous se trompent; mais plutôt cela témoigne que la puissance de bien juger et distinguer le vrai d’avec le faux, qui est proprement ce qu’on nomme le bon sens ou la raison, est naturellement égale en tous les hommes; et ainsi que la diversité de nos opinions ne vient pas de ce que les uns sont plus raisonnables que les autres, mais seulement de ce que nous conduisons nos pensées par diverses voies, et ne considérons pas les mêmes choses. Car ce n’est pas assez d’avoir l’esprit bon, mais le principal est de l’appliquer bien ».
(oui, je sais, il faut la lire 2 fois pour bien comprendre :))
Mr Djeepy,
L’étymologie, c’est l’étude de l’origine des mots pour découvrir leur sens véritable.
Agile vient du latin agilis qui signifie « que l’on mène facilement » ou « qui se meut aisément ».
Cela se rapproche éventuellement de la souplesse mais cela n’a, par contre, pas grand chose à voir avec la rapidité.
Ceci étant, le sens d’un mot ne dépend pas que de son origine. Il y a le contexte culturel (ici un débat sur le développement logiciel) et le contexte syntaxique (ici le mot agile qualifie systématiquement une méthode). Autant de raisons pour considerer « agile » à la lumière du manifeste du même nom.
@Fleid
Honnêtement, je trouve dommageable d’aborder l’agilité par les processus, ne serait-ce que parce que les individus et leurs interactions ont plus de valeur (ce n’est pas moi qui le dit, c’est le manifeste). Ca ne veut pas dire qu’il ne faut pas parler de processus mais que la dimension humaine a au moins autant d’importance.
Typiquement, si ma capacité de production est un goulet d’étranglement, je vais essayer d’augmenter l’efficience du goulet (augmenter la confiance entre les personnes, entrainer les producteurs à accroitre leur capacité, etc.) avant de me rabattre sur la diminution du flux de spécifications qui atteignent la production.
En théorie de contraintes(http://fr.wikipedia.org/wiki/Th%C3%A9orie_des_contraintes), un concept connexe à l’agilité, on parle d' »exploiter la contrainte » avant de « subordonner tous les processus au processus contraint »
@Oaz
Croyez-vous vraiment que le fait que je parle de processus avant les valeurs vaille le tweet agressif que vous m’avez servi? Comment voulez vous que je vous prenne au sérieux quand ensuite vous venez me parler de valeurs? Connaissez vous ce blog? Me connaissez vous? Ma position sur l’importance des valeurs? Avez vous pris le temps de comprendre le contexte avant de juger?
Le malheur c’est que vous dites des choses très intéressantes, j’ai noté de très bons articles sur votre blog, mais l’arrogance dont vous faîtes preuve décrédibilise complétement votre message.
Le mieux pour moi est de continuer sur le sujet comme je l’avais prévu. Et tiens, c’est marrant, le prochain sujet c’est justement les valeurs, comme indiqué dans l’article quand on prend le temps de le lire 😉
Ah oui tiens la suite… sur le même ton que le premier billet de la série ;)4)
De toute façon la méthodologie c’est pour les filles ! Vive le quick & dirty !
Je viens de lire l’une de vos articles pour la première fois ainsi que tous les commentaires. Je suis nouveau en Agile mais je possède plusieurs années d’expérience en gestion de projet d’ingénierie logiciel (industriel, embarqué, médical …).
On voit effectivement les « mini cycle V » dans l’Agile alors pourquoi en faire un montagne! L’avantage du cycle en V est de pouvoir prédire la date de fin du projet ce qu’Agile ne peut procurer (ou que j’ai mal compris!!). Mais il faut une bonne méthodologie et un processus rigoureux pour évaluer chaque spécifications à sa juste valeur.
Sylvain,
Nous avons déjà eu assez de problème avec Mister Oaz sur ce thème, je le rejoins d’ailleurs à 100% là dessus, mais ne mélangez pas Agile et itératif 😉
Agile ça sous-entend des valeurs, une vision différente de ce qu’est un projet, et une manière originale d’appréhender la collaboration entre êtres humains. Le développement itératif c’est faire des mini cycles en V.
Faire le mélange n’est certainement pas de votre faute, je n’ai surement pas été assez clair dans mon article sur ce point.
Pour vous répondre, si on enlève les valeurs à l’Agilité, et qu’on ne se concentre que sur l’aspect itératif du développement, il est clair qu’il n’est pas la peine d’en faire une montagne.
Mais si on prend le tout, et qu’on se tient bien à l’esprit, oui on risque de mettre plus longtemps à arriver à la fin du projet, oui les estimations d’une date de complétion seront hasardeuses en début de projet (puisqu’on ne sait pas vraiment où on va), mais le résultat final sera autrement meilleur qu’avec un développement en mode tunnel. Et c’est là la montagne de différence avec le cycle en V: non seulement les équipes travaillent de manière beaucoup plus harmonieuse, mais le résultat produit est à tout moment une solution entière et fonctionnelle – même en plein milieu du projet – qui correspond réellement aux besoins. Ça on ne l’a pas vraiment dans un cycle en V.
Bonjour,
Je tiens à vous remercier énormément pour ce blog, car je suis un élève ingénieur en stage de fin d’étude, sur un sujet ou je dois tenir compte d’une vision cycle en V pour la gestion de mon projet, tout en tenant compte de la méthode Agile pour mener des workshops post-formation.
Je ne viens pas particulièrement du milieu informatique, ce qui m’impose un travail de recherche important sur ce sujet.
Le contexte de mon sujet concerne le déploiement d’un outil MES au sein d’une entreprise aéronautique, et je dois préconiser la méthodologie de la conduite d’ateliers pour les futurs utilisateurs de cet outil informatique.
Après lecture du blog et de ses commentaires, je peux conclure qu’il n’est pas absurde de baser le déploiement de mon projet sur un cycle en V, et que la conduite des ateliers concernant l’implémentation IHM du MES peut se faire par la méthode Agile?
Bonjour à vous!
Je crois comprendre que ce que vous souhaitez c’est utiliser méthode itérative, et non une méthode Agile, pour vos IHMs.
L’Agilité c’est une méthode itérative, certes, mais un des différences vient du fait qu’on découpe les itérations sur des fonctionnalités ayant du sens pour les métiers et non pas par des briques technologiques.
C’est à dire découper votre projet sur les processus métiers de votre application (gestion des commandes fournisseurs, gestion des activités sur la ligne de production, gestion RH…) de bout en bout (du code à l’IHM) et non faire tout le back office, puis toutes les bases de données, puis tout le middle office et enfin toutes les IHM.
Aucune honte à adopter un cycle en V, puis une méthode itérative sur les IHMs, mais ça ne correspond juste pas à de la véritable Agilité.
N’hésitez pas à poser vos questions, je suis là pour ça 😉
Merci Fleid pour ta prise en compte et ta réactivité.
Je n’hésiterai pas à revenir vers vous si j’en ressens le besoin. Ça n’est pas encore très claire pour moi en ce qui concerne mon niveau d’intervention concernant la gestion de données.
A ce stade du projet, je participe au cadrage du besoin.
Ce qui m’est demandé c’est de mettre en place une méthodologie de conduite d’atelier autours du MES (Manufacturing Execution System), de baser ma conduite de projet sur un cycle en V, et pour reprendre tes mots, mettre en place une forme d’itération (méthode Agile).
En tout cas je te remercie pour ta réponse:
« Aucune honte à adopter un cycle en V, puis une méthode itérative sur les IHMs, mais ça ne correspond juste pas à de la véritable Agilité. »
C’est exactement ça. Je ne suis pas dans se la véritable Agilité en tant que telle, et je ne suis pas informaticien. Ce qui m’intéresse c’est la conduite et la gestion de projet, pour ce cas là, Cycle en V et adaptation de la méthode Agile.
Ce que je trouve d’intéressant à travers cette mission c’est l’ouverture et une approche différente genre: Pourquoi ne pas utiliser ce qui marche ailleurs pour faire quelque chose de nouveau dans la conduite de projet?
Je m’étale.
Merci Fleid!!
Bonjour,
Concernant le risque sur les sources de données, j’ai une solution à vous proposer qui à mon sens respecte le framework Scrum. Elle consiste à intégrer dans l’équipe de développement une ou plusieurs personnes qui maitrise la source de données. Le manifeste dit :
Developement Teams are cros-functional, with all of the skills as a team necessary to create a product increment.
Dans un contexte de projet BI, la présence d’une personne à plein temps n’est peut etre pas nécéssaire. A ce moment, les « Community of practice » me semblent une bonne option. (http://www.mountaingoatsoftware.com/blog/cultivate-communities-of-practice)
Merci pour vos articles,
Guillaume