Bref, j’ai joué aussi et comme l’ambiance s’y prêtait bien, j’ai ressorti ma doc de mysql. Un petit guard dans un coin pour avoir mon autotest et hop c’est parti. J’ai fait une petite vidéo du début pour vous partager de quoi ça peut avoir l’air et démystifier un peu le tdd avec le sql. Dans la session la semaine dernière nous avons pris l’option de ne pas utiliser de framework “sur étagère”, histoire de bien comprendre ce qui se passe en refaisant juste ce dont nous avions besoin. C’est cette option que j’ai repris ici.

Nous avons discuté de l’idée de supprimer ces commentaires. Une décision pas facile à prendre dans l’état car, pour plusieurs personnes présentes, le dessin du commentaire a beaucoup de valeur. En effet, il résume le cas qui nous intéresse de façon très claire.

Cela devient pourtant une décision facile à prendre si tout simplement on décide de reproduire ce dessin dans le code. Après un peu de tuyauterie, je suis récompensé : ma fille comprend mieux le code. Ci-dessous un exemple de ce que cela peut donner.

Bien sûr il reste à ranger tout ça plus proprement mais vous voyez l’idée. Notez que dans la bataille on est passé de 2 tests à 1 seul. Là c’est parce que on a fait du ADD. C’est ma fille qui vient d’inventer ça ce soir : le développement piloté par l’esthétisme. Elle trouve ça plus joli comme ça.

Et vous, vous faites comment ?

Depuis l’été dernier j’ai changé un truc qui me semble significatif dans mes formations Scrum et je voulais aujourd’hui le partager.

La version courte : pendant mes cours PSM, j’utilise maintenant le terme Scrum trainer en lieu et place de Scrum Master.

La communauté agile a largement, il me semble, décrit les inconvénients du nom “Scrum Master”, et surtout de cette étiquette “Master”. J’ai donc souhaité chercher une alternative. Et comme je souhaitais surtout essayer autre chose et mesurer sur le terrain ce que cela changeait, je n’ai pas attendu le résultat d’un éventuel long débat pour faire un essai.

Voici ce que j’ai cru mesurer:

• L’étiquette “trainer” véhicule mieux la partie “enseignant de Scrum” du rôle
• L’étiquette “trainer” supprime toute relation de hiérarchie avec l’Equipe

La façon dont je mesure ces améliorations est fort simple : d’une part les discussions pendant le cours ne sont plus les mêmes. D’autre part, une proportion beaucoup plus grande de participants me semblent comprendre comment tirer le plus avantage de ce rôle, et au delà du rôle, de l’ensemble de Scrum.

Un exemple ?

Avant, j’avais systématiquement la question “Est-ce que le Scrum Master fait les burndown charts ? “, et nous débattions un long moment sur les conséquences de le faire ou non. Maintenant cette question n’apparaît plus en ces termes et les participants explorent plutôt les conséquences pour une équipe de faire un burndown d’itération ou non.

Un autre exemple ?

Avant, nous débattions longuement autour de l’idée que le Scrum Master, vous savez, “removes impediments”. J’avais coutume d’insister sur le fait que nous parlons ici de blocages mentaux liés à la compréhension de l’étendue des responsabilités de PO et d’Equipe (de dev comme on dit maintenant). Cette idée avait du mal à se frayer un chemin dans les cerveaux tant le vocabulaire ne nous aidait pas. Maintenant c’est beaucoup plus simple et il n’y a presque plus de point dure dans cette discussion.

Il me semble aujourd’hui logique qu’une nouvelle approche ait besoin d’être apprise. Nous disons toujours que Scrum s’apprend en se pratiquant. Logique alors que Scrum prévoit un prof embarqué.

Je faisais remarquer aux participants d’une PSD le mois dernier que l’on passe énormément plus de temps à lire du code qu’à en écrire. C’est pour cette raison, entre autres, que je leur conseillais d’investir dans la lisibilité du code. Une façon de faire ça qui fonctionne bien pour moi c’est d’écrire l’intention du test en langage naturel, puis de m’arranger pour faire compiler et passer ce que je viens d’écrire.

Un exemple ? Allez, un exemple…

Considérez le test suivant. Sans doute vous trouverez que j’exagère de montrer autant de choses qu’il ne faut pas faire, mais c’est pour l’exemple.

