mardi 27 décembre 2011

Lecture : "Agile Coaching" de Rachel Davies et Liz Sedley

Je viens de finir la lecture du livre "Agile Coaching" écrit par Rachel Davies et Liz Sedley.
A la question "à qui s'adresse ce livre ?", je dirais qu'il est destiné à des coachs Agile, qu'ils le soient depuis peu ou qu'ils soient des ScrumMasters souhaitant faire la transition (des coachs senior pourraient trouver que le livre manque un peu de profondeur pour leur niveau d'expérience). La construction est axée sur du coaching dans le but d'introduire Agile au sein d'une équipe ou d'une organisation. Mais contrairement à ce qu'on pourrait penser en lisant le titre, ce livre n'est pas utile uniquement à des coachs. Ne l'étant pas moi-même, je trouve déjà intéressant de découvrir des problématiques et des méthodes de coaching Agile. Dans la quantité de conseils donnés tout au long de cet ouvrage, beaucoup seront utiles aux membres d'une équipe de développement, puisque pas mal de points abordent les relations, parfois de conflits, entre individus au sein d'un projet. Les comportements à avoir ou à éviter vous serviront dans vos projets quelque soit votre poste.

Le livre présente d'abord une approche générale du coaching et de la communication. Vient ensuite une longue partie passant en revue les cérémonies Agile avec des conseils de coaching appliqués à ces réunions (on sent d'ailleurs qu'elles utilisent Scrum sans le revendiquer ouvertement). La construction est bonne avec cependant un petit bémol : les mêmes recommandations reviennent plusieurs fois tout au long du livre. Certains apprécieront qu'on les leur répètent, d'autres non.
Un bon point est que la forme des chapitres est la même du début à la fin : des conseils, puis les obstacles éventuels, enfin une checklist de ce qu'il faut retenir du chapitre. Ceux-ci sont parsemés d'encadrés décrivant des exemples vécus par les auteures et aussi des concepts particuliers avec des références pour les découvrir et/ou les appronfondir via d'autres livres ou sites web (management, design, programmation, etc...). Elles pointent aussi des mauvaises pratiques à éviter dans certaines circonstances et par lesquelles on pourrait être tenté. Les auteures n'ont d'ailleurs pas peur de revenir sur leurs erreurs et échecs. Ce qui montre beaucoup d'humilité mais aussi une volonté constante de progrès : c'est clairement la philosophie qu'elles souhaitent nous transmettre.

Pour ma part, je suis satisfait de cette lecture. Le style est fluide, les exemples sont convaincants et le livre n'est pas cher ;)
A retenir :
- les exemples/situations personnelles vécues
- la dernière partie "Growing you"
- à la fin, une longue liste d'autres ouvrages à découvrir pour aller plus loin

jeudi 22 décembre 2011

TDD : "Les Tests en Trois Temps"

Parmi les pratiques agiles les plus connues et/ou les plus appréciées, on retrouve les Développements Dirigés par les Tests (Test Driven Development en anglais ou TDD). Les TDD font grand bruit depuis quelques années déjà. Conduire un projet en utilisant les TDD est gage de réussite, de bonheur et de longue vie. Toutefois, tout n’est pas si rose dans le petit monde du logiciel.

Le premier principe des TDD est d’écrire des tests avant de coder l'application. Les développeurs peuvent ainsi s’appuyer sur lesdits tests pour valider que les fonctionnalités correspondent bien aux attentes du client. Plus précisément, la méthode conseille de faire initialement échouer les tests puis, progressivement, de coder l’application pour que tous les tests passent.

Le site developpez.com propose une présentation (en français) des TDD.

Dans la réalité, peu d’équipes jouent le jeu bien longtemps. Un des plus gros défauts de la méthode est aussi une de ses qualités. En effet, hormis le principe de base décrit plus haut, les TDD laissent beaucoup de libertés aux développeurs. Très vite, on se rend compte que "trop de libertés tue la liberté". La plupart des développeurs ont besoin d’un cadre de travail clair, faute de quoi on ne sait rapidement plus par quel bout prendre l’affaire.

