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.

FRAGILITÉ

On nous demande fréquemment quelles sont les limites à la pratique efficace d'une démarche agile. En dehors du périmètre de l'équipe de développement, qu'est-ce qui peut nuire à la productivité de l'équipe? Au-delà de la contraposé de chaque valeur, principe et pratique agile, voici quelques contextes de développement inadéquats.

LA MULTIPLICATION DES FRONTIÈRES ET DES CONTRATS

La multiplication des relations contractuelles et des frontières au sein d'un projet (entre équipes, entre métiers, entre lieux géographiques, entre bureaux, entre langues, entre l'organisation et ses sous-traitants) entraine un effort d'organisation. Cet effort peut-être vu comme un gaspillage (au sens du Lean) puisqu'il n'apporte aucune valeur au client.

LE MANQUE DE CONFIANCE ACCORDE AUX ÉQUIPES

Si l'organisation n'accorde pas sa confiance aux équipes de développement, elle gaspillera de l'énergie à planifier en détail les travaux (qui ne se dérouleront pas conformément aux détails), à formaliser et standardiser en détail les procédures (que les développeurs souhaiteront adapter à plusieurs reprises) et à contrôler les activités (au lieu de supprimer les obstacles). Aussi, elle démotivera les équipes et freinera la prise d'initiative et de décision.
Cet état d'esprit, qui consiste à vouloir séparer penser et faire, se concrétise souvent par des procédures très détaillées, des outils complexes et une planification microscopique et à long-terme.

LE MANQUE DE MATURITÉ DE L'ORGANISATION

L'organisation doit faire preuve de maturité et de sang-froid pour accepter et traiter les problèmes qui seront identifiés tôt par la pratique des démarches agiles. Une organisation immature sera tentée d'agir sur la démarche qui a révélé les problèmes et non sur la cause racine des problèmes.

LE GIGANTISME ORGANISATIONNEL

L'équipe doit croître de manière itérative et incrémentale pour éviter de démarrer le projet avec de trop nombreuses ressources ou d'ajouter des ressources à un moment où le projet prend du retard. Conduire un grand projet avec de nombreux développeurs n'est pas une fatalité. Cette vision des grands projets est souvent liée à la planification par homme/mois. La synchronisation de nombreux intervenants est un effort. Cet effort peut être vu comme un gaspillage (au sens du Lean) puisqu'il n'apporte aucune valeur au client.

UN LANGAGE DE PROGRAMMATION INADAPTÉ

L'utilisation d'un langage de programmation orienté-objet est un atout pour construire une application de manière incrémentale et pour rendre le logiciel testable. Faire l'impasse sur la programmation orientée-objet rend les applications plus laborieuses à tester et à construire par incréments.

ET LA LISTE N'EST PAS FINIE ...

Tous ces contextes réduiront les bénéfices d'une démarche de développement agile. D'ailleurs ces freins à l'efficacité ralentissent tous types de projets, agiles ou non. Malheureusement, il ne s'agit sûrement pas d'une liste exhaustive.