Une des règles de base du TDD, le dévelopement piloté par les tests, est "avant d'écrire une ligne de code, écrire un test qui ne passe pas". Le ligne de code sert ainsi à faire passer le test. Cette approche permet d'écrire le code le plus simple possible, au sens où celui-ci n'a aucune ligne superflue, et de découvrir facilement le code à écrire puisque celui-ci découle du test.

Tout ceci serait très facile si le problème de l'inception de code n'était pas repoussé vers les tests. Certes, on découvre facilement le code à écrire. Encore faut-il trouver le bon test à faire passer !
Le BDD, le développement piloté par le comportement ("behaviour") apporte une réponse à ce problème en proposant une structure des tests basée sur le comportement observable des éléments du système.

Le prochain SigmaT, 7ème du nom, aura lieu le 16 octobre prochain. Ce sera une édition spéciale : les festivités démarreront dès le début de l'après midi et ce sera l'occasion d'accueilir à Toulouse, l'Agile Tour.

Pour plus d'informations, il suffit de suivre l'actualité sur les sites sigmat.fr et agiletour.com. Et pour être sûr de ne pas rater l'évènement, on peut déjà s'inscrire (et c'est toujours gratuit).

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.

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.