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

Publicité

Note de lecture : Adopting the rational Unified Process, par Stephan Bergström & Lotta Raberg

Note : 4 ; Une demarche qui a le mérite d’exister … mais la faiblesse de ne fonctionner que dans un environnement idéal !

Cet ouvrage complète la vision du RUP, non pas en abordant son utilisation, mais son déploiement au sein d’entreprises. A cette fin, les auteurs ont développé un processus d’adoption, dont les étapes servent de fil rouge à la structure de l’ouvrage. Si cette démarche est bien aboutie et forme un ensemble logique, il n’en reste pas moins que sa mise en œuvre semble se confiner aux grands groupes dont les moyens sont conséquents, capable de dédier un projet juste-comme-il-faut en tant que poisson pilote de l’organisation, et tout et tout…

Bref, il y a du bien et du moins bien dans ce livre, mais il est improbable que l’on ait souvent l’occasion de dérouler le processus tel qu’il est décrit. Il est plus probable que l’on ait la possibilité d’en exploiter des morceaux. Un autre point faible (et gênant) de l’ouvrage est qu’il est très abstrait quand au RUP lui-même ! J’aimerais d’avantage d’exemple plus concrets que des phrases telles que « sous ensemble de la discipline de tests ». En fait d’exemple, d’ailleurs, le style de l’ouvrage aurait été plus vivant si il avait été illustré tout au long par un exemple d’organisation fictive au sein de laquelle RUP doit être déployé.. Et ce, même si 2 références de déploiement sont décrites en annexes.

adopting-RUP

Référence complète : Adopting the rational Unified Process: Success with RUP – Stephan Bergström & Lotta Raberg – Addison Wesley / O.T. series 2004 – ISBN: 0-321-20294-5

Adopting the Rational Unified Process: Success with the Rup


http://www.goodreads.com/book/add_to_books_widget_frame/0321202945?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 : Debug it ! Find, Repair & Prevent Bugs in Your Code, par Paul Butcher

Note : 3 ; Dommage qu’on y parle si peu de debug …

S’il est une facette du développement considérée comme peu noble, c’est bien le debug ! L’évolution des pratiques de développement tendent à réduire considérablement la part de debug nécessaire (entre autre via les tests unitaires) et c’est une bonne chose ! Toutefois la maîtrise de cet art reste une compétence nécessaire (où je n’ai pas la sensation d’exceller), c’est donc avec bonheur que j’ai accueilli ce nouvel ouvrage, cautionné par le sérieux des « pragmatic programmers » !

Je vais immédiatement casser le suspens en avouant de but en blanc que j’ai été fortement déçu.

La première partie est dédiée à la décomposition du processus de correction, avec un chapitre consacré à chaque phase du processus, soit 4 chapitre plus un chapitre de présentation, pour un total de 85 pages (sur 200). Le processus est simple et bien connu : reproduire, diagnostiquer, corriger, réfléchir (ou s’interroger plus exactement). Je ne suis pas un expert en correction de problèmes pourtant je connais (et pratique) cela depuis fort longtemps, aussi je pense que cette partie s’adresse au débutant. Too bad !

La seconde partie « biger picture », est longue de 25 pages découpée en 2 chapitres. Elle replace la correction de bugs dans un contexte plus large : les interactions avec les utilisateurs une équipe support, la remontée aux sources du mal (pourquoi avons-nous des bugs).

La troisième partie « debug fu » est la plus proche de ce que je considère comme le sujet du livre. Elle couvre 4 chapitres sur 85 pages. Les 20 pages du chapitre 8 « spécial cases » sont même au cœur du sujet. J’aurais espéré voir ce thème développé plus longuement, alors que le chapitre 9 consacré au « debuging environnement » parle de tout sauf d’environnement de debugging !

Au final, ce livre s’est fixé un but : décrire comment travailler (et avec quoi travailler) pour ne plus avoir besoin de debugger. En fait, je suis d’accord avec cet objectif. Mais je pense que les sujets attenants sont déjà traités par ailleurs et dans plus d’un livre ! Et mieux ! Et il arrive un moment où il faut bien sortir de sa boite à outil un savoir faire de debugage, car c’est ce dont on a un besoin. Et là ce livre ne réponds pas présent, alors que c’est là où je l’attendais, sur un domaine abandonné par tous les auteurs.

