Note de lecture : Designing for Growth, par Jeanne Liedtka & Tim Ogilvie

Note 6 ; Bon sur le framework et le mindset design thinking. Mais le propos se perd parfois un peu en route.

Il y a finalement assez peu de littérature sur le Design Thinking. J’ai profité du MOOC avec le Pr Liedtka pour me plonger parallèlement dans cette lecture. C’est un beau livre, à l’impression bi chromique et comptant environ 200 pages auxquelles il faut ajouter les annexes. Découpé en 5 sections, il suit la logique des 4 questions qui structurent l’approche des auteurs..

Le texte s’ouvre sur une partie introductive de 2 chapitres totalisant 40 pages. Les 20 pages du premier chapitre tentent de répondre à la question « pourquoi le design ». Ce sont avec des histoires et des témoignages que des réponses sont apportées. C’est bien vu, même si cela n’apporte qu’une réponse partielle à la question. Le second chapitre de cette introduction est la « big picture » du framework : 4 questions et 10 outils. Aussi émaillé de témoignages, même s’ils sont moins percutants, le chapitre permet de s’approprier la logique de la démarche, mais pas l’essence.

La seconde partie du livre est consacré à la première question : « what is ? » sur 55 pages et 4 chapitres. Cette partie s’ouvre sur un chapitre consacré à la visualisation. Il manque cruellement de contenu concret, on reste dans la déclaration d’intention et les bénéfices attendu. Difficile d’y décerner une matière concrète avec laquelle rentrer chez soi ! Le chapitre 4 est tout l’inverse : s’il est succinct, il décrit parfaitement l’approche et le tout est brillamment illustré. Le value chain analysis est expédié à toute vitesse et c’est le « mind mapping » qui conclut cette partie. Ce mind-mapping n’est pas à confondre avec les cartes heuristiques. Il s’agirait plutôt de safaris pour partager et brain-stormer.

Lire la suite

Publicités

Note de lecture : Fifty Quick Ideas to Improve your User Stories, par Gojko Adzic & David Evans

Note : 7 ; De bonnes recettes, surtout pour le découpage des user stories

Les auteurs l’annoncent clairement dès le début : ceci n’est pas un livre pour le débutant. Il s’adresse à ceux qui ont déjà une connaissance et une compréhension de base de ce qu’est une user stories. Les 200 pages de l’ouvrage sont consacrées à solidifier cette connaissance et à améliorer le savoir-faire qui y est lié. Le tout en 5 parties et en, comme l’indique le titre, 50 idées ou principes. Je ne vais pas parler des 50 principes, ce serait fastidieux.

Chaque « idée » emprunte la même présentation. D’abord une introduction que l’on pourrait appeler « motivation ». Elle développe ce qu’il y a derrière le titre, le « pourquoi » de cette idée. Vient ensuite une section intitulée « key benefits », comme son nom l’indique elle met en exergue l’amélioration apportée par cette pratique ou le travers qu’elle évite. Enfin, la 3ème partie est consacrée au « how to make it works », c’est à dire le mode d’emploi.

La première partie est dédiée à la création de User Stories. Ce sont 8 idées sur environ 35 pages qui constituent celle-ci. On retrouve quelques idées qui font leur chemin aujourd’hui comme les « 3 C » de Ron Jeffries ou les 3 questions de Jeff Patton plutôt que le template de Mike Cohn qui perd son aura de jour en jour. Mon « take away » de cette partie est certainement la notion de sphère de contrôle liée à la sphère d’influence qui est le thème de l’idée n° 7.

Lire la suite

Note de lecture : User Story Mapping, par Jeff Patton

Note : 9 ; Bien au-delà du story mapping, vers la découverte de la vraie nature des spécifications agiles en tant que compréhension partagée. Book of the year 2015 !

Jeff Patton est un vrai maître Jeidi de l’agilité : après avoir lu, ou plutôt dévoré son livre, je n’en ai plus aucun doute ! Mais si vous pensez lire « simplement » un ouvrage décrivant par le menu la technique développée par Jeff Patton, vous allez être surpris ! Car c’est bien plus que cela.

Le livre fait un peu plus de 260 pages en 18 chapitres. Je dis « un peu plus de 260 pages » car le corps principal du livre est précédé d’une introduction « read this first » qu’il ne faut rater sous aucun prétexte. On y parle « instructions » versus compréhension partagée, de comparer les (docs de) spécification à des cahiers de voyage, de l’importance de raconter des histoire et d’être frugal dans la construction tout en cherchant à maximiser l’impact plutôt que les fonctionnalités ! Bref, cette introduction à elle seule a la valeur d’un très bon livre. Et ce n’est pas fini !

