2006, agilité timide - Scrum, Agilité & rock'n roll

First post. Juste une annonce du commencement.

J’ai été prof à la fac pendant 15 ans, de 1997 à 2011 ; c’était toujours à temps partiel, j’étais consultant indépendant comme activité principale.

Ma première présentation de Scrum dans une conférence. En 2006.

Ma première contribution aux communs de l’agilité, une traduction d’un présentation de Mike Cohn.

Tout a démarré quand j’étais prof à la fac. Je m’occupais des projets tutorés, je proposais plusieurs sujets chaque année pour le travail en groupes des étudiants. À la rentrée 2005, j’avais eu l’idée d’un outil Scrum.

Contrairement à une idée répandue, la notion de user story ne provient pas de Scrum, mais d’Extreme Programming (XP).

Mon intérêt pour Scrum a été amplifié par son nom, qui fait référence au rugby, un sport que j’ai pratiqué et dont je reste passionné.

C’est un graphique qui illustre ce premier article qui parle d’estimation, publié dès 2006. Il est appelé burndown chart. On voit ici qu’il descend avec des points gagnés pendant une itération. Des points ? Comme c’est mystérieux !

Un excellent article d’InternetActu sur les évolutions des logiciels que tout étudiant en informatique devrait lire (et ses enseignants aussi) : Qu’est ce que le web 2.0 : Modèles de conception et d’affaires pour la prochaine génération de logiciels. On y parle pas vraiment des méthodes agiles mais presque : voir le chapitre 4 sur la fin des versions et la partie sur l’intelligence collective.

Extreme Programming propose le rôle de Client. Dans Scrum ce rôle de “client” s’appelle Product Owner. Je l’ai traduit jusqu’à maintenant — logiquement — par propriétaire de produit. Je joue ce rôle sur des projets, je le connais bien, mais le terme propriétaire ne m’a jamais bien plu. Client ne convient pas non plus. Alors, quoi dire ?

Je supervise le déroulement de projets de Bureaux d’Etudes à l’IUP ISI depuis 9 ans. Avec 7 ou 8 projets par an, cela fait une bonne soixantaine de projets. Les premières années, le cycle en V était d’usage. Nous avons introduit progressivement, à partir de 2001, les cycles de développement itératifs, dérivés du RUP, puis Scrum

J’ai remis à jour ma formation sur l’agilité dans le cadre des relations client - équipe de développement. Cela concerne le tout ce qui doit se faire pour définir le produit que l’équipe réalise. Le quoi pas le comment, comme on disait. En anglais je dirais “Agile Requirements”. En français ça fait Gestion agile des exigences. Pas trouvé mieux. J’ai développé la partie consacrée aux User Stories et aussi celle au rôle qui fait l’interface entre les clients et les développeurs (le directeur de produit).

Le projet IceScrum avance. Nous appliquons Scrum depuis le 14 avril. Les sprints durent une semaine. Bien que l’équipe ne soit pas regroupée géographiquement, les scrum meetings sont quotidiens (certains par Skype). Hier c’était la revue de fin de deuxième sprint : démonstration des user stories réalisées et rétrospective sur la façon de “scrummer”. Nous produisons pour chaque sprint un résumé de fin de sprint qui servira au rapport de stage de Cédric.

Lorsqu’on se lance dans le développement itératif, une des premières questions à laquelle il faut répondre concerne la durée des itérations. Avec 2 questions annexes : l’équipe peut-elle repousser une fin d’itération si elle n’a pas atteint ses objectifs ? est-ce que la durée est la même pour toutes les itérations ? Il n’y a pas de réponse universelle, chaque projet est différent et doit définir sa façon de travailler.

Sur le forum Scrum, un étudiant demande des commentaires sur sa thèse qui porte sur l’association de XP et Scrum. Il appelle ça xP@Scrum. Il a manifestement beaucoup utilisé le copier-coller… Ron Jeffries s’en est vite aperçu. En fait l’intégration de XP dans un cadre Scrum se pratique déjà. Sur des projets récents j’ai utilisé ou fait utiliser les techniques suivantes d’origine XP (sans parler de ce qui est commun aux 2) : user stories, estimation en groupe (planning game), remaniement (refactoring), développement dirigé par les tests (TDD) -la plus difficile à mettre en place-, binômage (pair programming).

