Pour commencer, après quelques péripéties (erreur sur la gare de RER, Val de fontenay != Fontenay sous Bois ), me voila sur les lieux dans le magnifique chalet de la porte jaune. Le cadre est très sympa, très vert avec un petit lac, des oies, des canards, des chats qui se baladent…
Je récupère mon badge ainsi que mon sac de goodies. Cette année, le cadeau était un timer (style minuteur de cuisine), cool, j’en voulais justement un (très important pour timeboxer une réunion).
La journée commence par une brève présentation, cela me permet de constater que l’évènement est une réussite : plus de 250 inscrits venant de toutes la France, de Belgique, du Canada (et d’ailleurs). Décidément, l’agilité en France à de beaux jours devant elle.

Première conférence de la journée : Comment soigner sa schizophrénie MOA/MOE

Le but de cette intervention était de monter comment rapprocher ces deux entités au travers des spécifications exécutables. L’accent est principalement mis sur Fitnesse.
J’en retiens que le fait d’écrire ces tests de hauts niveaux en collaboration avec la MOA permet de structurer la phase de spécification, et de lever toute ambiguïté et interprétation.
De plus, cela structure la manière de coder tout comme le fait le TDD à un niveau plus bas.
Les spécifications sont faites sous formes de scénarii au formalisme : Given … when … then …
Je vous recrache le schéma présenté sur les tests qui permet de situer les différentes catégories :

Je trouve qu’il est pas mal.
L’outil présenté est bien évidemment Fitnesse (utilisé avec SLIM) qui est pour un eux un premier bon pas vers les spécifications exécutables. Cependant, l’aspect peu sexy du wiki peut être un frein à l’acceptation par la MOA selon eux.
Parmi les problèmes soulevés il y a également le découplage du versionning avec le versionning de l’application (deux workflow différents, un wiki, l’autre basé sur le SCM), cependant il parait que la communauté Fitnesse y travaille. En discutant avec les gens de Pyxis, nous avons constaté que le problème était similaire sur GreenPepper qui se base sur la gestion des versions par Confluence.
Enfin, deux pistes à suivre : Jbehave2 (plutôt un DSL pour écrire du test à ce que j’ai compris) et Twist, poussé par Thoughwork, qui propose une solution basée sur Eclipse RCP pour écrire et avoir une aide syntaxique à la volée des tests fonctionnels (payant cependant). A creuser…

Ceintures et brettelles, test d’une application Web puis, mon JavaScript est agile lui aussi.

Je regroupe en une seule ces deux présentations car la deuxième est la suite de la première.
Arnaud Bailly, nous détaillait la chronologie des méthodes de tests utilisés pour tester une application RIA, avant de s’arrêter sur la méthode qu’ils avaient retenu.
Tous d’abord, il nous présente le duo Selenium/WebDriver. C’est sympa, les écrans défilent, c’est facile, on peut l’enregistrer avec un mode record/play. Mais au final, c’est trop lent avec prêt de 30 secondes pour lancer 3 tests et surtout c’est très dure à lire (donc à maintenir) et très peu souple. Dès que l’on bouge un peu à la page, tout s’effondre et il faut retravailler les expressions Xpath d’accès au élément HTML.
Ils ont essayé d’améliorer la chose en créant une surcouche pour décorréler la partie métier de la partie quincaillerie de manipulation des pages. Cependant, pour lui les problèmes demeurent et surtout la lenteur d’exécutions des tests. Sur un projet 500 tests peuvent mettre une nuit entière à s’exécuter. Dans ce contexte il se pose la valeur ajoutée par ceux-ci.
La solution qu’il a choisie est de tester unitairement la partie cliente tout comme il le fait pour la partie serveur. Ce qu’il cherche à tester c’est du JavaScript fait avec une bonne dose de JQuery. Pour cela il a démontré comme se créer un DSL en JavaScript (en utilisant massivement les prototypes), afin de rendre les tests facile et très expressifs. Pour finir il a intégré le tout avec HTMLUnit et Maven.
C’est assez sexy, mais je crains que le coût d’écriture du DSL soit trop élevé. De plus, qu’est ce qui prouve que le DSL n’est pas buggé. Je suis mitigé. Sinon il parait que Google a lancé un projet similaire multi-navigateurs, je vais chercher (c’est ici ).

Rétrospectives, la clef de l’amélioration continu.