Plus concrètement, la méthode ne précise pas qui spécifie les tests, qui les écrit, selon quelles normes, qui les vérifient, dans quel ordre ils doivent être créés et/ou exécutés, comment on se sert de ces tests pour coder les fonctionnalités, etc... Chaque membre de l’équipe est laissé seul devant ces questions, qui finissent par le dépasser. Au mieux chacun travaille en fonction de ses propres interprétations. Il en résulte d’abord des séries de confusions, des pertes de temps plus ou moins importantes, des divergences critiques, pour finir après quelques temps sur l’abandon pur et simple de la méthode.

Le pire des cas est lorsque tout ce "non cadrage" n’est pas détecté. Les conséquences peuvent alors prendre des proportions démesurées et faire échouer le projet entier. On a ainsi vu des équipes envoyer en production leurs projets, pensant en tout bonne foi que 100% des besoins étaient couverts, et se rendre compte le jour J que rien ne va. Ici on ne parle même pas de la dégradation progressive de l’ambiance et des conditions de travail.

Partant de ces constats, Thierry s’est imposé des règles simples à suivre dans le cadre des Développement Dirigés par les Tests. Pour cela il s’est attelé à se mettre dans la peau de chaque acteur d’un projet classique (chef de projet, développeur, testeur, client, etc.) et identifier les attentes et besoins de chacun. Il a pris en compte des considérations sur les coûts, les délais, les responsabilités, la simplicité, le respect des normes et de la qualité, la communication, sans oublier l’ambiance générale et le travail en équipe.

Après quelques tentatives et ajustements, Thierry a proposé une simplification cadrée des TDD qui se décompose en trois phases successives qu’il a naturellement nommé "3T". Les "Tests en Trois Temps" (3T) ont été présentés sur le site developpez.com ici.

La proposition 3T se décompose comme suit :
1) Le développeur A écrit une Interface décrivant le service à programmer. Les fonctionnalités correspondent exactement à ce qui est indiqué dans le cahier des charges. Chacune des règles mentionnées est recopiée, numérotée, référencée. Si besoin, on fait un aller-retour avec la MOA pour mettre à jour les spécifications. Le développeur A ne fait que recopier ce qui est écrit. Sa seule valeur est de transformer des mots en français vers du code source de qualité. A ce stade, il ne programme pas la fonctionnalité ; il ne fait que la décrire.
2) Le développeur B part du travail réalisé par A. Il écrit des tests complets en s’appuyant sur les interfaces écrites durant la première phase. Chaque règle mentionnée doit être reprise et testée séparément. Chaque exemple fournit fait l’objet d’un test spécifique. Le développeur B rédige ses tests selon une norme précise, s’inspirant de AAA (Arrange, Act, Assert), et commune à l’équipe. A la fin, tous les tests doivent échouer car la fonctionnalité n’a pas encore été développée.
3) Enfin, le développeur C programme la fonctionnalité demandée. Pour cela il s’aide des tests qu’il doit faire réussir progressivement. Chaque étape de ce processus est prise en charge par un développeur différent. Cela évite les tests de complaisance. Cela permet également de bien séparer les responsabilités et d’éviter de se mélanger les pinceaux. En outre, chaque développeur peut s’appuyer sur des bases très solides, rendant les temps successifs relativement simples ; il suffit souvent de recopier. Bien entendu, le travail réalisé à chaque étape peut faire l’objet d’une livraison, garantissant encore plus la qualité globale.

Pour aller plus loin, Thierry s’est demandé comment coupler 3T aux autres pratiques Agiles comme Scrum ou Kanban. Il a présenté un article humoristique sur le site de developpez.com, mettant en œuvre (et en pratique) quelques pistes, et disponible ici. Dans cet article, il met notamment en scène différents acteurs (cdp, développeur, architecte, client, etc.) du projet, ainsi que leurs attentes respectives, à travers plusieurs versions du produit.

mardi 20 décembre 2011

Agile Tour Paris 2011 : "Ni Gladiateurs ni Bisounours - Une équipe remarquable au quotidien par Christophe Thibaut d'Octo"

