Être Agile

Le site Être Agile est directement accessible depuis :

tco.thierrycros.net

Ce site https://tcros.blogspot.com/ est donc plus "perso" désormais... Parce que toute vérité ou du moins opinion n'a pas sa place dans le monde professionnel.

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 !

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/