Objectifs de nos articles

Nos articles visent à partager avec nos lecteurs les méthodes et les pratiques que Lato Sensu Management applique tous les jours à la conduite des projets dans les secteurs bancaire, des télécoms et de la pharmacie. Ils ambitionnent également de susciter le dialogue et l'échange d'idées.

Lorsqu'un article est affublé de l'avertissement « à paraître » cela indique qu'il n'est pas disponible ou qu'il n'est pas encore finalisé.

2009-03-20 à 16:14:26

Méthodologie agile : une vue d'ensemble

Toutes les méthodologies se valent, en bien ou en mal. Souvent en bien, parfois en mal, ou est-ce l'inverse ? Nous avons décider ne nous fâcher avec les ronds-de-cuir de la gestion de projet, avec ces individus qui ne supportent que la position assise prolongée  !

Le Littré {{—}} la référence {{—}}, pour méthodologie, nous parle de philosophie, d'un traité des méthodes, de l'art de diriger l'esprit humain dans la recherche de la vérité. Tout un programme à vrai dire. On parle aussi d'ensemble de méthodes d'un domaine donné, de façons de procéder.

À vrai dire, une méthodologie devrait être comprise comme une série de gammes, de recettes à succès, un entraînement qui vise un but, un esprit de travail (hmmm ... philosophie). Cela est vrai pour les méthodologies dites lourdes (e.g. Prince 2) ou pour les méthodologies plus légères, dites agiles. Atteindre un but dans un esprit donné !

Fixer un objectif, avoir un but

Ceux — et ils sont nombreux, très nombreux mêmes — qui confondent méthodologie et objectifs se trompent lourdement. Ils confondent l'objectif et les moyens de l'atteindre … et pour eux, le respect d'une méthode donnée devient l'enjeu de leur travail, leur raison d'être. Ils perdent le sens, la direction, la vision … mais faites-leur confiance pour vous dire quand il faut créer un amendement à un Business Case, quand il faut rentrer un Exception Report, quand et sous quelle forme rentrer votre feuille d'allocation de ressources, dans quelle mailbox commune il faut envoyer une demande de congé, quel template utiliser pour gérer les risks and issues, etc. En cela, ils excellent ! Mais de gestion de projet, nada !

Ces gens sont souvent incapables de se remettre en question et ils se perdent en subtilités confondantes … car le succès des projets leur est devenu étranger  : ils amalgament succès et apparences, ils fondent la réussite et les rapports (vous savez ce genre de rapport qui explique tout ce qui a été fait, qui vous donne des RAG (Red, Amber, Green), des colonnes avec des pourcentages … mais qui amèrement ne posent jamais la question qui fâche, à savoir Est-ce que le client est content ?. C'est une erreur dramatique — une faute, disons-nous — qui pave le plus souvent le quotidien des chefs de projet d'arguties administratives stériles. Nous l'avons vécu dans les plus grandes organisations comme les banques, celles-là mêmes qui sont aujourd'hui dans la tempête … pour manque de gouvernance, de clairvoyance. Disons-le carrément, dans ces administrations du privé qui sont aujourd'hui la risée du monde.

La seule chose qui compte dans ce pandémonium est de se rappeler les 7 commandements du chef de projet, et basta  :

  1. Délivrer (qqch d'utile) tu feras,
  2. À la satisfaction de tes clients
  3. Dans les conditions de temps et de budget.
  4. Créer de la valeur tu feras;
  5. Tes (con)disciples tu respecteras
  6. et fiers et heureux tu les rendras
  7. Afin qu'ils souhaitent t'accompagnent dans les nouvelles aventures que tu te fixeras.

… et toute méthodo doit vous permettre de respecter ces 7 commandements ! Exit toute autre théorie. Haro sur les ronds de cuir.

Les méthodologies agiles - le Manifeste Agile

Parler d'agilité, en ces temps troubles de récession économique, est de mise. Il ne s'agit pourtant pas de limiter le propos concernant l'agilité au développement d'applications {{—}} bien que ce soit notre sujet principal {{—}} mais de l'étendre à la flexibilité « Business », de promouvoir une forme d'élasticité, de capacité d'adaptation. Certains y trouvent une possibilité de croissance, d'autres y voient une technique de résilience, de survie.

Le Manifeste Agile est né de l'initiative de Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, et Dave Thomas, 17 acteurs tous reconnus dans la profession de chef de projet. Ils ont édicté 12 principes de base, qui sont la fondation de toute méthodologie agile. Ces 12 principes sont cités ci-dessous, en anglais :

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity{{—}} the art of maximizing the amount of work not done {{—}} is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Pour peu que nous puissions en juger, ces principes de base respectent les 7 commandements du chef de projet que nous mettions en exergue sous forme d'une parabole. Nous les faisons nôtres, sans vergogne.

Les 12 principes énoncés ci-avant se matérialisent par une philosophie qui peut se formuler suivant les quatre valeurs suivantes (édictées par les 17 membres fondateurs du Manifeste Agile)  :

  1. Accorder plus d'importance aux individus et aux interactions qu'aux processus et outils
  2. Accorder plus d'importance à du logiciel qui marche qu'à de la documentation
  3. Accorder plus d'importance à la collaboration avec le client qu'à la négociation de contrat
  4. Accorder plus d'importance à la flexibilité et à la capacité de répondre aux changements qu'à suivre un plan pré-établi

Une fois encore, nous souscrivons entièrement à cette philosophie. En revanche, elle ne nous dédouane pas de mettre en place processus et outils, documentation et plan, négociation de contrat, etc. En d'autres termes, les quatre valeurs sont une échelle et non un rejet péremptpoire de principes superfétatoires.

Les reproches, les délires, les mythes

Il est courant d'entendre des propos diffamatoires concernant les méthodologies agiles. ces propos sont tenus par des gens qui défendent leur fonds de commerce.

Les sujets sur lesquels les méthodologies agiles sont attaquées sont connus. Il s'agit le plus souvent de mettre à mal le principe même de la simplicité et d'utiliser la méconnaissance de l'auditoire pour instiller le doute. À défaut, on dénigre complètement la validité de la démarche en utilisant des arguments "ad hominem".

Ainsi, est-il courant de parler de "méthode de cowboy", "méthode folklorique", "absence de rigueur", … sans qu'il soit nécessaire, semble-t-il, de motiver ces médisances. On prétend que dans les méthodologies agiles, il n'est pas demandé d'avoir de documentation (ce qui est faux), que les rôles habituels de la gestion de projet sont inexistants (par exemple on fait fi des Analystes Business, des testeurs, …).

Réalités … cependant

Même si beaucoup des reproches adressés aux méthodologies agiles sont des escobarderies de responsables dépassés, celles-ci ne doivent pas nous faire oublier quelques difficultés réelles.

Nous rangeons ces difficultés en 3 groupes distincts :

  1. Flexibilité
  2. Construction des parties constitutives fondamentales d'une solution technique
  3. Information des parties prenantes (stakeholders)

Flexibilité

La flexibilité doit provenir tant du fournisseur de la solution que du client. Ce n'est pas toujours comme cela que le client l'envisage et plus particulièrement lorsqu'il s'agit de discuter de budget et d'échéances. C'est une réelle difficulté pratique des méthodologies agiles.

Construction des parties constitutives

Blabla

Comment ça marche ?

N'attendez pas d'un simple article qu'il aille dans le détail de la pratique de tous les jours. Nous ne faisons qu'éveiller votre intérêt et vous présentons les principes fondateurs. Nous souhaitons déclencher une réaction.

… suite à écrire.