It’s OK to figure out murder mysteries, but you shouldn’t need to figure out code. You should be able to read it.
Steve McConnell
Étiquette : McConnell
Retours sur Agile France 2013, dernière partie (en images)
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 :
- 1ère épisode : le début de matinée
- 2ème épisode : de la fin de matinée au début d’après-midi
- 3ème épisode : la fin d’après-midi
Pour le vendredi :
- 4ème épisode : la matinée
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 :
- Software Estimation, par Steve McConnell
- Expert Political Judgment, par Philip Tetlock
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 :
- Par Jamel Ghechua, sur le Blog d’Objet Direct
- Par Yannick Grenzinger sur le blog de Xebia ; ici c’est d’avantage un entrefilet…
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 !
Vous trouverez la présentation de Remy-Christophe ici.
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 !
Note de lecture : Software Project Survival Guide, par Steve McConnell
Note : 5 ; Une approche seulement à demi itérative plutôt décevante
Steve McConnell fait partie des auteurs que je lis systématiquement, ce faisant j’ai fort peu de chances d’être déçu. C’est hélas le cas ici ! Pour « survivre » McConnell nous propose d’adopter le « stagged delivery », sorte d’approche à mi-chemin du mode itératif « time-boxed », sans toutefois lui être équivalent. Sans être à coté de la plaque, on sent que ce livre est antérieur aux publications sur les approches agiles : ici, on s’appuie beaucoup sur de la formalisation, je serais curieux de voir si l’auteur maintiendrai aujourd’hui ses positions, ou si il intègrerait ce nouvel éclairage. Au final, l’approche est assez proche du RUP, sans s’en réclamer. On reste sur sa faim.
L’ouvrage, en lui-même, est divisé en quatre sections principales :
- The survival mind-set : Cette partie nous amène à prendre con science de plusieurs facteurs: quel est notre niveau de maturité actuel ? Quelles sont les compétences nécessaires et les facteurs clés de succès des projets.
- Préparations : Cette section balaye les disciplines d’ingénierie des projets: gestion des exigences, architecture, assurance qualité, etc. L’auteur expose ici des vues particulières : utilisation intensive de prototypes dans la capture des exigences, gestion et contrôle des changements explicites via des CCBs, etc.
- Succeeding stage by stage: On suit ici les phases de réalisation du projet. C’est certainement un des aspects les plus “vieillots” du texte, où l’on parle conception détaillée, précédent l’implémentation, elle-même précédant d’abord les tests puis le déploiement.
- Mission accomplished: Cette partie indispensable couvre la rétrospective de projets.
Autant j’ai pu être ébloui par « Rapid Development » et son incroyable richesse, autant celui-ci m’a déçu. Evidemment tout est relatif, le contenu reste extrêmement pertinent et Steve McConnell reste un auteur très solide, ce qui justifie cette note franchement moyenne.
Référence complète : Software Project Survival Guide – Steve McConnell – Microsoft press 1998 – ISBN: 1-57231-621-7
Note de lecture : Software Estimation, Demystifying the Black Art, par Steve McConnell
Note : 8 ; Steve McConnell frappe encore!
Les ouvrages de Steve McConnell sont parmi les seuls que j’achète sans les ouvrir : quand je vois un nouveau titre, je ne cherche même pas à savoir ce qu’il y a à l’intérieur, j’en fais juste l’acquisition ! Celui-ci, colle à l’accoutumée (ou presque) et ne m’a pas déçu.
McConnell différencie l’art de l’estimation et la science de l’estimation. La « science », ce sont les méthodes d’estimation permettant, à l’aide de formules, d’euristiques et de facteurs d’ajustement d’obtenir des chiffrages de projet ; les approches telles que FPA et Cocomo II se rangent dans cette catégorie. Ce livre traite de l’autre partie : l’art de l’estimation.
La première partie est consacrée aux concepts de l’estimation. Cette partie est particulièrement précieuse pour comprendre et justifier les facteurs d’incertitude, les facteurs influençant les estimations et les sources d’erreur.
La seconde partie constitue le cœur du livre, puisque l’auteur y livre son approche des estimations. Celle-ci est basée sur un simple processus : compter, calculer et juger. Autour de cette approche, Steve McConnell développe plusieurs techniques, telles que l’utilisation de données historiques, le jugement d’experts, l’estimation par analogie ou en groupe.
La dernière partie se focalise sur les challenges particuliers de l’estimation : estimer la taille, évaluer l’effort associé et estimer une planification. Au-delà des estimations elle-mêmes, le problème le plus souvent rencontré est la présentation des résultats et le traitement des problèmes politiques entourant les estimations.
Les estimations sont un problème épineux, peu d’ouvrages traitent ce problème. Ceci fait de ce livre un ouvrage particulièrement précieux sans être inutilement compliqué. C’est pour cela que je conseille ce livre sans réserves aucune.
Référence complète : Software Estimation, Demystifying the Black Art – Steve McConnell – Microsoft press 2006 – ISBN: 0-7356-0535-1
Note de lecture : Professional Software Development, par Steve McConnell
Note: 8; Comment faire du développement logiciel une profession… et une carrière!
L’informatique constitue-t-elle une véritable profession d’ingénierie ? C’est à cette difficile question que tente de répondre Steve McConnell dans ce livre. Le constat initial est plutôt sévère, c’est l’objet de la première partie du livre. Les pratiques d’usage les plus répandues sont encore et toujours le « code and fix » et le noyau de connaissances universellement partagé par les professionnels reste considérablement plus faible que dans les disciplines d’ingénierie classiques établies de longue date. Ce constat amène l’auteur à considérer deux dimensions à la mesure de maturité de la profession :
- Le corpus de connaissance : il se décline en un noyau stable (pour lequel la demi-vie des connaissances est de 50 ans) et un « body of knowledge », plus large, dont la demie-vie est de 10 ans.
- Les éléments statutaires de la profession : certification, code d’éthique, sociétés professionnelles (telles que IEEE et ACM), développement professionnel, licences et accréditations.
Le second thème développé par l’auteur est le « professionnalisme individuel », où comment, à titre individuel, s’engager dans une voie de développement personnel. Là encore l’auteur présente ce développement en étapes, depuis le « mode héros », auquel succède la prise de conscience, le partage au sein de communautés, l’étape la plus haute étant le partage par la publication de textes.
Après le professionnalisme individuel, viennent les organisations professionnelles : comment structurer, favoriser la montée en compétence et la reconnaissance du professionnalisme des membres d’une organisation ? Plutôt que de passer en revue les chapitres de cette partie, intéressons-nous plutôt au « Construx Professional Development Program ». Dans ce programme de développement que l’auteur a mis en place dans sa propre société, les consultants sont évalués et évoluent sur des échelles de compétences par discipline d’ingénierie. Ces disciplines d’ingénieries sont définies au sein d’un organisme, le Swebok (Software Body Of Knowledge, émanation de l’IEEE). Il définit une échelle allant de 9 à 15, 10 “knowledge area” déclinés en 4 niveaux (introduction, compétence, leadership et maitrise). Chaque étage de l’échelle définit le nombre de KA pour lesquelles il faut avoir l’un des 4 niveaux. Cette échelle permet de définir des plans de progression professionnelle, définissant les actions à mener, les formations à suivre, etc..
Si cet ouvrage est surtout une source de réflexion plus profonde sur ce que veux dire ou devrait vouloir dire être un professionnel de l’informatique. Il établit les bases de ce que devrait être une véritable reconnaissance de l’informatique en tant que profession. Et c’est là une réflexion que devraient mener toute société de service informatique. Il est clair que nous en sommes loin.
Référence complète : Professional Software Development – Steve McConnell – Addison Wesley 2004 – ISBN: 0-321-19367-9
