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 : The People’s Scrum, par Tobias Mayer

Note : 9 ; Scrum niveau « Ri ». Book of the year 2013 !

Le livre ne paie pas de mine : un petit format qui compte environ 150 pages et une annexe de 3 pages (la description de Scrum selon l’auteur !). Le contenu lui-même vient d’une sélection de posts de l’auteur en provenance de son ancien blog : Business Craftsmanship. Les posts eux-mêmes ont été un peu retouchés, mais à peine ! Le volume se présente donc en 3 parties, chacune découpées en environ une douzaine de posts.

Ainsi décrit, il n’y a rien qui attire spécialement l’attention ! Ce qui attire vraiment l’attention, c’est le contenu même des posts, l’angle pris par l’auteur. Ici, nul focus sur l’aspect folklorique des méthodes agiles. D’ailleurs on ne parle même pas de méthode, mais de communication, de savoir-être et de culture ! C’est un point de vue original et disruptif sur Scrum, où l’auteur met d’avantage le doigt sur l’aspect dépouillé du framework qui laisse la place à ce qui compte vraiment. Voyons cela, justement.

La première partie, « The Intrepid Explorers » est composé de 13 posts, qui couvrent 35 pages. Parmi ceux-ci, je retiendrai « the heart of Scrum », qui présente le Scrum board comme un forum de communication pour l’équipe, « distributed teams are not teams » qui pose bien la posture tranchée de l’auteur. « The agile explorer » est très significatif du point de vue de l’auteur sur l’approche agile, un état d’esprit de perpétuelle découverte, de remise en cause de l’organisation pour implanter l’ADN agile. Bien entendu, on ne peut faire l’impasse sur « the people’s Scrum » qui donne son titre au livre, véritable profession de foi de l’auteur sur sa vision humaniste de l’agilité.

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

Note de lecture : Business Model, nouvelle génération par Alexander Osterwalder & Yves Pigneur

Note : 9 ; Une approche disruptive du marketing tourné vers l’innovation. Un contenu de qualité qui devrait faire partie du bagage de base. Book of the Year 2013 !

Voici un ouvrage qui ne ressemble à aucun autre. Contrairement à mon habitude, j’ai acheté la version française, sans qu’il n’y ait de raison à cela. Visiblement la qualité de la traduction ne compromet pas le contenu. Une bonne nouvelle ! La chose qui frappe le plus lorsque l’on feuillette ce livre au format très inhabituel est la mise en page sophistiquée où chaque page semble être une maquette. En fait, on a même l’impression d’être face à une plaquette marketing, ce qui fait craindre que le contenu ne soit pas à la hauteur des espérances…

Coupons court au suspens : cette crainte est infondée. En fait la mise en page accentue et supporte le contenu. Mais il est temps de parler de ce dernier. Le livre (je n’ose dire « le texte ») compte 280 pages regroupées en 5 parties principales.

La première partie constitue la fondation du reste, car elle présente l’outil de base de l’approche Business Model Generation : la canevas. Les auteurs suggèrent ainsi, plutôt que de produire de lourds et fastidieux business plans de produire un canevas sous forme de poster découpé en 9 aires. Les 50 pages de cette première partie sont consacrées à décrire ces 9 aires.

La seconde partie montre 5 typologies de business, exemples à l’appuie et montre comment ces typologies se présentent dans la canevas. Une excellent façon d’illustrer et comprendre l’utilisation du canevas.

La 3ème partie, « design » s’éloigne un peu du Canevas pour s’intéresser aux techniques d’innovation permettant la génération d’idées. Ce sont 6 techniques qui sont passées en revues au long de 70 pages consacrées à cette partie : connaissance du client, design thinking, story telling, prototypage, etc… Chacune de ces technique est un champs de connaissance à part entière, mais la façon dont chacun d’entre eux est traité en fait une excellente introduction.

40 pages (seulement, pourrait-on dire) sont consacrées à la stratégie qui constitue la quatrième partie du livre. On y couvre la compréhension des éléments environnementaux (forces du marché, forces du secteur, tendances et forces macro-économiques), l’évaluation des modèles économiques basée sur le SWOT, la stratégie « océan bleu » et le support de plusieurs modèles économiques. Finalement, beaucoup de matière en si peu d’espace !

La cinquième partie parle processus de création du modèle économique. Celui-ci se décline en 5 phases : mobiliser, comprendre, concevoir, déployer et gérer.

Il n’y a pas une forces, mais des forces dans ce livre, qui en font à mon avis une lecture incontournable.

