Note de lecture : Agile Coaching, par Rachel Davies & Liz Sedley

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Une vision claire de ce qui est nécessaire à un projet agile, mais un texte plutôt entre la conduite de projet et le coaching proprement dit.

Coacher une équipe pour la rendre agile est sans aucun doute un exercice difficile. Que faire ? Comment interférer, comment aider l’équipe à se prendre en main, à quel moment faut-il faire preuve de fermeté ? Bref, faire les bonnes actions, adopter les bonnes approches et les bonnes attitudes ne sont pas choses aisées et la frontière entre le succès et l’échec est parfois bien mince.

L’objectif de ce nouvel opus des pragmatic programmers est d’aider le coach à agir de manière opportune le long des pratiques agiles classiques. L’écueil de ce type d’ouvrage est de tomber dans une nouvelle description des pratiques agiles en négligeant la façon dont le coach doit ou peut entreprendre l’équipe sur chacun de ces sujets.

Je ne vais pas revenir sur chacun des chapitres, il y en a 14, pour 200 pages, sachez donc que la brièveté des chapitres joue en faveur de l’efficacité du texte et donne un rythme à la lecture, celle-ci n’est donc pas pesante. Je peux toutefois dire quelques mots à propos des 4 parties qui découpent le livre.

La première partie (ainsi que la dernières) sont celles qui concernent réellement la partie coaching « humain ». Les 4 chapitres couverts sur 58 pages sont consacrées au travail avec les personnes et avec les équipes. Le parti pris est ici de « coacher par l’exemple » et non de se ternir en retrait. Bien sûr l’observation, le feedback et la communication font partie des outils abordés. C’est fort peu à propos que je parle d’outil, car le texte montre plutôt des directives et si j’ai certaines idées générales une fois la dernière page tournée, je me suis quand même senti plutôt démuni.

La seconde partie nous montre clairement que l’expérience des auteurs vient plus des projets agiles que du pur coaching. En effet cette partie est consacrée aux pratiques de projet : planning meeting, stand-up, etc… Le tout sur 4 chapitres et un nombre de pages qui va de pair avec la première partie. Ici on est en terrain solide et les auteurs savent parler de la matière. Dommage que la matière n’ait plus l’attrait de la nouveauté car ces sujets ont déjà été largement traités par ailleurs. Le texte est intéressant mais devrait prendre place dans un ouvrage sur les projets agiles plus que dans un texte consacré au coaching.

Un pas plus loin, la troisième partie traité des pratiques de craftmanship : qualité du code, build, définition du « done ». Là encore les auteurs connaissent leur sujet, mais on en est plus à donner des conseils sur les pratiques de développement qu’à guider l’équipe ou ses membres.

La quatrième partie est dédiée au feedback : démo, rétrospective et progression du coach lui-même. Le chapitre sur la démo est dans la continuité des chapitres précédents, donc d’avantage lié à la conduite de projet qu’au coaching tandis que le chapitre sur la rétrospective, s’il est plus dans la continuité de ce à quoi je m’attendais n’est qu’un condensé de « Agile retrospective » d’Esther Derby, lecture que l’on préfèrera. Cette partie me laisse un goût d’inachevé.

Au final, le bilan est assez mitigé. J’ai trouvé que l’ouvrage insistait trop sur les pratiques déjà bien connues : standup, planning meeting, rétrospectives, démonstrations, ainsi que sur les activités d’ingénierie (build, design, tests). Fort heureusement, le tout est émaillé de conseils et d’histoires venant de l’expérience des auteurs. Mais ceux-cis ne constituent pas une part assez importante du livre à mon goût. J’avoue avoir quand même apprécié les sections « hurdle » et « check-list » à la fin de chaque chapitre.

Si je semble quelque peu déçu (et peut-être un peu sévère dans a notation), c’est sûrement que j’attendais beaucoup de ce livre en particulier et du « pragmatic bookshelf » en général, dont la qualité s’avère quand même élevée de manière récurrente. Mais je n’irais pas jusqu’à déconseiller la lecture de ce livre. Au pire, vous y aurez appris des choses sans consacrer trop de temps à la lecture !

agile-coaching-pragprog

Référence complète : Agile Coaching – Rachel Davies & Liz Sedley – Pragmatic Bookshelf 2009 – ISBN : 978 1 93435 643 2

Agile Coaching


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

Les 30 jours du Canard

Le par addinquydans ArticlesLaisser un commentaire

