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

Publicité

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.

Lire la suite

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

Note de lecture : The Pragmatic Programmer: From journeyman to master, par Andrew Hunt & David Thomas

Note : 9 ; Think! About your work; Book of the year (ex-æquo) 2002

Pensez! Mais pensez à la façon dont vous travaillez! Tel pourrait être le credo des auteurs de ce livre. Cet ouvrage ne traite pas de processus de développement logiciel à proprement parler, il expose plutôt une façon de se comporter et d’appréhender le développement logiciel au quotidien.

L’activité de développement logiciel est-elle un travail systématique décrit par des règles rigides? A cela les auteurs répondent: non! Ils abordent d’ailleurs le travail du développeur d’avantage comme l’activité d’un artisan que comme un travail d’ingénierie. Bien loin d’être un parallèle défavorable, il faut y voir une valorisation de notre travail, quand pour chaque problème il faut chercher une solution réfléchie, pragmatique et adaptée. Certains l’auront déjà compris, c’est d’agilité dont nous parlons ici ! Publié en 2000, il ne s’agit pas là d’une adhésion tardive à un effet de mode, mais au contraire le fruit de réflexions de « véritables croyants ». D’ailleurs Hunt et Thomas sont parmi les signataires originaux de l’agile alliance.

Le livre se découpe en 8 chapitres qui regroupent au total 70 « tips » (il y a un aide mémoire avec le livre).

Chap 1 : Pragmatic philosophy. On nous enseigne ici les lignes directrices de l’agilité : le « juste assez », l’entropie du logiciel, …

Chap. 2 : Pragmatic approach. Ce chapitre traite des tactiques de réalisation : la « balle traçante » ou le langage du domaine, par exemple.

Chap. 3 : Basic tools, traite de l’environnement, outils d’édition, de build ou de génération de code. Bref, c’est pour l’usine logicielle !

Chap. 4 : Pragmatic paranoia (là, c’est pour moi) nous enseigne l’anticipation des comportements erronés.

Chap. 5 :Bend or break, traite de conception (donc de patterns) et de sa bonne mise en œuvre.

Chap. 6 : While you are coding évoque tout ce qui gravite autour de l’implémentation : les tests, le refactoring, etc…

Chap. 7 : Before the project, car il ne faut pas confondre vitesse et précipitation ! On parle ici de spécifications, mais aussi des travers qui peuvent en découler.

Chap. 8 : Pragmatic projects, évoque la dimension stratégique du projet : la gestion des tests, le cycle itératif, etc…

Ne vous y trompez pas: ce livre ne vous expose pas comment programmer. Il existe pour cela d’autres ouvrages dédiés aux langages de programmation, par exemple. Une partie (importante) du texte est toutefois dédié à des aspects de conception générale: programmation défensive, méta programmation, architecture MVC.

Mais pour moi l’intérêt principal du livre n’est pas là. Son intérêt principal est de nous montrer que la responsabilité d’un ingénieur de développement ne se limite pas à écrire du code. Notre responsabilité est de livrer un développement dont nous pouvons être fiers, de qualité et répondant aux réels besoins utilisateur. Un travail que nous pourrions même signer: fruit d’une élaboration sérieuse, robuste, bien écrit et convenablement documenté. Un travail professionnel, réalisé par un vrai professionnel, un “pragmatic programmer”.

Ai-je oublié de vous dire que je recommande fort chaudement cet excellent ouvrage ? Mais notez au passage le vocabulaire plutôt riche employé dans le texte, qui peut en rendre la lecture légèrement difficile.

pragmatic-programmer

Référence complète : The Pragmatic Programmer: From journeyman to master – Andrew Hunt & David Thomas – Addison Wesley 2000 – ISBN: 0-201-61622-X

The Pragmatic Programmer: From Journeyman to Master

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

Note de lecture : Effective C++, 55 specific ways to improve yours programs and designs, 3rd edition, par Scott Meyers

Note : 10 ; Un texte à l’écriture hors pair, remis à jour en prenant en compte la STL, mais toujours irréprochable!

Je sais que vous pouvais être surpris de voir une note de relecture sur un livre dédié à C++ ici ! Sachez deux choses:

  • Ayant pratiqué C++ pendant 12 ans, j’ai un très important fond de commerce de livres, et donc de notes de lectures, sur C++.
  • Discutant l’autre jour avec une de mes collègues, nous parlions de style d’écriture de livres, et de ce à quoi ressemble un très, très bon style d’écriture. De ceux qui vous accrochent, vous passionne, vous font comprendre les choses et vous font rire, quel que soit la complexité ou l’aridité du sujet. L’exemplarité dans le domaine existe, de mon point de vue. Parmi plusieurs centaines de livres, il s’agit de cet auteur là, de ce livre là. Sans aucun doute possible.

