Denis Dollfus' Blog

La Fable Du Scrumier

Adpatation françoise de Flaccid Scrum.

(Connoisseurs et amateurs de poésie, passez votre chemin...)

 

                     O -- o -- o -- O

 

Maître Saint-Gueuleton, artisan logicier,
Contemplait rayonnant sa troupe d’apprentis :
Depuis qu’au mode Scrum il avait consenti,
Sa fabrique de code lui semblait s'apprécier.

“Fini l’odieux brouillard, supprimé le tunnel,
Ce long chemin qui part d’un monceau fonctionnel.
Les Stories validées par notre clientèle,
Apaisent l’acheteur redevenu fidèle.
Les causeries du jour et les courses sans fin
Assurent le labeur des techos au parfum.
Enfin qu’il est plaisant de voir ces rastaquouères
Accablés dans l’effort a forger du softouère!”

Savourant son plaisir, jaugeant les retombées,
Notre ami satisfait soudain fut bouche bée.

D’une grande pagaille au fond de l’atelier
S'éleva l’expression d’un intense courroux :
“Par Chuck ! Il suffit, céans je file au Pérou !
Le fouillis a gagné, je rends mon tablier !”

Le scrumier, très surpris, de précisions s’enquit :
“L’ouvrage est fragile et le code... quel foutoir !
Comment oeuvrer serein dans ce vrai champ de foire
Qui s'accroît en dépit des rites du Wiki ?

L’addition cadencée de fonctionnalités
Provoque malgré nous régressions et naufrages
Si bien que nos efforts se vouent au colmatage
Hélas, point au concours de valeur ajoutée.”

Le scrumier assommé compris alors que Scrum
Pouvait fort bien rimer avec capharnaüm.
Il se dit que fini, on ne l’y prendrait plus,
Le code vermoulu était bien révolu.

                              -- o --

A petits pas agiles dans de jolis souliers,
On peut bien trébucher dans la mare aux cochons.
Gare aux seules manières : adoptons aussi l’art
De nouer les lacets, ficelles du métier.

Le point de tout software si on le veut pérenne,
Repose sur sa substance, ses forces souterraines.
Cachée des managers, la qualité du code
Fournit l’alliée majeure de toutes les méthodes.

 

                      O -- o -- o -- O

 

 Alexandrins de rigueur dans les commentaires ;)

XP sans Scrum, Scrum sans XP

On lit souvent qu'XP et Scrum s'entendent comme larrons en foire parce qu'ils sont complémentaires, l'un comblant les lacunes de l'autre, et vice versa. L'expérience que j'ai de ces deux méthodologies et l'intérêt que je leur accorde me font dire que l'idée est consensuelle mais inexacte.

Scrum ♥ XP