Description sur le site de l'Agile Tour : "Le succès -- et la difficulté -- pour un développeur, ça peut être de réaliser des prodiges techniques, de résoudre des problèmes intéressants, de choisir et maîtriser ses outils, de se former continuellement. Mais ça ne suffit pas. Pour réussir un projet, il faut former une équipe qui marche. Et une fois en équipe, les difficultés changent. Vous souvenez-vous d'avoir, durant votre parcours scolaire ou vos premières années de travail, été formé pour réussir en équipe ?
Pour réussir en équipe faites-vous appel à "l'esprit d'équipe" ? A "l'engagement" ? Au "leadership" ? Dans cette session, à travers des retours d'expérience, nous parlerons de quelques modèles, outils et pratiques qui permettent de surmonter trois difficultés du travail en équipe, à savoir: - comment exercer toute sa créativité ? - comment livrer à temps, tout le temps ? - comment se confronter mutuellement ?"

Finalement, comme je le disais dans mon feedback de la journée, un thème récurrent fut le premier point du manifeste Agile : les relations et interactions entre individus. Pour cette présentation, Christophe Thibaut nous parle de la formation d'une équipe Agile. Non pas du point de vue processus de formation au cours duquel vous rassemblez votre équipe. En fait, il parle plutôt des mauvaises pratiques qui empêchent une équipe de bien fonctionner, ceci via une liste d'anti-patterns à éviter. Je connaissais certains de ces anti-patterns pour les avoir subi lors de projets mal gérés (comme les "spécialistes" ou les "super-héros") et j'en ai découvert d'autres (l'équipe "feu de camp"). Il donne ensuite une série de contre-mesures pour se sortir de ces mauvaises pratiques. Une part importante de sa présentation a été la prise en compte des émotions des membres d'une équipe. Dans l'absolu, nous sommes tous des professionnels et dans un monde idéal, nous agissons toujours de façon posée et raisonnée.
Mais voici un scoop : nous ne vivons PAS dans un monde idéal ! Ainsi la gestion de conflits pouvant émerger d'actions ou de réactions engendrées par des comportements commandés par le "cerveau reptilien" est une nécessité. Christophe Thibaut présente des pistes pour gérer une équipe et la rendre "remarquable" donc :)

Sur la forme, la présentation était pleine d'humour et avec une grande pertinence, illustrée par des métaphores drôles et proches de nous. J'ai passé un bon moment et vraiment instructif !

ROTI : 5/5

Et voilà, cette conférence fut la dernière de ma journée sur le campus Microsoft et ce billet est mon dernier sur l'Agile Tour Paris 2011. En tout cas, je n'ai pas perdu mon temps, ce fut vraiment enrichissant et je suis très heureux d'avoir assisté aux présentations et ateliers où j'ai pu me rendre.
Mon objectif pour le prochain coup : y trainer mon patron ou ma commerciale pour les rallier à ma cause et développer une cellule Agile dans la boite :)

samedi 17 décembre 2011

Agile Tour Paris 2011 : "Améliorez l'efficacité de vos cérémonies agiles par Véronique Messager d'Ici & Demain"

Description sur le site de l'Agile Tour : "La méthodologie Scrum est simple. Cependant, au-delà de cette simplicité apparente, sa mise en œuvre efficace nécessite de nouvelles compétences, en particulier pour le scrumMaster. En effet, le scrumMaster a en charge, entre autres, l’animation des cérémonies agiles. Or, on s’improvise rarement animateur ou facilitateur, si on ne l’a jamais fait, et ces réunions ne se déroulent malheureusement pas toujours comme on le souhaiterait. Alors, on s’étonne, « on avait pourtant fait comme dans le livre ! » Peut-être ! Mais c’était sans compter les difficultés liées aux interactions entre les personnes, les jeux de pouvoir, la passivité des uns ou l’agressivité des autres, les digressions, les interruptions… ScrumMasters, animateurs ou participants, vous êtes peu à l’aise pour gérer ces situations difficiles ? Venez découvrir comment canaliser les comportements qui pénalisent le bon déroulement des cérémonies. Venez chercher les « ingrédients » d’une cérémonie réussie. Vous pouvez améliorer l’efficacité de vos cérémonies agiles."

Lorsqu'on intègre un projet Scrum qui fonctionne bien : c'est-à-dire que les membres de l'équipe communiquent correctement et beaucoup entre eux, les rituels se déroulent de façon fluide, etc... On a une impression de facilité et de simplicité dans l'application de la méthodologie : comme si ça se faisait tout seul. En effet, ça peut sembler simple sur le papier, Scrum propose un cadre bien défini : vous respectez les rituels, vous intégrer les artefacts et tout devrait rouler comme sur des roulettes et dans la bonne humeur :P C'est trop beau pour être vrai et ça ressemble au pays de Oui-Oui mais quand on a travaillé sur des projets qui marchent bien, c'est le sentiment qu'on risque de développer.