Depuis quelque temps j’utilise Duck Duck Go comme moteur de recherche. Je souhaitais donner sa chance à une alternative à Google. C’est la moins commerciale des options en présence. Voici mon feedback.

Présentation

Duck Duck Go (je vais simplement l’apeller DDG à partir de maintenant) est un moteur de recherche dit “hybride” qui s’appuie à la fois sur ses propres crawlings et sur des moteurs de recherches externes. Deux aspects (par ailleurs très corrélés) ont mis en luière ce nouveau venu dans la bataille des moteurs de recherche:

  • Il est désormais le moteur de recherche par défaut de plusieurs distributions Linux.
  • Sa politique de respect de la vie privée, DDG ne conservant aucune information nominative de navigation !

L’un des reproches grandissant à l’encontre des moteurs de recherche en général et de Google en particulier concerne les règles de ranking. Aujourd’hui Google intègre dans ses rankings des paramètres locaux mais aussi des paramètres liés aux recherches précédentes des utilisateurs. Cela introduit un “biais de confirmation”. En clair: si vous recherchez des avis ou des informations sur un sujet controversé, disons par exemple le créationisme, vous aurez des chances de tomber en premier sur des sites pro-créationistes si vous êtes l’un d’entre-eux car vos recherches précédente auront tourné en ce sens. L’exemple est un peu grossier, mais vous comprendrez l’idée générale ! Evidemment, cette caractéristique va rendre les résultats apparemments plus désirables car ils iront d’avantage dans le sens de vos opinions initiales. Mais vous avez aussi moins de chance d’apprendre quelque chose de nouveau ou de confronter une opinion différente !

Duck Duck Go s’écarte délibérément de ces traits de personalisation. Donc outre la comparaison des résultats remontés, le ranking des informations est aussi intéressant à comparer !

Les recherches vagues

Aujourd’hui, une recherche que j’apellerais “vague” est composée de deux ou trois terme. Faire une recherche à un seul terme est à peu près inutile car ce n’est pas suffisamment discriminant. En fait aujourd’hui la plus grande part des recherches sont faites sur deux mots !

Sur ce type de recherches les deux moteurs m’ont paru globalement de pertinence égale par rapport à ce qui est remonté.

L’un des tests classiques est de rechercher sur mon nom.

  • Google flatte plus mon égo en remontant très haut, mon blog, mon profil LinkedIn ainsi que diverses choses que j’ai comises dans un passé pas très éloigné.
  • DDG est moins complaisant. Il ne va pas remonter plus haut ce que j’aimerais voir haut. Par contre il va me remonter des choses plus inattendues et que j’aurais même cru définitivement perdues pour certaines.

Dans certains cas de figure particuliers, DDG ne parvient pas à me remonter ce qui m’intéresse, alors que Google y parvient. Je n’ai pour l’instant jamais fait l’expérience inverse.

Ergonomie

Il serait dommage de passer sous silence l’apect ergonomique. DDG se distingue positivement du géant de Mountain View par l’absence de liens sponsorisés d’une part et d’autre part par un affichage particulièrement clair facilitant le repérage des sources par l’iconographie située à gauche. Je m’en sert pour repérer nottament les liens vers Wikipedia ou Twitter. Autre originalité, le propositions de termes secondaires situés à droite. Honnêtement, je les ai essayés de temps à autres mais n’en ai pas encore perçu l’utilité ou la pertinence. Mais l’idée parait bonne.

Les recherches précises

Dans ce cas, les choses se compliquent sérieusement pour DDG. Il s’agit des recherches où je souhaite cibler du contenu particulier avec 5 ou 6 termes. Je dois bien l’avouer DDG échoue souvent à me remonter ce qui m’intéresse, du moins avec un ranking valable. Je tombe à moins de 20% de recherches courronnées de succès (c’est un pourcentage au feeling, je n’ai pas de mesure précise), alors que je suis plutôt dans les 50% voir plus pour Google.

J’avoue que j’essaie généralement les deux recherches dans cette configuration. Parfois même vais-je directement sur Google. Au mieux, les deux recherches ont des pertinences équivalentes. Au pire, DDG prend cher.

Je suis venu te dire que je m’en vais ?

La bataille, au simple niveau de la pertinence tourne à l’avantage de Google ! Mais il ne faut pas négliger l’aptitude de DDG à remonter de “l’inattendu”. Parfois, c’est justement là où vous trouverez votre bonheur. Dans de rares cas, c’est ce qui m’est arrivé.