Mon conseil, et il est exceptionnel eut égard à la qualité du « pragmatic Bookshelf » : évitez ce livre !

debug-it-pragprog

Référence complète : Debug it ! Find, Repair & Prevent Bugs in Your Code – Paul Butcher – Pragmatic Bookshelf 2009 – ISBN : 978 1 93435 628 9

Debug It!: Find, Repair, and Prevent Bugs in Your Code

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

Note de lecture : Behind Closed Doors, secrets of great management, par Johanna Rothman & Esther Derby

Note : 6 ; Fortement concret, mais néanmoins décevant…

Evidemment, avec un titre, les attentes sont fortes ! Trop fortes, peut-être, car je dois m’avouer un peu déçu à la fin. Mais revenons au commencement : Behind closed doors est construit comme un recit, le recit d’un manager nommé Sam, arrivant dans une entreprise où il doit prendre en main une équipe formée d’une demi-douzaine de chefs de projets. Le corps du texte est formé de 7 chapitres, chacun représentant une semaine. Chaque semaine représente une étape majeure dans l’accomplissement de l’équipe et de Sam : apprendre à connaitre l’équipe, faire émerger l’ordre du chaos, construire l’équipe, gérer au jour le jour, découvrir les problèmes larvés, solidifier les capacités et s’arranger avec les réalités de la compagnie.

Finalement, les secrets dont il est question gravitent tous autour de la gestion des personnes. Il rapellent en cela l’ouvrage de Stephen Covey ou les outils promus lors des formations Krauthammer. Certes, ils ont de la valeur, mais de là à appeler cela des secrets…

La dernière partie (35 pages) est constituée de fiches pratiques autour des éléments mis en avant lors des 7 chapitres précédents. Il s’agit là d’une référence fort pratique, un véritable condensé d’expertise.

behind-closed-doors

Référence complète : Behind Closed Doors, secrets of great management – Johanna Rothman & Esther Derby – The Pragmatic Bookshelf 2005 – ISBN: 0-9766940-2-6

Behind Closed Doors: Secrets of Great Management


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

Note de lecture : Aspect-Oriented Software Development with Use Cases, par Ivar Jacobson & Pan-Wei Ng

Note : 3 ; Ou comment aller trop loin avec les cas d’utilisation.

Jacobson a décidé de surfer sur la vague des aspects, et d’offrir une nouvelle tenue « coloriée aspects » à ses cas d’utilisation à cette occasion. Pour cela, il s’est adjoint les services de Pan-ei Ng, qui a d’ailleurs en fait écrit la très grande partie du texte. Cela n’est pas un problème, car ce dernier tient fort bien la plume.

Le point de départ de ce livre est un article d’Ivar Jacobson écrit en 1986 sur une idée proche des « crosscutting concerns ». Ayant exhumé cet article et développant à partir de celui-ci, les auteurs ont fait évoluer l’approche des cas d’utilisation dans deux directions :

  • Structuration intensive des cas d’utilisation, utilisant intensivement la relation « extend » qui est la pierre angulaire du rapprochement avec l‘AOD. Cette structuration intensive s’accompagne de l’émergence de cas d’utilisation d’infrastructure. Bref, à mon avis cette approche s’éloigne d’un média de communication avec les utilisateurs car elle complexifie à outrance les cas d’utilisation. A cet égard, cette direction se rapproche des « use case patterns » de Gunnar Övergaard. Les spécifications de l’extension sont aussi beaucoup plus développé afin de ressembler aux « join points », le reste est à l’avenant : intéressant pour l’informaticien, moins pour celui qui ne l’est pas.
  • Les « use case slices » et « use case modules » : sont la structuration objet d’analyse. Plutôt que développer une architecture orthogonale au modèle des besoins, les auteurs soutiennent une bijection entre les cas d’utilisation et la structuration en « use case slices ». On aboutit ainsi à un système architecturé par les cas d’utilisation (même si les auteurs ne dénient pas la factorisation), ce qui me plonge dans un abîme de perplexité.

