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?

4 liens rapides pour la semaine (2011-24)

Après 3 Dilbert, 4 liens pour retourner dans le bain!

  1. Via BoingBoing, un article de Paul Krugman sur les régulations économiques qui favorisent les rentiers sur la création d’emplois.
  2. Une excellente vidéo d’un cycliste new-yorkais qui en a marre de prendre des contraventions stupides. Je trouve que l’auto-dérision est une magnifique forme de révolte face aux règlements absurdes.
  3. Jason Kottke fait le point sur l’ouverture du capital de Groupon.
  4. Sur Signal vs Noise, quelques retours d’entrepreneurs ayant vendu leur start-up à des grosses sociétés type Google ou Microsoft.

______________________

<< Semaine PrécédenteSemaine Suivante >>

Saines lectures

On m’a déjà demandé plusieurs fois quels étaient les bouquins que je trouvais indispensables. Pour éviter de me répéter, j’ai fais une petite liste qui ne perd rien à être hébergée ici.

Cette liste je la veux minimaliste et exhaustive. Je dis minimaliste parce que pour apparaître dans cette liste un bouquin doit m’avoir fait changer radicalement de point de vue, ou découvrir des idées fondamentales dont j’ignorais tout – c’est un critère plutôt restrictif! En fait ce sont les livres qui définissent ma manière d’appréhender le monde aujourd’hui. Les voici dans le désordre:

  • Approching Infinity : La série d’articles de Mike Masnick de Techdirt sur l’économie numérique. J’ai déjà du la linker 15 fois sur ce blog tellement je la trouve indispensable pour comprendre comment le numérique n’a rien changé à l’économie 😉 Ils avaient compilé un livre à partir de ces articles mais il n’est plus disponible. En attendant tout le contenu est disponible sur le site, tous les articles sont regroupés sur le lien.
  • ReWork de 37 Signals. Celui là aussi je l’ai déjà cité 20 fois, c’est un livre qui change complétement sa perception du monde du travail, tout simplement (dispo en FR, via Tommy)
  • Why Beautiful People Have More Daughters: la vulgarisation de référence de la psychologie évolutionniste. Ce livre permet de comprendre d’où nous viennent nos pulsions animales, nos peurs primales, et à moi ça m’a permit de mieux les vivre!
  • Life Inc de Douglas Rushkoff. Un peu plus difficile à lire que les autres, mais c’est un livre qui ouvre les yeux sur le monde corporatiste. Il repart du moyen age pour comprendre comment s’est constituée la notion d’entreprise, de corporation, c’est vraiment passionnant.
  • Starship Troopers, le livre de Robert Heinlein (et pas le film de Paul Verhoeven), qui existe en français sous le nom Etoiles, garde à vous !. C’est un livre qui a été pas mal critiqué au moment de sa sortie mais qui à mon sens renferme des trésors de philosophie.
  • Le Cycle des Dieux de Bernard Werber (enfin un auteur francais!). Alors ok, à la fin ça part en sucette, mais alors les deux premiers tomes sont juste magiques.

C’est tout pour le moment. Si je pense à autre chose, ou si j’en trouve un autre, je mettrais cette liste à jour. A votre tour maintenant, n’hésitez pas à me proposer votre liste dans les commentaires en bas 🙂

NB: Je me suis permis de mettre mon code affiliate dans les liens Amazon. Pour info ça me file une commission de 5% à utiliser sur leur site: c’est le début de la richesse!

4 liens rapides pour la semaine (2011-22)

Enfin les vacances! J’espère que les vôtres ne sont pas trop loin 🙂

  1. Un flashback de 37 Signals qui s’applique à toutes les disciplines pour tous les projets.
  2. Deux citations reprises par Swiss Miss: Benjamin Elijah Mays avec « Ce qui est grave ce n’est pas d’échouer, mais de viser trop bas » et Clay Christensen avec « Une stratégie de vie ce n’est rien d’autre que de décider consciemment d’allouer son temps, son énergie et son talent. »
  3. Une histoire qui résume bien la taxe trop importante sur l’innovation qu’est la protection de la « propriété intellectuelle ».
  4. Et pour finir le best-of d’edw519, un livre en ligne qui compile les meilleurs articles d’Ed Weissman, un des top contributeurs du Hacker News. Ça parle surtout aux programmeurs et aux consultants informatiques, mais c’est une excellente lecture pour les managers et directeurs IT afin de comprendre comment fonctionnent leurs troupes.

______________________

<< Semaine PrécédenteSemaine Suivante >>

4 liens rapides pour la semaine (2011-15)

Pas de Dilbert cette semaine, je rentre d’Amsterdam et je suis trop à la bourre! (Simple tourisme, c’était génial)

  1. Via Good Experience, un article qui résume en 5 phrases la crise budgétaire des Etats-Unis (applicable en France sans problème).
  2. Scott Adams (Dilbert) écrit une colonne sur comment obtenir une réelle formation en entreprenariat.
  3. Jason Fried sur pourquoi son entreprise, 37 Signals, ne possède pas de hiérarchie. Encore une fois c’est excellent.
  4. Aza Raskin qui nous rappelle qu’un peu de recul résout bien des situations.

______________________

<< Semaine PrécédenteSemaine Suivante >>

4 liens rapides pour la semaine (2011-12)

Et voilà!

  1. L’excellent Dan Ariely en vidéo. Ça parle de self-contrôle et de tentation et c’est l’incontournable de la semaine 🙂
  2. Un graphique intéressant via FlowingData sur l’adoption des derniers gadgets et leur prix.
  3. Jason Fried (37 Signals) nous raconte comment, pour son business, il a su transformer un échec critique en un événement fédérateur.
  4. Enfin, Cory Doctorow sur comment il utilise la redondance pour éviter de se noyer sous le flux de données constant qu’est Internet. A mon avis il y a une idée business intéressante qui se cache là dessous…

______________________

<< Semaine PrécédenteSemaine Suivante >>