Le défaut de ce test qui m’intéresse aujourd’hui c’est que beaucoup de gens vont le lire plusieurs fois pour bien comprendre son intention. Si j’essaye de me concentrer sur l’intention du test, en tentant d’activer mon meilleur anglais, cela me donne envie d’écrire les choses plutôt comme ci-dessous.

A partir de là, je dis souvent aux participants “il ne vous reste plus qu’à placer les parenthèses et les points où cela vous arrange pour faire compiler tout ça”. Il y a bien sûr plusieurs façons de le faire et je ne vais pas m’étendre sur ce point. Juste mentionner que pour ma part j’aime bien le pattern builder et, en Java, les imports statiques. Cela peut par exemple donner le résultat ci-dessous.

C’est plus clair non ?

Sami m’a dit un jour quelque chose comme : “oublie les branches, pense graph”. Sur le coup j’ai compris intellectuellement cette phrase mais pas l’utilité pratique. Le temps passe et voici qu’un nouveau défi Git se présente à mon cerveau – c’est assez fréquent. Hier soir j’aurais exprimé le défi comme ça : je voudrais bien faire un cherry-pick d’un commit précédent dans ma branche, pourrais-je faire un merge et non un cherry-pick ? Un merge d’une branche sur elle-même ? Je m’endors là dessus et j’entends Sami de nouveau : “oublie les branches, pense graph”. Et cette fois ça me parle ! Et cela me pose une autre question : “What if…” je ne connaissais pas le commit en question mais uniquement son effet. David cette fois me parle à l’oreille : “bisect”. Cela fait plusieurs années il me semble que David me “rabâche” les oreilles en conférence avec ce bisect qui permet enfin de faire mieux que d’utiliser Git en première vitesse.

Je me réveille et là plus possible de dormir, il faut que j’essaye ça.

1. Merger une branche sur elle-même
2. Rechercher un commit

Merger une branche sur elle-même

Je conserve ce titre “merger” mais ce terme me semble de plus en plus inapproprié.

Donc, j’ouvre mon terminal préféré et je me lance :

1. Créer un nouveau répertoire suivi par git.
2. Repérer un commit en particulier. En pratique un code chat, du genre 3a68fd32ca3b16547c5abb2da52fdf7aed290ee3
3. Contredire le commit héros de cette histoire
4. git cherry-pick 3a68fd32ca3b16547c5abb2da52fdf7aed290ee3
5. Et là, “magie”

Bien sûr un git merge est sans effet puisque ce raccourcis de plusieurs commandes git se censure lui-même. Comme souvent quand on sait faire, la solution à mon problème d’hier soir semble triviale. Je le note quand même dans un petit blog pour pas oublier .

Rechercher un commit avec git bisect

Maintenant, j’imagine que je ne connais pas le commit que je cherche. En pratique dans mon exemple le commit en question ne fait que créer un fichier. Je veux trouver un commit qui crée ce fichier.

1. Créer un fichier shell qui teste si mon fichier existe.
2. initialiser git bisect. Je prends l’intervale le plus large : [HEAD premier-commit]
3. lancer le run: git bisect run search.sh

Et là c’est juste E-norme ! J’ai trouvé des tas de blogs sur bisect qui finissent comme ça : c’est E-norme. A croire que dans la vie d’un utilisateur de Git c’est une étape mentale qui mérite d’être criée au monde. Je ne résiste pas à l’envie de vous partager la copie d’écran du retour de git.

Parmi les points qui sont clefs à mon avis dans cette mise à jour il y a l’introduction de la notion de prévision faite au début de l’itération. Cela en a interpellé certains qui aimaient bien se raccrocher à cette idée répandue que “ok on fait du Scrum et on ne fixe pas un plan à 6 mois, mais, les gars, quand même, pour ces 3 semaines qui commencent, c’est quoi votre engagement, combien pouvez-vous prendre ?”.

Hmm…

Cette remarque m’inspire deux penseés…

1. … à propos des itérations en cascades :

Peut être avez-vous rencontré des équipes, moi beaucoup, qui reproduisent un processus de développement en cascade dans chaque itération. La plupart ont bien fait leur devoir et bien compris que chaque itération devait livrer un incrément terminé. Ils reproduisent alors à l’intérieur de chaque itération le processus en place pour livrer quelque chose de terminé, soit souvent un processus en cascade. Cela me semble une déduction logique.

