Note de lecture : Agile Game Development with Scrum, par Clinton Keith

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Un texte honnête, finalement peu spécifique au domaine du jeu, mais qui accuse un peu son âge.

Pour une « simple » déclinaison de Scrum à l’univers du jeux, l’addition est un peu sévère avec ses 325 pages. Quand on regarde la date de publication, on voit qu’il date d’une époque où le sujet n’avait pas encore envahis chaque recoin de notre bibliothèque. Fort logiquement il reprend un certain nombre de basiques. Je pensais rentrer dans un univers très différent, mais c’est finalement peu le cas comme nous le verrons.

Le livre comprend 5 parties, pour un total de 16 chapitres. Belle bête, donc. La 1ère partie maigre d’une trentaine de pages sur deux chapitres est un avant-propos, au domaine du jeu et au développement agile. Le domaine du jeu est traité dans le chapitre introductif. L’auteur y aborde efficacement la course à l’armement des studios de développements conduisant à une crise du logiciel spécifique de ce secteur. La vingtaine de pages du second chapitre serait classique si l’auteur n’y avait introduit quelques concepts spécifiques du domaine du jeu : phases de pré-production / post-production et recherche du « fun », par exemple.

La seconde partie, avec ses 90 pages et ses 4 chapitres est plutôt indépendante du domaine concerné. Le chapitre 3 s’intitule sobrement « Scrum ». On y trouve sur ses 22 pages ce qu’on peut s’attendre à y trouver. Seuls les exemples sont empruntés au monde du jeu. La prose est bien écrite, avec quand même certains partis pris. Le déroulement du Sprint est au menu du chapitre 4. Là non plus nous ne trouverons une prose se démarquant réellement des grands classiques. Nous arrivons ainsi au chapitre 5 évoquant les user stories. Pas non plus beaucoup d’originalité ici également. On évoque longuement le « INVEST » comme à l’accoutumée. Plus original, le découpage hiérarchique des stories me laisse toutefois un peu perplexe. Enfin, l’agile planning n’est probablement pas mon sujet préféré, mais je dois avouer que le chapitre 6 qui lui est consacré est de bonne teneur. Il me rappelle quelque peu « agile estimating and planning » de Mike Cohn. C’est dire…

Lire la suite →

Note de lecture : Refactoring to Patterns, par Joshua Kerievsky

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Un grand sujet, traité avec acuité, mais parfois présenté de façon un peu fastidieuse !

Joshua Kerievsky est donc le premier à avoir franchi le fossé entre le refactoring et les patterns ! Nous devons lui en être reconnaissants. L’intérêt et l’expérience de l’auteur (notamment en tant que créateur du « new York patterns group ») l’ont conduit à aborder les patterns non pas comme des éléments initiaux de conception, mais comme des solutions à des problèmes, donc des éléments de conception émergentes, ce qui nous amène au refactoring ! La conception émergente via les patterns est le thème et l’intérêt central du livre et en font sa valeur.

Le sujet va nous occuper au long des 350 pages découpés en 11 chapitres que forme cet ouvrage. Au chapitre 1, l’auteur nous livre la démarche que l’a conduit à ce texte. En partant tout d’abord des patterns pour obliquer vers le refactoring et le cycle TDD, pour revenir enfin vers les patterns, pour améliorer la conception sans tomber dans l’over engineering. Le second chapitre est consacré au refactoring. Il ne s’agit pas là, en une douzaine de pages, de reprendre le propos de Martin Fowler, mais simplement de se focaliser sur l’intention et l’essence de cette démarche.

L’introduction aux patterns du chapitre 3 n’est ni vraiment utile, ni spécialement éclairante. Le chapitre est court mais assez vague sur la nature des patterns, le propos se concentrant plutôt sur l’histoire personnelle de l’auteur… Les Code Smells du chapitre 4 souffrent moins de ce défaut, Joshua Kerievsky nous gratifie ici des odeurs les plus rependues. Il s’agit plus d’un mini-catalogue que d’une introduction.

Lire la suite →

Note de lecture : Modélisation de systèmes complexes avec SysML, par Pascal Roques

Le par addinquydans Notes de lecture1 commentaire

Note : 5 ; Succinct et fait le boulot, mais pas spécialement agréable à lire.

J’ai passé l’époque où j’avalais les bouquins de modélisation au kilomètre. Mais la modélisation système, domaine dont j’ignore tout attisait ma curiosité. SysML, c’était pour moi l’occasion d’assouvir celle-ci, car maîtrisant parfaitement UML, j’étais à peu près sûr de ne pas être largué. Objectif rempli de ce côté. Je connais les livres de Pascal Roques sur UML (j’en ai même lu plusieurs éditions successives), je suis donc aussi parti confiant sur la qualité de la prose.

