Note de lecture : DSDM, Business focused development, 2nd edition, par Jennifer Stapleton edt.

Note : 5 ; L’agilité, vue par nos voisins anglais.

Tout comme le « XP explained » de Kent Beck, cet ouvrage peut être vu comme l’argumentaire de DSDM que comme la synthèse de la méthode qui est plutôt montrée en filigrane ! N’hésitons pas à le dire, cela nuit beaucoup à la qualité de l’ouvrage (sans préjuger de la qualité de la méthode). Je pense que la raison principale de ce choix est de ne pas empiéter sur les documents du consortium DSDM réservés aux adhérents. Ce genre de choix est toujours délicat, mais un peu malheureux ici, en l’occurrence. Au niveau de la qualité du texte, on remarquera que pour un ouvrage collectif, celui-ci est agréable à lire, il n’est pas trop long, comme c’est souvent le cas dans ce genre de situation, les chapitre sont courts et l’on ne perçoit ni redondance ni différence de style, hormis dans la partie dédiée aux retours d’expérience.

Car l’une des originalités intéressantes de ce livre est de consacrer une moitié de l’ouvrage à des retours d’expérience, judicieusement choisis afin d’éclairer des aspects particuliers de la méthode. Une bonne idée qui devrait être plus souvent reprise.

Si vous vous intéressez à DSDM, ce livre est tout simplement incontournable, car c’est le seul qui existe. Il ne saurait suffire toutefois, et c’est bien dommage, à la compréhension de la méthode. Il faudra pour cela aller surfer sur le site Web ci-dessous, ce qui était probablement un des buts inavoués. Mais cela est franchement un peu pusillanime.

DSDM

Référence complète : DSDM, Business focused development, 2nd edition – The DSDM consortium, Jennifer Stapleton edt. – Addison Wesley / ASD series 2003 – ISBN: 0-321-11224-5

DSDM: Business Focused Development


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

Scrum Night II : l’appel du 19 Avril

C’est parti !

Ca y est, l’évènement est en ligne depuis une petite semaine. Assez longtemps pour que l’on se retrouve avec un évènement complet et une liste d’attente digne des bouchons du 15 Août !

Alors je sais, c’est chez Google. Ce nom magique éveille tous les intérêts, anime toutes les passions ! Hé ! Vous avez bien remarqué qu’il n’y a encore aucun programme ?

Avoir un programme dépend de vous ! Si personne ne propose d’atelier, nous écouterons du Rap pendant 3 heures. je vous le dit tout net, je n’y survivrais pas.

Qui peut proposer un atelier ?

Tout le monde ! Si les innovation games sont un sujet qui vous passionne et que vous êtes aguerri(e) à la pratique de l’un d’entre eux, alors n’hésitez pas plus longtemps : proposez votre sujet !

Bien sûr, il est mieux d’avoir un peu d’expérience de son sujet. Mais les expérimentations seront aussi bienvenues. Nous porteront une attention particulière aux ateliers qui n’ont pas été proposés pour la 1589ème fois. Ah, c’est vrai: nous ne serons pas seul à décider, vous en serez aussi. J’y reviens dans 2 minutes.

Et si je veux participer à l’animation, mais que je ne me vois pas proposer un atelier moi-même ?

Oui, cela sera possible ! La méthode que nous avons retenu pour les propositions va permettre cela. Il est temps d’en parler.

Une nouvelle façon de proposer les sujets

Nous innovons pour cette Scrum Night II : Les sujets devront être proposés Sur IdeaScale : 

Dans la catégorie “Scrum Night II” (si vous avez suivi le lien, vous y êtes déjà), vous soumettez simplement votre sujet avec le bouton Idoine. Il vous faudra préciser:

  • Le titre de votre atelier, bien entendu
  • Le nom des animateurs
  • L’objectif de l’atelier
  • Un petit descriptif de celui-ci

Chaque sujet ouvre un fil de discussion. Vous pouvez poser des questions, ou proposer votre aide à l’animateur. Pourquoi pas ?

C’est jusqu’à quand ?

Jusqu’au 13 Mai ! C’est vrai, ça fait peu de temps avant la date fatidique de ladite Scrum Night, donc tenez-vous prêt. Visiblement, cela ne conditionnera pas l’affluence qui est déjà … euh … affluente !

Cette date tardive nous permettra d’intégrer des propositions d’atelier faisant suite à Agile Games France qui se sera terminé la veille. Autant dire qu’il ne faudra pas tarder pour les joyeux participants à cet évènement (j’en serais).

Soyez acteur du choix des ateliers

