Professionnal Scrum Foundations

Salut,

Nous (Vincent et moi) venons de donner deux sessions de la nouvelle formation PSF de scrum.org. Et je voulais partager avec vous ce que j’ai appris.

Les participants aiment les exercices de simulation pendant lesquels ils construisent du logiciel. J’ai donné des formations pendant lesquelles les participants construisent des prototypes papier. J’ai ressenti qu’ils préfèrent le logiciel. Cela améliore visiblement leur compréhension de comment utiliser Scrum dans leur projet. Cela augmente aussi la participation ; ils sont plus motivés à faire les exercices.

La mise en pratique d’un Scrum avec plusieurs équipes a beaucoup de valeur pour les participants. Pendant la PSF, la quatrième itération – pendant la seconde après-midi – impose aux participants de mettre en commun leur travail pour construire un site internet portail de leurs différents produits. Les échanges sur les différentes stratégies d’intégration sont beaucoup plus profonds que dans une formation théorique car les participants sont riches de cette mise en pratique.

La PSF est plus pertinente que la PSM pour les équipes qui débutent avec Scrum. J’ai donné beaucoup de PSM. Elle n’est pas faite pour les débutants. La PSM se concentre sur la compréhension de Scrum nécessaire à un Scrum Master. La PSF aborde tous les rôles de Scrum de façon plus équilibrée. Les Product Owner, Team et Scrum Master ainsi que toute personne qui est ou sera en contact avec une équipe Scrum trouveront dans la PSF ce dont ils ont besoin pour commencer: des réponses à leurs questions commençant par « comment ».

Classes ouvertes en ruby

Le kata du mois dernier proposé par @12meses12katas m’a encore appris quelque chose. C’était la première fois que je faisais en Ruby le kata bowling. Comme d’habitude je voulais passer sous les 10 minutes avec un code et des tests avec lesquels je sois confortable, c’est à dire qui communiquent leurs intentions d’une manière que je pourrais encore comprendre l’année prochaine.

J’ai commencé par écrire des tests qui ressemblaient à ceci:

describe Bowling do
    specify "spare" do
        claire.sheet = "1/------------------"
        claire.score.should == 10

        claire.sheet = "1/2-----------------"
        claire.score.should == 14
    end
end

J’ai continué tranquillement avec le kata et lorsque j’ai fait passé les tests avec les cas plus complexes avec des spares et des strikes j’ai regardé mon chronomètre et j’ai pris une baffe: 24 minutes. J’ai recommencé plusieurs fois, j’ai posé mon scénario sur une feuille, pour arrêter de perdre du temps à calculer les résultats attendus, j’ai utilisé un raccourcis clavier de plus pour introduire une variable dans RubyMine, j’ai tapé sur mon clavier comme un fou, j’ai mis une table dans les tests, et j’ai péniblement atteint 18 minutes. Bof.

Puis je me suis rappelé du kata des chiffres romains de @jacegu du mois dernier et j’avais bien aimé ses tests qui utilisaient une extension de la classe Fixnum. Alors j’ai essayé de mettre ça en pratique et cela donnait des tests assez différents:

describe Bowling do
    specify "spare" do
        "1/------------------".scores(10)
        "1/2-----------------".scores(14)
    end
end

J’aime mieux cette version des tests qui se concentrent sur le problème à résoudre et supprime le bruit. En plus cela m’a permis de baisser le chrono :).

« a working proposal » : semaine 3/3

C’est toujours émouvant pour moi d’arriver à ce qui semble être la « fin » d’une aventure. Depuis 3 semaines nous avons eu cette journée en point de mire. La construction de cette offre autour d’un logiciel qui fonctionne chaque semaine a été le fil rouge qui m’a guidé dans une foule d’autres activités.

Ce que j’ai aimé dans cette expérience:

• binômer avec Xavier
• avoir un fil rouge parmi une foule d’autres activités

Pour que cela soit parfait, faudrait-il que notre prospect décide de poursuivre ou bien est-ce que cela va chercher ailleurs ? Cette idée de « gagner la propale » dans le future rend-elle meilleure l’expérience passée ?

Comme on nous l’a dit souvent, c’est plus l’aventure, le parcours qui nous rend heureux, moins que la destination. Alors je n’ai pas d’idée pour améliorer l’aventure ; le logiciel oui 😉

« a working proposal » : semaine 2/3