Raconter des histoires, c’est le sujet du 1er chapitre où l’auteur introduit les story maps dans le but de raconter la grande histoire du système, d’avoir une « big picture ». Il le fait d’ailleurs en racontant une histoire, celle de Gary par qui les user stories sont arrivées ! D’ailleurs la totalité du livre est formée d’histoires. Et celles-ci sont illustrées de photographies des fresques (en couleur dans la version anglaise) que sont ces stories maps auxquelles l’auteur surimpose des explications sous forme de cartographie.

Lire la suite

Note de lecture : Why Plans Fail, par Jim Benson

Note : 8 ; Où l’on parle (enfin) de biais cognitifs !

J’ai eu un peu de mal à classer ce texte. De par la nature du texte, il devrait plutôt se classer dans la gestion de projet, la gestion de projet agile pour être plus précis. D’un autre côté, la nature même du sujet me donnait envie de le classer dans l’expression de besoin : à mon avis la détection des biais cognitifs doit nécessairement faire partie de la boite à outil du Product Owner. Finalement j’ai opté pour le premier choix.

L’une des grandes qualités de ce mini-livre est sa brièveté : 82 pages (plus quelques annexes) sous un format des plus réduit. Il s’agit donc d’une lecture que l’on peut avaler en quelques jours, voir une seule journée ! Ce sont une douzaine de biais cognitifs parmi les plus fréquents qui sont évoqués ici, remis dans un contexte de projet informatique. Cela en fait un livre unique, car si le sujet est traité de manière plus extensive dans d’autres ouvrages qui font autorité et auxquels l’auteur se réfère, celui-ci est le seul à évoquer le propos dans le domaine qui nous concerne.

Le texte ne se veut pas un traitement en profondeur du sujet, mais plutôt une amorce de réflexion et de discussion autour de ces biais cognitifs. La prose est en effet découpée en 16 chapitres, qui ne comptent donc que quelques pages chacun.

Lire la suite

En finir avec les User Stories ?

Aujourd’hui je vous propose d’investiguer l’un des outils les plus emblématiques des approches agile : la User Story. Par son « focus » et la légèreté de son expression elle symbolise une part importante de ce que nous voulons faire en agile.

Créées avec l’Extreme Programming, elles ont été adoptées largement par la communauté Scrum (Scrum n’évoque qu’une notion plus générique de « product backlog item » ou PBI). Ces User Stories peuvent-elles nuire aux projets agiles ? En quoi leur usage peut-il être néfaste ?

3 mots sur un bout de carton !

…Ou sur un post-it, pour rester dans la tradition agile. Voilà qui nous change des documents de spécification tellement épuisants à compléter ! Sans compter que ces derniers sont vraiment ennuyeux : traquer la précision, chasser l’ambiguité, devoir tout justifier… Un vrai travail de romain !

Lire la suite

Quand les users stories deviennent techniques…

Je ne suis pas un intégriste de la User Story. Il ne m’importe pas tellement qu’elles suivent le fameux template de Mike Cohn « en tant que… je veux… afin de… ». Même si ce template n’a rien de mauvais et peut guider vers l’écriture de meilleurs histoires, c’est aussi un bon moyen de devenir un « template zombie ». Je préfère les 3 questions de Jeff Patton : Qui ? Quoi ? Pourquoi ?

image

En fait, peu m’importe que vous parliez de User Story, d’item de backlog ou d’un autre terme inventé de toute pièce. Ce qui va m’importer, c’est que votre story ait un sens d’un point de vue externe au système que l’on construit. C’est là qu’intervient le « qui », un acteur externe aus système. Ce n’est pas par dogmatisme que j’y suis sensible, mais au contraire par pragmatisme. Une petite explication s’impose.

Lire la suite

Note de lecture : Use Cases : Requirements in Context, par Daryl Kulak & Eamonn Guiney

Note : 6 ; Bonne mise en pratique du cycle itératif et de bonnes idées, mais pas entièrement concluant.

Ce livre présente les cas d’utilisation dans le cadre d’un processus itératif, en fait celui d’Unfied Process. A ce titre, il propose une approche incrémentale pour la spécification des cas d’utilisation, basée sur celle de Craig Larman. Cet ouvrage taille aussi un short à la gestion des exigences, par rapport auxquels les auteurs préfèrent la spécification des règles métier, même si en fait c’est surtout la production de gros documents de spécification monoblocs qui est remise en cause. La description des spécifications incrémentale est réellement valable et concrète, et de plus desservie par des exemples concrets en annexe.