Vous l’avez certainement vu en allant sur IdeaScale, vous pouvez voter positivement (en accord) ou négativement (en désaccord). Les tendances qui émergeront seront prises en compte dans le choix des ateliers, mais on ne sait pas encore vous dire comment. Nous même d’avons pas encore décidé…

Bref, allez de temps en temps sur IdeaScale, voir les ateliers qui seront proposés d’ici le 13 Mai pour donner votre avis. Attention, d’expérience le gros de la troupe arrive à la fin, mais nous ferons le vote dans les 2 ou 3 jours qui suivront, donc ça va aller assez vite à ce moment là !

J’comprend rien !

Si vous êtes un lecteur assidu du “Guide du Routard Galactique” de Douglas Adams, vous savez que sur cet illustre ouvrage figure en première page ces mots magiques: “Pas de Panique !”. Je vais donc les répéter ici:

Pas de panique !

  • D’une part, vous pouvez contacter le bureau en envoyant un mail à orateur@frenchsug.org
  • D’autre part, vous pouvez poser une question ou faire un commentaire ici même !

Nous espérons vous voir nombreux à proposer des ateliers !

Note de lecture : More about Requirements, par Karl E. Wiegers

Note : 7 ; Karl Wiegers n’a pas tout dit !

Comme son nom l’indique, ce petit opuscule (185 pages) est un complément au classique « Software Requirements » du même auteur, et plus précisément à la seconde édition de cet ouvrage. Plus que d’être un livre par lui-même, ce texte fait un peu l’effet d’être un complément d’information. Aussi je déconseille fortement de plonger dans cette lecture si vous n’avez pris d’abord le temps d’étudier le premier ouvrage. Si vous l’avez fait et l’avez apprécié (ce qui est mon cas), cette lecture poursuit le plaisir.

Le format du livre est réellement inhabituel, il rappelle celui, un peu déconcertant, de Kent Beck : l’ouvrage compte 23 chapitres répartis en 7 parties. Pour un livre de 185 pages. Faites le calcul, la moyenne de chacun d’entre-eux se situe aux alentours de 8 pages ! En fait, je trouve cela fort agréable, car on a le sentiment que chaque chapitre a un objectif « tactique » et que celui-ci doit être atteint le plus efficacement possible. Et cela rythme bien la lecture. Par contre, on a aussi l’impression que chaque chapitre est traité assez superficiellement. En fait les renvois vers le livre principal sont assez nombreux, on est parfois aux limites de la FAQ.

La première partie est consacrée aux concepts : ce qui est vrai ou faux concernant la gestion des exigences et aussi la « big picture » des types d’exigences vue par Karl Wiegers, que j’aime particulièrement.

La seconde partie se focalise sur la partie management des exigences : comment peser le retour sur investissement ? Comment en estimer l’effort ? Comment planifier ce travail et le répartir tout au long du projet ?

L’interaction avec les utilisateurs est abordée dans la troisième partie. Ici c’est l’élément humain qui est décortiqué, et l’on s’intéresse à la meilleure façon de collaborer avec un utilisateur.

La quatrième partie est dédiée aux cas d’utilisation : que sont-ils, quels sont les concepts importants et quand est-il utile de compléter ce formalisme par un autre ou tout simplement de l’abandonner au profit d’un autre !

La rédaction des exigences est un problème crucial, car elle détermine la qualité et l’utilisabilité effective du produit final. La cinquième partie est dédiée à ce sujet.

Karl Wiegers reste un homme de processus, et la sixième partie recadre la gestion des exigences dans un processus projet : définition de la portée du projet, gestion du changement, etc..

Enfin la dernière partie aborde le volet « gestion » : de quels indicateurs peut-on avoir besoin ? Comment gérer les exigences à travers plusieurs releases d’un projet ou comment aborder le choix d’un outil de gestion des exigences.

Cet ouvrage n’est certainement pas un ouvrage de référence, comme peut l’être le « Sotware Requirements, 2nd edition », mais c’est une bonne lecture complémentaire. Le propos de Karl Wiegers fait souvent mouche et apporte grandement au sujet. Je vous engage donc à poursuivre la lecture du premier ouvrage cité par celui-ci !

more-about-requirements

Référence complète : More about Requirements – Karl E. Wiegers – Microsoft press 2006 – ISBN: 0-7356-2267- 1

More About Software Requirements: Thorny Issues and Practical Advice: Thorny Issues and Practical Advice

http://www.goodreads.com/book/add_to_books_widget_frame/0735622671?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 : Succeeding with Use Cases, Working smart to deliver quality par Richard Denney

