Note de lecture : ATDD By Example, par Markus Gärtner

Note : 3 ; Mélange des genres…

Je sors assez désappointé de la lecture de ce livre assez succinct de 185 pages. Heureusement la lecture n’en est pas trop longue, d’une part du fait du nombre de pages et d’autre part du fait du format plus réduit que d’habitude. L’ouvrage est découpé en 3 parties, les deux premières sont dévolues à des études de cas tandis que la dernière évoque les principes de l’ATDD.

La première partie est consacrée à la gestion d’un parking d’aéroport. Elle couvre 50 pages environ sur 4 chapitres. Ca commence relativement bien au premier chapitre, sous la forme d’un dialogue entre le développeur et le responsable métier. Bien que cela n’ait rien de grandiose et ne m’ait rien appris, cela m’a même semblé assez basique. Et puis rapidement aux chapitres 2 et 3, on cause outils, Selenium pour être précis. Je ne m’attendais pas vraiment à un cours (pas terrible de surcroit) sur les fixtures Selenium. Tant pis ! Le dernier chapitre évoque la collaboration et le wishful thinking sur 4 pages, c’est assez creux. Cela ira peut-être mieux sur la prochaine partie ?

En fait non, c’est pire ! Cette partie déroule également sur 4 parties, mais sur 75 pages cette fois, la gestion de feux de croisement tricolores. Le chapitre 5 est une description du fonctionnel. Comme tout ça reste assez simple, on va être autonome : on ne va pas s’encombrer d’un spécialiste fonctionnel qui va trainer dans nos pieds pendant qu’on code, n’est-ce pas ? Et hop ! Dès le chapitre 6 on saute à pied joints dans des fixtures Fitness. Un peu de code… un peu de refactoring… c’est franchement brouillon, difficile à suivre mais l’auteur à l’air très fier de lui. On se souvient au chapitre qu’on est sensé écrire des cas de test. On gribouille donc quelques tables et c’est reparti pour une très ennuyeuse tirade de code et de refactoring. Le chapitre 8 conclut cette partie : testez votre « glue code » ! Ah ouais ? OK…

Tous mes espoirs reposent donc sur la 3ème partie. Vais-je y trouver ce que j’étais venu chercher ? Elle compte 5 chapitres sur 60 pages. Au chapitre 9, l’auteur évoque la nécessité de s’appuyer sur des exemples. En résumant (visiblement) tant bien que mal les propos de Gojko Adzic. Au chapitre 10 il parle de la nécessité de spécifier en collaboration en reprenant péniblement la prose de Mike Cohn qui l’a lui même emprunté à Suzanne et James Robertson (je fais référence au « trawling requirements » par exemple). Mais cela l’auteur semble l’ignorer. Sur les deux chapitres suivants (automatisation des tests et « clean tests ») l’auteur est un peu plus chez lui, ça va mieux. Le dernier chapitre ? Ah, bah…

Continuer à lire « Note de lecture : ATDD By Example, par Markus Gärtner »

Note de lecture : Agile Metrics in Action, par Christopher W. H. Davis

Note : 3 ; L’agilité à mi-chemin.

Ce livre est une déception, je n’ai hélas pas d’hésitation à cet égard. Il est vrai que l’on manque souvent sur les projet agile à mesurer des choses alors que la collecte de faits tangibles est la base d’une démarche Lean ! L’origine de cet ouvrage est un système de collecte de mesures pensé et développé par l’auteur et déployé sur les équipes dont il était le manager. Ce système collecte des données depuis Jira, Github, Jenkins, la plateforme de déploiement et Google Analytics, pour ensuite consolider cela. Une idée tout à fait brillante. Malheureusement, comme nous allons le voir, le livre ne parvient pas à valoriser cela.

