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’aimerai 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 de Johan Strandell (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 adapte 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 solution n°1. Le cycle en V correspond à la solution n°2.
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?
Rétroliens & Pings
- Gestion de projet décisionnel : gardez vos utilisateurs proches de vous! « La BI ça vous gagne!
- Gestion de projet décisionnel – Les valeurs de l’Agilité « La BI ça vous gagne!
- Décisionnel Agile : Réaliser son Datawarehouse en itérations agiles « La BI ça vous gagne!
- Modèle d’organisation de la DSI, ce qu’il ne faut pas faire. « La BI ça vous gagne!
- Petit Rappel Consulting: Forfait, Régie, Régie forfaitée… « La BI ça vous gagne!
- La BI ça vous gagne : Audience au 06/04/2012 « 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 !