La présentation du Business Model Canvas. Celui-ci a été depuis repris et adapté par Ash Maurya et présenté dans son ouvrage : Running Lean. A vous de voir celui qui vous paraît le plus adapté.

Chacune des parties aborde une face importante de la construction du business model et est elle-même structurée en différents volets articulés entre eux. C’est presque comme si l’on avait 5 livres en un seul ! De nombreux sujets sont traités et le livre en est une excellente introduction. Il est toujours possible de creuser chaque sujet avec des contenus spécialisés.

La construction graphique du livre avec sa mise en page sophistiquée en font un outil pédagogique d’une rare efficacité.

Le seul défaut que je vois à ce livre est la fragilité de sa reliure ! L’objet est donc hélas à manier avec précautions (et/ou à ne pas prêter à tout le monde). Cette réserve mise à part, la conclusion ne fait aucun doute : un livre à lire ! 

Business Model Genaration

Référence complète : Business Model, nouvelle génération – Alexander Osterwalder & Yves Pigneur – Pearson education France 2011 (V.O . : Business Model Generation ; John Wiley & sons 2010) – ISBN : 978-2-7440-6487-6

Business Model Nouvelle Génération: Une Guide Pour Visionnaires, Révolutionnaires Et Challengers


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

Note de lecture : OMT, Modélisation et conception orienté objet, par James Rumbaugh & al.

Note : 7 ; Un livre dense, presque indigeste (tout comme le style), mais bourré d’information. Book of the year 1996 !

OMT est LA méthode sur laquelle a été construit UML, et doit constituer environ 70% de cette notation. Ce livre est évidemment la référence sur le sujet. Les 500 pages qui le constitue sont très dense (aussi bien du point de vue informatif que du point de vue typographique) et traite les aspects méthodologiques sur un spectre très large : notation, analyse des besoins, conception, développement, mapping vers les bases de données, etc… Cette masse d’information est structurée en 20 chapitres regroupés en 4 parties. 50 pages sont consacrées aux annexes.

Une courte introduction nous remet dans le contexte de l’appréhension de l’objet en ce début de décennie 90 : elle accorde moins de place à l’analyse fonctionnelle et dissocie fortement modèle d’analyse et modèle de conception (l’implémentation, c’est encore autre chose) avec une prédominance pour le modèle d’analyse ! Bien entendu, sur les modèles objets, une importance ridicule était aussi portée aux arbres d’héritages : plus ils sont profonds, plus ça fait virile !

La première partie aborde les concepts de modélisation. Le tarif est de 5 chapitres et 130 pages. On commence par un chapitre 2 ultra court qui nous donne les définitions des différents modèles. Ce qui doit être dedans et ce qui ne doit pas l’être est très clair. Ca rigole pas. Au chapitre 3, on passe en revue la notation des diagrammes de classes, mais surtout toutes les subtilités concernant les associations (multiplicités, noms d’association et de rôles, agrégations, généralisations, qualifiers, attributs et associations n-aires). S’il est complet, le texte reste très touffu et pas réellement prévu pour être pédagogique. Mais comme c’est ainsi tout au long du livre, je vais arrêter de le dire. Le chapitre 4 prolonge le 3 avec des concepts avancés que l’on retrouvera plus tard dans UML : notions d’héritage disjoint, de contraintes, etc… On aborde enfin le modèle dynamique au chapitre 5. On s’y focalise sur les diagrammes d’état et on n’y va pas avec le dos de la cuillère ! On y trouve tous les trucs tordus qui ne servent qu’à quelques zombies du temps réel (et qui a fait les beaux jours de certains cours Valtech). Enfin le chapitre 6 vaut le détour car on n’y parle du modèle fonctionnel (modèle de traitements, mais surtout flots de données) qui n’ont pas été du tout (heureusement) retenus dans UML. A mon humble avis, c’est inexploitable.