Les recherches pointues continuent à laisser à Google une confortable longueur d’avance, aucun doute là-dessus.

Maintenant la vrai question : la position éthique de DDG compense-t-elle sa performance en retrait par rapport à Google ? Dit autrement: vais-je garder DDG comme moteur de recherche par défaut ?

Au début, j’aurais répondu Non. Mais aujourd’hui je le trouve suffisemment bon dans la plupart des cas (sans compter un affichage supérieur esthétiquement dans les résultats de recherches), même si je dois régulièrement sur Google. Je vais donc le garder jusqu’à nouvel ordre, en espérant qu’il s’approche de son redoutable concurent !

Une dernière chose…

Le titre de ce post est inspiré du titre d’un film, saurez-vous le reconnaitre ? Je laisse le plus affuté et/ou le plus rapide répondre ici même !

Le Lean Startup expliqué aux développeurs, par Camille Roux

Le par addinquydans Compte-renduLaisser un commentaire

Camille Roux est le (jeune) fondateur de Human Coders et un adepte du Lean Startup, sinon un évangéliste et un addict ! Je n’ai hélas pas encore eu l’opportunité d’assister à une de ses présentations ni d’échanger avec lui (j’espère remédier à cela un jour prochain).

Voici un support de présentation sur l’approche Lean Startup qu’il a employé pour la création de Human Coders

Note de lecture : Blue Ocean Strategy par W. Chan Kim & Renée Mauborgne

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; La stratégie de la non compétition expliquée

Le « blue ocean strategy » est devenu un grand classique du marketing, et ce livre en est la bible. La première partie explique (exemples à l’appui) ce qu’est cette stratégie et pourquoi elle est si porteuse. Les exemples sont clairs tout comme l’est le raisonnement.

En deux mots, et en simplifiant beaucoup : plutôt que de combattre dans un secteur d’activité fortement concurrentiel où l’on se comparera aux compétiteurs en terme de prix d’images ou de performance (le red ocean), l’idée est de créer son propre espace (le blue ocean) où l’on ne peut être comparé aux autres acteurs du marché. Bien sûr, c’est plus facile à dire qu’à faire. Tout d’abord cela à fort à voir avec l’innovation et ensuite il faut s’assurer que la création de ce nouveau marché attirera des clients, que ce soient les anciens ou un nouveau segment.

La suite du livre se focalise sur la démarche pour arriver dans ce type de positionnement. La aussi, et toujours bien aidé par des exemples on comprend ce qu’il faut faire et ne pas faire. Cela commence par les « principes de formulation » : se focaliser sur la « big picture », aller chercher au-delà de la demande directe formulée par le marché, etc.. Pour cela on utilise la nouvelle courbe de valeur : quels facteurs doivent être réduits ? Lesquels doivent être augmentés ? Lesquels doivent être éliminés ? Lesquels doivent être créés, que l’industrie n’a jamais offert ?

La seconde partie « formuler le blue ocean » se focalise sur la façon de faire émerger celui-ci d’un marché existant. La chapitre 3 évoque la reconstruction des limites du marché. Les auteurs proposent 6 chemins pour cela :

  • Examiner les autres secteurs industriels susceptibles de proposer une alternative.
  • Examiner les sous-ensembles de stratégies au sein du secteur industriel où l’on opère.
  • Explorer la chaine d’achat.
  • Evaluer l’offre des produits et services complémentaires.
  • Evaluer l’attraction fonctionnelle et émotionnelle des acheteurs.
  • Regarder les tendances à travers le temps.

Les 6 directions qui devront être explorées serviront à construire le planning stratégique. C’est le sujet du chapitre 4 : construire la « big picture ». Celui-ci propose de Visualiser cette stratégie en 4 étapes :

  • Visualiser la prise de conscience.
  • Visualiser l’exploration (en s’appuyant sur les 6 chemins vus précédemment)
  • Visualiser la stratégie à venir.
  • Visualiser la nouvelle stratégie en terme de « avant / après ».

A partir de là, le chapitre 5 évoque la façon de dépasser la demande existante. C’est le principe des trois tiers de « non clients » qu’il faut identifier, au-delà de ce qui est notre marché actuel : ceux qui sont prêts à devenir nos clients, ceux qui refusent d’être nos clients et ceux qui ne sont simplement pas explorés.

Le chapitre 6 se concentre sur l’exécution du plan stratégique : évaluer l’utilité pour l’acheteur, cibler le prix, calculer les coûts et construire l’adoption.

