2007, Scrum méthode populaire - Scrum, Agilité & rock'n roll

J’ai animé une formation la semaine dernière chez Areva à Montpellier, pour 10 personnes. Il s’agit de ma formation Méthodes Agiles, la mise en œuvre, en trois jours. C’est un cours dont plus de 50% du temps est consacré à des exercices et travaux pratiques.

Sur France Inter ce matin, on parle de Toyota qui est devenu le numéro 1 mondial de l’automobile. Les interviews associées mettent en avant la préoccupation constante des besoins des automobilistes et la qualité des produits, obtenue grâce à un système de production original. Cette gestion d’entreprise est appelée Lean. Le Lean est décliné depuis quelques années sur l’industrie du logiciel, en particulier par Mary Poppendieck. Les principes de la pensée Lean sont tout à fait dans l’esprit des méthodes agiles avec une emphase particulière qui est mise sur l’élimination du gaspillage. Le gaspillage[1] est défini comme tout ce qui ne crée pas de valeur pour le client. L’objectif d’une approche agile est de favoriser la simplicité, qui est l’art de maximiser le travail non fait. Dans le développement de logiciel, il existe de nombreux gaspillages qui peuvent être éliminés. J’ai fait en mars un audit chez un éditeur de logiciel où, compte tenu des objectifs à court terme, l’élimination de gaspillages était la possibilité la plus évidente d’améliorer la productivité, la plus facile à mettre en œuvre.

Le “Cercle Génie Logiciel Toulousain” a pour vocation de constituer un lieu de rencontre, au travers de présentations et débats, pour les différents acteurs du monde du Génie Logiciel en région Toulousaine. Ce matin, j’y ai fait une présentation des Méthodes Agiles. Je pense que cela en a surpris quelques-uns… Ma présentation est en ligne. Deux commentaires : j’ai enfin pu placer la méthode à Gilles, c’est le prénom de l’ancien président du Cercle j’ai appris qu’on dit goulet d’étranglement plutôt que goulot

Je viens de finir un article sur comment vendre les méthodes agiles. La date limite c’était fin avril. Je le savais depuis longtemps, presque 2 mois. Ce travail m’a demandé quelques heures et j’aurais pu trouver ce temps pour finir cet article bien plus tôt. Mais j’ai tendance à travailler dans l’urgence et à m’y mettre vraiment au dernier moment. Cette façon de faire est connue en psychologie sous le nom syndrome de l’étudiant. Je connais pas mal de personnes qui ne sont plus étudiantes depuis longtemps et qui font comme ça. C’est humain : quand on a du temps devant soi, on repousse une tâche difficile jusqu’à se sentir obligé de la faire car il ne reste plus de mou dans le planning.

Mercredi dernier, au XP Day (qui en fait dure deux jours), j’ai présenté avec Total la première session lors de l’après-midi consacrée aux retours d’expérience. Elle portait sur la mise en œuvre de la méthode Agile chez Total Gas Elec.

L’atelier Mon processus s’étrangle était animé par Pascal van Cauwenberghe. Ca commence par une simulation avec 7 volontaires qui vont construire des bateaux et des chapeaux en papier. Chacun joue une rôle particulier : client, analyste, concepteur, plieur, testeur… L’objectif est d’identifier le goulet d’étranglement du processus. La présentation est basée sur la théorie des contraintes. Le goulet a été facile à identifier et nous avons essayé les techniques pour exploiter la contrainte.

L’après-midi du 2 mai du XP Day était consacrée aux retours d’expérience avec 6 sessions. Le public était nombreux, une cinquantaine de personnes en moyenne, alors qu’il y avait 2 autres présentations en parallèle. Beaucoup de questions pendant et à la fin des présentations sur la mise en œuvre concrète des pratiques agiles. Pour ma part, j’ai particulièrement apprécié les présentations de Business Services Orange et de la banque Wallonne, notamment pour leur éclairage sur les tests.

Je n’ai pas réussi à trouver une traduction correcte de burndown en français. J’ai envie de lancer un néologisme avec le beurdone.

