2007, l'essor de Scrum

Scrum prend son envol.

Ne plus mesurer les tâches d'un sprint en heures

Une alternative aux estimations en heures

Dans un billet précédent, je notais que la ré-actualisation en heures du reste à faire pendant un sprint était difficile à obtenir des équipes. Suite à la lecture de When is Scrum not Scrum, j’ai décidé d’essayer la technique proposée pour le suivi du sprint. Je la résume ci-dessous, en mettant en évidence les différences avec la pratique Scrum standard.

La certification ScrumMaster, c'est pipeau

Du pipeau

Pour obtenir la certification Scrum actuelle, il suffit de suivre un cours de 2 jours. Cela ne garantit pas que vous êtes devenu un maître de Scrum.

Je suis ScrumMaster certifié depuis 2005. J’apparais dans la liste des 10888 CSM[1] de la ScrumAlliance. J’y suis même 2 fois, ce qui me fait douter de la précision du chiffre et de la bonne gestion de la ScrumAlliance.

Ca m’a beaucoup amusé au début, plus d’être ScrumMaster (le côté rugby) que d’être certifié il est vrai. Pour cela, il m’a suffi d’assister aux 2 jours de cours dans une cave de Gentilly. En arrivant en retard. C’était la première formation Scrum en France et à l’époque l’aspect certifiant n’était pas du tout mis en avant.

Scrum2.0 ?

Le Scrum enseigné dans les cours officiels et présenté dans les livres est un peu dépassé

Tobias Mayer, dans son billet When Scrum is not Scrum?, présente les adaptations qu’il apporte au Scrum de base et se demande s’il s’agit encore de Scrum. Si c’est intéressant, je ne trouve pas ça complètement nouveau : la plupart de ses propositions sont déjà pratiquées dans la communauté Scrum et j’ai déjà parlé de certaines dans mon blog.

De la mêlée au maul

Scrum et les autres méthodes Agiles

Scrum fournit un cadre léger qui facilite le passage à l’Agilité. Les évolutions de Scrum (voir mon précédent billet) empruntent à XP (comme le fait remarquer Ervin). Cela s’amplifie encore dès qu’on ajoute à ce cadre de nouvelles pratiques d’ingénierie (TDD, binômage…). On peut considérer que beaucoup d’utilisations sont hybrides au sens qu’elles combinent du Scrum et de l’XP.

J’étudie actuellement DSDM et j’ai lu pas mal d’articles sur Lean. J’ai aussi parcouru des présentations de FDD et Crystal.

Avantages d'une release à date fixée

La technique des blocs de temps a du bon

Pour décider de la livraison d’une release, on a en gros 2 solutions : dire que la release sera terminée quand le backlog sera vide. C’est ce qu’on appelle une release à périmètre fixé. La planification de la release permet d’estimer la date de fin. définir une date de livraison et s’y tenir absolument. C’est une release à date fixée. Avec une planification de release, on peut estimer quels éléments du backlog devraient être finis à cette date.

MOA et MOE ne sont pas Agiles

En France on a tendance à abuser des notions de MOA et MOE

De nombreuses organisations utilisent intensivement ces acronymes. Personnellement je trouve que c’est de façon abusive, surtout quand on les utilise au sein d’une seule organisation ou pour des rôles alors que, historiquement, ces notions s’adressent à des personnes morales.

Mais l’essentiel n’est pas dans le nom. L’utilisation de MOA et MOE tend à créer une séparation très nette entre 2 groupes. Cela contribue aux problèmes suivants :

Release et moi

Release et moi

Avec des réponses aux commentaires des lecteurs

Les titres auxquels vous avez échappé :

  • lettre à release
  • release tailor

Suite aux commentaires sur le billet release à date fixée, je reviens sur la notion de release.

La confusion vient de ce que j’utilise release pour désigner à la fois ce qui est produit et la période de temps nécessaire pour le produire.

Les présentations du Sigmat2

Les présentations du Sigmat2

42

Une première photo-merci à Benjamin- où on voit une partie des 42 personnes qui ont assisté au séminaire. La présentation de Thierry Cros sur le développement responsable est disponible sur son blog. La présentation d’Olivier Azeau sur les freins est disponible sur son blog Celles de Brice Jones (CPAM) et de l’équipe Wilos sont disponibles sur demande. Mes diapositives d’introduction et d’animation sont téléchargeables (Présentations).

Agile vs pas agile

Ce n'est pas évident d'organiser les processus en catégories

Dans les séminaires ou dans les réunions, quand je présente l’agilité je montre les différences -généralement les bienfaits- par rapport à une approche… pas agile.

Cela revient à séparer le monde des processus en 2 parties[1], ce qui est très schématique… De plus comment qualifier la partie non agile ?

Passer les tests d'acceptation des histoires d'utilisateur

On dit acceptation pas acceptance

C’est la responsabilité de l’équipe Agile de passer ces tests, pas question de laisser ce travail à une équipe de testeurs indépendante qui attendrait la production d’une release pour commencer.

Les histoires d’utilisateurs doivent être finies à la fin de chaque sprint et a fortiori à la fin d’une release. Une histoire d’utilisateur est considérée comme finie quand elle a passé avec succès les tests d’acceptation qui l’accompagnent.