Cependant, pour atteindre une simplicité apparente, cela implique d'avoir des relations saines au sein du projet et de l'équipe. C'est le rôle du ScrumMaster de gérer cet aspect !

J'ai écrit un billet sur le fun en Scrum. Il est vrai que c'est un facilitateur, mais comme dans les arts martiaux, la chose qu'il ne faut pas oublier ce sont les BASES ! Que ce soit en aikido, en taekwondo ou en judo, même une ceinture noire travaillera les positions de base toute sa vie :)
La conduite de réunion n'échappe pas à cette règle et le ScrumMaster se doit de maitriser les techniques pour mener les cérémonies, désamorcer des situations conflictuelles entre les membres de l'équipes, etc...
Par exemple, les rétrospectives sont le moment où on donne la parole aux membres de l'équipe. Ceux-ci sont invités à prendre la parole et exprimer leur retour sur la vie du projet, les plus comme les moins. Le risque inhérent est d'y voir surgir des interventions non motivées par la volonté de progression mais motivées par des facteurs humains émotionnels qui peuvent mener à des relations conflictuelles (réglements de compte etc...) et du coup,
1) gâcher le temps consacré à la rétro;
2) dégrader l'ambiance générale du projet.

Véronique Messager a donc orienter sa présentation sur les techniques que doit connaitre le ScrumMaster pour être le garant de la bonne application de Scrum via sa conduite de réunion. Elle y donne des pistes et des méthodes pour gérer les membres de l'équipe en cérémonie, pour analyser les situations de conflits et en sortir.

Au final, ce fut une conférence très intéressante pour moi qui souhaite devenir ScrumMaster :)

ROTI : 5/5

mercredi 14 décembre 2011

Agile Tour Paris 2011 : "Kanban pour la préparation - Scrum pour la réalisation par Bertrand Dour d'Agile Genius"

Description donnée sur le site de l'Agile Tour : "L'objectif de la session est de présenter une utilisation combinée de Kanban et de Scrum pour la mise en place et la réalisation d'un projet en se basant sur l'expérience de refonte des applications en ligne du PMU. L'idée derrière la démarche est de tirer parti de l'environnement agile dès la phase d'initialisation du projet (préparation des environnements, PoC et prototypes, écriture des user stories, planning poker,…) en utilisant le Kanban et continuer la démarche en utilisant Scrum."

Première constatation : cette présentation n'était pas destinée à un public de novice total. Bertrand n'est pas revenu sur les principes de Kanban ni Scrum. Perso, j'ai eu un petit soupir de soulagement d'avoir déjà pratiqué Scrum et avoir lu le livre "Kanban et Scrum - tirer le meilleur des deux". Ce n'était pas le cas de Thierry, il n'avait pas lu ce livre qu'il m'avait justement recommandé ! Ironie... :P Heureusement, il est très chanceux, et juste avant nous avions assisté à la très bonne présentation "Améliorez votre Kanban" de Jonathan Scher qui lui a servi d'introduction du coup :)

Le plus intéressant selon moi était l'application de l'Agile dans un environnement hostile. L'organisation du PMU n'était pas favorable à une intégration de l'Agile (Bertrand a même parlé à un moment de bras de fer avec la hiérachie). C'est une chose que chacun a affronté ou affrontera dans sa carrière Agile et son exemple sera probablement une inspiration le moment venu.

Cette approche progressive est une bonne manière de gérer le côté réfractaire des gens face au changement et faire entrer puis accepter l'Agile : utiliser Kanban dans un premier temps puis glisser vers Scrum plus tard.
Kanban est moins rigide et possède moins de préconisations que Scrum et cela a permis de faire entrer des pratiques Agile sans trop révolutionner le quotidien. C'est par ces petites touches que finalement, ils en sont arrivés à une pratique de Scrum sur la phase de réalisation.

C'est une bonne leçon pour qui veut introduire de l'Agile sur un projet mais qui fait face à une hiérarchie frileuse à l'idée de tout chambouler dans ses processus et habitudes. Car c'est bien le but : changer la façon de fonctionner (voir la philosophie) d'une organisation, d'une société ou du moins d'une entité.

