2006, agilité timide

Ma première année de blog, qui a démarré le 4 avril.

Enseignement

Avec travaux pratiques

Les formations que j’ai faites cette année, pour mes clients industriels ou pour mes étudiants :

Amélioration du processus avec les rétrospectives

Dans Scrum (comme dans XP ou OpenUP), la rétrospective est la pratique recommandée pour améliorer le processus.

Lors des revues d’itération de vendredi, une discussion a commencé sur les fournitures relatives à la gestion de projet. Les équipes doivent-elles fournir une liste des risques, un relevé des heures passées, un bilan de l’itération ? Sous quelle forme cela doit-il être élaboré ? Ces informations doivent-elles être écrites ou présentées oralement lors de la revue ?

Histoires de points

L'estimation des histoires d'utilisateur en points (story points) est une pratique qui suscite beaucoup de discussions.

Lors du séminaire du 8 décembre, Benoit est revenu sur ses doutes -dont il m’avait déjà fait part- dans la technique d’estimation en points. A partir des relevés individuels de charges sur les tâches, il a calculé les heures passées sur les histoires. Il a constaté que des histoires estimées à 2 points ont finalement pris plus de temps à développer que des histoires à 3 points. Il a mesuré que pour 2 histoires avec le même nombre de points, il pouvait y avoir des variations du simple au double dans les heures passées. Il a calculé qu’un point ça faisait en moyenne 1,25 h/j mais que la variance était importante. Cela le pousse à mettre en doute la technique d’estimation en points.

Echos du SIGMA(T)

Feedback

Voici quelques commentaires après le séminaire de vendredi dernier. Encourageants ! Et des sujets à débattre pour une prochaine fois.

Donation

Non, ce n'est pas pour le téléthon ni pour la fondation de France, mais pour la fondation Eclipse.

Pour essayer Eclipse Project Framework Composer, j’avais pris comme exercice le “processus” Scrum, comme raconté dans ce billet et celui-ci.

Je me suis pris au jeu, j’ai complété la description de Scrum et j’ai continué en ajoutant l’utilisation d’Icescrum avec des “tool mentors”.

Le rôle de directeur de produit

Le rôle de directeur de produit

Comme au cinéma

Un résumé du rôle, appelé Product Owner dans Scrum et Customer dans XP

Le directeur de produit [1] est le représentant du “métier” dans le projet.

Scrum en une diapo

Scrum en une diapo

Simple à comprendre, difficile à faire

Je prépare une présentation pour le séminaire de vendredi. Mon idée était de présenter Scrum en une seule diapo, animée. Je me suis battu avec OpenOffice Impress. Pour l’instant, j’en suis là (sans les animations)…

Planification de release

La planification d'une release repose sur l'ajustement de 2 variables : le contenu et la durée

La planification agile permet de s’adapter à la situation courante : à tout moment on donne la priorité à ce qui apporte le plus de valeur.

Une release est une série de sprints. Mais quand arrête t-on de faire des sprints pour finir la release ? A la lecture du premier article de Scrum(1996), voilà comment on décide :

quand les variables de temps, de concurrence, d’exigences, de cout et de qualité concourent à sortir une release.

Que penser de ces variables ?

Utilisation du produit obtenu en fin d'itération

A la fin de chaque itération on livre un produit potentiellement livrable. Quel usage en fait-on ?

Qu’est ce qui fait la différence avec la fin de release où on livre vraiment le produit ?

Avec les méthodes Agiles, on cherche à obtenir un produit partiel potentiellement livrable- pour reprendre la formulation Scrum- à la fin de chaque itération. Lors de la revue de fin d’itération, l’équipe fait une démonstration de ce produit. Et après ?

Sprints, releases et produit

Sprints, releases et produit

La release, du demi-fond

Les présentations de Scrum, notamment les courtes, mettent particulièrement en évidence la notion de sprint. On comprend que la livraison du produit (complet) se fait suite une série de sprints et on pourrait croire que le backlog de produit a une vie uniquement liée à cette suite de sprints. En fait la vie du produit, et donc de son backlog, va bien au delà.

Après une série de sprints, il y en a une autre, puis encore une autre, jusqu’à la fin de vie du produit. J’ai pris l’habitude d’appeler une série de sprints une release. La release est le chainon manquant entre le produit et le sprint.

Scrum en bref

Comment expliquer à son directeur ce qu'est Scrum en 100 mots

Récemment une discussion sur le forum Scrum : comment expliquer à un DSI DG ce qu’est Scrum en 100 mots. Le point de vue est celui d’un ScrumMaster qui parle pour son équipe. Voilà ce que ça donne en français, avec mes adaptations, mais en restant dans l’esprit du texte anglais :

Agilité et maîtrise des risques

Quand une difficulté à estimer cache un risque technique.

Nous avions aujourd’hui une séance d’estimation pour le projet IceScrum2.0. Une cinquantaine d’histoires d’utilisateur déjà réalisées dans la première version client lourd Java sont à porter dans un environnement J2EE.

Séminaire sur les méthodes Agiles

Plus d'information sur le séminaire du 8 décembre

Ci-dessous le programme du séminaire sur les Méthodes Agiles à Toulouse. Vous pouvez télécharger la Plaquette de présentation du SigmaT1, un grand merci à Frédéric. Pour vous inscrire et obtenir un plan d’accès, envoyez-moi un message.

RUP vs Agile

Retours d'expérience sur ce qu'apportent les processus agiles