La construction du livre est un peu curieuse, car les annexes forment la moitié de l’ouvrage, le texte principal ne comptant que 170 pages structurées en 11 chapitres. Le premier d’entre-eux consacre ses 18 pages à l’identification des problèmes liés à l’approche classique. La prose manque un peu d’élan lyrique, mais s’efforce néanmoins de bien synthétiser ces points d’achoppement. Disons que le boulot est fait.

Le second chapitre s’étend sur 32 pages, il s’agit d’une introduction aux cas d’utilisation d’inspiration très « Gery Schneider ». On y aborde plutôt efficacement les basiques de la représentation des cas d’utilisation et les bonnes règles de conduite. Plus globalement on y traite aussi des cas d’utilisation dans l’environnement UML. Un chapitre rondement mené.

Lire la suite

Note de lecture : Managing Software Requirements, par Dean Leffingwell & Don Widrig

Note : 7 ; Les exigences selon RUP, avec beaucoup d’éléments sur les pratiques, mais aussi un manque de matière sur la mise en œuvre.

Ce livre traite de la gestion des exigences vue par Rational Unified Process. Les auteurs ont d’ailleurs travaillé sur l’outil Requisit Pro. La lecture en est plaisante, le découpage en nombreux chapitres assez découplés bien que complémentaires y aide beaucoup. Comptez 385 pages pour ce volume qui comprend en sus près de 90 pages d’annexes ! Les 35 chapitres que les auteurs ont concoctés sont divisés, non en parties mais en 8 « skills », une petite subtilité, mais assez intelligente !

En une trentaine de pages comptant quand même 3 chapitres, la première partie fort opportunément appelée « introduction » est vite passée ! Si on s’intéresse aux grands classiques du « pourquoi » des exigences, c’est à dire le coût des exigences erronées, on arrive vite à la définition de ce qu’est une exigence au chapitre 2. C’est ici aussi que l’on introduit la pyramide problème / besoin / solution que j’aime tant ! L’auteur n’oublie pas que le développement logiciel, même dans l’ingénierie des exigences, est une affaire d’hommes et de femmes, il consacre le chapitre 3 à l’équipe et aux compétences. Bref, une première partie tout à fait sympathique.

Ce sont 3 chapitres (sur environ 40 pages) qui sont également consacrés à la seconde partie « Analyser le problème » qui est le premier « team skill » du livre. Nous voilà rentrés dans la matière. L’auteur nous propose 5 étapes pour définir le problème. Les choses sont rarement aussi simples que l’on puisse suivre une telle séquence de manière immuable, mais nombre d’analystes devraient s’inspirer de ce que l’on trouve ici : identification des acteurs, définition du périmètre du système et de ses contraintes et surtout, surtout : l’analyse causale ! La matière proposée concernant l’analyse métier est bien moins convaincante, mais on peut bien excuser de petites faiblesses… Le dernier chapitre de cette partie met surtout en musique ce que nous avons vu avec l’étude de cas du livre : HOLIS. Fort intelligemment, il ne se contente pas de reprendre la matière du chapitre 4, on y ajoute quelques petits éléments comme l’elevator statement.

Lire la suite

Note de lecture : Specification by Example, par Gojko Adzic

Note : 8 ; La référence sur le développement guidé par les tests. Book of the year 2014 !

Régulièrement, je retarde le moment d’ouvrir un livre que je sais excellent (de réputation) et qui prend la poussière sur une de mes étagères. Ce livre est de ceux-là ! Bien que Manning nous gratifie de temps en temps de titres non-techniques, il est assez étonnant de trouver celui-ci chez cet éditeur, probablement parce que ce n’est pas un livre pour remplir un vide thématique.

Il s’agit bel et bien d’un texte nous proposant un regard novateur sur les tests d’acceptance, même si l’auteur rappelle régulièrement au fil des pages qu’il fait suite à son ouvrage précédent « The Communication Gap ». Ce n’est pas non plus un livre très facile à lire, non qu’il soit volumineux car il ne compte que 250 pages, mais il s’appuie essentiellement sur de nombreux témoignages qui transforment le fil conducteur en une sorte de patchwork. Evidemment, ces nombreux témoignages qui sont autant de cas d’étude font beaucoup pour la crédibilité du texte qui est ainsi à la fois un travail digne d’un universitaire et l’œuvre d’un praticien de terrain. Venons-en au contenu.