ROTI : 4/5 (ce fut une excellente présentation, plombée quelque peu par une session de questions/réponses sortant du contexte)

samedi 10 décembre 2011

Agile Tour Paris 2011 : "Le bout du Tunnel par Pierrick Thibault d'Agile Garden"

Description donnée sur le site de l'Agile Tour : "Nous connaissons tous l'effet tunnel pour avoir travaillé sur des projets au long cours pilotés par les spécifications. Pourtant, de nombreux projets continuent à fonctionner de cette manière en suivant le bon vieil adage "c'est sûr, on fera mieux cette fois-ci". Il est en effet difficile dans la multiplicité des paramètres de la conduite de projet informatique de faire ressortir que le mode spécifications écrites, développement long, livraison est en lui-même une cause importante d'échec. Cet atelier ludique propose de montrer de manière simple les limites des spécifications écrites et de faire apparaître l'intérêt de miser sur les interactions entre le porteur de la vision et l'entité en charge de sa réalisation. Le corps de l'atelier est constitué de 2 sessions totalisant 30mn, le reste du temps étant réservé à la présentation et mise en place de l'atelier, au dépouillement des résultats et à la discussion."

L'atelier consistait à former des équipes de 2 personnes :
- un client avec sa vision d'un produit (un dessin géométrique en l'occurence);
- un développeur en charge d'exécuter ce dessin.

Session 1 : Le développeur de chaque équipe sort de la salle. Puis uniquement par écrit (aucun dessin ni symbole), le client doit mettre sur une feuille les informations qui permettront à son développeur de reproduire le dessin. Au bout des 10 minutes, le client sort de la salle avec le dessin qui a servi de modèle et le développeur entre. Ce dernier a 10 minutes à son tour pour faire un dessin en se basant sur les écrits que lui a laissés le client.

Session 2 : distribution d'un nouveau dessin mais cette fois-ci, le client et le développeur ont le droit de rester dans la salle. Le client cache le dessin au regard du développeur et lui donne des instructions uniquement à l'oral (pas de signe des mains) pour reproduire le dessin qu'il voit. Le développeur peut poser des questions à son client.

Résultat : le dessin produit à la session 2 est plus fidèle (voir complètement fidèle) au modèle, alors qu'il y avait beaucoup de décalages sur le dessin de la session 1. Et pour plusieurs groupes, le travail a été plus court lors de la session 2 : 5 minutes pour finir au lieu des 10 allouées.

Cet atelier a fait ressortir en pratique les travers de la gestion de projet en cycle en V. Les spécifications écrites, malgré les efforts du client, ne seront pas assez claires ni assez exhaustives pour permettre au développeur de sortir un produit qui collera à la vision client. La différence de culture et de vécu de chacune des parties amènera forcément des interprétations différentes des écrits. De plus, même un temps important consacré à l'écriture ne permettra pas d'avoir une communication aussi bonne qu'une discussion avec des échanges. La session 2 l'a bien prouvé : sur un mode de feedbacks fréquents et d'interactions entre le réalisateur et son client, le résultat est bien plus proche de l'attente de ce dernier.

Qu'ai-je appris au cours de ces deux sessions de jeu ? Finalement, des choses que je savais déjà. MAIS la grande force est d'avoir, au travers d'un jeu simple de 30 minutes, de quoi faire réfléchir les participants et aussi donner des arguments pour convaincre les gens de passer à l'Agile.

Vous pouvez le faire avec vos collègues : ça ne dure que 30 minutes et c'est facile à mettre en place !

ROTI : 5/5

mercredi 7 décembre 2011

Evénements : "De retour de l'Agile Tour"

Mise à jour : vidéo de la keynote de Martin Woodward

Et voilà ! Je me suis rendu à l'Agile Tour Paris hier. Bilan : une expérience clairement positive de la journée.

En premier lieu, une très bonne présentation de Martin Woodward. Sans entrer dans les détails de sa présentation (disponible ici) il est revenu sur les erreurs et mauvaises pratiques du 20ème siècle. Ensuite, un tour a été fait des bonnes pratiques engendrées par l'émergence de l'agilité et qui sont appliquées aujourd'hui au 21ème siècle. Et enfin on a eu une toute petite partie sur la vision de ce qui viendra dans le futur.
Alors sur la forme, les slides étaient vraiment très (très) bien faits et pros ! Ok, on ne pouvait pas s'attendre à moins, mais c'est agréable d'avoir des animations discrètes mais esthétiques (ça ne piquait pas les yeux comme ces titres en Word'Art qui arrivent en faisant une spirale sur toute la page) et le ton de la présentation était plaisant et humoristique avec des anecdotes et des expériences personnelles. Même en anglais, c'était très accessible et les applaudissements à la fin n'étaient pas volés.

