Être Agile

A compter du 16 mars 2009, accédez directement au site Être Agile :

http://etreagile.thierrycros.net

qui est maintenant à la fois la partie "articles" et la partie blog.

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.

Que devient alors le manager ? Il me semble que c'est le rôle habituel de Directeur de Projet qui s'en approche le plus, dans l'ancien monde du développement. Il alloue puis enlève des ressources au "projet".

Il joue un rôle capital de couverture aérienne. Autrement dit, il anticipe des situations qui sont d'ores-et-déjà actées. Par exemple le fait qu'une version est demandée début septembre par le Client et que la moitié de l'équipe a posé ses congés en août. 

Ce rôle prend acte de l'auto-gestion de l'équipe, il demande un certain courage au Manager. Le courage de faire confiance et respecter.

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 !

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.

Vendredi 28 Mars 2008 : Séminaire d'Information Gratuit sur les Méthodes Agiles de Toulouse

SIGMAT 5
Le prochain séminaire "agile" de Toulouse propose plusieurs retours d'expérience.

Contenu du séminaire

Ce séminaire sera consacré essentiellement à plusieurs retours d'expérience. Rendez-vous donc le vendredi 28 mars, à partir de 16h00 à l'Université Paul Sabatier de Toulouse. Comme d'habitude, le séminaire se conclura par un apéritif.

Inscriptions
envoyez simplement un courriel : claude@aubryconseil.com

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

Meilleurs Voeux 2008

Nous voici à fin 2007.

Peu à peu, l'Agile s'installe dans le paysage.
Pour preuve, les différents retours d'expérience, aux XpDays à Paris
ou bien lors des SIGMAT organisés à Toulouse.


Agile
Aujourd'hui, l'Agile peut être intégré progressivement.
Il s'agit d'être plus agile.
Voir par exemple la dernière présentation SIGMAT consacrée au feedback.
En 2008, nous aurons l'occasion de revenir sur ce point important :
comment être plus agile dans mon contexte ?

Extreme Programming
Lorsque je présente XP, j'utilise les trois cercles créés par Ron. Jeffries.
On voit alors que XP intègre Scrum tout en utilisant un vocabulaire simple.
L'intérêt est que, en démarrant à partir du premier cercle, nous embarquons
dans le projet tous les acteurs concernés. Ce qui est l'un des fondements
de l'Agile. Ainsi, la confiance peut s'installer et permettre alors les pratiques
des autres cercles.

UML
Ah... UML ! Grady réveille-toi, ils sont devenus fous !
Pendant longtemps j'ai envisagé de modifier le support en ligne gratuit pour
le passer en UML v2 et également intégrer "plus" d'UML.
Et les mois passent...
En fait, je constate que mon utilisation d'UML n'a vraiment pas
besoin de cette v2.

Et puis sur le terrain, nous en sommes encore bien souvent à revenir aux bases.

- Ne pas confondre cas d'utilisation et fonction (un cas est un ensemble d'interactions)
- Une classe ne représente pas la dynamique du système et ne se réduit pas à des données
- Les collaborations entre objets forment le coeur du système
- L'unité dans UML est le modèle et pas le diagramme
- Organiser un modèle n'est pas une mince affaire...

Bref, l'UML que je préfère, c'est un UML interactif au tableau ou au paper board,
qui insiste sur les deux piliers de la modélisation : structurel et dynamique,
qui sait jouer quand il le faut avec le formalisme pour le rendre plus lisible,
qui se transmet sous forme de photos numériques ou scans,
qui utilise abondamment les collaborations ou communications.

UML est un langage. Autrement dit un moyen de communication
entre humains et éventuellement entre humains et machine.
Modéliser c'est un moyen de mieux comprendre.
C'est si simple ! Pourquoi compliquer cette expression ?

Pour terminer, j'aime beaucoup dans XP et plus généralement dans l'Agile
la notion d'apprentissage : nous saurons mieux faire demain.
Ce sont les fameux cercles vertueux dont je parlais plus haut.