Deuxième semaine de notre aventure de construction logiciel en parallèle de la mise au point de notre offre de développement. Bien sûr cette semaine s’achève avec une revue d’itération et une rétrospective.

C’est l’occasion pour nous de faire le point sur notre incrément, le produit dans son ensemble, notre compréhension actuelle d’une stratégie incrémentale pertinente pour atteindre les objectifs visés. Pour cela nous nous sommes retrouvés autour du second incrément déployé sur Heroku, autour de notre Product Backlog et de notre propale.

La semaine dernière nous n’avions pas partagé avec notre prospect l’incrément réalisé. Cette semaine c’est différent. Maintenant que nous avons deux incréments, nous avons de quoi démontrer ce que veut dire « construire un logiciel par incréments successifs ». Il se trouve que notre prospect n’a jamais travaillé de cette manière. La semaine dernière nous avions décidé de déployer certes mais sans le lui dire. Notre sentiment était que la notion d’incrément risquait d’être très théorique à ce stade. Maintenant nous avons deux incréments, avec des adresses distinctes. On peut donc voir concrètement l’ajout de fonctionnalités entre les deux versions. Quel sera son feedback ? Suspence…

« a working proposal » : kick-off

Lundi matin nous avons fait un sprint planning un petit peu particulier. Je voulais partager ça avec toi cher lecteur :).

Nous travaillons à construire une offre pour un développement logiciel. « Bien sûr », en tant qu’infecté par l’agilité nous nous concentrons sur le « working software » et adoptons une démarche empirique. Sachant que nous avons un délai de 3 semaines ça a été naturel pour nous de partir sur 3 itérations de 1 semaine chacune. Chaque semaine nous allons construire un petit morceau du logiciel et d’autres choses autour ; par exemple le document très officiel de l’offre en elle même qui décrit notre démarche pour la suite.

Les étoiles se sont alignées pour nous aider. Nous avons pu passer une journée entière à faire du story mapping avec le client et nous avons pu voir le système actuel.

Maintenant nous avons démarré notre première itération sur cette offre. Qu’allons nous apprendre sur le domaine de ce client ? Qu’allons nous livrer ? Suspense…

#scrum release burndown chart

PM: I want to see increase the velocity of the Team
PO: I want to see decrease the remaining work

PM: If the velocity increases, the remaining work will decrease
PO: No, new work could be added at the same time

PM: I don’t like when the Team updates an item with a smaller effort estimation because the velocity could decrease
PO: I like when the Team updates an item with a smaller effort estimation because the remaining work decreases

PM: You don’t track the velocity in a velocity chart?
PO: No, I track the remaining work in a release burndown chart

Kata @onf

Du nouveau dans l’équipe web @onf. On avait déjà fait des randoris et nous avons commencé les katas. Comme l’exercice était nouveau pour l’équipe, nous avons emprunté une structure d’atelier tdd. L’atelier que j’avais en tête était la session de craftsmanship de @slagyr lors du Scrum gathering à Orlando début 2010.

Pendant une rétrospective, l’équipe avait décidé d’explorer les katas le lundi suivant. Je leur ai proposé la structure suivante, répartis sur 1h45:
– 15mn : on regarde une vidéo de kata. En l’occurrencehttp://vimeo.com/16935085
– 45mn : chacun pratique seul ce kata dans le langage de son choix.
– 15mn : pause
– 15mn : quelqu’un se lance et fait le kata devant tout le monde
– 15mn : feedback du public au démonstrateur sous la forme d’un jeu de la perfection

Pendant la pratique, la consigne est de réussir à trouver un chemin qui puisse être parcouru en moins de 15mn.

Etant à l’ONF, Office Nationnal du Film canadien, les analogies évoquées par l’équipe après l’exercice ont tourné autour du film. La personne qui fait le kata s’est retrouvé tantôt réalisateur tantôt héros malheureux malgré lui. Les tests plutôt dans le rôle de l’agresseur. A un moment, un copier/coller malheureux s’est retrouvé être le méchant de l’histoire. Le public l’avait vu, pas le héros…

Ce que j’ai aimé avec cette analogie proposé par l’équipe et nouvelle pour moi c’est l’idée consistant à voir le kata comme un film dans lequel le scénario est autant important que le dénouement, voir plus important. En effet traditionnellement dans un kata, le héros gagne à la fin ; peu de suspence de ce côté. Le public est sensible au scénario, au chemin incrémental choisi par le réalisateur, et apprécie un tableau final original et des émotions fortes en cours de route.