La structure de l’ouvrage suit en grande partie les 5 grandes « travées » que l’auteur voit dans le développement agile. Il est organisé en 10 chapitres format 3 parties, le tout totalisant 220 pages. A cela il faut ajouter les 2 annexes qui ajoutent près de 20 pages : celles-ci apportent quelques éclaircissements sur la chaine de collecte conçue par l’auteur. La première de ces parties ne compte qu’une trentaine de pages sur deux chapitres. Le premier d’entre-eux « Measuring Agile Performance » dresse sur près de 20 pages un tableau du problème que l’on s’efforce de résoudre. Je ne suis que partiellement d’accord avec l’auteur, par exemple quand il prétend que l’on a pas une vue claire de nombreux concepts comme celui de « bonne qualité » ou qu’il pointe du doigt le focus sur le produit plutôt que sur le projet comme un problème !

Continuer à lire « Note de lecture : Agile Metrics in Action, par Christopher W. H. Davis »

Note de lecture : Workflow Management, par Wil Van der Aalst & Kees Van Hee

Note : 6 ; Une référence, certes, mais aussi un texte aride !

Soyons clair dès le début : ce livre fait autorité sur les fondamentaux des Workflow et est écrit par la plus grande autorité reconnue en le domaine. D’ailleurs le livre débute ses deux premiers chapitres en posant les bases des concepts fondamentaux des Workflows : tâches, work items et activités, mais aussi les réseaux de Pétri, bien entendu.

Le chapitre 3 s’attaque à la gestion des workflows : l’alignement des ressources et de l’organisation sur les workflows, ainsi que l’adéquation de ceux-ci par rapport aux objectifs et aux coûts. Cette étude est complétée par le chapitre 4 qui couvre l’analyse de pertinence et de performance des workflows.

Si ces 4 premiers chapitres couvrent la théorie, la pratique arrive avec le chapitre 5 qui présente les architectures de systèmes de Workflow, le chapitre 6 qui lui fait suite s’attaque à l’aspect méthode. Une partie qui aurait aussi bien pu être oubliée car elle apporte assez peu ici. L’étude de cas qui termine l’ouvrage est une bonne idée, mais elle est peu passionnante aussi bien par le fond que par la forme.

On notera enfin les 2 annexes : la première destinée aux fondamentaux mathématiques ravira les plus courageux (je n’en fais visiblement pas partie) et la seconde assez courte dédiée à la représentation des workflows avec UML.

Continuer à lire « Note de lecture : Workflow Management, par Wil Van der Aalst & Kees Van Hee »

Note de lecture : Scrumban, par Corey Ladas

Note : 8 ; Réflexions sur la transition de Scrum à Kanban, la vraie nature d’un processus agile et les moyens de l’adapter.

J’entends beaucoup de personnes parler du Scrumban, mais bien peu ont lu les essais de Corey Ladas compris dans ce volume, car il ne s’agit pas de ce dont ils pensent. Car avant tout, Scrumban est une compilation d’essais (souvent des reprises de posts de blog) sous la forme d’un livre au format très court, moins de 175 pages, celles-ci étant par elle-même assez courte, du fait de la mise en page. Mais court ne signifie pas sans valeur, car le texte de ce praticien très chevronné de l’agilité nous propose des réflexions très profonde sur le passage de Scrum à Kanban et la vrai nature des processus que nous utilisons !

Il n’y a pas vraiment de chapitres au livre, mais plutôt des espèces de thèmes qui sont au nombre de 7. Le premier d’entre-eux concerne Kanban lui-même. L’auteur y explore les mécanismes fondamentaux : le WIP et le flow, bien sûr, mais aussi la synchronisation et les buffers. On termine avec une réflexion sur la notion d’itération : pourquoi son avènement était inévitable, tout comme maintenant … sa disparition !

Le workflow est le second thème. C’est l’occasion de réfléchir sur la vrai nature d’un processus, en commençant par souligner qu’un workflow n’est pas une planification (les 2 concepts sont orthogonaux). L’auteur va plus loin en étudiant le PSP du SEI par rapport à Kanban et en mettant en relief les … similitudes ! Enfin l’auteur termine cette partie en dénaturant le kanban en le transformant en un processus à un ticket : c’est un cycle en « V » !

Continuer à lire « Note de lecture : Scrumban, par Corey Ladas »

Note de lecture : Serial Communications, A C++ Developer’s guide, par Mark Nelson

