Note de lecture : The Professional Product Owner, par Don McGreal & Ralph Jocham

Note : 6 ; Une solide lecture pour le Product Owner, qui ne reste pas figée dans le dogme Scrum mais s’égare parfois un peu.

La Scrum.org s’est impliqué dans l’écriture de son corpus de connaissances et de pratiques. Le présent volume consacre celui dévolu au Product Owners. Comme nous allons le voir, c’est globalement une bonne surprise, même s’il nous embarque dans quelques hors sujets.

Les 320 pages du présent ouvrage sont découpées en seulement 9 chapitres structurés en 3 parties. Nous voilà donc embarqués dans des chapitres plutôt conséquents. La première partie « strategy » couvre 4 chapitres, soit un peu plus de 100 pages. Le premier chapitre est lui consacré à la gestion de produit agile. On y retrouve quelques poncifs habituels tels que le triangle de fer. Plus intéressant sont les propos sur les boucles de valeur et surtout les « roles type » qui offre une vue originale des profils de maturité du product ownership.

La vingtaine de pages du second chapitre va aborder la Vision. Le propos tourne autour de quelques pratiques désormais bien connues : le business model canvas, la product box et l’elevator statement. Le propos est bien ficelé, mais les habitués n’y découvriront pas grand-chose. Arrive le chapitre 3 et un sujet tout à fait épineux : la valeur ! Les auteurs lui accordent un peu moins de 40 pages. Les auteurs ont quelque peu du mal à trouver un angle, aussi commence-t-on avec « l’évidence-based management », ce qui a au moins le mérité d’introduire le sujet pour évoquer ensuite la satisfaction des employés et des utilisateurs (avec l’inévitable NPS). Après cela, ça part un peu n’importe comment en parlant budget, taux d’innovation, etc. Un chapitre qui n’est pas mémorable, sur un thème particulièrement difficile.

Lire la suite

Sponsored Post Learn from the experts: Create a successful blog with our brand new courseThe WordPress.com Blog

WordPress.com is excited to announce our newest offering: a course just for beginning bloggers where you’ll learn everything you need to know about blogging from the most trusted experts in the industry. We have helped millions of blogs get up and running, we know what works, and we want you to to know everything we know. This course provides all the fundamental skills and inspiration you need to get your blog started, an interactive community forum, and content updated annually.

Note de lecture : Enterprise Integration Patterns, par Gregor Hohpe & al

Note : 8 ; Un très grand classique !

Cet ouvrage s’inscrit dans la continuité du « Patterns for Enterprise Applications » de Martin Fowler. Plus exactement, il traite de l’intégration d’application asynchrones par le biais de messages. Cette imposante référence regroupe 65 patterns, décrits au long des 650 pages de cette imposante référence. L’ensemble est découpé en seulement 14 chapitres.

Le premier chapitre est déjà conséquent avec près de 40 pages. Les auteurs y construisent un exemple d’intégration d’application fictif allant jusqu’au monitoring et montrant comment et pourquoi chaque pattern y prend place. Cela me rappelle quelque peu le premier chapitre de l’Enterprise Applications Patterns de Martin Fowler. Par contraste, le second chapitre est bien plus succinct avec ses 17 pages. Il s’agit ici de patterns stratégiques décrivant les différents styles d’intégration : transfert de fichiers, base de données partagée, échanges de messages, appels de procédures distantes, etc.

Le chapitre 3 s’attache à zoomer sur un seul des styles d’intégration décrit précédemment : l’échange de messages. Les patterns figurant ici décrivent les différents composants de cette structure : messages, endpoints, chanel, routeurs, transformateurs, etc. Nouveau coup de zoom au chapitre 4, sur un des composants de l’échange de messages : les canaux. Ce chapitre nous fait découvrir les différents types de canaux de manière exhaustive : point à point, publish and subsribe, bridge, etc. C’est l’occasion de découvrir certains patterns beaucoup moins connus que les grands classiques. Je pense, par exemple au Datatype chanel ou au Dead-letter chanel.

Lire la suite

Note de lecture : The Inmates are Running the Asylum, par Alan Cooper

Note : 7 ; Thumbs up sur le goal-directed design, thumbs down sur le processus.

Il s’agit là du livre de référence sur les Persona. Mais en fait l’ouvrage couvre bien plus largement la question de la place du design dans la conception des produits. Un propos qu’il faudra relativiser avec son écriture au début des années 2000 et même de la findes années 90, car il s’agit en fait d’une édition révisée.

