Agile et Lean Développement

Les organismes officiels commencent à s’impliquer : les publications sur les méthodes Agiles vont devoir respecter un minimum de principes et d’éthique.

ADELI (http://www.adeli.org/), (Le comité de lecture d’ADELI, Association pour la maîtrise des systèmes d’information) publie dans le numéro 76 (été 2009) de  La Lettre  la communication de Jean-Pierre Vickoff sur l’évolution des cycles de vie et des méthodes, intitulée Du Prédictif à l’Adaptatif.

Le comité de lecture de l’AFIS, Association Française d’Ingénierie Système (http://www.afis.fr/), a programmé la communication de Jean-Pierre Vickoff intitulée, PUMA Essentiel Processus Urbanisant les Méthodes Agiles pour sa 5ème Conférence Annuelle d’Ingénierie Système à PARIS, les 23, 24 et 25 septembre 2009 (INCOSE International Council on Systems Engineering).

Je présente (JPV), pour approbation, à Agile Tour 2009, une communication écrite en Anglais sur PUMA (Process Unifying Methods of Agility, A toolbox dedicated to application development (http://www.agiletour.org/fr/at2009_callforpapers.html).

Je la présente aussi, pour approbation, à Agile Tour 2009 Paris

N’étant pas concurrent en matière d’offres de services, je propose de me déplacer pour réaliser gracieusement cette conférence dans les autres villes dont les comités d’organisation le souhaiteraient (simplement me contacter par mail à Vickoff@noos.fr).

Journal du Net > Développeurs > Tous les quiz > 

Note : Je n’ai absolument pas participé à la construction de ce questionnaire. 

Je viens de me rendre compte que mon adaptation de la métaphore de la Joconde de Jeff Patton (qui illustre l’aspect adaptatif dans mon dernier livre), n’était pas claire pour tout le monde. Je viens donc de la modifier en conséquence : http://www.entreprise-agile.com/HistoAgile.pdf Cette éclaircisement est d’importance puisque c’est ce principe qui permet de traiter des forfaits en mode Agile (aspect qui semble toujours incompris de pas mal de gens).
 

Au-delà des apparences : conforme aux nouveaux besoins

Entre les statistiques publiées, une solide base de projets ayant permis de calibrer Evaluateur en son temps http://www.rad.fr/eval2000.htm (à Hydro Québec j’ai supervisé jusqu’à plus de 60 projets simultanément) et mes expériences de consultant méthode de ces dernières années, j’en arrive à la conclusion qu’en termes de besoins :
- seuls 18% des applicatifs auraient été en mesure d’être définis précisément en début de projet;
- environ 22% des applicatifs étaient en mesure d’être abordés sans structuration des exigences en début de projet.

En clair, vouloir fixer un périmètre complet et détaillé  pendant une phase d’exploration est une erreur aussi sérieuse que de vouloir se passer de l’indispensable réflexion qui doit précéder l’action. Les échecs de projets itératifs liés à cette faute d’appréciation font courir le risque de voir cantonner les méthodes Agiles actuelles à des petits développements avec un nombre très limité d’utilisateurs.  Dans ce cas, il est d’ailleurs intéressant de se demander à quel moment, comment et sur quelles bases, se ferait l’arbitrage budgétaire conduisant à lancer le projet.  

Je viens de tomber sur un article traitant de l’agilité. Il s’intitule « Un contrat réaliste ». Je pensais que l’on y parlait de droit appliqué à la métrique du changement de périmètre en cours de projet. En fait, on y trouve des réflexions intéressantes sur la profonde bonté de l’âme humaine appliquée à la gestion de projet.

On peut y lire cette déclaration : « la rémunération du fournisseur étant directement liée à la satisfaction du client ». Voici deux ou trois semaines sur BFM j’ai entendu un autre son de cloche. L’interviewé, un patron de SSCI se présentant comme un Scrum Master, répondait à la question « comment gérer vous le changement » par « le client change ce qu’il veut et on le facture en avenant ».

En ce qui concerne la contractualisation des projets Agiles, il ne faut pas rêver sur l’ingénuité des relations clients / fournisseurs. Pour s’assurer de maîtriser les conflits potentiels liés aux évolutions, la seule option réaliste consiste à mettre systématiquement en œuvre une mesure immédiate et tracée de chaque changement qualifié par ses causes. Cette gestion s’effectue sur le radiateur d’information.

Une bonne explication juridiquement et commercialement acceptable vaut tous les nouveaux rêves et anciens cynismes. Les deux explications laissent néanmoins à penser qu’il y a encore pas mal de chemin à parcourir pour que les pratiques contractuelles  Agiles s’appuient sur des fondements évolués, mais réalistes.

Je viens de m’apercevoir que la structure de PUMA Essentiel est perçue par certains comme composée de 4 phases. Il n’en est rien. PUMA Essentiel ne comporte nativement qu’une phase semi-itérative. Un nouveau graphique permettant de visualiser l’imbrication des éléments principaux le montre un peu mieux : http://www.entreprise-agile.com

Le moteur de Solution, par exemple, n’est pas une phase mais un modèle itératif de structuration des exigences. Il est mis en œuvre (si nécessaire) dans le cadre du moteur de Communication, lequel n’est pas non plus une phase mais lui aussi un modèle itératif de facilitation de la communication en environnement sensible.Le moteur de Pilotage spécialisé dans la conduite itérative incrémentale du projet est le seul élément pouvant être apparenté à une phase. Imbriqué dans cette phase, un moteur de Réalisation pouvant, dans le cas d’un développement spécifique, être basée sur XP ou sur une structure moins extrême, n’est en fait qu’une simple boite à outils composée des meilleures techniques actuelles de développement.

C’est terrible d’avoir toujours 10 ans d’avance !

Au début des années 90,  j’ai du me battre contre la modélisation lourde et la conduite de projet  « cascade » dont la représentation en France s’appelait Merise. A l’époque la méthode RAD (1991) semblait anarchique car elle proposait un périmètre variable, un cycle itératif incrémental, l’adaptation permanente par la validation de l’utilisateur,  la présence recommandée d’un animateur-facilitateur, une War Room, une équipe relativement autonome (SWAT), l’affichage mural et quelques autres folies pour l’époque. Enfin, tout ce qui fait une bonne méthode Agile aujourd’hui.
Les merisiens me tombèrent dessus.

Les méthodes Agiles apparurent, soit en directe émanation du RAD comme DSDM (1995) ou FDD, ASD, soit en “pompant” la totalité de ses techniques sans le référencer comme Scrum (1996), soit en apportant un plus d’usage comme XP (1999).

Dix ans après RAD, en 2002, en réponse au Manifeste Agile, je proposais PUMA pour l’Unification des méthodes Agiles sur la base de leur complémentarité. On trouve toujours ce document  en anglais à partir du wiki de  Ward Cunningham (http://c2.com/cgi/wiki?PumaProposal) et en français sur le site d’ADELI (ftp://ftp2.adeli.org/adeli/lalettre/l48p19.pdf). Cette proposition “pour le plaisir”, que je savais commercialement impossible, se transforma en simple principe d’urbanisation, puis récemment en méthode publiée.  

Nous ne sommes pas encore 10 ans après, mais déjà les méthodes Agiles commencent à mettre en œuvre les principes de PUMA en regroupant informellement  leurs approches incomplètes sur la base du choix de la technique utile au contexte.

Et évidemment les scrumistes me tombent dessus.

A chaque décennie je me fait crucifier ! 
Ah décidemment, c’est terrible d’avoir toujours 10 ans d’avance!

Comme une bonne partie des présentations des sources du mouvement Itératif, Incrémental et Adaptatif dont les travaux ont conduit au manifeste Agile sont biaisées, lorsque ce n’est pas trafiquées par des révisionnistes ou des incultes, je vous en réalise une retrospective dont les dates sont officielles :
 http://www.entreprise-agile.com/HistoAgile.pdf 
Et voici aussi un petit résumé des controverses en cours :
http://www.entreprise-agile.com/AgileControverses.pdf

Suite à un échange avec FrédéricTardieu concernant Scrum :
http://www.frederictardieu.net/?cat=25&lang=fr
J’ai tenu à lui donner mon opinion.  Après avoir lu The New New Product Development Game ou tous les principes fondateurs de Scrum étaient exposés (y compris la métaphore du rugby) et après avoir pris en considération les techniques du RAD largement publiées qui préexistaient, on se demande vraiment quel à été l’apport technique de Scrum à la conduite des projets de développement d’applications.  

J’ai eu la chance (pour le côté expérience) de travailler dans des sociétés utilisant le cadre CMM (Software) et d’autres un cadre Agile. J’ai aussi réalisé pour le Gartner Group en 1998, la première synthèse de CMM en français à partir des travaux du Québécois Richard Basque. Puis un comparatif entre CMM et RAD qui avait conduit à la production pour le Gartner d’un processus formel RAD2 de niveau 5. Plus récemment, l’année passée, des organisations professionnelles de l’Ouest français m’ont commandé une étude-conférence  sur le sujet Agile / CMMi.

Ma conclusion : Même si -certaines- pratiques sont communes, l’approche Agile représente à l’évidence la philosophie contraire de celle qui sous tend la normalisation et CMM (même abordée comme dans CMMi light, un livre que je conseille à tous ceux qui souhaitent parler du sujet en sachant agilement de quoi il en retourne). D’ailleurs ma blague de conférencier sur le sujet :

CMM : Nous déclarons que la qualité d’un produit logiciel est intimement liée à la qualité de son processus de fabrication. C’est pourquoi nous mesurons la conformité de ce processus (Watts Humphrey).

AGILE : Nous déclarons que la qualité d’un produit logiciel est intimement liée à la qualité de ce produit logiciel. C’est pourquoi nous mesurons la qualité de ce produit logiciel  (Jean-Pierre Vickoff).

Bien qu’un mappage permet de comprendre les aspects techniques sans résoudre les problème fondamentaux,  j’ai énormément apprécié la vision d’un praticien qui ne se contente pas de blabater des généralités.

Lien sur Granit CMM / Agile

Evidemment c’est aussi une question de niveau. Le niveau 2 n’est peut être pas incompatible avec XP (mais pas pour Scrum qui ne dispose pas de technique de génie logiciel). Par contre au niveau supérieur, dès que le besoin d’un processus formalisé apparaît, les méthodes Agiles ne proposent plus rien. Ensuite au niveau 4 pour les métriques et 5 pour les rétrospectives, certaines pratiques de Scrum, une fois formalisées, feraient certainement l’affaire, du moins dans la limite d’un projet donné. Malheureusement une organisation ne se certifie pas CMM L5 pour voir ses processus remis en question en temps reéel dans un projet particulier. Sous l’angle de la complexité et de la courbe d’apprentissage,  il est aussi évident que l’observation de CMMi (même dans une vision Light) découragera immédiatement plus d’un Agiliste. Sinon, dans l’optique de monter une usine à gaz « comme au bon vieux temps », il est toujours possible de  multi-coupler CMMi, CMM-Personal SP, CMM-TeamSP, Scrum, XP et quelques techniques de gestion des exigences structurées ou de modélisation systémique dans le cas d’un BPM  ou technique dans le cas d’une SOA.

Mais le vrai problème ne se situe pas dans les aspects techniques. Il en coute des milliers (voir des dizaines de milliers) d’euros afin de devenir certificateur CMM et ce fric alimente une pyramide financière (en comparaison, Scrum est un regroupement d’enfants de chœur) dont les instances tiennent à la continuation. D’autre part (d’expérience) une société qui va investir dans du conseil CMM souhaite que ce consultant la certifie au final et ne prendra pas autre chose qu’un certificateur . Lorsque le SEI aura créé CMMa  (pour Agile) en acceptant quelques techniques Agiles dans trois ou quatre secteurs, la messe sera dite. Les entreprises achèteront massivement la sécurité d’un processus mature se référant de l’agilité. Surtout celles ayant déjà investi dans CMM SW ou CMMi. Plus de rupture organisationnelle, la continuité tranquille.  Quelle place restera-t-il au mouvement Agile basé sur des approches imparfaites, incomplètes, formant ses experts en 2 jours et qui, en plus,  se refuse à évoluer autrement que dans les détails de techniques insignifiantes pour la plupart des DSI  ?