Principes de l'Extreme Programming : autosimilarité

Le quatrième principe XP est celui de l'autosimilarité. Ce principe est celui de la copie de ce qui marche, à différents niveaux, dans différentes situations.

• Le Client spécifie des tests pour se rassurer quant à la réalisation,
• Le Développeur spécifie des tests pour se rassurer, de la même façon.

Kent Beck exprime l'autosimilarité dans XP :

• Les besoins du métier sont raffinés en Histoires d'utilisation
• Ces histoires se traduisent en tests-client
• Ces tests-client sont alors réalisés, adressés par le produit.

Une carte bristol ou un post-it sont utilisés pour rédiger les histoires, de la même façon, ces otils peuvent être réutilisés dans d'autres situations : tests-client, activités de l'équipe...

D'une certaine manière, le codage d'objets métier est une autosimilarité : les relations qui existent vraiment entre objets réels du métier se retrouvent dans le codage.

Les fractales sont un exemple d'autosimilarité. 

Scrum de scrum est aussi une autosimilarité.

Couverture aérienne, une pratique du manager XP

Dans XP, la notion de "chef de projet" au sens habituel disparait. En effet, l'équipe s'auto-gère et plusieurs pratiques de management, bien plus contraignantes et disciplinées que dans la plupart des projets, sont mises en place, du stand up meeting quotidien aux réunions de planification de releases. Le Coach XP est là pour susciter, déclencher, provoquer, aider... pas pour manager.

Principes de l'Extreme Programming : bénéfices mutuels

Voici le 3ème principe de XPv2 : bénéfices mutuels. Ce principe, que l'on pourrait aussi nommer Gagnant - Gagnant, consiste à mettre en place une collaboration dans laquelle chacun trouve réellement un avantage : les organisations bien entendu (l'organisation ou le service "Client" d'une part, l'organisation ou le service réalisteur - informatique d'autre part) ; également les individus eux-mêmes.

Un pré-requis, à mon sens, de ce principe - et donc de XP - est de s'entendre sur un ensemble de valeurs communes.

Les valeurs de l'Extreme Programming sont :

• Communication
• Feedback
• Simplicité
• Courage
• Respect.

Principes de l'Extreme Programming : Economie

Après l'Humanisme - premier des principes de l'Extreme Programming - voici l'économie. Produire un logiciel, c'est produire de la valeur ajoutée. Au delà de l'aspect "retour sur investissement" du produit informatique, la rapidité de cette valeur ajoutée est aussi un aspect d'XP. 

Les demandes du "métier" - les exigences - sont des histoires d'utilisation en XP. Chacune de ces histoires est caractérisée par la valeur ajoutée qu'elle apporte.

La science de l'économie - en Extreme Programming - s'appuie sur deux leviers :

