Scrum - Méthodes agiles

Mi avril, je m'étais mis d'accord avec un charpentier pour la construction d'un appentis. Il s'était engagé à faire les travaux en mai. Je l'appelle hier, il me dit : vous comprenez, avec tous ces ponts, on a pris du retard, je ne pourrai venir chez vous qu'en juin. Ce que je comprends surtout c'est que le 17 avril, il n'avait pas pensé qu'il y aurait des ponts en mai pour ses prévisions de travaux. Après tout, les artisans ne sont pas formés à la gestion de projet.

Il arrive aussi que des étudiants, sensibilisés eux à la gestion de projet, utilisent ce genre d'argument -faire passer une situation prévisible pour une vicissitude imprévue- pour tenter de justifier un manque de résultat. Par exemple, à la fin d'un sprint j'ai quelquefois entendu qu'à cause du projet temps réel l'équipe n'avait pas pu consacrer autant de temps qu'elle aurait souhaité sur mon projet. Je ne suis pas dupe, le responsable du projet temps réel a dû entendre la même chose.

Agile ou pas, la planification agile doit tenir compte des événements connus à l'avance, comme les ponts en mai. Pour Scrum cela peut influencer la durée du sprint. Par exemple, une équipe de 5 personnes qui fait habituellement des sprints de 3 semaines dispose de 5 fois 5 fois 3 soit 75 jours de ressources. Elle commence un nouveau sprint le 28 avril et les membres de l'équipe font les ponts de mai. Pour avoir en gros les mêmes ressources que pour les autres sprints^[1], il est logique de passer la durée de ce sprint à 4 semaines. Cela devrait être anticipé dans le planning de la release.

Par mes amis canadiens de la Communauté agile de Québec, je viens de consulter la présentation de Grigori Melnik, de Microsoft. Sa présentation s'appelle Empirical Evidence of Agile Methods. Elle est bizarrement sous-titrée ce que nous savons, ce que nous pensons savoir et ce que nous voulons savoir, car ce sont les seuls mots en français.

Pour ceux qui cherchent à avoir des chiffres qui prouvent que les méthodes agiles sont largement diffusées et qu'elles apportent des résultats, sa présentation est une mine d'informations. Il a compilé les différentes études disponibles sur le sujet.

A noter qu'il repose encore la lancinante question : Have Agile Methods Crossed the Chasm Yet? alors que je pensais que c'était fait il y a 2 ans et confirmé l'année dernière.

Done done

Lire la suite -->

Emmanuel Chenu a publié des illustrations sur les principales pratiques de Scrum et de l'Agilité. Les dessins sont en anglais et les commentaires qui les accompagnent sont en français.
C'est sympa, mais pourquoi sont-ils tous chauves ? Dans un genre différent, j'utilise maintenant les icônes de IceScrum pour illustrer les rôles Scrum dans mes formations et mes présentations :

Vous avez reconnu les différents rôles ?

Courant mai, je visite des étudiants de l'IUP ISI en stage dans les entreprises toulousaines. Pour l'instant, j'ai vu 3 étudiants. Tous travaillent sur des projets innovants et utilisent des technologies de pointe. Côté méthode, 100% des projets utilisent Scrum. Les étudiants sont parfois amenés à expliquer Scrum à des collègues.
Dans une entreprise, j'ai vu un beau tableau des tâches (horizontal) avec des notes collantes au mur de la salle de réunion. Dans l'autre, c'est IceScrum qui est utilisé intensivement. Des initiatives venant des étudiants en stage et acceptées et même encouragées par les entreprises.

Toujours dans un contexte universitaire mais presque dans un autre monde, j'assistais la semaine dernière à une réunion avec des anciens étudiants. J'y ai entendu dire par un représentant d'Airbus que l'avenir des étudiants en informatique, c'était le MDA et la méta-modélisation. Pour avoir consacré énormément de temps aux modèles et méta-modèles il y a une dizaine d'années et voir leur utilisation actuelle dans les nombreuses entreprises que je visite, j'ai de sérieux doutes sur leur application en dehors d'un microcosme proche de la recherche.

Je ne veux surtout pas dire que le MDA n'est pas intéressant et qu'il faut l'opposer aux méthodes agiles. Mais simplement rappeler que c'est une niche et que la plupart des étudiants n'en feront pas une fois dans la vie active. Une recherche des emplois proposés sur lesjeudis.com donne 5 pour MDA, 5 pour Scrum et 37 pour Agile. A mon avis la tendance va s'amplifier.

