Retour sur Sophia Conf 2011, soirée Developpement Agile

En mission sur Draguignan les 7 et 8 juillet dernier, j'en ai profité pour assister à la soirée Développement agile du 7 juillet à Sophia Conf 2011. Voici un petit retour basé sur les notes que j'ai pu prendre pour compléter mes visions.

"Scrum Masters" par Véronique MESSAGER, Ici et demain

Véronique n'a pas pu venir à la conférence (problème de santé). Dommage, j'avais vu en vidéo sa présentation, mais je l'aurais bien revu "en live", ça fait toujours du bien.

En tout cas, les organisateurs ont bien géré cette absence, notamment Eric BARTHELEMY qui a fait une présentation rapide de Scrum.

"Scrum" par Eric BARTHELEMY, ViaXoft

Finalement, à en faire moi-même, je me rends compte qu'il n'est pas si facile de présenter l'agilité et Scrum en quelques minutes, surtout pour faire passer les messages forts et importants. Et de ce point de vue, Eric s'en sort bien !

Voici quelques idées fortes à retenir (NDLA : en plus des infos habituelles que je ne rappelle pas ici) pour différents aspects de la méthode ...

Product Owner :définit les fonctionnalités du produit
ScrumMaster : S'assure que l'équipe est complètement fonctionnelle et productive, doit faciliter une coopération poussée entre les rôles et les fonctions
Equipe : regroupe tous les rôles (architecte, concepteur, développeur, spécialiste IHM, testeur, ...), elle doit être stable pendant une itération (NDLA : et même pendant plusieurs itération si on veut travailler en points et vélocité)
Backlog Produit : on oublie les spécifications fonctionnelles et les spécifications fonctionnelles détaillées, on utilise un langage utilisateur
Sprint 0 : mise en place technique
Histoires (User Stories) : découpées en tâches inférieures ou égales à 16h lors de la réunion de lancement de sprint
Backlog de Sprint : c'est le périmètre d'une itération

Eric a bien sûr présenté tous les concepts de base de Scrum que je ne reprends pas ici.

"Outils et méthodes pour automatiser les tests" par Benoit GANTAUME, AGILIDEE

Le format de présentation adopté par Benoit change un peu des habitudes puisqu'il n'a pas de diaporama et écrit quelques informations clés sur un tableau papier. Ce qui est marrant, c'est d'observer le silence et l'attente de l'auditoire pendant que Benoit écrit ... Tadaaa ...

Après quelques sondages et blagues, Benoit rappelle les règles du TDD :

1. Du code n'est écrit que pour faire passer les tests
2. On fait passer le test le plus vite possible
3. On supprime toutes les duplications (refactoring)

Dans une premier temps, j'ai mal compris le point 2), probablement par une récente intervention en entreprise où j'insistais sur le fait que les tests doivent s'exécuter rapidement (quelques secondes par test). C'est vrai ! Mais Benoit parlait plutôt de la phase d'écriture du code, avec l'idée de faire passer le test sans se soucier, dans un premier temps, de la façon, propre ou non, de le faire. Une fois que le test passe, on peut alors se repencher sur son algorithme pour l'optimiser, le rendre plus propre, plus efficace, ...

Le point 3) m'a également surpris, car pour moi, il ne faut pas se limiter aux duplications. Benoit fait bien d'insister sur ce point trop souvent négligé, surtout pour des duplications parfois "cachées". Mais pour moi, il est également très important, avant de passer au test suivant, de rendre son code propre, lisible, beau !

Benoit a rappelé le principe des coûts de changement, exponentiel avec le temps dans une conception classique. L'idée intéressante est que le TDD va améliorer ce rapport coût/temps, en le rendant plus proportionnel que exponentiel, et donc pas nul comme on pourrait parfois l'imaginer ou le laisser croire ...

J'ai bien aimé l'image proposée par Ken Beck "du sceau et du puit", malgré un enthousiasme mitigé de l'auditoire. L'idée est simple. Pour remonter une sceau plein dans un puit avec une corde, il est impossible de relâcher la corde et donc son effort, analogie avec les méthodes classiques, il faut aller au bout. Le TDD c'est la "roue crantée" où passe la corde du puit, permettant à volonté de relâcher la corde pour se reposer et repartir de plus belle. J'aime bien cette image de progression paisible grâce au TDD, c'est vraiment ça ! Mais peut-être faut-il l'avoir vécu pour comprendre cette image ?

Je retiens la phrase suivante "Concevoir pour aujourd'hui et coder pour demain" qui est tout le contraire des approches habituelles, où l'on pense concevoir l'architecture pour demain et le code pour aujourd'hui ... Le TDD est un investissement pour l'avenir !

Après une démonstration basique ;-), Benoit termine sa présentation par les limites du TDD : coût d'apprentissage, coût du changement (de code) non nul, rigueur, .... et une idée intéressante à laquelle j'adhère, et qui peut expliquer certaines difficultés pour certains développeurs, avoir des compétences en design pour une véritable approche TDD.

"Scrum et pratiques d'ingénierie associées" par Eric BARTHELEMY, ViaXoft

Eric a fait un retour d'expérience de la mise en oeuvre de Scrum au sein de sa société Viaxoft.

On retrouve là des facteurs d'échecs qui commencent à être connus :

• Backlog trop détaillé (dans un premier temps)
• Manque de vision à moyen et long terme
• Difficulté à savoir ce que vaut 1 point (nécessité d'un référentiel)
• Réunions de planification (Planning pocker) trop longues, discussions sans fin, nombreuses interruptions (hot-line)
• Problèmes avec le développement incrémental, pas si évident, difficulté à trouver la bonne pratique, peur du PO que la fonctionnalité ne soit jamais faite jusqu'au bout
• Difficulté pour appliquer les plans d'actions issus des rétrospectives
• Attention aux démarrages avec une équipe non complète, difficulté d'intégration d'une nouvelle personne, éviter les temps partiels
• ...

Quelques retours de bonnes pratiques :

• Mise en place d'un objectif par sprint
• Trouver la bonne durée de sprint
• Améliorer la gestion de la parole lors de la mêlée quotidienne (utilisation d'un objet pour le tour de parole)
• Détachement chaque jour d'une personne pour la hot-line
• Nommage d'un responsable par sprint pour la revue et la démo, garant de la préparation
• Implication forte du client très présent créant un stress bénéfique
• ...

Eric nous présente sa "boite à outils" pour l'agilité :

• Un responsable par sprint
• Intégration continue
• Tests fonctionnels croisés entre développeurs
• Tâches testables
• Pair-programming (décidé lors des mêlées quotidiennes)
• Propriété collective du code
• Avoir un ordre dans les tâches (identifier les tâches prioritaires)
• Refactoring
• Standard de codage
• ...

Une remarque intéressante sur le refactoring : devrait être un besoin de la direction générale, plutôt qu'un besoin technique, car le refactoring favorise la pérennisation des développements !

En conclusion, Eric rappelle que l'agilité n'est pas facile, et qu'il est intéressant de mixer plusieurs méthodes, notamment Scrum et XP : nous sommes bien d'accord !

Merci aux organisateurs et aux présentateurs pour cette bonne soirée !