C’est certainement moins vrai aujourd’hui, grâce en partie à cet ouvrage. Le père du Visual Basic nous gratifie ici d’un ouvrage de près de 250 pages découpé en 14 chapitres. Le nombre apparemment élevé de chapitres est bienvenu car il s’agit presqu’uniquement de prose ! L’ensemble est structuré en 5 parties. La première, intitulée « computer obliteracy » couvre 40 pages avec 2 chapitres. Le premier « riddles for the information age » nous propose de regarder les objets qui nous entourent pour constater à quel point l’électronique les a envahis … et à quel point notre expérience avec ces objets s’est dégradée. La phrase clé du chapitre est : quand vous croisez un objet (quel qu’il soit) avec un ordinateur, le résultat est un ordinateur ! Au second chapitre, il est question d’apologistes, de survivants et d’ours qui dansent. L’interaction avec les logiciels s’apparentent aux ours qui dansent : on s’émerveille de ce qu’ils font, mais tout bien considéré, en fait un ours ça danse terriblement mal ! Les apologistes sont les développeurs : ils imaginent que parce qu’ils sont capables de d’utiliser un ordinateur à la geek, les utilisateurs le seront ! Ces derniers s’apparentent souvent à des survivants : Bien qu’ils soient tourmentés par un système qui se comporte pour eux en dépit du bon sens, ils se conforment pour pouvoir faire leur boulot. Les deux chapitres sont de purs régals.

La 2ème partie « i twill cost you big time » regroupe 3 chapitres sur 40 pages. Le chapitre 3 « wasting money » couvre 17 d’entre elles. On y comprend que l’agilité, ce n’est pas son truc à Alan Cooper. Exhortant des « shipping late doesn’t hurt » ou les coût des prototypes, il nous invite à prendre le temps de faire des études amont bien détaillées… Le chapitre 4 signe le retour de l’ours dansant. L’auteur évoque le coût de la non qualité des logiciels : installation fastidieuse, incapable de mémoriser les habitudes de l’utilisateur ou simplement inflexibles et paresseux. Un coût qui se chiffre en perte de loyauté, comme il est évoqué au chapitre 5. Si Apple a su se rendre désirable au point que la loyauté de ses clients soit à tout épreuve, seule la position dominante de Microsoft lui a permis de contrer le manque de désirabilité de ses produits. Un atout que n’avait pas Novell et qui lui a coûté la vie alors que l’entreprise se pensait invincible.

La troisième partie prétend nous montrer comment manger de la soupe avec une fourchette. Elle compte 3 chapitres sur une quarantaine de pages. Le chapitre 6, éponyme du livre nous compte combien les ordinateurs sont différents des humains (sauf les programmeurs qui tendent à converger vers les ordinateurs) et que malgré tout on s’attend qu’ils leur ressemblent ce qui est la recette pour des catastrophes. Le développeur, parlons-en ! L’auteur l’appelle « homo logicus » qu’il oppose à « homos sapiens ». Dans ce chapitre 7, Alan Cooper évoque tout ce qui différencie ces deux espèces. De geeks oppressés par les brutes au lycée, ils sont devenus les brutes oppresseurs de leurs anciens bourreaux… C’est bien sévère ! Le chapitre 8 fera mal à certains, car il appelle la culture de la programmation, une « culture obsolète », isolationniste centrée sur les souhaits de l’ingénierie et non sur les besoins de l’utilisateurs.

Lire la suite

Note de lecture : Mastering Professional Scrum, par Stephanie Ockerman & Simon Reindl

Note : 6 ; Fidèle à l’évangile Scrum, mais de la bonne quand même !

J’avoue que je n’étais pas très confiant à l’ouverture de ce livre. Il s’agit du texte ostensiblement officiel de la Scrum.org sur le rôle du Scrum Master. Les examens de certification, même si je diverge assez peu avec les opinions sous-jacentes montrent quand même un certain dogmatisme sur les positions. Oui, je m’attendais à retrouver ce dogmatisme ici. C’est parfois un peu le cas, mais nous allons voir qu’il y a aussi (et surtout) pas mal de bonnes nouvelles.

