Praxeme et méthodes agiles : un début d’articulation

Les méthodes agiles incluent des dispositifs opérationnels aux vertus très intéressantes, notamment le pair programming qui peut être d’une redoutable efficacité en résultats bruts mais aussi en formation continue, ou l’approche par les user stories qui aide à rétablir un discours orienté métier.

En revanche, l’idée fondamentale sur les spécifications me semble passablement biaisée : après avoir admis que ni les gens du métier, ni les IT ne parviennent à réaliser des spécifications pertinentes, rigoureuses, contrôlables et démontrables, on abandonne le terrain sans combattre : ne faisons plus de spécifications, elles émergeront naturellement par un processus d’essais-erreurs commun entre IT et gens du métier. Dans la foulée, il semble qu’on fasse disparaître les effets tunnels, ce qui peut à première vue se confondre avec une miraculeuse réduction des coûts. Je résume, mais pas tant que ça.

Développement agile ET spécifications. Pourquoi pas ?

Il y a une autre façon de voir les choses. Et comment alors profiter des vertus des approches agiles en plus des dispositifs indépendants comme le pair programming ?

Deux éléments de réponse…

  1. La démarche agile se concentrant sur les activités des utilisateurs, elle appartient en propre à l’aspect pragmatique. Les user stories à base de scénarios sont des candidats tout trouvés pour faire le lien avec la conception des use cases. Une fois finalisés, les scénarios sont d’abord intégrés dans des UC bruts puis retravaillés en termes d’activités élémentaires pour réduire les redondances et favoriser la réutilisation (voir le procédé de conception de la vue de l’organisation dans l’aspect pragmatique).
  2. La réalisation des parties d’applications visibles par l’utilisateur en runs courts et démontrables devient un outil à fort potentiel dans le dialogue entre les IT et les gens du métier. Il s’établit sur une base active, souvent graphique et dans le contexte même de l’utilisation. Son pouvoir est alors de lisser les difficultés de dialogue, de s’appuyer sur un artefact non plus seulement décrit, mais réellement présent.

…, deux pré-requis,

  1. Les vocabulaires, deviennent encore plus importants pour supporter le travail commun IT / métier. La capture des terminologies locales (jargons) dont l’efficacité n’est pas remise en cause, permet de réduire les efforts de réflexion sur les nouvelles applications et de se concentrer sur les vrais sujets.
  2. Le modèle sémantique, evidemment, est le support stable et rigoureux sur lequel les activités seront plaquées exactement selon la démarche Praxeme fondamentale. Il doit donc être suffisamment avancé pour supporter les runs agiles même si ces runs peuvent commencer bien avant que le modèle ait aquis sa complète maturité.

… et deux dangers

  1. Ne pas oublier les scénarios alternatifs. Cest une recommandation générale qui s’applique encore plus en développement agile. La forme même de la démarche entraîne à se concentrer sur les scénarios nominaux (ceux où tout se passe au mieux) et à oublier purement et simplement les dysfonctionnements, les exceptions et autres cas étranges. Ces oublis, même s’ils sont peu nombreux en cas et en probabilité d’apparition, peuvent très facilement mettre tout le système en péril.
  2. Ne pas négliger les jeux de tests. Là encore, rien de nouveau mais une tendance qui peut aller de paire avec la démarche de développement agile dans une envie de pousser encore plus loin des économies qui se payeront très vite, et très cher.
Publicités
Cet article, publié dans Aspects, Méthode, est tagué , , . Ajoutez ce permalien à vos favoris.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s