La seconde partie va nous occuper sur 6 chapitre et couvre aussi 130 pages. Elle va traiter de méthode de conception. Comme pour la partie précédente, on commence par un chapitre 7 qui présente la méthode OMT dans ses grandes lignes. Car à cette époque, méthode et notation étaient deux concepts liés, tout le temps ! Le chapitre 8 aborde l’analyse, l’aspect le plus important d’OMT. Le recueil des besoins est balayé en 2 pages, pourtant on y trouve de petites remarques pleines de finesses mais qui ont disparu lors des mises en œuvre. La démarche est guidée et illustrée par une étude de cas : le guichet automatique de banque : on passe des classes candidates au modèle objet, que l’on raffine. Puis un modèle dynamique (un diagramme d’état) met en musique les scénarios évoqués. Et hop ! grâce à ça, on obtient les opérations que l’on n’a plus qu’à ventiler sur les classes ! Elle est pas belle la vie ? Le chapitre 9 parle de conception. En principe. On voit bien que ce n’est pas le trip des auteurs car ça part un peu dans tous les sens : sous-systèmes, partitionnement, couches, infrastructure matérielle ( ??). Bref, on s’est senti obligé d’y mettre quelque chose, sinon c’est pas crédible. Le chapitre 10 est un guide de conception des classes, pour les auteurs, c’est un retour en terrain connu, mais pour le lecteur c’est assez difficile d’emboiter cela avec le chapitre 8…  Le chapitre 11 résume les étapes de la méthode vu précédemment. C’est très clair et franchement une bonne idée. On conclu cette partie par une comparaison des méthodes. Je pensais voir un chapitre tarte à la crème, j’ai été (agréablement) surpris : les auteurs font un travail méticuleux de comparaison avec les approches structurées (SA/SD, Jackson), orientées entités (ER de Chen) et orientées objet (Booch, Yourdon, schlaer et Mellor). Ils mettent en avant chaque fois les atouts et les faiblesses, voir les complémentarité par rapport à OMT. J’ai rarement vu un travail de cette qualité.

La troisième partie nous parle d’implémentation, et sur 5 chapitres et 120 pages. Comme à l’accoutumée, le chapitre 13 sert d’introduction. On parlera d’implémentation par des langages de programmation, sur des bases de données et même au-delà des ordinateurs ! Le chapitre 14 va parler de style de programmation et je m’attends au pire. Et c’est le choc, car on n’y trouve rien de moins que ce que l’on trouvera bien des années plus tard sous la plume de Robert C. Martin ! Bravo ! Le chapitre 15 évoque la transformation de modèles vers des langages objet tels que C++, Eiffel et Smalltalk. Tout ce ci ne m’apprends rien, mais les auteurs ne prennent pas les chemins de traverse et font remarquablement bien le boulot ! C’est au tour des langages non objet au chapitre 16, en l’occurrence C, Ada et Fortran. Là aussi, un grands coup de chapeau pour la qualité du travail, qui est ici plus difficile. On se tourne vers les bases de données au chapitre 17. J’ai moins été impressionné ici, mais le boulot est fait.

La quatrième partie est plus courte, elle ne compte que 3 chapitres sur moins de 50 pages. Le chapitre 18 traite d’une application développée chez GE (où travaillait alors James Rumbaugh) : un compilateur de diagramme. J’avoue ne pas avoir été convaincu. Au chapitre 19 on voit rapidement un système de conception d’animation, l’occasion pour les auteurs de parler rapidement de la mise en œuvre de la méthode sur la partie analyse. Enfin, au chapitre 20, c’est une petite étude de cas sur la distribution d’électricité. Cette dernière partie ne m’aurait pas manquée si elle n’avait pas été là.

De nombreux aspects de ce livre sont d’un autre temps, comme le couplage indissociable entre méthode et notation, ou l’emphase exagérée sur le modèle d’analyse, un traitement grotesque du recueil des exigences et un quasi mépris pour la conception. Tout ceci ne me manquera pas, je n’ai jamais été en phase avec cette façon de voir. Pourtant le livre mérite l’intérêt à plusieurs égard. D’abord parce qu’il est simplement le meilleurs représentant de cette époque. Ensuite car de nombreux sujets sont traités avec finesse, rigueur et profondeur. Les auteurs ne mégottent pas sur la qualité de l’information. Enfin, OMT constitue la majeure partie de la notation UML. Et si des livres (de nombreux livres) couvrent la notation, cette seconde vie a en quelque sorte prolongé la pertinence de celui-ci. Toutefois, c’est surtout l’aspect historique qui nous retiendra aujourd’hui.

OMT, par James Rumbaugh

Référence complète : OMT, Modélisation et conception orienté objet – James Rumbaugh, Michael Blaha, Frederick Eddy, William Premerlani & William Lorensen – Masson 1995 (V.O. Prentice Hall 1991) – ISBN : 2-225-84684-7

Omt, Tome 1:  Modélisation Et Conception Orientées Objet

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

Note de lecture : Effective Enterprise Java, par Ted Neward

Note : 9 ; Un pur régal ! Book of the year 2005 !

