L'Agilitateur - En français

Agilité on the road again

Oaz — Thu, 15 Oct 2009 13:38:00 +0200

Comme l'an dernier, l'agilité fait son tour de France et même son tour du monde.

Le 22 octobre, dans une semaine, c'est l'étape toulousaine. J'aurai le plaisir d'y animer un atelier sur le développement logiciel piloté par les tests. Il y aura bien évidemment de nombreuses interventions comme en atteste le programme de la journée.

Experienced Extreme Programmer

Oaz — Tue, 07 Apr 2009 01:00:00 +0200

Quelqu'un qui prétend s'y connaitre un peu en méthodes agiles sans logo "Certified ScrumMaster" sur son blog, ça ne fait pas vraiment sérieux. Mais comme cette "certification" ScrumMaster ce n'est pas vraiment très sérieux non plus, il fallait trouver autre chose.

Emmanuel Chenu a la solution : sa proposition de logo autoproclamé "Experienced Extreme Programmer" est tout à fait ce qu'il me fallait.

Pas de taches dans les sprints

Oaz — Mon, 06 Apr 2009 01:01:00 +0200

Une fois n'est pas coutume : je suis d'accord avec Jeff Sutherland :

The best teams I work with burn down story points. They only burn down when a story is done.

Quand on arrive à travailler avec demandes du client suffisamment élémentaires^[1] et ayant une cohérence intrinsèque^[2], il n'y a plus de raison pour gérer un sprint en planifiant des taches.

D'ailleurs, un burndown de sprint en taches est une véritable hypocrisie. Si un sprint ne comporte qu'une seule histoire utilisateur et que ce sprint est planifié en 10 taches, le burndown qui montre les 9 premières taches terminées n'apporte aucune valeur. Si la 10ème tache est nécessaire à la finition de l'histoire utilisateur, l'équipe n'a produit aucune valeur tant que cette dernière tache n'est pas terminée.

Notes

[1] c'est à dire ayant des tailles leur permettant de rentrer à plusieurs dans un sprint

[2] ce qui signifie que leur valeur ajoutée ne dépend que d'elle même et de l'existant

J'ai enfin ma certification de spécialiste en méthodes agiles

Oaz — Wed, 01 Apr 2009 14:38:00 +0200

Il m'est arrivé de dire du mal des certifications pour tout ce qui concerne le développement logiciel. Je reconnais que mes reproches sur le manque de sérieux d'un diplôme obtenu en 2 jours intenses n'étaient pas toujours justifiés.

Après avoir longtemps hésité, j'ai fini par franchir le pas et me voilà désormais "Certified Agile Software Specialist". Si, comme moi, vous voulez bénéficier d'une certification reconnue internationalement et recommandée par les plus éminents membres de la communauté agile, n'hésitez pas : http://www.agilecertificationnow.com/.

Les deux sortes de TDD

Oaz — Tue, 31 Mar 2009 00:35:00 +0200

Le Développement Dirigé par les Tests est une des pratiques emblématiques d'Extreme Programming. A ce titre, elle est devenue un passage presque obligé pour quiconque envisage d'évoluer vers les méthodes agiles.

Le problème avec les pratiques disruptives, c'est que, lorsqu'elles viennent s'insérer dans un contexte existant, leur mise en oeuvre peut souffrir d'approximations. Les méthodes agiles font face, bien plus que d'autres, à ce genre de mésaventures : la faiblesse dans la prise en compte des pratiques d'ingénierie est une réalité.

Vendredi dernier j'assistais à la 9ème édition des séminaires SIGMAT. Une bonne cuvée comme en attestent les compte-rendus d'Antoine ou de Laurent.
Sur la présentation d'Atchick Realtime, un paragraphe a retenu mon attention :

TDD (pour les tests manuels) à Toulouse (2 testeurs), pas de testeur à CPH => pas de TDD au sens des tests manuels. Sur les deux sites : tests unitaires

Pour quiconque ayant déjà expérimenté le TDD, cette formulation a de quoi laisser perplexe. Renseignement pris auprès des personnes concernées, leur pratique consiste, au sein d'une itération, en :

l'écriture de fiches de tests par les testeurs avant que le code correspondant soit écrit
l'écriture du code
la vérification par le test prévu