Note : 7 ; Bien que désormais obsolète (car concerne surtout Windows 16 bits), reste intéressant sur les principes de gestion des ports série.

Tant que je suis dans les antiquités…en voici une tout à fait honorable ! Certes ce livre a perdu une grande partie de son intérêt, d’abord avec l’arrivée du Windows 32 bit et de TAPI puis des infrastructures et librairies qui rendent aujourd’hui transparente les vicissitudes des protocoles de communication.

Cet ouvrage nous permet, aujourd’hui encore, de nous ressourcer sur la mise en œuvre des communications à bas niveau, là où les caractéristiques du matériel ne peuvent être ignorées ! Mais la bête est imposante : ce sont 600 pages qui se présentent à nous sur ce seul sujet, le tout en 11 chapitres ! Le premier d’entre-eux rappellera des souvenirs aux plus anciens d’entre nous, il aborde l’interface RS 232 C sur 64 pages. Tout y passe, depuis la norme du connecteur, la signification des signaux et les protocoles de transmission modem. L’électronique sous-jacente, les fameux UART sont évoqués, mais leur gestion fera l’objet d’un chapitre à part. Finalement les protocoles d’échange de fichier (Kermit, ZModem, etc.) clôturent le chapitre. C’était en quelque sorte le tour du propriétaire.

Continuer à lire « Note de lecture : Serial Communications, A C++ Developer’s guide, par Mark Nelson »

Note de lecture : Conception orientée objet, par Peter Coad & Edward Yourdon

Note 3 ; Les principes embryonnaires de la conception objet

Il y a « l’avant » Design Patterns, et « l’après ». Cet ouvrage est dans la catégorie « avant ». Il fait aussi suit à « l’Analyse orientée objet » des mêmes auteurs. Et son âge respectable le classe parmi les livres qui ont servi de fondation à l’orienté objet. Bien sûr, depuis on a construit pas mal d’étages, et seul les férus d’histoire informatique auront à cœur de se replonger dans ces textes !

Le problème avec « l’avant » Design Patterns, c’est que l’on parle bien d’analyse et de conception (ici séparés en 2 livres) et que l’on prétend faire la différence clairement, mais en fait ce n’est pas le cas ! Au long des 160 pages du texte principal, les auteurs peinent à exposer des aspects clairement différents entre l’analyse et la conception. Voyons cela.

En plus du texte principal découpé en 10 chapitres, l’ouvrage  compte 24 pages d’annexes, elles-mêmes séparées en 3. Passé la quinzaine de pages d’avant-propos, ce sont les 10 pages du premier chapitre « améliorer la conception » qui ouvrent le bal. Bien que cela ne soit pas avoué ouvertement, la conception y est présenté comme quelque chose d’ajoutée « après coup » pour améliorer la qualité et la maintenance ! On y évoque aussi les principes d’encapsulation et l’organisation fonctionnelle.

Continuer à lire « Note de lecture : Conception orientée objet, par Peter Coad & Edward Yourdon »

Note de lecture : Service Design Patterns, par Robert Daigneau

Note : 5 ; Des patterns qui sont plutôt des exemples d’implémentation…

Ce texte, ce devrait être en principe le complément des Enterprise Integration Patterns de Gregor Hope. Dans la pratique, il n’est pas à la hauteur de son ainé, même s’il nous permet d’apprendre certaines choses sur les web services, qu’ils soient SOAP ou REST.

En pratique, ce texte de 270 pages est découpé en 7 chapitres. Il faut aussi compter les annexes qui ajoutent une trentaine de pages de glossaire et référence de patterns. Les 10 pages du premier chapitre servant d’introduction ne nous apprennent pas grand chose, passons ! Le second chapitre est plus conséquent, en nombre de pages d’abord car on en compte 40, mais surtout par le contenu. C’est de « style de web services » dont il est question, de 3 styles plus précisément : RPC, orienté messages et orienté ressources. Ce chapitre focalise sur les considérations d’architecture liées à ces 3 styles, c’est donc en fait la véritable introduction au reste du livre ! En tout cas, le contenu est digne de Martin Fowler.

