Note de lecture : Urbanisme des SI et gouvernance : Retours d’expérience et bonnes pratiques, par le Club Urba-EA

Note : 2 ; Creux et plat tout à la fois

Bon, je dois être honnête : si j’ai acheté ce livre, c’est parce que je connais deux des projets qui y sont exposés pour y avoir trainé mes guêtres. Comme globalement il s’agissait de vastes pantalonnades aussi pleines de prétentions que vides d’efficacité, ceci associé à une pratique modérée mais réelle des écrits du club « Urba EA », disons que mes attentes ne se situaient pas très haut. Je n’ai pas été déçu : c’est nul.

J’avais tout d’abord choisi comme titre de cette note de lecture : « comment uriner dans son froc efficacement », mais j’ai finalement changé après avoir tourné la dernière page, car ce n’est pas le trait qui m’a le plus marqué. Non, ce que j’en garde comme souvenir, c’est que l’on n’y dit rien. Oh, on couvre bien les plus de 200 pages du livre, mais essentiellement avec des lieux communs, des banalités et aussi peu d’information pertinente et opérationnelle qu’il est possible. En fait, la seule chose que j’y aie apprise est une succincte explication du framework de Zachman. Comptez 3 pages. Bien sûr, vous allez me dire qu’ayant lu toute la littérature sur l’urbanisation du SI (ou presque), il était improbable que je puisse y apprendre quelque chose de nouveau. Erreur. Je pense qu’il y a beaucoup de choses que vous ou moi puissions apprendre malgré la littérature publiée sur le sujet, mais elle n’est pas là.

Le bouquin est trop déprimant pour que je me livre à une analyse chapitre par chapitre (mais il y a 5 parties, OK je veux bien aller jusque là). Si au moins le style était au rendez-vous et en rendait la lecture plaisante malgré son vide abyssal. Même pas, c’est pompeux à souhait, comme certains aiment à penser que doit l’être la littérature sérieuse.

Je passe la première partie (composée de 2 chapitres) destinée à introduire les sujets couverts dans le reste de l’ouvrage. La seconde partie couvre les activités de l’urbaniste. Les 6 chapitres qui composent cette partie, peut-être la moins inintéressante du livre tentent d’expliquer ce qu’est le rôle de l’urbaniste. Deux pathétiques études de cas illustrent le propos. Si vous ne comprenez pas ce que les équipes des études de cas ont vraiment fait, rassurez-vous : moi non plus. Ce chapitre vaut au livre la moitié des points que je lui accorde. L’autre, c’est qu’hélas il existe encore pire que ce livre-ci !

La troisième partie, on y parle de gouvernance. C’est hautement gonflé de prétentions, ridiculement pauvre de contenu, et on a rien appris au final. 7 chapitres pour cela dont 3 études de cas. Mots clés : ROI, valeur, gouvernance, ITIL, Cobit, CMM, etc…

La quatrième partie est consacrée au rapport entre urbanistes et projets. Dans un éclair de lucidité, les membres du club Urba SI on comprit qu’ils devaient, pour justifier leur existence, être en contact des projets. Avec ce qu’on y voit la question est donc : les projets auront-ils envie d’être en contact des urbanistes. De mon point de vue, étant convaincu de l’utilité de l’urbanisation des SI et à la lumière de ce que je lis ici, la réponse sera non. Deux études de cas illustrent ce propos. Mais oui. Je les connais et je n’en dirais pas que les urbanistes y sont au contact des projets.

La cinquième partie est consacrée à la création de valeur (2 chapitres, pas d’étude de cas). Je parlais de lieux communs tout à l’heure ? Cela s’applique bien ici.

Peut-être avez-vous eu le courage de lire ma prose jusqu’au bout. Pour ceux qui, particulièrement fatigués par leur journée de travail ou n’ayant pas encore émergé de la fête outrageusement arrosée d’hier soir, n’auraient pas encore extrapolé mon conseil, le voici exprimé explicitement : ce livre est hautement déconseillé.

urba-si-gouvernance