Avec ses 160 pages (175 en comptant les annexes), il ne s’agit pas d’une lecture effrayante. Les 8 chapitres structurent le contenu en séquences tout à fait digestes. Le premier d’entre-eux « continuously improving your Scrum practice » fait un petit peu fourre-tout. On y trouve les valeurs de Scrum, les compétences des équipiers Scrum et des éléments de pratiques d’amélioration. C’est plutôt bien écrit mais c’est une entrée en matière un peu incongrue.

Le chapitre 2 « creating a strong team foundation » va nous mettre davantage dans le rythme. Tout d’abord, il est mieux ciblé sur un sujet qu’il traite en 3 volets. On commence par les savoir-être, le profil et les compétences attendues d’un membre, pour ensuite aborder le cadre de l’équipe (confiance, finalité, etc.) pour terminer sur la dynamique d’équipe avec ses phases de formation selon différents modèles (Tuckman, Satir…). C’est un chapitre très riche avec de très nombreuses références et renvois. Ce dernier point est une très bonne surprise que l’on retrouvera dans les chapitres suivants.

Lire la suite

Note de lecture : Clean Agile, par Robert C. Martin

Note : 7 ; Un « back to basics » très bien écrit et malheureusement aujourd’hui nécessaire… mais par moments trop empreint de dogmatisme XP !

Quand on ouvre un livre de Robert Martin, on est presque toujours sûr de passer un bon moment. C’est bien le cas ici, et c’est sans doute pourquoi j’ai avalé ce court opuscule en à peine 2 jours. Le sous-titre « back to basic » traduit bien la volonté de l’auteur, revenir aux sources de ce qu’est l’agilité, de pourquoi et comment la met-on en œuvre. Le retour aux sources, c’est le retour à la véritable agilité, et pour l’auteur ce ne peut être rien d’autre que Extreme Programming. Nous verrons que cela induit quand même quelques biais qui peuvent aller de légèrement irritant à franchement embarrassant.

Place au texte ! Comme énoncé, c’est une lecture fort digeste : 185 pages réparties sur 8 chapitres. C’est d’histoire dont nous parle Robert Martin dans ce premier chapitre. L’histoire telle qu’il la connait et qu’il l’a vécue. Cela couvre des éléments bien antérieurs aux années 89/90, que les non-férus d’histoire découvriront, et bien sûr l’écriture du manifeste à Snowbird. Un régal. Le chapitre se termine sur le « circle of life » d’extreme programming, car pour l’auteur agile est synonyme d’extreme programming, et en fait rien d’autre.

Le chapitre 2 couvre les raisons de faire de l’agile (oui, j’ai dit « faire »). Le chapitre incarne assez bien l’aspect « retour aux bases » avec un éclairage résolument XP et ingénierie du développement. Ce n’est pas vraiment une découverte bien sûr, ni une redécouverte pour moi, mais il pourra éclairer des nouveaux venus qui n’ont que le prisme facilitation en tête. Le plus curieux dans le chapitre 3 est le titre « business practices » qui pour moi correspond peu au contenu (pour ne pas dire pas du tout). Peut-être que selon le prisme XP, le business est tout ce qui n’est pas strictement l’ingénierie de développement ? On y aborde de manière conséquente les estimations et la vélocité ce qui, même si c’est bien et clairement abordé est tout à fait ennuyeux. La fin du chapitre sur les tests et la QA parvient tout de même à me sortir de ma torpeur.

Lire la suite

Note de lecture : Coacher une équipe agile, par Véronique Messager

Note : 7 ; Une boite à outil plutôt qu’un cadre de coaching

Faire une note de lecture d’un livre dont j’ai été l’un des relecteurs principaux n’est pas une tâche facile. De plus, j’avoue n’avoir que peu goûté les ouvrages que j’ai pu croiser sur le coaching agile. Peut-être bien est-ce au fond un manqué d’intérêt de ma part sur ce sujet ? Voyons ce qu’il en est.

Tout d’abord l’ouvrage : avec 273 pages découpés en 21 chapitres plus une conclusion il est de taille moyenne. Moi qui apprécie les chapitres de taille raisonnable, je serais plutôt satisfait, toutefois il y a une forte disparité de longueur des différents chapitres, mais rien de bien gênant.