Une présentation assez rapide sur laquelle j’ai pris peu de note.
Cependant, elle m’a fait pointer l’intérêt crucial qu’apportait les rétrospectives d’itérations et de projets ainsi qu’également la complexité de garder du dynamisme autour de celles-ci. En fait au bout de quelques itérations elles peuvent devenir routinière et il devient alors intéressant de varier les approches et les exercices. A ce titre, j’ai bien aimé le jeu de carte proposé par François Bachmann et Jacques ? qui ont synthétisé dans quelques cartes assez sympas le livre « agile retrospective ». Je vous conseille d’aller voir sur leur site www.alchimiste-agile.com
En vrac les infos que j’ai noté :
Pour les rétrospective de sprint, prendre 30’ par semaine d’itération, avoir un groupe réduit (équipe + chef de projet).
Pour les rétro de projets, avoir une équipe la plus ouverte possible (inviter le management, la production voir même les commerciaux). Préparer des débriefs individuels avant et essayer de sortir la rétrospective du lieu de travail habituel (terrain neutre).
Une idée pour collecter de l’information :
Placer une pile de post-it et écrire en vrac les idées des participants, regrouper en grosse catégories et identifier ainsi les principaux problèmes et réussites. Trouver une ou plusieurs actions pour l’itération suivante.
Pour la rétrospective de projets l’aspect chronologique est préféré, on refait la liste des faits selon un axe.
Il y a un groupe yahoo pour ceux qui ont des questions.

La suite dans un prochain post…

J’hésitais un peu à y aller, craignant que les présentations soient plus de l’introduction à Scrum. Puis je me suis décidé pour voir Eric Mignot de chez Pyxis, voir le Touilleur (aka Nicolas Martignole) faire sa première et pour revoir Guilaume Bodet qui avait fait une très bonne présentation au Scrum User Group en mars. Bien m’en a pris, car la soirée était très instructive !

Première présentation

La première présentation, sous la forme d’un dialogue, a été une introduction à Scrum. Le Touilleur en a profité pour ressortir sa métaphore de la machine à laver.

Je ne ferais pas un topo complet de cette présentation qui a principalement reposé les bases de Scrum et du manifeste agile, mais j’ai cependant bien aimé certaines idées avancées par Eric Mignot.

Notamment : apprendre Scrum c’est désapprendre autres choses (avec en cible de mire les processus lourds et parfois incohérents imposés par certaines méthodes).

L’idée véhiculée tout au long de cette présentation est que les méthodes agiles ne doivent pas être vues comme une méthodes à appliquer aveuglement « out of the box ». Les méthodes agiles sont là pour nous faire réfléchir sur ce que l’on fait, et pour nous redonner le goût de faire du dev. Pour cela, elles proposent un ensemble d’outils, mais elles ne doivent pas être vues comme une méthode à part entière.

Le but ce n’est pas de faire du scrum, mais de s’améliorer. Ainsi, pourquoi pas introduire petit à petit le daily Scrum ou bien la démonstration post itération tous les mois ?

Je vous ai refait au propre le schéma d’Eric qui synthétise assez bien Scrum ci-dessous :

Info intéressante, Eric estime que la vélocité sur un projet se stabilise au alentour du 5^ème ou 6^ème sprint.

Deuxième présentation

La deuxième présentation, proposée par Guillaume Bodet a été encore une fois extrêmement enrichissante. Guillaume nous proposait de confronter la réalité de l’introduction de Scrum sur les équipes en place.

Premier problème, comment trouver un Product Owner ? Pour cela, et contrairement à ce que la littérature propose on se rend compte fréquemment :

• que le product owner n’est pas forcément seul
• qu’il n’est pas forcément responsable de tout
• qu’il n’est pas forcément un visionnaire

On n’a pas tous un Steve Jobs dans nos entreprises. Le rôle de du product owner est avant tout un rôle logique.

Deuxième problème comment on démarre un projet agile et comment on constitue un Backlog de produit.

Pour démarrer un projet il faut au mininum :

• la taille estimée du projet
• le ROI
• la liste des principaux risques
• la composition de l’équipe

Le tout pouvant tenir dans un document d’une dizaine de pages max.

A partir de ceci on obtient le go du projet et on peut partir sur un Sprint 0 avec une équipe réduite. A l’issu de ce Sprint le Product Owner, aidé par l’équipe, aura créé un premier backlog de produit.

Le burdown chart a ensuite été évoqué. La notion intéressante est de mettre en avant deux courbes, une qui montre les stories implémentées à partir de l’estimation initiale, l’autre pour montrer l’ajout de story (ou le retrait) ou la réévaluation des tâches. C’est plus motivant et vendeur de voir un burdown qui globalement est en baisse.

