Je ne sais pas si c'est dû au cycle lunaire ou à quelque chose du même genre mais j'observe une floraison de billets "polémiques" sur les blogs traitant de méthodes agiles. Là, il s'agit de l'éternelle méfiance des agilistes envers les phases trop grosses de modélisation (le Big Design Up Front comme on dit) et, par extension, envers les approches de "développement piloté par les modèles".

Emmanuel Chenu écrit 2 billets pour réagir à un article de "Programmez!" et confronter l'agilité avec le pilotage par les modèles. Le touilleur express en rajoute une couche sur les promesses de maintenance facilitée par ces approches.

Les adeptes de méthodes agiles utilisateurs de la version française de wikipédia auront peut être remarqué un assez curieux historique sur les entrées concernant les méthodes agiles et Scrum en particulier : la méthode "RAD" de James Martin serait à l'origine des méthodes agiles !
Claude Aubry explique comment cette information a induit en erreur un très sérieux journal d'informatique.

J'ai pris l'initiative de supprimer la plupart des références abusives sur la fiche de Scrum. L'auteur de ces références n'a visiblement pas aimé la manoeuvre.

L'étape toulousaine de l'Agile Tour 2008 a attiré plus de 200 personnes. Un des points culminants de l'après-midi était la présentation par Claude Aubry et Philippe Krutchen de l'agilité en situation qui traitait del'adaptation des méthodes agiles à un contexte.

De nombreuses personnes ont assisté à cette présentation. Certaines connaissaient déjà bien les méthodes agiles, d'autres les découvraient. Quel impact a pu avoir une telle présentation ?

I watched a great presentation by Jeremy D. Miller : How does design get done on an Agile Project ?.

Jeremy shows through multiple examples the kind of design issues you inevitably face during an project and explains how to handle them in an agile way.

Au SigmaT 5, Pascal Bruyez a présenté un retour d'expérience sur l'utilisation de Scrum pour la refonte du site communautaire Planetsagem.

Voici les 4 vidéos prises à cet occasion.

Pour plus d'info, voir sur le blog de Pascal.

Un petit billet sur ce blog en sommeil depuis bien longtemps pour signaler que le vendredi 28 mars se tiendra la 5ème édition du Séminaire d'Information Gratuit sur les Méthodes Agiles de Toulouse.

Tous les détails utiles sont chez Claude.

Depuis notre précédente livraison, notre logiciel peut être considéré comme acceptable pour une utilisation basique : lister le contenu d'un podcast audio, sélectionner un morceau et l'écouter. C'est là une des forces de l'agilité : fournir rapidement un système ayant une réelle utilité tout en garantissant que ce système va pouvoir aisément évoluer par rajout (sans douleur) de nouvelle fonctionnalités.
C'est ce que nous allons faire aujourd'hui pour continuer notre aventure de conception émergente. Le problème récurrent de notre utilisateur est qu'il doive sans cesse saisir l'URL de son podcast à chaque lancement du logiciel. Cela devient vite laborieux et son besoin le plus prioritaire est donc que le logiciel mémorise cette URL.

Septembre, la fin de l'été (a-t-il vraiment commencé ?), la rentrée des classes...

Les agilistes du sud-ouest font aussi leur rentrée. Cela se passera le 21 septembre dans un amphi de l'université Paul Sabatier pour le 3ème "Séminaire d'Information Gratuit sur les Méthodes Agiles de Toulouse".
Toutes les informations utiles sont chez Claude Aubry avec entre autres le programme bien garni de cette rencontre. J'aurai, par ailleurs, le plaisir d'y faire une intervention sur la conception émergente.

Après avoir terminé l'implémentation de notre 1er scénario, nous sommes presque sur le point de pouvoir livrer une 1ère version de notre logiciel. Notre client ayant mis en évidence un cas d'utilisation non couvert par nos tests, nous allons nous empresser de rectifier le tir. J'entends déjà les esprits chagrins se lamenter "Voilà ce qui arrive quand on veut laisser émerger la conception au lieu de bien réfléchir avant de se lancer dans le codage !" J'ai envie de leur répondre que, permièrement, en se contentant de réfléchir sur papier, on a bien peu de chances de découvrir les cas limites. En l'occurrence, le client n'a vu le problème que parce qu'il avait le logiciel définitif devant lui et non pas des diagrammes à l'exécutabilité hypothétique ou une vulgaire maquette. Deuxièmement, moi, au moins, j'ai déjà un logiciel près d'être livré. Si j'avais passé mon temps à "concevoir" dans un état de pure abstraction, j'aurais gaspillé une bonne partie de mon temps.
Ceci étant dit, retournons au travail. Une URL invalide saisie comme source pour notre podcast fait planter le logiciel et cela n'est pas acceptable.