Rien à redire à ce genre de pratiques. Il est toujours préférable que l'on sache comment vérifier du code avant de l'écrire. Cela améliore le feedback sur le produit développé et la communication entre ceux qui savent ce que le logiciel doit faire et ceux qui l'écrivent.
Rien à redire à ce genre de pratiques, si ce n'est que ce n'est pas du TDD.

Alors, bien sûr, en écrivant les tests avant le code, on peut dire que le développement est piloté par les tests. Oui mais à ce compte là, le cycle en V est lui aussi piloté par les tests puisque les tests sont écrits dans la descente du V, avant l'écriture du code, et joués lors de la remontée du V.
Ce qu'il ne faut pas oublier, c'est que l'apport principal d'Extreme Programming, c'est d'avoir poussé à l'extrême des pratiques existantes. En l'occurrence, le TDD, c'est la contraction dans un laps de temps le plus court possible de ces phases "écriture de test-écriture du code correspondant-vérification du test". En pratique, ce genre de cycle est exécuté plusieurs fois par heure.

Pour rendre cette contraction possible, il faut s'affranchir de quelques contraintes. Une communication trop formalisée entre un testeur et un codeur ne permettrait pas de maintenir le rythme. La seule solution pour pratiquer le TDD c'est de mettre devant le même écran la ou les personnes qui vont faire fonctionner ces cycles de test-codage à haute fréquence.
Le corollaire de cette approche, c'est que le codeur et le testeur sont bien souvent obligés d'être des rôles tenus par les mêmes personnes : des développeurs, au sens le plus large possible du terme.