Guillaume nous livre la difficulté rencontrée de vendre le burdown aux comités de direction, habitués au diagramme de Gantt et aux jalons clairs. Il convient selon lui de maintenir à jour 5 niveau de planification :

• daily (quotidienne en heures)
• itération (toutes les 2 semaines)
• releases (trimestriel)
• product roadmap (semestriel)
• product vision (annuel)

La scalabilité de Scrum a ensuite été mise en avant au travers de plusieurs retours d’expérience. Le but est d’avoir ses équipes de Scrum avec chacun un ScrumMaster. Puis les ScrumMaster se retrouvent tous les 2/3 jours avec un « Meta ScrumMaster » qui est le ScrumMaster des ScrumMasters. Le principe s’applique en théorie sur n’importe qu’elle profondeur (j’ai déjà vu ça dans des présentation de Yahoo).

Sur le projet ProRail au Pays-bas, 25 personnes étaient réparties en 4 équipes. La V1 a été livré au bout de 8 mois puis les releases s’en sont suivis tous les 3 mois.

Enfin, Guillaume a fini la présentation en parlant d’architecture.

Il met un léger bémol au principe d’architecture émergente. Selon lui, l’architecture doit quand même être réfléchi au début du projet, on sait globalement qu’elles vont être les besoins et on doit prévoir ce dont on aura besoin au minimum. Selon lui, les erreurs d’architecture peuvent être très lourdes à corriger (si c’est possible) si l’architecture est fondamentalement fausse.

Il a fini par présenter la notion d’architecte agile (que l’on trouve présenté sur le blog de Xebia) 

L’architecte agile est cet architecte qui propose des règles flexibles plutôt que dogmatique.

D’après Scott Ambler (IBM) :

• piloter l’architecture par les besoins
• essayer de modéliser à plusieurs
• préférer la collaboration plutôt que la documentation (à quoi servent des best practices de centaines de pages si personnes ne les lit ni ne les comprend).
• faire simple (KISS)
• s’attaquer aux grandes problématiques tôt, régler les détails au moment voulu
• rester flexible
• publier les modèles d’architecture/métaphores.

Pour conclure, la soirée a été encore très intéressante. Merci aux présentateurs et au ParisJug pour ces présentations de qualité.

Un résumé très complet et avec photos est disponible également ici.

De plus, l’article propose une méthode pour aller vers cet objectif. La méthode proposée et je trouve très interessante, elle propose de définir les domaines à travailler, d’identifier le but de tavailler ce domaine, puis de définir un ensemble d’actions concrètes. Rien de bien nouveau, cependant, j’ai trouvé intéressant la méthode qui est de travailler de manière incrémental, plutôt que de travailler full time un sujet. Mieux vaux travailler un ensemble de sujet et d’itérer dessus pour monter en compétence. Cela donne plus de recul et une meilleure vision d’ensemble. A titre d’exemple, l’année dernière en travaillant Spring,  je travaillais en parallèle les design pattern, le fait de comprendre des design pattern comme le « template » ou le « stategy » m’ont aidé à avoir une meilleure compréhension de Spring et de son utilisation.

Après avoir lu l’article j’ai créé mon propre tableau d’objectif, je vous le livre dans sa version alpha :

Je pense que cela vaut le coup de se définir des objectifs et d’y travailler quotidiennement. En effet, on a malheureusement tendance à ne se focaliser que sur les sujets que l’on connait ou qu’y sont les plus faciles. Or, être expert c’est justement avoir l’esprit ouvert et connaître tous les sujets connexes au sujet maitrisé.

Lorsque l’on atteint un niveau correct dans un domaine on a tendance à s’arrêter sur cet acquis et à ne plus voir le reste. Le schéma ci-dessous que j’ai piqué à Kathy Sierra l’illustre bien :

D’un autre coté, le premier article nous fait bien comprendre que l’on ne peut pas se reposer sur nos employeurs pour nous prendre la main et nous guider vers ce genre d’objectif. Nos buts ne sont pas les mêmes :

Your company expects results from your work: reliable, with minimal mistakes and focused on the company main goal – make money. Your employer could provide minimal training to help you with job requirements. However, your growth will be constrained by company needs, timelines, work assignments and acceptable methods.

En développement logiciel les technologies vont tellement vite que l’on ne peut surtout pas se permettre de se reposer sur une compétence acquise.

