XXP

mai 2016

lun. mar. mer. jeu. ven. sam. dim.
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31          

« La Fable Du Scrumier | Accueil | La Fable Du Scrumier »

01 octobre 2011

La Fable Du Scrumier

Adpatation françoise de Flaccid Scrum.
(Connoisseurs et amateurs de poésie, passez votre chemin...)
  Pig
                     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 ;)

TrackBack

URL TrackBack de cette note:
http://www.typepad.com/services/trackback/6a00d8341c871f53ef015391ff17bb970b

Listed below are links to weblogs that reference La Fable Du Scrumier:

Commentaires

C'est un blog magnifique.
[done]+google reader

À 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 ?

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 !

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 ?

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

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.

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...

Magnifique, j'adooore !

Bonjour,
Il me semble que le rôle dont vous parlez existe déjà, sans devoir faire recours à un Scrum 2.0. Il s'agit de l'Architect Owner qui est garant de l'architecture, et dont le rôle est de proposer / imposer des Technical Stories, au même titre que le Product Owner qui propose les User Stories.
Ceci afin de réduire la Dette Technique qui semble être le coupable dans la fable.

La lutte continue entre les Functional Stories qui amenent de la valeur et les Technical Stories qui apportent de la stabilité peut effectivement être exprimées par les 3 lois de la scrumbotique mentionnées ci-dessus, que j'aime bien !

Oui bien vu, un Architecture Owner a toute sa place.

Je ne connaissais pas ce rôle, sans doute parce qu'il n’apparaît ni dans le guide officiel de Scrum (http://www.scrum.org/storage/scrumguides/Scrum_Guide.pdf) ni dans la définition des rôles de Scrum Alliance (http://www.scrumalliance.org/pages/scrum_101). En fait dans ce guide on cherche déjà en vain le mot "software", inutile d'y chercher "Architect".

Mais c'est peut-être en train de changer sous l'impulsion de Ken Schwaber, qui pousse les sujets techniques à apparaitre dans Scrum. Ce qui lui a valu d'être éjecté de Scrum Alliance. L'histoire du schisme et les motivations de Ken sont intéressantes à lire : http://www.scrum.org/originsofscrumorg/.

C'est à lui qu'on doit l'introduction d'une formation au développement logiciel en mode Scrum http://www.scrum.org/professionalscrumdeveloper/. Peut-être un Scrum 2.0, ou au moins un Scrum orienté software...

Merci pour cette fable. J'ai beaucoup aimé!

Très chouette fable. Qui me rend affable.
Pas très doué pour les alexandrins.

J'adore! Merci!

L'utilisation des commentaires est désactivée pour cette note.