Nouvelle matérialisation du consensus, le questionnaire sur les méthodes agiles en France publié par le Scrum User Group français fait apparaître la dichotomie habituelle. Scrum rassemblerait les techniques de gestion de projet (réunion d'itération, réunion brève quotidienne, etc.) et XP les techniques d'ingénierie logicielle (tests unitaires, intégration continue, etc.). L'alliance Scrum-XP serait alors la synergie idéale.

XP seul

La réalité est qu'XP possède ses propres pratiques de gestion de projet et n'a donc pas besoin de Scrum pour couvrir l'aspect management des développements. Les itérations courtes, les réunions de planification d'itération, la présence quasi permanente du client, le partage des connaissances entre membres de l'équipe sont autant de pratiques XP qui ne sont pas de l'ordre des pratiques d'ingénierie. Pour être clair :

 

Scrum seul

Réciproquement, il existe quantité de contextes dans lesquels Scrum n'a pas besoin de compléments XP. Scrum seul excelle dans des projets ou XP est hors sujet car fortement lié à des langages de programmation orientés objets et fortement typés.

Par exemple les tests unitaires chers à XP sont inapplicables en environnement RAD, quand le code est auto-validé au moment même où l'utilisateur (le développeur ?) finit son glisser-déplacer d'un champ de la base de donnée sur un formulaire en construction. Dans ce cas Scrum, lui, reste pertinent, comme plus généralement dans les projets dominés par l'emploi d'outils de génération de code.

Autre exemple, le refactoring intensif est une des pratiques clés d'XP. A chaque changement du code, qu'il soit évolutif ou correctif, le refactoring améliore l'architecture, facilite la maintenabilité du code et fondamentalement le maintient dans un état qui autorise les futures modifications ("embrace changes"). Or le refactoring (petits ou gros remaniements du code) devient délicat et dangereux quand les outils de refactoring automatique (e.g. extract method) ne peuvent plus épauler le développeur. Or les langages dynamiques, JavaScript en tête (et SmallTalk inclus), mettent les bâtons dans les roues à ces outils car certaines ambiguités de syntaxe ne peuvent être résolues qu'au runtime. Dans ce cas encore XP perd de son charme, pas Scrum.

Scrum plus libre qu'XP

En somme XP a une forte adhérence aux environnements de développement devenus standards que sont Java, C# et dans une moindre mesure car un peu plus résistant au refactoring, C++. Dans des contextes dominés par ces langages, faire de l'agile sans adopter les pratiques d'ingénierie d'XP, c'est se priver de ce qui maintient le code évolutif et léger, c'est un peu vouloir construire un building en mode agile…

En revanche dans d'autres contextes, non seulement Scrum se suffit à lui même, mais XP est out. C'est le cas des projets sur lequel le code n'est pas un élément central du système à construire, par exemple lorsque les outils sont graphiques, lorsque le code est généré ou lorsqu'il s'agit de paramétrer un progiciel (SAP, Reporting, CMS, etc.). Ou encore quand le projet comporte un degré d'innovation tel qu'il n'existe pas encore de bonnes pratiques reconnues, mais ça je l'ai déjà dit.

Le cœur de métier des méthodes Agiles c'est l'innovation

Après quelques années de développement dans des contextes très différents dont quatre en mode agile, j'apprécie l'apport de l'Agilité, de Scrum et d'XP. Petit point de vue sur l'Agilité via Scrum.

Pas agile, mais éventuellement habile.
Les Temps Modernes, Chaplin.

Scrum va beaucoup plus loin que la déclaration d'intention Agile parce qu'il complète les voeux qui la composent par des moyens pratiques. Il donne corps aux valeurs Agiles, au premier rang desquelles figurent les individus et leurs interactions. Il aide à mettre en place des techniques de gestion de projets, canalise l'ingéniosité des membres de l'équipe, leur réactivité face à des nouveaux outils, leur créativité, leur facultés d'écoute et de communication, leur capacité à identifier une mauvaise direction technique ou fonctionnelle et à faire demi-tour.

Du coup Scrum excelle dans des projets où les qualités des individus sont essentielles, là où l'astuce est plus utile que la force, là où la valeur produite n'est pas proportionnelle à l'effort. Ces projets sont plus proches de la recherche que de l'industrie, du bureau d'étude que de l'usine. Ils sont souvent caractérisés par des risques assez élevés sur l'identification des besoins ou sur les technologies mises en œuvre.

En un mot, le cœur de métier de Scrum c'est l'innovation. Scrum est à son aise et se suffit à lui-même quand tout est nouveau, depuis les services rendus par le futur système jusqu'aux technologies à mettre en œuvre, parce que dans ce cas le software est essentiellement du Peopleware, livre devenu un classique dont je vous recommande la lecture.

 

Scrum : gare au déficit de qualité du code

Martin Fowler dans un article publié hier :

Il y a un problème dont j'ai entendu parler récemment sur quelques projets. Ca se présente comme ça :

• Ils veulent une méthodologie Agile et choisissent Scrum
• Ils adoptent les pratiques Scrum et même les principes
• Au bout d'un certain temps l'avancement du projet ralenti parce que le code source est en pagaille

[...]

J'ai mentionné Scrum parce que quand on constate ce problème, Scrum semble être fréquemment la méthodologie suivie par l'équipe. Pour beaucoup, la situation est amplifiée par Scrum parce que Scrum est centré sur les techniques de gestion de projet et omet délibérément les pratiques techniques, à l'inverse de (par exemple) Extreme Programming.

Scrum nuisible ? Non ça n'est pas si simple, lisez l'article.

En revanche, vous-même, êtes-vous plutôt technique ou plutôt management dans votre projet actuel ? Vous pouvez le savoir et vous comparer à quelques centaines (deux centaines c'est déjà quelques non ?) de développeurs francophones grâce à ce questionnaire.

Scrum et XP en pratique : un livre en français à télécharger

Emmanuel Chenu vient de signaler la sortie de la traduction française de "Scrum and XP from the trenches", d'Henrik Kniberg.

Loin de la théorie et de la simple déclaration d'intention de l'Agile Manifesto, ce livre décrit les pratiques (et leur justification) à mettre en oeuvre au jour le jour pour développer en mode Agile grâce à Scrum et XP.

Il est téléchargeable gratuitement depuis cette page.

Agilité : grandeur et décadence ?

Un article de James Shore intitulé "grandeur et décadence de l'agilité" fait du bruit (Cf. par exemple Claude Aubry). Le raisonnement de ce billet tient en deux points :

• Pour un projet donné, Scrum échoue sur le long terme si aucune méthode d'ingénierie logicielle ne vient compléter Scrum.
• Avec le temps, la multiplication de ces échecs donnera une réputation calamiteuse aux méthodes agiles, qui feront alors fuir tous les chefs de projets.

J'approuve ce point de vue sur Scrum. Scrum seul est réellement une calamité pour les logiciels à longue durée de vie parce que rien dans Scrum n'aide à bâtir des logiciels maintenables et évolutifs. Or rester agile, c'est-à-dire maintenir un rythme d'itérations courtes, requiert de développer un logiciel qui accepte les évolutions fréquentes. Ce qui n'a rien d'évident.

Pour y parvenir, les bonnes pratiques d'ingénierie logicielle, au premier rang desquelles les tests unitaires (TDD ou non), le refactoring et l'intégration continue doivent compléter les méthodes de management pur déconnectées du métier du software telles que Scrum. Ces pratiques doivent être adoptées pour que l'agilité dépasse la déclaration d'intention. Et pour que la réputation des méthodes agiles ne soit pas mise en danger.

Hélas, ces pratiques ont un succès tout relatif parce que Scrum et son écosystème rémunérateur de certifications est la plus vigoureuse et la plus visible des méthodes agiles.

On en arrive à la thèse de James Shore : la méthode Agile qui est en train de gagner entrainera toutes les méthodes agiles à leur perte.

Certes on a vu récemment des crises plus graves dans des domaines qui se portaient mieux, mais n'est-ce pas pessismiste ? Peut-on revigorer XP ?