Référence complète : Urbanisme des SI et gouvernance : Retours d’expérience et bonnes pratiques – Club Urba-EA : Philippe Anquetil, Jean-Christophe Bonne, Denis Carpentier, Laurent Chaigneau, Michel Dardet, Patricia Gotlib, Bruno Guenoden, Alain Legac, Christophe Longépé et René Mandel – Dunod 2006 – ISBN : 2-10-049678-6 ; EAN : 978-2-100-49678-5

Urbanisme des SI et gouvernance : Retours d’expérience et bonnes pratiques


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

Note de lecture : My Job Went to India (and all I go twas this lousy book), 52 ways to save your job par Chad Fowler

Note: 7; Une ligne de conduite pour sauvegarder son employabilité: utile bien au-delà du contexte cite dans le titre, et à reconsulter régulièrement.

Derrière un titre amusant (et une couverture qui ne l’est pas moins), Chad Fowler nous livre un propos tout à fait sérieux et profond: comment rester employable et éviter l’obsolescence. L’approche de l’auteur est à la fois simple et originale: il faut considérer sa carrière comme un produit. Cela conduit à une approche en 5 parties, plus une “supplémentaire”.

Choisir son marché: c’est orienter sa carrière selon ses capacités mais aussi par rapport aux opportunités de marché. C’est aussi garder le contrôle de la direction que l’on souhaite emprunter et éviter de se laisser embarquer dans des voies sans issues.

Investir dans votre produit: c’est définir et mettre en œuvre le plan d’action pour prendre la direction que l’on souhaite.

Exécuter : Ou comment se comporter et agir au jour le jour dans son poste. C’est aussi se remettre en cause continuellement et avoir une idée claire de sa valeur et de la valeur (ou du manque de valeur) de son travail. 

Marketing : comme son nom l’indique, c’est se vendre en mettant en valeur son travail sans penser que l’on sera automatiquement connu et reconnu par la simple production de livrables de qualité. C’est donc aussi savoir être un bon communiquant.

Maintenir son avantage : C’est éviter l’obsolescence en restant en mouvement, en ayant une gestion « agile » de sa carrière.

Si vous ne pouvez les battre… : Ce dernier chapitre adresse la position que l’on peut prendre par rapport à l’offshore, non en essayant de l’éviter, mais en prenant une position forte dans ce processus.

L’auteur est tout à fait aguerri sur son sujet : il a été manager sur la mise en place d’une entité offshore dans son entreprise. Chaque item est traité sur 2 à quatre pages environ, ce qui évite l’ennui, dans un style plutôt agréable et illustré d’exemples, mais dans un anglais parfois un peu sophistiqué qui en complique un peu la lecture. Chaque item se termine par des points de « mise en mouvements », certains sont bons et d’autres un peu forcés. Au final ils sont un peu nombreux, mais on peut utilement piocher dedans.

Un ouvrage qui invite à la réflexion, donc.

job-went-to-india

Référence complète : My Job Went to India (and all I go twas this lousy book), 52 ways to save your job – Chad Fowler – Pragmatic Bookshelf 2005 – ISBN: 0-9766940-1-8 (une seconde édition sous un autre titre existe qui fera l’objet d’une note de lecture ultérieure)

My Job Went to India: And All I Got Was This Lousy Book (Pragmatic Programmers)


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

Note de lecture : Use Case, patterns and blueprints, par Gunnar Övergaard & Karin Palmkvist

Note : 3 ; Des patterns qui n’en ont que le nom et des préoccupations exagérément focalisées sur la structuration.

En voyant le nom du disciple d’Ivar Jacobson en auteur de ce livre, je m’attendais à une vision Jacobsionienne, mais aussi à de bonnes choses. Très curieusement, je n’ai eu aucun des deux points.

