L'ingénierie civile est aux méthodologies classiques ce que le foot est à l'agilité
Un article de Agile-Swiss.
Sommaire |
La mèche
J'ai lu récemment un article et une entrée de blog qui m'ont enfin décidé à parler d'un sujet qui sur la forme ne fait pas l'unanimité mais qui sur le fond me semble assez fédérateur:
les méthodologies Agiles aussi innovantes qu'elles puissent l'être sur certains points s'incrivent plus dans une évolution des méthodologies de développements qu'elles ne sont en rupture avec ces dernières.
Quelles 'anciennes' pratiques ne sont pas reprises ?
En effet au sein des méthodologies agiles nous retrouvons les termes gestion du risque, collecte des exigences utilisateur, analyse, design, gestionnaire de source, gestionnaire de bugs, tests fonctionnels, pattern, tests d'intégration, composant, UML, etc... En effet en XP, quand un développeur discute en tête à tête avec le client pour bien cerner sa user story il fait en fait un travail d'analyse. De même quand un développeur suit une approche TDD (Test Driven Development), chaque écriture de test est suivi d'un réflexion sur le design et ce n'est qu'ensuite qu'arrive le code. Contrairement à FDD (Feature Driven Development) qui est plus centré sur le modèle et qui par conséquent s'appuie massivement sur UML, XP est centré sur le code mais ne renie pas pour autant tout usage d'UML. C'est clairement désormais un language universel qui permet un meilleur dialogue entre développeurs et a facilité la diffusion des design patterns. La polémique porte uniquement sur l'utilisation d'UML de manière massive et systématique en amont du développement.
J'ai donc tendance à penser que les méthodologies agiles s'incrivent naturellement dans une évolution des méthodologies de développement. D'ailleurs ce qu'on appellent les méthodologies agiles (scrum, crystal, fdd, xp, dsm, asd, etc...) sont une suite assez cohérente et homogène de méthodologies qui sont apparues plus ou moins simultanément au milieu des années 90 sans liens apparents si ce n'est au travers des retours d'expérience de chacun suite à la mise en oeuvre de processus en cascades. D'ailleurs pour être totalement cohérent historiquement toutes ces méthodologies puisent leur racines dans la méthdologie RAD (Rapid Application Development) mise au point par James Martin au milieu des années 80.
La métaphore du soccer
Dire que les méthodologies agiles correspondent à une évolution naturelle des méthodologies de développement ne minimise pas pour autant leur intérêts et bien au contraire les crédibilise d'autant plus. Mais alors qu'apportent ces méthodologies agiles ? Dans Scrum (le terme signifie mêlée de rugby) la métaphore avec le fonctionnement d'une équipe de rugby ou de foot est souvent utilisé et je vais le reprendre car elle me semble relativement parlant. Elle pourra parraître assez caricaturale à première vue mais merci d'y réfléchir à deux fois:
Analyse
Admettons que vous êtes entraineur d'une équipe de foot. On vous a assigné comme objectif d'année de terminer dans le haut du classement. On vous impose une partie des joueurs de l'équipe et vous recrutez les joueurs pour les places laissez vacantes. En suivant une méthodologies de développement classiques vous allez analyser la situation , définir un budet de fonctionnement pour l'année, vous encadrez d'un préparateur physique, d'un nutritioniste, éventuellemnt d'un adjoint, demander de nouveaux locaux, bref mettre en place un cadre de fonctionnement le plus adéquat possible. Comme vous savez de plus qu'il vous sera plus difficile en cours d'année de justifier de telles demandes vous chargez un peu la mule en demandant également un masseur et un préparateur mental.
Planning
Il vous faut maintenant établir un planning de progression qui sera votre fil rouge durant toute l'année et qui permettra de comparer la progression réelle de l'équipe aux prévisions. Comme vous ne connaissez pas les joueurs et encore moins vos adversaires, vous définissez un planning un peu défensif qui consiste à dire que le premier trimestre est avant tout un trimestre à la fin duquel l'équipe devra avoir trouvé ses automatismes. Par conséquent l'objectif du premier trimestre est avant tout de rester en milieu de tableau. Progressivement au fil des deuxième et troisième trismestres l'équipe remontra lentement mais surement jusqu'au premières places.
Design
Là c'est la phase de l'orgasme intellectuelle où tous les schémas stratégiques élaborés, ressassés, affinés depuis de nombreuses années et bonifiés d'une expérience assez conséquente peuvent enfin voir le jour. On part sur du 4-4-2 avec des arières latéreaux offensifs. Le libéro et le stoppeur fonctionneront en binôme interchangeable. On part sur deux milieux défensifs, voir très défensifs et par contre le numéro 10 sera le poumon offensif. Bref, un truc state-of-the-art qui recueille sans problème l'unanimité. Bon pour que tout ça soit le plus clair possible, vous rédigez un document qui explique au brin d'herbe près comment tout cela fonctionne. En annexe on trouve également le descriptif précis de chaque poste et vous donnez tout cela aux joueurs qui sont plutôt satisfaits de la tournure que prend l'aventure.
Développement
Arrive donc les premiers matchs, l'équipe n'est pas ridicule du tout mais perd néanmoins plus de matchs qu'elle n'en gagne. On arrive donc à la fin du premier trimestre avec un tout petit peu de retard par rapport à l'ordre de marche mais rien de trop grave. Si on se retourne sur ce premier trimestre, on constate que les joueurs ont bien un bon potentiel, la stratégie est bonne c'est indéniable, mais il manque ce petit truc qui fait que la mayonnaise monte. Pas de panique, on laisse passer les vacances de Noël et avec une équipe fraiche on va tout casser.
Le deuxième trimestre commence donc mais le déclic annoncé se fait toujours attendre. Fait surprenant, on a également quelques joueurs qui commencent à montrer des signes d'énervement sans d'ailleurs savoir eux-mêmes l'origine de ce mal-être. Ils s'entendent plutôt bien avec les autres joueurs, la stratégie est bonne mais le fait est qu'ils ont du mal à s'épanouir pleinement. Bon après tout c'est la vie, l'homme doit savoir dompter dès son plus jeune age la frustration et il faut que ces joueurs arrivent à prendre sur eux.
On démarre donc le troisième trimestre dans un état un peu critique, la pression monte mais finallement pourquoi tant s'inquiété puisqu'un processus cartésien et bien travaillé est rigoureusement suivi, ça va bien finir par payé! Le président du club fait néanmoins usage de son pouvoir absolu pour imposer un nouveau numéro 10 recruté à prix d'or histoire d'être sûr que la machine redémarre virilement. C'est le sixième du chef qui vient de se manifesté.
Au final le troisième trimestre se termine comme le premier: pas de catastrophe (j'ai volontairement pris un exemple optimiste ;-) mais les objectifs sont loin d'être atteints et pourtant on a eu un budget de fonctionnement nettement plus important que les trois premières équipes du championnat.A ce stade on a six attitudes de management possible: la méthode couet: ça ira mieux l'année prochaine, la méthode bowling: on change l'entraineur et une partie de l'équipe, la méthode tétue: la stratégie n'était pas bonne on en prend une autre, la méthode capitaine flam: je fais appel à un cabinet d'audit qui va m'indiquer que LA stratégie a adopter n'est pas exactement celle là, la méthode responsable: qu'est ce qui n'a pas marché ? Toutes les méthodologies agiles sont parties de cette question: qu'est qui n'a pas marché ?
Le soccer est une activité humaine et complexe
organisation auto-adaptive
La première réponse à cette question consiste à dire qu'on aurait du se poser la question beaucoup, beaucoup plus rapidement. Car après tout quelle est le principal risque sur un projet si ce n'est qu'il ne remplisse pas ses objectifs ? Il faut donc résussir à minimiser le plus possible ce risque principal en découpant le projet en un maximum d'itérations qui se terminent toutes par un période d'évaluation (le sacro-saint feedback). Chaque itération doit porter sur des points parfaitement visibles et quantifiables. Si nous reprenons notre premier trimestre, nous allons le découper en trois itérations d'un mois. Durant le premier mois nous allons nous focaliser principalement sur les aspects défensif: fonctionnement du binôme libero/stoppeur, replacement des arrières latéraux, positionnement des milieux défensif, et rôles préventif des attaquants. Si à la fin du premier mois on a un feedback négatif sur un de ces points c'est qu'il a danger et qu'il faut donc s'adapter. La notion d'adaption est essentiel mais n'est pas naturelle dans une méthodologies de développement classique. En effet on compare depuis trop longtemps les processus de développement à l'ingénierie civile. Or quand on construit un pont, l'ensemble du problème est parfaitement connu à l'avance et il n'y a jamais à s'adapter, voir c'est d'ailleurs un non sens. L'erreur qui est faite dans cette comparaison à l'ingénierie civile c'est que le contexte dans un projet informatique est quasi toujours évolutif et possède souvent des zones d'ombres: la dernière version de jBoss va-t-elle tenir la charge, doit-on opter pour l'AOP, on part directement sur EJB 3.0 que personne ne maîtrise encore totalement en interne, le client n'a pas encore spécifié une grappe de fonctionnalités, etc... Face à cette complexité qui ne cesse d'ailleurs de croître, les méthodologies agiles recommandes l'adoption de techniques qui permettent de rendre le processus auto-adaptif et là je reprends directement le manifest agile:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Si nous revenons sur notre parallèle avec le football, au bout d'un mois si la charnière centrale n'arrive pas à se mettre en place c'est qu'il y a un problème. Or comme ce problème peut être relativement complexe: problème de confiance en soi du libéro, manque de capacité de replacement du stoppeur, arrière latéraux tellement offensifs que la charnière centrale tend à se disperser, etc... il est essentiel de permettre à tout le monde de s'exprimer sur le sujet et de proposer des solutions. Si la conclusion à la fin de se brainstorming consiste à dire que le fonctionnement en binôme du couple libéro / stoppeur n'est pas adapté à l'équipe et bien on change de solution tactique sur ce point même si c'est pour revenir sur une solution plus simple. La plus part des pratiques XP répondent justement à ce besoin d'adaptation au contexte.
Prise en compte de la dimension humaine
--
Freddy
