Scrum et XP depuis les tranchées

Il est sorti en français!
Annoncé sur le groupe XP France aujourd'hui, je ne saurais que vous conseiller la lecture de ce livre qui fait référence (préface de Jeff Sutherland et Mike Cohn) sur la mise en pratique de Scrum et XP.

Rédiger des cas d'utilisation efficaces

J'ai acheté ce livre juste après la formation Gestion de projet RUP et surtout parce que c'est un livre d'Alistair Cockburn, un des signataires du Manifeste Agile, et avant de me plonger dans le livre de mike Cohn, très prochainement: D'abord le livre est vraiment trop très complet, plein d'exemples: à lire si vous devez écrire des cas d'utilisation. Il survole les 3C d'XP, comme étant un résumé des cas d'utilisation et finalement faisant partie de la vision d'ensemble du projet. On trouve d'autres commentaires sur sa vision des users stories vs use case. On retrouve des problématiques communes avec les user stories, trouver la bonne granularité, la portée des descriptions d'exigences, entre autre. Au passage, les niveaux décrits par Cockburn sont assez intéressants nuage, cerf-volant, mer, poisson: on nage en plein dans la métaphore du niveau de la mer avec laquelle j'ai bien accrochée. Ce qui me bloque avec les cas d'utilisation, et avec RUP pour la même raison, c'est qu'un cas d'utilisation peut recouvrir plusieurs itérations. On est dans un processus itératif non incrémental, à mon sens, bien que tout dépend de l'échelle de temps avec laquelle on mesure ces incréments, lire ici un post d'Alistair sur le sujet, des "nano-incréments" d'XP à l'incrément-release. Cela peut se traduire par exemple par une version simplifiée d'un cas d'utilisation dans une itération et une version complète dans une itération ultérieure. La longévité d'un use case est plus grande qu'une user story ou 3C. Quels bénéfices peut-on attendre d'une approche incrémentale? Il s'agit de livrer à chaque fin d'itération un ensemble de fonctionnalités finies au client, avec une définition partagée de finie pour tous. L'équipe peut s'engager sur le contenu de l'itération à réaliser. Le client peut donner son feed-back puisque l'on peut faire la démo de ces fonctionnalités. Si le client a validé l'incrément, on ne revient plus dessus et il peut repartir avec. Pour l'équipe, ces petites victoires successives donnent du rythme et du courage pour le projet. Pour le product owner, on peut réellement prioriser l'itération suivante puisque rien ne traîne dans le Sprint Backlog. On perd beaucoup de bénefices à mon avis à ne pas être incrémentale (à chaque itération). Trop flemmard pour lire le livre, je vous propose un podcast de Pascal Roques sur les bonnes pratiques autour des cas d'utilisation (sans lien avec le livre). Et pour suivre une discussion en cours sur la documentation agile, c'est ici.

Open Coffee Club de Rennes

La communauté Web2Rennes, regroupant les entrepreneurs, développeurs, investisseurs, ..., du monde internet à Rennes, organise régulièrement des rencontres informelles.

Cette communauté a un nouveau site OpenCoffeeRennes pour rejoindre les communautés OCC de France (Nantes, Sophia, Lilles, Lyon).

Nous serons présents au Forum West Web Valley : le Web2.0 dans tous ses états! à Rennes demain, organisé par le MEITO, avec notamment une Keynote de Loic LeMeur depuis la Silicon Valley.

Cliquer ici pour voir le diaporama du Forum et ici pour le compte rendu de Lidia.

Agile CMMI?

CMMI et Agile sont dans un (même) bateau...

De retour de formation CMMI, je partage le point de vue de QualityStreet et plus généralement ce que j'avais déjà souligné ici, à savoir que CMMI et Agile peuvent faire bon ménage et converger. Ils partagent certains fondements notamment celui d'apporter plus de valeurs au client dans une démarche d'amélioration continue alignée avec le métier.
Si le CMMI adresse le "Quoi" via les objectifs et propose bonnes pratiques et activités typiques pour y répondre, les méthodes Agiles implémentent des "Comment" alternatifs et acceptables pour le CMMI. Ce n'est pas nouveau mais je l'ai vraiment ressenti pendant ces trois jours avec des échos côté Lean, 6 sigma, RUP, Scrum ou XP.

Compatible aux niveaux de maturités 3 & 5

On trouve une littérature assez complète sur le mapping ici ou là entre pratiques Agile et objectifs CMMI, en français avec afoucal.
Le niveau de maturité 3 du CMMI est bien couvert avec des modèles comme MSF et son implémentation Agile par David Anderson ou encore Agile+.

On peut lire récemment des retours d'expérience sur le niveau de maturité 5 par Jeff Sutherland.

La revue par les pairs en Agilité?

Le mapping n'est pas suffisant pour se rendre compte de ce que la convergence implique. Je propose pour cela de faire un focus sur l'activité de revue de pairs du domaine de processus Vérification SG2 (Niveau de maturité 3)

Les revues par les pairs consistent en un examen méthodique des produits d'activité par les pairs de ceux qui les ont réalisés, afin d'identifier les défauts à éliminer et de recommander les modifications nécessaires