Parlons déjà du volet « patterns », pour commencer. Franchement, je ne sais pas pourquoi on a laissé passer ce texte dans la SPS series, car si le livre de Steve Adolph et al. (Patterns for effective use cases) présente bien des patterns, celui-ci fait seulement semblant. Ceux-cis sont mal cadrés, aucune description de problème ne les introduisent, ils ne sont pas compréhensibles, et d’ailleurs ils ne servent en fait que d’introduction à la discussion qui s’en suit. Deux autres parties suivent la partie pattern, une partie « blueprint » qui sont des applications concrètes (en fait plus proches de ce que devraient être des use case patterns), mais toujours de peu d’intérêt, et une partie « mistakes » plus intéressante mais longue de seulement 30 pages (le livre en compte 420) !

Pour ce qui est du fond, ce livre est malheureusement un danger, car il se focalise excessivement sur les relations entre patterns : relations d‘inclusion et d’extension et généralisation, rendant les modèles de cas d’utilisation bien trop techniques et pas assez lisibles. Un véritable danger pour le pratiquant débutant !

Du coté des bonnes nouvelles, le livre intègre (outre les patterns) une introduction à la modélisation des cas d’utilisation assez bien faite et réduite à 100 pages (donc, bien). Si j’agonit de critiques l’excès de structuration, je dois aussi avouer qu’aucun texte ne détaille aussi bien la relation d’extension, et les possibilités offertes par les points d’extension. De même, les auteurs proposent une façon de documenter les cas d’utilisation parent et enfants dans une relation de généralisation qui est plutôt intelligente. Enfin, c’est le seul texte à ma connaissance qui décrive précisément et utilise les instances de cas d’utilisation. Ceci intéressera donc les académiciens d’UML (donc aussi le théoricien qui sommeille en moi).

Globalement, un livre que je déconseille, et qu’il faut absolument mettre hors de portée des non experts.

use-cases-patterns-blueprints

Référence complète : Use Case, patterns and blueprints – Gunnar Övergaard & Karin Palmkvist – Addison Wesley / Software Patterns series 2004 – ISBN: 0-13-145134-0

Use Cases: Patterns and Blueprints


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

Note de lecture : The Art of Readable Code, par Dustin Boswell & Trevor Foucher

Note 3 ; Le contenu est bien maigre…

Je m’en doutais un peu dès le départ en le tenant en main : le contenu serait vite lu. Ce fut bien le cas. Je pensais y trouver des éléments de style auxquels confronter mes propres idées, le bilan est pour le moins mitigé sur ce point. Au départ, l’ouvrage compte 180 avec une structure plutôt aérée et des cartoons humoristiques comme on aimerait en voir plus souvent. L’ensemble est découpé en 15 chapitres, eux-mêmes regroupés en 4 parties. Disons que c’est un bon point de départ.

La première partie « surface level improvements » compte 6 chapitres sur 60 pages. Elle ne parle que de choses simples, pourtant je l’ai trouvée plutôt pas mal. Les sujets qui y sont traités sont principalement nommages, indentation (et mise en page au sens large) et commentaires. J’adhère à beaucoup des idées, mais pas toutes. Les développements autour des commentaires sont probablement les plus intéressants que j’ai pu lire.

La seconde partie « simplifying loops and logic » est développée sur 3 chapitres totalisant un peu moins de 40 pages. On y parle ici de lisibilité du code via le découpage des méthodes ou la simplification des expressions. Certains sujets sont à la limité des questions de lisibilité et touchent plutôt la qualité. Les points abordés le sont bien, mais le sujet n’est plus neuf car il est le pain quotidien des pratiquants du refactoring.

En troisième partie « reorganizing your code », c’est en 35 pages sur 4 chapitres que les auteurs traitent du refactoring à plus grande échelle. La lecture et les exemples sont loin d’être palpitants et l’on peut même dire que le traitement du sujet en est largement superficiel. On préfèrera nettement la lecture du « refactoring to patterns » de Joshua Kerievsky à ce sujet !

La troisième partie « selected topics » est forte de 2 chapitres couvrant 30 pages. Le premier traite de la testabilité et de l’écriture des tests unitaire, là aussi un sujet bien mieux traité dans de nombreux ouvrages, tandis que le chapitre suivant est une sorte d’étude de cas qui ne restera pas gravé dans ma mémoire.