Scrum est un processus de développement. SPEM est un standard de l’OMG pour modéliser les processus. Peut-on représenter Scrum en utilisant SPEM ?

Voici le diagramme d’états complet du comportement d’un élément de backlog, tel qu’il sera dans IceScrum. Scrum, ça se présente de façon simple : on a un backlog de produit dans lequel on inclut tous les travaux à faire (on les appelle des items). Et on les fait sprint par sprint. Quand on développe un outil (IceScrum) qu’on veut vraiment utile tout en restant simple, ça se complique un peu.

Pendant chaque itération on refait le même type de travail, en le déclinant sur des nouvelles exigences. Mais pour pouvoir lancer la première itération, il faut faire un travail assez différent. Que faut-il pour démarrer la première itération ? Comment appeler cette période avant le cycle des itérations ? Certains parlent de l’itération 0 ou du sprint 0, d’autres d’une exploration ou d’une phase de préparation. Je préfère la notion de préparation, parce qu’il ne s’agit pas d’une itération au sens où s’entendent les suivantes : la plupart du temps, il n’y a pas de produit partiel au bout, mais seulement des documents et des plans. Le RUP qui, s’il n’est pas toujours vu comme agile, est clairement itératif propose une phase appelée Inception qui a — à peu près — le même objectif (en mettant plus l’accent sur l’architecture). En fait la question intéressante est : de quoi dois-je disposer pour commencer ma première itération dans de bonnes conditions ?

Je passe beaucoup de temps devant mon ordinateur et j’ai souvent du mal à le quitter alors que je sais pourtant que ce serait mieux de faire une pause. D’un autre côté, il est parfois difficile de rester concentré sur un travail productif avec les mails qu’on reçoit, les blogs, les news… J’essaie depuis quelques semaines la technique du podomoro, décrite dans le livre de Mike Cohn. Il s’agit de travailler intensivement pendant 25 minutes puis de faire une pause de 5 minutes. Puis de recommencer. Le podomoro a été expérimenté par des Italiens sur un projet XP (au rythme de 10 podomori par jour).

La Balaguère, comme les autres organismes proposant des randonnées, publie deux fois par an un catalogue avec, pour chaque séjour, un programme. Je viens de faire une randonnée dans les Albères choisie dans le catalogue de la Balaguère. Rando-thalasso avec accompagnateur (trice en l’occurrence avec Christelle) et en étoile (on revient chaque soir au même endroit). Le programme définissait (dans les grandes lignes) le parcours prévu pour chaque journée. Une clause précise que c’est donné à titre indicatif.

Dans le numéro de juin de Software Test & Performance : un article (et la couverture) sur l’utilisation de Scrum pour les activités de test et surtout une excellente présentation des différents tests dans un cadre agile par Dean Leffingwell “Take the Agile Path to true Balance”. Il présente bien la problématique des tests dans un développement agile. Il suggère notamment qu’une itération de “durcissement” est bien souvent nécessaire à la fin d’une release, après les itérations “normales”. C’est une évidence pour les projets débutant dans l’agilité auxquels je participe : tant qu’on n’a pas complètement automatisé, tous les tests concernant une user story ne peuvent pas être passés dans l’itération où elle est réalisée. Cela nécessite déjà un gros changement dans les habitudes pour y commencer les tests fonctionnels.

J’ai commencé à rédiger la présentation de ce qu’on va trouver dans la release 2 de IceScrum bientôt disponible (pour ceux qui préfèrent voir, Cédric a fait une vidéo de démonstration). ### Objectif de l’outil IceScrum est un outil qui assiste les équipes dans l’utilisation de Scrum

Dans un développement traditionnel, les clients renâclent quand on leur demande de définir les priorités de leurs exigences. Si on insiste ils ont tendance à dire que tout est prioritaire. En fait ils ne comprennent pas à quoi ça sert [1]. Dans une approche agile, l’utilisation des priorités devient concrète. J’ai vu de nombreux documents d’expression des besoins (EB) dans lesquels on trouve des attributs associés aux besoins exprimés. Généralement on a comme attributs priorité, stabilité, criticité avec 3 valeurs possibles pour chaque. Mon expérience est qu’on on trouve 1 (priorité max) pour 90 % des besoins. Souvent si c’est 1 pour priorité c’est aussi 1 pour stabilité et criticité. Ce qui n’aide pas beaucoup… Le client a l’impression que s’il ne définit pas son besoin comme prioritaire il ne l’aura pas à la fin du projet.

