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 !