PLANNING EXTREME PROGRAMMING, KENT BECK ET MARTIN FOWLER

Ce livre a été conjointement écrit en 2001 par Kent Beck et Martin Fowler et préfacé par Tom DeMarco. Cela fait trois grosses signatures pour un seul et même ouvrage.

LA GESTION DE PROJET

Les auteurs consacrent le livre à la planification et au pilotage d'un projet mené dans une démarche XP. Ils cherchent à montrer qu'en plus de pratiques techniques, la panoplie XP contient toutes les pratiques nécessaires et suffisantes pour planifier et piloter un projet.

XP + SCRUM OU XP?

On dit souvent que Scrum apporte aux pratiques techniques d'XP les pratiques de pilotage de projet et d'équipe. Ce livre tend à montrer que XP est déjà auto-suffisant pour la gestion de projet. La sur-couche Scrum ne fait que recouvrir avec son propre vocabulaire et ses rôles des pratiques pré-existantes dans XP. Ceci dit Scrum apporte plus de formalisme et de cérémonial, ce qui est une bonne chose à mon avis.

DE L'EAU DANS LE VIN

D'une manière générale, Martin et surtout Kent ont mis de l'eau dans leur vin. Dans ce livre, je trouve que l'aspect extrême d'XP est diminué. Déjà, en préface, les auteurs rappellent que XP n'est pas une destination mais un parcours. Une pratique conforme au livre d'XP doit servir à identifier ce qui dans la démarche doit être adapté au contexte du projet.

La durée de l'itération est devenue un sujet d'expérimentation. Le cycle hebdomadaire n'est plus une référence. L'essentiel est de rester en dessous du mois et de ne pas glisser!

De même, la pluridisciplinarité de chaque membre de l'équipe n'est plus encadrée par une rotation systématique des binômes sur toutes les parties de l'application. La spécialisation des développeurs est même encouragée à partir du moment qu'elle est liée à une motivation personnelle.

Aussi, les auteurs sont plus permissifs quand à l'existence de bugs dans le produit. La correction de bugs mineurs n'est pas nécessairement une priorité pour l'équipe.

Enfin, les auteurs sont moins impératifs sur la nécessité de développer les fonctionnalités de bout en bout. L'essentiel est désormais que tout ce qui est développé dans l'itération soit testé à la sortie de l'itération.

Personnellement je désapprouve le calcul d'une vélocité individuelle pour chaque développeur. Je suis peut-être un peu Bisounours, mais je ne vois pas comment cela peut rester compatible d'un esprit d'équipe efficace. Je préfère calculer la vélocité de l'équipe pour mesurer sa capacité de travail par itération et éventuellement diviser cette vélocité par le nombre de développeurs pour surveiller l'impact de l'intégration de nouveaux membres dans l'équipe.

Enfin, j'ai apprécié le désaccord entre Kent et Martin portant sur la priorité des fonctionnalités à développer. Kent accorde une plus grande priorité à celles qui apporte le plus de valeur au client alors que Martin accorde les plus hautes priorités à celles qui comportent le plus de risques. C'est le pilotage par retour sur investissement contre le pilotage par les risques.

EN CONCLUSION

Bref, si on connait déjà XP et Scrum, il ne me semble pas que la lecture de ce livre soit si importante. Par contre, si on croit que XP ne contient que des pratiques techniques, alors ce livre est une occasion de se détromper. Il se lit très vite gràce au style reconnaissable de Kent: une succession de petits chapitres de 2 ou 3 pages au plus.

ARMURE OU MOBILITE?

En 2000, Tom DeMarco (co-auteur du brillant PeopleWare) a rédigé une préface vraiment intéressante pour le livre Planning Extreme Programming de Kent Beck et Martin Fowler.

LE BALANCIER

Il évoque que dans le livre On War, Carl von Clausewitz constate que l'histoire de la guerre est assimilable au mouvement d'un balancier. Au fil du temps, ce balancier oscille entre avantages relatifs de l'armure et de la mobilité.

Les chevaliers en lourdes armures ont écrasé les fantassins peu protégés. La cavalerie légère a décimé les chevaliers trop lents. Les chars ont piétiné la cavalerie trop fragile. Les guérilléros armés de lance-roquettes transpercent les chars trop aveugles .. (et Paix sur Terre aux hommes de bonne volonté).