C’est vrai, il y a une corrélation forte entre les points de jonction de l’AOD et la relation « extend », et si le sujet mérite certains développements, je n’adhère pas franchement aux extrémités des auteurs qui nous éloignent par trop de la simplicité et des qualités de communication inhérente des cas d’utilisation. D’ailleurs l’ouvrage lui-même devient parfois un peu obscur. Limiter volontairement son volume à moins de 250page aurait certainement pu le rendre plus limpide.

Bref, une lecture tout ce qu’il y a de plus facultative.

aspect-or-soft-dev-use-cases

Référence complète : Aspect-Oriented Software Development with Use Cases – Ivar Jacobson & Pan-Wei Ng – Addison wesley / O.T. series 2005 – ISBN : 0-321-26888-1

Aspect-Oriented Software Development with Use Cases


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

Note de lecture : Clean Code, par Robert C. Martin

Note : 6 ; Du (très) bon, mais hélas aussi du moins bon

Comme l’indique son nom, ce livre concerne l’écriture de beau code. Il rejoint en cela « implementation patterns » de Kent Beck ou « Refactoring » de Martin Fowler.

J’ai beaucoup apprécié les 10 premiers chapitres. L’auteur (ou les auteurs, devrais-je dire) y évoque en détail différents aspects d’écriture et de présentation du code.

Au chapitre 1 qui évoque le « pourquoi » de l’ouvrage, le chapitre 2 traites du nommage, ou comment le rendre pertinent et distinguable. Des aspects que l’on a trop souvent tendance à oublier.

Le chapitre 3 traite des fonctions, sujet important s’il en est. Bien sûr on y parle de la taille des fonctions et de leur lisibilité, mais aussi de la nécessité de concevoir les fonctions selon un seul niveau d’abstraction. Par contre l’idée de séparer l’interception d’exception ne tient tout simplement pas la route. Désolé.

Au chapitre 4 on aborde les commentaires. La règle est simple, le code doit principalement être lui-même le commentaire et ceux-ci doivent donc être réduits à la portion congrue. Le chapitre 5 concernant le formatage est plus surprenant, pourtant les conseils y sont bons, par exemple concernant l’espacement vertical.

On monte en niveau d’abstraction avec le chapitre 6 traitant des structures de données et le chapitre 7 évoquant les exceptions. Rappeler d’anciens principes tels que la loi de Déméter me semble aujourd’hui plus nécessaire encore qu’hier !

Les chapitres 8 et 10 traitent d’avantage de considérations de design. Si le contenu reste valable, le traitement du « 3rd party code » est quand même un peu simpliste. On ne saurait couvrir ce genre de problématiques en 15 pages et 2 conseils donnés à l’emporte-pièce. Les directives données sur la conception des classes rappellent celles issues du précédant livre de l’auteur : « agile software development ». Donc rien de nouveau.

Rien de nouveau non plus sur les tests unitaires évoqués au chapitre 9, bien que la lecture en soit plaisante.

En montant en niveau d’abstraction, les chapitres 11 à 13 qui traitent plutôt de problématiques d’architecture, voient un peu gros pour un traitement qui se révèle un peu court. Le chapitre 11 aborde l’intérêt de l’AOP par rapport à la conception de systèmes, mais il s’agit à peine d’une introduction même si l’on tente d’évoquer les mérites comparés d’Aspect J et de Spring AOP. Je n’ose même pas retenir le chapitre 12 traitant de l’émergence en 5 pages ou du chapitre 13 sur la concurrence qui ne saurait soutenir la comparaison avec l’ouvrage de Doug Lea. Même avec son chapitre complémentaire en annexe.

Les chapitres 14 à 16 sont des tutoriaux guidés de refactoring. Hélas, le format livre se prête mal à cet exercice qui se révèle rapidement rébarbatif. Un support interactif online serait bien mieux adapté.

Bref, j’ai bien apprécié 150 des 400 pages de ce livre. C’est insuffisant pour classer celui-ci dans les bons ouvrages, mais il vaut quand même un petit détour.

clean-code