Cela m’a donné envie de scénariser plus mes katas en empruntant des chemins dangereux, en revenant en arrière, … pour finalement gagner tout de même à la fin ;).

Software for your head

J’ai recommencé à lire ce livre

Définir « Terminé »

Résumé
Les axes de réflexion que je considère pour construire une définition de Terminé :

• qualité externe
• qualité interne
• autorisations
• déploiement
• exploitation

Lorsque je travaille avec une équipe à établir ou modifier notre définition de « Terminé » (le Done de Scrum), je ne leur propose pas d’exemple comme point de départ de la discussion. Par contre je leur propose les différents axes de réflexion dans lesquels nous allons identifier les points pertinents pour eux.

Pour démarrer la discussion, je propose de commencer par explorer les axes qualitatifs :

• qualité externe
• qualité interne

Qualité externe
Cette notion de qualité externe nous parle de notre capacité à construire le bon logiciel, celui qui rend les services souhaités, à un niveau de performance satisfaisant, à un niveau d’ergonomie qui fluidifie sa prise en main et son utilisation. C’est la qualité perçue lorsqu’on utilise le système.

Pendant cette réflexion, nous partageons alors comment nous comprenons cette idée de qualité externe et nous décidons quels types de tests nous souhaitons construire notre confiance dans notre code : des tests automatiques qui exercent le système dans son ensemble avec des données réalistes, des tests qui spécifient les conditions aux limites des services rendus, des tests de performance, des tests de sécurité, des tests de traduction, …

La question des anomalies est parfois abordée à ce moment dans la discussion. Cette discussion peut être difficile parce que chargée d’un historique peu flatteur pour les programmeurs. On distingue ici deux types d’anomalies: les anomalies que l’on découvre après la mise en production et celles que l’on connaît avant la mise en production.
Pour les premières, il s’agit de définir comment nous allons les prendre en compte, c’est à dire comment leur découverte va impacter le travail en cours. La démarche stop the line du Lean est la démarche la plus cohérente avec une approche empirique, même si elle représente des défis importants.
Pour les secondes une attitude cohérente avec ce que l’on vient de dire consiste à ne jamais déployer un système avec des anomalies connues. Cela demande souvent beaucoup de courage dans des environnements qui ont malheureusement appris à supporter des systèmes avec beaucoup d’anomalies.

Qualité interne
Cette notion de qualité interne nous parle de notre capacité à construire correctement un logiciel. Par correctement, on entend ici un logiciel que l’on peut faire évoluer durablement. Plusieurs outils aujourd’hui sont capables de construire des indicateurs qui, lorsqu’on les améliore, nous aide à construire un logiciel que l’on peut faire évoluer durablement. Par exemple le pourcentage de couverture de code par des tests unitaires et d’intégration, la compléxité cyclomatique, le taux de duplication… Certains outils, comme Sonar, vous permettent même assez simplement d’implémenter votre propre règle.

Les tests automatiques sont des indicateurs de qualité assez simples à construire car ils se basent sur une analyse statique du code, c’est à dire sur une photo du code à un instant donné. Or il se trouve que l’on a constaté que le fait d’écrire un test avant d’écrire le code de production qui le fait passer a un impact majeur très positif sur la qualité du logiciel construit. On parle ici d’un indicateur de qualité dynamique qui nous renseigne sur la manière dont le logiciel a grandit. La plupart des équipes mettent en place cette idée simplement en ayant la discipline de toujours écrire un test avant d’écrire du nouveau code.

Vient ensuite, dans l’ordre chronologique des étapes à passer pour être prêt à déployer un système en production, la question des autorisations nécessaires.

Autorisations
Certaines industries contrôlées imposent aux créateurs de logiciels de faire la preuve de certaines caractéristiques dans un format imposée par une convention. C’est le cas par exemple dans l’avionique ou la pharmacie, pour en citer deux à priori assez éloignées. D’autres normes, internes celles-ci s’imposent parfois aux équipes.

La plupart du temps, ce besoin d’autorisation déclenche la rédaction de document dans un format souvent imposée à l’équipe. Le travail récurrent d’une itération à l’autre consiste alors selon les cas à les créer ou bien à les tenir à jour.