Sur l'Agile en particulier :
- des choses que je savais ont été redites de façon plus jolies et attractives (par exemple via l'atelier "Le bout du tunnel");
- des fondamentaux rappelés lors de la conférence "améliorez vos cérémonies agiles" ont fait écho en moi par rapport à mon billet sur le fun en Scrum : avoir du fun, c'est bien, mais garder en tête les fondamentaux de conduite des réunions est primordiale au bon scrum master;
- j'ai aussi découvert des choses nouvelles (surtout lors de la conférence "Ni Gladiateurs Ni Bisounours").

Dans l'ensemble, un gros centrage pour moi sur l'humain, que ce soit au niveau de l'individu ou de l'équipe. La gestion des relations entre les individus devient une tâche extraordinairement importante, allant bien au-delà de la simple constitution d'une équipe d'individus performants.
Tout ceci me conforte dans ma motivation de continuer sur ce mode de gestion projet : tendre vers l'excellence en restant sain et proche de l'humain.

Hors Agile, voici ce que j'ai appris :
- si vous voulez qu'on vous parle, arborez un nom de grand compte sur votre badge (BNP, AXA, Carrefour, ...) et vous vous ferez accoster;
- tout le monde à quelque chose à vendre : sa boite ou soi-même;
- les petites salles de conférence sentent le poney après une journée.

Je ferai des billets sur les conférences et ateliers qui m'ont marqué dans les prochains jours.

ROTI : 4/5

lundi 5 décembre 2011

Evénements : "Agile Tour Paris, c'est parti !"

Checklist pour demain :
  • Confirmation d'inscription => ok
  • Costume + cravate => ok
  • Sacoche avec cahier et stylos => ok
  • Téléphone rechargé => ok
  • Cartes de visite => ok


La suite demain en direct sur mon twitter @HingCChan :)

jeudi 1 décembre 2011

Mes deux cents : "Planning poker et l'estimation relative"

On pratique en Scrum le planning poker et l'estimation relative car les user story (US) sont estimées les unes par rapport aux autres en point d'histoires. Par exemple, l'US-127 vaut 8 points car elle demande 4 fois plus de travail que l'US-98 qui elle en vaut 2.

L'estimation est relative à un deuxième niveau également : selon les individus.

Pour comprendre, revenons un instant au concept de jour/homme : l'expérience sur un projet me permet d'estimer qu'une US valant 2 points sera traitée en une demi-journée par mes soins. Cela ne veut pas dire qu'un autre développeur mettra le même temps. 2 points chez lui peut être équivalent à 1 jour de travail. Au moment d'estimer une US lors du planning poker, je pense qu'elle me prendra une demi-journée mais mon voisin pense que lui mettra une journée : nous sortons donc tous les deux la carte à 2 points ! :)
Au fond, ce qui importe, ce n'est pas tant le temps que prendra telle ou telle US mais plutôt le nombre de points (donc le quantité de travail) qui se sera abattu dans le sprint (d'où le concept de vélocité en Scrum).

L'estimation relative et les points d'histoire ne sont pas des concepts évidents au premier abord pour les novices. Les gens qui sont habitués au jour/homme, et sans l'aide de l'étalon de référence qu'est le jour, ne savent pas forcément comment estimer les US car ils ne possèdent pas d'US de référence sur laquelle se baser en arrivant sur un projet. C'est assez perturbant au début, je l'admets.

Une bonne pratique dans un précédent projet était de ne PAS faire estimer les nouveaux arrivants lors du premier planning poker auquel ils participaient. Cela leur permettait d'observer le rituel (s'ils étaient novices en Scrum) et ensuite de travailler sur des US estimés par les autres pendant le sprint. A la fin du sprint, au planning poker suivant, ils pouvaient alors participer à l'estimation car ils avaient des US de référence. Chacun savaient dès lors ce que valait 1 points chez lui en terme de charge de travail.

