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 !

mercredi 22 juin 2011

Vidéo de retours sur le ScrumDay 2011

Le FrenchSUG (French Scrum User Group = Groupe des Utilisateurs Français de Scrum) a mis en ligne une vidéo de compilation de retours sur le Scrum Day qui a eu lieu le 31 mars dernier.

La vidéo et le montage sont sympas et dynamiques, mais au delà de la forme, les retours collectés me semblent très significatifs de la situation de l'agilité actuellement, avec un gros engouement, un intérêt montant avec une popularité grandissante, mais également une mise en garde et donc une prise de conscience intéressante sur la dualité suivante : la simplicité de l'approche et la difficulté de sa mise en oeuvre au quotidien, "tout n'est pas si simple, mais ça vaut le coup", d'où la nécessité de se renseigner, se préparer et se faire accompagner !

La vidéo est là : http://www.facebook.com/video/video.php?v=10150198547436366

lundi 6 juin 2011

[Agilité] Estimation relatives des histoires

Je viens de lire l'article "90 stories en 45 minutes" publié par Benoit Gantaume, et ça me rappelle un atelier que j'avais animé, j'en profite donc pour partager cette expérience ...

Tout comme Benoit, le besoin était d'estimer une bonne quantité d'histoires, pour dégrossir les estimations et se donner une idée globale d'effort à fournir. Je m'étais inspiré de lectures ici et là pour proposer à l'équipe un atelier d'estimations relatives en mélangeant différentes idées, avec une grosse influence du Story Mapping.

Déroulement

L'atelier s'est déroulé en présence du Product Owner, de 3 équipiers (développeurs) et moi en tant que ScrumMaster. Nous nous sommes installés dans une salle tranquille en alignant 2 tables rectangulaires de façon à pouvoir circuler autour. Nous avons préparé un post-it pour chaque histoire.

Pour débuter, nous avons chercher très rapidement l'histoire qui nous semblait la plus petite (en terme d'effort à fournir, je ne parle ici que de cela) et nous l'avons positionné sur la gauche.

Ensuite, nous avons pris les histoires 1 par 1 et les avons positionné sur la table, à gauche ou à droite les unes des autres selon leurs efforts relatifs. Pour des efforts identiques, nous avons placé les histoires les unes en dessous des autres. Les histoires trop floues et ne pouvant pas être estimées ont été placées dans un coin identifié de la table.

Constats

Les histoires ont été rapidement placées les unes après les autres, quitte à décaler certains "paquets" pour en insérer certaines. Très vite, certaines histoires ont été placées très loin sur la droite, instinctivement pour un effort conséquent mais flou. D'ailleurs, une 3ième table a due être ajoutée ... Ces histoires ne peuvent donc pas être sélectionnées pour un backlog de sprint sans être re-découpées.

Nous avons également placé 1 ou 2 histoires à gauche de celle initialement estimée comme étant la plus petite, comme quoi ça n'était pas le cas, mais ça n'a absolument pas gêné le déroulement de l'atelier, l'essentiel étant d'avoir un point de départ de faible poids (effort).

Il était intéressant de constater que certaines histoires ont été déplacées plusieurs fois, dans un sens ou dans l'autre, surtout en fonction des questions posées au Product Owner pour mieux comprendre les besoins, les questions pour une histoire venant parfois lors du placement d'une autre histoire. En effet, le positionnement proche entre 2 histoires faisait parfois émerger des questions sur l'une ou l'autre pour bien évaluer les différences.

Tout comme Benoit, nous avons consigné au fur et à mesure les précisions données par le Product Owner, mais également des éléments de solutions techniques émergeant des discussions entre développeurs. Ce point est souvent négligé. Je l'ai souvent constaté, ces moments d'échanges amènent naturellement l'équipe vers un début de réflexions techniques et il est souvent dommage de perdre ces informations qui feront gagner du temps par la suite ...

Une fois toute les histoires en place, nous les avons passé en revue 1 par 1, de gauche à droite, pour vérifier leurs positionnement relatifs. Ensuite nous avons mis des chiffres, en partant de 1, et tout comme dans l'atelier de Benoit, naturellement, les écarts se sont creusés pour être proche de la suite de Fibonacci ( 1, 2, 3, 5, 8, 13, ... ?).

Bilan

En très peu de temps, nous avons pu estimer une bonne quantité d'histoires, avec un résultat recevant un bon indice de confiance de toute l'équipe ("Give me five") et permettant d'avoir une certaine visibilité sur le projet.

