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 ?