Dernière ligne droite pour cet Agile France 2013 !
Pour ceux qui n’auraient pas suivi les épisodes précédents, nous avons :
Les épisodes du Jeudi :
Pour le vendredi :
Projetons-nous directement au début d’après-midi où nous avons rendez-vous avec …
Laurent Bossavit : L’art d’avoir tort
Il manquait à notre main la quatrième carte de mon carré d’as. La voici. Il ne devrait pas être la peine de présenter Laurent Bossavit qui fut non seulement un des membres fondateurs de cette conférence, mais aussi une des figures marquantes de l’agilité en France depuis 12 ans ! Evangéliste, auteur, infatigable chercheur et bien d’autres choses encore, il est aussi à l’origine de l’institut Agile qui est aujourd’hui, selon ses propres mots, plus un hobby qu’un travail.
Laurent nous promet pour cet atelier :
- 3 exercices interactifs (en fait, nous n’en ferons que deux, pour des questions de temps).
- 1 super-pouvoir
- 2 sites Web
- 1 page de pub
Commençons par une question: pourquoi la question des estimations donne-t-elle lieu à tant de discussions enflammées (pour ne pas dire plus) ? Parce que l’on voir le monde en noir et blanc !
Le but de cet atelier est de sortir de ce mode de pensée binaire pour rentrer dans une logique probabiliste. C’est aussi grâce à ce mode de pensée que l’on va pouvoir se diriger vers une logique d’amélioration en travaillant sur nos intervals de confiance.
Assez pour l’introduction. Au boulot !
1er exercice
Ce premier exercice est largement inspiré d’un exercice de Steve McConnel extrait de cet ouvrage. L’objectif est de donner des réponses aux questions posées avec un interval de confiance de 90%. Allons-y !
En tant qu’informaticiens aguerris, nous savons que nous avons tendance à être optimistes. Plus amusant : en sachant cela et sachant même que l’exercice veut montrer cela, nous donnons dans le panneau. En relevant les copies, l’interval que nous avons voulu de 90% se révèle plutôt être de 50%. Votre serviteur n’a pas échappé à la chose : je n’ai réussi qu’un médiocre 5/10 !
Quel est notre problème ? C’est ce que Laurent appelle un “problème de calibration du hardware” !
Connais-toi toi-même
Voilà donc où il faut travailler : apprendre à connaitre notre propre cerveau : MON incertitude m’intéresse plus que les faits !
Dans son ouvrage “Expert Political Judgment”, Philip Tetlock présente des tests de pronostiques politiques auprès d’experts mondiaux reconnus. Les résultats parlent d’eux-mêmes:
- 15% des évènements qualifiés “d’impossibles” par ces experts ont effectivement eu lieu.
- 27% des évènement jugés par ces mêmes experts “d’absolument certains” ne se sont pas produits.
Le problème est un problème de calibration de l’écart de confiance. Dans le principe, il est facile à adresser: il suffit d’élargir l’interval de confiance !
Calibration = %confiance – %fausses réponses
Second exercice
Dans ce second exercice, Laurent nous propose une série d’affirmations. Nous devons nous prononcer sur celles-ci avec un pourcentage de confiance. On jauge nos réponses en utilisant le “score de Brier” originellement utilisé en météorologie. On obtient le moins de points en donnant réponse juste avec un pourcentage de confiance élevé, mais un maximum de points dans le cas contraire.
Le but est d’obtenir le minimum de points. On peut connaitre notre capacité de résolution à partir de là :
Résolution = %réponse vrais / %réponses fausses
En fait, ces deux exercices nous guident vers des directions qui peuvent paraître divergentes :
- Je suis bien calibré : je ne me mouille pas dans mes estimations
- Je veux m’améliorer en résolution : je dois me mouiller.
En travaillant sur ces deux fronts, nous allons acquérir notre super-pouvoir : SuperGeek !
Conclusions et références recommandée
Pour aller plus loin, il faut travailler, comme toujours ! Laurent nous propose de le faire via deux sites :
- Pour enregistrer et suivre nos prédictions : predictionbook ; ça, c’est pour l’approche “fun”.
- Philip Tetlock mène des études très sérieuses à l’aide de groupe de travail. On peut s’y joindre sur goodjudgement mais c’est visiblement assez prenant.
L’un des effets de bord positif de cet approche, de l’expérience même de Laurent, est qu’elle permet de prendre de la distance par rapport à un évènement à venir. Dans le cas de Laurent, un jugement au tribunal !
Quelques références bibliographiques :
C’est vrai, Laurent nous avait aussi promis une page de pub ! Elle concerne son livre paru sur LeanPub
Pour finir, qualques posts sur la même présentation, faite cettefois-ci lors du ScrumDay :
Alfred Almendra : Un peu d’UX pour innover efficacement
Alfred nous propose un atelier pour imaginer un MVP à la Lean Startup, en utilisant un peu d’UX !
Cet atelier est inspiré d’un atelier réalisé par Ariadna Font. Nous allons avoir un temps très limité pour réaliser une première ébauche de notre MVP. Plutôt qua de rentrer dans de longues explications, jetons-nous dans le bain ! 6 étapes en tout et pour tout. Et ça rigole pas ! Enfin si, quand même un peu…
Etape 1 : La carte d’empathie
On avait le choix entre deux sujets. Je suis très fier d’avoir convaincu les personnes de mon groupe d’avoir choisi un autre sujet : nous allons réaliser Funky Shirt, un service permettant de réaliser des chemises uniques et custosmisées … et bien sûr, Funky !
La carte d’empathie nous permet de parler aux émotions : ce qu’on pense et ressent, ce que l’on entend, ce que l’on voit, ainsi que les problèmes et les besoins. Nous avons 10 minutes pour cela. C’est un peu court et c’est un peu le rush.
Etape 2 : Le pitch
En utilisant le fameux “elevator statement. Il pouvait servir de base à notre pitch … ou nous pouvions utiliser autre chose. C’est ce que nous avons fait. La clé étant de mettre en avant la proposition de valeur essentielle et l’aspect différenciant.
Les 10 minutes étaient aussi un peu serrées, mais c’était déjà moins la panique qu’à l’étape précédente.
Etape 3 : Prototypage
C’est une application mobile ! Donc à nous de réaliser la "landing page” de cette application, plus une ou deux autres. Mais si possible une seule autre. 15 minutes pour ça !
Etape 4 : Test utilisateur
Une personne de chaque groupe va tester l’application d’un autre groupe. Elle se tient à bonne distance, le groupe reste silencieux et observe le testeur. Celui-ci décrit à haute voix ce qu’il observe et la façon dont il réagit.
Etape 5 : Prototypage
Sur la base de ce feedback, nous avions le droit de faire 1 modifications. En fait, on en a bien fait 2 ou trois. Hum… 5 minutes de modifications et nouveau cycle de feedback !
Etape 6 : Test utilisateur
Cette fois, c’est moi qui fait le beta testeur sur un autre MVP. Une ergonomie meilleure que chez nous, je dois dire …
Ce que j’en ai pensé
J’aime bien l’idée de ces ateliers en cycle court. Cet atelier-ci était probablement un peu surpeuplé pour qu’Alfred puisse en faire une facilitation efficace. J’ai bien aimé que nous ayons essayé de développer une idée originale ! Je retiens toutefois que :
- On pouvait essayer de travailler sur une idée existante, pas nécessairement super-originale et faire quelque chose de potable dans le timing.
- Ou l’on pouvait essayer d’être beaucoup plus original et alors le timing devenait un peu plus contraignant.
Bien sûr, la seconde idée me semble plus porteuse, mais il aurait fallu 1,5 ou 2 fois plus de temps…
En prime, voici le support d’ariadna Font dont Alfred s’est inspiré.
Remy-Christophe Schermesser : Tester autrement, le guide du testeur intergalactique
Ca sent la fin de cet Agile France : j’ai eu du mal à me décider sur la dernière session. Et en plus j’arrive en retard, largement en retard. L’orateur a commencé depuis un bon moment.
Remy-Christophe nous propose de nous détacher un moment de nos problématiques de langage “tel langage se teste mieux que tel autre…” et de reflechir à l’expressivité de nos tests.
JUnit, c’est bien mais on en atteint rapidement les limites, surtout en terme de lisibilité. Et surtout en terme d’expressivité quand on veut tester un comportement.
Il y a-t-il un espoir de ce côté ? Oui, il s’appelle RSpec ! Le DSL de RSpec permet de décrire ce qui est attendu !
Autre problème : le test des combinatoires. Nécessiare à une bonne couverture, il l’est aussi au traitement des différents cas sur les tests fonctionnels. La réponse s’apelle ici : mutations ! Ecrire un test et le faire muter, cela peut se faire avec Javalanche. La création de ces mutants peut toutefois conduire à des explosions combinatoires allongeant de manière exagérée la durée d’execution des tests. Il faut tuer sans pitié les combinaisons inutiles ou redondantes.
3ème volet : le property testing. ScalaCheck permet la génération automatique de cas de tests en se basnt sur la description des propriétés au sens mathématique du terme ! A n’utiliser que pour les sections de code critique, car là aussi l’inflation des temps d’execution des tests nous guette au tournant !
This is the end
Ici s’achève pour moi l’édition 2013 d’Agile France où j’étais présent cette année en touriste. J’aimerais l’être moins l’an prochain, nous verrons ce que l’édition 2014 nous réservera !
Software Freethinker 