Les plus :
  • rapidité
  • aspect ludique
  • participation collaborative de tous, naturelle et immédiate
  • échanges riches et constructifs
A améliorer :
  • mise en évidence des valeurs métiers de chaque histoire : nous n'avions rien mis en place pour cela, le Product Owner connaissant très bien son backlog et le ROI de chaque histoire, mais l'idée de Benoit (bandes de couleurs) est intéressante
  • ... certainement plein d'autres choses dont je ne me souviens plus à ce jour ... ;-)

mercredi 1 juin 2011

Git et les branches : super pratique !

Introduction

Pour un projet d'application WEB, j'avais besoin d'utiliser un éditeur HTML en ligne WYSIWYG en lieu et place d'un TextArea :
Après une petite recherche sur internet, j'ai trouvé 4-5 librairies et j'en ai retenu 3 d'après les premières informations collectées (licence, rendu, intégration, ...). Restait alors à les tester pour vérifier l'intégration technique dans mon application et les résultats visuels dans mes pages.

La solution est venue immédiatement : faire des branches avec Git, surtout que j'avais déjà mis mon projet sous Git !

Déroulement

Voilà en résumé l'enchainement des opérations réalisées ...

Je vérifie mes branches actuelles :
$ git branch
* master
Aucune branche, donc j'en crée une pour tester la librairie "truc" et je bascule dessus :
$ git branch html_editor_truc
$ git checkout html_editor_truc
Switched to branch 'html_editor_truc'
J'installe la librairie, je modifie mon application, je mets au point, et je vérifie le résultat (rendu et utilisabilité de l'éditeur HTML). Une fois que j'ai pu évaluer la librairie "truc", je peux ajouter les nouveaux fichiers à Git et je commit :
$ git add libs/
...
$ git commit -a -m "Essaie avec l'editeur HTML truc"
...
Je reviens à ma branche principale :
$ git checkout master
Switched to branch 'master'
Et je vérifie l'état courant :
$ git status
# On branch master
nothing to commit (working directory clean)
Rien ... bon ...
Je regarde dans mon arborescence de fichiers et le répertoire que j'avais ajouté avec la librairie "truc" a disparu : magique !

Je refais les mêmes opérations pour la librairie "toto". Le résultat est moins satisfaisant, au final, je préfère la librairie "truc" : mon choix est fait ! En étant sur la branche "master", je commence par supprimer la branche pour les tests avec la librairie "toto", je n'en ai plus besoin (mais je pourrais la garder) :
$ git branch -D html_editor_toto
Deleted branch html_editor_toto (was fa84cec).
Ensuite, je demande la fusion avec la branche d'essai de la librairie "truc" :
$ git merge html_editor_truc
Updating 77cd7dc..7c0a0f6
Fast-forward
...
 21 files changed, 19 insertions(+), 2 deletions(-)
Et voilà ! La librairie précédemment testée est intégrée à la branche principal.

Play! framework

J'en ai déjà parlé, et l'article est toujours en prévision : pour ce projet, j'utilise Play! Framework,un framework de développement WEB écrit en Java : on écrit les contrôleurs et les beans de données en Java, et les template de vue en Groovy. Ce framework est très simple d'utilisation, et extrêmement productif, notamment par sa compilation en ligne : pas besoin de recompiler ou de relancer le serveur à chaque modifications, un simple rafraichissement dans la page WEB suffit pour voir les modifications apportées aussi bien dans le modèle de données, dans les contrôleurs ou dans les vues.

Donc, en utilisant Git et les branches, il suffit de basculer d'une branche à l'autre, et là encore, un simple rafraichissement de la page suffit à nous remettre dans le contexte de la branche choisie.

Dans mon cas, ça m'a permis de tester les différentes librairies pour mon éditeur HTML très rapidement. Sans compter la facilité pour comparer chaque solution en basculant de l'une à l'autre par une simple ligne de commande (git checkout ...) !

Seul bémol : j'ai été un peu embêté par la base de donnée H2, de type file, utilisé pour ma version test de mon appli sur mon poste. Par défaut, j'ai initialement ajouté à Git tous les fichiers de Play!, y compris la base de données :
$ git add .
Du coup, à chaque changement de branche, Git me signale un problème car la base a été modifiée. Il suffira donc que je l'enlève de la gestion par Git.