Dans sa mission de vulgarisation de l’agilité, Scott Ambler revient dans Dr. Dobb’s sur les conséquences néfastes de faire des projets à coût fixé à l’avance, ce qu’on appelle généralement en France les contrats au forfait. Tout le monde, me semble t-il, est à peu près conscient des graves inconvénients des contrats au forfait. Il est temps, comme le conclut Scott, de repenser la façon de financer les projets. Mais il faut pour cela aller un peu plus loin que simplement proposer des projets à coût variable…

Ma dernière formation était pour une équipe qui va démarrer l’utilisation des méthodes agiles sur un projet de refonte d’un site grand public. L’équipe inclut des Web designers. Lors de la formation, nous avons constitué le backlog initial. L’équipe s’est posé des questions relatives à la prise en compte des aspects IHM comme définir la charte graphique, définir la carte du site et la navigation dans les pages, définir les blocs et la mise en page…

Quand j’ai lu le livre de Mike Cohn, Agile Estimating and Planning, fin 2005, j’ai trouvé géniale son approche d’estimation par les points. Plutôt que d’estimer en jours, on associe à chaque user story un nombre de points. Sans unité. Depuis j’utilise et je fais utiliser cette technique sur tous les projets dans lesquels je suis impliqué[1]. Cette façon d’estimer présente de multiples avantages qui sont rappelés dans 2 billets récents :

Un des gaspillages les plus spectaculaires dans le développement de logiciel est l’écriture de spécifications détaillées suivie de la rédaction d’un cahier de recette, plus ou moins à partir de ces spécifications. Plutôt moins parce qu’en général le cahier de recette est écrit à la fin, à un moment où les specs, écrites au début, ne sont plus à jour depuis longtemps.

Aujourd’hui pas de billet sur l’agilité, j’ai installé et essayé la dernière version d’Ubuntu. C’est ma première véritable expérience Linux. A première vue, c’est vraiment très bien. Installation impeccable, wifi reconnu instantanément. Un peu de mal à la fin avec le réseau, obligé de faire du sudo avec samba mais j’y suis arrivé.

Je présentais déjà les méthodes agiles aux étudiants de l’IUP ISI. A la rentrée, une UE du Master M1 sera entièrement dédiée aux méthodes agiles. L’ingénierie du logiciel sera présentée en 2 parties distinctes : une “classique” et une agile. J’en prépare le programme détaillé. Cela représente 50 heures étudiant.

Wilos, qui a été développé en appliquant Scrum à 33 et qui continue en développement communautaire, utilise le framework IceFaces. Cela a donné lieu à une success story publiée par IceSoft. Que fait Wilos ? Quelques explications d’Emilien.

Mise à jour octobre 2009 : une version plus récente de cette intro à Scrum est disponible. Une autre présentation, sur les bénéfices de l’agilité, toujours en Creative Commons, pourra aussi vous intéresser. J’ai reçu vendredi un message de Mike Cohn, un des gourous de Scrum et de l’agilité, fondateur de MountainGoatSoftware :

Hier soir, je suis allé au cinéma voir Les LIP, l’imagination au pouvoir qui revient sur cette expérience d’autogestion des années 70.

Signez le pacte numérique. Défendez le logiciel libre en adhérant à l’April comme le demande Richard Stallman. Passez aux méthodes Agiles.

Scrum se veut un moyen de canaliser les rapports humains dans le cadre du travail en équipe.

Esther Derby publie dans la tribune hebdomadaire de la Scrum Alliance un article Performance without Appraisal, où elle pourfend l’évaluation individuelle au mérite.

J’étais ce matin à un séminaire organisé par l’ITSMF sur ITIL et ISO 20000. Vous allez me dire, quel rapport avec l’agilité, qui est le sujet de ce blog ? On y a bien parlé et abondamment de la roue de Deming, qu’on cite aussi dans les méthodes agiles et dont j’ai parlé dans un billet précédent. On y a bien mis en avant la nécessité de prendre en compte les besoins des clients pour la définition des services, et c’est aussi un des objectifs des méthodes agiles que de se rapprocher des clients. Mais sinon pas de rapport direct, on ne va pas dire qu’ITIL est agile, bien que ça rime.

