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 !

S'adapter au contexte... et vice versa

Dans cet article, paru en septembre 2000 dans "Langages et Systèmes", j'écrivais page 6 "Adopter XP implique des mutations". Il me semble que cela s'applique à l'agilité de façon plus générale.

Que la mise en oeuvre d'une approche agile tienne compte du contexte, de l'environnement, me parait être une nécessité. C'est d'ailleurs un principe d'XP : adaptation locale.

D'un autre côté, être agile correspond à un changement de rôles d'identités des personnes actives du projet. Le Chef de Projet MOA devient par exemple "Client" XP ou Product Owner Scrum. Ce n'est pas le même rôle. Dans cet ordre d'idée, laisser à penser qu'un Chef de Projet MOE se transforme naturellement en ScrumMaster ou Coach agile est à mon sens démagogique. Un peu comme un bon technicien ou ingénieur qui deviendrait naturellement bon manager... Ou un bon mathématicien qui deviendrait bon prof de mathématiques. D'autant plus que cela ne facilite pas la prise de conscience de la différence des rôles.

Cette différence de rôles, de pratiques,  de responsabilités... est due à un autre changement, encore plus profond : le projet lui-même change, dans le cadre d'une transition vers l'Agile. Pour être clair, le point focal n'est pas le projet, plutôt le produit. Habituellement, nous avons deux phases macro pour un produit :

1. Développement (y compris pré-étude), qui se concrétise par la mise en exploitation
2. Maintenance, bien souvent prise en charge par une équipe différente.

Dans une approche agile, centrée sur le système et les livraisons fréquentes, le schéma est :

1. Exploration ou "sprint 0"
2. Première version (à Tzéro + 3 mois par exemple)
3. Deuxième version (à + 3 mois...)
4. etc

Si l'Agile s'adapte au contexte, ce contexte - et les personnes qui le composent - s'adaptent à l'Agile. Il s'agit de "virer sa cutie" : de CP MOA on devient Product Owner, de Développeur on devient Extreme Developpeur, etc.

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.

Soirée "Agile" à Marseille, le 17 mars

J'aurai le plaisir de participer à cette soirée, organisée par ViaXoft le 17 mars à partir de 18h00. Toutes les infos sur le blog "Esprit agile". 

Ce sera une bonne occasion de présenter l'Extreme Programming, Claude Aubry présentera Scrum.  Ces deux méthodes « phares » se consolident mutuellement : en 1996, Scrum apparaît avec une idée-force : « Un processus de développement de systèmes est imprévisible ». De fait, Scrum est alors un cycle itératif incrémental « court » : un mois. C'est tout Scrum.

L'Extreme Programming apparaît en 1999, via l'ouvrage phare de Kent Beck : Extreme Programming Explained. Si XP s'inspire de Scrum (itératif court), cette nouvelle approche est un véritable système, une constitution :

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

Scrum s'inspire alors de XP, une nouvelle version apparaît en 2004, qui intègre plusieurs apports.

Aujourd'hui, l'Extreme Programming offre cette palette de pratiques, pour la plupart indispensables à une véritable mise en oeuvre "agile" : tests-client, intégration continue...

 

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.

Concepts objet et Conception : UML agile

Un article du site consacré à la  Conception objet avec UML .

• Ce qu'est la modélisation
• Les concepts objet
• Les principes de base d'une véritable conception objet 
• Structurel et Dynamique d'un système d'objets
• Consolidation réciproque de ces deux piliers de la conception (Structurel et Dynamique)

Un programme « objet » est constitué d'objets qui communiquent. Chacun assume une certaine  responsabilité dans ces échanges. C'est cela l'objet.

Modélisation agile : Expression de besoins avec les cas d'utilisation

Cet article : Expression de besoins agile du site Être Agile présente un processus d'expression de besoins basé sur les cas d'utilisation de l'UML. Le maintien du modèle (dans un modeleur) les différents rôles est également traité.

Les niveaux de cas d'utilisation, tels que formalisés par A.Cockburn, sont étudiés. 

Prochain Séminaire SIGMAT : vendredi 27 mars

Comme d'habitude à la fac de Sciences de Toulouse (Université Paul Sabatier, Route de Narbonne), à 16H. Voir le site de l'association SIGMAT : http://www.sigmat.fr/

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

Licence Pro Jeux Vidéo, fac Paul Valery, Montpellier

Je réalise une présentation des méthodes agiles, Scrum, XP dans le cadre de la fac de Montpellier. La licence Jeux Vidéo du SUFCO à la fac est présentée ici. Cela dure 2 jours.

Grosso modo, la présentation correspond à ce qui a été fait lors de l'Agile Tour 2008, étape toulousaine : présentation méthodes agiles. L'accent est mis sur la planification, avec pour illustration un XpGame et/ou une mise en oeuvre sur un "mini-projet" Scrum avec Game Factory. La planification s'appuie sur Scrum qui intègre les apports de XP, ou peut-être bien sur XP qui intègre les apports de Scrum :-)

C'est en fait ce que l'on appelle maintenant : Scrum + XP.

Présentations utilisées pendant la formation

• Intro Agilité : voir le site sigmat.fr
• Scrum : voir la présentation libre de Scrum sur le site Être Agile, merci à Claude Aubry
• Extreme Programming : voir la présentation libre de XP sur le site Être Agile.

Photo "Montpellier, place de la comédie" : stock.xchng

Prochain séminaire à Toulouse : vendredi 12 décembre 2008

Après l'Agile Tour d'Octobre 2008, qui correspondait au 7ème séminaire SIGMAT, le prochain rendez-vous agile de Toulouse est fixé au 12 décembre, plus d'infos sur le site www.sigmat.fr.

• C'est toujours l'Université Paul Sabatier, IUP ISI, qui nous accueille, merci à eux,
• Horaires : 16h - 19h
• Contenu : on va s'y mettre :-)
  

Site Être Agile : version 3

Après le piratage du site en septembre, voici une version simplifiée qui reprend les articles principaux.

Être Agile

Agile Tour 2008, Toulouse : c'est fait !

Agile Tour 2008, étape toulousaine : c'est fait. L'amphi archi-plein, les horaires respectés, des préz vraiment intéressantes (que vous pouvez retrouver sur le site du groupe SIGMAT).
Venant de la communauté XP, ces présentations questionnent sur la "collaboration" légitime Scrum et XP, également sur les pourcentages d'utilisation (grosso modo 1/2 Scrum, 1/4 XP+Scrum). Voir à ce sujet ces quelques slides.

Agile Tour : étape toulousaine le 16 octobre

L'agile tour (http://www.agiletour.com/) fait étape le16 octobre à Toulouse. C'est la fac de sciences qui nous accueille dans l'amphi "Concorde". Parmi les différents sponsors, "la Mélée" bien connue à Toulouse publie ce communiqué de presse.


Les 100 premiers inscrits recevront un (p'tit) cadeau ! ... Et nous en sommes aujourd'hui à 80 inscriptions.
Plus d'infos sur le site des organisateurs de l'événement : www.sigmat.fr.

Inscrivez-vous ici.

Nouveau site "Être Agile"

Le site fait peau neuve. Les articles et ressources existants sont repris (y compris quelques éléments de l'ancienne partie wiki).

Site Être Agile

(http://etreagile.thierrycros.net)

SIGMAT5 le vendredi 28 mars à l'Université Paul Sabatier de Toulouse

L'adresse précise du séminaire est :
Université Paul Sabatier
Bâtiment U3, amphi Didier Daurat (au rez de chaussée)
Route de Narbonne, Toulouse.