2009, premières controverses

Scrum est un processus de développement faisant partie des Méthodes Agiles qui s’inspire des valeurs collectives du rugby : scrum signifie mêlée.

En fait, Scrum n’est pas vraiment un processus ni une méthodologie -ni une méthode même si on parle de méthode Agile.

Lors d’un Scrum Gathering, Ken Schwaber, un des fondateurs, a décrit Scrum comme :

“not a process or a methodology, but a path”.

Une voie à suivre.

Depuis le lancement de mon blog en 2006, j’utilise Dotclear. La version 1 m’a rendu de bons services, mais il était temps de changer. Pour passer à Dotclear2, il m’a fallu aussi changer aussi d’hébergeur, mon ancien hébergement n’offrant pas Php5 requis pour Dotclear2.

Mon blog s’appelait, depuis 2006 et jusqu’à maintenant Scrum, Méthodes Agiles. C’est fini.

J’alimente le backlog de produit d’IceScrum pour la nouvelle release. J’y mets donc des features et des user stories, qui représentent l’aspect fonctionnel. Pour avoir un produit de qualité, je réfléchis aussi aux exigences non fonctionnelles. J’avais fait un billet “que faire avec les exigences non fonctionnelles ?” il y a quelque temps en disant qu’elles devaient aussi aller dans le backlog. Mais ça ne marche pas avec toutes.

Ce backlog en couleurs a été produit avec une vieille version de iceScrum. Un exemple récent avec un beau dessin existe sur ce site, voir PermaBio

Les équipes agiles ne produisent pas une documentation faite au début du projet, qui décrit en détail toutes les spécifications fonctionnelles. Elles collectent les fonctions essentielles (les features) et les raffinent progressivement. Il n’y a pas un gros document de spécification, l’outil de collecte s’appelle le backlog de produit.

Distinguer les pratiques d’ingénierie et de management, c’est par exemple ce que fait Denis dans son questionnaire sur le niveau d’agilité.

Vous aurez noté que dans ce blog je parle plus des pratiques de management. C’est parce que je préfère parler de ce que je pratique (!) couramment : je suis impliqué dans de nombreux projets agiles, mais je n’écris plus de code depuis déjà un certain temps.

Pour le savoir, il faut passer des tests.

A l’occasion d’évolutions dans IceScrum, j’ai remis à jour le (méta) modèle de l’élément de backlog de produit.

Le backlog de produit contient des éléments. Un élément de backlog est généralement qualifié de story.

Mais ce n’est pas si simple. A partir des idées de ce billet, j’ai modélisé la typologie qu’on retrouve dans Icescrum :

Hier j’étais en déplacement à Paris pour une réunion de préparation à l’introduction de l’agilité dans une organisation offshore. J’en ai profité pour assister à la présentation sur le Lean chez Zenika, c’était en soirée. La présentation était assurée par Pascal van Cauwenberghe. J’avais participé à un de ses ateliers au XP Day 2007. Cette fois-ci, c’était sur The Toyota Way.

C’est d’ailleurs une des demandes du test Nokia, une équipe doit connaître sa vélocité pour être considérée comme appliquant vraiment Scrum.

Après le TDD, voici l’ATDD.

29 nouveaux diplômés en développement agile !

Jeff Patton n’écrit pas souvent. Mais quand il le fait, c’est long et ça donne à réfléchir. J’avais parlé à l’époque de son article Je ne sais pas ce que je veux mais je sais comment l’obtenir. On y retrouvait la Joconde illustrant les notions d’incrément et d’itération.

La diffusion de Scrum a connu une croissance très forte ces dernières années. Fatalement ce mouvement amène son lot de personnes mal formées, d’opportunistes qui vendent des compétences au rabais… puis de projets en difficulté. Rien d’étonnant : la transition à Scrum (et à l’agilité en général) demande beaucoup d’efforts et du savoir-faire pour conduire le changement culturel.