Je suis impliqué dans des projets étudiants depuis 8 ans. Avec en moyenne 7 projets en parallèle par an, cela fait plus de 50 projets suivis :

  • En 1999, c’était un cycle en V avec plan qualité qui était appliqué.
  • A partir de 2000, j’ai introduit le RUP puis des variantes allégées. Les étudiants pratiquent un développement itératif et incrémental.
  • A partir de 2005, je suis progressivement passé d’une approche style RUP à une approche plus agile type Scrum.

Backlog : quand examiner les priorités

Le backlog de produit est mis à jour régulièrement. Les priorités sont revues. A quel rythme ?

C’est le Directeur Produit (product owner) qui définit les priorités. Quand je joue ce rôle sur des projets, j’utilise et mets à jour les priorités de la façon suivante :

Au début du projet, une fois que le backlog contient suffisamment d’exigences :

  • je fais un première passe sur les priorités
  • une séance d’estimation a lieu avec l’équipe. Les exigences sont estimées en suivant les priorités que j’ai définies (la durée de la séance étant limitée, il est préférable de traiter en premier les exigences les plus prioritaires).
  • j’ajuste les priorités en tenant compte des estimations. Je peux, par exemple, monter dans la liste une exigence estimée peu chère.

Séminaire à Toulouse le 8 décembre

Le premier SIGMAT !

Avec Laurent Bossavit, président de XP France, nous organisons le vendredi 8 décembre entre 16 heures et 19 heures un Séminaire d’Information Gratuit sur les Méthodes Agiles. Au programme des retours d’expérience, des présentations, des débats, des démonstrations. Ce premier SIGMA Toulouse, organisé en collaboration avec l’IUP ISI, se tiendra sur le Campus de Rangueil. À noter sur vos agendas !

Chèvre de montagne

Mountain goat

Elle est agile, c’est sûr, cette chèvre qui n’existe pas dans les Alpes ni les Pyrénées, mais peuple uniquement les Rocheuses.

Ca doit être pour ça que Mike Cohn en a fait son emblème et a appelé sa société Mountain Goat Software. Comme si je m’appelais BouquetinLogiciel !

Backlog : critères pour établir les priorités

Sur quels critères baser les priorités ?

Un des points forts de Scrum est le backlog de produit, qui regroupe toutes les exigences, ce qui facilite leur gestion. Il est -techniquement- simple de définir les priorités entre les éléments du backlog. Mais sur quels critères se baser ?

Il faut d’abord bien comprendre que la priorité correspond à l’ordre de développement. Ce ne sont pas 2 notions différentes. La priorité est souvent comprise autrement -que pour définir le contenu des itérations-(voir ce billet précédent), tant qu’on n’a pas pratiqué Scrum.

La vie d'une histoire avant le sprint

La vie d'une histoire avant le sprint

Pour être sélectionnée et développée dans un sprint, un histoire d'utilisateur doit être dans un état nécessitant du travail avant le début de ce sprint

Un principe agile est qu’une histoire d’utilisateur soit développée et finie dans une itération. Une histoire possède une carte, une conversation et une confirmation. Ce qu’on met sur la carte, c’est le titre de l’histoire et cela est fait (bien) avant que l’itération ne commence. On pourrait croire qu’au début de l’itération on n’a que ça et que la conversation et la confirmation ont lieu pendant l’itération.

Il n’en est rien.

Vision agile

Pour être agile, il faut commencer par avoir une bonne vision

J’ai entendu parler pour la première fois de document Vision avec les premières versions du RUP, vers 1997. Un bonne vision, c’est quand même autrement utile que les documents d’EB (expression des besoins) ou les pseudo cahiers des charges que je lis souvent dans les entreprises.

Résumé type pour une histoire

En tant que…

Une histoire d’utilisateur est composée d’une “carte”, d’une conversation et de sa confirmation. Sur la carte (bristol, post-it, ou carte virtuelle), on écrit le “résumé de l’histoire”.

Mike Cohn, auteur de User Stories Applied, préconise l’emploi de la formulation suivante :

As a , I want so that

En français, cela donne :

Roadmap IceScrum

Roadmap IceScrum

IceScrum 2.0 ?

Le développement d’IceScrum a repris. La version courante est IceScrum3, sortie en août. Les travaux effectués pour les releases 2 et 3 sont décrits dans le rapport de stage de Cédric. Le développement était au ralenti depuis la fin de son stage, mais le site du projet est actif, avec son wiki et ses forums. Il reçoit une cinquantaine de visites par jour en moyenne. Une nouvelle équipe, composée de 5 personnes pour le moment, toujours avec Cédric, a commencé à travailler sur la release 4.

SchtroumpfMaster

Scrum un nom bizarre pour une méthode utilisée dans l'informatique ?

J’ai déjà parlé de la visite de Michel et d’autres français chez Google : voyant marqué Scrum sur une porte, un de ces visiteurs a pensé au rugby " tiens ils font des mêlées chez Google ?". En Angleterre, en Australie et en Nouvelle-Zélande grandes terres rugbystiques et pour des français aussi donc, c’est une réaction normale -quand on n’a pas entendu parler de la méthode Scrum- on pense à la mêlée du rugby.

Des histoires d'utilisateur

Les histoires d'utilisateur servent de rappel pour tenir des conversations et existent dans le but de faciliter la planification.

C’est clair ?

Je prépare une formation sur la façon de spécifier des exigences “agiles” avec des user stories. Bien sûr je me suis posé la question de comment traduire user story en français et j’ai regardé ce qu’en disaient les autres, dans la communauté XP :