Il faut maintenant exécuter un plan qui nous y amènera : c’est le sujet de la troisième partie.

Le chapitre 7 évoque les obstacles organisationnels. Ils peuvent être cognitifs (le blocage sur le statu quo), politiques (l’opposition de ceux qui n’ont pas intérêt à sortir de la situation existante), motivationnels ou liés aux ressources existantes limitées.

Le chapitre 8 se focalise sur le « fair process » : comment mettre en action une nouvelle stratégie dans l’entreprise en engageants les personnes qui y participeront ?

La stratégie « blue ocean » n’est pas un processus statique, elle s’entretient et évolue dans le temps. Le chapitre 9 évoque la tenue de ce processus dans le temps.

Personnellement, étant un béotien du marketing, ce fut une découverte, une nouvelle façon de voir le positionnement d’un produit. Il s’agit d’une nouvelle façon de dire : « si les règles du jeu ne te plaisent pas, change les règles ! ». Il s’agit aussi probablement d’une application particulière de certains préceptes de l’art de la guerre.

Je recommande vivement !

Blue Ocean Strategy

Référence complète : Blue Ocean Strategy: How To Create Uncontested Market Space And Make The Competition Irrelevant – W. Chan Kim & Renée Mauborgne – Havard Business Press 2004 – ASIN : B001E5207M (Kindle edition)

Vous trouverez aussi en ligne une mind map reprenant les éléments du livre

Blue Ocean Strategy: How To Create Uncontested Market Space And Make The Competition Irrelevant


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

Mes retours sur l’Agile Day Valtech 2012

Le par addinquydans Compte-renduLaisser un commentaire

Ce 19 Juin 2012, Valtech nous accueillait dans ses locaux du 103 rue de Grenelle pour une journée de présentations et d’atliers dédiés à l’agilité. Quelques retours.

Keynote

C’est toujours quelque chose d’écouter Laurent Sarrazin ! Il y a du dynamisme, de la substance, beaucoup d’anglicisme et des phrases choc ! C’est sous un format singulièrement raccourcis que Laurent nous a présenté Sweet Rupture qu’il avait déjà joué au Scrum Day. Je n’avais alors assisté qu’à une partie de cette présentation. Ici, j’ai tout vu, mais en accéléré !

Laurent nous raconte l’odyssée du centre agile de la société générale et ses nombreuses sources d’inspiration qui en font de “l’agilité Benetton” selon ses propres mots. Difficile de raconter cette session, je vous propose plutôt d’en visonner la version longue  celle du Scrum Day.

Kanban game

Laurent Morisseau est probablement l’une des personnes les plus pointues en France sur l’application de Kanban en France. Il est d’ailleurs l’auteur d’un livre qui arrive en librairie ces jours-ci : Kanban pour l’IT. Vous devriez d’ailleurs avoir droit à une note de lecture à ce sujet dans euh … un certain délais, car Laurent a eu la gentillesse de m’en faire parvenir un exemplaire !

Cet agile game est désormais un classique, car Laurent a déjà joué le Kanban Game à de nombreuses reprises. Toutefois je n’avais jamais eu la possibilité d’y participer. J’étais donc bien décidé à combler cette lacune.

Je n’ai pas été déçu, d’autant que Laurent et son complice Dimitri Baeli (visiblement faire collaborer Bretons et Normands est donc possible) sont rompus à l’exercice. Nous avons donc exécuté par équipe de 6, 8 itérations de développement afin de délivrer de la valeur, mais surtout de l’argent (eh oui : la valeur délivrée tôt capitalise et rapporte plus…). Voici ce que j’en ai trouvé:

  • Le jeu est intéressant et prenant, la qualité de l’animation aide sans aucun doute !
  • Des équipes de 6, c’est un peu trop: on se marche sur les pieds et cela génère trop de discussions quand aux différents choix !
  • Le jeu met bien en évidence les “limites de WIP” et le focus sur le flux et les goulots d’étranglements.
  • L’aspect “comptabilité” est un peu complexe et ce n’est pas évident d’en tirer les enseignements. Au minimum, il aurait fallu passer plus de temps (encore !) pour les décoder.
  • Le timing était un peu trop serré, mais c’était lié à l’agenda spécifique de cet Agile Day. Les conditions normales requièrent un peu plus de temps.

Bref, je suis satisfait de cet agile game qui matérialise très bien les aspects principaux du Kanban.

