Agile France 2010

Agile France 2010

J’ai assisté ces derniers jours à la conférence Agile France 2010, 5ème édition de ce qui s’appelait « XP days » ces dernières années. Je vous livre ici mon ressenti sur ces deux jours de conférence que je considère comme un retour sur la situation de l’agilité en 2009. Pour situer un peu le contexte, j’y ai assisté en tant que Scrum Master/Développeur mais aussi dans une perspective future de coaching/accompagnement vers l’agilité.

La première chose marquante pour moi : sur plus de 60 présentations … à priori une seule a pour sujet principal Scrum et elle est annotée ‘Débutant’ ! Je me pose donc la question du pourquoi : est-ce que Scrum est déjà en cours d’abandon (les problèmes de certification lui ont certes causé du tort mais tout de même !) ? Devenu trop ‘mainstream’ pour qu’on ait encore des choses à dire dessus ? … Si vous avez des éléments de réponse, je suis preneur !

De même, les sessions sur la « vente » de l’agilité ont été plutôt rares (2 seulement) : l’agilité rentre dans les mœurs et il est devenu moins nécessaire de convaincre ?

En revanche le Lean s’est taillé la part du lion dans la catégorie ‘les bases des méthodologies’ pour une petite dizaine de présentations, associé à la bonne dizaine de sessions sur la transition de l’organisation vers l’agilité. C’est, il me semble, un point important à retenir : l’agilité commence à dépasser le cadre de l’équipe de développement pour s’installer dans les DSI en premier lieu et s’immisce doucement vers l’organisation de l’entreprise toute entière. Cela se fait principalement sur le constat suivant : les développements deviennent performants avec Scrum mais l’entreprise n’arrive pas à digérer cette performance, le lead time global peut difficilement changer si l’organisation n’est pas adaptée.

XP aussi est beaucoup ressorti, j’interpréterais cela de différentes façons : en premier lieu, la conférence s’est appelée XP Days pendant 4 ans, même si elle n’était pas exclusivement destinée à XP. Et puis c’est tout de même sur ces pratiques (plus que sur toute autre méthodologie … tiens, un élément de réponse 🙂 ) que les principes de l’agilité dans le monde du développement logiciel DOIVENT se reposer. L’accent a été mis sur les tests automatisés (10% des sessions) avec notamment le TDD qui commence à percer tout doucement. Et bien que ces pratiques soient globalement comprises elles restent toujours très peu mises en place.

Le dernier point que j’ai pu ressentir, certainement le plus important (pour moi étant donné mon profil mais aussi pour la réussite sur le long terme de projets de développement), c’est l’accent mis sur l’équipe, ses interactions et l’amélioration de la communication, le tout à la limite du développement personnel. Mais aussi un retour qui émerge : l’agilité à plein régime c’est exténuant et tout le monde ne supporte pas la transparence et le courage requis ! Le tout couronné d’une keynote d’Esther Derby sur l’alchimie équipe/management où comment se faire confiance réciproquement.

Ce fut une expérience instructive qui m’a permis de prendre un peu de recul et d’entrevoir de nombreux pans de l’agilité, et tout cela dans un environnement propice aux échanges dans un coin de verdure en bordure du bois de Vincennes. Un grand merci aux organisateurs !

JUnit Rules

L’équipe de Kent Beck a récemment publié JUnit 4.7 qui n’apporte pas grand chose hormis la notion de Rule. Une Rule ressemble énormément à la notion d’intercepteur de l’AOP Alliance ou de TestExecutionListeners dans Spring.

A quoi celà peut-il servir en pratique? Dans les précédentes versions de JUnit 4, pour exécuter un traitement avant/après chaque méthode de test, on utilisait une méthode annotée @Before ou @After. Pour factoriser ce traitement sur plusieurs classes de tests, il fallait passer par une classe mère commune.

Dorénavant, on pourra isoler ce traitement dans une classe:

public class LogRule implements MethodRule {
    public Statement apply(final Statement base, final FrameworkMethod method, final Object target) {
        return new Statement() {
            public void evaluate() throws Throwable {
                try {
                    System.out.println("Begin " + method.getName() + " on " + target);
                    base.evaluate();
                    System.out.println("End " + method.getName() + " on " + target);
                } catch (Throwable ex) {
                    System.out.println("Exception " + method.getName() + " on " + target+": "+ex.getMessage());
                }
            }
        };
    }
}

puis le référencer dans un test, on ajoute un attribut public annoté @Rule:

public class ComplexTest {
    @Rule
    public LogRule logRule=new LogRule();
    @Test
    public void testAdd() { ... }
}

JUnit inclut quelques Rules basiques:

  • ExpectedException: vérifie qu’une exception est levée (généralise @Test(expected=...) à une classe de test)
  • Timeout: vérifie qu’un test ne dépasse pas une certaine durée (généralise @Test(timeout=...) à une classe de test
  • ExternalResource: base pour gérer une ressource: ouvrir/fermer une connexion par exemple
    • TemporaryFolder: créer/détruit un dossier temporaire pour les tests qui produisent des fichiers
  • TestWatchman: base pour observer l’exécution d’un test sans intervenir
    • TestName: donne accès au nom du test depuis la méthode de test
  • Verifier: base pour vérifier l’état de l’objet de test
    • ErrorCollector: recueille les erreurs sans interrompre un test

Gageons que des projets connexes à JUnit, comme DBUnit, tireront profit de cette notion.

Séminaire à l’Université de Savoie : tests automatisés et intégration continue

Voici un rêve qui vient de se réaliser : animer un cours à l’Université de Savoie aux étudiants de deuxième année de Master Technologies de l’information et des communications. Pour la petite histoire, j’ai suivi ce cursus il y a déjà quelques années.

Le séminaire portait sur la mise en place de tests automatisés et de l’intégration continue dans un projet de développement logiciel. Ce sont 2 sujets qui prennent toute leur importance dans un développement itératif et incrémental mais qui ne sont pas toujours traités dans un cursus universitaire. C’est là l’intérêt de la démarche de l’Université de Savoie: demander à des intervenants spécialisés dans le génie logiciel de venir partager des retours d’expérience avec les étudiants.

Seul bémol : cette intervention est arrivée un peu tardivement dans le cursus et les étudiants vont avoir du mal à mettre en place les bonnes pratiques présentées dans leur projet de fin d’année. L’année prochaine, on essaiera de la planifier un peu plus tôt. Il est également envisagé de programmer une journée de type « Travaux dirigés », dans laquelle les étudiants pourront se confronter concrètement à cette mise en place sous l’œil vigilant d’un consultant.