Ce livre mérite bien son titre, car il fait honneur à son grand frère (effective C++), à la fois sur la qualité, la pertinence et la technicité de son contenu, mais également sur le style agréable, vivant et parfois même humoristique (ce qui tire aussi parfois le niveau d’anglais un peu vers le haut). Je ne suis pas vraiment un expert J2EE, mais le livre m’a accroché, car sans être débilitant, il exprime clairement les concepts, mais surtout il s’appuie et développe les principes d’architectures sous-jacents. En fait, le livre aurait pu s’appeler: “effective enterprise applications with J2EE”. Loin d’être un reproche, cela confère de la solidité à l’ouvrage, et même de la pérennité par rapport aux futures évolutions des API. Dans la lignée de “l’effective series” le livre démythifie les API J2EE, et met en perspective la réalité des applications d’entreprise par rapport aux discours commerciaux des vendeurs des serveurs d’application, abordant clairement les aspects que l’architecte “ne peut ignorer” ! Les différentes facettes de l’architecture sont abordées, même celles souvent à peine ou mal évoquées telles que les transactions et la sécurité. Les 75 items du livre sont découpés en 7 volets :

  • Architecture : Traite les sujets tels que répartition données / traitements, gestion des crashs, de la scalabilité et des aspects annexes tels que déploiement, administration et monitoring.
  • Communication : Ce chapitre traite des contextes de communications, allers-retours entre tiers et autres choix de styles de communication
  • Processing : Le traitement de ce chapitre est essentiellement focalisé sur les transactions (techniques et utilisateurs), ce qui comprends les différents types de transaction, d’isolation, ainsi que les points de reprise et es rollbacks
  • State management : Ce sujet englobe les contextes de transaction, mais surtout les sujets afférents à la persistance.
  • Présentation : ce court chapitre traite des clients riches et de la séparation traitement / présentation.
  • Sécurité : Peut-être un des chapitres les plus étonnants, car outre que j’y ai appris pas mal de choses (connaissez-vous le « SQL injection », l’attaque la plus simple et la plus courante qu’un site puisse subir ?), l’auteur met l’emphase d’avantage sur le processus que sur la technique !
  • System : On retrouve ici toute la plomberie bas niveau : garbage collecting, sérialisation, etc…

Au premier abord, le livre est déconcertant, car épais de 450 pages, il ne présente quasiment aucun diagrammes (en présenter quelques uns aurait pu aider), un peu de code (mais cela reste raisonnable et ciblé), mais les craintes s’envolent une fois la lecture commencée. Le style rédactionnel, s’appuyant sur des exemples ne permet pas seulement d’apprendre, mais également de réfléchir et parfois d’anticiper sur la compréhension de la solution. Le livre sert également remarquablement bien de points d’entrée vers d’autres lectures, on peut faire bon usage de la bibliographie commentée.

Voilà un texte qui mériterait sans aucun doute une seconde édition. Car si la substance est bien construite pour résister au temps, celui-ci fait quand même son  œuvre : le livre date de 2005 et beaucoup de choses ont quand même changé depuis. Je prends quand même le risque de vous le conseiller malgré son âge honorable.

effective-enterprise-java

Référence complète : Effective Enterprise Java – Ted Neward – Addison Wesley / Effective software development series 2004- ISBN: 0-321-13000-6

Effective Enterprise Java


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

Note de lecture : Design Patterns, par Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides

Note : 10+ ; LE livre de la décennie 90 !! Book of the year 1995 & Book of the decade ‘90!

Il y a un « avant » et un « après » Design Patterns. Il y a tellement de choses à dire sur ce livre emblématique qu’il est même difficile de trouver par où commencer. Commençons par « avant ».

Dans les années 80, jusqu’au début des années 90, on parlait bien d’activité de conception (par opposition à l’activité d’analyse) mais sans parvenir vraiment à identifier ce en quoi cela consistait. « montre-moi ton arbre d’héritage » était alors l’aulne à laquelle on mesurait la qualité d’une conception objet. Evidemment un arbre large et profond était jugé meilleur qu’un arbre rabougri. Pour certains gourous, seuls les objets issus du domaine métier étaient des éléments valides de conception. Je garde un souvenir vivace de m’être fait tancé vertement pour avoir introduit dans ma conception des objets qui n’en étaient pas. Bref l’activité de conception était alors généralement considéré comme le tartinage de code dans les classes identifiées en analyse. Sauf pour quelques uns qui se disaient qu’il y avait plus…

Puis est arrivé le Design Patterns. Un ouvrage tellement emblématique qu’il porte même un nom alternatif dans la communauté des patterns : le GoF, c’est à dire le « gang of four » par référence à ses quatre auteurs.

