Don’t prioritise user stories. Prioritise impacts, outcomes, business goals. Story prioritisation follows naturally.
Gojko Adzic
Publicités
Note de lecture : Fire in the Valley 3rd edition, par Michael Swaine & Paul Freiberger
Note : 8 ; Les petites et grandes histoires du début de la micro-informatique racontées et témoignées de manière passionnante.
C’est un livre d’histoire. D’histoire contemporaine pour être plus précis, qui couvre essentiellement le début des années 70 jusqu’au début des années 90. Ou devrais-je plutôt appeler cela une épopée : celle de la naissance du micro-ordinateur, jusqu’à sa banalisation qui coïncida avec l’avènement d’Internet et la banalisation des micro-ordinateurs devenus objets de grande consommation.
Ce n’est pas une lecture légère : le livre au format classique des ouvrages d’informatique concède près de 380 pages mais presqu’exclusivement de texte. Ramené au format classique, on est plutôt entre 500 et 600 pages. Fort heureusement, c’est fort bien écrit, les auteurs ont de réels talents de story tellers. Normal me direz-vous, pour des journalistes.
L’ouvrage est organisé en 10 chapitres, qui sont donc chacun assez conséquents. Ils ne suivent pas un ordre strictement chronologique, mais sont plutôt thématiques. Ces thèmes étant quand même séquencés globalement chronologiquement.
Le premier chapitre, déjà est un régal. Il nous emmène sur une trentaine de pages, depuis la machine de Babbage jusqu’au CP/M et aux premiers hacks de Bill Gates. En fait, les 5 dernières pages mangent déjà un peu sur la suite du livre. Je me serais bien arrêté à l’Eniac. Le véritable démarrage de l’épopée est au crédit du chapitre 2 : la naissance, la gloire et la mort de l’Altaïr. Même s’il n’est pas le premier micro-ordinateur (un privilège qui revient au Micral Français). A l’Altaïr succède (ou suit) IMSAI, puis l’auteur se tourne vers les geeks, plus précisément le Homebrew Computer Club, son apôtre de la contre-culture, Lee Felsenstein et ses membres de la première heure tels que Steve Wozniak. Plus que tout autre, c’est lui qui sera à l’origine du foisonnement de hobbist et de petits constructeurs artisanaux en tout genre dans la seconde moitié des années 70.
Note de lecture : The Mikado Method, par Ola Ellnestam & Daniel Brolund
Note : 2 ; Que de remplissage !
Les auteurs ont découvert un bon truc pour refactorer du code legacy. Une technique à la fois simple et pratique, donc réellement bonne. Et ils ont voulu en faire un livre. Seulement voilà, parce qu’elle est simple, cette technique tient en 20 pages, guère plus !
2 parties totalisant 7 chapitres sur 140 pages constituent le corps de l’ouvrage. La première partie « The basics of the Mikado Method » se satisfait de 4 chapitres avec 65 pages environ. On ouvre le bal avec « meet the Mikado method ». En fait, tout est dit, ou presque, dans ce premier chapitre d’une quinzaine de pages. La démarche en fait très simple (c’est sa qualité première) est décortiquée pas à pas. La seule chose qui manque est un exemple. C’est ce que l’on escompte avec le chapitre 2 « hello, Mikado Method ». L’exemple est hélas un peu simpliste, mais la vingtaine de pages illustre un peu tout, y compris le « revert » à l’aide d’un petit exemple en Java. L’utilisation du gestionnaire de version, partie intégrante de l’approche, fait partie du lot. Il y a déjà pas mal de répétitions avec le chapitre précédant, mais cela reste intéressant.
Le chapitre 3, « goals, graphs and guidelines » est là pour nous donner un peu de recul sur ce qu’est un bon objectif de Mikado. C’est très abstrait et ne nous emmène pas très loin. Au chapitre 4, les auteurs explorent des variations de l’approche Mikado avec « Organizing your work ». En l’occurrence ils déclinent l’approche Mikado en isolation, en pair et en équipe. L’aspect « équipe » rappelle un peu le « Mob Programming », mais il ne m’apparait pas évident que la mise en œuvre ait été sérieusement expérimentée… Cela conclut la première partie du livre.
Telling your truth with compassion instead of delivering “constructive” criticism
Lissa Adkins
Note de lecture : Working Effectively with Legacy Code, par Michael C. Feathers
Note : 9 ; Le refactoring repensé pour le legacy. Book of the year 2018 !
Appréhender la remise sous contrôle du code legacy est à mon avis une discipline à part entière. C’est en partie de l’architecture, tout en empruntant au refactoring avec une démarche de tests bien à elle. Entre autres choses. Mais peu d’ouvrages sont dédiés à la question, il faut dire que celle-ci n’est pas la plus sexy qui soit. Le livre de Michael Feathers se tient au sommet de cet édifice depuis plus d’une douzaine d’années et pour de bonnes raisons.
Michael Feathers nous propose une approche dans la ligne de l’approche extrême programming, en s’appuyant sur une vision code adossé à des tests unitaires. D’ailleurs sa définition du code legacy s’en inspire directement : du code legacy, c’est du code sans tests !
Avec 420 pages, ce n’est pas un petit volume que nous avons entre les mains. Il se découpe en 3 parties. La première d’entre-elle « the mechanics of change » est aussi la plus courte avec une cinquantaine de pages en 5 chapitres. Il s’agit bien d’une introduction assez exhaustive à l’approche que propose l’auteur et que j’appelle le « inside out ». Elle répond aux questions suivantes :
Note de lecture : Traité du Zen et de l’entretien des motocyclettes, par Robert M. Pirsig
Note : 8 ; Un road-trip qui associé aventure humaine, réflexions philosophique et réparation des motos !
Le plus curieux dans ce livre, c’est le titre ! En fait, il n’est guère question de Zen, mais on y évoque bien l’entretien des motocyclettes. Ce livre, c’est un road-trip, que l’auteur entreprends avec son fils, à moto. Ou plus exactement un Chautauqua ainsi que le qualifie l’auteur. Le livre en lui-même est difficile à décrire, et je vais faire de mon mieux.
La trame de fond est le road-trip que j’ai évoqué. C’est l’aventure que l’auteur a imaginée pour renouer le contact avec son fils, entreprise qui s’avérera ardue, et leur fera traverser la moitié des Etats-Unis. Très vite on y rencontre un 3ème personnage, Phèdre, dont on finit par comprendre qu’il s’agit de l’auteur lui-même, avant son internement en hôpital psychiatrique, mais qu’il dissocie de lui-même. Phèdre à une vie, une pensée propre et surtout sa propre quête, celle de la « Qualité ». C’est d’ailleurs à ce moment que cet autre moi s’empare de l’auteur.
Les passages consacrés à Phèdre sont les plus ardus du livre, l’auteur y développe ses points de vue philosophiques, ou plutôt ceux de Phèdre. Nombre de réflexions sont toutefois réellement transposables, par exemple :
- Les multiples évocations de la méthode scientifique et la manière dont elle peut être quotidiennement utilisée.
- La dichotomie entre les modes « romantique » (inspiration, vision, intuition) et « classique » (structure de la pensée, approche scientifique).
- Les divers écueils de nos modes de réflexion : blocages, freins et revers…
Man’s achievements rest upon the use of symbols…. we must consider ourselves as a symbolic, semantic class of life, and those who rule the symbols, rule us.
Alfred Korzybski
Note de lecture : A Tour of C++, par Bjarne Stroustrup
Note : 5 ; Une introduction au C++ 2011, qui se lit mieux si on comprend déjà quelque peu le langage…
Une mise à jour de mes connaissances sur les dernières évolutions du langage : voilà ce qui étaient mes attentes concernant ce livre. Un livre fort court avec seulement 170 pages, ce qui me convenait parfaitement. D’ailleurs quand je dis « dernières évolutions du langage », c’est une façon de parler : j’ai bien attendu l’année de la norme 2017 pour lire un livre sur la norme 2011…
Le texte est bien découpé : les 170 pages sont réparties en 14 chapitres, chacun adressant un thème particulier du langage. Le premier couvre les « basics » sur 14 pages, j’y apprends quand même plusieurs nouveautés : le nullptr qui remplace null et la syntaxe for range permettant l’itération implicite sur des containers, comme en Java. Mais aussi l’inférence de types avec auto et l’initialisation des variables avec les accolades au lieu des parenthèses (on continue par ailleurs à utiliser celles-ci, tout n’est pas clair…). De petites (et moins petites) choses, mais de bonnes choses. Seulement 6 pages pour les « User defined types » du chapitre 2. Il faut dire que l’on n’a pas encore abordé les classes. Ici la nouveauté réside dans les class enums qui permet de typer ceux-ci. Là aussi on se rapproche du Java, mais sans pour autant pouvoir faire autant de choses avec. Dommage d’y consacrer moins d’une demi-page.
Note de lecture : Understanding A3 Thinking, par Durward K. Sobek & Art Smalley
Note : 7 ; Pour donner du sens à la « pensée A3 », en conservant l’austérité du Lean !
Ne vous y trompez pas : le format de cet ouvrage est certes réduit, il ne prendra guère de place sur l’étagère… mais le contenu est consistant et demande à prendre son temps pour être consommé !
Ne vous y trompez pas : on y évoque le A3, mais ce n’est pas une explication de texte, en tout cas pas seulement. Comme le titre l’indique, il s’agit avant tout de comprendre la pensée A3, comment il s’inscrit dans une démarche et une logique PDCA. C’est d’ailleurs une trame récurrente du texte : superposer au A3 cette démarche PDCA.
160 pages et 8 chapitres, c’est tout ce qu’il faut pour venir à bout des objectifs énoncés ci-dessus. Le premier d’entre-eux est fort court avec 8, et c’est le PDCA qui nous est servi en guise d’introduction. C’est la philosophie Toyota que les auteurs tentent de nous faire toucher du doigt. Ils réussissent au minimum à nous donner l’envie de lire « The Toyota Way » ! Les 11 pages du second chapitre sont clés pour la suite, car il s’agit de la pensée A3 résumée en 7 éléments. Je ne vais pas les énoncer ici. Si je dois en retenir 3, je dirais : objectivité (résumé par l’approche scientifique), synthèse et vue systémique.
La confiance rapporte plus que le contrôle.
Jean-François Zobrist