Pour être compris, le TDD souffre d'un grand handicap : la lettre T comme "Test". Le TDD n'est pas une pratique de test. Le TDD n'est pas une pratique de test. Le TDD n'est pas une pratique de test. (quelquefois c'est en répétant plusieurs fois les choses que l'on arrive à s'en souvenir). Le TDD est une pratique de développement logiciel, c'est à dire de conception d'un produit à partir de contraintes.
C'est une des raisons qui font que je préfère désormais le terme BDD à celui de TDD.

Ceci étant, deux sortes de TDD vont encore cohabiter pendant longtemps : celle de ceux qui l'ont compris et celle de ceux qui ne l'on pas encore compris.

Société des Innovateurs pour la Généralisation de Méthodes Agiles de Toulouse

Oaz — Thu, 26 Mar 2009 13:32:00 +0100

Lu sur le Journal Officiel

No d'annonce : 279
Paru le : 28/02/2009

Association : SOCIETE DES INNOVATEURS POUR LA GENERALISATION DES METHODES AGILES DE TOULOUSE (S.I.G.M.A.T.).

Identification WALDEC : W313011297

No de parution : 20090009
Département (Région) : Haute-Garonne (Midi Pyrénées)

Lieu parution : Déclaration à la préfecture de la Haute-Garonne.
Type d'annonce : ASSOCIATION/CREATION

Déclaration à la préfecture de la Haute-Garonne. SOCIETE DES INNOVATEURS POUR LA GENERALISATION DES METHODES AGILES DE TOULOUSE (S.I.G.M.A.T.).
Objet : fédérer et faire connaître les acteur de l’agilité de Toulouse et sa région, informer et initier aux méthodes agiles les personnes désireures de les découvrir, favoriser l’adoption des méthodes agiles dans le tissu économique régional.
Siège social : Hoegaarden Café - La Chunga, 52, route de Narbone, 31400 Toulouse.
Courriel : contact (at) sigmat.fr.
Site Internet : http://www.sigmat.fr.
Date de la déclaration : 9 février 2009.

Ca y est. L'association SIGMAT existe désormais officiellement !
Les inscriptions sont déjà ouvertes. On peut même s'inscrire en ligne.

Et bien sûr les séminaires trimestriels continuent. Le prochain, c'est demain, vendredi 27 mars, et il reste encore quelques places.

Architecte logiciel et agilité : c'est pas gagné...

Oaz — Wed, 25 Mar 2009 09:53:00 +0100

Offre d'emploi Architecte logiciel

Au sein d'une équipe, vous êtes en charge de l'architecture technique du Pôle Système d'Information de notre client. Vous assurez la définition des recommandations et bonnes pratiques architecturales et de développement en environnement Microsoft, spécialisé .net. Vous mettez en place les nouveaux outillages de développement grâce à votre expertise (intégration continue, tests) avec une sensibilité pour les méthodes agiles. Vous étudiez et qualifiez l'introduction de nouveaux produits et frameworks au sein du système d'information de notre client.

Il n'y a pas beaucoup d'offres d'emploi qui mentionnent explicitement les méthodes agiles mais quand on en voit comme celle-là, on se dit que, finalement, ce n'est pas plus mal.

L'oryzus n'est toujours pas en voie d'apparition dans les ressources humaines.

Allo ? C'est pour un sondage !

Oaz — Thu, 08 Jan 2009 00:33:00 +0100

Denis Dollfus, avec qui j'ai eu le plaisir de travailler il y a quelques années chez Reuters, lance une enquête sur l'état d'agilité des projets de développement logiciel en France.

J'encourage tous ceux qui font du développement logiciel à y répondre, même s'ils n'ont jamais entendu parler "d'agilité".
En fait, l'info qui serait intéressante c'est la comparaison entre les résultats obtenus au test et le résultat attendus par les intéressés.

En ce qui me concerne, pas de surprise. Je savais que les questions 18 et 24 m'empêcheraient d'atteindre le 100%

Ceux qui ont réussi à atteindre le point (0,0), je les soupçonne d'avoir joué à chercher la réponse "qu'il ne faut pas donner". Quant à ceux qui dépasssent les 80% en ingénierie mais restent à zéro en management, je serais très curieux de voir comment ils fonctionnent...

Videos de Noël

Oaz — Wed, 24 Dec 2008 00:07:00 +0100

Deux videos du dernier SigmaT, le 8ème du nom, sont en ligne. Celle de Claude Aubry n'est pas encore disponible car il est AFK.

Il y a donc celle de Pascal Roques qui nous a parlé de modélisation agile et que j'ai vraiment apprécié. Surtout quand elle permet de mettre en avant une idée toute simple : l'activité de modélisation en elle-même est au moins aussi importante que le résultat car elle permet à l'équipe de communiquer et de se forger une vision partagée.

Et puis il y a aussi la mienne sur l'utilisation de Scrum chez Varian Medical Systems :

Joyeuses fêtes et à l'an prochain pour de nouveaux billets, de nouveaux SigmaTs et plain d'autres choses !

Retour d'expérience

Oaz — Wed, 03 Dec 2008 01:40:00 +0100

Le prochain SigmaT aura lieu le vendredi 12 décembre à 16h00. J'y présenterai un retour d'expérience sur l'utilisation de Scrum chez Varian Medical Systems (dont j'avais évoqué les prémisses il y a fort longtemps).

Je pense avoir quelques trucs intéressants à raconter mais je préfère prévenir que cela risque de ne pas être aussi passionnant que le retour d'expérience XP chez Igeoss. Je viens d'ailleurs de mettre en ligne la prestation de David Desmarest que j'avais filmée lors de l'Agile Tour.

