The computer can’t tell you the emotional story. It can give you the exact mathematical design, but what’s missing is the eyebrows.
Franck Zappa

The computer can’t tell you the emotional story. It can give you the exact mathematical design, but what’s missing is the eyebrows.
Franck Zappa
Note : 7 ; Thumbs up sur le goal-directed design, thumbs down sur le processus.
Il s’agit là du livre de référence sur les Persona. Mais en fait l’ouvrage couvre bien plus largement la question de la place du design dans la conception des produits. Un propos qu’il faudra relativiser avec son écriture au début des années 2000 et même de la findes années 90, car il s’agit en fait d’une édition révisée.
C’est certainement moins vrai aujourd’hui, grâce en partie à cet ouvrage. Le père du Visual Basic nous gratifie ici d’un ouvrage de près de 250 pages découpé en 14 chapitres. Le nombre apparemment élevé de chapitres est bienvenu car il s’agit presqu’uniquement de prose ! L’ensemble est structuré en 5 parties. La première, intitulée « computer obliteracy » couvre 40 pages avec 2 chapitres. Le premier « riddles for the information age » nous propose de regarder les objets qui nous entourent pour constater à quel point l’électronique les a envahis … et à quel point notre expérience avec ces objets s’est dégradée. La phrase clé du chapitre est : quand vous croisez un objet (quel qu’il soit) avec un ordinateur, le résultat est un ordinateur ! Au second chapitre, il est question d’apologistes, de survivants et d’ours qui dansent. L’interaction avec les logiciels s’apparentent aux ours qui dansent : on s’émerveille de ce qu’ils font, mais tout bien considéré, en fait un ours ça danse terriblement mal ! Les apologistes sont les développeurs : ils imaginent que parce qu’ils sont capables de d’utiliser un ordinateur à la geek, les utilisateurs le seront ! Ces derniers s’apparentent souvent à des survivants : Bien qu’ils soient tourmentés par un système qui se comporte pour eux en dépit du bon sens, ils se conforment pour pouvoir faire leur boulot. Les deux chapitres sont de purs régals.
La 2ème partie « i twill cost you big time » regroupe 3 chapitres sur 40 pages. Le chapitre 3 « wasting money » couvre 17 d’entre elles. On y comprend que l’agilité, ce n’est pas son truc à Alan Cooper. Exhortant des « shipping late doesn’t hurt » ou les coût des prototypes, il nous invite à prendre le temps de faire des études amont bien détaillées… Le chapitre 4 signe le retour de l’ours dansant. L’auteur évoque le coût de la non qualité des logiciels : installation fastidieuse, incapable de mémoriser les habitudes de l’utilisateur ou simplement inflexibles et paresseux. Un coût qui se chiffre en perte de loyauté, comme il est évoqué au chapitre 5. Si Apple a su se rendre désirable au point que la loyauté de ses clients soit à tout épreuve, seule la position dominante de Microsoft lui a permis de contrer le manque de désirabilité de ses produits. Un atout que n’avait pas Novell et qui lui a coûté la vie alors que l’entreprise se pensait invincible.
La troisième partie prétend nous montrer comment manger de la soupe avec une fourchette. Elle compte 3 chapitres sur une quarantaine de pages. Le chapitre 6, éponyme du livre nous compte combien les ordinateurs sont différents des humains (sauf les programmeurs qui tendent à converger vers les ordinateurs) et que malgré tout on s’attend qu’ils leur ressemblent ce qui est la recette pour des catastrophes. Le développeur, parlons-en ! L’auteur l’appelle « homo logicus » qu’il oppose à « homos sapiens ». Dans ce chapitre 7, Alan Cooper évoque tout ce qui différencie ces deux espèces. De geeks oppressés par les brutes au lycée, ils sont devenus les brutes oppresseurs de leurs anciens bourreaux… C’est bien sévère ! Le chapitre 8 fera mal à certains, car il appelle la culture de la programmation, une « culture obsolète », isolationniste centrée sur les souhaits de l’ingénierie et non sur les besoins de l’utilisateurs.
Lire la suiteNote : 6 ; Fidèle à l’évangile Scrum, mais de la bonne quand même !
J’avoue que je n’étais pas très confiant à l’ouverture de ce livre. Il s’agit du texte ostensiblement officiel de la Scrum.org sur le rôle du Scrum Master. Les examens de certification, même si je diverge assez peu avec les opinions sous-jacentes montrent quand même un certain dogmatisme sur les positions. Oui, je m’attendais à retrouver ce dogmatisme ici. C’est parfois un peu le cas, mais nous allons voir qu’il y a aussi (et surtout) pas mal de bonnes nouvelles.
Avec ses 160 pages (175 en comptant les annexes), il ne s’agit pas d’une lecture effrayante. Les 8 chapitres structurent le contenu en séquences tout à fait digestes. Le premier d’entre-eux « continuously improving your Scrum practice » fait un petit peu fourre-tout. On y trouve les valeurs de Scrum, les compétences des équipiers Scrum et des éléments de pratiques d’amélioration. C’est plutôt bien écrit mais c’est une entrée en matière un peu incongrue.
Le chapitre 2 « creating a strong team foundation » va nous mettre davantage dans le rythme. Tout d’abord, il est mieux ciblé sur un sujet qu’il traite en 3 volets. On commence par les savoir-être, le profil et les compétences attendues d’un membre, pour ensuite aborder le cadre de l’équipe (confiance, finalité, etc.) pour terminer sur la dynamique d’équipe avec ses phases de formation selon différents modèles (Tuckman, Satir…). C’est un chapitre très riche avec de très nombreuses références et renvois. Ce dernier point est une très bonne surprise que l’on retrouvera dans les chapitres suivants.
Lire la suiteA good leader does not get bogged down in the minutia of a tactical problem at the expense of strategic success.
Jocko Willink
Note : 7 ; Un « back to basics » très bien écrit et malheureusement aujourd’hui nécessaire… mais par moments trop empreint de dogmatisme XP !
Quand on ouvre un livre de Robert Martin, on est presque toujours sûr de passer un bon moment. C’est bien le cas ici, et c’est sans doute pourquoi j’ai avalé ce court opuscule en à peine 2 jours. Le sous-titre « back to basic » traduit bien la volonté de l’auteur, revenir aux sources de ce qu’est l’agilité, de pourquoi et comment la met-on en œuvre. Le retour aux sources, c’est le retour à la véritable agilité, et pour l’auteur ce ne peut être rien d’autre que Extreme Programming. Nous verrons que cela induit quand même quelques biais qui peuvent aller de légèrement irritant à franchement embarrassant.
Place au texte ! Comme énoncé, c’est une lecture fort digeste : 185 pages réparties sur 8 chapitres. C’est d’histoire dont nous parle Robert Martin dans ce premier chapitre. L’histoire telle qu’il la connait et qu’il l’a vécue. Cela couvre des éléments bien antérieurs aux années 89/90, que les non-férus d’histoire découvriront, et bien sûr l’écriture du manifeste à Snowbird. Un régal. Le chapitre se termine sur le « circle of life » d’extreme programming, car pour l’auteur agile est synonyme d’extreme programming, et en fait rien d’autre.
Le chapitre 2 couvre les raisons de faire de l’agile (oui, j’ai dit « faire »). Le chapitre incarne assez bien l’aspect « retour aux bases » avec un éclairage résolument XP et ingénierie du développement. Ce n’est pas vraiment une découverte bien sûr, ni une redécouverte pour moi, mais il pourra éclairer des nouveaux venus qui n’ont que le prisme facilitation en tête. Le plus curieux dans le chapitre 3 est le titre « business practices » qui pour moi correspond peu au contenu (pour ne pas dire pas du tout). Peut-être que selon le prisme XP, le business est tout ce qui n’est pas strictement l’ingénierie de développement ? On y aborde de manière conséquente les estimations et la vélocité ce qui, même si c’est bien et clairement abordé est tout à fait ennuyeux. La fin du chapitre sur les tests et la QA parvient tout de même à me sortir de ma torpeur.
Lire la suiteNote : 7 ; Une boite à outil plutôt qu’un cadre de coaching
Faire une note de lecture d’un livre dont j’ai été l’un des relecteurs principaux n’est pas une tâche facile. De plus, j’avoue n’avoir que peu goûté les ouvrages que j’ai pu croiser sur le coaching agile. Peut-être bien est-ce au fond un manqué d’intérêt de ma part sur ce sujet ? Voyons ce qu’il en est.
Tout d’abord l’ouvrage : avec 273 pages découpés en 21 chapitres plus une conclusion il est de taille moyenne. Moi qui apprécie les chapitres de taille raisonnable, je serais plutôt satisfait, toutefois il y a une forte disparité de longueur des différents chapitres, mais rien de bien gênant.
Enfin, il faudra noter le découpage en 5 parties qui reflète une progression dans la démarche de coaching.
La première partie campe le contexte. Il faut compter 3 chapitres sur 40 pages pour cela. Si le premier d’ntre-eux parle d’agilité, ce sont bien les « comportements attendus » figurant en dernière page qui constituent le point dominant du propos. Le second chapitre forme un contrepoint mettant en relief au travers d’exemples fictifs mais inspirés de la réalité, la différence entre ce qui devrait être un acquis et l’observation du terrain. Le contraste est saisissant. L’explication arrive au 3ème chapitre avec, entre autres, l’homéostasie et le poids de nos émotions que l’auteur compare à un GPS interne.