Pour ceux qui seraient inquiets quand à cette 3ème édition de l’ouvrage, le style de l’auteur est resté égal à lui-même : un régal ! En fait, l’écriture de Scott Meyers est l’exemple même de ce que devrait être l’écriture d’un texte technique. La première fois que j’ai lu cet auteur, j’ai dû avaler le livre en 2 ou 3 jours. On s’y accroche tel en bon roman, peut-être ai-je surpris des personnes dans le métro en éclatant de rire… Il m’a fallu un moment pour que je prenne conscience, une fois la dernière page tournée, que j’avais lu un texte très technique !

Alors c’est vrai : j’ai sauté la seconde édition ! Je devrais donc me contenter de comparer cette 3ème mouture avec la seconde édition. Dix ans ont passé depuis, et l’auteur a fait bien plus qu’un simple rafraichissement des items présentés, il a effectué un travail d’introspection en réévaluant la pertinence des items (9 ont disparus), en créant de nouveaux (15 items complètement nouveaux), en fusionnant certains et en découpant d’autres. Au-delà de ce remaniement, le texte est complètement revu, eut égard au niveau des compilateurs actuels, de la librairie standard et même du futur standard, et même de la librairie Boost. On trouve aussi des inspirations nouvelles : ainsi le « copy and swap », les 3 types de garanties (basic guarantee, strong guarantee et no-throw guarantee) ainsi que le NVI idiome sont directement inspirés des « exceptional C++ » de Herb Sutter, d’ailleurs largement cité en préface.

Ce volume est plus épais que les précédents, avec ses 280 pages, en impression bicolore, s’il vous plait ! Je vois une double raison pour céder à la lecture de cette seconde édition : se rafraichir la mémoire sur les bonnes pratiques de Meyers, dans le contexte actuel du C++ et découvrir de nouvelles choses non traitées dans les éditions précédentes (dans les nouveaux items comme dans les items existant). Je vous laisse deviner la conclusion qui s’impose…

Pour ceux qui n’ont rien à faire du C++ mais rêvent de devenir auteur, et même auteur hors pair, voici ce à quoi vous pouvez vous mesurer. Je n’ai aucune meilleure référence à vous proposer.

effective-c++-3edt-Meyers

Référence complète : Effective C++, 55 specific ways to improve yours programs and designs, 3rd edition – Scott Meyers – Addison Wesley / Professional Computing series 2005 – ISBN: 0-321-33487-6

Nb : La première édition de ce livre était mon “book of the year” 1994.

Effective C++: 55 Specific Ways to Improve Your Programs and Designs


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

Note de lecture : Applying Use Cases 2nd edition, par Geri Schneider & Jason P. Winter

Note : 9 ; Un simple raffinement d’un livre déjà excellent, mais qui va dans le bon sens.

J’ai quelques références sur les Use Cases dans ma bibliographie. Ce texte-ci est l’un de mes préférés, sinon mon préféré. Historiquement, à mon échelle, c’est par la note de lecture de la 1ère édition de ce livre que j’ai commencé ma compilation bibliographique il y a maintenant 14 ans.

C’est un ouvrage succinct (environ 170 pages hors annexes), exclusivement destiné aux uses cases, à leur utilisation, leur développements (use case scénarios, diagrammes d’activité, liens vers la modélisation), leur documentation. Le propos est très clair, très direct et bien illustré à l’aide d’un exemple développé au long du livre. La taille réduite du livre fait partie de ses qualités, la substance utile étant très importante. 

Pour cette seconde édition, je m’attendais à d’avantage d’évolutions. En fait, les auteurs ont simplement repris leur matériel de base, en le réorganisant et en mettant à jour certains concepts (relations “includes” et héritage, ainsi que cas d’utilisation subordonnés).  La partie la plus faible de l’édition précédente (documentation des cas d’utilisation) a désormais atteint la qualité des autres chapitres et certains nouveaux thèmes ont été abordés comme les Use Case “CRUD” et les exigences complémentaires. La lourde description de l’étude de cas qui encombrait un peu l’ouvrage a été rejeté en annexe ou elle figure désormais de façon plus complète. Finalement, les auteurs ont réussi le tour de force de remettre à jour cet ouvrage sans nous pénaliser de l’augmentation de volume qui en est le corollaire. Toujours excellent, donc.

Un livre que je conseille très fortement, sans arrières pensés.

applying-usecases-2

Référence complète : Applying Use Cases, second edition, a practical guide – Geri Schneider & Jason P. Winter – Addison Wesley / O.T. series 2001 – ISBN: 0-201-70853-1