Les autres interventions filmées le 16 octobre ne sont malheureusement pas encore disponibles pour des raisons techniques (mon camescope m'a laché avant que je puisse les récupérer).

Agilité, modélisation et méta-programmation

Oaz — Wed, 19 Nov 2008 00:04:00 +0100

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.

Il ne faut pas être trop sévère avec ces approches. Faire des boites et des flèches à la place d'écrire du texte ne serait pas mauvais en soi si l'on avait des moyens de le faire incrémentalement et en étant piloté par des tests (là je fais de la spéculation).

Ce qui bloque vraiment dans cette démarche, à mon avis, c'est quand on se met à considérer tout ça comme de l'outillage qui va générer du code sur lequel on va (éventuellement) intervenir manuellement. Il y a toujours cette ambiguïté entre conception et code qui déforme la vision de ce qu'est le développement logiciel. On ne le répètera jamais assez : "The source code is the design". Le code, c'est la conception, et on ne génère pas une conception : on la conçoit !!!
Le code généré doit être considéré comme du langage machine généré par un compilateur. Le modifier n'est pas une option acceptable car on ouvre alors une brèche sur un gros paquet de problèmes : la lisibilité de l'intention du développeur, la duplication des référentiels et la robustesse de la chaîne de conception.

Si toutes les conditions étaient acquises et si les outils étaient au rendez-vous, il faudrait peut être reconsidérer la chose. Mais la vraie question qui devrait être posée dans un tel contexte, c'est "est-ce que je ne peux pas faire la même chose avec des approches bien plus naturelles pour un développeur et permettant une expression plus riche ?"

Les modèles et les diagrammes, c'est sympa pour montrer des ébauches ou pour avoir une vision de haut-niveau forcément partielle. Quand il s'agit de concevoir réellement une application avec précision, quand il s'agit de raconter des histoires dans le détail, rien ne vaut l'alphabet et le texte.

Il y a environ 10 ans (le temps passe...), je travaillais sur un projet où l'on avait fait le choix de modéliser la majorité de l'application en UML avec Rational Rose et de générer le C++ qui pouvait l'être (je n'étais d'ailleurs pas étranger à cette direction). J'avais écrit un add-in afin d'avoir une génération suffisamment "intelligente". Elle était basée sur un ensemble de stéréotypes UML qu'il suffisait d'attacher à chaque classe pour lui adosser une certaine interface ou un certain comportement.

Mais c'était il y a fort longtemps. Plus tard, j'ai découvert le "modern C++" d'Andrei Alexandrescu et le Policy based design et je me suis dit qu'un grand nombre des bénéfices de la génération de code étaient en fait à la portée du langage lui-même.

Enfin, j'ai découvert toutes les techniques "récentes" de méta-programmation, la programmation orientée aspects, et tout ce que l'on peut faire avec les attributs de C# ou les annotations de Java.
Et là je suis définitivement convaincu : dessiner à la main des boites et des flèches, que ce soit avec un crayon ou avec une souris, c'est vraiment très rudimentaire quand on a sous la main tout ce qu'il faut pour exprimer la même chose de manière bien plus concise à l'intérieur du langage lui-même.

Je sais bien que je fais là un raccourci un peu facile. Des puristes pourront même, par exemple, objecter que des croisements existent entre les approches puisque l'on en vient à évoquer la modélisation orientée aspects. Mais tout ça reste encore très académique, au sens où cela n'est pas prêt de rejoindre le quotidien de la masse des développeurs.

Mon principal sentiment vis à vis des techniques actuelles qui vont au delà de l'écriture de code au kilomètre, c'est qu'il y a plusieurs approches pour exprimer des conceptions de manière plus synthétique, des conceptions de "plus haut niveau" pourrait-on dire.
Les approches purement textuelles et intimement liées au langage de développement, grace à leur référenciel unique (le code source), leur lisibilité (le code source est le langage "maternel" du développeur) et leur testabilité (c'est du code donc ça se teste comme le reste du code) me paraissent plus aptes à favoriser l'agilité.

De bien belles perspectives pour les consultants en méthodes agiles

Oaz — Mon, 17 Nov 2008 18:04:00 +0100

Ce n'est pas moi qui le dit, c'est James Shore dans son dernier billet. "Rescuing Scrum teams keeps me in business" avance même un de ses collègues.

La raison ? L'engouement pour Scrum a fait que nombre d'équipes insuffisamment préparées se retrouvent dans des situation inextricables de dette technique. Ils ont naïvement cru que l'on pouvait tirer bénéfice d'une gestion de projet agile sans en payer le prix.

La plus grosse erreur que peut commettre une équipe qui passe à Scrum est de croire que Scrum "seul" suffit à organiser efficacement un développement logiciel. Faire des itérations, construire un produit de manière incrémentale, améliorer la communication entre les intervenants, s'adapter aux besoins changeant. Tout ça c'est très bien mais on ne peut pas s'en contenter.

La clef d'un bon fonctionnement agile c'est d'être en permanence en situation de pouvoir faire toutes les modifications désirées sur un logiciel existant sans se retrouver dans des impasses. Pour cela, il n'y a qu'une solution : maîtriser techniquement le logiciel. Ceux qui espèrent tirer des bénéfices de Scrum en modifiant leur gestion de projet mais sans être prêt à assumer les conséquences techniques seraient bien avisés de revoir leur copie.

Développement agile ou pas, il est toujours souhaitable que les développeurs aient un minimum de cette maîtrise technique. Mais là où un développement en V ou en cascade réduit le risque de non-maîtrise par une réflexion accrue en amont (avec comme conséquence de ne pas être adaptable), le développement agile ne peut s'en sortir qu'avec une réflexion permanente. Etre agile, et donc assumer tous les changements incrémentaux, ça commence par une maîtrise de tous les instants. Cela demande bien plus d'efforts qu'une simple définition d'architecture en amont.

Dernièrement, j'ai assisté à une formation sur la conception d'applications web en java et le formateur a, à mon grand plaisir, introduit son sujet par ces mots "la seule chose qui m'intéresse, c'est la maintenabilité du code".
Au bout du compte qu'est ce que la maintenabilité si ce n'est "d'être en permanence en situation de pouvoir faire toutes les modifications désirées sur un logiciel existant sans se retrouver dans des impasses" ? Développer de manière agile, ce n'est jamais que baigner dans une situation extrême de "maintenance" où la plupart des fonctionnalités du logiciel ne sont pas encore parfaitement connues et où l'on veut pouvoir assurer une maintenance évolutive pendant un temps illimité.

Il y a, parmi les principes agiles, une phrase qui est bien trop souvent laissée de côté au profit de toute la mécanique itérative et incrémentale : "Continuous attention to technical excellence and good design enhances agility".
Il sera toujours temps de le rappeler aux équipes qui ont adopté les méthodes agiles en ne modifiant que leurs pratiques de gestion de projet.

"Responding to change over following a plan" : une idée neuve ?

Oaz — Sat, 15 Nov 2008 00:25:00 +0100

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.

Sur ma page personnelle wikipédia, il tente d'affirmer, une énième fois, que l'antériorité de la publication de J.Martin (1991) sur la notion de méthode "itérative, incrémental et adaptative" induit la filiation entre RAD et Scrum, pour ne pas dire avec l'ensemble des méthodes agiles.

RAD peut éventuellement être qualifié de méthode agile (je ne suis pas compétent pour confirmer ou infirmer une telle affirmation) mais de là à en faire la source d'inspiration des autres méthodes, il y a un fossé à franchir.
Le plus drôle, c'est que ce lien de parenté est limité au monde francophone : si on va sur le wikipédia anglophone, on ne trouve aucune trace d'une telle filiation !

Alors, Schwaber et Sutherland ont-ils pompé sur Martin sans le citer ? La réponse n'a que peu d'importance. Tous ces travaux datent de la même période et leurs influences sont forcément multiples.
La vérité, c'est que cette idée de prise en compte active du changement dans un projet logiciel est loin d'être neuve. Voici un texte dont je laisse aux lecteurs le soin de découvrir le nom de l'auteur et la date de publication. Après, on pourra reparler de la paternité des processus incrémentaux et adaptatifs...

La première étape est d'accepter le changement en tant que phénomène normal et habituel, au lieu de le voir comme un désagrément facheux et exceptionnel. [...] ce que le programmeur livre à un client est la satisfaction d'un besoin plutôt qu'un produit concret. Et ce besoin, ainsi que la façon dont il est perçu par l'utilisateur, changeront pendant que les programmes seront construits, testés et utilisés. [...] certains changements d'objectifs demandés par le client sont inévitables, et mieux vaut s'y préparer que de supposer qu'il ne s'en produira aucun.

Le Behaviour Driven Development ou l'art d'écrire des tests que tout le monde comprend

Oaz — Sun, 09 Nov 2008 00:47:00 +0100

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.

Je ne vais pas ici développer le BDD en long et en large. Il y a de très bon sites pour cela, http://behaviour-driven.org/ entre autres.

Un développeur qui commence à pratiquer le TDD y trouve rapidement un bénéfice : sa confiance dans le code ne cesse de grandir car il met en place des centaines de garde-fous qui, à tout instant, le remettent dans le droit chemin.
Dans un 2ème temps, au delà de cet aspect de contrôle des régressions, un développeur va trouver dans le TDD un bon moyen pour documenter son code : les tests sont alors des exemples d'utilisation. Mais ce n'est que lorsqu'on approche le TDD comme technique de conception que l'on peut en mesurer toute la puissance.

Le BDD est l'évolution naturelle du TDD. Le pilotage par les tests permet littéralement de découvrir les interfaces du code à écrire. Et c'est là que le BDD entre en action en proposant un canevas : "étant donné un contexte, si un évènement survient, alors le système vérifie un certain nombre de conditions".

Prenons un exemple. Une fonctionnalité de mon système consiste à fournir le transfert d'argent d'un compte épargne vers un compte courant.
Pour le tester, je peux donc décrire un contexte :

Si le compte épargne est en crédit de 100
Et le compte courant est en crédit de 10

Puis initier un évènement :

Quand je transfère 20 vers le compte courant

Et enfin vérifier le nouvel état du système :

Le solde du compte épargne est 80
Et le solde du compte courant est 30

Un test facilement lisible va respecter ces étapes. Par exemple, en C# avec NUnit, je peux décrire mon contexte initial sous la forme d'un héritage de classes (une classe par condition initiale) :

namespace SiLeCompteEpargneEstEnCreditDe100 {
  public class C_SiLeCompteEpargneEstEnCreditDe100 {
    protected Compte leCompteEpargne;
    public void Given() { leCompteEpargne = new Compte() { Solde = 100 }; }
  }
}

namespace SiLeCompteEpargneEstEnCreditDe100.EtSiLeCompteCourantEstEnCreditDe10 {
  public class C_EtSiLeCompteCourantEstEnCreditDe10 : C_SiLeCompteEpargneEstEnCreditDe100 {
    protected Compte leCompteCourant;
    public void Given() {
      base.Given();
      leCompteCourant = new Compte() { Solde = 10 };
    }
  }
}

Pour que cette description de contexte compile, il me faut déclarer la classe Compte avec une propriété Solde : je viens de découvrir un "objet métier" de mon système.

public class Compte {
public int Solde { get; set; }
}

A partir de là, je peux écrire un test qui lance l'évènement de transfert de compte à compte :

Si je veux compiler ce test, il me faut enrichir ma classe Compte : je viens de découvrir le besoin d'avoir une méthode de transfert.

public class Compte {
public int Solde { get; set; }
public void TransfererVers( Compte unAutreCompte, int montant ) {}
}

Maintenant, je peux vérifier mes conditions :

namespace SiLeCompteEpargneEstEnCreditDe100.EtSiLeCompteCourantEstEnCreditDe10 {
  [TestFixture]
  public class QuandJeTransfere20VersLeCompteCourant : C_EtSiLeCompteCourantEstEnCreditDe10 {
    [SetUp]
    public void When() {
      base.Given();
      leCompteEpargne.TransfererVers(leCompteCourant,20);
    }
    [Test]
    public void LeSoldeDuCompteEpargneEst80() {
      Assert.That(leCompteEpargne.Solde, Is.EqualTo(80) );
    }
    [Test]
    public void LeSoldeDuCompteCourantEst30() {
      Assert.That(leCompteCourant.Solde, Is.EqualTo(30) );
    }
  }
}

En lançant, l'exécution du test, je découvre rapidement qu'elles ne sont pas satisfaites mais, au moins, je sais pourquoi : mes résultats de test ne souffrent d'aucun manque de lisibilité !

Pour faire passer mes tests, il me faut implémenter la méthode de transfert :

public class Compte {
  public int Solde { get; set; }
  private void AjouterAuSolde( int montant ) {
    Solde = Solde + montant;
  }
  public void TransfererVers( Compte unAutreCompte, int montant ) {
    if( Solde > 0 ) {
      unAutreCompte.AjouterAuSolde(montant);
      AjouterAuSolde(-montant);
    }
  }
}

Et voilà !

A noter que si j'avais été très rigoureux, j'aurais rajouté mes conditions à vérifier une par une et j'aurais écrit le code correspondant au fur et à mesure.

A l'usage, on constate rapidement que l'écriture de tels tests avec un outil de TDD "classique" est fastidieuse. Plusieurs toolkits ont donc vu le jour pour s'adapter à ce genre d'approche "contexte/évènement/vérification". La page anglaise du BDD sur Wikipédia en propose une liste.

Voilà donc, en quelques mots, comment le BDD apporte :

un canevas d'écriture de test proche du langage humain : la spécification exécutable n'est pas très loin tout en gardant un outil proche du développeur !
une démarche de conception logicielle pilotée par les comportements attendus du système.

A mon avis, le BDD peut apporter bien plus que ça, notamment en termes de documentation du système développé et de communication entre les intervenants.
A suivre dans un prochain billet... Stay tuned !

S'adapter au contexte

Oaz — Wed, 29 Oct 2008 08:02:00 +0100

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 ?

C'est en lisant la revue de cette présentation sur le carnet d'un informaticien que j'en redoute les effets négatifs :

J’ai été particulièrement satisfait de cette présentation. Premièrement parce qu’elle va à contre-courant de ce que j’ai souvent lu pour l’application des méthodes agiles, à savoir que la meilleure façon de mettre en place une méthode agile, c’est de commencer par appliquer toute la méthode, pour ensuite voir ce que l’on en retient. Aubry et Kruchten disent l’inverse. Et je dirai que c’est le bon sens même. Pour eux, il faut sélectionner les pratiques que l’on va mettre en place, en faisant une analyse de son contexte.

Je ne me fait pas de souci pour quelqu'un qui aura vu au moins une fois fonctionner un projet qui essaye d'appliquer l'ensemble des principes agiles. Mais cette idée de "les méthodes agiles passent partout puisqu'il suffit de s'adapter au contexte" me semble, sur le long terme, complètement dévastatrice.

Adapter ou utiliser tel quel, c'est un peu l'arlésienne des débats entre agilistes. Pour être honnête, prôner l'adaptation, je vois surtout ça comme le bon sens pour éviter d'effrayer le chaland et faire en sorte qu'une méthode telle que Scrum passe à peu près partout.

Quant à savoir si ceux qui adaptent avant d'utiliser pleinement ne loupent pas quelque chose, la question reste entière. Et c'est bien là le plus grand risque de l'adaptation au contexte : à force de compromis "faciles", en arriver à un truc qui n'a plus rien d'agile.
Alors adapter, oui, mais tant que cela reste réservé à des personnes qui savent ce qu'elles font et notamment des personnes qui adaptent quelque chose uniquement lorsqu'elle l'ont déjà utilisé tel quel dans un autre contexte.

Par ailleurs, je dirais que jouer le jeu de l'adaptation peut être le bon sens si, lorsqu'un problème de méthode survient (et il en survient forcément), l'attitude est "quelle adaptation abusive ai-je faite ? Il me faudrait la reconsidérer" plutôt que "quelle nouvelle adaptation me manque-t-il ?".
Et ne parlons même pas du "finalement, cette méthode agile, ça ne vaut rien" qui reste, au bout du compte, ce qui pend au nez des apprentis-adapteurs.

SigmAgileTour

Oaz — Tue, 15 Jul 2008 21:40:00 +0200

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

Vidéo : Forfait Scrum, l'agilité dans un cadre contractuel

Oaz — Mon, 12 May 2008 18:12:00 +0200

Au SigmaT 5, Benjamin Böhle-Roitelet a présenté un retour d'expérience sur l'utilisation de Scrum par la société Ekito dans un cadre contractuel à l'occasion d'un forfait pour Milan Presse.

Voici les 4 vidéos de cette présentation.

Les transparent sont téléchargeables sur le blog de Claude Aubry.

Vidéo : Scrum utilisé pour la refonte du site communautaire Planetsagem

Oaz — Mon, 12 May 2008 17:59:00 +0200

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.

XP Day France 2008

Oaz — Mon, 14 Apr 2008 21:36:00 +0200

Pour ceux qui ne seraient pas encore au courant, les 5 et 6 mai 2008 à Paris se déroule XP Day France 2008, les Journées d'XP et de l'agilité : http://www.xpday.fr/

Pour diverses raisons, je n'y serai toujours pas cette année mais je ne désespère pas de pouvoir m'y rendre un jour...

SigmaT 5

Oaz — Mon, 03 Mar 2008 23:23:00 +0100

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.