Pas de crise pour l’Agilité

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

Le comité de lecture d’ADELI, Association pour la maîtrise des systèmes d’information (http://www.adeli.org/), 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) (http://guest.cvent.com/EVENTS/Info/Custom.aspx?cid=38&e=a6241dd6-45d8-4661-a5ee-d2a376f918ac).

Dans de nombreuses villes, de divers pays, en octobre 2009, vont se tenir des communications, des conférences, des ateliers …

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 présente aussi, pour approbation, à Agile Tour 2009 Paris (http://www.agiletour.org/)  (accessible par mon lien direct personnel :  http://www.agile-france.com/) une conférence sur PUMA Essentiel, un framework Agile de pratiques organisationnelles, d’expression structurée des Exigences, de formes avancées de communications, de techniques de pilotage applicables à tous types de projets et de pratiques de génie logiciel.

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).

  • Comments Off

Testez vous sur les méthodes agiles

Journal du Net > Développeurs > Tous les quiz > 
http://www.journaldunet.com/developpeur/questionnaire/fiche/10073/d/f/1/

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

MAJ de la base < Pratiques Agiles >

Mise à jour de la base de pratiques Agiles.
http://www.entreprise-agile.com/Base/News.htm
Après la fiche Récit qui présentait le travail de Jean-Claude Grosjean sur les “Récits utilisateurs”
c’est au tour de Yannick Quenec’hdu avec la fiche “Jeux d’estimation”

Le 6 Avril c’est Création d’une fiche  (Reporting Agile : état du réalisé) avec le graphique de reporting sophistiqué d’un projet majeur proposé par Frédéric Tardieu.
  • Comments Off

Petit voyage aux sources du pouvoir et du savoir

Enfaisant du ménage numérique je viens de retrouver un livret : Constat des divergences en termes de formes de management et tentative de mise en évidence de leurs origines géographique, culturelle et religieuse. Un petit voyage aux sources du pouvoir et du savoir écrit par Jean-Pierre Vickoff avec pour base de réflexion une expérience professionnelle concrète d’une trentaine d’années sur les deux bords de l’atlantique.  http://www.rad.fr/managil.pdf
  • Comments Off

Réorganisation de mes sites

Un résumé se trouve en bas de mes principaux sites. Des nouveaux sites en construction apparaissent :
http://www.agile-entreprise.com/http://www.agile-francophone.org/ , Methode-Agile.eu et Méthode-Agile.fr.
Si on ajoute que je dois complèter la base de pratiques  http://www.entreprise-agile.com/Base/0Arrive.htm,
produire les données de http://www.mymethode.com/,  réécrire et produire le Livret PUMA Essentiel, envoyer les 2000 bouquins “Méthode Agile” (dont la couverture à du être refaite), plus deux ou trois autres tâches du genre, autant dire que je peux travailler jour et nuit durant une année sabatique !
Dans deux semaines je présente le courant organisationnel de pensée Agile et  PUMA Essentiel  à une cinquantaine de DSI qui m’ont invité pour un point sur les limites des méthodes Agiles actuelles. Plusieurs autres associations françaises viennent aussi de me contacter sur le même sujet. Mais ça, c’est la récompense.
  • Comments Off

Terrible d’avoir 10 ans d’avance

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!

 

XP Days 2009

Les XP Days 2009 ressemble  à la caverne d’Ali Baba

 

XP (eXtrem Programming), la plus sérieuses et techniques des méthodes Agile  semble avoir perdu la partie face à l’envahissement de Scrum dont les certifications de complaisance sont la cause des controverses actuelles aux USA sur l’Agilité et de la totalité des échecs de projets Agiles rapportés.

 

Après avoir été incomplet, controversé, le message Agile devient relativement illisible et hétérogène observé de l’extérieur.

 

 

En tous cas, cette évolution confirme la justesse de ma vision et son aboutissement concret dans PUMA Essentiel.

 

En effet, la fusion des pratiques, qui devient évidente, n’est rien d’autre que le principe basique de PUMA Essentiel sans malheureusement sa simplicité et son homogénéité.

L’avantage de PUMA, c’est l’urbanisation et la formalisation existante de cette évolution.

 

La couverture méthodologique de PUMA règle une grande partie des problèmes actuels mis en évidence.  De plus, les nouvelles techniques qu’il propose sont porteuses d’une capacité d’élargissement de l’Agilité aux grands projets et aux couches supérieures de l’organisation.

 

____________________________________________________________________________
Petit rappel d’anciens messages techniques ayant disparu de la première page :

Comparatif Scrum, XP, PUMA  http://agiles.blog.com/2952126/
Le Mythe du périmètre variable 
http://agiles.blog.com/2501821/
Le mythe de l’itératif sans concession 
http://agiles.blog.com/2854726/

  • Comments Off

PUMA ne comporte qu’une phase

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.

  • Comments Off

Contractualisation des projets Agiles

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.

  • Comments Off

Suite de l’itératif sans concession

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.  

Calendar

May 2012
M T W T F S S
« Jul    
 123456
78910111213
14151617181920
21222324252627
28293031  

Tags