28 décembre 2007

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

14 décembre 2007

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

12 décembre 2007

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 !

15 novembre 2007

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

10 octobre 2007

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

07 octobre 2007

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 !

23 septembre 2007

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

19 mars 2007

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


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.


Happy Modeling & Extreme Programming.

15 mars 2007

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.

12 mars 2007

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.

27 février 2007

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.

17 février 2007

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)

24 janvier 2007

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 !