Au final, on peut considérer que ce livre est une sympathique, mais peu consistante distraction. Les illustrations qui émaillent le livre ajoutent à l’agrément. Il reste bien léger et à part les aspects traitant des commentaires, je n’en garderais pas grand chose. Vous pouvez passer votre chemin.

art-readable-code-oreilly

Référence complète : The Art of Readable Code, Simple and practical techniques for Writing better code – Dustin Boswell & Trevor Foucher – O’Reilly 2011 – ISBN : 978-0-596-80229-5

The Art of Readable Code

http://www.goodreads.com/book/add_to_books_widget_frame/0596802293?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 : Agile Adoption Patterns, a roadmap to organisational success, par Amr Elssamadisy

Note : 4 ; Le pattern ne fait pas le moine !

Etant à la fois amateur de patterns et de méthodes agiles, je me faisais un plaisir d’aborder cet ouvrage. De plus, Amir est un excellent ex-collègue que j’ai eu le plaisir de rencontrer. J’ai pu apprécier sa maîtrise du sujet et aussi sa grande humilité. Ce livra n’en reste pas moins une déception.

Les deux premières parties sont dédiées à une présentation générale (mais plutôt agréable) des valeurs et du sens de l’agilité, tandis que la seconde partie est consacrée aux « stratégies d’adoption ». Les deux axes en sont la valeur métier et les « mauvaises odeurs » conduisant à une direction / stratégie d’adoption. Cette partie se conclue par des propositions de roadmaps s’appuyant sur les patterns présentés au long des parties suivantes.

La troisième partie est forte de 38 chapitres couvrant 37 patterns (et un chapitre introductif) construits selon la forme dite « alexandrienne ». Ces patterns couvrent de très nombreux aspects des pratiques agiles, sinon toutes. Depuis la capture des besoins jusqu’aux pratiques de développements en passant par les pratiques supports telles que l’intégration continue, le rythme du projet, etc… Chacun de ces patterns traite de manière réduite (donc concentrée) chaque pratique en mettant l’accent sur les points forts et faibles de celles-ci. J’avoue avoir trouvé difficile de faire le lien entre les patterns, et ce malgré les roadmaps. La partie « sketch » sensée donner un contexte au pattern est hélas à mon goût trop stéréotypé : on croit entrer dans un monde où tout est parfait. Telle n’est pas mon expérience.

Les deux chapitres finaux consacrés aux retours d’expérience valent le détour : il s’agit tout simplement des rapports d’audit et de rétrospective de l’auteur sans aucun habillage ni concession. Outre qu’il met en évidence le travail de consulting de l’auteur il met aussi en lumière la réalité du terrain de l’adoption de l’agilité.

Ma déception face à cet ouvrage est probablement due au fait que ce texte ne s’adresse pas à moi ! J’ai ainsi eu du mal à y fixer mon intérêt. Un nouveau venu dans cet univers aura probablement un autre regard !

agile-adoption-patterns

Référence complète : Agile Adoption Patterns, a roadmap to organisational success – Amr Elssamadisy – Addison Wesley 2008 – ISBN : 0-321-51452-1 ; EAN : 978 032 151452 3

Agile Adoption Patterns: A Roadmap to Organizational Success


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

Note de lecture : MDA en action : Ingénierie logicielle guidée par les modèles, par Xavier Blanc

Note : 7 ; Un très bon livre, pour comprendre les concepts clés de MDA, les métamodèles associés et leurs mécanismes de transformation.

Mon snobisme naturel m’incite généralement à préférer les livres américains à leurs équivalents français. Le fait que je m’intéresse aujourd’hui à un ouvrage bien de chez nous ne doit rien à une quelconque cabale hexagonale, mais bien aux qualités intrinsèques dudit ouvrage.