Corrections sur la branche principale

Même si mes tests pour choisir ma librairie ont été rapides, j'ai été interrompue pendant ces tests pour une correction mineure sur la branche principale. Qu'à cela ne tienne, je suis revenu sur cette branche, j'ai fait mes modifications (+tests bien sûr), j'ai commité et livré, et je suis revenu à ma branche de test :
$ git checkout master
Switched to branch 'master'
... // modifications
$ git commit -a -m "..."
... // livraison
$ git checkout html_editor_truc
Switched to branch 'html_editor_truc'
Aucune interférence entre les 2, vraiment super pratique !

Une galère

Durant cette expérimentation, j'ai eu essentiellement une galère. Lors de mes opérations avec Git, il me signalait un problème, assez incompréhensible, sur un dossier d'un plug-in d'une des librairies testées. J'ai longtemps pensé que j'avais raté ou mal fait quelque chose. Je me suis retrouvé bloqué !

Au final, pas de chance, mais en fait, c'est l'archive de la librairie qui contenait, dans ce dossier là, un fichier .gitignore et un dosser .git : Git était perdu, y'avait de quoi ... J'ai signalé le problème aux développeurs de la librairie, bien contents de ce feedback !

Conclusion

J'avais pas mal entendu parler de Git, et notamment pour ses avantages pour les (nombreux) commits "locaux", mais aussi pour sa gestion des branches permettant de travailler sur plusieurs sujets à la fois.

L'idée en utilisant Git est de faire une branche pour chaque modification entamée.

Lorsque j'avais lu cela, avec mon expérience Subversion (et la gestion des branches parfois lourde), j'avais été surpris. Mais l'expérience, même de faible ampleur (pas énormément de modifications sur plusieurs branches à la fois), est vraiment concluante : ces possibilités offerte par Git et sa gestion des branches est vraiment génial !

Et vous ?

Quelle est votre point de vue, expérimenté ou non, sur Git ?
Qu'en pensez-vous ?

jeudi 26 mai 2011

Première demande de "pull" sous Github

A y est !! Enfin ! ....

Il y a presque 1 an, pour un développement WEB perso, j'avais récupéré une librairie Javascript sur Github. J'avais d'ailleurs eu quelques échanges sympa avec le nouveau "propriétaire" de la librairie (officiellement forké d'une version officiellement non maintenue par l'auteur initiale de la librairie).

Pour les besoins de mon appli, j'avais fait une petite modif pour ajouter une petite fonctionnalité sympa à la librairie. J'avais promis à l'auteur de soumettre ma modif, mais ... le temps a passé ... et je ne l'avais jamais fait ...

Maintenant, le projet est réouvert pour quelques temps, et j'en profite pour tenir ma promesse.

J'ai donc "forké" la librairie de référence sur mon compte Github en suivant cette page d'aide simple et claire : github:help : Fork A Repo.
Note : Pour faire des commits, voir plus bas ... ;-)
Ensuite, comme j'ai changé de machine et que je suis (pour l'instant ...) sous Wnidows, j'ai installé Git (msysgit) en suivant ce tutoriel pour débuter avec Git et GitHub sous Windows, simple et efficace, avec un petit rappel de ce qu'est un SCM décentralisé. On peut zapper la fin du tutoriel, les infos seront vus dans un autre tutoriel ...
Attention : chez moi, la génération de la clé dans une console "bash" ne fonctionnait pas, mais j'ai pu l'obtenir avec Git GUI.
Ensuite, pour compléter ma configuration de git et rentrer plus en détails dans les principes de fonctionnement et les commandes, je recommande ce tutoriel vraiment excellent : Gérez vos codes source avec Git !
Attention : pour la création du dépôt local et l'envoi de commits ("push"), se référer plutôt à l'aide Github citée plus haut.
Avec tout ça, j'ai réussit à faire un commit et à la pousser sur mon dépôt Github, donc sur mon fork du projet. Ensuite, en 1 clic dans l'interface de Github, j'ai fait une "Demande de pull" pour demander à l'auteur principal (de référence) d'intégrer mes modifs dans la branche principal de la librairie.

Reste plus qu'à attendre qu'il l'accepte ....

En tout cas, les principes mis en avant par Github sont vraiment très sympas pour les aspects collaborations, et l'apprentissage de git (j'y avais déjà touché) n'est finalement pas si compliqué que cela.

Et toi, lecteur de passage, que penses-tu de Git ? Es-tu plutôt SVN ?