L’ouvrage se découpe en 3 parties inégales. La première d’entre-elles ne compte que 60 pages réparties en 4 chapitres. Le premier chapitre nous laisse un peu dans le flou, il s’agit surtout d’un argumentaire étayé de témoignages sur la raison de s’intéresser à la spécification par l’exemple. On rentre dans le dur au chapitre suivant qui aborde la manière dont Gojko Adzic voit s’articuler le besoin depuis les « business goals » jusqu’à la « documentation vivante ». Les aspects amont sont par ailleurs l’objet de son ouvrage suivant « impact mapping ». On y apprend incidemment pourquoi l’auteur préfère « spécification par l’exemple » à « développement guidé par les tests d’acceptance ». Un chapitre à ne rater sous aucun prétexte ! Le chapitre 3 « living documentation » offre pour moi peu d’intérêt, sauf peut-être celui de couvrir le schéma de processus que l’auteur nous a exposé au chapitre 2 ? La spécification par l’exemple ne se veut pas une pratique spécifique aux projets agile, bien que ce soit un terrain de jeu naturel. Au chapitre 4, l’auteur aborde différentes façon de basculer d’un projet classique à l’écriture des tests en amont sous forme de patterns (bien qu’ils n’en empruntent malheureusement pas la forme).

La seconde partie est la plus imposante du livre, avec environ 130 pages et 6 chapitres. C’est le cœur de l’ouvrage. Les 11 pages du chapitre 5 « deriving scope from goal » sont un prélude à « impact mapping » et on y retrouve les mêmes thèmes. Je ne peux qu’en recommander la lecture. Le chapitre 6 est un de mes thèmes préférés car on y évoque la spécification collaborative. Tous les patterns de cette vingtaine de pages valent de l’or. J’applique déjà certains d’entre eux mais trouve ici des éléments pour m’améliorer. Encore un chapitre à ne pas rater.

Les deux chapitres suivants sont au cœur de l’ouvrage. Le chapitre 7 aborde l’écriture même des tests, comment les concevoir, comment les penser pour couvrir une spécification. Là encore ce sont des patterns desquels se dégage une stratégie claire et précise : sur la conception des tests, des cas passants et non passants, des données de test et des exigences « non fonctionnelles » ! Le chapitre 8 est un approfondissement du précédent, avec un accent mis sur les antipatterns.

Il était probablement difficile de parler de ce sujet sans évoquer les questions d’automatisation. C’est ce que font les 2 chapitres suivant. Le chapitre 9 évoque les options techniques d’automatisation y compris l’épineuse question des IHM. Le chapitre 10 se préoccupe surtout de l’intégration de ces tests dans des plateformes d’intégration et des stratégies possibles : isolation des systèmes tiers, plusieurs niveaux de validation, etc. Le chapitre 11 qui clos cette partie reprend le thème de la « documentation vivante ». Les patterns n’y sont pas sans intérêt, mais il reste le chapitre le plus léger de cette partie.

La Troisième partie est consacrée aux études de cas, c’est à dire les projets principaux (pas tous) qui ont donné la matière au livre. Des 7 chapitres qui la compose, 6 sont consacrés à ces études de cas sur 40 pages. J’ai eu du mal à me passionner pour cette partie. Y sont exposés les challenges auxquels ces différents projets ont été exposés à leur passage à le spécification par l’exemple, pourquoi ils l’ont fait et ce qu’il y ont appris.

Le dernier chapitre du livre nous livre les conclusions de l’auteur. L’une des plus importantes me semble être le passage d’une pratique des tests basée sur la défiance (coûteuse et inefficace), à une dynamique basée sur la collaboration et la confiance. Pas étonnant que cette pratique marche mieux en milieu agile.

L’ATDD ou plutôt la spécification par l’exemple est aujourd’hui ce que je considère comme un des plus forts effets de levier pour un projet agile, une fois acquis les pratiques d’ingénierie. L’auteur aborde les différents aspects (collaboration, processus, écriture et conception) avec un regard aiguisé que corrobore des données de terrain. En le lisant, je suis passé du « waouh effect » au « mais bien sûr » jusqu’à « ah oui, c’est ce que je fais et ça marche du tonnerre ». Cet éventail de réactions me rappelle la lecture du Design Patterns. Une autre façon de dire que je pense qu’il s’agit là d’un texte majeur !

image

Référence complète : Specification by Example, How successful teams deliver the right software – Gojko Adzic – Manning 2011 – ISBN : 978 1617290084

Specification by Example

https://www.goodreads.com/book/add_to_books_widget_frame/1617290084?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on