MDA est un sujet complexe, qui nécessite d’en comprendre les fondements afin de pouvoir saisir les nombreux « buzzwords » que sont OCL, Semantic Actions, et autres CIM, PIM, PSM et MOF ! C’est exactement l’approche de ce livre : après un chapitre de présentation générale de MDA, on aborde tout de suite la pierre angulaire du MDA : le MOF (méta-object facilities) encore appelé méta-métamodèle ! Si il est un sujet ardu dans MDA, c’est bien ce fameux MOF (vous l’avez probablement compris rien qu’en lisant la phrase précédente). Mais l’auteur s’en tire fort bien, de manière exemplaire devrais-je même dire car au chapitre 6, on se plonge même dans la manipulation d’un métamodèle construit à l’aide du framework EMF d’Eclipse (celui-là même qui est au cœur de Rational Software Modeler / Architect) : bravo ! Bien sûr, il vous faudra avoir le goût des métamodèles, mais dans le cas contraire, MDA n’est probablement pas pour vous. UML2 est bien entendu abordé, et si vous n’aviez pas encore compris ce que sont UML infrastructure et superstructure (on ne saurait vous en blâmer) et la fameuse dépendance « merge », l’explication est ici. Je met juste un bémol sur les explications dédiées aux classes du métamodèle UML2 qui sont un peu fastidieuses.

Les standards connexes, si ils sont traités brièvement ne le sont pas moins clairement, avec une mention spéciale pour le traitement de XMI et DI (diagram interchanges) ce dernier sujet n’étant même jamais abordé dans les autres textes. De même, si vous êtes noyés dans les problèmes d’incompatibilités de XMI, la réponse est ici. La clé de voûte de MDA, la transformation de modèles n’est pas en reste, puisque l’auteur développe les 3 approches possibles : transformation par programmation, par « templates » et par règles de programmation, la 1ère et le 3ème approche étant par la suite illustrés dans la prise en compte des plates-formes d’exécution, J2EE et PHP respectivement, la transformation entre 2 métamodèles différent (car l’auteur présente un métamodèle PHP simplifié pour l’occasion) est carrément la cerise sur le gâteau ! On est pas loin du tour de force.

Sur le fond, l’approche de l’auteur (fusion des informations de transformation avec le modèle) s’oppose avec l’approche de Kleppe & Warmer qui est de séparer les informations de transformation du modèle. Personnellement je préfère cette dernière approche. Cela ne retranche rien à la qualité de cet ouvrage, que je conseille à la condition que vous recherchiez l’approche « en profondeur » et soyez friand de métamodèles !

L’étude cas et la présentation de deux outils MDA (Rational Software Architect et Objecteering MDA Modeler) ne sont pas la meilleure partie de l’ouvrage, mais elles complètent utilement celui-ci en donnant une illustration concrète.

Voilà donc un livre solide et complet sur MDA. Il requiert un peu e motivation pour aborder le sujet sous l’angle métamodèle, mais il équilibre de façon fort heureuse les principes et la pratique, le tout dans un volume raisonnable, puisque le livre compte 260 pages.

MDA en Action

Référence complète : MDA en action : Ingénierie logicielle guidée par les modèles – Xavier Blanc – Eyrolles 2005 – ISBN : 2-212-11539-3

MDA en Action


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

Note de lecture : Succeeding with Agile, Software development using Scrum, par Mike Cohn

Note : 8 ; Réussir la transition vers l’agilité

En quelques années et avec 2 livres remarquablement écrits, Mike Cohn s’est imposé comme l’in des leaders du mouvement agile. Voilà donc un livre qui pouvait difficilement passer inaperçu au sein de la communauté !

Globalement, le livre est assez pesant, dans tous les sens du terme : avec ses 450 pages, d’abord, ensuite parce qu’il est composé presqu’exclusivement de texte. Ce n’est pas un texte qui s’avale en un week-end ! Heureusement, Mike Cohn sait écrire et il fait mieux qu’aligner des platitudes, mais je pense quand même que la présente prose n’est pas aussi efficace que celle de l’excellent « agile estimating and planning ». C’est aussi que j’attends beaucoup d’un auteur capable de délivrer un livre d’excellente qualité.