lundi 23 mai 2011

Scrum Day France (Part 3)

"ScrumMasters, devenez le coach de votre équipe agile" par Véronique Messager

(Type : vidéo et diaporama mixés)

En introduction, Véronique évoque une révélation que j'ai eu moi aussi : la réponse que les méthodes agiles apportent lorsqu'on cherche (cherchait) une approche plus "humaine" dans la gestion de projet. J'ai pris conscience de cela au bout de pas mal de temps : l'approche et l'organisation qui m'étaient proposées pendant des années ne me convenaient pas, l'agilité a pointé ce qui manquait : l'aspect humain ...

Véronique rappel quelques points importants avec des variantes ou point de vue qui m'ont intéressé :
  • Le ScrumMaster protège l'équipe, de l'extérieur bien sûr, mais également des siens, des membres de l'équipe
  • Parmi les valeurs poussées par l'agilité, le droit à l'erreur, pas assez mis en avant
  • L'équipe s'engage sur les résultats, le ScrumMaster s'engage sur les moyens (moyens pour l'équipe de tenir ses engagements, notamment moyens techniques)
Comme souvent, la question : le ScrumMaster peut-il être un responsable hiérarchique ?

Véronique précise que c'est un débat, mais n'y répond pas. Personnellement, malgré mon pragmatisme, je suis assez formel : par expérience, il faut absolument éviter que le ScrumMaster soit un responsable hiérarchique. Pour obtenir la concrétisation de valeurs comme Transparence, Confiance, Ouverture, etc ..., pour obtenir l'affichage par les équipiers de leurs faiblesses pour qu'ils expriment leurs difficultés du moment lors de la mêlée quotidienne, il ne faut pas que le ScrumMaster soit hiérarchique !

Autre sujet abordé, pendant la présentation, mais également, pendant les Questions/Réponses : le ScrumMaster est-il un ancien chef de projet. Véronique dit qu'elle constate que c'est souvent le cas. Je pense que c'est possible, il n'y a rien qui s'y oppose, mais ça ne doit pas être systématique : un chef de projet peut très bien devenir (Proxy) Product Owner, notamment s'il a une bonne compétence métier et relationnel avec le client. L'important est que le ScrumMaster soit à l'écoute des équipiers et dans la communication, un chef de projet trop habitué à un rôle directif aura du mal avec cette approche très humaine, en "position basse" comme dit Véronique. J'y reviendrai dans un autre billet ...