C'est le voeu que je forme à l'aube de cette nouvelle année.
Soyons plus agiles !
- communiquons clairement, apprenons à écouter,
- simplifions,
- donnons le feedback qui permet d'installer la confiance,
- respectons chacun dans son rôle.

Voila un sacré programme.

Et comme toujours :
Happy Modeling & Extreme Programming !


Thierry.

Bonus track : un coin sympa, la Martinique

Ê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 !

SIGMAT 4 : vendredi 14 décembre

Ce dernier séminaire 2007 se tiendra le 14 décembre, à partir de 16h00 à l'Université Paul Sabatier.

A propos d'actu, notez cet article du magazine "Le Monde de l'Informatique" qui évoque ces Séminaires, initiés par Claude Aubry :
http://www.lemondeinformatique.fr/actualites/lire-des-rencontres-agiles-pour-ameliorer-le-taux-de-reussite-des-projets-24790.html

Enfin, le programme de ce vendredi inclut
- présentation des méthodes agiles
- retour d'expériences de la division système d'information des laboratoires Pierre Fabre
- quelques mots sur le feedback en tant que principe constitutionnel de l'Agile
- et justement... feedback sur ces premiers séminaires agiles à Toulouse.

-- Happy Modeling & Extreme Programming !

Licence "Jeu vidéo" à Montpellier, Université Paul Valéry

Cette licence a démarré.
l'Extreme Programming a été retenu en tant que méthode.

Plus d'infos sur le site de l'Université Paul Valéry

Séminaire SIGMAT, 4ème du nom, le 14 décembre 2007 à Toulouse

Ce prochain Séminaire d'Information Gratuit sur les Méthodes Agiles à Toulouse (4) aura lieu le 14 décembre.
Comme pour tous ces séminaires : des présentations de techniques "agiles", des retours d'expérience...
Plus d'infos (PDF 125 Ko)

Lien vers le blog de Claude Aubry : Présentation SIGMAT4

Diagrammez vos modèles UML

Qu'est-ce que l'élément de base de l'UML ?
Le diagramme ?
La classe ?

Non !
L'élément est le modèle. Unified Modeling Language.
Les diagrammes composent alors le modèle, tout comme les éléments de modélisation. La mise au point des diagrammes est une qualité de la modélisation. Et ce n'est pas si simple !

Consultez cet article : "Diagrammez vos modèles UML".
http://agile.thierrycros.net/diagrammez.html

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

Les "SIGMAT"

L'organisation des SIGMAT propose désormais une liste de diffusion, pour être informé de l'actu "SIGMAT" ou tout simplement échanger sur les sujets abordés.

Pour s'inscrire, il suffit d'envoyer un message à :
sigmat-subscribe@icescrum.org

SIGMAT 3 : "quand l'Agile sort du bois"

Voici la présentation donnée lors du SIGMAT 3 :
Quand l'Agile sort du bois :
http://agile.thierrycros.net/docs/sigmat3.pdf

Deuxième Séminaire Agile de Toulouse

Ce vendredi 16 mars s'est tenu ce deuxième séminaire organisé par Claude Aubry.
Je le remercie pour son invitation et son accueil !

Claude ouvre le séminaire (ses diapos sont disponibles sur son site).
Je présente ensuite le Développement Responsable, complémentaire de l'XP.
Olivier Azeau présente les freins à l'adoption de l'agile.
Brice Jones de la CPAM présente une expérience SCRUM.
Les étudiants de la fac présentent le projet Wilos et IceScrum (présentation disponible sur le site de Claude).
Et un apéro pour clore la rencontre :-)

Une rencontre "agile" particulièrement intéressante : évoquer les questions d'éthique, de responsabilité pour rendre XP - et l'agile - réaliste du point de vue du manager, découvrir une mise en oeuvre concrète, des outils qui s'élaborent...