Outside in Design : the BDD way

Cette session présentée par Marcus Anhve de Valtech Suède était pour moi la session hard core de cette journée ! Concrètement, cette session dédiée au Behaviour Driven Developement par l’exemple était d’un abord ardu pour moi : Marcus a réalisé ses exemples en Ruby (que je ne connais pas), en y ajoutant du Rails, de la compilation avec Rake  et évidemment du RSpec pour l’acceptance testing ! Sans oublier un moteur de templating pour le HTML que j’ai justement oublié …

Bref, au-delà de la présentation d’introduction il me fut très difficile de suivre le fil, j’ai juste réussi à ne pas être complètement noyé. Respect pour notre très cool présentateur qui a réussi à faire du “par l’exemple” avec absolument aucun code préparé à l’avance et en réalisant absolument tout en live ! Franchement il faut le faire et c’est la première fois que je le vois ainsi fait intégralement. Marcus m’a confié qu’à son avis c’est vraiment la bonne façon d’exposer la façon dont on avance et on construit les choses : de le faire sans tricher !

Innovation needs waste

Ce fut ma sesion préférée de la journée ! L’animateur de cette session, Dirk Lässig de Valtech Germany était venu nous initier au Design Thinking. Dirk a intelligemment combiné une présentation limpide avec un exercice hélas un peu trop sous la contrainte du temps !

Le Design Thinking, quest-ce que c’est ? Une approche et un ensemble de pratiques pour permettre l’innovation radicale, celle qui n’est pas une simple amélioration d’idées existante mais l’émergence d’un concept nouveau en rupture avec l’existant !

Les approches agiles parlent souvent de “vison” et de son importance. Mais d’où vient-elle ? D’une personne particulièrement géniale qui l’a sortie de son chapeau à l’aide d’un quelconque tour de magie ? Faire émerger les Visions innovantes ne doit plus être comme le-boulot-de-quelqun-d’autre-car-nous-on-écrit-du-code ! Le design thinking nous apprend à mettre ensemble des personnes d’horizons différents justement pour élargir le champs du possible. Et justement pour élargir ce champs il faut générer des idées sans se censurer, même si au final la plupart et peut-être même toutes seront écartées.

Nous avons donc tenté (avec un succès mitigé, je le crains) d’abord d’identifier des cibles et des contextes d’utilisation pour une application smartphone, puis de développer ce concept à l’aide de techniques de brainstorming. Bien sûr en si peu de temps, il ne pouvait s’agir que de jeux de l’esprit. Toutefois un peu plus de temps aurait certainement produit un résultat plus pertinent.

Mais j’ai appris une nouvelle chose, un nouveau territoire à explorer qui fait le lien avec d’autres que je connais. J’ai aussi remarqué et apprécié la synergie très importante entre cette approche et le Lean Startup. D’ailleurs cette technique est fugitivement évoquée dans le livre d’Eric Ries. Ici aussi on parle d’emettre une hypothèse, de confronter celle-ci à la réalité le plus vite possible, d’apprendre sur cette base et d’itérer en s’appuyant sur ce que l’on a appris.

Bravo Dirk !

L’agilité au service du marketing, une révolution en marche

Une mauvaise pioche m’a fait choisir cette session que j’ai trouvé la plus décevante de la journée ! J’étais impatient de voir et comprendre l’agilité projeté dans le domaine du marketing. Hélas la présentation de Laura Guillemin manquait cruellement de substance ! Certes, la bonne idée de cette présentation était d’y faire participer des acteurs métier (mais aussi un consultant). Alors oui, on peut facilmement se douter que les plan marketing à long terme se voient balayés par les itérations rapides et les possibilités qui nous sont offertes de mesurer les impacts dans l’économie numérique ! Mais même un gros bourrin d’informaticien comme moi sait cela depuis longtemps.

Il existe une substance, des concepts dans le marketing numérique dont j’ignore même l’existence. Un question venant de la salle (mais vite balayée) sur les modèles d’attribution en a été l’un des exemples. Bref, je n’ai rien appris !

Keynote de cloture

A la session de Laura Guillemin, j’ai largement préféré la cloture que nous a proposé Scott Brinker ! Difficile de résumer cette intervention vraiment très riche. Je vous recommande la présentation qui est en lien, ce support est vraiment très bon (avec un petit arrêt sur le slide 16). Le(s) message(s) de base de cette présentation est (sont):

  • Tout est marketing !
  • Tout le monde doit être agile !

