Note de lecture : Corba : des concepts à la pratique, 2nd édition – Jean-Marc Geib, Christophe Gransart & Philippe Merle

Note : 6 ; Une présentation plutôt pédagogique, mais un texte qui accuse son âge.

Comme le titre l’indique, l’objet de ce livre est d’expliquer Corba en commençant par les principes, puis en poursuivant par la pratique. De fait, le texte devrait pouvoir servir de support d’un cours Corba, par exemple.

Les deux premiers chapitres sont un tour d’horizon des principes de Corba. En une cinquantaine de pages, on fait le tour des concepts de ce middleware, le tout agréablement soutenu par des diagrammes. Pas mal. Curieusement, c’est par une investigation en profondeur que l’on continue, que l’on a un peu de mal à raccrocher à la partie précédente. L’auteur a dû juger que cela était un prérequis indispensable aux chapitres suivants : les interfaces standard de Corba (chapitre 4), hélas fort peu illustré par un exemple pratique, puis les services standard (chapitre 5), toujours aussi peu soutenu d’exemple, même si les diagrammes sont valables. Nous voici arrivé en page 180 (sur 265, hors annexes), avec une vue consistante de Corba, mais peu d’exemples.

C’est le chapitre 6 qui constitue l’étude de cas venant illustrer les parties précédentes. Celui-ci aide pas mal pour comprendre l’implémentation d’un objet Corba en BOA, ainsi que l’utilisation du service de nommage, hélas de nombreux concepts précédemment illustrés n’apparaissent pas, comme les différents types de services décrits.

Lire la suite

Publicités

Note de lecture : Réussir la conduite de projets informatiques, par Pham Thu Quang & Jean-Jacques Gonin

Note : 3 ; Les bases de la gestion de projet à la papa. Assez léger.

Il fut un temps où, croyant fermement que mon avenir était de devenir chef de projet, je voulais réellement savoir en quoi cela consistait, figurant vaguement que cela avait à voir avec la planification. C’est bien cette approche à la papa que couvre cet ouvrage. Hop, c’est parti pour 170 pages divisé en 3 parties totalisant 14 chapitres.

La première partie n’occupe que 25 pages et 2 chapitres et s’intitule pompeusement « conduite de projets d’informatisation ». Elle commence par un chapitre ultra-court de 4 pages pour distinguer système informatique et système d’information ! A la lumière d’une décennie et demie d’agilité, le second chapitre sur les raisons de l’échec laisse rêveur : absence d’une démarche, besoins insuffisamment exprimés ou changeants… Cela présage bien pour la suite !

La suite, c’est la seconde parties « techniques et démarche de la conduite de projet ». Près d’une centaine de pages et 8 chapitres, c’est la plus longue partie. Le chapitre 3 nous parle de démarche, donc de « cycle en V ». On notera le petit paragraphe sur la partie développement « considérée triviale par certains mais tout de même importante » ! Le chapitre se fend de plans-type des documents important. Pour ce qui est d’un texte sur le cycle en V, j’ai vu bien pire ! Le chapitre 4 est celui qui m’a fait acquérir le livre à l’époque : le diagramme de Gant expliqué ! Oui, vous avez bien lu ! Le fait est qu’il est très bien expliqué. Le chapitre 5 traite quand à lui de l’estimation des charges. Il traite à part égale les points de fonction et le COCOMO. Les auteurs ne s’étalent pas en longueur et le texte ne saurait servir de référence sur l’un ou sur l’autre, il n’en est pas moins ennuyeux.

Lire la suite

Note de lecture : RSS and Atom in Action, par Dave Johnson

Note : 5 ; Une vue du RSS orientée vers le Blog…

RSS n’est pas en soi un sujet tellement difficile. Il est surtout compliqué de trouver un angle d’attaque : le format ? Les parseurs ? La génération de feeds. Ce livre fait le choix de présenter ce standard sous l’angle de la mise en place de Blogs, ce qui n’est pas si clair dans le titre de l’ouvrage.

