17 novembre 2006

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

16 novembre 2006

"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"

13 novembre 2006

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 !

14 octobre 2006

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

04 octobre 2006

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

28 septembre 2006

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

26 mars 2006

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

10 mars 2006

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.

05 mars 2006

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




04 mars 2006

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.

03 mars 2006

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.

01 mars 2006

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.

22 février 2006

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

19 février 2006

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.

10 février 2006

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