Un serious game intéressant au sujet de l'estimation relative est le doggy planning expliqué par Michael McCullough et traduit par Fabrice Aimetti :
[EN] Doggy Planning
[FR] Doggy Planning

jeudi 24 novembre 2011

Mes deux cents : "Prendre 3 minutes pour préparer son daily scrum !"

Jusqu'ici, j'ai participé à des projets Scrum en tant que développeur. Je ne suis ni scrum master, ni product owner, "juste" un membre de l'équipe.

En tant que membre de l'équipe (développeur, testeur ou architecte), vous êtes protégé pendant le sprint des perturbations extérieures par votre scrum master.
Ok ça c'est cool de sa part, mais être une équipe auto-organisée implique aussi que chacun apporte sa contribution. On vote lors des planning poker et on s'exprime pendant les rétrospectives.

Une chose pourtant sur laquelle je voudrais qu'on insiste, c'est la participation et la contribution des membres d'une équipe au daily scrum (ou daily stand-up meeting).

Au premier abord, ce rituel semble facile à appréhender : piece of cake ? Pas tant que ça si on ne se prépare pas un minimum. J'ai connu des daily scrum où des intervenants dépassaient largement un temps de parole raisonnable (autour de la minute normalement), entrainant ainsi un dépassement du quart d'heure alloué en général à cette réunion. Pourquoi ? Et bien parcequ'ils n'avaient pas préparé leur speech en vue de répondre aux trois questions : Qu'ai-je fait hier ? Qu'est-ce-que je compte faire aujourd'hui ? Ai-je des points de blocage ?

Je le redis : si court soit-il, le daily scrum se prépare ! Quand j'arrive à 9h30 et que le daily scrum est à 10h, je trouvais 3 minutes pour préparer ma petite intervention (de préférence avant le café du matin parceque le temps passe vite quand on papote avec les collègues :)

C'est assez rapide : je jette un oeil sur mon cahier pour me remémorer ce que j'ai fait. Si je suis organisé, je tiens à jour une ToDo List de ce que je dois faire. Je peux aussi anticiper un peu et me poser la question de qui aurait une expertise sur les points bloquants. Une anti-sèche est autorisée et tout projet Scrum possède un stock conséquent de post-it. N'hésitez pas à y noter vos tâches. Je ne recommande cependant pas d'emmener un cahier, c'est un peu trop formel pour un stand-up, et on peut y lister trop de choses : vous n'avez qu'une minute pour parler ! :P

Je choisissais aussi à l'avance mes mots, pas grand chose mais juste ce qu'il faut pour avoir un discours fluide non pollué de "euh... et puis après je euh...". Ca a l'air évident et de bon sens ainsi présenté (comme tout ce qui touche à l'Agile :) mais ce n'est pas appliqué par tout le monde. Scrum est sympa à suivre mais chacun doit y mettre du sien pour que ça s'écoule facilement.

Une bonne pratique que j'ai depuis pas mal d'année maintenant est de m'imprimer un calendrier chaque mois avec des cases suffisamment grandes pour y inscrire de façon succinct ce que je fais chaque jour : pas sous la forme "j'ai travaillé sur le module de recherche des clients" mais plutôt "US 79 - rech. client". Ca vous remet en tête en un clin d'oeil ce que vous avez fait tel ou tel jour !
Une façon rapide de s'imprimer un calendrier est de le faire depuis Outlook :)
Autre avantage : il s'avère que sur mon premier projet Scrum, chaque développeur effectuait la démonstration de ses user story en fin de sprint. Le calendrier me donnait une vue rapide des user story que j'avais traitées pendant le sprint, donc celles que j'aurais à montrer au product owner.

mercredi 23 novembre 2011

Evénements : "En route pour l'Agile Tour Paris 2011"

Le mardi 6 décembre 2011 aura lieu à Issy-les-Moulineaux sur le campus Microsoft l'étape parisienne de l'Agile Tour 2011.

Au menu, des conférences sur l'Agile : Scrum, Kanban, des retours d'expérience, des serious games, etc...

Je ne pourrai pas assister à toutes les conférences et c'est bien dommage... :(

En tout cas, vous pourrez me suivre au fil de cette journée sur mon twitter @HingCChan !

mardi 22 novembre 2011