L’une des premières impression qui m’est venue à l’esprit, est le parallèle entre ce livre et celui de Craig Larman « agile & itérative development ». Le livre est divisé en 5 parties, il nous faut bien les passer en revue, car le contenu s’avère au final plutôt riche !

La première partie « getting started » compte 5 chapitres qui totalisent 92 pages. Ce n’est hélas pas la meilleure partie de l’ouvrage. Un large focus est mis sur les communautés de transition vers Scrum, sujet qui m’est apparu abstrait et hélas peu convaincant. Cette première partie se termine sur le choix du projet pilote. Certainement cela s’adresse à ceux qui ont ce choix, donc un public assez restreint pour autant qu’il existe. Heureusement, les parties suivantes reprennent du poil de la bête.

La seconde partie adresse les individus. Longue de 80 pages, elle compte 4 chapitres. Mes deux chapitres préférés sont le chapitre 6 sur le traitement des résistances au changement : agrémenté d’exemples, j’ai trouvé le tour d’horizon complet et pertinent. La façon d’adresser les différents types de résistances est aussi fort judicieuse. J’ai également apprécié le chapitre sur le changement des rôles, il va plus loin que le simple « oubliez ce qui existait avant ». Le rôle du « functionnal manager, par exemple, simplement méprisé par la littérature agile en général, est bien pris en compte.

Avec près de 150 pages et 7 chapitres, la 3ème partie consacrée à l’équipe est la plus longue du livre. Elle traite à la fois la structure de l’équipe et les pratiques de Scrum. Il s’agit justement du chapitre le plus « Scrum » du livre, et l’auteur y livre sont point de vue subjectif sur nombre de pratiques Scrum. Bien que n’étant pas en accords avec tous les points de vue de l’auteur, je n’en considère pas moins cette partie extrêmement riche : elle nous guide littéralement vers la mise en place de Scrum. A noter le chapitre sur la planification qui est un résumé du livre précédent de l’auteur … et une invitation à lire celui-ci !

La quatrième partie est consacrée à l’application de Scrum aux organisations. J’avoue m’être moins intéressé à cette partie qui ne fait pas partie de mes préoccupations. Les 100 pages découpés en 4 chapitres de cette partie évoquent surtout Scrum appliqué en équipes multiples, la coexistence avec d’autres approches et toutes ces sortes de choses..

La cinquième partie a forme de conclusion, avec ces 2 chapitres et ses 20 pages. L’auteur nous signifie simplement qu’on n’est pas au bout du chemin. On ne l’est jamais. On y voit quels outils utiliser pour s’évaluer et quels horizons il reste à explorer.

Comme je l’ai dit au début, le livre est assez lourd, parfois fastidieux à lire. Néanmoins il n’en reste pas moins un ouvrage majeure de cette littérature Scrum encore naissante. Et je pense qu’il le restera. Comment, vous ne l’avez pas encore commandé ?

succeeding-with-agile-Cohn

Référence complète : Succeeding with Agile, Software development using Scrum – Mike Cohn – Addison Wesley 2010 – ISBN : 0-321-57936-4 ; ISBN13 : 978-0-321-57936-2

Succeeding with Agile: Software Development Using Scrum


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

Note de lecture : Software Development for Small teams: A RUP centric approach, par Gary Pollice, Liz Augustine, Chris Lowe & Jas Madhur

Note: 2 ; « J’écris un programme avec 3 potes, et j’en profite pour écrire un bouquin là-dessus ».