Note : 6 ; Excel à la rescousse des cas d’utilisation, ou comment les colorier au-delà du trait.

Ce livre ne va pas vous apprendre à modéliser avec les cas d’utilisation, mais il va vous apprendre à les utiliser plus avant, notamment dans une optique qualitative. Ce livre est découpé en 4 parties indépendantes, qui constituent autant de facettes d’utilisation améliorée des cas d’utilisation.

La première partie est consacrée aux « QFD » ou Quality Function Deployment, qui permet non seulement de tracer les cas d’utilisation vers les « business drivers » ou vers les exigences, mais permet d’en calculer les priorités. La méthode est simple et adaptable, et si l’on considère que l’auteur va jusqu’à montrer concrètement comment la matrice QFD se construit avec Excel, on ne voit guère ce qui empêche d’exploiter cette technique.

Excel est également utilisé dans la seconde partie dédiée aux SRE (Software Reliability Engineering), dont le but est d’adapter l’effort de développement et de test à la « qualité perçue » et à l’usage opérationnel réel des cas d’utilisation, ces ratios d’usage réel étant construit d’après les étapes de UC effectivement parcourues, et d’après la nature des relations entre cas d’utilisation lorsqu’il y en a. Si l’usage opérationnel réel est utile, entre autre pour se fixer des objectifs de disponibilité opérationnel et de fiabilité, les méthodes de calcul liées à l’effort de test sont complexes et la pertinence de leur mise en œuvre limitée à certains types de projets.

La troisième partie est dédiée aux préconditions, postconditions et invariants. Elle emprunte beaucoup aux méthodes formelles, ce qui explique probablement un certain désintérêt de ma part. Hélas, l’exemple appuyant cette partie n’aide pas à rendre le propos plus clair.

La quatrième partie est dédiée à la gestion de la configuration, dont un chapitre est dédié au calcul du ROI, et un autre au « project portfolio management ». Si ce dernier chapitre ne m’a guère convaincu, par contre celui dédié au ROI est particulièrement concret et utilisable.

Cet ouvrage se démarque clairement des autres livres consacrés aux cas d’utilisation, car il est dédié à « ce que l’on peut faire avec les cas d’utilisation ». Bien que certaines parties s’appuient sur un formalisme très poussé, une grande partie est directement utilisable sur pratiquement beaucoup de type de projet.

succeeding-use-cases

Référence complète : Succeeding with Use Cases, Working smart to deliver quality – Richard Denney – Addison Wesley / O.T. series 2005 – ISBN: 0-321-31643-6

Succeeding with Use Cases: Working Smart to Deliver Quality


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

Note de lecture : Agile Product Management with Scrum, Creating products that customers love par Roman Pichler

Note : 3 ; Vraiment très léger, et pas si bien avisé que ça.

Plutôt qu’un livre, il s’agit d’un opuscule. D’abord par son nombre réduit de pages (118) et par son format à mi-chemin du livre de poche, ce qui est inhabituel. Tant mieux si le texte y gagne en pertinence et en efficacité. Hélas, ce n’est pas trop le cas, on frôle même parfois le hors sujet sans traiter en profondeur le sujet principal du livre ! Justement, effeuillons le texte. Celui-ci est découpé en 6 chapitres, donc avec une moyenne de 20 pages par chapitre.

Le premier chapitre rentre directement au cœur du sujet : qu’est-ce que le product owner ? On y énumère les qualités attendues de celui-ci et on évoque son rôle au sein de l’organisation, y compris celle d’un groupe de PO. Je dirais que globalement le propos est intéressant mais qu’on y apprends pas grand chose, le traitement me paraissant abstrait voir un peu théorique.

J’ai été intéressé de voir un chapitre consacré au développement de la vision, qui est l’un de mes thèmes favoris. Si on y reprends des bonnes idées largement connues par ailleurs (elevator statement, vision box ou modèle de Kano), je vois plutôt ce chapitre comme une introduction au sujet. Et je reste gentil.

Le troisième chapitre consacré au backlog est naturellement un des points majeurs du livre. Le principe de granularisation progressive des items de backlog est je pense un sujet connu d’un certain nombre de praticiens, il est bien de le voir évoqué là. Hélas une fois encore j’en trouve le traitement superficiel. Ce chapitre joue un double rôle en évoquant le volet recueil des besoins. Ce sujet aurait mérité son propre chapitre. Cet aspect est important et j’en trouve le traitement bien léger, voir bâclé. Un exemple du genre est l’évocation des exigences non fonctionnelles. La comparaison entre ce qui est dit ici et ce que l’on retrouve dans les meilleurs ouvrages traitant de l’ingénierie des exigences fait mal, très mal.

