Les équipes agiles sont plus efficaces avec des généralistes ou des spécialistes qui se généralisent
Thierry Crouzet vient d’écrire un billet sur Généralistes contre spécialistes. Il défend avec brio l’idée que les généralistes sont plus utiles que les spécialistes dans les périodes de changement.
Dans un commentaire récent, Rémy me dit à propos du relevé des heures sur les tâches :
Cela est utile pour le burdown chart (cf. greenhopper par exemple, <www.greenpeppersoftware.c>… ) et nécessaire dans la gestion de projets pour pouvoir imputer dans les outils de gestion d’entreprise.
Il dit plus loin :
cela est aussi utile pour identifier rapidement des problèmes (estimation erronée et/ou le développeur ne s’en sort pas) et donc de trouver des solutions au plus vite.
Une mesure simple pour montrer le budget consommé par rapport à l'avancement
Je trouve que c’est mal de mesurer en heures le temps passé sur chaque tâche du sprint, mais c’est bien de savoir combien de jours ont été passés par l’équipe sur un sprint. C’est bien plus facile à collecter et cela permet de répondre à des questions comme :
combien avons-nous consommé sur notre budget ? combien allons nous consommer compte tenu de l’avancement ? Prenons un exemple simple
Dans Scrum en 100 mots, apparaît une notion essentielle de Scrum : le résultat (d’un sprint) est inspecté et, en fonction de son évaluation, il est décidé d’arrêter ou de continuer le développement.
J’étais vendredi au SigmaM6 à Montpellier. Nous avons eu des retours d’expérience dans des domaines très différents. Les histoires différent pas seulement parce qu’Areva s’est basé sur Scrum et Igeoss sur XP, mais surtout parce que les contextes ne sont pas les mêmes.
La pratique Scrum d'une équipe autonome et responsabilisée rend caducs les aller-retours entre le chef de projet, les membres de l'équipe et le management
Bien avant de passer à Scrum, je faisais du processus itératif. J’ai encadré de nombreux projets qui appliquaient un processus itératif, genre RUP. Comme dans Scrum, il y avait une planification à 2 niveaux : plan grosses mailles pour le projet et plan détaillé pour l’itération. Le concept est le même, mais la façon de préparer le plan diffère, essentiellement sur 2 aspects :
le timing la responsabilité
Je reviens de 3 jours passés à Marseille chez ViaXoft. C’est une startup dans le domaine du tourisme. L’équipe a démarré avec Scrum il y a quelques mois en auto-apprentissage. Elle m’a demandé d’intervenir, après 5 sprints de 2 semaines, pour auditer les pratiques appliquées et recadrer l’utilisation qui en est faite.
C'est dimanche (pluvieux), on travaille pas, on se distrait
Dans Reste à brûler, Eric revient sur la francisation en informatique et évoque mes efforts de traduction des termes agiles.
C’est vrai que je me suis amusé, l’année dernière, à inventer un néologisme. J’ai la volonté d’essayer d’utiliser le français quand l’anglais n’est pas évident à comprendre. Je suis comme Etienne qui, dans le commentaire du billet d’Eric, pense que la recherche de la traduction est un très bon exercice. Mais comme je me suis heurté à la difficulté de traduire burndown chart, j’ai suggéré beurdone.
Un plan de release permet d’avoir la connaissance actualisée de ce qui va être fourni au long des sprints de la release. C’est une projection du backlog sur les sprints qui constituent la release.
Pour un développeur est-il plus facile d'estimer qu'il reste 6h sur une tâche que de dire qu'elle est en cours et qu'elle sera finie demain ?
La pratique usuelle de suivi des tâches dans un sprint consiste à mettre à jour quotidiennement le reste à faire et à produire un burndown chart de sprint. Une autre pratique répandue est de suivre l’avancement avec un tableau des tâches avec 3 colonnes (ou 3 lignes).
La première pratique se préoccupe de la valeur estimée en heures du temps restant pour finir la tâche. La seconde est basée sur les états de la tâches. Une tâche du sprint est dans un de ces 3 états :
Depuis le début de l’année, j’ai participé à la mise en œuvre de Scrum sur 8 projets différents. Les pratiques mises en place sont à chaque fois différentes. Même s’il y a un socle commun, le choix dépend toujours du contexte du projet.
Tout le monde n’est pas d’accord avec cette façon de voir les choses : certains considèrent Scrum comme un dogme intouchable. C’est apparemment le cas de Laurent Carbonnaux qui fustige les dérives dans l’application de Scrum. Il semble me considérer comme hérétique[1] pour avoir osé remettre en question l’utilité du burndown chart de sprint au profit du suivi par états.
Dans mon billet d’hier, je trouvais abusif la référence à une culture française spécifique à propos du suivi de projet.
Coïncidence, je viens de trouver l’usage de la même expression franco-française sous la plume de Louis Naugès, mais cette fois je suis bien d’accord avec son emploi.
Il y a plus d’un an, je constatais qu’une organisation de type MOA MOE provoquait souvent une division du travail à l’opposé des recommandations des méthodes agiles. L’Agilitateur avait apporté, avec brio comme d’habitude, des compléments sur l’origine de cette pratique, qui est répandue dans nos administrations et nos grandes entreprises.
Les méthodes agiles encouragent le courage en donnant des facilités pour l'exprimer
Nous sommes 4 à préparer le prochain séminaire SigmaT qui se déroulera dans le cadre de l’Agile Tour le 16 octobre. En plus de Thierry et Olivier, il y a maintenant Jean-Marie. C’est lui qui s’occupe de confectionner l’affiche qui va nous permettre d’annoncer cette demi-journée. En fait il est parti de l’affiche de Grenoble. Dans la partie droite, il y a une liste de méthodes agiles.
Plutôt que de lister des méthodes confidentielles comme DSDM, Crystal, ASD, nous avons décidé de mettre des mots clés. Jean-Marie est parti sur 3 valeurs de XP : simplicité, rétroaction(feedback) et courage. Personnellement j’y aurais plus vu des pratiques que des valeurs et je tique un peu quand je vois écrit courage sur une affiche pour attirer le chaland à une conférence sur l’agilité.
Il y a déjà quelques semaines, j’avais écrit un petit tutorial d’initiation à IceScrum2, en décrivant le sprint 0, c’est à dire la façon de démarrer un projet, jusqu’au lancement du premier sprint.
Depuis la release R2#5 est sortie et je vais l’utiliser pour montrer le déroulement du sprint1. Je reprends donc là où je m’étais arrêté :
une release est créée, les stories du backlog ont été associées aux sprints par une planification automatique, le sprint 1 est activé.
Ils z’écrivent pas de specs
C’est la faute à Kent Beck
Laissent tomber les outils
C’est la faute à Jeffries.
Aux clients offrent une Leffe
C’est la faute au gars Jeff
Ne relèvent pas les heures
C’est la faute à Schwaber.
Dans un article trouvé sur InfoQ, Kent Beck rappelle que l’application des méthodes agiles sur des projets passe par l’utilisation d’outils :
it’s ridiculous to speak of agile software development without tools
Par rapport à un plan monolithique, les méthodes agiles sont basées sur plusieurs plans à différents niveaux, correspondant aux cycles de vie. La vie d’un produit est constituée de releases successives, chaque release est une suite d’itérations ou sprints.
La technique des “user stories” est très efficace couplée à un développement par itérations. Les stories alimentent le backlog de produit et sont développées pendant l’itération. La tendance est à avoir des stories très petites, ce qui présente des avantages en terme de gestion et de suivi. Mais cela a l’inconvénient de rendre les choses plus difficiles à comprendre. Une story est à replacer dans un contexte plus large pour qu’on voit à quoi elle sert.
L'agilité favorise l'adaptation mais n'interdit pas un peu d'anticipation
Les méthodes agiles facilitent l’adaptation au changement. Dans les présentations, on oppose souvent ce côté adaptatif de l’agilité à celui, associé aux méthodes traditionnelles basées sur un cycle en V, de faire en sorte de tout prévoir à l’avance. Le prédictif contre l’adaptatif.
Cette vision est trop simpliste. Qu’on utilise une méthode agile ou pas, on a toujours besoin de prévoir. Pour anticiper.
Pour la conférence du 16 octobre, il nous faut un communiqué de presse. En y réfléchissant, je me suis mis à la recherche d’une définition de l’agilité qui permettrait de faire comprendre l’idée à un public non averti.
En relisant la présentation de Philippe Kruchten à XP2008, je retrouve la définition de Jim Highsmith que j’ai mise dans mes supports de cours :
L’agilité est la capacité à favoriser le changement et à y répondre en vue de s’adapter au mieux à un environnement turbulent.
La rétrospective, c’est le nom une réunion servant à améliorer le processus. Elle commence par une présentation chronologique de faits passés. Revenir sur le passé pour préparer l’avenir.
Je viens de lire 2 rétrospectives sur le développement de logiciel faits par 2 illustres agilistes.
Mary Poppendieck, la gouroute du Lean, a présenté à Agile2008 Expanding Agile Horizons: The Five Dimensions of Systems Sa présentation fait une large part au passé du génie logiciel.
Le Lean est à la mode. Au delà des principes qui ne sont pas discutables, je suis sceptique sur ce que les gens en font vraiment sur le terrain. Le Lean ne constitue pas, pour le logiciel, une méthode fournissant un cadre de mise en œuvre bien définie comme l’est Scrum. Jusqu’à maintenant, le Lean m’est apparu, à travers mes lectures, comme une attitude, présentant plus de principes que de pratiques. J’essaie bien d’appliquer du Lean sur mes projets, mais cela reste ponctuel.
Pas facile de donner une valeur à la valeur ajoutée par une user story…
Dans la toute première version d’IceScrum (2005), il y avait un attribut associé aux éléments du backlog de produit, qui s’appelait valeur. Je l’avais demandé parce que c’est un précepte de Scrum et des méthodes agiles que de définir la priorité en fonction de la valeur. Plus la valeur est grande, plus la priorité est importante et la priorité définit l’ordre dans lequel les éléments du backlog sont réalisés.
Une pratique de développement répandue, avec quel impact sur l'agilité ?
Les entreprises utilisent fréquemment des progiciels ou des plateformes pour développer des applications de leur système d’information. J’ai noté qu’elles considéraient ce type de développement comme bien adapté à une approche agile. Certes un progiciel facilite la livraison de versions à un rythme rapide, mais cela ne suffit pas pour être agile.
VersionOne a publié les résultats de son enquête annuelle sur l’état du développement Agile.
Plein de chiffres sur l’usage de l’Agilité, avec les évolutions par rapport à l’enquête de l’an dernier, qui montrent une pénétration importante des pratiques (page 6).
Dans les nouveautés de l’enquête 2008, il y a :
les raisons du passage à l’Agilité : en premier accélérer le time-to-market, le taux d’échec et les raisons de ces échecs : en premier la culture de l’entreprise, les bénéfices obtenus : (presque) tout le monde est content, en particulier de l’amélioration pour gérer les changements de priorité et d’une meilleure visibilité sur le projet. Les bénéfices sont moindres pour la réduction du coût et la gestion des équipes distribuées. À noter aussi que Scrum est clairement la méthode plébiscitée : plus de la moitié des personnes interrogées disent utiliser Scrum et presque les 3/4 (71%) si on ajoute ceux qui s’appuient sur un mélange de Scrum et XP.
Le tableau devant lequel se passe la mêlée.
Après avoir entendu Rachel chez Atchick, c’est la salutation que je vais adopter pour commencer une réunion.
Ça fait plus Scrum que bonjour à tous.
Je commence ce matin.
Bonjour équipe !
L’année dernière à la même époque, je vous avais parlé de ma lecture des rapports de stage. Dans une sorte de rétrospective, j’y faisais un plan d’actions pour que les rapports de stage de 2008 soient rédigés de manière plus agile.
Les soutenances avaient lieu hier. Les étudiants ont tous bien réussi leur stage et ont été très appréciés. Mais concernant le rapport de stage, mes actions pour sa rédaction itérative et incrémentale n’ont pas été un grand succès.
Le prochain séminaire agile de Toulouse constituera une étape de l’Agile tour. Il se tiendra le 16 octobre, sur toute l’après-midi. J’y ferai une présentation avec Philippe Kruchten.
Les idées présentées iront à l’encontre de plusieurs croyances sur l’agilité :
des personnes sont persuadées que leurs pratiques agiles sont universelles et peuvent s’appliquer partout, certaines pensent être agiles parce qu’elles appliquent 2-3 pratiques qu’elles considèrent agiles, d’autres disent que l’agilité c’est sûrement très bien, mais croient que c’est totalement incompatible avec leur organisation. En fait, les retours d’expérience montrent que des pratiques agiles peuvent s’appliquer dans de très nombreux secteurs. Mais ce n’est pas la même agilité qui s’applique partout. Celle qu’on met en œuvre dans une startup du web2.0 n’est pas celle qu’on applique dans une grande administration.
Ces derniers mois, la région Rhône-Alpes paraît avoir décollé sur l’agilité.
Un club d’agilistes s’est créé. Des blogueurs y apparaissent, comme Alex. Les étapes de l’Agile tour de Valence et Grenoble affichent déjà complet.
Des retours d’expérience y sont publiés, comme celui d’Emmanuel Chenu qui raconte les pratiques mises en place pour faciliter la communication dans son équipe.
L’article qu’il publie est plutôt bluffant quand on sait que cette équipe développe des logiciels temps-réel critiques embarqués pour l’avionique(ce que j’ai fait pendant plusieurs années dans ma vie de développeur).
L'agilité favorise le changement, mais ne le rend pas gratuit ni permanent
Des utilisateurs brimés depuis longtemps pas les DSI découvrent que l’agilité peut accueillir et même favoriser les changements, ce qui les amène à penser qu’ils peuvent tout changer tout le temps.
Je conseille aux organisations de développement d’éviter le multitâches en faisant en sorte qu’une personne soit affectée dans la mesure du possible à plein temps sur un projet.
Ce n’est pas un conseil que je peux appliquer moi-même sur mes activités : je travaille sur plusieurs projets en même temps. En général j’arrive quand même à consacrer une journée ou une demi-journée à un seul sujet. Mais en ce moment particulièrement j’ai à changer de contexte très souvent pour passer d’un projet à un autre.
J’ai déjà évoqué maintes fois le problème délicat de la traduction en français des termes de l’Agilité et de Scrum en particulier : dans les billets RAB et Glossaire par exemple.
J’ai évolué sur le sujet. J’essaie de m’adapter à mon public. Il se trouve que demain je donne une formation pour un ministère et on m’a bien recommandé de ne pas utiliser de termes anglais. Glurps, je viens de jeter un oeil à mon support de cours et il est en truffé.
Attention ce n'est pas un vrai sprint, c'est l'échauffement
Avant de commencer le premier sprint, il y a une période de temps utilisée à préparer ce qui est nécessaire au lancement des sprints dans de bonnes conditions. Jusqu’à récemment, je désignais cette période sous le nom de phase, pour la distinguer de la phase des sprints. Je disais simplement phase de préparation et c’est que j’ai utilisé dans le plugin Scrum pour EPF.
Je viens de passer 6 jours consécutifs chez des clients pour les former aux méthodes agiles. 3 clients différents : un ministère, une SSII spécialisée dans les nouvelles technologies de taille petite-moyenne et une grande entreprise avec un SI conséquent.
Pour le ministère et la grande entreprise, la formation était synchronisée avec le démarrage d’un projet, ou plus précisément avec le début de l’application de la méthode agile sur le projet. Juste après la formation commençait le sprint zéro.
Comme je suis tous les jours avec des équipes et des entreprises qui font la transition aux méthodes agiles, j’ai tendance à croire que la diffusion de l’Agilité en France se poursuit régulièrement et qu’une fois qu’une entreprise a essayé, elle continue.
Deux messages reçus la semaine dernière viennent me rappeler que la réalité du terrain n’est pas un long fleuve tranquille vers un océan d’agilité.
M. avait monté début 2007 un groupe de travail pour discuter des méthodes agiles dans sa société de services. Il a essayé vaillamment de diffuser des informations sur les méthodes agiles. Il me racontait ses efforts et nous discutions de la meilleure façon de communiquer. La société a été rachetée il y a quelques mois. Depuis je n’avais plus de nouvelles. Dans son dernier message il me dit que les choses évoluent, mais dans une direction complètement opposée à l’Agilité. Il parle de méthodes très lourdes et bureaucratiques, et d’une mise en œuvre sur un mode plutôt militaire.
Le burndown chart classique ne permet pas de voir l'évolution de périmètre.
Un burndown chart de release donne une bonne indication du travail qui reste à faire. En y ajoutant la consommation du budget, on obtient des indicateurs permettant de répondre à des questions fondamentales de la gestion d’un projet : où en sommes-nous dans l’avancement du projet, combien de budget avons-nous consommé ?
Plus de 200 personnes hier pour la conférence sur l'Agilité à Toulouse !
L’amphi Concorde était plein comme un oeuf. Plus une seule place disponible, il a même fallu ajouter des chaises dans le fond.
Une première photo panoramique, merci Benjamin.
Jeudi dernier lors de la conférence Agile Tour de Toulouse, Philippe Kruchten et moi avons fait un exposé intitulé L’Agilité en situation.
Comme Philippe vit à Vancouver, nous l’avions préparé en communiquant par Skype toutes les semaines. Cela a été très enrichissant de partager nos expériences de mises en application des pratiques agiles sur différents projets et dans différents contextes.
Je fais de nombreuses présentations de Scrum. Rien que pour les séminaires SigmaT organisés à Toulouse (et à Montpellier), j’ai fait une introduction à Scrum presque à chaque fois. Cette fois pour l’Agile Tour, j’ai fait une nouvelle présentation, intitulée Scrum : des racines à la ScrumMania. Comme Scrum est maintenant beaucoup plus connu, j’ai préféré revenir sur les racines et montrer l’évolution plutôt que d’expliquer la mécanique, comme je le fais d’habitude[1].
Les risques avec Wikipedia si on ne vérifie pas ses sources
J’ai lu le dossier sur les méthodes agiles dans 01 Informatique.
Un article du dossier revient sur la genèse des méthodes agiles, en remontant loin (1957 !). Dans la litanie des citations, on trouve RAD, pourquoi pas. Mais quand Scrum est abordé, je lis : …
Les 100 premiers inscrits à la conférence Agile Tour de Toulouse ont reçu des goodies. Dans le sac estampillé Agile Tour, il y avait un jeu de cartes pour le planning poker, grâce à notre sponsor Agile Hardware.
Cela faisait longtemps que je n’avais pas parlé d’OpenUp et du projet Eclipse Process Framework. Ce projet communautaire continue à vivre et à évoluer. Je viens de me mettre à jour, à l’occasion d’une présentation d’OpenUp à mes étudiants.
J’ai donné il y a quelques jours une formation pour une grosse SSII. Il s’agissait de la formation d’une journée qui présente l’Essentiel de Scrum et des Méthodes Agiles. Le contenu est dense et la formation occupe bien la journée. J’ai donné cette formation 5 fois en un mois et, à chaque fois, quand je terminais le cours, les participants étaient pressés de rentrer chez eux ou d’aller voir leurs messages.
