Pourquoi l'approche processus ? (ou le match MOA MOE)
Bonjour,
Depuis quelques temps, l'idée de remettre en cause la répartition des rôles MOA-MOE réapparaît.
Voir, par exemple, ce billet tiré du Blog de M. Corniou.
Ce point de vue est souvent défendu par les promoteurs des méthodes "agiles" de type XP.
Il est normal que ce thème refasse son apparition de temps en temps.
De prime abord, la séparation stricte MOA/MOE n'a rien de sympathique, elle est fortement teintée de contractuel, ce qui décourage certains. Compte tenu des exigences de rapidité d'e mise en oeuvre, on peut penser que tout le formalisme attaché à la gestion MOA/MOE va constituer un frein.
D'autres reproches sont également faits.
La MOA (le client, pour parler plus simplement) a pour rôle principal d'exprimer ses besoins et ses exigences à la MOE (le fournisseur !).
A ce stade, plusieurs effets interviennent :
1 - la sur-exigence
Le client, qui est roi, comme chacun sait, mis en situation de "puissance" se met à exiger. Et il exige ! Il exige ! Il exige !
Et je me mets à sa place ! Supposons que, pendant la rédaction du cahier des charges, le rédacteur vienne dans mon bureau me demander ce dont j'ai besoin, il me paraît naturel de "charger la barque". J'y vais à fond. Je vais lui demander tout ce qui me semble plus ou moins nécessaire. Et même plus encore. Parce que j'ai plein d'idées. Et puis, je veux aussi toutes les fonctions précédentes, mais en mode simulation uniquement, histoire de vérifier que je ne fasse pas de bêtise en entrant les données.
Est-ce que j'ai réellement besoin de tout cela ?
2 - la spec de solutions
Le client n'a pas toujours la capacité à parler de ses besoins.
Quand vous avez soif, vous ne vous dites pas "j'ai soif, qu'est ce que je vais faire ? J'ai plusieurs stratégies ..." Non! Vous allez directement vous servir un verre d'eau.
Eh bien, pour la rédaction d'un cahier des charges c'est un peu le même phénomène : celui de la "spec de solution". Vous décrivez la solution plus que le besoin.
Décrire le besoin, c'est plus difficile, plus abstrait, mais c'est plus utile que de décrire la solution.
Souvent, quand la solution est décrite d'abord, il faut repartir en arrière et réinterroger les gens sur leur motivation d'origine.
Par exemple, un jour j'ai trouvé la phrase "le système doit stocker les données dans une base sécurisée". Bon, le lendemain j'en parle avec l'auteur et il m'explique, en français, avec ses mots à lui, que ce qu'il voulait, c'était tout simplement que seules quelques personnes dotées d'un profil particulier peuvent accéder à l'ensemble des données. Nous avons donc décidé de changer la phrase. Pas facile d'exprimer ses besoins !
3 - la faible connaissance du métier
C'est triste à dire mais souvent, il arrive que des gens en charge de la partie MOA connaissent finalement assez peu le métier pratiqué par l'entreprise ou du moins la partie de métier dont ils (sans vouloir leur en porter rigueur)
4 - le symptôme du MOE "qui connait mieux le besoin du client que le client"
Le MOE qui pense, sans le dire "Moi, je sais mieux que lui ce qu'il lui faut"
Alors que faire ?
Option 1 : Supprimer le rapport MOA - MOE. Faire des équipes mixtes où l'on ne distingue plus qui est client ni qui est fournisseur. Les deux construisent ensemble la solution logicielle.
Avantage : plus de conflits à court terme.
Inconvénients : ni le métier, ni les besoins ne sont mieux connus / partagés.
On a encore des conflits latents s'il s'avère que la solution construite en commun s'avère ne pas résoudre le besoin/problème initial.
Le système fabriqué est décidé non en fonction du besoin mais en fonction de ce qu'il est possible techniquement de faire => risque de passer à côté de fonctions nécessaires.
Option 2 :
La MOA modélise le métier avec les processus.
La MOE décline chaque activité/tâche du processus en fonction sur le système cible.
J'ai eu un jour l'occasion de réaliser une modélisation de processus alors que l'expression de besoin était déjà prête, et les spécifications générales aussi. Le processus était modélisé avec la même personne MOA qui avait fait rédiger le cahier des charges. On devrait donc s'attendre à un minimum de cohérences. J'ai donc proposé de croiser le processus, le CdC MOA, les specs MOE. Et bien vous me croirez si vous voulez : nous avons trouvé :
- des fonctions qui étaient demandées mais totalement absente du processus !
- des activités sans fonctions en CdC !
- des tâches réalisées toujours successivement, mais présentes dans les spécifications MOE comme des IHM distinctes et éloignées dans les menus, ce qui signifiait que l'utilisateur aurait à naviguer inutilement entre les écrans => mise en évidence de l'adaptation de l'ergonomie,
- des tas d'autres d'incohérences.
Il faut apprendre à la MOA à réaliser cette modélisation. Cela s'apprend. Franchement, ça vaut le coup d'essayer.
Il faut demander à la MOE de partir de cette modélisation pour définir les fonctions cibles.
Tout ceci donne à réfléchir...
Christophe Thiry
posted by Christophe Thiry @ 5/04/2006
8 Comments:
Je ne connais pas grand chose aux MOA, MOE et autres BPM mais j'aimerais réagir sur "Ce point de vue est souvent défendu par les promoteurs des méthodes agiles de type XP".
Il est souvent facile de justifier tel ou tel changement en disant "c'est parce que l'on applique telle méthode" même si le changement préconisé n'a pas grand chose à voir avec la méthode en question. C'est juste une histoire d'alibi.
Le travail de modélisation métier tel que décrit dans l'option 2 est exactement ce que l'on attend du "client" dans XP : raconter des histoires qui vont permettre aux développeurs de comprendre comment l'utilisateur travaille et ainsi développer le système correspondant.
S'il y a une différence, c'est plutôt dans l'existence d'un "rôle MOE" distinct des développeurs eux-mêmes. Une fois décrite la façon dont l'utilisateur travaille, je ne vois pas de quelle étape supplémentaire on a besoin avant de donner la main aux développeurs.
(cette dernière phrase est un peu de la provocation mais c'est pour la bonne cause...)
Bonjour, je vais essayer de te répondre point par point
A lire le §1, j'ai l'impression que tu t'es senti pas mal visé, alors que bon, on ne fait qu'échanger des opinions.
"Il est souvent facile de justifier tel ou tel changement ..." très franchement je n'arrive aps à comprendre le sens de la phrase. Tu es favorable à quoi, exactement ?
§2 "raconter des histoires qui vont permettre aux développeurs de comprendre comment l'utilisateur travaille" : Tant mieux si XP est sur la bonne voie. Cependant, la modélisation du processus métier va plus loin en formalisme (et à mon humble avis, en efficacité)que "raconter des histoires". Pour quelle raison ? Il te faut creuser le sujet !
§3 je ne pense pas avoir dit qu'il y ait un rôle MOE "distinct des développeurs eux-mêmes"
§3 "je ne vois pas de quelle étape supplémentaire on a besoin avant de donner la main aux développeurs"
Ce n'est pas de la provocation, c'est une bonne remarque ! Pour moi il ne s'agit pas d'une étape supplémentaire mais d'un étape préalable à la définition du périmètre d'une application, qui permet de modéliser le métier des acteurs de l'entreprise sur une échelle plus vaste que celle que tu observes en tant que développeur.
J'étais développeur et chef de projet avant d''être urbaniste. Je comprend à quel point il est difficile de "sortir du cadre"
Si tu ne vois pas l'intérêt de l'approche, je te conseille d'oublier un instant le métier de développeur d'applications et de t'intéresser à tout ce qui touche aux processus métier (qu'est ce que c'est , à quoi ca sert, etc.) de même que tout ce qui touche à la définition des rôles MOA/MOE puis de revenir plus tard à ton métier. Tu obtiendras une bonne complémentarité de points de vue.
Merci et à bientôt.
Merci pour ta réponse.
En fait je ne me suis pas du tout senti visé par la petite phrase sur les méthodes agiles. Je me suis juste demandé ce qu'elle venait faire là. La réalité, c'est que des personnes prennent des positions du genre "puisqu'on fait du XP alors ...." suivi d'une conséquence qui n'a pas forcément un lien avec XP ou les méthodes agiles en général. Ce sont ces gens là qui m'exaspèrent et il est fort possible que le point de vue défendu par certains promoteurs de méthodes agiles en rapport avec les roles de MOA/MOE tombe dans ce cas là (il faudrait un exemple plus concret...)
Vis à vis du formalisme et de l'efficacité de la modélisation du processus métier, je peux difficilement parler de quelque chose que j'ai n'ai jamais regardé de près (mais je promets que je vais creuser). Il y a une seule chose dont je suis sûr : il faut conserver la simplicité, c'est à dire l'art de ne pas faire des choses qui ne servent pas, comme valeur essentielle. Ce dont je ne veux pas (en bon partisan des méthodes agiles), c'est une trop grande emphase sur une documentation moyennement utile quand la vraie finalité est le système qui sera construit.
Maintenant, si un environnement relativement complexe avec de nombreux processus et de nombreux intervenants nécessite une modélisation plus formelle pour gagner en efficacité, je ne vois pas de mal à cela, bien au contraire. Une autre valeur essentielle de l'agilité, c'est la capacité à être réactif par opposition au suivi d'un schéma pré-établi. Celui qui ne prend pas le parti d'un plus grand formalisme lorsque le besoin est avéré, n'est pas "agile". C'est juste quelqu'un qui prend les méthodes agiles comme prétexte fallacieux pour ne pas faire un travail essentiel (et on retombe donc sur le 1er point relatif à la défense de certains points de vue).
J'enregistre le fait que le rôle MOE n'est pas forcément distinct des développeurs eux-mêmes. C'est un bon point. Par contre, je ne crois pas avoir compris ta réponse sur l'étape supplémentaire. Peut être ai-je mal formulé ma remarque ? Je ne remets pas du tout en cause le besoin de définition d'un processus métier.
En fait, l'étape supplémentaire que je ne comprends pas, c'est : "Il faut demander à la MOE de partir de cette modélisation pour définir les fonctions cibles."
Pour reprendre le cadre de ton "option 2", à quoi servent les "specs MOE" ? S'il y a tant de différences avec le cahier des charges MOA, en quoi développer directement avec le cahier des charges n'est pas une solution viable ? Un tel choix aurait au moins le mérite d'éviter la traque de contradictions entre 2 systèmes documentaires quand, en fin de compte, ce qui importe vraiment ce sont les contradictions entre le cahier des charges et les applications développées.
Pour comprendre les processus métier, je conseille l'excellent livre "L'Approche processus : Mode d'emploi" de Hans Brandenburg et Jean-Pierre Wojtyna.
Pour répondre rapidement sur le dernier point: côté MOA, le Cahier des charges contient le BESOIN, côté MOE, les spécifications contiennent la SOLUTION. C'est une bonne pratique de ne pas confondre les deux, pour des tas de raison.
Peux-tu m'indiquer une URL où l'on trouve une bonne explication des méthodes XP et en particulier leurs différences avec les méthodes de développement traditionnelles ?
Merci.
"Les spécifications contiennent la solution"
Je crois que là est la base du quiproquo. Dans une vision agile du développement, il n'y a qu'une seule solution : le système livré qui fonctionne. Aucun livrable papier ne peut être considéré comme une solution :-)
Pour ce qui est de points d'entrée sur les méthodes agiles, il en existe tellement que faire une sélection n'est pas vraiment simple.
- Agile Manifesto énonce les valeurs et les principes de base (oserai-je dire la philosophie ?) de manière très concise.
- un document en français qui date un peu mais présente de manière relativement honnête (1) les relations de certaines approches plus classiques avec les valeurs agiles ; (2) les forces et faiblesses de méthodes agiles plus ou moins répandues. Le document est assez long mais les sections de conclusion suffisent à avoir une bonne idée générale. (Je précise que je n'ai aucun lien avec la société qui a produit ce document)
En ce qui concerne XP proprement dit (qui n'est qu'une méthode agile parmi d'autres même si sa visibilité lui a donné un certain statut), je suis encore plus gêné pour donner un lien qui ne soit pas trop biaisé (à mon goût) par les aspects marketing.
- What is XP a le mérite d'être écrit par un des pères de la méthode
- Misconceptions est un bon complément explicatif au lien précédent ainsi que ce dialogue sur un ton plus humoristique.
La dichotomie MOA/MOE a au moins un mérite celle de présupposer un séquencement des études (Le quoi? avant Le comment?).
Bien-sur nous avons tous pu apprécier les modes itératifs (type RAD)... mais quand les itérations deviennent "synchrones" les pertes d'energie deviennent considérables!
Je découvre ainsi aujourd'hui un document de lancement de projet avec un propos tel que "Parallèlement à la définition des besoins sera définie l'architecture fonctionnelle et technique" ... et puis on défera à chaque occurence ... Faire et défaire...
L'avantage c'est qu'après le dérapage personne n'est responsable puisque tout le monde l'est!
Mon opinion est que si l'on vous demande de paralléliser contre votre gré des EdB, AF et AT, vous n'avez qu'une seule voie possible :
- exigez des versions/itérations distinctes des EdB qui vous arrivent,
- chiffez le temps passé sur les AF et AT et exposez ces coûts lors de votre reporting hebdomadaire (si vous en avez un),
- à cette fin mettez les versions et les coûts en correspondance dans un petit tableau, ce qui montre à chaque itération combien vous coûte d'entretenir en parallèle des AF / AT sur des EdB flottantes.
- Mettez aussi en avant les travaux que vous ne pouvez pas avancer du fait de ceux là.
En résumé, créez vous votre indicateur ad hoc et donnez de la visibilité au N+1.
Vous verrez, en général, si ca ne tombe pas dans l'oreille d'un sourd, le N+1 prendra seul les mesures sans que vous ayez à faire l'effort d'en dire plus.
Bon courage et merci pour votre participation.
CTH
Hello!
Nice site, keep up the good work .
http://buy-phentermine.hem.nu BUY PHENTERMINE
BUY PHENTERMINE
http://blog.sol.no/buy-phentermine
BUY PHENTERMINE
http://buy-phentermine.hem.nu buy phentermine
http://buy-phentermine.hem.nu phentermine online
http://buy-phentermine.hem.nu order phentermine
http://buy-phentermine.hem.nu cheap phentermine
http://buy-phentermine.hem.nu buy phentermine online
http://buy-phentermine.hem.nu phentermine diet pill
http://buy-phentermine.hem.nu phentermine online pharmacy
http://buy-phentermine.hem.nu phentermine prescription
http://buy-phentermine.hem.nu what is phentermine
http://buy-phentermine.hem.nu free phentermine
Enregistrer un commentaire
Links to this post:
Créer un lien
<< Home