ET LE DÉVELOPPEMENT LOGICIEL DANS TOUT CELA?

Tom DeMarco constate que le développement logiciel suit le même mouvement de balancier entre l'armure (les processus lourds) et la mobilité (les démarches légères).

Au commencement, les développeurs adoptaient des démarches empiriques et rapides. Puis, avec le volume croissant des logiciels et les pertes de visibilité sur les projets, des processus lourds et formels ont été mis en place pour se protéger des échecs. Désormais, fatigués par l'inertie de ces démarches lentes et lourdes, les équipes passent à l'offensive et cherchent à réussir par des développement éclairs.

On dit d'ailleurs d'un process qu'il est lourd (comme une armure?). Aussi, l'"agilité" est un mot proche de "mobilité". De plus, l'agilité prône la réactivité et celle-ci n'est autre que la mobilité transposée au développement!

Il fut un temps où on cherchait ce qu'on pouvait ajouter à son process pour mieux se protéger contre le fiasco. Maintenant, les équipes pistent ce qu'elles peuvent retirer de leur process pour gagner en rapidité et gagner tout court.

PLUS GÉNÉRALEMENT

Il semble que lorsqu'on renforce son armure, on cherche à ne pas perdre. Par contre, lorsqu'on allège son armure, on cherche à gagner.

LE MOT DE LA FIN

Ces réflexions me ramènent bien sur au CMMi et à l'agilité. De quel côté se trouve le CMMi? De quel côté se range l'agilité? Cela a t-il un sens de les associer? Doit-on parler de CMMi et d'Agile ou de CMMi puis d'Agile? Le CMMi ouvre-t-il la porte à l'agilité car il voit le balancier le quitter pour pencher vers la mobilité? Vers où penchera le balancier après l'agilité?

CARA, PREMIERE REUNION A VALENCE

Hier soir, s'est tenue la première réunion du CARA à Valence. Elle a eu lieu dans les locaux de l'IUT.
Nous étions 13 participants provenant de plus d'une demi-douzaine d'entreprises locales.
Le compte-rendu de la session est disponible sur le site du CARA.

Les premières rencontres sont toujours un peu délicates car il n'y a pas de programme pré-établi. Nous avons donc choisi de conduire un forum-ouvert. En tout cas, nous n'avons pas eu de flottement et les discussions coulaient naturellement.

Merci aux participants et rendez-vous au mois de Janvier!

LEAN EVENT, PAR ADACORE

Je suis invité au mois de Mars pour présenter une conférence sur les thèmes de l'avionique, de l'agilité et du Lean à l'occasion d'un évènement sur le Lean organisé par AdaCore.

Jim Sutton, co-auteur de Lean Software Strategies, sera la guest-star de l'évènement. Les conférences seront en anglais. Il faut donc que je me mette au travail!

ITERATION OU SPRINT?

Dans Scrum, il y a un terme que je n'apprécie plus trop: le Sprint.

ITÉRATION OU SPRINT?

Après 130 jours ouvrés de développement, nous en sommes à notre septième itération et nous en avons encore pour plus d'un an de développement.
Déjà, nos itérations se sont transformées en sprints dans le sens premier du terme. Nous n'en sommes plus à un rythme durablement soutenable.

VÉLOCITÉ ET COURSE

Nous mesurons notre vélocité, nous la publions et nous l'utilisons pour planifier les itérations. Nous subissons une forte pression provenant de nous même comme du management pour améliorer continuellement cette vélocité.
Classiquement, une telle course à la productivité se fait au détriment de la qualité. C'est la nature même du développeur. Heureusement, le secteur du logiciel critique n'autorise pas de prendre la qualité comme variable d'ajustement. Alors, nous rognions sur certaines tâches de fond que nous poussons devant nous au risque de nous ralentir un jour. Par exemple, nous délaissons la réorganisation de la base de gestion de configuration, la rapidité du build et la rotation des développeurs sur les différentes parties de l'application.

TUNNEL ET TRANSPARENCE

Ce qui est fou, c'est que nous sommes à l'origine de cette course à la vélocité.
Avant, nos projets avançaient "tranquillement" dans un tunnel. La pression venait tard car nous n'avions que tardivement une vision objective et réaliste de l'avancement du projet.
Depuis quelques projets, avec la publication régulière d'une vélocité pertinente et des estimations basées sur cette productivité, nous sommes rapidement conscients de la partie immergée de l'iceberg. La vision réaliste du projet est vite révélée. Et la pression arrive tôt.