Les estimations agiles sont basées sur des fonctionnalités (user stories) et sont comptées en points (story points). Pour des raisons de ressources et de budget, il peut être nécessaire d’obtenir une estimation de ce qui reste à faire en hommes-jours. Kane Mar vient de publier un billet, pertinent comme toujours, sur “How Much does a Story Point cost?” C’est une mesure qui se rapproche de celle de la vélocité, qui est la mesure standard des plannings agiles. La vélocité se mesure par le nombre de points gagnés par itération. Le coût du point c’est le coût de l’itération divisé par la vélocité.

L’Agilitateur revient dans “que fait-on dans la dernière itération ?” sur le statut particulier de la dernière itération d’une release. Se garder pour la fin un sprint de “stabilisation” (ou durcissement) n’est effectivement pas une bonne idée. Mike Cohn me le confirme dans un récent message : I stopped using the term “stabilization sprint” and now use “release sprint.” To have a stabilization sprint implies that the software can be unstable at some point and that’s a bad idea.

Cédric me demande ce matin à quelle heure est la scrum aujourd’hui. Dans une autre équipe, on dit plutôt le scrum. J’avais essayé d’imposer la mêlée quotidienne comme traduction de daily scrum meeting, mais ça ne marche pas. Scrum sonne mieux. Le terme scrum est utilisé au Québec par les journalistes. Un exemple trouvé par Google : “Je viens d’assister à mon premier scrum. Une quinzaine de journalistes (et un blogueur) entourent François Legault….”. A noter qu’ils disent un scrum.

L’utilisation d’une méthode agile conduit à donner plus de responsabilités à l’équipe. Il faut du temps pour développer cette intelligence collective. Lors de ma formation ScrumMaster avait été évoqué le modèle de Tuckman, qui démontre la nécessité de consacrer du temps à la construction de la confiance dans une équipe. Ce modèle présente le cycle de vie d’une équipe avec 4 phases :

J’utilise le composer EPF pour documenter l’utilisation de Scrum sur un projet.

Le contrat au forfait tel qu’il est couramment pratiqué n’est pas la meilleure façon de travailler entre une MOA et une MOE. Mais s’il est imposé, il n’est pas incompatible avec des pratiques agiles, qui peuvent contribuer à son succès.

Pour estimer les items (user stories) d’un backlog, je recommande d’organiser un workshop et de combiner le “planning poker” et l’estimation par analogie.

En rangeant mes papiers, je suis tombé sur le premier article parlant de Scrum que j’ai lu. Il s’agit “Scrum Development Process” de Ken Schwaber. Il date de 1996. 10 ans !

Les indications associées à un lieu sont en minutes sur les sentiers de montagne (par exemple Lac de Vogealle 1h10). Il s’agit donc de durée, en l’occurrence d’une estimation de durée idéale. Pourquoi ne met-on pas la distance, comme sur les panneaux routiers ?

La semaine dernière j’ai fait un module (projet ?) bois. On avait ce tas de bois. Il fallait le transporter et le ranger. Il était 10 heures. L’équipe n’avait pas d’expérience dans le domaine, mais disposait d’une brouette et d’un Berlingo. Est-ce qu’on aurait terminé pour le déjeuner ?

Une équipe que j’ai formée aux méthodes agiles vient de finir une itération de 3 semaines. La vélocité estimée au début de l’itération était de 24. Résultat à la fin : seulement 6 points. Des événements imprévus ont perturbé le déroulement de l’itération, mais cela ne justifie pas un résultat 4 fois inférieur aux prévisions.

Le Manifeste Agile, que j’ai signé sous le numéro 101926216593185936, commence par : Individuals and interactions over processes and tools. Il se trouve que j’ai travaillé au cours de ces dernières semaines, sur un outil et un processus autour de Scrum : je participe au développement de l’outil IceScrum et j’ai rédigé IceScrum avec Scrum, une documentation qui pourrait être assimilée à un processus. Ne serais-je manifestement pas en violation de manifeste ?