On pourrait presque s’écrier : à l’arnaque ! On n’en est pas loin, et une note de « 2 », c’est plutôt bien payé. Mais commençons par le commencement. Le livre ne porte pas sur l’adaptation d’UP aux petites équipes, mais d’un seul et unique projet sur lequel les auteurs ont essayé UP, c’est donc d’avantage une étude de cas qu’une synthèse d’experts. D’ailleurs, en fait de projet, il s’agit plutôt d’un développement fait en marge de l’activité professionnelle des auteurs, on est donc très loin des conditions normales d’un projet, mais par contre très proche des conditions de développement en « open source », ce qui n’est malheureusement pas identifié, et devrait être valorisé dans le titre. Il y a bien peu de chose à retirer de cet ouvrage ; les conditions de projet ne sont pas là, l’utilisation d’UP est plus expérimentale qu’autre chose, l’outillage employé (et éhontément promu dans le texte) inapproprié n’était-ce le fait que les auteurs les connaissent parfaitement et en disposent gratuitement. Une fois que l’on a lu cela, on peut à juste titre se dire que l’on peut tous se mettre à écrire son livre.

Les 2 seuls points intéressant sont la description du développement de type open source / distribué et l’aspect « post mortem » particulièrement bien abordé. En bref : ne perdez pas votre temps sur ce bouquin.

soft-dev-small-teams-RUP

Référence complète : Software Development for Small teams: A RUP centric approach – Gary Pollice, Liz Augustine, Chris Lowe & Jas Madhur – Addison Wesley / O.T. series 2004 – ISBN: 0-321-19950-2

Software Development for Small Teams: A Rup-Centric Approach


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

Note de lecture : Patterns of Enterprise Application Architecture, par Martin Fowler & al.

Note: 8 ; J’ai des scrupules à le juger excellent …

Franchement, rien que la première partie justifie l’achat du livre. En une centaine de pages, l’auteur parvient à faire le tour des aspects sur lesquels il faut opérer des choix d’architecture et les contraintes qui peuvent nous guider vers telle ou telle solution. Le tout est exposé clairement et simplement, avec limpidité devrai-je même dire, par comparaison aux autres ouvrages dédiés à l’architecture logicielle. Voilà qui devrait être une saine source d’inspiration pour les auteurs des pavés de 1000 pages !

L’auteur prend des positions nettes par rapport à ces choix, et c’est tant mieux. Cette première partie, par sa qualité et son narratif me rappelle “UML distilled” du même auteur.

En revanche c’est à “Refactoring” que me fait penser la seconde partie du livre, car Martin Fowler a utilisé ici la même présentation pour ses patterns. C’est plutôt une qualité, car j’avais déjà trouvé cette présentation claire et intéressante, même si elle tend à mettre beaucoup d’emphase sur le code (nous avons le droit à du Java – essentiellement – et aussi du C#) et parfois pas assez l’accent sur l’essence de la solution. Ces patterns (il y en a tout de même 51) sont regroupés en “thèmes” qui font le pendant aux chapitres de la première partie :

  • Organisation de la logique métier.
  • Architecture des sources de données
  • Mapping comportemental objet-relationnel
  • Mapping structural objet-relationnel
  • Mapping objet-relationnel des métadonnées
  • Présentation Web
  • Distribution des traitements
  • Gestion transactionnelle
  • Gestion des états
  • Patterns de base

Ce qui m’a certainement le plus troublé (et même choqué, devrais-je dire), c’est l’absence de référence aux autres ouvrages ! Et pourtant il devrait y en avoir. Pire : nombre de patterns présentés ici ne sont guère que des reprises de patterns déjà publiés. Les indécrottables de la galaxie Patterns (j’en fais partie) s’en offusqueront. C’est ce dernier point qui m’incite à ne pas attribuer un 10 à cet excellent livre. Il y a toutefois un aspect pratique : nous avons un livre complet et auto-suffisant de patterns applicatifs dans lesquels faire notre marché pour les applications d’entreprise. Et cet ouvrage est de haute qualité, cela mérite certainement quelques concession… Martin Fowler nous a plus ou moins suggéré qu’il pourrait y avoir un second volume: nous l’attendons toujours…

patterns-enterprise-architecture

Référence complète : Patterns of Enterprise Application Architecture – Martin Fowler with David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee and Randy Stafford – Addison Wesley / Signature series 2002 – ISBN: 0-321-12742-0

Patterns of Enterprise Application Architecture


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