Chose classique à chaque fois que l’on aborde RSS et Atom, le livre évoque l’historique et sa pléthore de normes divergentes. Si le parti est pris de promouvoir Atom, les tenants et aboutissants des versions de RSS est clairement mis en valeur.
Une fois sorti du format, il faut bien parler traitement. Dans l’optique de rester indépendant par rapport au langage, le texte promeut à égalité Java et .NET (par le biais de C#), il aborde même fugitivement Python ! Bien que chaque monde soit abordé à égalité de traitement, je pense que le texte aurait gagné en clarté et en cohérence à n’en traiter qu’un. En tout cas, cette pluralité nuit à la cohérence et à la pertinence pour chaque environnement pris indépendamment.

Pour ce qui est du monde Java, c’est la librairie Rome qui est mise en lumière. Elle n’est pas exempte de faiblesses et l’auteur les relève honnêtement. Je regrette cependant que la génération de feeds soit traitée si légèrement : quid des « feeds infinis » ou d’un exemple concret de déploiement dans une architecture J2EE / conteneur de servlets. Hélas, ces aspects sont très vite éludés.

Lire la suite

Note de lecture : Object-Oriented Reengineering Patterns, par Serge Demeyer, Stéphane Ducasse & Oscar Nierstrasz

Note : 4; Un sujet important, mais auquel le format « pattern language » ne rend pas justice.

Le reengineering d’application est un sujet souvent passé sous silence, les auteurs préférant parler des applications débutées depuis une page blanche, ce qui ne constitue pas finalement la plus grande part des projets. Dans cet ouvrage, les auteurs nous proposent une démarche en 9 étapes, qui va de la rencontre avec le legacy au système restructuré.

Le découpage du texte se calque sur les étapes de réengineering proposées, donc 10 chapitres en comptant l’introduction, pour un total d’environ 250 pages sans les annexes (par ailleurs assez courtes). L’ensemble est principalement structuré en deux parties, avec un premier chapitre servant d’ouverture à l’ensemble. Les auteurs viennent du monde des patterns, c’est d’ailleurs dans une de ces conférences que je les ai rencontrés. La quinzaine de pages de ce premier chapitre nous explique la « forme pattern » empruntée (en l’occurrence la forme Alexandrienne) et la démarche de reengineering que j’ai évoquée plus haut.

La première partie s’intitule « reverse engineering » et compte 4 chapitres sur une centaine de pages. Le second chapitre « setting directions » nous propose des patterns pour orienter notre travail, tel que le « most valuable first » ou le « if it ain’t broke, don’t fix it ». Rien de bien palpitant pour l’instant, c’est l’échauffement. Suit « first contact » où, comme le titre l’indique, on va récolter nos premières informations. C’est plus concret, avec « interview during demo » ou l’intéressant « read all the code in one hour ». En fait, tous les patterns de ce chapitre recèlent quelque chose d’intéressant !

Lire la suite

Note de lecture : User Acceptance Testing, par Brian Hambling & Pauline Van Goethem

Note : 1 ; Une approche des tests à l’ancienne pour un texte récent et une cible complètement ratée.

Tests d’acceptation et User Acceptance Tests n’adressent pas pour moi la même finalité : Le premier est destiné à valider la conformité de ce qui a été réalisé par rapport à la spécification, tandis que le second se doit d’évaluer dans quelle mesure ce qui a été spécifié puis réalisé adresse l’expression de besoin initiale de l’utilisateur. Bref, l’UAT est là pour tester (indirectement) la spécification.

Il y a vraiment très peu de livres consacrés aux UATs. Celui-ci est en fait pratiquement le seul que j’ai pu identifier à ce seul thème. J’avais deux craintes avant même d’avoir ouvert ce livre : avais-je la même vu sur les UATs que les auteurs ? Et , étant donné l’origine très « corporate » du texte, n’allais-je pas rencontrer une approche très processus à l’ancienne ? Comme nous allons le voir, la réponse est hélas « oui » aux deux questions.

L’ouvrage n’est guère long, moins de 180 pages si l’on ne compte pas les inénarrables check-lists ou templates. Le tout est découpé en 10 chapitres pour reprendre son souffle. Moins de 20 pages en moyenne par chapitre, il n’en faudrait pas plus, car le style d’écriture n’est pas pensé pour être une partie de plaisir. Le premier chapitre n’a que peu à offrir, mais je m’arrête quand même sur deux points : d’abord le contexte considéré est bel et bien du cycle en V. Ensuite la définition du rôle de l’UAT semble correspondre à la mienne. Le second chapitre « the importance of UAT » en rajoute une couche sans apporter grand chose : toujours plus de processus, la contribution des différents rôles… tout cela est un peu creux. On revient sur la définition des UATs et cela deviens moins clair, entre la validation des spécifications et la satisfaction du besoin utilisateur. A ce stade, je doute que la distinction soit même claire pour les auteurs.

Lire la suite

Note de lecture : Scrum Mastery, par Geoff Watts

Note : 7 ; Les postures Scrum Master, illustrées par du story telling.

Cela faisait déjà un moment que j’entendais parler de ce livre, il était temps de lui faire un sort. Comme son titre l’indique bien, ce volume traite du boulot et de la posture du Scrum Master, le texte n’explique pas Scrum (il y a bien 3 pages là-dessus en annexe, mais bon…). Le texte part du principe que la connaissance de Scrum est acquise. La démarche (car il y a une démarche de Scrum Mastery) sur laquelle s’appuie l’auteur emprunte l’acronyme RE-TRAINED. C’est sur cet acronyme que s’articule le livre. Il compte 270 pages, mais compte tenu du format et de la mise en page très aérée (sans compter la qualité de la prose, cela se lit très bien.

R, comme « Respected ». Cette partie compte 3 « patterns », ainsi que je les appelleraient. Je retiens principalement de cette partie la notion de confiance, et plus particulièrement de faire confiance à l’équipe. Je retiens aussi l’acronyme AID (qui nous vient du « Tao of Coaching ») : Action, Impact et Desired Outcomes.
Le E est pour « Enabling ». 3 patterns également ici. De cette partie, mon take-away sera le modèle de maturité proposé par l’auteur. Il aborde aussi le sérieux problème du proxy : l’auteur n’aime pas le concept.

Le T signifie « Tactful ». La « fable des 2 Scrums » en début de partie va servir de point d’ancrage à d’autres parties. L’auteur nous conduit également à utiliser les silences à bon escient, un art plus difficile qu’il n’y paraît et de poser les bonnes questions pour que l’équipe prenne elle-même conscience de ses travers.

Lire la suite

Note de lecture : Le Mini-Book Cynefin, par Greg Brougham

Note : 3 ; Malheureusement, introduit plus de confusion qu’il n’éclaire.

J’utilise beaucoup le modèle Cynefin pour introduire la notion de complexité lors de mes introduction à l’agilité. Ce mini-book était pour moi l’occasion de découvrir une manière de l’aborder et de comprendre le framework plus en profondeur. Au final il s’agit d’avantage pour l’auteur de promouvoir les outils de cognitive edge que de développer le propos de Dave Snowden. Malheureusement également, la traduction française m’est apparu très poussive. Heureusement que je possède aussi la version originale !

Le livre est plutôt court, avec 58 pages (un mini-book comme stipulé dans le titre), découpé en 5 parties. Le framework Cynefin expliqué en occupe une dizaine de pages. C’est probablement la partie la plus intéressante. Elle développe la différence entre systèmes ordonnés et désordonnés. Mais il termine toutefois avec des concepts dont je ne comprends pas tellement comment ils se raccrochent au framework comme « l’obliquité » (toutefois intéressant) et le résolution de conflits !
La seconde partie est consacrée au narratif. Il y est question du narrative inquiry. Là aussi je ne parviens pas à raccrocher cela au Cynefin, mais je note le concept, qu’il me faudra creuser.

En troisième partie, on parle de « sense making ». L’auteur y développe la notion de contextualisation à l’aide de logique abductives (si, si). Sur ce principe, il développe la contextualisation qu’il préfère au VSM (value stream mapping). On y propose aussi un exercice de contexte partagé à l’aide narratif. C’est en quelque sorte du teasing pour Cognitive Edge car on n’y comprends pas grand chose…

Lire la suite

Note de lecture : Change your Questions Change your Life 3rd edition, par Marilee Adams

Note : 9 ; Un très bon ouvrage de coaching centré sur le questionnement.

L’art du questionnement un aspect clé, non seulement en coaching agile, mais aussi dans des activité comme le product management, j’en suis convaincu depuis longtemps. Jusqu’ici je n’ai trouvé que des outils assez ponctuels comme les « powerful questions » de Debra Preuss. Avec cet ouvrage, c’est une véritable approche structurée, le « question storming » qui nous est proposée.

Le texte est fort de 12 chapitres complétant 180 pages et d’un petit workbook en annexe regroupant les 12 principaux outils mis en œuvre dans le corps du texte. Les 12 chapitres ne sont pas individuels, si chacun comporte un thème, il s’agit en fait d’une histoire, celle de Ben Knight, manager fraichement promu par Alexa, chez QTech. Ben est en situation d’échec et s’apprête à poser sa démission. Une situation qui rappelle celle du « Phoenix Project ». C’est ainsi que nous faisons la connaissance du coach, Joseph S. Edwards, qui nous introduit au Question Thinking. Le Question Thinking, c’est trouver de meilleurs questions, des questions qui ouvrent de multiples possibilités, pour obtenir de meilleurs résultats.

Le chapitre 3 introduit le « choice map » dont le trait principal est l’opposition du « judger minset » et du « learner mindset ». Notre premier reflexe est celui de juger et cette carte est là pour nous aider à réorienter notre approche, du jugeant vers l’apprenant. Toutefois, comme nous l’apprends le 4ème chapitre, nous sommes tous des jugeants qui cherchent à s’en sortir. Aussi faut-il l’accepter et savoir repérer nos moments de jugements pour nous réorienter. C’est sur ce dernier point que se focalise le chapitre 6 : les question permettant de « switcher » du jugeant vers l’apprenant. Le chapitre 7 y ajoute un outil, le « ABCD process » pour questionner nos postulats.

Lire la suite

Note de lecture : CoreOS in Action, par Matt Bailey

Note 3 ; Malheureusement je ne suis pas un ops…

Je voulais vraiment en savoir plus sur CoreOS. Chemin faisant, je savais que je risquais une lecture qui pouvait s’avérer ennuyeuse pour moi, sinon hermétique. C’est surtout la brièveté de l’ouvrage qui m’aura permis de survivre, le texte n’étant vraiment pas fait pour moi.

Bref, le texte l’est avec seulement 175 pages et 10 chapitres (donc des chapitres assez courts en moyenne). L’ensemble est divisé en 3 parties. La première d’entre-elle « getting to know CoreOS » comprends 3 chapitres. Et on commence bien sûr par une introduction au système, d’une quinzaine de pages. Cette introduction doit nous donner une image de haut niveau de CoreOS, qui un OS « statique », dont les composants majeurs sont fleet et etcd. Mais pour moi, l’angle est déjà bien trop « système ».

Les 18 pages du chapitre 2 sont consacrées à faire fonctionner CoreOS sur une machine de dev, dans un environnement Vagrant, lui-même dans une machine virtuelle VirtualBox. En sachant que ce n’est pas un mais 3 CoreOs que l’on souhaite faire fonctionner, cela donne une idée de la configuration : pas vraiment une partie de plaisir pour moi. Je sombre encore un peu plus au chapitre 3 « expecting failure » qui rentre dans les arcanes d’etcd, le tout pimenté de configuration Ngnix !

Lire la suite

Note de lecture : Implementing Domain-Driven Design, par Vaughn Vernon

Note 3 ; Quand implémentation rime avec confusion.

C’est un beau pavé de presque 600 pages que nous a produit l’auteur. J’avais pas mal d’espoirs sur celui-ci, en effet malgré l’ampleur du mouvement DDD suscité par Eric Evans, j’ai toujours eu pas mal de difficultés avec le niveau stratosphérique de son propos. Avec ce volume orienté implémentation, je pensais régler ce problème. Nous n’y sommes pas et il s’en faut de beaucoup. Certes il y a du code, quoique souvent avec des « leaky abstractions » : pourquoi donc le choix de la stratégie de persistance devrait-il influer le modèle du domaine ? On arrive au pire avec les « values object » où l’on dit à demi-mot qu’il s’agit d’un choix technique ! L’étude de cas n’aide malheureusement pas beaucoup : elle manque de vie, son propos est trop abstrait et bien que le choix du sujet soit très pertinent pour moi, j’ai eu toutes les difficultés à le suivre. J’oublie encore les interludes « cow-boy logic » sensés donner de la légèreté au texte, mais incompréhensibles pour les non-américains.

Le premier chapitre est en quelque sorte le « business case » du DDD. On n’y apprends pas grand chose mais au moins le texte est compréhensible ainsi que les extraits de code. Tout de même, 42 pages pour cela… C’est d’ailleurs la taille du second chapitre « domain, sub-domain & bounded-context ». Les 3 niveaux de structuration rendent le propos difficile à suivre et à mon avis d’une complexité non-nécessaire. De plus l’exemple choisi (identity & access control) n’est guère pertinent. Il en résulte que l’on sort du chapitre avec peu d’éléments pour déterminer la granularité du bounded context mais avec un gros mal de tête sur les notions avancées.

Le chapitre 3, context map est un court interlude qui évoque la projection d’un bounded context sur un autre. C’est intéressant sans être mortel. Polluer le propos avec du http ou du rest est non seulement inutile mais hors de propos. Malheureusement, c’est récurrent dans tout le livre. Contrastant avec cela, le chapitre 4 « architecture », c’est du sérieux avec ses 56 pages ! On y évoque différents types architecturaux comme le modèle en couche et l’architecture hexagonale d’Alistair Cockburn. Il évoque aussi le DIP qui n’est jamais que la même intention que l’Adapteur au centre de l’architecture hexagonale, ce qui ne semble pas effleurer l’auteur. Le CQRS est à peu près compréhensible, ce qui n’est pas le cas de l’Event-driven architecture, bien qu’il faille concéder une représentation intéressante intégrant l’architecture hexagonale. Le pipe and filter est juste évoqué et les « sagas » c’est à dire les transactions applicatives sont plus à décoder qu’à lire. L’Event-sourcing et les data frabric ont aussi doit à quelques mots. Dans l’ensemble le chapitre est bien trop long pour son contenu ?

Lire la suite