Enfin, je terminerai sur cet article, qui nous explique les qualités qui font selon lui un véritable expert  :

• les connaissances
• l’expérience
• des capacités de communications
• un réseau
• la curiosité

Pour y parvenir, il nous propose de travailler sur ces axes :

• travailler continuellement
• pratiquer
• se faire un réseau
• acquérir des capacité de présentation (plutôt au sens marketing, savoir en mettre plein la vue)
• partager son expertise

Rendez-vous dans 2, 3 ans pour voir si la méthode marche

Tests Logiciel

View more presentations from nrichand. (tags: java tdd)

En effet, j’ai remarqué que beaucoup de gens connaissaient le terme eXtrem Programming. Malheureusement, pour ces personnes les seules idées qu’ils en restent sont : « XP c’est coder à deux sur un seul PC ? Très peu pour moi… » ou bien « XP c’est coder et ne pas faire de docs ? C’est faire un projet à l’arrache …».

Et bien non ! XP, et plus généralement les méthodes agiles, ce n’est pas ça !

Méthodes agiles … What’s that ?!

Qu’est ce que les méthodes agiles, en quoi ça nous concerne et surtout qu’est ce que cela peut nous apporter ?

Ca me concerne :

D’après les rapports du Standish Group (plus ou moins contesté), les chiffres concernant les réussites de projets informatiques sont très faible, même s’ils évoluent à la hausse :

Pourcentage de réussite des projets informatique.

Mitigés voulant dire : un important retard ou surcoût, ou bien un produit ne correspondant pas aux besoins du client.
Les chiffres sont éloquents, nous avons encore beaucoup de chemin à faire…

Devenir agile, qu’est ce que cela :
Les méthodes agiles sont nées d’un mouvement de protestation face aux méthodes classiques de gestion de projets (cycle en cascade, cycle en V, normes ISO, …) et ont prises leur envol lors de la création du manifeste agile en 2001. Les principes agiles sont :

1 ) Mettre en avant les humains, favoriser leurs interactions et donc donner moins d’importances aux processus et aux outils.
Casser le système de hiérarchie – n’avez-vous jamais eu l’impression des fois de jouer au téléphone arabe ? – et favoriser les contacts (directs de préférence) entre les personnes, notamment entre l’équipe de développement et le client.

2 ) Redonner au client le pouvoir par rapport au cahier des charges.
Actuellement, le cahier des charges a pris une place déterminante dans les projets. C’est à lui que l’on se réfère incessamment. Lorsqu’il est validé, c’est lui qui détient la vérité et non plus le client. Chaque nouvelle demande peut être refusé au titre qu’elle n’est pas spécifiée dans le cahier des charges. Conséquence, les phases de recensement et d’expression des besoins sont par fois très longues et sans réelle fin, le client ayant peur de s’engager.

3 ) Gérer les priorités. Le client doit être le responsable de la priorité des besoins, c’est à lui (aidé éventuellement par l’équipe) de déterminer quelles fonctionnalités sont les plus importantes et méritent d’être développé au plus tôt.

4 ) Accepter le changement. C’est là, que la notion d’agilité prend tout son sens. Actuellement, les changements sont vécus comme une tragédie, certains sont acceptés (mais difficilement vécu par les développeurs qui y voient un surplus de travail), d’autres sont refusés car non inscrit dans le CDC et doivent faire éventuellement l’objet d’un avenant au contrat.
Dans les méthodes agiles, le changement est accepté, car normal. Les besoins sont souvent difficiles à appréhender dans les projets informatique, car complexes et immatériels. De plus, ils peuvent évoluer en fonction de la conjoncture (ex : un concurrent sortant un produit similaire avec des fonctionnalités innovantes). Il est normal d’accepter le changement, dans ce cas là, c’est au client, à tout moment, de remettre à jour les priorités et d’accepter le développement de nouvelles fonctionnalités aux dépend d’autres.
Les fonctionnalités annulées feront soit l’objet d’un autre lot, ou bien seront définitivement supprimées. Est-ce réellement un souci ? Au vu de la présentation de la présentation de Jim Johnson (Keynote speech, XP 2002) la question se pose :

Pourcentage d’utilisation des fonctionnalités implémentées et fonctionnant

5) Utiliser un cycle de développement itératif et incrémental. Il est important de découper les développements en périodes de temps dont la durée est fixe. Ces périodes de temps sont appelées itérations ou sprints.

Au début de chaque itération :