Déploiement
Le déploiement par incréments successifs suppose que plusieurs déploiements vont être effectués pour mettre à jour un système. Dans ce contexte, il est pertinent de ne pas considérer le premier déploiement comme un cas particulier mais bien comme le déploiement d’un incrément qui part d’un état précédent vide.
Des éléments de différentes natures sont à considérer. Sans ordre d’importance, on peut citer : un moyen d’interdire l’accès au système pendant le déploiement du nouvel incrément, la modification de l’environnement, la modification des configurations réseaux, la modification de la structure de données, la migration des données, … Disposer de tests automatiques de déploiement s’avère encore une fois très utile pour être capable de déployer chaque incrément sans détruire le système déjà en place.

Exploitation
Ce qui précède concerne la préoccupation de mise à jour d’un système existant. Il faut aussi considérer les activités qui tournent autour de l’utilisation du système en place. Selon les cas il s’agit de choses aussi variées que des scripts de redémarrage, la formation des utilisateurs, la formation des équipes travaillant à la hot-line du système, …

Si le développement incrémental est nouveau pour vous et que vous avez des difficultés à établir votre définition de Terminé avant de commencer, rassurez-vous c’est normal. Explorez pendant une première discussion les différents axes de réflexion qui vous semblent sensés et établissez vos premiers indicateurs en fonction de la vision du produit. Faites une itération et pendant la revue d’itération posez vous la question: est-on prêt à déployer cet incrément en production ? Si oui, faites le. Si non, améliorez votre définition de Terminé pour la suite.

« S’engager »

Pendant un planning d’itération, il est commun de demander à l’Equipe de fixer/choisir/établir son “engagement”. Et la plupart du temps, le comportement attendu consiste à choisir un ensemble de fonctionnalités à livrer au client à la fin de l’itération qui commence ce jour là. Dans Scrum, ce rituel de planning se répète à chaque commencement d’itération.

Pendant l’itération, c’est le temps de la réalisation. C’est là que les artistes-artisans informaticiens réalisent le miracle de leur art pour livrer un morceau de logiciel d’une qualité exceptionnelle. Hum… Mais au fait, c’est quoi pour vous la Qualité ? Autour d’un café on devrait probablement s’entendre sur le fait que des professionnels de l’informatique devraient livrer des logiciels de qualité. Voire, que leur “engagement” a quelque chose à voir avec “livrer un logiciel de qualité”.

Durant les dix dernières années, une technique appelée TDD s’est développée. J’imagine que vous connaissez ça très bien, ainsi que sa représentation la plus populaire :

La couleur pour le côté du refactoring est parfois le vert pour exprimer que pendant une opération de refactoring, “les tests passent toujours”. J’ai pris ici le gris surtout parce que sur ma magnifique casquette tdd, le refactoring est en gris.

Mais au fait : quelle est la vocation du refactoring ? Parce que si le test passe, je pourrais livrer le code et n’en parlons plus ! Bien sûr la plupart du temps le logiciel n’est pas fini ; il faut continuer. Pour pouvoir continuer, on met à profit ce temps de refactoring pour transformer le code que l’on a écrit à la va-vite pour faire passer le test en un “code de qualité”. L’objectif semble donc être la qualité. Autrement dit, l’artiste-artisan informaticien professionnel construit un code de qualité pendant le refactoring. Encore autrement dit : l’artiste-artisan informaticien respecte son engagement de qualité pendant le refactoring.

Maintenant si je dessine le cycle du TDD plutôt comme ça, est-ce que vous me voyez venir ?

En mélangeant les notions d’engagement du planning d’itération et de refactoring du tdd, on pourrait vivre la situation suivante : pendant un planning d’itération, l’Equipe considère les premiers éléments de carnet de produit, écrit les tests et les fausses implémentations qui font passer les test, et réfléchit à son engagement : quel part du code écrit pendant le planning pouvons-nous transformer en code de qualité pendant l’itération ? Par exemple pendant le planning on a fait passer 4 tests mais notre engagement ne couvre que la livraison du code faisant passer les 3 premiers.

Cette approche met au premier plan les notions de qualité et de professionnalisme des équipes on affichant que la valeur des professionnels de l’informatique va se chercher pendant le refactoring. “Pisser du code” ne s’appliquerait plus qu’au code écrit le plus vite possible pendant le planning pour faire passer les tests, pas au code que l’on livre.