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.
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.
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 ;)
C'est un blog magnifique.
[done]+google reader
Rédigé par : Xiaoyuan | 01 octobre 2011 à 19:50
À vrai dire tout cela sent très fort le vécu,
Il nous faut regretter qu'on ne t'y reprenne plus.
À bien y observer ton histoire semble tourner,
Autour d'un même problème de code avarié.
N'aurait-il pas fallu, tout reprendre au début ?
Ceci a défaut de l'avoir profond dans l'fut !
En ce qui concerne les ajouts de fonctionnel,
N'aurait-il pas fallu une par décisionnelle ?
Rédigé par : Tekool | 01 octobre 2011 à 22:33
O Monsieur de Dollfus, maître des logiciels
Que tes vers retentissent dans toutes les oreilles
Surtout celles des marchands, sautant comme des cabris
Vendant à qui en veut, leur "méthodologie"
Point ne faut recourir au parler de la soule
L'art du code n'a rien d'un jeu de coups de boule
Piquer le bon ouvrage sans un certificat
Compagnons de l'extrême, montrons le b-a-ba !
Rédigé par : Oaz | 01 octobre 2011 à 23:47
Bel effort messieurs :)
Et oui il y a une part de vécu -- mais pas en ce moment dois-je préciser (je ne règle pas de compte sur ce blog).
Mais notez que je ne jette pas la pierre aux "marchands" comme tu dis @Oaz. L'ampleur des changements et l'attention accordée aux nouvelles pratiques sont telles que l’équipe seule peut perdre de vue la qualité du matériau de base du soft, pourtant garante d'une "itératibilité" durable, donc de Scrum lui-même.
Parfois ça marche bien : l'atout de Scrum est d'offrir suffisamment de souplesse et de feedbacks pour que l’équipe s'en aperçoive, typiquement lors d'une rétrospective, et s'auto-organise en conséquence. Mais le problème décrit par Martin Fowler survient quand on s'en aperçoit trop tard...
Il faudrait au moins ajouter a Scrum un rôle, une pratique ou je ne sais quoi qui institutionnalise la recherche de qualité du code. Et qui apparaisse aussi distinctement à la lecture de Scrum que les planning meetings, les Sprints ou le product owner.
Un Scrum 2.0 en somme. C'est possible ça ?
Rédigé par : Denis | 03 octobre 2011 à 21:45
Et bien moi je la jette la pierre !:-)
A qui la faute si aujourd'hui la grosse majorité des gens ont pour seule équation « méthode agile = scrum = gestion de projet » ?
Je ne crois pas à des pratiques supplémentaires – d'ailleurs je ne crois même plus à scrum.
Les gens qui en sont réduits à appliquer des "pratiques" passent à côté de l'essentiel.
Je crois en un retour à des fondamentaux très simples :
Principe 1 : la maintenabilité d'un produit, c'est à dire le maintien d'un cout de changement constant de manière continue, est la priorité absolue
Principe 2 : la création de valeur dans le délai le plus court possible pour le client/utilisateur est la priorité, sauf si cela va à l'encontre du principe 1
Principe 3 : toutes les occasions pour s'améliorer et pour améliorer le produit dont l'équipe est capable sont la priorité, sauf si cela va à l'encontre des principes 1 ou 2
Rédigé par : Oaz | 06 octobre 2011 à 00:37
C'est pas mal ça ! Ça m’évoque évidemment les 3 lois de la robotique d'Asimov, et du coup je me demande si elles ne peuvent pas conduire aux mêmes situations tortueuses que celles qui font la matière des nouvelles d'Asimov.
Par exemple: en vertu de la loi 1 l’équipe ne cesse de repousser la création de valeur parce qu'elle juge que le code ne permet pas encore une maintenance aisée -- on refactor, on ajoute abstraction après abstraction, on tend vers le super framework qui fait tout... et vers la faillite du projet.
Rédigé par : Denis | 08 octobre 2011 à 13:31
Dingue ça !
Je n'y avais (honnêtement) même pas pensé - mais ça fait plus de 20 ans que j'ai lu l'intégrale des Robots...
Pour que ça fonctionne, je pense qu'on ne peut pas complètement se reposer sur un jugement qui serait inexorablement subjectif. Il existe surement quelques règles qui permettent d'être plus objectifs (Rule Of Three...)
Ceci étant, si on pense aux 3 lois d'Asimov, c'est qu'il y a peut être une loi 0 qui se cache quelque part...
Rédigé par : Oaz | 18 octobre 2011 à 00:58