Référence complète : Clean Code, a handbook of agile software craftsmanship – Robert C. Martin – Prentice hall / Robert C. martin series 2008 – ISBN: 0-13-235088-2 ; EAN: 978 0 13 235088 4

Clean Code: A Handbook of Agile Software Craftsmanship

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

Note de lecture : JUnit recipes, par J.B. Rainsberger & Scott Stirling

Note : 7 ; Un peu de déchets, mais beaucoup de matière, souvent aussi utile qu’originale.

Ce livre est pratiquement un livre de patterns d’utilisation de JUnit, donc à rapprocher de l’ouvrage de Mezzaros. L’ouvrage est imposant avec ses presque 700 pages. Heureusement, il n’est pas nécessaire de les lire linéairement.

Les deux premiers chapitres sont consacrés aux classiques B.A. BA de JUnit, on en est débarrassé en 70. Vient ensuite la vraie substance.

Les deux chapitres suivants (les 3 et 4, donc) ont un focus plus original, car ils traitent de l’organisation des tests, en terme de package ou de projet (avec ou hors du code de production), puis de l’organisation des suites de tests. Ce sont, pour la plupart, des questions réccurentes auxquelles il est rarement répondu. Le chapitre 5 suit logiquement en évoquant l’exécution des tests pilotée par les données. Bien évidemment, DbUnit est évoqué, mais aussi Ant avec ses tâches SQL. On a donc droit à un propos assez large.

Les chapitres 6 et 7 ont d’avantage trait à l’execution et au reporting des tests. Bien entendu, cela couvre l’extension du framework JUnit pour le reporting. La première partie se conclut par un chapitre dédié aux problèmes fréquemment rencontrés, je ne suis hélas pas en mesure de jauger sa pertinence.

La seconde partie est consacrée aux tests J2EE. Si on couvre quelque peu le XML et les pages HTML, les tests sur JDBC se taillent la part du lion. A l’heure de JPA, d’Hibernate ou JDO, je me pose quand même des questions, pour ne pas parler du chapitre consacré aux EJBs ! De la même façon, si le chapitre sur les tests des composants Web paraît utile, on n’évoque guère que JSP et Servlets, quid des JSF et autres Struts. D’ailleurs un chapitre est consacré aux tests de navigation où aucuns de ces frameworks (Struts, WebWorks, etc..) n’est évoqué ! Quand à parler de Spring… Bref, je suis déçu par le contenu de cette partie, même si il reste affuté techniquement.

La troisième partie porte sur des sujets complémentaires, où l’on traite des cas de figures non classiques : listeners, singletons, etc… Très utile, autant qu’original.

Bref, un livre de ressources utiles que l’on fera bien d’avoir sous le coude pour performer sur les tests unitaire : Il y a clairement beaucoup de matière ici.

junit-recipes

Référence complète : JUnit recipes, practical methods for programmer testing – J.B. Rainsberger & Scott Stirling – Manning 2005 – ISBN : 1-932394-23-0 ; EAN : 9 781932 394238

JUnit Recipes: Practical Methods for Programmer Testing

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

Note de lecture : Manage it ! Your guide to modern, pragmatic project management, par Johanna Rothman

Note : 9 ; Une impressionnante somme d’expérience de gestion de projet

Johanna Rothman n’est pas seulement un chef de projet avec une longue expérience du métier, c’est également une experte qui s’est élevée fort haut en compétence dans ce métier. Ce livre reflète parfaitement toute la valeur et le savoir-faire de l’auteur et le fruit est tout bonnement impressionnant. Si « JR » comme elle-même se surnomme elle-même a produit un texte indépendant du type de processus emprunté, elle tend toutefois, et cela est explicite dans le texte, vers des processus de type agile. N’espérez pas avaler ce volume en un week-end, car au-delà de ses 340 pages, le texte est dense et ne se laisse pas avaler facilement !

Le plan est découpé en 16 chapitres. Je ne les énumérerais pas tous, mais ils couvrent l’ensemble des activités et des contextes auxquels peut être confronté le chef de projet : lancement de projet, planification, suivi, spécifications et tests, animation d’équipes et de réunions, gestion d’un sous-traitant, d’équipe off-shore ou simplement reparties sur plusieurs sites, etc… Sur chaque sujet, l’auteur pointe ce qui est important et ce qui ne l’est pas, elle indique la voie à suivre, ou du moins ce qui est sa voie et n’hésite pas à nous fournir des guides, des exemples, etc.. Souvent JR évoque sa propre expérience pour étayer son propos, mais elle nous gratifie aussi de nombreux témoignages de tiers.