Enfin, il faudra noter le découpage en 5 parties qui reflète une progression dans la démarche de coaching.
La première partie campe le contexte. Il faut compter 3 chapitres sur 40 pages pour cela. Si le premier d’ntre-eux parle d’agilité, ce sont bien les « comportements attendus » figurant en dernière page qui constituent le point dominant du propos. Le second chapitre forme un contrepoint mettant en relief au travers d’exemples fictifs mais inspirés de la réalité, la différence entre ce qui devrait être un acquis et l’observation du terrain. Le contraste est saisissant. L’explication arrive au 3ème chapitre avec, entre autres, l’homéostasie et le poids de nos émotions que l’auteur compare à un GPS interne.

Lire la suite

Note de lecture : Software Requirements 3rd edition, par Karl E. Wiegers & Joy Beatty

Note : 6 ; Il échoue à se mettre au goût du jour et déçoit sur sa prise en compte de l’agilité

J’avais adoré la 1ère et la seconde édition, c’est avec un plaisir par anticipation que j’abordais ce 3ème opus. J’ai l’habitude de faire perdre un point de note à une édition qui ne fait que se maintenir par rapport à l’édition précédente. Las, ce n’est pas 1 mais 3 points qu’a perdu cette édition-là ! J’avais gardé un excellent souvenir de la seconde édition et m’attendais à une modernisation conséquente du texte, plus particulièrement sur la convergence avec le mouvement et les pratiques agiles. Sur ce dernier point plus particulièrement les auteurs ne sont pas dans le coup et la déception est grande. Le texte reste un ouvrage majeur toutefois dans l’ingénierie des exigences. Voyons cela.

Ce sont 550 pages que compte ce 3ème opus, structurées sur 5 parties pour un total de 32 chapitres, hors annexes. Et ces dernières sont conséquentes. Ce n’est pas ce que l’on peut appeler une lecture légère, ni par le volume ni hélas non plus par le style. La première partie est forte de 4 chapitres sur 75 pages et va nous camper le décor de l’ingénierie des exigences. Le premier chapitre est fort bien fait, il donne la big picture des exigences, avec les différents types (dont les fameux NFR, Non functional Requirements), et comment ils s’articulent sur 3 niveaux. On y a un aperçu quoique superficiel du cycle de vie des exigences et des enjeux de leur bonne gestion. Le second chapitre est consacré aux exigences du point de vue des utilisateurs. On apprend donc à les distinguer et à identifier le décisionnaire. Le point réellement intéressant de ce chapitre sont les « bill of rights / bill of responsibilities » des utilisateurs.

Le chapitre 3 nous sert les « bonnes pratiques » du développement et de la gestion des exigences. Il y en a vraiment beaucoup. De fait, c’est un peu la table des matières de la seconde partie de l’ouvrage. Un chapitre pas spécialement sympathique à lire. Cette première partie se referme sur l’analyste : sa vie, son œuvre et ses compétences. Un chapitre bien fait, très clair sur ce qu’on attend d’un bon analyste.

Lire la suite

Note de lecture : Seriously Good Software, par Marco Faella

Note : 4 ; Le “seriously” est à prendre très au sérieux !

Ce texte n’est pas très facile à classer entre Java et Craftsmanship. S’il est résolument orienté sur la plateforme Java, c’est tout de même sur les principes d’implémentation (et un peu de conception) que l’auteur met l’accent. L’auteur, parlons-en, est professeur d’informatique à l’université de Naples. De fait, sans en avoir l’austérité, le texte a quelques ressemblances avec un support de cours.

Voyons un peu ce qu’il en est. L’ouvrage compte 9 chapitres répartis sur 2 parties très inégales, pour un total de 280 pages. On le voit, ce sont des chapitres relativement conséquents, en moyenne supérieur aux 20 pages par chapitre qui m’a toujours semblé un bon compromis. La première partie compte deux chapitres, couvrant 45 pages. Le chapitre introductif traite de la qualité ou plus exactement des qualités attendues d’un logiciel. Ce seront les points successivement développés dans les chapitres suivant, puis l’étude de cas qui nous suivra tout au long de l’ouvrage est introduite.

Le second chapitre introduit l’implémentation de référence. Une implémentation qui ne cherche à optimiser ni la performance ni l’emprunte mémoire. Toutefois l’approche adoptée pour analyser l’un et l’autre est présentée ici, grâce à cette version facilement appréhendable. Bien sûr c’est la notation O popularisée par la STL qui est utilisée pour les performances. On sent déjà le côté « support de cours » dans ce chapitre par ailleurs pas désagréable à lire.

Lire la suite