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.

Après quelques considération d'ordre général sur la conception émergente, il est temps d'entrer dans le vif du sujet. Comme prévu, nous allons essayer de faire émerger la "conception" du code que nous allons écrire. Comme nous en sommes au début du projet, nous n'avons aucune base sur laquelle ancrer notre code mais ce n'est pas grave. L'essentiel est de faire un peu de conception sur papier -- suffisamment pour démarrer l'écriture d'un premier test. Le TDD fera le reste. Le premier scénario à implémenter est "L'utilisateur s'abonne à un flux de podcast et visualise la liste de ses éléments". Nous allons donc commencer par en proposer une représentation simple sous forme de diagramme de séquence, puis, nous implémenterons la logique de ce scénario à travers un ensemble de composants mis en évidence par le diagramme.

Thanks to Jeremy D. Miller I just discovered a place that is worth a web surf: Process, People, and Pods. Fred George started to blog less than a month ago and, in a few articles, he described the very nature of agile software development.
From agility inner secret to encounters of the third kind (of developers) and path to development wisdom, we go through all what we would like to tell about our jobs if we knew the words for that.

Oh, and did I tell you about the pods? You should really read those ones too!