La gestion de projet est un sujet difficile à traiter et souvent mal traité. Ce volume représente ce que j’ai vu de mieux sur le sujet, sans contestation possibles. Il devrait rester sur le dessus de votre bureau et en tout cas restera à souvent à ma portée. Il n’en reste pas moins que le livre s’adresse davantage au chef de projet déjà en place, qui trouvera naturellement ses repères par rapport au texte, qu’au chef de projet en devenir pour lequel le propos sera difficile à raccrocher à la réalité.

Un livre à ne manquer sous aucun prétexte.

manage-it-pragprog

Référence complète : Manage it ! Your guide to modern, pragmatic project management – Johanna Rothman – The pragmatic Bookshelf 2007 – ISBN : 0-9787392-4-8 ; EAN : 978 0 9787392 4 9

Manage It!: Your Guide to Modern, Pragmatic Project Management


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

Note de lecture : Agile Retrospectives, Making good teams great, par Esther Derby & Diana Larsen

Note : 7 ; Des patterns pour les rétrospective

Le « project retrospectives » est incontestablement l’ouvrage phare sur les rétrospectives de projets. Hélas, cette approche en grand était fort peu adaptée aux simples rétrospectives d’itération, destinées à être menées en une heure ou deux. Ce titre couvre cet aspect, entre autres choses. Certaines des pratiques évoquées sont également adaptées aux rétrospectives de release, mais sans un focus particulier sur ce dernier point. Tout comme le livre de Norman Kerth, celui-ci est construit en une suite d’activités que l’on peut sélectionner judicieusement. En fait, ces activités sont même présentés sous forme de patterns regroupés en 5 rubriques (les chapitres 4 à 9) qui sont autant de phases de la rétrospective :

Activities to set the stage : 4 activités sont proposées afin de démarrer la rétrospective et accueillir les participants.

Activities to gather data : Cette phase permet de collecter des données chiffrées ou qualitatives sur l’itération passée. Ce ne sont pas moins de 8 activités différentes (et interchangeables) qui sont offertes pour aboutir à cette fin.

Activities to generate insights : 9 activités sont proposées ici afin d’élaborer causes et conséquences du déroulement de l’itération.

Activities to decide what to do : Une rétrospective qui n’aboutit pas à un plan d’action n’a que peu de valeur. Ce sont 4 activités qui sont proposées ici pour aboutir à cette fin.

Activities to close the retrospective : Les 5 activités proposées ici permettent de conclure la rétrospective.

Au-delà de ces phases, cet opuscule de 160 pages complète le paysage par quelques mots sur les rétrospectives de release et de projet, et un panorama de l’environnement nécessaire à la menée des rétrospectives.

Cet ouvrage propose incontestablement des outils pour les rétrospectives, hélas l’exposé de ceux-ci est parfois bien léger. Quelques pages (de 2 à 4) sont consacrés à la description, avec un format invariant : But, durée nécessaire, description, étapes, matériel et préparation et exemples. Justement, la partie « exemples » pourrait être plus développée afin de décrire l’activité de façon moins abstraite. De même, toutes les activités ne se combinent pas entre elles, et lister les activités en entrée possible aurait bien aidé !

L’utilité de ce livre est incontestable, il est hélas plus léger que ce que les auteurs auraient été capables de produire. Je suggère de toute façon de commencer par lire le livre de Norman Kerth, il permet de bien comprendre la notion de rétrospective. Ce livre est certes différent car s’adressant à un type de rétrospectives différent, mais il est plus pertinent en complément du premier.

agile-retrospectives-pragprog

Référence complète : Agile Retrospectives, Making good teams great – Esther Derby & Diana Larsen – Pragmatic Bookshelf 2006 – ISBN : 0-9776166-4-9

Agile Retrospectives: Making Good Teams Great


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