Ce que je trouve décevant dans cette approche c’est que, certes l’horizon de planification est passé de plusieurs mois à une itération, mais le modèle mental est resté le même : une demande d’engagement forte sur le triplet date+budget+scope. Rien n’a en fait changé en profondeur dans notre compréhension du caractère émergent de l’activité créatrice du développement logiciel.

Cette interprétation erronée amène d’ailleurs des équipes à s’épuiser rapidement après quelques itérations. C’est écrit d’avance pour ces équipes qui reproduisent à chaque itération le stress de ce type d’engagement.

2. … et à propos de la qualité :

Malheureusement la qualité des logiciels construits dans cet état d’esprit ne s’améliore pas sensiblement dans cette situation. On continue à construire des fonctionnalités inutiles. On continue à avoir de nombreuses anomalies.

Oubliez Scrum ! Est-ce difficile de se rencontrer rapidement dans la journée lorsque vous en avez subitement besoin ? Le Daily Scrum vous permet de vous entraîner à cela pour que cela ne soit jamais un problème dans la journée.

Dan: Chez nous il y a deux personnes différentes qui gèrent les priorités et le budget. Il est impossible de trouver un Product Owner. Scrum ne marche pas chez nous, il faut l’adapter.

Oubliez Scrum ! Sur quels critères décidez-vous (de continuer) d’investir dans un développement ? Sur quels critères décidez-vous d’arrêter un développement ? Sur quels critères décidez-vous de libérer une version au marché ? Le Product Owner vous permet de vous entraîner à ces questions en se les posant à chaque itération.

Jude: Notre système est extrêmement complexe, inclus des dizaines de modules qui gèrent des centaines de millions de dollars. Il est impossible de livrer chaque itération un incrément potentiellement prêt pour la production. Scrum ne marche pas pour nous, il faut l’adapter.

Oubliez Scrum ! Combien de temps se passe-t-il entre le moment où votre client préféré à une idée géniale et le moment où vous lui livrer un (morceau de) logiciel qui lui permet de tirer profit de son idée ? Que faudrait-il faire pour diviser ce temps par 2 ? La livraison d’incréments terminés à chaque itération vous permet de vous entraîner à diminuer ce temps pour pouvoir être opportuniste, pour pouvoir saisir facilement les opportunités marché.

Oubliez Scrum ! L’objectif n’est pas Scrum. L’objectif est l’amélioration. Scrum vous propose plusieurs axes d’amélioration. Chaque outils de Scrum – Sprint, Product Owner, Equipe, Done, Retro, Revue, Planning, Vision, Product Backlog, etc – se concentre sur un thème précis. Ils sont conçus pour fonctionner ensemble. Ils sont difficiles à comprendre. Votre Scrum Master est là pour vous les enseigner.

Cela a encore été une bonne occasion d’apprentissage.

• Nous avons pris le temps d’explorer plusieurs manières d’exprimer nos tests : les  assertions basiques de NUnit, l’écriture d’une contrainte personnalisée.
• Nous avons évoqué le Broken Test Pattern avant la pause. Partir avec un test rouge avant la pause nous aide au retour à savoir où nous en sommes.
• Nous avons utilisé nos moments de refactoring pour introduire au maximum le langage du domaine qui faciliterait une conversation avec un expert du domaine.
• Chemin faisant nous avons créé de la duplication algorithmique et nous avons ressenti le dilemme entre payer cette dette et augmenter les capacités de notre code.

Cela a été une séance très agréable avec beaucoup d’interactions. Cela nous a tous donner envie de refaire une séance de ce type à l’automne.

Le lendemain matin, je me suis lancé dans un refactoring. Puis je me suis dit que j’aimerais connaître vos idées de refactoring. Quelles modifications ferriez-vous ? Bien sûr, il ne suffit pas de dire ce que vous ferriez, il faut le prouver avec du code.

Le code de départ est sur Github : le refactoring-challenge. Faites un ou plusieurs refactoring et partagez-nous vos réflexions et résultats.

Amusez-vous bien .

PO: what do you call commitment?

PM: the features they commit to deliver.

PO: how does this understanding of commitment help you?

PM: well actually it doesn’t…

…

PM: what do you call commitment?

PO: the Team and myself we commit to be transparent.

PM: what do you expect from this commitment?

PO: from the Team, typically two things. First, the Team will ask me if it needs help to clarify requirements. Second, the Team will only deliver done increments.

PM: what if the Team does not deliver anything?