Mes deux cents : "Scrum is fun"

Un côté de Scrum que je tenais à aborder est le fun que j'ai eu à appliquer cette méthode au sein des projets auxquels j'ai pu participer.

Il y a de nombreux avantages dans l'Agile et Scrum : l'auto-organisation de l'équipe qui motive et responsabilise ses membres, la relation forte et de confiance avec le client, l'amélioration des livrables et tout le tralala... En tant que développeur, mon travail est valorisé (en démo et en rétrospective), je suis motivé parcequ'on m'écoute (daily scrum), on me laisse faire des choix et donner mon avis (planning-poker, vote de confiance, note d'itération). C'est clair : travailler sous pression constamment, ça ne me fait pas plaisir. Qu'un chef ne pointe que mes erreurs, ça me démotive. Avoir une relation conflictuelle avec mon client ne me fait pas me sentir utile.

Mais sérieusement, si Scrum était une méthodologie ennuyeuse et lourde, je ne pense pas que j'aurais été autant réceptif à l'époque où je la découvrais, malgré les avantages annoncés.

En débarquant sur mon premier projet Scrum, j'ai découvert un monde peu commun. On m'a raconté l'histoire du poulet et du cochon, on m'a parlé de concepts comme les pizza team, j'ai participé à du planning poker... Des concepts rigolos à intégrer pour participer à des rituels un peu bizarres. En tant que novice, j'étais amusé. Et c'était là que ça s'est joué : tout ceci était vraiment fun, d'où mon envie d'en connaitre toujours plus sur la méthode et d'en débattre avec tous les membres de l'équipe et au-delà !

Conclusion : le fun est un facilitateur (haha ! on l'aime ce terme ! :)
Le fun est une force. Mais ne vous méprenez pas : je ne parle pas de s'amuser au lieu de travailler, je parle de travailler dans une bonne ambiance et une émulation de tous les jours car on en a envie. Il n'y a pas besoin de faire cela par la contrainte et la pression. Si c'est fun de bien travailler et de produire de la qualité, ce sont les membres de l'équipe qui auront envie de progresser et c'est le projet qui avancera.

jeudi 17 novembre 2011

Mes deux cents : "Lean/Scrum/XP"

Pour préparer ma première présentation Scrum, je m'étais mis à la recherche d'un schéma situant Scrum par rapport au Lean et à l'eXtreme Programming (XP).
Voici celui que l'on trouve généralement (enfin celui-ci est dessiné par mes soins) :
Ici, XP est contenu entièrement dans Scrum.
Cependant, à la suite de discussions (plus ou moins animées) autour de Scrum et Agile avec des collègues, je représenterais plutôt Scrum comme dans le schéma ci-dessous :
Scrum intègre des outils d'eXtreme Programming comme les sprints (itérations en XP) ou le planning poker. Par contre, le pair programming par exemple n'était pas systématiquement employé sur les projets Scrum auxquels j'ai participé.

samedi 12 novembre 2011

Lecture : "Scrum et XP depuis les tranchées" d'Henrik Kniberg


Ce livre est clairement un must-have.
D'ailleurs il est gratuit et téléchargeable ici donc vous n'avez aucune raison de ne pas le posséder :)

A qui s'adresse-t-il ? Je dirais à un développeur qui va intervenir sur un projet Scrum mais est débutant dans cette méthodologie (en fait c'était moi là).
D'ailleurs, quand un développeur qui ne connaissait pas Scrum rejoignait notre équipe, je recommandais systématiquement la lecture de ce livre, avec le sourire en coin amusé du Scrum Master.

La lecture de "Scrum et XP depuis les tranchées" se fait en un weekend (je l'ai lu dans le RER paresseusement en 1 semaine, c'est dire...).
Cependant, il contient ce qu'il faut savoir pour comprendre les concepts et rituels pour ne pas être perdu lors d'un démarrage.

Comme je le disais : la lecture est rapide. Ceci est facilitée par le style d'Henrik Kniberg tout en humour et en exemple.

A l'origine, il m'a été recommandé par Thierry Leriche quand je ne connaissais Scrum et Agile que de nom.
C'est via ce livre que j'ai découvert Scrum et j'en profite pour en faire le kick-start de mon blog dédié à Scrum et au monde de l'Agile.

A mon tour de vous recommander cette lecture ! :)