DU MOU

En rétrospective d'itération, l'équipe a identifié la course à la vélocité comme étant le principal problème à régler. Nous avons demandé à expérimenter la chose suivante: le premier jour d'une itération sera exclusivement consacré à des tâches de fond et à des améliorations. Ce jour là, personne ne cherche à produire un incrément de fonctionnalité. Cela peut paraître un peu maigre comme avancée, mais il n'est pas évident de convaincre les managers de ralentir une locomotive rapide, mais en retard sur un horaire.

UNE QUESTION DE VOCABULAIRE?

Je suppose que le mot "sprint" plait aux managers et aux clients. Il sous-entend que l'équipe ne peut aller plus vite sans prendre le risque d'un claquage. Le problème est que nous ne pouvons sprinter longtemps. Je préfère le mot "itération". Il me parait plus serein. Il reste à concrétiser cette nuance de vocabulaire en un rythme durablement soutenable pour l'équipe.

METAPHORE V VERSUS ITERATIF ET INCREMENTAL

Aujourd'hui, nous cherchions une métaphore pour comparer le cycle en V à un cycle itératif et incrémental.

LE PARCOURS PRÉDICTIF

Il nous a semblé que conduire un cycle en V revient à prendre le temps de visualiser où on souhaite se rendre, à prévoir la trajectoire à suivre pour atteindre ce lieu, à estimer le temps qu'il faut pour parcourir le chemin, puis à fermer les yeux et se diriger sans voir vers cette destination. Quand la durée estimée du trajet est atteinte, on ouvre les yeux.

LE PARCOURS ADAPTATIF

Conduire un cycle itératif et incrémental revient à répéter en boucle la démarche suivante: jeter un coup d'œil rapide vers sa destination, fermer les yeux, faire quelques pas sans voir vers cet objectif et ouvrir les yeux. Plus le nombre de pas entre deux coups d'œil est réduit, et plus le pilotage est fin.

LA MÉTAPHORE CONCRÉTISÉE PAR UN ATELIER

Cette métaphore peut être jouée en atelier. Deux volontaires côte à côte se voient attribuer une même destination. Le premier doit se rendre à ce lieu en suivant la première démarche. Le second adopte la deuxième démarche.
Pour pimenter l'atelier, le parcours peut être initialement perturbé par un obstacle, comme une chaise ou une personne. Il est également intéressant d'ajouter un obstacle supplémentaire (une autre chaise ou une autre personne) en cours de parcours.
Ensuite, il peut être intéressant de rejouer le même atelier, mais cette fois avec deux volontaires adoptant la deuxième démarche. Le premier ouvre les yeux tous les pas. Le deuxième n'ouvre les yeux que tous les trois pas.

A EXPÉRIMENTER

J'utiliserai cette métaphore et j'essayerai ces petits ateliers avec les étudiants lors de mes prochains cours de génie logiciel pragmatique.

EN CONCLUSION

Cette métaphore ne suffit pas à illustrer les différences entre les deux démarches. Aussi, cette comparaison est caricaturale. Personne ne mène un cycle en V aussi aveuglément (rassurez-moi). En cours de développement, il y a bien sûr des réajustements (tardifs certes, mais il y en a toujours). Néanmoins, cette métaphore me semble être une bonne vulgarisation.

SCRUM AND XP FROM THE TRENCHES, HENRIK KNIBERG

J'ai profité de la traduction en français de ce livre pour enfin le lire.

Loin de la théorie de Scrum, l'auteur décrit de manière très pragmatique son implémentation de la démarche en révélant plein de petits conseils pratiques.

Après avoir lu un ouvrage de Ken Schwaber, ce livre est idéal pour se faire une idée concrète de comment Scrum peut être appliqué au jour le jour. Étant déjà praticien, j'ai trouvé très intéressant de confronter nos pratiques à celles de Henrik. Aussi, dans la multitude de petit conseils pratiques, tout le monde trouvera bien un petit quelque chose à expérimenter sur son projet.

Les 150 pages se lisent tranquillement et agréablement le temps d'un week-end.

Merci à Emmanuel Etasse, Bruno Orsier et leurs compères pour ce travail de traduction. Le livre est gratuitement et légalement téléchargeable ici.