Le livre en lui-même est court : 136 pages hors annexes (et presque 170 en les comptant. Le tout est structuré sur 10 chapitres en 4 parties. J’ajoute que les illustrations abondent (ce qui est normal pour un livre traitant de modélisation), autant dire qu’il s’agit d’une lecture rapide. Là aussi, cela me convient dans le principe. Avant même d’aborder la première partie, le premier chapitre introduit le sujet sur une quinzaine de pages. On y évoque les normes et organismes liés à la modélisation système et une ébauche très abstraite de SysML. C’est assez aride et finalement peu instructif, à part si on aime les normes.

La première partie comprend 3 chapitres sur un peu moins de 30 pages et a pour objet la modélisation des exigences. Elle s’ouvre sur un chapitre 2 qui adresse, tambour battant, les cas d’utilisation en moins de 10 pages ! La prose est claire mais ne peut couvrir le sujet en profondeur. Elle aborde néanmoins les relations d’inclusion et d’extension et même la généralisation qui est à peu près inutile à mon avis. Mais les explications sont vraiment succinctes. L’auteur insiste sur son dogme favori : la limitation de la modélisation à 20 cas d’utilisation, quitte à transformer les UC en sorte de thèmes. Une approche que je ne partage pas, tout comme la plupart des auteurs. Je trouve cavalier de présenter cela comme une vérité.

Le diagramme de séquence est traité encore plus rapidement en 7 pages. L’auteur parvient à bien illustrer et expliquer les subtilités de ce diagramme qui ne sont ni plus ni moins que celles d’UML 2.0 dans cet espace réduit. Je retrouve l’angle du cours Valtech et de « UML en Action » consistant à positionner le diagramme de séquence au niveau de l’expression des besoins, alors qu’il s’agit d’un usage particulier, voir détourné. Mais ce n’est pas grave. 7 pages encore pour le diagramme d’exigences qui est lui bien spécifique de SysML. Là aussi c’est efficacement expliqué et illustré, mais je suis un peu frustré par la brièveté du chapitre qui faisait partie de mes grandes attentes, certaines subtilités me semblant même passées sous silence.

Ce sont 3 chapitres également qui sont compris dans la seconde partie, consacrée à la modélisation d’architecture. Le diagramme de définition de blocs (BDD) a droit à une quinzaine de pages. Sans le nommer il fait le pendant au diagramme de classes d’UML. Là encore la prose est claire, le boulot est bien fait.

Près de 20 pages sont dédiées au diagramme de bloc internes (IBD) au chapitre 6. Il s’agit d’un sujet complexe avec des subtilités assez compliquées au niveau du concept de ports. L’auteur s’en sort plutôt très bien sauf quand on arrive sur les nouveaux types de ports de SysML 1.3 où le propos devient trop abstrait. Autre problème plus embêtant : ces diagrammes font apparaitre des subtilités au niveau de la notation graphique qui sont mal rendues au niveau de l’impression. Pour un aussi petit ouvrage vendu 35 €, c’est inacceptable. Le diagramme de package est couvert en 5 pages, mais il y a peu à en dire. Petit regret quand même sur les stéréotypes « model », « view » et « viewpoint » qui, à l’exception de ce dernier, sont mal expliqués.

Sans surprise, c’est la modélisation dynamique qui est au menu de la 3ème partie. Une quinzaine de pages sont dédiées au diagramme d’état. A l’échelle de cet ouvrage, c’est un gros chapitre. Je retrouve l’angle du cours Valtech (qui s’étendait sur 2 chapitres sur ce sujet) consistant à rentrer dans les plus petits détails de cette notation, jusqu’aux extraordinairement peu usités « deep history ». Il en est de même ici. Peut-être que SysML fait-il plus usage de diagrammes d’états que moi avec UML ? Disons simplement que tous les aspects de la notation ne sont pas logés à la même enseigne. Le chapitre 8 est un exemple du genre : il couvre sur 15 pages aussi les subtilités du diagramme d’activité en les introduisant progressivement. Beau boulot ! Tout comme au chapitre 6, la notation qui devient fouillée avec les concepts de flux est rendue difficilement lisible du fait de la médiocrité de l’impression.
La dernière partie traite de « modélisation transverse » sur 2 chapitres. Il s’agit d’aspects qui sont particuliers à SysML. Le chapitre 9 nous invité à découvrir le diagramme paramétrique sur 5 pages. C’est bien et clairement fait, même si je ne peux m’empêcher d’être frustré par la brièveté du chapitre : n’y a-t-il rien d’autre à dire ? C’est ce genre de sujets que j’étais venu découvrir. Le dernier chapitre est dédié aux concepts d’allocation et traçabilité. Il a droit à 8 pages, ce qui est plus qu’assez pour couvrir le sujet.

J’ai eu ce pour quoi j’étais venu. Je trouve toutefois le texte un peu court sur un certain nombre de sujets, mais l’efficacité du propos fait partie des qualités que je recherche : le plus gros investissement dans un livre, c’est le temps passé à le lire. Pascal Roques m’a habitué à une prose de grande qualité et je l’ai trouvé ici plus austère qu’à son habitude. Peut-être est-ce ma perception qui a changé ? Je connaissais les biais de modélisation de l’auteur, entre autres sur les cas d’utilisation. Nous avions déjà des « discussions de clans » sur ce sujet chez Valtech. Je vois que cette ligne n’a pas changé. Bref, un texte qui sans être enthousiasmant fait le boulot. Sauf pour le rendu des diagrammes.

Référence complète : Modélisation de systèmes complexes avec SysML – Pascal Roques – Eyrolles 2013 – ISBN : 978 2 212 13641 8

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

Le par addinquydans Notes de lectureLaisser un commentaire

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 →

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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 →