PO: it means we failed to express my vision into product backlog items that the Team can turn into potentially shippable increments

PM: … and it breaks your plan!

PO: my plan is never broken, I change it to maximize the value of my product.

PM: what if you don’t find a better plan?

PO: I’m accountable for maximizing the return on investment. Sometimes the best business decision is to stop investing in a product.

Qu’est-ce que tu vois après Scrum ?

De mon expérience, lorsque quelqu’un me pose cette question, il s’attend à ce que l’on parle de la prochaine méthode, de la prochaine approche, du prochain outil. Il a souvent envie d’avoir un avis comparé sur toutes les méthodes ou techniques du moment. Je me souviens par exemple que c’est de cette manière qu’était posé le thème d’une table pendant un world-café Scrum avec l’intention d’étudier le buzz de l’époque sur le Kanban.

Aujourd’hui, ce n’est pas cet aspet de la question qui m’interpelle. Considérant Scrum comme un outil que l’on utilise pour découvrir ce que l’on a besoin de changer pour devenir meilleurs à développer des logiciels, la question de l’après Scrum m’incite à imaginer le monde lorsqu’effectivement nous serons devenus meilleurs à développer des logiciels.

Est-ce que tu imagines qu’alors nous n’aurons plus besoin de Scrum ?

Non car d’une part on peut toujours progresser, et d’autre part il faudra toujours former la relève.

Cette question de la formation des jeunes m’amène à considérer l’intégration de Scrum à l’enseignement universitaire non pas comme l’outil à apprendre mais comme un outil à utiliser au cours de la formation pour construire des équipes performantes. Ces universités, ou plutôt ces académies du logiciel, ne formeront plus des individus mais des équipes complètes capable de livrer un logiciel utile en un mois.

Le mouvement du software craftmanship qui étudie des modèles autour du compagnonnage nous donne des pistes pour repenser la formation continue autour du parrainage actif de ces nouvelles équipes par des professionnels d’expérience.

De son côté le lean startup explore des modèles de recherche de valeur en se basant sur des cycles d’apprentissage très rapide.

Plusieurs questions se bousculent. Que veux-tu dire par livrer un logiciel utile en un mois ? Pourquoi un mois ? J’ai en tête des systèmes qui ont mis des années à être construits, imagines-tu pouvoir les construire en un seul mois ?

Lol. Allons-y doucement.

Plusieurs pièces du même puzzle s’emboîtent pour moi très naturellement.

Une première pièce concerne la formation que l’on vient d’évoquer. Une autre concerne le mode de financement.

Le passage du Waterfall à Scrum a des impacts importants sur de nombreux aspects. Néanmoins, sur le terrain, le mode de financement est souvent resté le même. Je rencontre de nombreux cas dans lesquels des projets démarrent pour 12 ou 18 mois tout en disant qu’ils vont utiliser Scrum. Plusieurs éléments m’interpellent dans ces situations. Par exemple on parle alors souvent de projets, et non de produits. Ou encore, plus évident, on a déjà un plan et un financement pour plusieurs mois, ce qui me semble contradictoire avec une approche empirique, c’est à dire une approche qui considère que l’humain ne sait pas identifier ce qui sera une bonne idée dans 6 mois.

Imaginons maintenant une rupture plus nette. Un mois, un seul.

Cela nous invite à considerer un mode de financement différent. Dans ce mode, je ne finance que le premier mois et je mets en production l’incrément construit. Cet incrément ensuite génère lui même les bénéfices pour financer un autre incrément.

Cela suppose que l’on sache trouver de la valeur en un seul mois.

Oui. Et que l’on sache livrer un incrément terminé en un mois. C’est une invitation à aller au delà du potentially shippable, c’est une invitation à shipper.

Scrum est un outil pour être meilleur. Un outil pour s’entraîner à livrer un logiciel utile en un mois. S’entraîner à trouver la fonctionnalité utile. S’entraîner à construire un incrément terminé. Les deux.

Shipper plutôt que potentially shippable me semble puissant car dans sa recherche de ROI, le Product Owner doit mettre en production pour effectivement avoir accès au ROI. Sinon, ce ROI n’est que potentiel.

N’as-tu pas peur de perdre les avantages de l’empirisme dans cette idée de faire des itérations d’un mois ?

Je n’ai pas dit ça.