Il y a de nombreuses choses que je trouve géniales dans ce livre. La première est son absence apparente de génie. De nombreuses personnes ayant lu l’ouvrage disent, ou disent la première fois « je n’y ai pas appris grand chose ». Effectivement, aucun des 23 désormais célèbres patterns n’est une création des auteurs. C’est même une contrainte, un point obligé de l’identification des patterns : les patterns ne sont pas créés, ils sont découverts et doivent avoir été appliqués plusieurs fois avec succès pour prétendre à être identifié en tant que pattern. C’est le point de départ de l’apport des patterns :

L’activité de conception devient l’introduction de « mécaniques » dans le modèle objet, non de façon descendante, mais de façon émergente sous l’effet de « forces » documentées au sein des patterns, par refactoring d’un modèle existant.

L’accent est désormais mis sur la structure du modèle objet, par ses relations et sa dynamique, plus que par l’arbre d’héritage. Aujourd’hui les arbres d’héritages larges et profonds sont d’ailleurs jugés plutôt négativement.

L’utilisation d’un vocabulaire permettant de dialoguer plus efficacement sur les problématiques de conception.

L’adhésion de la communauté objet à cette approche a été immédiat. L’épuisement du premier tirage en 1 mois et demi en est l’une des preuve. Aujourd’hui le livre approche son 40ème retirage et plus d’un million et demi d’exemplaires en ont été vendus… L’autre symptôme est la naissance d’un véritable mouvement avec sa propre communauté et ses conférences qui dureront jusqu’au début des années 2000. Aujourd’hui, cette communauté en tant que telle s’est évanouie, mais elle a donné naissance à un autre mouvement : le développement agile !

Derrière ce mouvement de nombreux autres ouvrages ont vu le jour, mais 17 ans après, c’est bien le GoF qui reste la référence, par sa qualité et la pertinence des patterns qui y sont documentés : c’est LA bible incontournable du design pattern. Je lui ai décerné la titre de « book of the décade » car je considère qu’il s’agit de l’apport le plus important au monde de l’objet sur les années 90. Il a incontestablement fait évoluer de manière radicale ma manière de concevoir.

Le texte est simple, clair et lisible. Mais certains des concepts forts, comme la conception émergente se dissimulent en fait en filigrane dans le texte. Ce n’est pas évoqué explicitement, mais c’est un corollaire naturel… Des traductions ont existé, entre autre en français dont je ne pense pas qu’elles soient encore commercialisées. De toute façon je recommande la lecture en Anglais, la traduction française (que je possède par ailleurs) est entachée de nombreuses petites erreurs et traduire les noms des patterns en français n’est d’ailleurs pas la moindre (à l’exception de la « façade » pour laquelle des américains sont venus me demander la signification…).

L’épopée « patterns » appartient au passé. J’aimerais dire que c’est une bonne chose car ce savoir doit faire partie des acquis du développeurs. Mais je constate au jour le jour que ce n’est pas le cas, peut-être même avons-nous perdu de ce côté.

C’est pourquoi je recommande ce livre, non seulement sans réserve mais comme jalon incontournable du cursus de tout développeur. L’âge du texte ne change rien à l’affaire : Il excelle aussi bien par la qualité de son contenu, que par son concept novateur à l’époque (exprimer et nommer explicitement les briques de réutilisation de conception), que par sa présentation où patterns sont présentés selon un schéma constant. Au cas où vous ne l’auriez pas remarqué, je l’ai noté “10+”. C’est le seul de mes notes notes de lectures que j’ai ainsi noté, il est donc celui qui a obtenu la note la plus haute.

design-patterns

Référence complète : Design Patterns, Elements of reusable object oriented software – Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides – Addison Wesley / Professional Computing series 1995 – ISBN : 0-201-63361-2

Design Patterns: Elements of Reusable Object-Oriented Software


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

Note de lecture : The Usability Engineering Lifecycle, par Deborah J. Mayhew

Note : 8 ; Book of the year 2000! Un processus complet et à l’ancienne pour l’interface homme machine, complété d’un matériel prêt à l’emploi.