1. Livrer rapidement et fréquemment la réalisation des histoires qui offrent le plus de valeur ajoutée, c'est ce qui est obtenu par la planification des versions ( de l'ordre du trimestre), des itérations (de l'ordre de la semaine).
2. Retarder les investissements non évidents, investir uniquement lorsqu'ils offrent un retour sur investissement clair et au plus tôt ; ce qui est atteint par la conception émergente.

Humanisme et science de l'économie sont les deux premiers principes d'XP.

Principes de l'Extreme Programming : Humanité

Le premier principe de XPv2 est Humanité. Un software est développé par des personnes, pour d'autres personnes. Le facteur humain est donc primordial. Or, le développement du logiciel s'inscrit dans un cadre qui est l'organisation elle-même (ou parfois l'organisation du Client et l'organisation des Développeurs). Il s'agit donc de considérer les besoins des personnes et les besoins de l'organisation, ces derniers étant déclinés d'une certaine manière dans les variables du projet (budget, planning, périmètre, qualité).

Bien que la pyramide des besoins de Maslow soit sujet de controverse*, elle nous donne une première approximation des besoins des membres de l'équipe de développement :

• Client ou Product Owner
• Managers
• Développeurs et plus généralement Réalisateurs.

Les besoins de sécurité, d'accomplissement, de progression, de sentiment d'appartenance sont bien réels et plus ou moins prégnants suivant les personnes. Si le produit dont nous parlons (qui est l'une des nombreuses déclinaisons de système à forte composante logicielle) est le résultat d'une activité essentiellement humaine, il devient clair que ces besoins devraient être pris en compte - et adressés - pour améliorer la qualité du produit.

Un coach XP, tout comme un ScrumMaster, assume un rôle particulier dans une équipe. Il s'assure que tout est mis en œuvre pour le bien-être des acteurs du développement, du Client au Développeurs.

Un volet tout aussi passionnant est la relation entre Product Owner ou Client et Utilisateurs. Là encore, l'humain est primordial. Dans cet ordre d'idée, l'un des principes agiles préconise un rythme viable pour tous :

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Une livraison par semaine peut être viable - durable à long terme - pour l'équipe qui développe... et insupportable pour l'équipe d'exploitation ou les Utilisateurs eux-mêmes. Ce principe agile, décliné en pratique Rythme viable est une déclinaison concrète du principe XP d'Humanité.

Pour terminer, nous retrouvons ici la première valeur agile :

Si les processus et outils sont importants, les personnes et leurs échanges le sont encore plus.

* Les controverses portent sur les priorités des besoins selon les individus, également sur la distinction entre besoin et désir. Voir par exemple Théorie des besoins.

Humilité ?

L'Humilité est une qualité, une valeur, présente dans certaines approches agiles : Extreme Programming ou Agile Modeling en particulier. Dans XPEv1, Kent Beck écrit, à propos de l'intervention d'un manager en cas de problème :

... Rather, it is time to come to the team and say "I don't know how I let it get like this, but now I have to do XXX... Humility est the rule of the day for an intervention.

Attention toutefois à la définition de l'humilité que l'on se donne dans une équipe. Loin des définitions un brin teintées de culture judéo-chrétienne (voir par exemple le wiktionnaire), l'Humilité est simplement cette qualité qui consiste à dire que nous en saurons demain plus qu'aujourd'hui sur notre boulot, que l'on soit Développeur, Manager ou Product Owner. C'est une force et non une faiblesse. C'est cette capacité à changer notre savoir-faire, à s'améliorer. C'est le pouvoir de changer la vision du produit et de son développement et non pas seulement nos pratiques.

L'humilité est inhérente à l'agilité. Elle est une condition sine qua non des rétrospectives, des mises en œuvre du principe agile :

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Ainsi, nous devenons plus naturels, moins formatés par des attitudes convenues. Plus libres, nous devenons meilleurs.

Ah... les process !

ADSL en panne... Aïe aïe aïe...
Deuxième coup de fil au "service technique". Une personne à la voie charmante répond :
- Bonjour, je suis... Quel est votre problème ?
- ... Pas de connexion depuis quelques heures. Après mon premier coup de fil, j'ai testé la box comme demandé par votre collègue et elle fonctionne.
- Combien de prises de téléphone avez-vous ?
- ??? Euh... Tout marche bien sans aucune modification, j'ai testé la box chez un voisin et elle fonctionne...
- [imperturbable] Avez-vous une rallonge ?
- [Bon... C'est pas gagné pour aller direct à la solution...] Ben non, tout fonctionnait et il n'y a pas eu de modif.
10 minutes plus tard.
- "Cela doit venir de la ligne" conclut la voie charmante.

Sensation désagréable. Visiblement, cette personne (qui n'est pas en cause elle-même bien entendu) déroule un protocole établi. Vous pouvez dire tout ce que vous voudrez, le protocole se déroule. Ce n'est plus un dialogue entre êtres humains capables d'adaptation en fonction d'un objectif donné. L'adaptation a été prévue dans le process. Point final.

Je peux comprendre la nécessité de questions de base. Un peu comme dans un système expert d'aide au diagnostic. Le problème c'est qu'il n'y a pas de différence d'intelligence ici entre un système expert et un être humain. Si ça se trouve, une hot line sera dans quelques mois automatisée :
- vous avez une rallonge, dites "rallonge"
- vous n'avez pas de rallonge, dites "oh que nenni"

Un process trouve sa valeur dans sa capacité à atteindre un objectif. Malheureusement, à force de mettre l'accent sur "les process" on perd de vue l'objectif.

Dans une approche agile, nous nous focalisons sur les pratiques, sur la chasse aux gaspillages, sur l'objectif qui est de livrer rapidement et régulièrement un produit qui fonctionne. Bien entendu, ces pratiques, regroupées, forment des process. Par exemple :

• Gestion des exigences,
  
• Gestion du planning,
• Développement (cycles très courts de TDD)
• ...

Si le contexte le demande, les process sont rédigés (type ISO 9000 v2000 par exemple). Ils sont obtenus par compilation de pratiques.

Par ailleurs, l'une des pratiques constitutives de l'Agile est l'amélioration continue, via les rétrospectives en particulier, voir le Manifeste Agile

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Ajuster les comportements consiste à faire évoluer les process. Une attention particulière est donc portée sur le contenu du plan qualité et son process d'évolution.
Dans cet ordre d'idée, cet autre principe agile résume bien ce que peut être un process dans une approche "agile".

Simplicity--the art of maximizing the amount
of work not done--is essential.

Logiciel ou... software ?

Il existe une différence entre agile et Extreme Programming. Si XP peut être représenté (XP v1 du moins) par ces trois fameux cercles de Ron. Jeffries, l'Agile se concentre sur le premier, tout comme Scrum d'ailleurs : 

• livraisons fréquentes
• équipe complète
• tests-client
• Planning game ou planning process :  la planification pilotée par la valeur ajoutée de chaque user story, l'optimisation de cette V.A. plus précisément.

Or, XP va beaucoup plus loin, le produit est de la pâte à modeler qui s'adapte, via TDD + Conception émergente + Refactoring, aux besoins avérés. C'est YAGNI au niveau du produit. Et de ce point de vue, le  nom software me semble plus réaliste que logiciel,  cartésien, c'est à dire inhumain.

Le soft n'est pas le hard. Et malheureusement, bien des cycles de vie de production de soft se calquent sur des cycles de production de hard. Quel dommage !

Agile... ou pas ?

Un lien vers un billet posté sur le site de l'asso SIGMAT : Agile... ou pas ?
Que signifie "être agile" ? Comment juger de la pertinence, de l'efficacité, de l'agilité si elle n'est pas véritablement déployée ?

L'agilité consiste en un changement de vision, de perception de ce qu'est un logiciel, de ce qu'est un "projet" de développement, de ce qu'est notre rôle dans ce "projet". Cela ne se fait pas simplement en le décretant ! D'où l'importance de bien démarrer, de bien comprendre les enjeux, les changements et la conduite de ces changements.

l'Association SIGMAT

L'association SIGMAT est née. Vous souhaitez participer, partager vos expériences... et vos questions sur les méthodes agiles et leurs pratiques ? Consultez le site de l'asso.

Expression de besoins agile

L'expression de besoins est une activité essentielle du développement. Que la méthode soit agile ou non, la qualité de cette expression est une clé de la réussite du projet.
En approche "agile", l'expression de besoins est reconnue comme une activité qui peut perdurer tout au long du projet, plus encore, l'agile reconnait au Client ou Product Owner le droit de changer de spécifications sans que cela soit un drame. Dans cet ordre d'idée, le feedback d'un système opérationnel est une aide conséquente pour le Client.

Une approche agile peut s'appuyer sur des user stories ou encore sur une approche agile "cas d'utilisation". La pierre angulaire est l'environnement, le contexte.

Ce texte présente un exemple d'expression de besoins, basée sur la technique des cas d'utilisation, employée via des tableaux, dessins, documentée, sur demande par du Client par un modeleur.
http://etreagile.thierrycros.net/useCaseEfficace.html

Credit photo : http://www.sxc.hu/photo/695464

Planification agile : quand Scrum et XP s'entraident

Scrum apparait en 1996, avec une idée simple : si le développement d'un système est imprévisible, il est pertinent de créer des points de contrôles, des "revues" périodiques et sur une courte durée. Point.

En 1999, l'Extreme Programming nait : c'est l'ouvrage XPE de Kent Beck. XP offre un système complet :

• Rôles, Droits de chacun
• Valeurs (Communication, Feedback, Simplicité, Courage, Respect) et Principes (adaptation locale, assumer la simplicité, voyager léger...
  
  Pratiques, qui se déclinent en :
• Planification (Equipe complète, User stories, Tests-Client...)
• Développement collectif (Rythme durable, intégration continue, métaphore...)
• Fabrication du système (TDD, refactoring, conception émergente).

De fait, Scrum intègre en 2004 des apports de XP tels que User Stories.

Aujourd'hui, nous avons donc un ensemble de pratiques de planification, déclinées par Scrum et XP. Ces pratiques ont pour but de planifier très régulièrement le projet, le planning étant adaptatif.

• Equipe complète : Client ( Product Owner) et développeurs
• Itératif incrémental "court"
• Expression de besoins par demandes de type User Stories.

Scrum se base sur un cycle de type :

1. Sprint 0
2. Planification de la release
3. Boucle sur les sprints
   

XP propose un cycle de vie qui intègre de base plusieurs releases, le feedback concret des Utilisateurs intervenant alors dans le pilotage du projet. C'est la pratique "versions fréquentes" de XP.

1. Exploration
2. Engagement : planification des releases
3. Boucle sur les releases, qui inclue une boucle sur les itérations dans les releases.

Un autre point important : la gestion des demandes du Product Owner. Si XP préconise une gestion par User Stories sur cartes "papier" (ce qui induit un aspect kinesthésique), autant XP que Scrum s'accomodent parfaitement d'une gestion informatisée, dans le respect du principe de simplicité qui structure les pratiques agiles. Dans cet ordre d'idées, une approche ShuHaRi permet de comprendre par l'expérience les préconisations de XP et ainsi de mieux adapter à l'environnement dans lequel l'agile est déployé.

XP et Scrum

La planification dans XP est une adaptation, une simplification de Scrum.
Backlog, Product Owner... XP propose des termes plus simples et surtout insiste sur les tests-client.

XP et Scrum... Le cadre de gestion de projet pour mettre en place les pratiques d'ingénierie de XP.
Pourquoi ne pas appliquer directement la planification XP ?
http://agile.thierrycros.net/docs/Agile_XP_Scrum.pdf

Être plus agile : améliorer le feedback

Comment être plus agile, quand on ne peut pas être "agile", par exemple quand on ne peut pas installer XP ou Scrum.
L'Agilité peut être vue comme relative : comment, dans un contexte donné, être plus agile.
Être plus agile c'est :

• mieux communiquer, s'exprimer clairement, écouter vraiment ;
• améliorer le feedback : concret et rapide ;
• choisir le plus simple ;
• tout cela demande courage et respect.
  

Présentation "Feedback" à SIGMAT v4

Il s'agit alors de se poser la question : quelle est la prochaine étape : quel nouveau feedback ?

Les méthodes agiles créent les conditions d'un feedback, d'une rétroaction, pertinente, efficace. Entre développeurs, entre développeurs et client, etc.

Le feedback ne se résume pas au retour d'information, il inclut aussi l'action qui en découle.

• Feedback concret : réaliste, significatif : typiquement un code qui passe ou non des tests-client plutôt qu'une doc par exemple ;
  
• Feedback rapide : afin d'être plus efficace ; par exemple le feedback généré par les outils d'automatisation de tests-développeur.
  

Soyons donc inventifs !

La caRa-Attitude

La CaRa-Attitude.. ou le savoir-être agile.
http://agile.thierrycros.net/xp/img64.html

Attention
L'une des dimensions de l'attention est l'écoute. Être à l'écoute des partenaires de jeu. Savoir entendre leurs signaux... et leurs silences ! Par exemple ce Client qui dit "oups... cette solution me semble difficile à expliquer aux Utilisateurs de tel site" au détour d'une conversation à l'occasion d'une soirée.

Assertivité
L'assertivité ou affirmation de soi est en quelque sorte le complément indispensable de l'attention. Par exemple en posant des questions, en affirmant un point de vue.
http://agile.thierrycros.net/xp/img65.html

Tout un champ d'investigation, d'amélioration, de coaching... Être Agile !

Présentation "de l'agilité individuelle à l'intelligence collective" XpDay Paris Mai 2007

Voici cette présentation au format PDF (1,8 Mo).
http://agile.thierrycros.net/docs/XpDayParis2007.pdf

Présentation de l'Extreme Programming + Développement Responsable

J'ai le plaisir de vous proposer cette nouvelle version de la présentation XP. Cette nouvelle présentation comprend aussi des éléments de "développement responsable".

Le développement responsable est en quelque sorte la clé qui permet réellement une mise en oeuvre de l'Extreme Programming. Cette présentation contient la traduction d'un papier de Kent Beck (avec son autorisation bien sûr).

http://agile.thierrycros.net/xp/presentation_XP2007_t3.html

Happy Modeling & Extreme Programming,
Thierry.

Extreme Programming et Apprentissage

Bonjour,

je présentais récemment l'Extreme Programming, en utilisant le
diaporama du site. Ce diaporama sera d'ailleurs prochainement
mis à jour pour intégrer l'aspect "Développement Responsable".
La présentation était suivie d'un Xp Game de 3 heures.

http://agile.thierrycros.net/formation/presentationXP/img0.html

J'ai donc repris la notion d'apprentissage qui me semble tout à
fait typique de la mise en oeuvre d'XP.
http://agile.thierrycros.net/formation/presentationXP/img21.html

On retrouve cet apprentissage concrètement dans le cadre d'un XP
Game, ce "jeu" montre bien la courbe d'apprentissage du
réalisateur en termes d'estimation, du client, en termes
d'optimisation de sa valeur ajoutée, en tenant compte de
"yesterday weather" autrement dit de ce qui s'est effectivement
passé lors de l'itération précédente.

Un autre atout de l'XP Game réside dans l'apprentissage du
travail collaboratif. par exemple, j'entendais certains, lors du
jeu, dire "il ne faut pas dire que l'on n'est pas d'accord".
il est possible de dire "je ne suis pas d'accord", simplement
cela se situe dans un attitude assertive et non agressive.

Communiquer : le choix des mots

Je suis amené, dans le cadre de ma mission en cours, à présenter
l'avancement du projet à un panel de managers.

Certains aspects du projet sont préoccupants, dans les deux sens
du terme :
- étymologique : je préfère m'en occuper "en avance de phase"
- tout simplement "problématiques".

Habituellement, je communiquai ces aspects sous forme de
"risques", en précisant bien que certaines stratégies de gestion
de projet sont très prophylactiques (voir en particulier :
http://agile.thierrycros.net/docs/agileRisques.pdf )

Or, le terme "risque" est souvent perçu négativement : il y a
des risques donc "ça va mal" alors qu'en fait, il s'agit bien au
contraire d'être proactif, dans une véritable gestion des
risques.

J'utilise aussi l'expression point de vigilance qui offre une
connotation plus positive : une certaine configuration du projet
mérite notre vigilance. Notez que nous parlons de la même chose
: la gestion d'un risque passe par la mise en place d'une
surveillance, d'une vigilance face aux causes du risque et
également par la mise en place d'actions de diminution du
risque.

Je relatai cet exemple simplement pour pointer du doigt
l'importance de notre langage, de notre terminologie dans la
sphère professionnelle. Sans être naïf, inconséquent, utiliser
un terme plus positif ou tout simplement neutre est très
important car il donne une couleur plus efficace aux échanges,
aux réunions.

Autrement dit, le même sujet est traité, dans une ambiance
plus confortable et positive, donc pertinente.


Happy Modeling & Extreme Programming.

Feedback concret et rapide

Il n'est pas facile de mettre en oeuvre XP voire même l'Agile, tant les visions, les perceptions, de ce qu'est un développement de logiciel sont encore marquées par une compréhension simpliste du cycle en V.

La question est alors : quelle est tout de même la prochaine étape vers l'Agile, à la fois ambitieuse et accessible ?

J'interviens actuellement sur un projet qui est sensé suivre ce type de cycle de vie :

• Spécifications
• Réalisation
• Tests de recette
• Mise en production.

Inutile de dire que l'effet tunnel inhérent à cette approche - plusieurs mois de réalisation sans aucun retour concret - ne me satisfait pas. Comment être agile sur ce projet ?

Que faire ?
Quels sont les principes "agiles" qui semblent le plus nécessaires et/ou réalisables ?
En partant d'une modélisation qui "voit" l'activité de développement, le projet, comme un système, l'élément crucial est alors le feedback.

Qu'est-ce qu'un feedback concret et rapide ?
Un feedback est un retour d'information : il peut être spontané ou bien demandé, formalisé, géré. Au delà d'une apparence libertaire, XP formalise très rigoureusement de nombreux feedbacks : résultats des tests unitaires, stand-up meetings, résultats des tests-client, etc.
Ce retour d'information est sensé nous permettre de nous forger une opinion sur le déroulement du projet et, par là, de nous aider à décider. Actions, choix... autant de décisions qui sont alors rendues pertinentes grâce au feedback préalable (voir aussi l'aspect graphique dans ma présentation de l'Extreme Programming).

Feedback concret et rapide. Un principe sous-jacent au cycle habituel est qu'une documentation fournit par elle-même un feedback : "si ce document est produit, alors le projet est dans tel état d'avancement". Or, de nombreux facteurs, à commencer par la "spécification molle" rendent ce principe arbitraire, infondé, voire inopportun.

Un feedback concret est un feedback de l'application elle-même, donné aux utilisateurs. Injecter des intermédiaires : personnes (chef de projet, analystes...) et/ou d'autres livrables (documents) rend le feedback de moins en moins valable.

Un feedback est rapide (sachant qu'il est aussi concret) lorsqu'il intervient au plus vite après la production de ce qui est l'objet du feedback. Autrement dit, si l'équipe développe une fonctionnalité demandée semaine 9, le feedback devrait intervenir semaine 9, 10 ou semaine 11. Ainsi, les équipiers ont encore en tête les éléments constitutifs du produit testé et leur intervention de mise au point est alors plus efficace.

En pratique
Il s'agit donc de créer les conditions d'un feedback rapide et concret. Quelles sont les questions ?
Tout d'abord, préciser les pratiques à mettre en place : écriture des tests-client, passage de ces tests, analyse et prise de décision par rapport aux résultats de ces tests.
Ensuite, qui fait quoi ? La MOA - utilisateurs - est toute désignée pour conduire ces opérations, dans le cadre d'une collaboration avec les développeurs.
Enfin, quel est le rythme ? Il me semble qu'un rythme basé sur :

• des tests "permanents" autrement dit, tester dès qu'une fonctionnalité est programmée,
• dans un cadre itératif incrémental centré sur des itérations de 2 semaines à un mois

est un excellent cadre pour un feedback concret et rapide.

Le mieux étant l'ennemi du bien, il convient alors de faire la part des choses. Sur le principe, découper une "longue" phase de réalisation en plusieurs itérations est déjà une avancée significative. Attention, il s'agit de bien comprendre quelle est l'unité de travail. Dans un cadre XP, c'est la user story qui joue naturellement ce rôle. Dans un cadre plus classique, ce sont les exigences qui prennent le relai.
Autre point important : jouer sur la notion de "fin d'une réalisation". Trop souvent, le développement d'une fonctionnalité est réputé terminé lorsque le développeur a saisi le dernier point-virgule de la dernière instruction. Ici, une fonctionnalité est terminée lorsque le client, qui s'appuie sur les résultats de ses tests, le décide, pas avant.
Enfin, si votre MOA rechigne parfois à écrire des tests... aidez-là.

Ce qui est fait
Nous mettons donc en place des itérations d'un mois. Il se trouve que l'environnement de développement et le domaine sont parfaitement adaptés à une découpe en fonctionnalité "courtes". Ce sont des aspects du logiciel (les droits d'accès, les éléments structurants...) qui sont traités lors d'ateliers et qui donnent lieu à un ensemble de spécifications, de tests-clients, d'implémentation et de passages de tests.


En conclusion...
Vous souhaitez être agile ? Interrogez-vous : comment pouvez-vous mettre en oeuvre un feedback concret et rapide sur vos projets ?

photo : plage du Diamant, Martinique (Thierry Cros)