Continuer à lire « Note de lecture : Service Design Patterns, par Robert Daigneau »

Note de lecture : Growing Object-Oriented Software Guided by Tests, par Steve Freeman & Nat Pryce

Note : 8 ; Craftmanship en grandeur réelle

Quand on évoque le craftmanship, on montre des exemples de code, sinon cela n’a pas de sens ! Généralement, il s’agit de 2 ou 3 classes qui se battent en duel que l’on refactore afin d’améliorer les abstractions, éviter les duplications de code et tout et tout… Ce livre-là est différent, car il va faire du design émergent en TDD une réalité en l’appliquant sur la construction d’un logiciel complet, le tout suivi pas à pas ! Pour mener à bien sa mission, le texte compte un peu moins de 330 pages hors annexes, le tout découper en 5 parties très inégales. Je ne vais pas vous compter par le menu les 27 chapitres de l’ouvrage, mais plutôt les 5 parties.

La première partie est introductive (comme on peut s’en douter). Elle ne compte que 3 chapitres sur 25 pages. Il s’agit avant tout de considérations générales, mais non dénuées d’intérêt. On y évoque des principes nouveaux ou anciens comme le cycle ATDD imbriqué dans le cycle TDD, les cartes CRC ou le « tell, don’t ask ».

Continuer à lire « Note de lecture : Growing Object-Oriented Software Guided by Tests, par Steve Freeman & Nat Pryce »

Note de lecture : Essential Business Process Modeling, par Michael Havey

Note : 7 ; Un titre trompeur, mais sinon un excellent tour d’horizon des langages de processware…

Commençons par clarifier un point important : ce livre ne traite pas de « business processes », pas plus qu’il n’aborde la modélisation métier. Hélas, ce terme a été kidnappé et est devenu depuis consacré, par les éditeurs d’infrastructures d’échanges et d’orchestration. Ce point traité, nous allons voir que ce livre, divisé en 3 parties, recèle beaucoup de bonnes surprises.

La première partie est consacrée aux fondamentaux du « BPM », historique et fondements théoriques. En effet, les standards du BPM s’appuient globalement sur 3 principes théoriques (au choix ou de façon complémentaire) : les réseaux de Pétri, le Pi-calcul (je vous garanti que celui-ci n’est pas facile à capter) et les diagrammes d’état-transition.  Si les fondements théoriques permettent de comprendre les paradigmes développés par les moteurs de processware, les process patterns permettent de comprendre les briques de base de l’orchestration et aussi de classifier les normes d’orchestration de process en fonction de leur support des 24 process patterns présentés.

Continuer à lire « Note de lecture : Essential Business Process Modeling, par Michael Havey »

Note de lecture : Convergent Architecture, par Richard Hubert

Note: 1 ; Pas convaincant et ennuyeux!

Mais pourquoi donc ai-je acheté ce bouquin? Tout simplement parce que l’excellent « enterprise patterns and MDA » y fait référence. Mais force est de constater que c’est l’échec complet. Voyons donc comment les 260 pages et les 8 chapitres de cet ouvrage pourtant estampillé « OMG press » ont pu nous amener là.

Le chapitre 1 « IT Architectural style » couvre 30 pages. Il s’agit, du moins pour les 15 premières pages d’une discussion philosophique sur la nature d’une architecture, son caractère évolutif, ses niveaux d’expression et l’équilibre entre innovation et couverture du risque. Rien de bien concret. Je ne me retrouve guère non plus dans les 4 propriétés énoncées concernant cette architecture, sujet des 15 pages suivantes :

  • Le métamodèle architectural, bref la nécessité de suivre un style prédéfinit.
  • Le cycle de vie du développement du modèle.
  • Une suite d’outils complète.
  • Une « projection technologique » formalisée.

On va même jusqu’à évoquer le template IEEE 1471-2000 pour documenter cette architecture. Bref, un chapitre qui n’a guère de sens pour moi.

Continuer à lire « Note de lecture : Convergent Architecture, par Richard Hubert »