L’ergonomie fait, partie du recueil des besoins est rarement intégrée au processus de développement logiciel. C’est là une grande part du mérite de cet ouvrage: proposer un processus complet de gestion des exigences ergonomiques intégré à la capture des besoins fonctionnels par le biais des Use Cases. Oui, c’est vrai je viens de parler de processus et cela a une odeur pas très agile. Et effectivement dès les premières pages l’auteur propose un « usability lifecycle » qui ferait facilement froid dans le dos. Nous pouvons nous y arrêter un peu car ce cycle de vie structure le livre lui-même.

  • La première étape est le recueil des besoins. Elle est couverte par 6 chapitres sur 160 pages. Elle couvre les 4 facettes identifies de cette étape : l’analyse des profils utilisateur, l’analyse des tâches, les objectifs d’utilisabilité et les principes généraux de l’IHM.
  • La seconde étape est bien plus dense car le schéma du processus nous montre pas moins de 7 sous étapes regroupés en 3 cycles internes. C’est presque une surprise de voir cela couvert en seulement 180 pages, sur 10 chapitres ! Les activités proposées vont du modèles conceptuel à la reconception des tâches en passant par la conception d’écrans.
  • La dernière étape a trait à l’installation. Il n’y a qu’un seul chapitre, mais il fait 50 pages ! Cette partie couvre le feedback utilisateur.
  • Enfin une dernière partie de l’ouvrage est consacrée aux aspects organisationnels. Elle est longue de 100 pages sur 4 chapitres avec en plus des aspects strictement organisationnels, l’évocation de la planification de projet ou la justification des coûts (une des spécialité de l’auteur).

Au total, le livre est quand même très lourd, car il totalise 560 pages ! Sa structure est entièrement guidé par le processus proposé par l’auteur ce qui tend à rendre la prose très longue, je l’ai déjà constaté. Ce fil extrêmement rigide est tout sauf agile. Mais le contenu est loin d’être inintéressant. En effet le texte est méritoire par le fait qu’il accompagne chaque activité proposée du processus de gestion des exigences d’artéfacts (plans types, questionnaires, etc…) et de guidelines immédiatement applicables. J’ai rarement vu des livres donner autant de matière directement utilisable.

Chaque chapitre traite des aspects de la spécificité des applications Web dans une section et propose des “activités alternatives” si le processus a besoin d’être abrégé.

Outre que le livre reste très lourd (même en considérant le matériel inclus) et qu’il est structuré par un processus très rigide, il prend aussi un sérieux coup de vieux avec la seconde vague du Web. Mon conseil ? Prenez du recul par rapport au texte, démontez les morceaux du processus. N’utilisez pas le processus, mais réutilisez les morceaux, les idées et la matière première d’une manière plus légère et plus agile. L’auteur a beaucoup d’expérience et de savoir-faire dans son domaine qu’il serait dommage de snober.

Un très bon ouvrage que je recommande fortement, surtout si vous n’avez pas de connaissances préalables dans le domaine de l’ergonomie.

usability-engineering-lifecycle

Référence complète : The Usability Engineering Lifecycle – Deborah J. Mayhew – Morgan Kaufman publishers 1999 – ISBN: 1-55860-561-4; EAN: 978-1-558-60561-9

The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design


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

Note de lecture : The Lean Startup, par Eric Ries

Note : 10 ; Le futur de l’agilité ? Book the year 2012 !

Je ne vais pas faire durer le suspens : j’adore ce livre ! C’est vrai, il parle de startups, en principe un sujet un peu éloigné de mes préoccupations quotidiennes. Mais en réalité tout ce qui y est dit ou presque est transposable dans le contexte d’un projet informatique.

Le Lean Startup est déjà un mouvement d’ampleur, que l’on ne peut plus ignorer et ce livre en est le texte emblématique, pour de bonnes raisons que je vais tenter d’expliquer. Tout d’abord, avant de devenir le gourou de ce mouvement Eric Ries était informaticien, et même un grand supporter des méthodes agiles en générale et d’extreme programming en particulier. Lui-même créateur de startups, il a vécu et cherché à dépasser les limites de l’approche agile et a puisé dans le Lean l’essence de ce qu’il souhaitait faire. Ce n’est pas une simple transposition du Lean, mais bel et bien l’esprit du Lean transposé dans le processus startup.

Il y a 5 principes sous-jacents au Lean Startup

  • Les entrepreneurs sont partout : Etre entrepreneur, ce n’est pas forcément être enfermé dans un garage avec 3 copains. On peut être entrepreneur dans une entreprise, ou même sur un projet.
  • L’entreprenariat EST le management : Le Lean Startup est un processus pour les business d’extrême incertitude. Cela requiert un nouveau type de management.
  • Validated Learning : C’est le cœur du Lean Startup. Le processus a pour but d’apprendre, de permettre de valider des hypothèses. Il est facile d’arguer que l’on a appris quelque chose, le but est d’apprendre quelque chose d’utile étayé par des données. Il s’agit donc d’avoir une approche scientifique de la connaissance.
  • Build-Mesure-Learn : C’est le cycle du Lean Startup. Le but d’une startup est de construire un produit à partir d’idées et d’en mesurer l’effet auprès de clients. Puis de produire un nouvel incrément à partir de ce que l’on a appris.
  • Innovation accounting : Ce sont les choses ennuyeuses qui comptent dans le succès d’une startup. Très peu est lié à la vision initiale, car ce que l’on construit finalement n’a pas forcément beaucoup à voir avec l’idée initiale. Ce qui construit le succès, c’est de rester engagé sur les étapes d’évolution, de persévérer ou de pivoter, jour après jour.

