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.

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.