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

Publicité

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