Je serais bien en peine de résumer simplement ce livre. Je vais donner les grandes lignes des 3 parties (mais vous trouverez cela sur Amazon de toute façon). Puis j’essaierai de vous dire pourquoi j’aime ce livre.

La première partie, « Vision », nous explique les bases du cycle du Lean Startup : Démarrer, définir, apprendre et expérimenter. On part dune vision, ce que Ries appelle « l’acte de foi ». Mais au lieu de partir gaillardement de l’avant, on s’efforce de valider la ou les hypothèses sous-jacentes en construisant et exposant le plus rapidement possible un MVP (minimal viable product). Contrairement aux approches agiles, le focus se fait sur la vitesse et ce que l’on souhaite apprendre au détriment éventuel de tout le reste !

La seconde partie, « Piloter », évoque le processus dans sa durer : Tester ses idées, les mesurer et savoir interpréter les mesures, en terme d’évolution et non en « mesure de vanité ». Enfin cette partie évoque un des thèmes centraux de l’approche : pivoter.

La troisième partie « Accélérer » traite de tout ce qui permet de raccourcir le temps de cycle : diminution des lots (hérité du Lean), déploiement continu, etc…

J’ai été très (trop) vite à parcourir le contenu du livre et j’ai zappé beaucoup de points importants. Ce n’est pas critique, car vous allez le lire. Le Lean Startup m’apparaît ici comme l’étape qui suit l’agilité.

Une étape où l’on ne se satisfait plus de backlog ou de user stories, mais où l’on va au front pour comprendre et décider de la prochaine étape.

Une étape où il n’y a plus une équipe de développement qui développe (certes en collaboration) avec un utilisateur où un Product Owner, mais simplement un startup qui fait le boulot et où on ne parle plus de rôle.

Une étape où le ne mesure plus la vélocité d’une équipe au nombre de user stories achevées, mais où cette notion même n’a plus de sens et où on se focalise sur le progrès du business.

Eric Ries fait passer dans son livre des concepts forts, étayé par des idées empreintes d’intelligences avec de nombreux exemples à la clé qui en rendent la lecture très agréable. Il n’y a réellement aucune longueur dans ce texte. Au contraire : il m’apparaît que faire le tour de ce sujet en un seul ouvrage n’est pas possible. J’ai eu l’impression d’avoir entre les mains « l’extreme programming » des années 2010, un livre qui engendrera et nécessitera des développements. En fait cela a déjà commencé. La lame de fond « Lean Startup » ne fait que débuter. Elle va impacter de nombreux domaines dans les années à venir et va voir son cercle d’influence s’agrandir, ses idées et ses pratiques se développer.

Je n’ai pas hésité à en faire mon « book of the year » dès maintenant. Nous sommes au mois de Mai et je n’ai guère de doute. Ma question est plutôt : est-ce là mon « book of the décade » ?

Si je n’ai pas été assez clair sur ce que je pense de ce texte et quel est mon conseil : relisez depuis le début, ça ne peut pas vous échapper !

lean-startup

Référence complète : The Lean Startup – Eric Ries – Crown Business 2011 – ISBN : 978-0-307-88789-4

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses


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

Note de lecture : Scaling Lean & Agile Development, par Craig Larman & Bas Vodde

Note : 9 ; Enfin un ouvrage sur le Lean développement qui renouvelle les idées ! Book of the year 2010 !

Le problème des ouvrages sur le Lean développement, c’est qu’ils ne savent guère que tourner en rond, exposer et (dans le meilleur des cas) développer les idées sous-jacentes aux principes Lean. Bien que le Lean soit à la mode, chaque lecture d’ouvrage sur ce domaine tend à se transformer en ennui annoncé.

J’ai donc une excellente nouvelle pour vous : ici, il n’en est rien ! Cet ouvrage de 330 pages est complété d’un « companion book » plus imposant, écrit par les deux mêmes auteurs. Mais nous allons nous concentrer sur celui-ci pour l’instant. Si l’ouvrage est écrit par deux auteurs, l’un des deux au moins, ne m’est pas inconnu : Craig Larman est « chief scientist » de mon employeur précédent, mais aussi un auteur émérite. Bref, il sait écrire, et je n’ai jamais été déçu par ses textes jusqu’à présent. Et disons que la série se poursuit.

