2006, agilité timide

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

Premier billet

Le début d'une longue aventure

First post.

Juste une annonce du commencement.

Enseignement agile

Professeur associé à l'université Paul Sabatier

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.

Humour agile

À l'arrache

Les agilistes ne se sont jamais pris au sérieux.

IceScrum

IceScrum

Un outil qui a démarré dans un projet d'étudiants et qui existe toujours quinze ans plus, c'est le signe d'une belle réussite

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.

User Stories

Lors des derniers projets auxquels j'ai participé ou que j'ai coachés, les exigences ont été définies par des user stories

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

Mêlée

Mêlée

Les valeurs du rugby

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é.

Estimation agile

Estimation agile

Estimation en points

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 !

Web 2.0

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.

Directeur de produit

Comme au cinéma

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 ?

L'agilité contre l'opacité

Les processus agiles dissipent les rideaux de fumée derrière lesquels une équipe a parfois tendance à se cacher

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

Gestion agile des exigences

Pour ne plus faire des docs de spécification détaillée de 300 pages qui ne sont jamais lus…

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).

Diffusion des méthodes agiles

Ça diffuse

Dans le numéro du 15 mars de SD Times, l’article sur les 5 ans du Manifeste Agile cite une enquête de Forrester : 14 % des entreprises (Amérique et Europe) utilisent les méthodes agiles, 19 % autres sont intéressées ou envisagent d’y passer. Même si c’est moins que dans mon sondage local, je trouve ça plutôt élevé. Evidemment ça dépend de l’interprétation de “agile”.

IceScrum : fin du sprint 2

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.
Sondage sur l'utilisation d'UML

Sondage sur l'utilisation d'UML

Merci aux étudiants qui ont répondu

Comme le précédent, sondage effectué à partir du forum IUP ISI auprès des M1 en stage. Merci à Psyko, chef, Bob, Akki, Neptune et Kemo pour leurs commentaires.

Durée d'une itération

Quels sont les critères à retenir pour définir la bonne durée ?

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.

XP et Scrum

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 et Spem

Scrum et Spem

Le déroulement d'un sprint

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 ?

La vie d'un item dans IceScrum

La vie d'un item dans IceScrum

Un élément de backlog a des attributs et des états

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.

Avant la première itération

De quoi dois-je disposer pour commencer ma première itération dans de bonnes conditions ?

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 ?

La pause

Mangez des tomates

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).

Planification agile en randonnée

S'adapter au changement plutôt que suivre le plan

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.

Tests agiles

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”.