• le client décide des fonctionnalités à traiter en priorité,
• les développeurs estiment la durée de chaque fonctionnalités,
• en fonction de la vélocité (que l’on pourrait raccourcir à la productivité de l’équipe) on détermine les fonctionnalités qui feront partie de l’itération.

Il est important que les itérations restent courtes (de 2 à 6 semaines max). A la fin de l’itération les fonctionnalités livrées sont testées, intégrées et utilisables. Le client peut ainsi décider de passer en production le produit après n’importe qu’elle itération, s’il le trouve suffisamment avancé.

L’intérêt de ce découpage en itération et multiple :

• stimuler les équipes et éviter l’effet ‘gaz parfait’. En effet, un développeur (et tout être humain ) a tendance à consommer tout le temps aloué à la réalisation d’une tâche, même si celui-ci est surévalué.
• supprimer l’effet tunnel. Dans un cycle de développement classique, après la phase de spécification, le projet rentre dans ‘la boîte noire’, ou le client est totalement aveugle. Puis, il ressort plusieurs mois après, quand les développements sont finis, et devient enfin visible pour celui-ci. Difficile d’identifier les dérapage ou bien même de se rendre compte des erreurs contenues dans les spécifications.
• recalculer la productivité. Après chaque itération on peut en effet recalculer la vélocité de l’équipe et ainsi remettre à jour le planning et prévoir en conséquence, et ce, très tôt dans le projet.

Et les méthodes Agiles prennent :

D’après une étude d’août 2007 sur les méthodes agiles, effectués par le cabinet Forrester, on se rend compte que les méthodes agiles ne sont plus d’obscures pratiques utilisées en cachette par quelques geeks.

D’autant plus que d’après ce rapport, ces chiffres sont à revoir à la hausse, la question ayant été posée aux grands décideurs des entreprises, qui ne sont pas forcément au courant de l’ensemble des méthodes pratiquées par leurs chefs de projets.

Attention, aux fausses idées :

Les fausses idées sur les méthodes agiles ont encore la vie dure, les principales sont pour moi :

• Dans un projet agile, le planning n’est pas très précisément défini, c’est donc forcément un projet sans fin. C’est faux! Dans les méthodes agiles ont retrouve également une phase d’estimation initiale qui permet de fixer une durée et une enveloppe au projet. Là ou cela change, c’est qu’après on n’essaye pas de faire un plan de tout le projet. On ne réalise le planning fin que pour la prochaine itération.
  Sur ce point la j’irai même plus loin, en affirmant que les projets gérés de manière ‘classique’ peuvent même être plus risqués et sans fin. En effet, dans ce type de projet le client n’a pas forcemment conscience des dérives et lorsque l’on s’approche des dates critiques, les parties les plus importantes pour lui ne sont pas forcemment celles qui ont été développées, et donc il ne peut rien faire de ce début d’application qui a été développée. Au contraire, dans les méthodes agiles, le client, à tout instant, a la vision précise de l’avancement des développements, car après chaque itération un produit fonctionnant lui est livré. A la fin du temps imparti initialement, il est sure que les parties développées correspondent aux fonctionnalités les plus importantes.
• Cela ne marche pour des contrats au forfait. Si! Mais il faut prévoir dans ce cas la, un contrat différent de ce que l’on fait actuellement. Et même, si le client ne souhaite pas s’impliquer, on peut utiliser quand même certains concepts agiles en interne, en désignant dans l’équipe une personne représentant le client et en réutilisant le concept d’itération.
• Les méthodes agiles ne fonctionnent que pour certains types de projets bien précis. Faux. Les méthodes agiles ont été testées sur tout types de projets, et l’on a remarqué qu’elles étaient les plus efficaces sur les projets critiques, les projets risqués avec des spécifications mal définies initialement.

Voila, je m’arrête là pour le moment. J’ai essayé ici de vulgariser les concepts agiles que je trouve extrêmement intéressant (désolé pour les approximations ou les raccourcis). Je ne me suis pas trop arrété sur les concepts de qualité que mettent en avant les méthodes agiles, en effet, même si l’on doit à celles-ci un regain d’intérêt pour les tests et l’apparition de méthodes tels le TDD (Test Driven Development), je pense que ces méthodes ne sont pas incompatibles avec la gestion de projets classiques et que ce n’est pas la un point de divergence fort.

Dans un second temps je vous présenterai la méthode Scrum et je ferais un petit résumé du livre de Véronique Messager Rota que je viens de finir et qui est extrèmement intéressant.

Une présentation sympa en est faites ICI.