Les chapitres 4 et 5 sont consacrés au rôle du PO au sein des différentes pratiques de Scrum. Il s’agit à mon avis d’ajouts inutiles. Ces aspects sont déjà traités dans les ouvrages classiques traitant de Scrum. Et même si le propos est centré sur le product owner, je n’y trouve ni créativité ni apport de l’expérience de l’auteur.

Le sixième chapitre conclut sur les façons de monter en compétence sur le rôle de product owner. Dommage qu’il ne fasse que 7 pages, la prose y est forcément superficielle.

Clairement ce livre a été une grosse frustration pour moi. Il ne mérite pas la « signature series ». Peut-être mes attentes étaient-elles trop élevées, mais je pense qu’il y a plus et mieux à dire sur le rôle du product owner que ce qui est évoqué ici. Je n’estime pas la note trop sévère. Il reste que le texte satisfera peut-être de nouveaux venus à Scrum ?

agile-product-mgt-scrum

Référence complète : Agile Product Management with Scrum, Creating products that customers love – Roman Pichler – Addison Wesley / Signature series 2010 – ISBN : 978 0 321 60578 8

Agile Product Management with Scrum: Creating Products That Customers Love


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

Note de lecture : Managing Agile Projects, par Sanjiv Augustine

Note 6 ; Pour définir la « substance » de l’agile leadership…

Ecrire sur la gestion de projets agiles n’est pas chose facile, tant cette activité est difficile à définir en termes d’activités et de processus. Au lieu de cela, l’auteur a choisit d’évoquer le sujet sous l’angle des thèmes qui constituent le périmètre d’action de l’agile management.

Agile manager : Ce chapitre nous dévoile quelles sont les qualités que doit avoir l’agile manager, ainsi que les différences entre management et leadership.

Organic team : Deux chapitres traitent de la collaboration et de l’apprentissage (au sens de l’artisanat) eu sein des équipes agiles. On y évoque aussi l’émergence des communautés.

La Vision : L’un des rôles principaux du leader est de porter la vision du projet. Ce chapitre évoque la création et l’animation autour de cette Vision.

Les règles simples : Dans ce chapitre, on évoque les pratiques propres au management agile (backlog, release plan, etc.).

Information ouverte : L’une des valeurs essentielles de l’agilité est la communication. Ce chapitre traite des principes de communication applicables dans le cadre de l’agile management.

Touche légère : Le management agile passe par une ingérence la moins forte possible au sein des équipes, mais sans être totalement absent toutefois. Ce chapitre développe les actions possibles pour gérer une équipe en lui laissant l’initiative.

Le leadership adaptatif : Le feedback et l’adaptation sont un autre principe de l’agilité. Ce chapitre explique comment mettre en œuvre ces principes dans le management agile.

Effectuer la transition : Finalement, ce dernier chapitre traite du passage à l’agilité : quelles actions sont à mettre en œuvre, comment savoir si l’on est dans le bon chemin.

Au final, ce livre n’est pas grandiose, mais le sujet n’est pas facile. Je suis un peu resté sur ma faim, car le traitement du sujet manque de concret. La division en thèmes est une bonne idée, elle structure l’approche mieux que dans le livre de Jim Highsmith, et les liens vers d’autres références sont particulièrement pertinents. En bref, à l’époque le livre le plus utile sur le sujet. Aujourd’hui, je préfèrerais celui de Jurgen Appelo.

managing-agile-projects

Référence complète : Managing Agile Projects – Sanjiv Augustine – Prentice Hall 2005 – ISBN: 0-13-124071-4

Managing Agile Projects


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

Note de lecture : Release It ! Par Michael T. Nygard

Note : 9 ; Comprendre enfin les impératifs de production sur l’architecture. Book of the year 2007 !

Pour être tout à fait honnête, je dois avouer que j’ai d’abord acheté ce livre d’avantage par confiance envers l’éditeur (Pragmatic Programmers) que pour le titre, qui ne me disait pas grand-chose. Bien m’en a pris, le livre s’est avéré une mine de connaissances.

Ce livre traite de l’architecture des applications d’entreprise. Mais plutôt que de se focaliser sur les qualités classiquement attendues de telles applications, l’auteur s’intéresse aux comportements de applications d’entreprise en production. Et il connaît particulièrement bien son sujet, ayant participé aux mises en production de très gros sites de e-commerce. De fait, le texte regorge « d’histoires horrifiques » arrivés en production.

