Étiquette : bookReview

Note de lecture : Debug it ! Find, Repair & Prevent Bugs in Your Code, par Paul Butcher

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Note de lecture : Project Retrospectives, a handbook for team reviews, par Norman Kerth

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; De l’or en pages ! Book of the Year 2006 !

La plupart du temps, quand un auteur traite un sujet, et plus encore lorsqu’il s’agit d’un sujet touchant au consulting, si cet auteur nous livre son savoir, il garde souvent pour lui son savoir-faire. Rien de tel ici, Norman Kerth nous lâche tout : ses trucs, sa façon de vendre les rétrospectives, l’attitude qu’il adopte dans certaines situations, absolument tout !

La rétrospective est une étape méconnue (et souvent méprisée) de la vie du projet : elle permet de tirer les enseignements positifs comme négatifs, du déroulement de celui-ci. C’est grâce aux rétrospectives qu’une organisation peut réaliser une démarche d’amélioration de ses processus. Après un rapide chapitre introductif traitant du besoin de rétrospectives, le livre débute réellement par un chapitre consacré à une présentation générale des rétrospectives, à l’aide d’une étude de cas fictive. Celle-ci campe très bien le contexte et permet de comprendre la progression d’une rétrospective. Les trois chapitres suivants sont consacrés aux étapes préalables : la vente, les choix et la préparation de la rétrospective.

Le chapitre 6 est de loin le plus long de ce livre, avec ses 70 pages. Il présente des exercices (il y en a 12) sous forme de patterns. Ce sont ces exercices qui forment la substance des rétrospectives. Ceux-ci sont largement expliqués, en termes de but, de contexte et de déroulement. Ils sont généralement illustrés par une expérience vécue qui ajoute encore à l’intérêt de l’exercice.

Les chapitres 7 et 8 sont consacrés aux postmortems: la rétrospective des projets ayant échoué et arrêtés avant leur terme. Les conditions psychologiques de tels projets ont amené Norman Kerth à adapter sa démarche et ses exercices à ces conditions particulières. On ne saurait conclure un tel ouvrage sans aborder les aspects de compétence du facilitateur : quelles qualités, quelle formation doit-il avoir, quelles compétences doit-il développer. Enfin, l’ouvrage se conclut sur les rétrospectives de rétrospectives et la manière de collecter ces expériences dans une organisation.

Vous l’aurez compris : cet ouvrage est non seulement complet sur le sujet, mais d’une substance hors norme, il s’agit pour moi d’un livre incontournable sur le sujet, qui doit absolument être lu par quiconque souhaite devenir facilitateur de rétrospectives.

project-retrospectives-dorsethouse

Référence complète : Project Retrospectives, a handbook for team reviews – Norman L. Kerth – Dorset House 2001 – ISBN: 0-932633-44-7

Project Retrospectives


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

Note de lecture : How to Become an Exceptional DBA, 2nd edition, par Brad M. McGehee

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Toutes les facettes du DBA idéal !

Brad McGehee serait-il aux DBA ce que Chad Fowler est au développement logiciel? La lecture de cet ouvrage le laisse penser. En tout cas l’objectif de ce livre recoupe celui du « passionate programmer » : exceller dans son métier.

12 chapitres et 170 permettent et suffisent à l’auteur pour prendre la mesure de ce que devrait être le code de conduite du DBA exceptionnel. Et il est vrai (surtout pour moi qui en cherche un) que cela fait rêver. Le chapitre 2 est d’ailleurs consacré à l’énumération et à l’explication des trait important attendus de ce DBA.

Le chapitre 3 invite le lecteur à choisir sa voie, car on ne peut tout savoir. Et pour compléter cela, le chapitre 4 donne des pistes pour améliorer et entretenir son savoir. Savoir qu’il faudra peut-être valoriser ensuite : le chapitre 5 évoque les certifications, celles qui existent qu’elles soient utiles ou inutiles. L’auteur finalement évalue l’importance de ces certifications.

Les 4 chapitres suivants évoquent la valorisation du DBA exceptionnel : participation aux communautés (chapitre 6), gestion de carrières (chapitre 7), gestion et valorisation de l’image (chapitre 8 et 9) et finalement recherche d’un nouvel emploi (chapitre 10).

Les derniers chapitres reviennent sur les points évoqués tout au long du livre, en les synthétisant sous forme d’un code de conduite (chapitre 11) et d’un résumé des « best practices » du DBA exceptionnel.

Je dois dire que j’ai pas mal apprécié cet eBook, outre que je converge pleinement sur l’éthique développée, il m’a aidé à comprendre ce qu’est un DBA. Cela dit, et quoi qu’ait voulu exprimer l’auteur, il est essentiellement centré autour du « DBA production ».

exceptional-dba-2edt

Référence complète : How to Become an Exceptional DBA, 2nd edition – Brad M. McGehee – Simple Talk publishing 2009 – EAN: 978 1 9064 22 9

Note de lecture : Le management pour les nuls, par Bob Nelson & Peter Economy

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Non, en fait il n’est pas nul du tout !

Une véritable surprise, ce livre. Si un ancien collègue ne me l’avait conseillé, je ne me serai jamais arrêté dessus. Les auteurs sont très aguerris sur le management, et le texte s’attache à ce qui est important, la gestion des hommes, leur motivation, la délégation de travail, le leadership, etc.. Les techniques de suivi en tout genre qui font les choux gras de bien d’autres ouvrages de moindre qualité n’ont pas leur place ici. Outre la remarquable pertinence du propos, le livre recèle deux qualités importantes : le texte est bien écrit, facile à lire, passionnant même. La seconde qualité du livre est de couvrir de façon volontariste les différentes facettes du management, dont le licenciement, les aspects politiques et la budgétisation, entre autre exemple.

Il y a peu de méchantes choses à dire sur cet excellent ouvrage qui permet, outre sa lecture linéaire, une utilisation en ouvrage de référence, eut égard au découpage en nombreux chapitres (23 en tout) et aux nombreuses « check-lists » et autres encadrés. Ah, si ! Une chose tout de même : le texte aurait pu être mieux adapté au contexte français sur certains points ; le chapitre sur le licenciement aurait pu (entre autre) être mieux adapté au contexte français.

Le Management pour les nuls

Référence complète : Le management pour les nuls – Bob Nelson & Peter Economy – First Editions 2004 (V.O. : Management for dummies – Wiley Publishing 2001) – ISBN : 2-87691-952-4

Le Management pour les Nuls


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