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

Publicités

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