Nb: La première édition de cet ouvrage était mon “book of the year” 1998

Applying Use Cases: A Practical Guide


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

31 ans de « book of the year »

En réponse à Dimitri Baeli, je dévoile ici ma ma liste complète de “book of the year”. En voici les principes:

  • Il s’agit d’un livre que j’ai lu pendant l’année en question. Ce n’est pas nécessairement un livre édité durant l’année en question !
  • C’est une question de coup de coeur, en principe il fait partie des mieux notés de l’année, mis en fait je ne vérifie même pas ça ! C’est complètement subjectif et je ne cherche même pas à me justifier !
  • J’ai le droit de changer d’avis jusqu’au 31 décembre de l’année. Mais après c’est trop tard, c’est gravé dans le marbre.
  • Je peux avoir plus d’un book of the year ! C’est mon classement à moi, je fais ce que je veux.
  • Il y a toujours un book of year. Si je n’ai lu que des navets, c’est le moins pire qui gagne.

Bon après, il y a aussi des “books of the decade”. Si vous être sages, ce sera pour un autre post !

1981 : Cours de Basic, analyse et programmation – D. Lautier & J.P. Lerner – Masson

1982 : La pratique du TRS-80, volume II, compléments basic & programmation Z80 – Pierre Giraud & Alain Pinaud – Editions du PSI

1983 : Suites pour PC 1500 : 20 programmes en Basic – Jean-François Sehan – Editions du PSI

1984 : Le Pascal par la pratique – Pierre Le Beux & Henri Tavernier- Sybex

1985 : Programmation du 6809 – Rodnay Zacks & William Labiak – Sybex

1986 : Gödel, Escher, Bach: Les brins d’une guirlande éternelle – Douglas Hofstadter – InterEdition

1987 : Au cœur de l’Atari ST – Laurent Besle – Eyrolles

1988 : PostScript par l’exemple – Adobe systems inc. – InterEdition

1989 : La bible PC, 2nd édition – Michael Tischer – Micro Application

1990 : Le langage C – Brian W. Kernighan & Denis M. Ritchie – Masson

1991 : Développer avec Turbo Pascal pour Windows – S. Van Gelderen – Sybex

1992 : Programmer sous Windows 3.1, 3ème édition – Charles Petzold – Microsoft press

1993 : Le génie logiciel – Ian Sommerville – Addison Wesley

1994 : Effective C++ – Scott Meyers – Addison Wesley

1995 : Design Patterns, Elements of reusable object oriented software – Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides – Addison Wesley

1996 : OMT, Modélisation et conception orienté objet – James Rumbaugh, Michael Blaha, Frederick Eddy, William Premerlani & William Lorensen – Masson

1997 : MFC Programmation sous Windows – Jeff Prosise – Microsoft press

1998 : Applying Use Cases, a practical guide – Geri Schneider & Jason P. Winter – Addison Wesley

1999 : Mastering the Requirements process – Suzanne Robertson & James Robertson – Addison Wesley

1999 : Refactoring, Improving the design of existing code – Martin Fowler & al. – Addison Wesley

2000 : The Usability Engineering Lifecycle – Deborah J. Mayhew – Morgan Kaufman

2000 : Extreme Programming Explained: Embrace Change – Kent Beck – Addison Wesley

2001 : Peopleware: Productive projects and teams, 2nd edition – Tom DeMarco & Timothy Lister – Dorset House

2002 : Rapid Development, taming wild software schedules – Steve McConnell – Microsoft press

2002 : The Pragmatic Programmer: From journeyman to master – Andrew hunt & david Thomas – Addison Wesley

2003 : Agile Software Development: Principles, Patterns & practices – Robert C. Martin, with James W. Newkirk & Robert S. Koss – Addison Wesley

2004 : Enterprise Patterns and MDA, Building better software with Archetype Patterns and UML – Jim Arlow & Ila Neustadt – Addison Wesley

2005 : Effective Enterprise Java – Ted Neward – Addison Wesley

2006 : Project Retrospectives, a handbook for team reviews – Norman L. Kerth – Dorset House

2007 : Release it! – Michael T. Nygard – Pragmatic Bookshelf

2008 : More Joel on Software – Joel Spolsky – Apress

2009 : Scrum and XP from the Trenches, how we do Scrum – Henrik Kniberg – InfoQ

2010 : Scaling Lean and Agile Development – Craig Larman & Bas Vodde – Addison Wesley

2011 : Système Lean 2nd edition, penser l’entreprise au plus juste – James Woomaack & Daniel Jones – Village Mondial