La conférence Agile 2008 a lieu dans 3 semaines seulement! Ce sont déjà les tout derniers moments pour s’inscrire (plus de 1200 inscrits il y a une semaine, sur 1600 attendus).

Valtech sera présent à cette conférence. 3 des sujets que nous avons présentés ont été retenus:

• Greg Hutchings: Distributed agile teams and alternative contractual forms: what works best?
• Greg Hutchings: Contractualisation des projets Agiles, en Français dans le texte et dans le discours
• Gilles Mantel: Test-Driven Requirements – Beyond Tools (cette session sera également présentée à Paris, en Français, lundi 28 juillet)

Par ailleurs, Eric Lefèvre a co-organisé la track Breaking Acts, une serie de sessions cherchant à faire avancer nos connaissances sur l’agilité.

Nos collègues des autres filiales de Valtech ne sont pas en reste. En particulier, Valtech US assure 8 sessions (!), plus une pour Valtech UK:

• Scrum Accelerator: The Game
• Effective Pairing: The Good, the Bad, and the Ugly
• Manager’s Introduction to TDD
• Overcoming Resistance to Change
• Advanced TDD Randori & Fishbowl
• The use of Ritual in Agile currently and identifying improving ways to harness the power of ritual
• Effective and Pragmatic Test Driven Development
• The Tail and the Dog: Aligning Governance with Agile Project Management
• The Aikido of Agile Project Metrics

Avec un total de 12 sessions, il semblerait que Valtech fournisse le plus gros contingent de présentateurs

Si vous vous rendez à Agile 2008, certains d’entre nous serons reconnaissables à leurs polos Valtech.

Si vous ne pouvez pas vous joindre à nous à Toronto, n’hésitez pas à assister à la présentation de Gilles sur TDR dans nos locaux, lundi 28.

XP Day Paris 2008, la conférence agile sur les méthodes agiles, a lieu à Paris 14ème, les 5 et 6 mai 2008.
(more…)

Il y aura ce soir lundi 14 avril 2008 un Coding Dojo organisé par la communauté Ruby Parisienne.

Notre collègue Etienne sera présent et prononcera quelques mots sur l’agilité.

Lors d’une récente fin d’itération, nous avons discuté de XP Installed, un ouvrage de la collection XP Series, écrit par Ron Jeffries, Ann Anderson et Chet Hendrickson. Voici les éléments à retenir.

(more…)

XP Day Paris, la plus importante conférence française sur l’agilité (et pas seulement sur XP) a lieu les 12 & 13 mai 2008.

Les organisateurs ont rappelé que l’appel à contributions s’achève le 10 février. C’est dimanche prochain! Il vous reste donc 2 jours pour faire vos propositions sur le wiki de la conférence.

Valtech soutient XP Day Paris 2008.

Non ! Encore cette étiquette d’extrémistes !

Comment Schumacher aurait-il pu gagner un championnat de formule 1 s’il n’appuyait pas au maximum sur l’accélérateur ? Voila l’idée de l’eXtreme Programming. Il ne s’agit pas d’aller trop loin, mais de rechercher la performance optimum des pratiques qui la constituent.

Il ne faut pas croire que eXtreme Programming signifie extrême effort, ou horaires extrêmes. Il s’agit en fait d’optimiser la méthode de travail. Quel effort y-a-t’il à pousser sur l’accélérateur jusqu’à sa position idéale ? Aucun, ce n’est qu’une question d’habileté ! D’un autre coté, se contenter d’appuyer mollement, de façon modérée, apporte plus de sécurité, mais certainement pas moins d’effort. Quand Toyota réorganise une ligne de production pour augmenter sa rentabilité, il s’ensuivra moins de gestes de la part de l’opérateur pour effectuer la même tache. L’optimisation des processus conduit à une réduction de la quantité de travail pour le même résultat.

Comment justifier auprès d’un client que l’on s’est contenté d’utiliser les ressources à notre disposition de manière modérée ? Notre façon de travailler doit être optimisée continuellement pour permettre un rendement efficace de notre activité. L’informatique a besoin de ça. En tant qu’utilisateur quotidien des nouvelles technologies, n’êtes-vous pas fatigué de cette philosophie du “Good enough” [1] ?

Certains pourraient penser que l’eXtreme Programming est la galère du développement logiciel, les développeurs devant travailler au son des tambours rythmant les itérations toujours plus rapidement. Et bien non, il ne s’agit pas de cela même si l’expression “extrême” pourrait le laisser penser. Si vous désirez trouver une image mentale plus cool, pensez par exemple aux sports extrêmes. Imaginez un informaticien qui sauterait d’un immeuble avec un parachute et un ordinateur portable et qui écrirait un programme tout en tombant en chute libre avant d’ouvrir son parachute in extrémis. Tout le monde sait que ces sports spectaculaires ne contiennent en fait qu’un risque mesuré pour les sportifs. Il faut être préparé, mais cela est naturel pour ces professionnels du sport.