Vivement SIGMAT 3 !

Happy Modeling & Extreme Programming

Xp Days France - 2 et 3 mai 2007 à Paris

Après le succés de l'an passé, les Xp Days reviennent les 2 et 3 mai.

Pour toutes les infos (lieu, programme, inscription...) :

Site XP France : Présentation des XP Days

Sessions plénières, exposé, démos, ateliers, retours d'expérience... sont au programme.
Je présenterai "De l'agilité individuelle à l'intelligence collective".

Ces journées sont vraiment une occasion - unique - de rencontrer les acteurs de l'Extreme Programming.

support gratuit

Pour accéder au support gratuitement, il suffit de s'inscrire à la liste de diffusion du site. Pour cela, envoyez un email à :
info_request@thierrycros.net
cet email ayant pour sujet : subscribe
c'est tout, il suffit de répondre à la demande de confirmation d'inscription. Le message de bienvenue contient les informations de connexion au support.

Le support est constitué de "diapos" munies de notes au-dessous.

Accès direct au support gratuit UML

Happy Modeling & Extreme Programming.

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)

Séminaire agile à Toulouse, le 16 mars 16h

Pour information, je participerai à ce séminaire, organisé par Claude Aubry (Scrum) à Toulouse, à la fac de sciences (IUP ISI). Je présenterai "Extreme Programming : le développement responsable", ce qui est l'évolution de XP telle que son fondateur principal, Kent Beck, l'envisage. J'utiliserai (avec son accord bien sûr) une traduction de sa présentation à XP2006.

http://scrum.aubryconseil.com/

Peut-être pourrons-nous nous y croiser, ce sera avec plaisir que j'échangerai sur ce sujet.

Et comme toujours : Happy Modeling & Extreme Programming !

Seminaire "agile" à Toulouse le vendredi 8 décembre

Pour info, Claude Aubry organise un séminaire à Toulouse. Plus d'infos.

Programmne

• Accueil
• Présentation des méthodes Agiles, et en particulier
• Scrum (Claude Aubry)
• Extreme Programming (Laurent Bossavit)
• Retours d'expérience
• introduction de Scrum à la Caisse Primaire d'Assurance Maladie de Toulouse (Brice Jones)
• introduction des méthodes Agiles chez Total Gas Elec (Benoît Chevalier)
• Débat sur l'état des lieux de l'Agilité en France, avec la participation du public. Parmi les sujets abordés :
• quelle est la diffusion de l'Agilité en France par rapport aux autres pays, exemples d'entreprises et de projets Agiles ?
• les méthodes Agiles sont elles adaptées à la culture française ?
• les méthodes Agiles sont-elles adaptées aux relations contractuelles ?
• l'enseignement des méthodes Agiles
• Démonstration de l'outil Open Source IceScrum, développé par des étudiants de l'IUP ISI
• Apéritif
  

Peut-être pourrons-nous nous y croiser !

Happy Modeling & Extreme Programming

Modélisation agile : changement incrémental

L'un des principes de base de la modélisation agile est : "Changement incrémental".
----
(traduit du site agile modeling)
En modélisation, il est important de comprendre qu'il n'est pas nécessaire d'obtenir le modèle correct dès la première fois ; en fait, il est très peu probable que vous y réussissiez même si vous essayez. Plus encore, vous n'avez pas à capturer tous les détails dans vos modèles, vous avez simplement besoin du niveau nécessaire à l'instant t. Plutôt que d'essayer de développer un modèle complet dès le départ, posez déjà un jalon en développant un premier petit modèle, peut-être un modèle haut-niveau, puis faites-le évoluer de manière incrémentale (ou tout simplement, jetez-le si vous n'en avez plus besoin).
----
Et ce principe est à rapprocher de la valeur de feedback dans l'approche agile.
Cela donne la liberté à l'équipe (modeleurs, clients) d'apprendre le système et sa modélisation de façon progressive.

Accès au support de formation gratuit UML

Ce support est accessible gratuitement. Pour cela, il suffit de s'inscrire à la liste de diffusion du site. Envoyer un email à : info_request@thierrycros.net dont le sujet est : subscribe.
Vous recevez alors une demande de confirmation d'inscription à laquelle il suffit de répondre tel quel.
Enfin le message de bienvenue de la liste contient les codes d'accès.
C'est tout !

Happy Modeling & Extreme Programming,
Thierry

"Conception médiatique" promo 2007

Cette formation continue en 2007. Inscriptions ouvertes. Je suis intervenu jusqu'à présent sur l'aspect méthode avec l'Extreme Programming qui se "marie" très bien avec la vision "Intelligence Collective" de la formation.
Si vous êtes intéressé par cette formation et par quelques mois à Montpellier :) c'est le moment !