Vous vous rappelez sans doute que dans la première description de Scrum, Ken et Jeff parlaient de sprints d’un mois, plus exactement de 30 jours. On a tous interprété cela comme des itérations d’un mois. Et on continue d’ailleurs à traduire sprint par itérations et de parler de sprints ayant des tailles comprises entre 1 et 4 semaines. Il faut dire que cela a des côtés pratiques dans nos calendriers.

Si on cantonne la notion de sprint au container de 30 jours dans lequel l’équipe se dote d’un objectif de sprint, le sprint goal, et s’impose un niveau de qualité production, rien n’empêche l’équipe de faire des itérations à l’intérieur de ce sprint, par exemple d’une semaine.

Cela ouvre l’idée de livrer un logiciel en un mois, puis de s’arrêter pour attendre d’avoir de nouvelles idées. Ne penses-tu pas que les clients continueront à avoir envie d’ajouter immédiatement d’autres fonctionnalités ?

On parle de clients dans un futur avec des équipes capables de leur livrer en un mois un logiciel pour les aider à tirer profit de leur idée. Ce ne sont pas les clients que l’on connait aujourd’hui. Leurs états d’esprit n’est plus le même. Ils valorisent le feedback d’utilisateurs qui ont utilisé le logiciel en situation réelle. Parfois plusieurs semaines, plusieurs mois peut être seront nécessaires pour un feedback pertinent. Pour ceux qui sont dans ce cas, s’ils ont envie d’ajouter une fonctionnalité, ils ne voudront certainement pas l’ajouter immédiatement, ce serait trop risqué.

Reprendre un développement plus tard représente un risque, comment être sûr que l’on trouvera une équipe capable d’ajouter une fonctionnalité ?

Aujourd’hui on est déjà dans cette situation. Il n’y a pas de raison de penser que le monde va devenir plus simple. Il y aura toujours des incertitudes, elles ne feront que changer et probablement que nous ne pouvons pas aujourd’hui anticiper de quelles natures elles seraient dans ce futur.

On peut néanmoins anticiper que les équipes continueront à avoir des spécialités. Certaines choisiront par exemple les énormes systèmes à modifier en un mois pour ajouter une fonctionnalité clef. D’autres se spécialiseront sur les nouveaux logiciels sans héritage à inspecter et un nouveau domaine à explorer.

L’industrie continuera à progresser. Les techniques et les outils continueront à s’améliorer et les prochaines promotions feront en une semaine ce qui prenait un mois aux précédentes. Le parrainage permettra d’enrichir mutuellement les mondes universitaires et professionnels.

Le point clef est d’apprendre à livrer un logiciel utile en un mois. Les équipes ont l’embarras du choix pour s’entraîner. Le monde regorge d’associations caritatives qui pourraient bénéficier de leur travail. Un seul critère d’évaluation : que le logiciel soit utilisé.

Tu parles d’académies, de mettre au placard les développements de plus d’un mois, mais tu vois ça pour quand ?

Les progrès accomplis dans les 10 dernières années tels que je les comprends me font penser que cela mettra plus de 10 ans. J’aimerais que cela prenne moins de 20 ans pour pouvoir en profiter.

Cela semble ambitieux. Par où commencer ?

C’est la troisième pièce de mon puzzle : le chemin pour nous y rendre. Pour l’instant je n’en connais que le début bien sûr. Et encore, un début qui fait du sens pour moi.

Evidemment il faut continuer à s’entraîner car nous sommes loin de ce monde. Cela veut dire enseigner tout ce qui peut aider une équipe à livrer un logiciel utile en un mois. Je contribue à cette effort en donnant des formations sur les pratiques agiles.

S’entraîner cela veut dire aussi aider les équipes à mettre en place ce qui fonctionne pour nous et que nous enseignons. Je me concentre aujourd’hui sur deux activités clefs qui maximisent selon moi cette transmission. D’une part l’animation de dojos dans les équipes. D’autre part l’immersion dans ces équipes : un mois avec une équipe avec l’objectif de lui transmettre le plus de savoir-faire et savoir-être possible.

S’entraîner enfin c’est livrer des logiciels utiles en un mois. De nombreuses personnes ont des idées et voudraient trouver une équipe pour leur livrer un logiciel rapidement pour tirer profit de leur idée.

Donc si je comprend bien, ils n’ont qu’à te contacter.

Exactement .

]]> http://ericminio.wordpress.com/2011/06/03/apres-scrum/feed/ 3 ericmignot