[ScrumDay 2014] Retours de 2 conférences - Coaching & BDD

J’ai assisté aux ScrumDays 2014 qui se sont déroulés les 10 et 11 avril 2014 à Eurodisney.

Parmi les nombreuses conférences intéressantes, 2 ont retenu mon attention. En voici un résumé :

1. En tant que Scrum Master, je veux m’améliorer pour mieux coacher mon équipe avec Véronique Messager & 5 autres Scrum Master

Les 5 Scrum Masters présents travaillent sur un même plateau et pilotent différentes équipes.

Régulièrement ils se réunissent pour discuter de leur travail de Scrum Masters en tant que tel (et pas sur l’avancée des développements par exemple, ce n’est pas un point projet) et ont, au fil de l’eau, élaboré 52 points à suivre qui, selon eux, améliorent leur travail de Scrum Master (cela fait de 3 à 5 ans qu’ils occupent ce poste)

Durant la conférence, 3 thèmes ont été abordés. Chaque Scrum Master apportait son point de vue à tour de rôle. C’était très claire et en même temps me parlait vraiment puisque c’était le reflet de ce que je vis au quotidien. J’ai ainsi ainsi eu quelques piqûres de rappel (des petites pratiques que je n’utilisais plus avec l’équipe), ou des nouvelles idées à tester.

Les 3 thèmes et les points que j’ai retenus :

Changement de posture du Scrum Master

• Regret de ne plus être proche du code quand on a été développeur, donc moins de suivi du code (mais d’un autre coté, plus d’impartialité dans les rapports dev/client).
• Le travail de Scrum Master n’est pas quantifiable (contrairement aux développeurs) donc reconnaissance différente vis-à-vis du client.
• Difficulté de ne pas passer pour un “chef” d’équipe (on doit être en support/aide de l’équipe pour progresser).

Motivation de l’équipe

• Proposer du temps libre aux équipes pour faire autre chose mais tout aussi utile pour progresser (coding dojo/intervenant extérieur pour un talk comme http://www.brownbaglunch.fr/…).
• Trouver des petites actions fun (big up à la fin d’une US, etc.).
• Donner un max de feedbacks (surtout dans grand groupe où le client est assez “éloigné”).
• Donner une meilleure vision de l’ensemble de la suite du projet, de l’ensemble des risques (backlog grooming).

Responsabilisation et auto-organisation de l’équipe

• Ne pas hésiter à faire tourner les rôles lors des cérémonies (time keeper, scribe, préparation des démos…).
• Regarder dans le code pendant le planning pocker (permet à chacun de progresser sur le code déjà développé).

2. Faites (re)vivre vos spécifications !

La 2ème conf était menée par 2 speakers qui ont raconté leur aventure consistant à intervenir chez un client afin de démêler des spécifications d’un projet qui avaient été écrites sous forme algorithmique (genre VBA Excel) puis de refactorer le code de l’application déjà existante.

Pour cela, leur approche a été de faire parler le métier, de tirer des histoires (User stories), puis de les traduire sous forme de scénarios en utilisant un formalisme BDD (Behavior-driven development).

Le principe est intéressant car il permet d’aider le dialogue entre une équipe de développement et le PO. De son coté, le PO écrit des phrase “en Français”  (des phrases le plus “unitaires” possible afin de les rendre “réutilisables” pour d’autres scénarios), fournit un jeu de données et le développeur se charge de les associer à des tests codés (en Java par ex.).

Une fois les tests réalisés, l’équipe de développement pouvait alors se consacrer à revoir le code, le simplifier tout en étant serein sur leur évolution.

Une partie la conférence montrait des exemples concrets de BDD, de code, puis l’exécution grâce à Maven en “live” (en modifiant le jeu de données par exemple). Enfin, l’exécution directement dans le navigateur de ces tests BDD (avec les formulaires qui se remplissent automatiquement à partir du jeu de données du PO, etc.)

Les outils utilisés :

• JBehave pour la rédaction des tests BDD/correspondance avec le code de l’application : http://jbehave.org/
• Thucydides pour l’exécution de ces BDD directement sur le navigateur : http://www.thucydides.info/ dont le rendu dans des rapports (interface web) semble assez sympa (photos d’écrans en cas d’erreur par exemple)

Pour conclure, je pense que si un PO rédige son cahier de recette avec une approche de tests BDD et que l’équipe de développement intègre ces scénarios au fur et à mesure, c’est un excellent moyen pour – en plus des tests unitaires – pérenniser la qualité de l’application.