Je viens de recevoir un message de Scrum Alliance qui me félicite de ma récente certification CSM et qui me fournit un login et un mot de passe pour accéder à des ressources réservées aux membres. C’est sympa, mais pour la gestion c’est pas tip-top la Scrum Alliance : dans le message on me dit donc que je suis nouveau membre et que c’est valable un an quand je me logue avec le mot de passe envoyé je vois sur mon profil que je suis (j’étais) membre jusqu’au 6 avril 2007 en fait j’ai suivi la formation en novembre 2005 et donc j’aurais dû être félicité à ce moment là et mon statut de membre aurait dû prendre fin un an après. De toute façon je n’ai pas l’intention de renouveler[1], mais je lis avec intérêt les articles[2] qui sont d’ailleurs ouverts à tout le monde. Les seules ressources réservées aux membres me semblent être les logos…

Cet article décrit les courbes qu’on peut produire à partir d’une estimation des stories en points. Il montre les faiblesses du burndown chart et présente des alternatives. Il introduit des notions venant du Lean, comme le diagramme de flux cumulé, le TAF et le DDD.

Le débat sur la certification continue de faire rage dans le monde (microcosme ?) Agile : Alan Shalloway revient sur les formations qui certifient ou pas, après s’être fait virer lui aussi de la liste de discussion Scrum. Scott Ambler, qui a été banni un peu plus tôt, se déclare en faveur de la certification dans son dernier article sur Dr. Dobb’s, tout en éreintant une nouvelle fois la certification CSM. Je reste très sceptique sur l’intérêt d’une certification Agile pour la France. J’ai un ami qui suit actuellement un programme de certification ITIL. La présentation des niveaux de certification est intéressante et semble pertinente. Par contre, le processus conduit à une lourdeur dans les apprentissages et pousse à du bachotage de la part des candidats. Cela me semble incompatible avec l’approche Agile, où il n’y a pas qu’une seule voix -et c’est une bonne chose- et où l’on privilégie la communication plutôt que la documentation, inévitable dans les processus de certification.

Des spécifications exécutables écrites par le métier ! Hier soir, j’ai fait une web conférence avec François Beauregard, qui m’a présenté GreenPepper. L’idée est assez géniale : permettre aux spécialistes du métier d’écrire les tests associés aux histoires d’utilisateur dans un langage simple et faire en sorte que ces tests soient exécutables. Tout cela dans un environnement collaboratif basé sur un wiki[1] et pouvant être intégré à Jira et Eclipse. Les tests d’acceptation sont décrits avec des exemples, de façon analogue à ce que j’ai présenté dans ce billet. Le langage de GreenPepper est basé sur 3 constructions : do with pour la séquence d’actions, list of pour les ensembles et rule pour définir des règles entre les données en entrée et les données en sortie.

L’empire contre-attaque sur la certification Sévèrement critiquée ces derniers temps sur la certification ScrumMaster, la Scrum Alliance lance la contre-attaque. A l’initiative d’un groupe dont le porte-parole est Pete Behrens, elle propose une version préliminaire d’une nouvelle certification : le programme Certified Scrum Coach. C’est du sérieux qui s’inspire des programmes de certification classiques. Le problème c’est que tout est en anglais. J’ai demandé si des certifications locales étaient envisagées, voici la réponse :

Forcément on en parle dans la blogosphère agile… Microsoft vient de lancer eScrum. Je ne vais pas l’essayer, il faut déjà avoir tout un tas d’outils [1]que je n’ai pas. En plus l’installation n’a pas l’air facile, d’après ce billet. Est-ce Microsoft utilise Scrum et les méthodes Agiles pour ses développements ? Des éléments de réponse là et là. Notes [1] payants, du genre Visual Studio Team System

