Nat's Gregarius » Être agile : modéliser, développer, vivre les projets

« Expand/Collapse

Être agile : modéliser, développer, vivre les projets (10 unread)

November 18, 2009
17:25
Être Agile
» ‎ Être agile : modéliser, développer, vivre les projets

Le site Être Agile est directement accessible depuis :

http://etre-agile.com http://www.thierrycros.net
March 18, 2009
16:55
Être Agile
» ‎ Être agile : modéliser, développer, vivre les projets

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.
http://www.thierrycros.net
March 14, 2009
13:11
Principes de l'Extreme Programming : autosimilarité
» ‎ Être agile : modéliser, développer, vivre les projets
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é.
http://www.thierrycros.net
March 11, 2009
8:50
Couverture aérienne, une pratique du manager XP
» ‎ Être agile : modéliser, développer, vivre les projets

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.
http://www.thierrycros.net
March 10, 2009
18:13
Principes de l'Extreme Programming : bénéfices mutuels
» ‎ Être agile : modéliser, développer, vivre les projets
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.
http://www.thierrycros.net
March 09, 2009
9:08
Principes de l'Extreme Programming : Economie
» ‎ Être agile : modéliser, développer, vivre les projets
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.
http://www.thierrycros.net
March 06, 2009
15:56
Principes de l'Extreme Programming : Humanité
» ‎ Être agile : modéliser, développer, vivre les projets
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. http://www.thierrycros.net
March 05, 2009
11:48
Humilité ?
» ‎ Être agile : modéliser, développer, vivre les projets

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. http://www.thierrycros.net
March 04, 2009
16:32
Ah... les process !
» ‎ Être agile : modéliser, développer, vivre les projets
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.
http://www.thierrycros.net
March 03, 2009
11:45
Logiciel ou... software ?
» ‎ Être agile : modéliser, développer, vivre les projets
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 !
http://www.thierrycros.net

← XProgramming - An Agile Software Deve... QualityStreet →

Nat's Gregarius » Être agile : modéliser, développer, vivre les projets

Feeds

Être agile : modéliser, développer, vivre les projets (10 unread)