Avec l’eXtreme Programming, vous allez pouvoir coder dans une maison en feu ! C’est une méthode agile et elle permet de développer un logiciel dans un environnement où les spécifications sont floues et changeantes… n’est-ce pas une maison en feu ? n’est-ce pas un sport extrême ? Certaines pratiques telles que le binômage, l’automatisation des tests, l’intégration continue, permettent de gérer avec beaucoup plus d’efficacité la crise probable de la fin de projet ! Alors pourquoi se priver de cet extrémisme ?

Il est vraiment dommage que ce terme “extrême” ait une si mauvaise image. Dans mes essais à venir, je ferai attention de l’utiliser associé à des adjectifs positifs pour lui donner une meilleure connotation. (Il est extrêmement utile de… Il faut faire extrêmement attention à…)

[1] Good enough software : du logiciel suffisant

J’ai eu l’occasion, il y a déjà quelque temps, de participer à une réunion avec un client. Il s’agissait de nous présenter le projet pour nous permettre de bâtir notre réponse à appel d’offre.

Le client avait eu une expérience de projet réussi ayant utilisé la méthode Extreme Programming, et nous espérions pouvoir vendre notre capacité à monter ce nouveau projet en utilisant cette méthode.

L’ordre du jour de la réunion était en partie de déterminer si nous présenterions un projet “Full XP”, “partiellement XP” ou simplement “standard” (Cycle en V).

Le client nous a rapidement fait sentir qu’il aimerait bien faire du Full XP. Sans doute avait-il entendu dire que cette méthode ne révèle son potentiel qu’à condition de l’appliquer dans son intégralité. Il nous fournirait une personne devant jouer le rôle de client, nous fournirions tous les autres postes : développeur, coach et testeur.

L’affaire s’annonçait rose…

Le sujet du projet était de développer la partie cliente d’un système de communication basé sur un protocole standard dont je ne me souviens plus du nom.

client : – Pour la spécification, pas de problème, vous aurez toute la spécification de la norme.

fournisseur : – Quel partie du protocole devrons nous implémenter en particulier

client : – la norme définit clairement et intégralement le contenu fonctionnel du projet

fournisseur : – Mais comment pourrons-nous savoir ce qui importe le plus, ou le moins dans ce protocole.

client : – Ah, vous faites référence à cette pratique de descopage [1] !

fournisseur : !!!

Et voila, fin de la discussion. Nous n’étions pas près de faire du full XP… La suite n’a pas été meilleure, nous n’avons pas su vendre de l’Extreme Programming. Nous avons essayé de faire un mixte catastrophique inspiré d’XP, ajouté d’une charge documentaire comme on en trouve dans un cycle en V, avec spécification système, spécification logiciel détaillée, documents de tests, plan de developpement sous MS Project…

Nous n’avons pas obtenu le projet.

Conclusion : Le client était peut-être prêt pour XP, mais pas nous. Quand on vend de l’XP, il n’y a pas de solution intermédiaire. On ne peut pas céder sur les fondamentaux. Si on veut vendre de l’Agile, il faut en comprendre l’essence.

Comment charger sa voiture pour les vacances

Cette année, je suis parti en vacances au mois d’aout et il a fait un temps pourri, mais là n’est pas la question. Je suis parti en voyage une semaine avec ma petite famille (ma femme et mes deux enfants de 5 mois et 3 ans) dans ma Clio.

Question, comment emmener tout ce qu’il faut dans aussi peu d’espace.

Réponse : faire du descopage ? Est-ce que cela veut dire que nous allons manquer de quelque chose ? Est-ce que cela veux dire qu’on va laisser un de nos enfants à la maison ?

Mais non, t’inquiète pas mon bonhomme, on t’emmène bien sur.

Non, la réponse, c’est qu’il faut ajuster nos valises à notre capacité de transport. Ce que nous voulons, c’est un moyen de remplir la voiture au maximum… Ou devrais-je dire au plus juste !

Comment faites vous ? Est-ce que vous ouvrez un document word pour lister toutes les choses que vous voulez prendre, puis calculez pour chaque chose, son volume, puis à l’aide d’un logiciel (Microsoft-Project ?) trouvez la solution optimum ?

Non, vous commencez par charger la voiture avec les choses essentielles, peut-être faites-vous un compromis sur certains gros trucs ? Est-ce qu’on emmène le lit parapluie ? La poussette ? Peut-être que le landau de la poussette pourrait faire office de lit, non ?

Ensuite, on remplit avec les petites choses, on peut aussi faire des petits sacs à fourrer dans les coins.

Bref, on remplit sa voiture de manière itérative. Il suffit de jeter un coup d’oeil dans l’habitacle après chaque ajout pour savoir s’il reste de la place. Il faudra parfois ressortir un gros truc qu’on décidera de ne pas emmener finalement.

Oui, mais pour un projet informatique, il faut pouvoir dire à l’avance ce que l’on va faire, combien ça va couter…

Pour les voitures, on sait bien qu’il faut 1 heure ou 2 pour charger mais sans doute pas plus. La voiture a une capacité fixe de toute façon ! N’est ce pas pareil pour les projets informatiques ? Les managers n’ont pas leur pareil pour estimer “grosses mailles”. Cela ne suffit-il pas ? Donner plus de précision est bien souvent très prétentieux de toute façon.

[1] “descopage”, ce mot est utilisé ici comme un MotArme