Agile vs pas agile

Dans les séminaires ou dans les réunions, quand je présente l'agilité je montre les différences -généralement les bienfaits- par rapport à une approche ... pas agile.

Cela revient à séparer le monde des processus en 2 parties[1], ce qui est très schématique... De plus comment qualifier la partie non agile ?

Par opposition à agile, les américains utilisent souvent waterfall ou classical waterfall. De mon côté, je ne vais pas, pour catégoriser le non agile, parler de cycle en V puisqu'il n'existe pas. Pour qualifier un processus non agile, je dois dire, de mémoire, lorsque je cause en public :

  • processus traditionnel,
  • parfois processus classique,
  • voire processus séquentiel
  • et même il m'arrive de dire cascade


Donc je n'ai pas de qualificatif bien clair. C'est peut-être que la segmentation n'est pas adéquate. De la même façon qu'il est difficile, et réducteur, de faire rentrer les gens dans des cases, ce n'est pas évident d'organiser les processus en catégories.

A suivre...

Notes

[1] c'est un principe marketing de segmenter et j'ai fait un peu de marketing il y a quelques années

Commentaires

1. Le mercredi 21 mars 2007, 12:17 par Camille Bloch

Je pense que cela vient aussi du fait que personne (a ma connaissance) ne respecte réellement les processus "classique". Leur lourdeur est tel que les différentes parties du cycle (plus particulièrement la partie réalisation) ont tendance à prendre des "libertés".

De ce fait, il n'existe plus, à mon sens, de catégories bien définie, puisque qu'il en existe pratiquement pour chaque projet...

2. Le mercredi 21 mars 2007, 15:00 par Matthieu

C'est vrai qu'aucun des projets classiques que j'ai connus n'était une pure cascade : on fait des livraisons intermédiaires pour limiter l'effet tunnel, on met en place des processus de questions-réponses et de remise à niveau des specs fonctionnelles car on sait qu'elles ne peuvent pas être parfaites du premier coup, on demande régulièrement aux gens d'estimer leur reste à faire (ce qu'ils pensent vraiment, pas l'estimé moins le consommé), etc...

Disons qu'il y a d'un côté le projet le projet en cascade caricatural et de l'autre le projet parfaitement agile. Aucun des 2 n'existe, ce sont des abstractions.
Les vrais projets sont quelque part entre les 2, certains plutôt du côté cascade et d'autres plutôt du côté agile.
Et ce positionnement peut évoluer au cours de la vie du projet : on peut gagner ou perdre en agilité au fil des choix techniques et/ou d'organisation