Après les succès du SigmaT1 du 8 décembre et du SigmaT2 du 16 mars, le troisième Sigmat aura lieu le 21 septembre[1]. L’objectif est toujours de partager des expériences sur les méthodes Agiles. Pour l’animation, je serai assisté, comme la dernière fois, par Thierry Cros et Olivier Azeau[2]. Lors du dernier SigmaT, nous avions ébauché un backlog des sujets pour les séminaires suivants. Vous êtes invités à compléter ce backlog et à nous aider à définir les priorités, en fonction de ce qui vous intéresse particulièrement.

Bien souvent, la revue de planification de sprint dure longtemps, trop longtemps, suite à des discussions parce que l’équipe a du mal à voir le périmètre des histoires d’utilisateur proposées par le Product Owner. Pour éviter de dépasser la durée normale de cette réunion, il arrive que l’équipe accepte d’inclure une histoire dans le sprint courant alors qu’elle ne sait pas bien la décomposer en tâches. Cela risque de provoquer des problèmes dans le déroulement du sprint. Pour éviter cette dérive, je propose d’ajouter une revue, un peu avant la fin du sprint précédent.

Les états significatifs d'un élément de backlog

J’ai déjà évoqué plusieurs fois le cycle de vie d’un élément du backlog. Par exemple, dans ce billet : la vie d’une histoire avant le sprint et dans celui-ci : la vie d’un item dans IceScrum. Je viens de refaire, avec StarUML, le diagramme montrant ces états. C’est lors de la revue de backlog que s’effectuent les transitions de Identifié vers Estimé et d’Estimé vers Prêt. Un élément devient En cours lorsqu’il est inclus dans le sprint courant.

Je reviens de chez le médecin que je suis allé consulter pour un tennis-elbow.

J’avais annoncé que les méthodes Agiles seraient enseignées plus largement à l’IUP ISI à partir de la prochaine rentrée. L’enseignement du génie logiciel en Master1 a été séparé en 2 parties : d’un côté le développement traditionnel, de l’autre le développement itératif et agile, qui fait donc l’objet d’une UE (Unité d’Enseignement) spécifique. Au programme :

Scrum donne un cadre au déroulement d’une itération (un sprint) avec les 4 rites de base :

On se demande ce qui est cumulé… Je viens de lire un billet (en fait une simple traduction de l’annonce) du JDNet sur l’outil Microsoft dont j’ai parlé il y a quelque temps. Je cite : L’eScrum est une nouvelle solution pour exploiter la méthode de gestion de projet de développement Scrum …Il intègre les objets Scrum comme le retard cumulé de produit, le management de tache, la rétrospective et les rapports avec l’aide sensible au contexte intégrée.

La valeur d’un élément du backlog, c’est ce qu’elle rapporte à l’organisation. La valeur est un des facteurs utilisés pour déterminer la priorité du backlog. C’est la responsabilité du directeur de produit de définir la valeur d’un élément, fonctionnalité ou histoire d’utilisateur. Il peut se trouver face à des difficultés pour évaluer la valeur financière (en €), en particulier s’il ne s’agit pas d’un produit commercial.

Dans moins de 2 mois, la Coupe du Monde de rugby aura commencé. A J-49, on commence à en parler. On voit les préparatifs de l’événement[1]. Le rugby va être au premier plan de l’actualité. C’est l’occasion de rappeler que la méthode agile Scrum est apparentée avec.

DSDM (Dynamic Systems Development Method) est une méthode Agile d’origine anglaise qui met l’accent sur les relations entre le métier (business) et le développement.

Les 2 premières sont simples, il s’agit de dire ce qu’on a fait et ce qu’on va faire. La troisième question c’est un peu plus délicat. Officiellement et en anglais[1], c’est : What impedes you from performing your work as effectively as possible? En français, cela donne :

Pas de bottleneck au concert de Robert Plant (ex Led Zeppelin)