Et la pratique correspondante XP le binomage (Pair programming): Puisque la revue de code est une bonne pratique autant la faire en permanence!

Mais le pair programming ne se limite pas à cela: c'est aussi une séance de conception et de revue de conception continue grâce au refactoring.
Les critères de vérification et la préparation de ces revues sont constitués par les pratiques XP liées au pair programming : coding standards, simple design, métaphore, testing.

Source igan sur Flickr

En plus du pair programming, on pourrait également parler de toutes les réunions collectives qui sont autant d'occasions de revues informelles.

• Les revues de conception / estimation / planification pour l'aspect technique
• Les rétrospectives, les cercles de qualité du Kaizen pour l'aspect processus
• Et plus généralement la transparence, vis à vis de l'organisation avec le radiateur d'informations ou les daily scrum, qui créée les conditions pour des revues potentielles.
  

Omni présente mais est-elle suffisante?

On voit que l'on est bien armé face à cet objectif de revue par les pairs à différents niveaux.
Mais le fait de ne pas avoir de revue structurée telle que l'inspection Fagan et de la faire à l'écran, selon Watts Humphrey, ne permettrait de remonter que 20 à 40% des anomalies contrairement au 60-80% d'une revue structurée. J'ajouterais qu'en binomage on est à la fois juge et partie.
En XP, le but n'est pas de trouver des anomalies mais de ne pas en introduire en couplant cette pratique avec le TDD.

Mais la pratique, malgré son bénéfice, n'est pas suffisante pour le dispositif CMMI dans une perspective d'amélioration continue: Il faut pouvoir suivre quantitativement l'effet de ces pratiques et faire des analyses causales (5W, Ishikawa, ...) des non-conformités.

L'analyse des données de la revue de pairs par le CMMI tourne autour du rendement de la revue (pourcentage de défauts détectés), le taux de revue (page par heure) et le cout (heures passées) par défaut découvert, entre autre...
Alors quelles métriques dans une équipe XP? Le nombre de défauts non introduit dans le processus? Ou bien estimer la dette technique comme le propose récemment Martin Fowler, bref difficile à quantifier... Et à mettre en pratique?

Des pistes pour converger?

D'abord côté CMMI et plus généralement, les spécificités des équipes et projet Agiles se retrouvent dans le domaine IPPD (Integrated Product and Process Development) qui

[...] recouvre aussi l'établissement d'une vision commune du projet et l'établissement d'une structure d'équipe pour les équipes intégrées qui vont favoriser la satisfaction des objectifs du projet".

Une équipe auto-gérée Scrum/XP est une équipe intégrée avec le client sur site, les développeurs, les testeurs...

De l’autre, pour la revue de pairs, le binomage n'exclut pas une revue par les pairs formelle en fin d'itération qui, elle, peut être quantifiée avec des éléments d'actions à suivre. Cela peut avoir un sens pour une équipe en plateau de vélocité: Les analyses causales sont intéressantes sur des processus stables sans quoi le signal émis n'est pas forcément pertinent.

Cette approche quantitative/statistique est peu présente dans l'approche Agile, délibérément puisque d'un côté Lean nous rappelle de ne suivre qu'une poignée d'indicateurs qui font sens plutôt qu'une multitude de métriques qui ne servent pas: La collecte et l'analyse de ces métriques a un cout important; d'avoir un management visuel (Radiateur d'info) et des métriques orientées client (Business Value cumulée, Story points implémentées, ...) et beaucoup moins processus et organisation.

Malgré tout, on a des mesures "agiles" à suivre, les radars des rétrospectives, les enquêtes à la Yahoo sont autant d'indicateurs dans un contexte d'adoption d'un processus au niveau projet ou organisation et pour la remettre dans son contexte.

Des pistes pour s'améliorer?

Les méthodes Agiles s'adaptent et s'améliorent dans leur contexte projet de manière qualitative avec les rétrospectives, les suivis de tendances (burndown chart, vélocité). Pour dépasser ce stade projet et se répandre dans l'organisation, un suivi plus quantitatif et contextuel est donc important. Mais n'est pas suffisant, comme le note encore Watts Humphrey, et met en avant avec le CMMI le support de transition: Le framework de transition de Mike Cohn en est une bonne illustration.

Conclusion

Nous avons vu qu'une simple réflexion autour du binomage XP et des revues de pairs CMMI permet déjà de mesurer l'effort pour converger là ou il semblait que le mapping était suffisant. Que cet effort pointe du doigt la gouvernance des projets Agiles, leur contextualisation pour atteindre l'organisation elle-même, sujet d'actualité, et qui explique qu'on puisse se tourner vers le CMMI pour avancer sur cette question.

--Ajout 12/11/08

Le SEI (Software Engineering Institute) a publié aujourd'hui le papier CMMI or Agile : Why Not Embrace Both! co écrit par le SEI et David Anderson entre autres.

Ils scellent leur volonté d'être compatibles voir complémentaires en faisant un appel aux experts CMMI d'un côté et aux experts Agile de l'autre pour aller dans ce sens. Une demande de changement a été émise pour inclure l'approche et les principes Agiles dans les modèles CMMI. La machine est en marche!

-- Ajout 23/11/08

La machine n'est pas en marche pour tous dans la communauté XP France!