Un grand merci à Valtech d’avoir organisé cette journée !

Note de lecture : Concurrent Programming in Java, second edition, par Doug Lea

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 9 ; Un remarquable ouvrage sur le multithreading, pour Java et pour les autres langages également … même si on accueillerait volontiers une mise à jour !

J’ai écrit cette note en 2005. Les livres liés à des technologies particulières ont fâcheusement tendance à mal accueillir le passage du temps. Celui-ci subit moins cette tendance car il s’intéresse plus aux concepts sous-jacents mais il vous faudra certainement relativiser certaines parties de mon propos.

S’il est un sujet d’importance sur le développement Java peu abordé aujourd’hui, c’est bien la programmation concurrente. Sans être ignoré, le multi-threading est largement mis de coté, ne serait-ce que parce que le développement coté serveur ne permet pas sa mise en œuvre. Or, il s’agit bien là d’un aspect majeur de conception, important coté client, et plus important encore avec l’avènement des clients riches. O, développeur Java, tu as bien de la chance dans ta misère, car à ta disposition un livre sur le multithreading tu as ! Nous parlons bien entendu du livre de Doug Lea. Bien sûr, il existe d’autres livres sur le sujet, ne vous attardez pas sur ceux-là : le livre de Doug Lea est LE livre. En fait, Doug Lea est le multithreading en Java, car depuis la version 1.5, l’API officielle dédiée au multi-threads est celle développée par l’auteur.

Mais revenons au livre lui-même. Et là, comme disent les jeunes : c’est du lourd ! La lecture des 380 pages du volume n’a rien d’une promenade bucolique, le texte et l’information sont denses. On aurait pu s’attendre à un livre traitant des spécificités de Java sur le multithreading, cet ouvrage va bien au-delà. Comme indiqué dans le titre, on parle avant tout de principes de conception et de patterns, puis de mise en œuvre en Java. C’est l’une des forces du livre : focaliser sur des principes de conceptions à l’aide de patterns, décrivant ainsi le contexte d’utilisation. L’ensemble est supporté par des représentations UML lorsque c’est nécessaire et du code Java avec juste le niveau de détail qui convient. On dénombre ainsi 17 patterns, répartis en 4 chapitres seulement, couvrant les sujets suivants :

  • La programmation concurrente : Ce chapitre évoque les principes de base de la programmation multithreads et des concepts liés tels que la synchronisation, les queues d’évènements, les pools de threads, etc. La base, quoi !
  • Les exclusions : On attaque les choses sérieuses, ou quelles sont les stratégies de base sur l’exclusion (l’élimination, la gestion dynamique ou la gestion structurelle), et comment celle-ci se déclinent en 5 patterns.
  • Les dépendances d’états : Ce chapitre nous montre comment géré en environnement concurrent des comportements dépendants d’états.
  • La création de threads : On couvre ici les choix de conception lié à la gestion au partage et à la création de threads.

Au cas où ce matériel ne suffirait pas à assouvir votre soif de savoir, l’auteur dispense 2 ou 3 pages de références de « lectures supplémentaires » en fin de chaque chapitre. De quoi satisfaire n’importe quelle boulimie ! Les chapitres en eux-même sont hélas un peu volumineux, ce qui conduit à un chapitrage à 4 niveaux, ce qui est trop. L’auteur aurait dû découper le livre en autant de parties et réaliser des chapitres plus courts. Ce sera peut-être ma seule critique.

La qualité de ce livre est en tout point remarquable, c’est en fait une référence incontournable pour quiconque désire s’attaquer au multithreading sur des systèmes objet, même au-delà du langage Java !

Ce livre fait sans contestations possibles, partie de la catégorie des excellents surprises, il est en tout point remarquable, aussi bien par sa couverture du sujet que par sa qualité pédagogique, et ce malgré le niveau relevé du texte. C’est de fait une référence incontournable pour quiconque désirerai s’attaquer au multithreading sur des systèmes objet, même au-delà du langage Java ! Finalement, j’ai un autre regret à formuler : cette édition accuse 5 ans, une 3ème édition mise à jour par rapport à Java 1.5 serait la bienvenue.

Allez Doug, t’as bien mérité ton 9 !

concurent-programming-java

Référence complète : Concurrent Programming in Java, second edition: Design principles and patterns – Doug Lea – Addison Wesley / Java series 2000 – ISBN: 0-201-31009-0

Concurrent Programming in Java: Design Principles and Pattern


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