Bottleneck, en anglais c’est un goulet d’étranglement mais c’est aussi une technique de guitare, d’ailleurs utilisée par Jimmy Page J’étais hier au concert de Robert Plant and the Strange Sensations au festival de Carcassonne. La dernière fois que j’ai vu Robert Plant sur scène c’était le 27 mars 1973. Il était alors le chanteur de Led Zeppelin et c’était au Parc des Expositions de Nancy lors de la fameuse tournée européenne du printemps 73. Le concert de Nancy avait provoqué l’annulation des suivants en France, la moitié des spectateurs[1] sont rentrés sans payer et l’organisateur est parti avec la caisse.

Un article qui est le regroupement de plusieurs billets courts publiés en juillet 2007.

Dans un billet récent, je reprenais les arguments d’Esther Derby contre l’évaluation individuelle, contreproductive pour l’équipe. David Anderson trouve même que c’est mal.

Si un système d’exploitation multitâche peut rendre des services appréciables en restant efficace, il n’en est pas de même pour une personne multitâche. Le changement de contexte est plus difficile pour un homme que pour une machine[1].

Gerald Weinberg définit les conditions qui devraient être satisfaites pour qu’un consultant s’engage dans un contrat. Ce sont 7 exigences dont devraient s’inspirer les coachs agiles : Je ne travaillerai pas pour une organisation dont les buts ne sont pas en accord avec mes propres idées Je ne travaillerai pas sur des projets qui ont des objectifs que je ne comprends pas ou avec lesquels je ne suis pas d’accord

OpenUP est le processus libre publié par la fondation Eclipse dans le cadre du projet EPF. La version 1.0 d’OpenUp vient de sortir. Cette nouvelle version montre un alignement important avec Scrum[1], au delà du vocabulaire.

Dans mes derniers billets, je m’aperçois que j’ai tendance à mettre une majuscule chaque fois que je parle de quelque chose Agile. Le quelque chose, ça peut être méthode, processus, approche, développement de logiciel, tout ce qui peut se rapporter au mouvement Agile. Dans sa définition, Wikipedia parle de méthode agile, sans majuscule. Dans l’abondante prose disponible en anglais, on trouve Agile et agile[1], à peu près autant de chaque.

Par un billet de Agile Executive Blog, je découvre un article qui montre une expérience[1] exceptionnelle sur le passage d’un processus en cascade[2] à un processus agile. Généralement, pour la transition à un nouveau processus, on conseille de commencer par un projet pilote de quelques mois, de faire le bilan et de continuer progressivement. Ici c’est toute la R&D de Salesforce[3] qui est passée à l’Agilité en 3 mois ! Le big bang agile.

Une devise du rugby c’est no scrum no win. Pour les non initiés, cela signifie que sans une bonne mêlée, une équipe ne peut pas gagner un match.

J’ai passé la plus grande partie de ma vie de développeur et de consultant dans le domaine de l’informatique dite technique : le logiciel embarqué, l’informatique industrielle, les logiciels temps réel, les sous-systèmes intégrés, etc. J’ai écrit plein de code (dont une bonne partie en assembleur) pour du logiciel embarqué dans des téléphones, dans des avions et dans des caisses enregistreuses. J’ai réalisé des tas de modèles avec SADT, SA/RT, SDL et UML pour des systèmes et des logiciels intégrés dans ces systèmes. J’ai défini et adapté des processus pour développer ces logiciels et ces systèmes. Cela me donne une connaissance pratique de ce qu’on appelle l’ingénierie système. Sans passer pour un zélateur exclusif de l’Agilité, je suis convaincu que bien des aspects des méthodes agiles sont applicables dans ce domaine. Evidemment, et comme toujours, en les adaptant au contexte (notamment les tests) et à l’organisation (les sous-systèmes) pour pouvoir produire régulièrement des versions fonctionnelles.

Ma rentrée à la fac [1] commence par les soutenances de stage, qui ont lieu la semaine prochaine. J’ai suivi 8 stagiaires, ce qui fait 8 rapports de stage à lire. J’ai fait des recommandations à chacun pour qu’ils rédigent de façon itérative leur rapport et qu’ils m’envoient des versions intermédiaires.