Véronique a un point de vue intéressant sur le rôle de ScrumMaster : qu'il adopte une posture de "coach". Je pense que le rôle de "coach agile", comme je peux le faire en indépendant extérieur à l'entreprise, est une mission bien spécifique et différente de ScrumMaster. Mais en écoutant la suite de la présentation, je comprends ce que Véronique veut illustrer à l'auditoire pour lui faire sentir ce rôle de ScrumMaster :
  • Faire en sorte que chacun (individu ou l'équipe) trouve lui-même la solution à ses problèmes
  • Non pas intervenir sur une problématique mais plutôt sur la façon dont l'équipe appréhende et traite cette problématique
Véronique insiste ensuite sur ce que cet aspect humain implique pour le ScrumMaster :
  • Connaissance de soi et contrôle de soi-même
  • Connaissance (humaine et non privée) des autres
  • Relations entre les personnes
  • Prise en compte des émotions de chacun
Selon les situations et les contextes, une "charte" au sein de l'équipe peut-être intéressante comme cadre, notamment en cas de relations difficiles.

Obligé d'accélérer sur la fin de sa présentation, Véronique aborde rapidement des points souvent délaissés, voir inconnus, et pourtant très importants à intégrer pour le ScrumMaster (et finalement tous les acteurs) :
  • La notion de deuil qui accompagne souvent les changements nécessaires pour chacun (développeurs, managers, ...), la prise en compte du cycle de deuil, et l'accompagnement au changement nécessaire (coaching)
  • La notion de cycle de vie d'une équipe (Création, Turbulence, Harmonisation, Performance, Séparation) impliquant une équipe stable où les acteurs apprennent à travailler ensemble
Dernier point noté qui ouvre le rôle de ScrumMaster : ce dernier intervient à différents niveaux :
  • Individu : accompagnement au changement, adaptation individuelle à l'agilité de chacun
  • Équipe : permettre la meilleure transformation "de groupe" vers l'agilité
  • Organisation : dynamique globale nécessaire, évangélisation dans l'entreprise

jeudi 21 avril 2011

Scrum Day France (Part 2)

Retour sur une autre présentation que j'ai visionné

Pratiques avancées des tests avec Nathaniel Richand

(Type : audio sur diaporama sous forme de video)

Nathianel attaque fort avec 2 qestions qui interpellent (tests des messages dans les exceptions et des messages dans les logs), en rappellant qu'il faut rester pragmatique selon le contexte !

Outre le TDD evidemment très intéressant, Nathianel évoque les tests qui vieillisent mal (notamment par la mise en commentaire des vérifications "assert"), et le fait que le TDD peut devenir un frein en augmentant la rigidité du code.

Il propose donc 2 axes pour éviter cela :
  • augmenter la lisibilité
  • diminuer la fragilité

Pour augmenter la lisibilité :
  • choisir des noms explicites pour les méthodes de tests en donnant le contexte et l'intention
  • ne pas masquer les informations utiles, qui peuvent par exemple venir de fichiers XML non visibles dans le code de test (cf DBUnit ou Unitils)
  • masquer tout ce qui est inutile en utilisant les Setup, les Teardown, les import static, du code "Fluent interface" avec le pattern builder, etc ...
  • éviter les "try/catch" avec "fail()" en remontant simplement les potentiels exceptions (throws sur les méthodes de tests) idem pour les "if/else" avec "fail()"
  • éviter les messages explicites en début d'assert en utilisant des tests natifs ou des bibliothèques favorisant l'affichage les messages d'erreur (cf FestAssert)
  • éviter des nombres et textes dans le code de test, utiliser des constantes, y compris pour des paramètres à null
  • garder la même structure pour tous les tests, comme par exemple "Given/when/then" proposé par Nathianel, ou plus perso pour moi, "Préparations/Tests/Vérifications", ce qui a en autre l'avantage de pousser le développeur à ne faire qu'un test par méthode
  • soigner ses assertions, notamment en utilisant les bons assert ("assertEquals" plutot que "assertTrue") et les librairies comme Festassert ou armcrest
  • utiliser Spock, dont j'ai déjà parlé dans un précédent poste et qu'il va vraiement falloir que je teste !

Remarque "évidente" (...) en passant : si les tests sont compliqués, c'est que potentiellement, le code est ... compliqué ! A méditer ...

Pour rendre les tests plus robustes :
  • pas de duplication de code (utiliser des fixtures, des builders, des assertions "maison", ...)
  • tester un comportement à un seul endroit
  • éviter la réflexion (reflect java pour tester des méthodes privées ..... bahhhhhhhh)
[NDLA] Sur ce point, je n'approuve pas l'idée de changer la portée "private" d'une méthode pour la tester, il y a d'autre solutions, notamment un changement d'architecture pour extraire cette méthode dans une autre classe testée unitairement ... éternet débat ? ...
  • adapter ses tests selon que le code est bas niveau (basique) ou haut niveau (interaction entre plusieurs collaborateurs), utiliser des mocks pour vérifier le comportement global de la méthode

Je note l'idées intéressante consistant à ajouter au TDD un étape après l'étape "rouge" pour vérifier les messages d'erreurs et les rendre explicites.

Je recommande moi aussi le livre "Clean code" de Robert C. Martin traduit en Français sous le titre "Coder proprement" dont la première moitié est tout simplement pleine de bon sens !

S'en est suivi une séance de Questions/Réponses sur différents sujets :
  • tests sur environnement de prod : plutôt éviter (selon contexte) !
  • tests des classes abstraites : Nathianel évoque la possibilité pour le code de test d'hériter du code de test de la classe abstraite
[NDLA] Perso, j'utlise de moins en moins l'héritage et les classes abstraites, et de plus en plus l'aggrégation ;-) donc la question ne se pose plus ...
  • alternatives à DBUnit : mocker les DAO, ou sur-couche DBUnit pour éviter les fichiers XML (DBUnit et Unitils n'étant plus maintenus)

Sur l'utilisation de mocks, mon approche est très différente de Nathianel qui dit les utiliser peu. Je développe depuis pas mal de temps de façon très découpée pour respecter le principe "1 classe - 1 role", et beaucoup de base d'interfaces et de collaborateurs. J'utilise donc énormément les mocks pour simuler et maitriser le comportement de chaque collaborateur pour que le test ait tout son sens, et je n'ai jamais rencontré de grandes difficultés lors d'évolutions et refactorings de code, du moins rien à voir avec l'apport d'une telle architecture !

En tout cas, une présentation intéressante, efficace, et que j'approuve entièrement, aux détails près mentionnés précédemment ;-)



lundi 18 avril 2011

Scrum Day France - Les présentations sont en lignes !

Je n'ai malheureusement pas pu me rendre au Scrum Day France le 31 mars dernier. Mais bon nombre des présentations sont en lignes sur le site du French Scrum User Group. Merci au groupe et à Xavier Warzee !

J'avais commencé à regarder quelques présentations dès leurs mises en ligne. Voici quelques retours sur :
  • Automatisation des tests : le mythe du ROI avec Gilles Mantel
  • Lorsque quelque chose empêche SCRUM de fonctionner !, Alexandre Boutin
  • Le Product Owner « Proxy », Bertrand Dour

Automatisation des tests : le mythe du ROI avec Gilles Mantel


(Type : vidéo et diaporama en parallèle)

En début de présentation, Gilles rappelle les différents types de tests. J'y ai découvert les Tests fonctionnels exploratoires, non automatisables, mais sujet certainement d'avenir.

Ensuite, Gilles présente la formule du ROI (=Coût des tests manuels - coût des tests automatisés) en détaillant le contenu de chaque terme. La courbe présentée ensuite montre, sans surprise, un ROI positif au bout d'un certain nombre de cycles d'exécution, le point de début de rentabilité pouvant être atteint au bout de 2 à 3 ans (période d'investissement au bout de laquelle on ne gagne rien !). Pas motivant ...

Gilles met donc ensuite le doigt sur le fait que dans cette approche très mathématique et financière, on oublie bon nombre d'intérêts des tests automatisés comme par exemple :
  • la possibilité de lancer les tests plus souvent, y compris la nuit, sans nécessité de disponibilité de ressources humaines
  • des retours (feedbacks) plus rapides
  • le coût des anomalies
Gilles détaille ce dernier point avec des graphes très intéressants mettant en évidence que plus une anomalie est découverte tard, plus elle coûte chère, évidemment. Mais un critère supplémentaire très important est la phase à laquelle l'anomalie a été créée : plus une anomalie a été introduite tôt dans le process (par exemple architecture, design, ...), plus elle va coûter chère, le tout étant accentué si elle est découverte tard !

La suite de la présentation reste très théorique en se basant sur le modèle de gain d'une option d'achat. Mais cette approche m'a enfin permis de comprendre pourquoi, en contexte agile, j'ai souvent été moins motivé à mettre en place des tests sur le GUI (par exemple) : tout simplement parce que par expérience, il y avait peu d'anomalies dans cette partie des logiciels, donc un ROI pressenti moins intéressant !

Gilles présente également un graphe très intéressant, de Scott Ambler, qui a fait une projection des pratiques, agiles ou non, sur la courbe de coût d'une anomalie, excellent ! Avec là aussi une mise en évidence d'un ROI, pour l'automatisation des tests, moins intéressant en contexte agile.

Conclusion : commençons par passer à des pratiques agiles, et les tests, ça vaut le coup à bon escient.

Une présentation que j'ai beaucoup apprécié, à voir !



Lorsque quelque chose empêche SCRUM de fonctionner !, Alexandre Boutin

(Type : audio sur diaporama sous forme de video)

Après une introduction sur une première raison d'échec, Alex anime sa présentation sur base du serious game "Buy a feature" (cf Innovation Game), en proposant 12 raisons d'échec de Scrum à acheter par les participants, raisons basées sur des exemples concrets vécus.

Parmi les sessions présentées :
  • Une seule personne ! : cas d'une personne malhonnête et méchante, ayant beaucoup de pouvoir
  • Casting du PO : une situation où tout semble parfait sauf que le PO n'était pas le bon, plus gestionnaire que visionnaire (pas impliqué), et non maitre des aspects financiers
  • Contrat agile : j'en retiens trop de contractualisation, trop d'adaptations de Scrum, trop de difficultés liés aux distances, aux mélanges d'équipes agiles ou pas, ...
  • Mission impossible : avec la blague de Ken Schwaber qui conseille à un ami, ayant un projet impossible, d'opter pour ..... la méthode Waterfall ! Scrum mettrait "trop" vite en évidence l'aspect impossible du projet
  • Les Geeks : échec d'un projet à cause des geeks, excellent techniquement, qui se font plaisir, mais pas du tout ouvert sur le métier. Personnellement, je me considère comme geek, par l'aspect passion, ou du moins, je me sens proche des geeks. Et je les perçois plus comme une réserve d'énergie et d'innovations. Je ne partage donc pas le point de vue d'Alexandre. Mais je comprends bien la raison d'échec de ce projet, plus dû à des développeurs renfermés sur leur focus technique, sans intérêt pour le métier. Et cela m'amène une question : quel est le rôle du coach agile et/ou du ScrumMaster dans une telle situation, intéressant ...
  • Micro management : présence d'un manager hiérarchique trop présent sur l'équipe, avec des pratiques incompatibles avec Scrum (déplacement des post-its, affectation des tâches, suivi du consommé, ...) et donc un ScrumMaster avec un rôle très réduit. Bilan : passivité et désengagement de l'équipe, Scrum devient impossible !
  • Multiples PO : présence réelle de plusieurs PO avec une répartition officielle (documentée) des rôles de chacun, rôles très répartis, aboutissant à un auto-blocage dans les décisions

Un rappel important au passage : l'agilité, avant tout, c'est un état d'esprit !

Une présentation intéressante (même si j'ai des différences de points de vue sur les geeks et les ScrumMaster qu'il est bon de faire "ramer"), avec une forme agile à différents points de vue. Évidemment, Scrum, ça fonctionne "presque" tout le temps, et il est intéressant et enrichissant de se repencher sur les raisons d'échec pour les comprendre et les éviter à l'avenir. Ce que j'ai pas mal fait personnellement ces derniers temps.

La conclusion est importante,puisqu'en général, ce n'est pas la méthode qui ne marche pas, mais son application, les limites de l'organisation, et les personnes concernées.



Le Product Owner « Proxy », Bertrand Dour

(Type : audio sur diaporama sous forme de video)

Une présentation rapide suivant d'une longue séance de questions/réponses. Malheureusement, difficile d'entendre toutes les questions, mais les réponses restent intéressantes ...

Bertrand présente le contexte de la mise en place,  chez PMU, pour 3 métiers différents, d'une structure agile sur base de 2 équipes de 4-5 personnes (permet de répondre à 2 thématiques à chaque sprint), travaillant sur 1 seul product backlog multi-activités, avec la présence d'un Product Owner Proxy dont Bertrand rappelle l'intérêt :
  • Un interlocuteur unique
  • Une gestion des priorités consolidées
  • Une planification de release cohérente
Bertrand lisse les problèmes et solutions :
  • Expertise métier : mise en place d'implication forte des experts métiers, vocabulaire commun et granularité similaires entre les métiers
  • Gestion des priorités : 
    • vrais jetons de pocker pour les valeurs métier (Business values)
    • augmentation de la transversalité entre métiers : fédération et collaboration
    • créations d'événements : démos au PO et aux personnes avec qui le PO est en contact, ateliers (écritures d'histoire, gestion du backlog, ...)
Bertrand dresse ensuite un bilan sur la mise en place de ce Proxy PO, que je complète avec les questions/réponses :
  • Avantages : gestion du besoin consolidé et interlocuteur unique, échanges transversaux entre métiers (ouverture)
  • Difficultés : connaissance métier (atelier indispensables), légitimité du PO, complexité du processus, Proxy PO avec pouvoir d'arbitrage mais sans pouvoir de décision (obligation de consulter la hiérarchie)
Les questions/réponses ont également permis de couvrir d'autres points plus généralistes sur l'agilité et Scrum : open space, évangélisation de l'agiliité au sein de toute l'entreprise (pas facile, comme souvent), etc ...

Une conclusion intéressante : un PO Proxy ça marche, mais commencer par essayer d'améliorer d'abord l'organisation ...


jeudi 7 avril 2011

Tests unitaires - Spock : à tester de toute urgence !

Je viens de lire le retour de Nicolas Martignole, alias le Touilleur Express, sur la présentation de Spock par Mathile Lemée à Mix-It :
http://www.touilleur-express.fr/2011/04/06/mix-it-le-framework-spock-par-mathilde-lemee/

Mathilde en a d'ailleurs fait 3 articles sur son blog :

Je découvre donc ce framework de tests que je ne connaissais pas, à tester de toute urgence pour se faire son propre avis !