A chaque fois qu’un logiciel est produit, il faut lui donner un nom pour l’identifier.

Mais c’est pas facile de convaincre une équipe Scrum d’utiliser un français correct. Nous aurions dû dire : Il serait judicieux que le propriétaire du produit participe à la mêlée quotidienne pour ranger les éléments du carnet de produit par priorité décroissante. Ou alors : Il faut inviter l’analyste à la réunion d’avancement afin qu’il classe les exigences dans l’ordre dans lequel il souhaite les voir réalisées par l’équipe. La francisation est un art difficile dans les nouvelles technologies, comme le montre la discussion de la page Scrum de Wikipedia.

Cédric présente son rapport de stage mardi prochain. C’est l’occasion de faire le bilan des techniques agiles utilisées sur le projet IceScrum depuis avril. Scrum de base : Sprints d’une semaine produisant à chaque fois un logiciel partiel Mêlées (daily scrum meetings) quotidiennes (ou presque) Réunion de planification des sprints Démo et rétrospective pour chaque sprint (compte-rendus sur le wiki) Utilisation intensive du backlog de produit et des backlogs de sprint

Hier soir au Stadium (victoire du Stade 20 à 3 contre Biarritz, mais match à oublier). La photo n’est pas bonne (prise avec mon téléphone), difficile de reconnaître les demis de mêlée (Michalak et Yachvili) mais cela me donne l’occasion de revenir sur l’origine de Scrum.

Je viens de commencer une nouvelle intervention pour un client qui va appliquer Scrum et notamment mettre en place des réunions quotidiennes. Toutes les personnes pressenties pour jouer le rôle de ScrumMaster sont des jeunes femmes. Comment doit-on dire ?

Mon site et ce blog étaient inaccessibles depuis hier après-midi. Ce matin un message de mon hébergeur qui me dit : La plateforme hébergeant votre service a subit un incident majeur. Nous nous sommes vus dans l’obligation de recréer votre pack avec ses paramètres par défaut sur une nouvelle plateforme. Gloups ! Argggggggggggggl, même.

Mais là c’est en couleurs… … et il y a quelques dessins supplémentaires me semble t-il. C’est sur la communication avec les clients : Flickr Photo Download: What the consultant saw Ça fait toujours un moment de détente, non ?

J’ai assisté vendredi dernier à la soutenance de stage de Frédéric alias Avangel. Il a raconté -avec brio- les difficultés et les succès rencontrés pour introduire Scrum dans un service de la CPAM. La conclusion, corroborée par son tuteur, est plutôt positive.

Je donne l’argument du rythme (sustainable pace) pour justifier cette recommandation, mais on ne peut vraiment la comprendre qu’une fois qu’on a pratiqué. L’intérêt d’avoir une durée identique pour toutes les itérations permet effectivement de donner un rythme à l’équipe et présente d’autres avantages : les revues sont plus faciles à organiser, les intervenants peuvent planifier à l’avance… C’est l’intérêt des blocs de temps (time box).

Quelques exemples… Scrum a ses origines dans le logiciel, mais peut s’utiliser en dehors de ce domaine.

Quand j’ai lu cette histoire de “pigs and chickens”, puis quand on me l’a racontée lors de la formation, je l’ai trouvée pour le moins naïve et pour tout dire très américaine. On m’avait proposé d’en faire le thème de ma présentation lors des Valtech Days. J’avais refusé trouvant cela un peu anecdotique dans l’ensemble de Scrum.

Jeudi dernier j’ai fait une présentation dans le cadre du Cercle Génie Logiciel de Toulouse. Le sujet principal était la modélisation de processus de logiciel.

Je recommence cette semaine mes interventions en “Ingénierie du logiciel” à l’IUP ISI (Université Paul Sabatier, Toulouse). Cette année plus d’insistance sur Scrum et OpenUP.

OpenUP est publié en Open Source par le projet EPF (Eclipse). La dernière mouture d’OpenUP/Basic apporte des compléments sur le positionnement. OpenUP se place dans le courant de pensée de l’Agilité. C’est même dit dans le Getting Started : …that takes an agile approach to software development.

C’est mon nouveau chat, il s’appelle Suissi. Il est très agile, celui-ci. Il grimpe aux rideaux, il pique des sprints, il adore la compagnie.