Tout le monde n'est pas ScrumMaster.

Lire la suite -->

Pour apprendre Scrum, la façon la plus efficace est probablement de suivre une formation^[1] et d'appliquer aussitôt. D'autres choisiront l'apprentissage individuel avec les quelques livres et les nombreux articles disponibles sur Internet. Les livres imposent une approche séquentielle et les articles ne forment pas un tout cohérent, ce qui n'est pas l'idéal pour accéder à un processus, même simple comme Scrum.

La présentation d'un processus sous forme de site Web est une bonne solution pour pallier ces inconvénients. Le plugin Scrum que j'ai réalisé avec EPF Composer en est un exemple. Le résultat est visible ici. La structure relativement complexe est due aux choix faits dans EPF et au méta-modèle sous-jacent (Software Process Engineering Metamodel).

Dans la même veine, Mishkin Berteig annonce la sortie de Scrum Study Guide. Il le vend 500$ ! J'ai regardé la version de démo, gratuite.

J'ai tout de suite identifié l'outil avec lequel il l'a fabriqué : c'est Tiddlywiki. Il s'agit d'un wiki personnel que j'utilise quotidiennement depuis 2 ans^[2]. L'intérêt de TiddlyWiki est sa légèreté -tout est dans un seul fichier html- et la simplicité du wiki. La structure dépend des choix de l'auteur pour créer les pages wiki, ça peut vite devenir difficile de s'y retrouver.

Tiens, ça pourrait être un exercice amusant de porter ce que j'ai écrit dans le plugin Scrum EPF sur un TiddlyWiki. Et après, je le vends ?

La nouvelle version d'IceScrum est disponible au téléchargement, en war ou en bundle.

IceScrum, le projet pour un outil Scrum libre et gratuit. Le Touilleur Express en parle et l'Expresso sans sucre y apporte même ses compétences.

Avec cette nouvelle version, l'outil parle aussi en anglais. L'utilisabilité a été grandement améliorée, notamment pour la gestion des tâches d'un sprint.

Olivier avait filmé les présentations du SigmaT5 du 28 mars. Il en a fait le montage et elles sont désormais en ligne sur Dailymotion.

Bientôt le XP Day 2008 à Paris, c'est les 5 et 6 mai. J'avais présenté un retour d'expérience chez Total lors du XP Day 2007, mais cette année je ne pourrai pas y assister. Il n'y est pas question que de XP, on y parlera aussi de Scrum. J'espère qu'un de mes lecteurs me racontera.

Dans notre sud-ouest, nous envisageons d'organiser le prochain séminaire à Montpellier, en juin. Après 5 SigmaT, un SigmaM !

Je termine demain ma mission à Paris. Presque 5 mois à mi-temps, à faire du coaching pour un ScrumMaster et un Product Owner et les aider à mettre en oeuvre Scrum sur un projet. J'avais commencé par former l'équipe à Scrum et, à côté de ma participation au projet, ma mission consistait aussi à capitaliser les pratiques agiles pour les insérer dans le cadre méthodologique de l'entreprise. Intéressant mais pas facile tous les jours, en particulier avec le rôle de Product Owner, dans un milieu pas vraiment favorable à l'agilité au départ^[1]. J'y reviendrai un peu plus tard.

En attendant j'enchaîne la semaine prochaine par une formation Scrum. Heureusement, à Toulouse.

Trouvé via le blog de Karl, un article publié dans le très sérieux magazine IEEE Software qui fait l'hypothèse d'une équivalence entre les tests et les exigences. L'article Tests and Requirements, Requirements and Tests: A Möbius strip, est signé de Grigori Melnik et de Robert C. Martin, le célèbre Uncle Bob.

La référence au ruban de Möbius illustre comment les 2 disciplines (exigences et tests) en deviennent une seule lorsque le formalisme augmente.

Dans l'article, les exemples sont en FIT qui propose une représentation tabulaire des tests exigences. FIT est bien adapté aux tests sur les données ^[1].

Je suis convaincu de cette hypothèse d'équivalence. L'écriture de tests d'acceptation est une technique de spécification, d'autant plus pertinente que les tests sont associés à des histoires d'utilisateur. Je l'applique maintenant sur tous les projets auxquels je participe, mais en utilisant le formalisme BDD plutôt que FIT. J'en ai déjà parlé ici et là.