Classification des processus

Classification des processus

Suite du billet sur les processus Agiles et pas Agiles

Classification des processus selon une enquête de Forrester.

Comme le font remarquer avec pertinence Camille et Matthieu dans leurs commentaires, il n’existe pas un processus traditionnel standard, traditionnel pris ici par opposition à Agile.

Rétrospective du Sigmat2

Que faut-il améliorer pour le Sigmat3 ?

J’ai eu 13 retours sur les 42 personnes qui ont assisté au Sigmat2 (deuxième Séminaire d’Information Gratuit sur les Méthodes Agiles de Toulouse) du 16 mars.

A noter que les personnes qui ont assisté à ce Sigmat2 n’avaient pas assisté au premier Sigmat pour la plupart, seules 20% environ ont assisté aux 2 (et 4 parmi les 13 qui m’ont fait des retours). Il serait intéressant de savoir pourquoi ceux qui ont assisté au premier ne sont pas revenus. En tout cas ceux qui ont répondu ont l’intention de revenir. Je vous livre les retours :

BMUF, Pigs and Chickens et Gripes

En vrac

BMUF

Après le BRUF, le BDUF, Scott Ambler s’attaque, dans un article du DDJ, à la grosse modélisation au début d’un projet, le BMUF.

Comme lui j’ai pratiqué la modélisation depuis très longtemps sur de nombreux projets et j’ai constaté qu’il y avait beaucoup de modèles trop détaillés faits au début et qui ne servaient à rien.

Pérégrinations

Coucou me revoilà

Je reviens d’une semaine de déplacements dans le nord[1], ce qui fait que je n’ai pas alimenté le blog pendant cette période. Je ne pensais pas rester aussi longtemps, mais pour rester agile, j’ai adapté mon emploi du temps aux besoins de mes clients et partenaires.

Anniversaire

Anniversaire

Mon blog a un an

J’ai commencé ce blog le 4 avril 2006. Ce serait le moment de faire une rétrospective ? Je vais d’abord donner quelques chiffres. Sur le blog 188 billets (celui-ci est numéroté 201, ce qui veut dire que 12 ont été supprimés, essentiellement pour spam abusif) 301 commentaires 19 rétroliens 15 fichiers à télécharger Sur les visites Les résultats dépendent du type de mesure… Les chiffres donnés par mon hébergeur

Scrum fait peur

Mieux vaut parler de méthodes agiles que de Scrum pour faire accepter l'idée de l'agilité sans effrayer la population !

J’ai fait la semaine dernière une présentation de Scrum à des personnes qui n’avaient jamais entendu parler des méthodes agiles. Ce n’est pas ce que je fais d’habitude et c’est à éviter pour des novices complets sur le sujet.

C’est qu’avec Scrum on utilise un langage particulier : sprint, scrumMaster, backlog, product owner, scrum daily meeting, etc.

User stories et use-cases

Histoires d'utilisateur et cas d'utilisation, ce n'est pas la même chose

jc de QualityStreet présente les différences entre les cas d’utilisation et les histoires d’utilisateur. Son étude présente bien ce que sont ces 2 techniques, mais sa comparaison s’inscrit dans le cadre de techniques de spécifications des exigences fonctionnelles. Or les histoires d’utilisateur ne sont pas vraiment une technique de spécification.

Les différences exposées dans son billet entre ces 2 techniques sont donc à replacer à l’aune de cette distinction.

Scrumeries diverses

Scrumeries diverses

Mes lectures pascales

Mike Vizdos a finalement publié ma traduction du cartoon Pigs and Chickens. On y apprend aussi que oeufs au lard se dit jaja na boczku en polonais, ça peut toujours servir[1]. Bon pour savoir à quoi fait référence ce cartoon, il faut lire le texte qui lui est anglais ou si on préfère le français chercher un peu dans ce blog. Mike Cohn explique les différences entre Scrum et Extreme Programming.

Emergence progressive des exigences

Plutôt que d'essayer de tout figer au début mieux vaut décider au dernier moment possible.

Il est impossible de connaître toutes les exigences[1] dès le début d’un projet. Depuis 20 ans j’ai participé à de nombreuses définitions et spécifications d’exigences dans différents domaines et il en a toujours été ainsi. En réfléchissant longtemps et en essayant d’imaginer les situations dans lesquelles se trouveront les utilisateurs, on peut bien sûr découvrir un bon nombre d’exigences significatives, mais il existera toujours des exigences que, même en se mettant dans la peau des utilisateurs, on ne pourra pas spécifier voire identifier à l’avance.

Wilos devient un projet communautaire

Une communauté de 11 pour l'instant

Après 3 mois de développement plutôt orienté OpenUp, 3 mois à suivre Scrum mâtiné de XP, le projet Wilos passe au développement communautaire[1] des logiciels libres. Hier soir avait lieu au Hoegaarden café[2] la deuxième réunion de la communauté Wilos. Wilos a d’abord été développé dans un cadre universitaire, jusque fin mars. Le projet continue, hors de ce cadre, avec actuellement les 11 personnes qui se sont manifesté pour poursuivre l’aventure.