lundi 25 juillet 2011

Chef de projet ScrumMaster ... Arg !

Mission "Chef de projet ScrumMaster"

Il y a plusieurs semaines, j'ai vu passer une annonce de mission intitulée "Chef de projet ScrumMaster". Interpellé par l'intitulé, j'ai consulté l'annonce. La personne recherchée devait :
  • piloter l'équipe
  • faire l'interface entre l'équipe et les clients
  • faire du reporting à la hiérarchie
  • etc ...
Bref, toute la panoplie d'un "Chef de projet" et rien à voir avec un ScrumMaster

"En fait, le ScrumMaster c'est l'équivalent d'un chef de projet ?"

Lors de récentes formations, ou plutôt "informations" (je préfère ce terme) sur l'Agilité et Scrum, systématiquement, la question ressortait : "En fait, le ScrumMaster c'est l'équivalent d'un chef de projet ?" ...

STOP !

Et oui, STOP ! Arrêtons de chercher des comparaisons avec les méthodes classiques. Le rôle de ScrumMaster n'a pas d'équivalent dans ce que nous pouvions connaitre avant l'agilité.

Le ScrumMaster s'assure que le cadre Scrum est respecté, que l'équipe est opérationnelle, fonctionnelle, productive, que l'équipe met et peut mettre en oeuvre tous les moyens d'organisation et techniques pour assumer ses engagements de production, c'est un facilitateur, un accompagnateur, un protecteur, il anime les différentes réunions, il s'assure de la collaboration étroite entre les intervenants, il veille au respect des rôles de chacun, il intervient dans l'organisation pour accompagner le changement, il expose les contraintes et les problèmes de mutation, etc ...

Il n'est pas question de diriger l'équipe, de distribuer les tâches de développement, de faire les choix techniques et technologiques, de faire du reporting, de faire l'interface avec le client pour évaluer ses besoins, etc ...

Certes, le ScumMaster peut également être un développeur et faire partie des équipiers, il intervient alors au même titre que les autres membres de l'équipe pour les estimations, les choix, la vision d'architecture, etc ... Il peut prendre en charge la mise à jour du Scrum Board (Sprint backlog, burndown chart, etc ...) mais à titre "moteur", ça n'est pas forcément à lui de faire cela !

Donc, le ScrumMaster n'a rien à voir avec un chef de projet.

Pour conclure, et pour ceux qui se demanderait ce que devient le chef de projet lors d'une transition vers l'agilité, certes il peut devenir ScrumMaster, mais en oubliant son rôle précédent, et à condition d'avoir de bonnes aptitudes pour ce nouveau rôle très orienté sur les aspects humains. Personnellement, je constate que bon nombre de chefs de projet feraient plutôt de bons (Proxy) Product Owner par leur connaissances du métier, leur relationnel avec le client et les utilisateurs !

jeudi 21 juillet 2011

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 !