Avant d’attaquer le contenu, je vous livre une de mes petites manies permettant d’avoir des indices sur la qualité du livre, avant et après lecture. Avant de commencer la lecture, je regarde les 1ère et 4ème de couverture. Une proportion importante des meilleurs ouvrages y propose des schémas ou des tableaux récapitulatifs du livre, ou même des aides mémoire. On a ça ! Après lecture, je compte le nombre de post It que j’ai placé sur le livre : ici j’en ai posé 22, c’est très très bon.

Après la forme, le fond. Le livre se découpe en 3 parties constituées de 12 chapitres, ce qui fait donc une moyenne de moins de 30 pages par chapitre. Ca va.

Autant nous occuper tout de suite de la 3ème partie, « miscellany » essentiellement constituée du dernier chapitre « Scrum Primer », qui n’est en fait pas écrite par les auteurs, mais par des auteurs du site http://www.scrumprimer.com ; Pour distinguer ce texte de celui des auteurs, le corps de la police utilisée est différent, plus petit. Il s’agit d’un bon « Scrum primer » qui présente l’avantage d’être assez direct et succinct et de bien recadrer ce qui fait partie du corpus de la méthode et ce qui n’en fait pas partie mais est généralement utilisé ! En plus de ce chapitre, on trouve les annexes habituelles (index et bibliographie), accompagné d’un « recommanded readings » assez sympa.

La première partie est consacrée aux « thinking Tools ». Il est long de 140 pages découpées en 5 chapitres (je n’ai pas compté le chapitre d’introduction, qui précède cette première partie). Le chapitre 2 (system thinking) est essentiellement un tutorial aux « causal loop diagram », même si les « fishbone diagrams » sont aussi évoqués. Le diagramme de boucles causales sera d’ailleurs utilisé ultérieurement dans le livre. Très réussi. On poursuit au chapitre 3 (Lean thinking) où l’on présente « Lean thinking house ». Les principes sont déclinés en pratiques. Les pratiques sont développés et illustrées. Impeccable là aussi. La théorie des queues est un volet important du Lean thinking. Le chapitre 4 qui lui est consacré est assez ardu à suivre. Mais on coupe court aux idées fausses de manière abrupte et l’on en a pour son argent ! Le chapitre 5 (false dichotomies) est sans doute l’un des plus abstraits par sa nature. Il s’agit là aussi de couper court aux idées fausses et de réfuter certaines idées prétendument opposées. Enfin le chapitre 6 (be agile) termine cette première partie en promouvant l’idée « d’être agile », donc de s’adosser aux valeurs, plutôt que de « faire de l’agilité » et donc de ne voir que les pratiques.

La seconde partie est dédiée aux « organizationnal Tools ». De taille égale à la premier (5 chapitres pour 150 pages), il focalise chaque chapitre sur une pratique Scrum inspirée de Lean, et adaptée aux projets de grande taille. Le chapitre 7 (feature team) met en exergue l’idée d’équipes pluridisciplinaires, par opposition aux organisations orientées composant. Le chapitre 8 (teams) est la poursuite de cette idée, avec une emphase sur le caractère auto organisée des équipes et sur la gestion des dépendances externes. Le chapitre 9 (requirements area) introduit une idée nouvelle sur la gestion de très gros backlogs. Dommage que ce chapitre de seulement 9 pages n’ait pas été plus développé ! Le chapitre 10 évoque l’extension de l’organisation agile au niveau de l’organisation de l’entreprise. J’y ai surtout aimé la distinction projet / produit, souvent incomprise et source de problème, tandis que les aspects ressources humaines sont du déjà vu et hélas une appréhension bien trop idéaliste du sujet. Enfin le chapitre 11 (large scale Scrum) évoque une partie du sous-titre de l’ouvrage et dit en substance que l’adaptation de Scrum aux grands projets … n’existe pas en tant que tel !

Finalement, j’ai retardé la lecture de cet ouvrage ne me sentant pas tellement concerné par le « large scale Scrum ». C’était une erreur, car en fait pu de choses dans ce livre sont vraiment dédiées spécifiquement aux grandes équipes. Au contraire, la littérature agile qui me semble rabâcher les mêmes propos depuis quelques années retrouve un peu de fraicheur ici. J’ai hâte de lire la suite, et bien sûr je recommande chaudement, sans aucune réserve !

scaling-lean-agile-dev-Larman

Référence complète : Scaling Lean & Agile Development, Thinking and organizational Tools for large-scale Scrum – Craig Larman & Bas Vodde – Addison Wesley 2009 – ISBN : 978 0 321 48096 5

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

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