J’ai conscience que mon appréhension des besoins des équipes de productions par rapport aux systèmes que je développe est superficielle. Nous sommes dans deux mondes séparés. Cet ouvrage vient confirmer ce pressentiment. Jusqu’à présent, je pensais que la meilleure chose que j’avais à faire par rapport à la production était de produire un système solide et stable (de bonnes considérations), et que la seconde meilleure chose à faire était de produire un système très, très solide (ce qui commence à devenir stupide). L’auteur nous assène une vérité : tous les systèmes, d’une manière ou d’une autre peuvent et vont finir par faillir. Le design des applications doit êtres orientés par rapport à cette vérité, en termes de stabilité et en termes de capacité et surtout en terme de reprise sur crash !

Les 334 pages du livre sont découpées en 4 parties formant 18 chapitres. Il regorge littéralement de conseils d’architecture et de design formulés sous forme de patterns et d’antipatterns. Une vraie mine d’or !

Je recommande cet ouvrage sans aucune réserve. L’auteur prend des positions importantes et intéressantes, éclairées par une d’incontestables compétence et connaissances. Il nous fait découvrir un nouveau point de vue et de nouvelles idées à intégrer dans nos designs et nos architectures.

release-it-pragprog

Référence complète : Release It ! Design and deploy production-ready software – Michael T. Nygard – Pragmatic Bookshelf 2007 – ISBN : 0-9787392-1-3 ; EAN : 978 0 9787392 1 8

Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers)


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

Note de lecture : Management 3.0, Leading agile developers, developing agile leaders, par Jurgen Appelo

Note : 8 ; Du lourd, comme disent les jeunes…

Encore un livre sur le management ! OK, sur le management agile, mais quand même… Eh bien, celui-ci est différent ! Comme le signalait Robert Martin dans son avant-propos, celui-ci contient le mot « eucaryote ». Plus sérieusement, il s’agit d’un aspect important et remarquable du livre : la façon dont il s’appuie sur un très important corpus de connaissances scientifiques. Je serais bien en peine de nommer ici très nombreuses théories auxquelles l’auteur se réfère, il y en a une bonne demi-douzaine à chaque chapitre. Je vais par contre essayer d’en donner un éclairage synthétique.

L’axe majeur du livre de Jurgen Appelo est que la gestion d’une communauté de personnes est un système complexe et qu’il doit être appréhendé en tant que tel, contrairement à beaucoup d’approches de management qui ont une vision réductionniste. L’auteur s’appuie donc sur les théories ayant trait à la gestion des systèmes complexes : théorie des jeux, théorie des systèmes dynamiques, émergence, etc… Il articule aussi sont propos sur 6 vues, ou 6 tentacules devrais-je dire, car Jurgen représente son approche du management à l’aide d’une sorte de pieuvre munie de 6 tentacules au bout desquelles se trouve un œil. La bestiole se prénomme « Martie » ! Nous avons donc :

  • Energize people
  • Empower teams
  • Align constraints
  • Develop compétences
  • Grow structure
  • Improve everything

Je ne vais pas développer ces différents thèmes. Si vous êtes curieux, vous lirez le livre. Chaque thème fait l’objet de 2 chapitres, l’un théorique, l’autre pratique. La différence entre les deux ne m’est pas toujours apparu évidente. Le point commun est que chaque chapitre est vraiment lourd, fort d’une quantité impressionnante d’information. Souvent trop. Bref, ce n’est pas un livre que l’on lit en dilettante. Heureusement, l’auteur fait preuve d’un grand sens de l’humour, ce qui associé à une réelle qualité d’écriture fait de ce texte un réel plaisir !

L’ouvrage est dense, je l’ai déjà dit. Il est émaillé d’illustrations, de dessins en fait, réalisés par l’auteur lui-même. Ils accentuent la touche d’humour. Je ne suis pas convaincu que l’on puisse tout retenir. Il s’agit de ces livres sur lesquels il faut revenir lorsque l’on souhaite trouver le moyen d’améliorer un point particulier. Le modèle à 6 points de vues est lui facile à mémoriser et peut servir d’axe directeur.

J’ai mis du temps à sortir ce livre de son étagère. A tord. Il est réellement étonnant. Il faut une dose de courage pour se plonger dedans, mais ça vaut le coup !

management-30-Appello

Référence complète : Management 3.0, Leading agile developers, developing  agile leaders – Jurgen Appelo – Addison Wesley / Signature series 2010 – ISBN : 978-0-321-71247-9

Management 3.0: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn))

http://www.goodreads.com/book/add_to_books_widget_frame/0321712471?atmb_widget%5Bbutton%5D=atmb_widget_1.png