Présentation de la formation "conception médiatique"

CMMI Niveau 2 : mission accomplie

Ma mission (chef de projet d'une équipe de déploiement/coaching CMMI) se termine, succès : l'organisation cliente est bien évaluée CMMI Niveau 2.
Plateau projet : 11 coachs, 2 "support".
Planning : début projet en mars, évaluation en novembre.

Ce fut un "challenge"...

Succès

• Evaluation réussie
• Adhésion des personnes concernées, fort sponsoring du management

Points de difficulté

• Management de l'équipe : difficile de manager "agile" quand ce n'est pas le deal de départ
• Parallélisme entre la montée en compétence CMMI, une évolution de l'organisation

Bilan

• Le succès du projet, bien sûr
• Belle aventure humaine, il a fallu trouver le courage, pour tous, d'avancer jusqu'au résultat !

La théorie de la taupe

Croyances dans les projets...
J'ai entendu récemment une théorie selon laquelle parmi les collaborateurs d'un projet se trouve "mécaniquement" une taupe. Moi qui suis militant de "l'agile" donc d'une communication honnête et sincère, je dois dire que cela m'a fait "un choc"...

Lors d'une formation à l'Extreme Programming il y a quelques mois, nous découvrions une autre théorie selon laquelle un membre de l'équipe "doit" jouer le rôle du vilain petit canard, tant et si bien que même si vous "virez" ce membre là, un autre prend le rôle ipso facto.

Et bien non. Je n'y crois pas. Je crois par contre à la nécessité de recruter dans l'équipe selon les règles du jeu. L'agilité ne se décrète pas...

Simplicité

Notre vie est gaspillée par les détails,
simplifiez, simplifiez, simplifiez!
Je vous dis, ayez deux ou trois affaires
et pas cent ou mille.

Henry David Thoreau

Et... qu'est-ce qui nous empêche d'appliquer cette valeur de Simplicité même sans Extreme Programming ? UML simple, use cases simples, conception simple !
Allez... Ce 4 octobre, c'est la journée de la Simplicité !

CMMI

Actuellement, je participe au déploiement du CMMI niveau 2 dans une organisation. Nous sommes proches de l'évaluation...

SCOPE / M

Info : cet article sur SCOPE/M vient d'être publié : Retour d'expérience sur SCOPE/M.

Mise à jour des liens
à l'époque, le site était sous l'URL www.thierrycros.net
Depuis la création d'autres web secondaires (tolteque..) le site "Etre Agile" est désormais ici :
http://agile.thierrycros.net

L'article concernant le modèle SCOPE est ici : http://agile.thierrycros.net/score.html
Les cartes SCOPE très utiles pendant la session sont ici : http://agile.thierrycros.net/docs/cartesScope.pdf

Être agile face aux risques

Un article : Être agile face aux risques qui présente dans un premier temps la gestion de risques sur un projet. Dans un deuxième temps, nous voyons l'apport des méthodes agiles, XP en particulier, dans la diminution des risques sur le projet. Ces méthodes sont de véritables tueuses de risques !

Accords toltèques sur le site...

Même si certains pont existent entre accords toltèques et XP, à ce sujet, voir ce qui est écrit dans les accords toltèques pour l'Extreme Programming, je crois qu'il est préférable de séparer les ressources sur le site.
Voici donc le petit dernier de la famille des sites web : http://tolteque.thierrycros.net/ exclusivement consacré aux quatre accords toltèques.

Avec en avant-première le passeport toltèque ! Un paquetage destiné au voyageur toltèque, basé sur une mise en pratique progressive de quatre semaines.

Comment développer vos ressources personnelles

Une ressource qui peut être un excellent complément à l'approche agile :

• pour comprendre ce qui se passe vraiment,
• pour accompagner le changement.

Un e-book de Francis Delval :
Comment développer vos ressources personnelles (format PDF 942 kO).

La ressource primordiale à utiliser dans la relation avec soi-même est la bienveillance.
Francis Delval

Cartes SCOPE/M : retour d'expérience

Je présente dans modèle SCOPE ma façon de mettre en oeuvre le modèle SCORE dans une équipe. Concrètement, il s'agit simplement de guider une réunion de travail dont le but est d'éclaircir puis améliorer une situation jugée inconfortable.

L'environnement, les invités à la réunion
Une salle de réunion, un tableau, une table de réunion. Les invités sont directement concernés par la situation, tous les membres d'une équipe ne pouvant être présents, un délégué spécialement adoubé pour cette réunion fut envoyé.

Déroulement de la session
Je (en tant qu'animateur de la réunion) présente SCOPE/M et les cartes support. Un embryon de diagramme d'idées est dessiné au tableau ; au centre, dans un cercle, le libéllé de la problématique et une ligne courbée pour chacune des 5 positions de base : S C O P E.
Il s'agit ensuite de passer par les 5 + 1 postures. La confusion sur la nature des éléments est assez fréquente, est-ce un symptôme, une cause... attention à rester cohérent, tout simplement. Autre point, dégager un plan d'action fut assez laborieux. Il s'agit d'être vigilant sur la qualité des actions décrites, ne pas rester dans les voeux pieux et déclarations de bonnes intentions. Les actions sont concrètes : l'action, qui en est le responsable, quelle est la date d'échéance a minima.

Améliorations à noter
- Passer 2 fois si possible sur les 6 postures : une première fois pour dégrossir, une position meta, puis reboucler sur les différents axes
- Si possible prendre une photo du tableau pour l'utiliser dans le compte-rendu
- Considérer cette réunion comme "exceptionnelle" en termes d'attitude, d'importance, bref, ce n'est pas une réunion d'avancement classique, c'est un peu comme si cette réunion se déroulait au Louvre (photo www.folp.free.fr).

Accés au support UML gratuit et liste de diffusion

Le support UML est aujourd'hui utilisé par plusieurs centaines de personnes. Pour faciliter la diffusion d'informations concernant ce support (mises à jour, compléments, changements de codes d'accés...) et plus généralement l'actualité du site, les emails auxquels sont envoyés les codes d'accés au support sont automatiquement inscrits à la liste de diffusion générale du site : info:thierrycros.net.

Avec quelques précisions :

• Cette inscription reste facultative, il est toujours possible de ne pas répondre au mail de demande de confirmation de l'inscription
• Une fois inscrit, vous pouvez à tout moment vous désincrire en envoyant simplement un mail au robot de la liste (voir la signature des mails envoyés par la liste)
• Cela va sans dire mais... c'est mieux en le disant :-) votre email est exclusivement réservé à la diffusion d'infos depuis www.thierrycros.net et n'est pas utilisé à d'autres fins ni transmis à qui que ce soit.
  

Pour demander l'accés au support, il suffit de cliquer ici.

De SCORE à SCOPE/M

Le modèle SCORE, destiné à clarifier des situations à améliorer, est au départ un outil de développement personnel me semble-t-il. C'est aussi un moyen de travail collaboratif, lorsqu'il s'agit par exemple de changer une situation jugée insatisfaisante.

En tant qu'outil "personnel" le R représente les ressources nécessaires à ce changement, comme plus d'enthousiasme, parler en public, etc. Dans cet ordre d'idée, il existe plusieurs outils qui permettent de mettre en place ces ressources (par exemple travailler sur des ancrages...).

En tant qu'outil de travail collaboratif, nous travaillons au niveau collectif et il s'agit alors d'établir un plan d'action pour les personnes concernées. Le R devient P.

• S pour Situation ou Symptômes
• C pour Causes
• O pour Objectifs
• P pour Plan d'action
• E pour Effets
• M pour meta ou poste d'observation du SCOPE.

Plan d'action
Un "bon plan d'action" comprend au minimum le libéllé de l'action, son porteur, sa date d'échéance. Il peut être selon les cas simplement décrit sur un tableau ou bien géré via un tableur ou encore un outil spécialisé. Quoi qu'il en soit, il est écrit. Et régulièrement suivi et mis à jour.

Objectifs, Effet et Plan d'Action
Les objectifs existent à plusieurs niveaux.

1. Niveau idéal, proche de l'effet dans SCOPE
2. Niveau global à terme
   
3. Niveau mesurable à plus court terme
4. En pratique les objectifs deviennent des actions du plan.

En conclusion...
Une situation à améliorer ? Scopez-là ! L'article Modèles SCORE et SCOPE/M propose un exemple de mise en oeuvre. Vous pouvez aussi éditer vos cartes SCOPE/M.

Photo f.o.l.p.

CARA

Je m'étais posé la question suivante : quelles sont les qualités à posseder pour être "bien" dans l'équipe (en tant que client, manager, développeur) ? Je ne parle pas de qualités de "professionnel" : maîtriser telle ou telle architecture, tel process métier, être capable de gérer un budget et de recruter... Non, plutôt de qualités humaines en adéquation avec les valeurs de XP :

• Communication,
• Feedback,
• Simplicité,
• Courage.

Et la réponse se trouvait (pour moi) dans C.A.R.A. pour :

• Courage,
• Attention,
• Responsabilité,
• Assertivité.

Quelques éléments dans cet article, toujours en construction. J'avais surtout insisté à l'époque sur l'assertivité en tant qu'expression d'une certaine affirmation de soi dans l'équipe.

Photo folp : plage du Diamant, Martinique.

Xp Day en France

Pour info, un événement "agile" en France : http://www.xpday.fr/
Les 23 et 24 mars à Paris,

Après Londres, Bruxelles, Rotterdam, Karslruhe, la conférence "XP Day" a désormais sa version française. XP Day France s'adresse aux professionnels du logiciel, quel que soit leur niveau de connaissance de l'Extreme Programming.

Je ne pourrai pas y être et c'est bien dommage, les premiers XP Day en France, cela fait bien plaisir, il y a bien loin depuis la création de l'asso XP France en 2000...

Modéliser "agile" : les demandes

l'Extreme Programming propose l'utilisation de cartes "bristol" qui contiennent des demandes, en fait des identifiants de demandes qui sont autant de prétextes à discussion, communication, entre client et développeur. Ces demandes sont aussi les items de gestion du projet. A chacune d'elles sont associés :

• une priorité
• un "poids" en termes de jetons ou points qui représentent l'effort nécessaire à la réalisation.

En fonction de ces éléments, le client établit - en tenant compte aussi de la vélocité ie la capacité de réaliser de l'équipe pour l"itération - la liste des demandes embarquées.

En modélisation agile, avec UML, il s'agit de :

1. satisfaire au principes et pratiques de la modélisation agile,
2. garder à l'esprit qu'un scenario de cas d'utilisation est équivalent à une user story XP.

De même, les cas d'utilisation sont réellement mis en oeuvre, voir à ce sujet le retour d'expérience significatif d'Alistair Cockburn.

Quelques éléments supplémentaires dans : cas d'utilisation efficaces.

Modéliser "agile"

Sans reprendre les principes et pratiques de la modélisation agile, quelques aspects pragmatiques de la modélisation agile. Voir aussi How Can Enterprise-Level Professionals Be Agile?.

Focaliser sur la valeur ajoutée
C'est l'un des principes du développement agile. Quelle est la valeur ajoutée de cette demande ? De cette action ? De ce document ? De cette réunion ?
Attention au terme "valeur ajoutée", il ne s'agit pas de valeur intrinsèque uniquement, plutôt de comparer le bonus obtenu avec le prix à payer. Ici, la question est alors : quelle est la valeur ajoutée de cette modélisation ?
Contrairement donc à un préjugé tenace, être agile est bien synonyme d'efficacité, d'amélioration de la productivité. Avec pour pierre angulaire l'humanité inhérente à la réussite du projet.
En résumé, "modéliser agile" est incompatible avec "modéliser inutilement".


Communiquer pour mieux collaborer
L'un des fondamentaux de l'approche agile (y compris Extreme Programming). Un modeleur agile ne passera des heures sans feedback de ses coéquipiers (clients, développeurs).

Feedback concret du système
De même que le feedback des collaborateurs est très régulièrement demandé, de même le feedback offert par le passage de tests du système est un élément crucial de la modélisation agile.

Concrètement, nous examinerons dans les jours qui viennent trois situations réalistes :

• Modélisation métier ou domaine,
• Modélisation de demandes,
  
• Modélisation de solution.

Extreme Programming et UML

Récemment, un fil de discussion a animé la liste "XP France", le sujet tournait autour de :
"quid de la modélisation en général et de l'UML en particulier"... entr'autres choses.

Alors... UML est-il "compatible Extreme Programming" ?

Pour être clair, je m'inscris parfaitement dans la modélisation agile. En ce qui concerne XP, je partage les idées de l'article Agile Modeling and Extreme Programming de Scott W. Ambler ; ma réponse à la question est donc oui, sans réserve !

Quelques précisions
Il s'agit de faire attention à ce qu'est UML... et ce qu'il n'est pas. UML est le langage de modélisation objet de l'OMG. Ce n'est pas une méthode ni un outil informatique. UML est le plus souvent découvert via le processus unifié ou l'une de ses variantes. UML est souvent associé à un outil modeleur. Or UML permet une autre utilisation basée sur le travail collectif, des outils pas nécessairement informatiques, des cycles courts... bref une modélisation agile.
De même pour XP. XP est une méthode de développement basée sur des valeurs, principes et pratiques. XP n'est pas destinée exclusivement aux développeurs, malgré le nom qui prête à confusion sur ce point. XP n'interdit pas les documents mais pose un regard critique - légitime - sur le flot de documentation produit par les méthodes habituelles, documentation souvent inutile, obsolète, mal positionnée dans le temps. XP n'interdit pas la modélisation mais rappelle que seul un code qui passe avec succès est garant de qualité. XP est riche en pratiques pour le développeur, riche en pratique de gestion du projet (planning process) et n'aborde pas les aspects strictement "gestionnaire" ou "client".

Un bref rappel...
... en ce qui concerne UML : l'élément de base de l'UML est le modèle (normal pour un langage de modélisation me direz-vous). Un modèle c'est quoi ? C'est une représentation d'un système (ie une société d'objets) à partir d'un point de vue : expression de besoins ou conception par exemple. Le modèle s'organise en paquetages, éléments de modélisation et diagrammes. Voir à ce sujet l'article Diagrammez vos modèles UML.

Un premier point important par rapport à XP. Si la création - et le maintien - d'un ou plusieurs modèles est une demande du Client et/ou du Manager (exigence qualité par exemple) alors il s'agit pour l'équipe d'une "histoire" à intégrer dans une ou plusieurs itérations, un peu comme les autres (fonction des priorités, poids en jetons, vélocité). Au passage cela permet de prendre conscience du coût d'un tel produit. En ce sens, XP est parfaitement compatible avec UML. Dans XP, les responsabilités et rôles sont définis ainsi : c'est le Client qui détermine les demandes.

Un modèle UML... est-ce utile ?
Cette question légitime trouve une réponse de la façon suivante. Le (ou les) modèle est créé une première fois. Ne pas le produire générerait un stress a priori. Avant de le maintenir, voire de créer d'autres modèles, il est important de faire le bilan : ce modèle est-il utile ? A qui ? Pendant combien de temps ? Quelle valeur ajoutée ? En fonction de ces réponses, la décision pourra être de poursuivre dans le sens de la modélisation ou pas. Cette tactique est d'ailleurs efficace pour tout type de livrable du projet.

Question de sensation
Examinons maintenant un point crucial dans l'appréciation de la modélisation. De même que certaines personnes ont une mémoire auditive et d'autres une mémoire visuelle (que faites-vous pour retenir un numéro de téléphone ?), de même certains développeurs "voient" l'architecture (la forme ou le squelette de l'application, par exemple l'utilisation d'un pattern tel que Observateur...) en lisant quelques entêtes de fichiers-sources. D'autres (dont je fais partie) voient une architecture plus rapidement dans quelques diagrammes bien faits. Diagrammes qui visualisent les aspects statiques et dynamiques du système en particulier. Nous touchons là à un élément naturel probablement inéluctable. Attention donc aux contraintes dans un sens ou dans l'autre.

Utiliser UML
Pratiquement, quel est l'utilisation d'UML la plus naturelle dans XP ? Il se trouve que l'Extreme Programming propose une autre technique de modélisation : les CRC Cards. UML pourrait être considéré comme un remplaçant. Comment ? Tout d'abord le contexte, par exemple découvrir les objets et interactions dans la réalisation d'une demande (user story) ou d'une tâche. Supposons un binôme qui démarre la réalisation d'une nouvelle tâche et qui se pose la question des tests, de la conception de cette réalisation. Ou bien une équipe qui doit donner un poids à une demande sans aucune idée de ce que peut être sa mise en oeuvre. Un tableau (tableau blanc, paper board...), quelques développeurs autour. Un diagramme d'interaction (séquence, collaboration)... et c'est parti ! Un diagramme de classes permet de "compiler" les différents apports des diagrammes d'interaction. Notez que les classes dans UML possèdent un compartiment dédié aux responsabilités (compartiment que l'on ne retrouve malheureusement pas dans les modeleurs). Combien cela dure-t-il ? L'une des clés de XP est le feedback rapide. Il importe donc de ne pas tomber dans le piège d'une modélisation trop longue sans le feddback des tests de code.

UML côté Client
XP définit trois rôles dans le projet. Si UML est généralement associé au développement de logiciels, ce langage permet également de modéliser des processus, des domaines. C'est l'activité de modélisation métier. Une solution possible avant de commencer la rédaction de demandes de développement est de travailler au changement induit par le prochain outil logiciel. Dans cet ordre d'idées, modéliser les processus impactés peut permettre de cerner plus rapidement le contour fonctionnel de façon plus rapide (modifier un modèle est plus rapide que modifier un code bien que le feedback soit moins probant). Ici, UML propose en particulier les diagrammes d'activités, d'état-transition et bien évidemment les classiques diagrammes d'interactions et structurels (appelés pour simplifier diagrammes de classes).

En guise de conclusion...
UML est-il compatible XP ? Oui, même si UML ne fait pas partie des outils proposés naturellement par XP. Pas n'importe quel UML, plutôt une mise en pratique qui respecte les principes d'XP tels que feedback rapide, assumer la simplicité, petit investissement de départ...
Et plus généralement, ceci étant vrai pour beaucoup de choses : tout dépend du contexte... Peut-être une affaire de décohérence quantique :-)