Étiquette : Livres

Top 5 – Lectures 2012

J’ai fait plusieurs lectures en 2012 et sur des sujets diverses. Je vous propose ici une compilation Top 5 des meilleurs ouvrages liés au domaine de l’informatique que j’ai lu dans le courant de l’année 2012:

1. Software Architecture for Developers par Simon Brown

Excellent résumé de ce que fait (et devrait faire) un architecte logiciel et comment partager sa structure et sa vision à l’équipe. L’auteur, Simon Brown, nous montre son côté pragmatique dans cette vue d’ensemble. J’ai apprécié particulièrement les parties sur le rôle d’architecte et la façon de concevoir et de communiquer le logiciel.

On y parle aussi de l’agilité et de son impact sur l’architecture ainsi que la notion qu’un diagramme UML n’est pas toujours nécessaire. Noter que ce livre est publié de manière indépendante sur « Leanpub » et est toujours en évolution. Un « Must » à lire pour tout développeur ou un architecte logiciel!

Lien du livre sur LeanPub

 

2. Specification By Example par Gojko Adzic

Gojko Adzic nous a écrit un 2e livre sur les spécifications.  Son premier, Bridging the communication gap, était surtout de nature théorique. Cette fois-ci, on nous présente les expériences de personnes et organismes différents avec l’utilisation de la spécification par l’exemple. En plus de cela, nous voyons comment Gojko a fait évoluer sa pensée sur la spécification et après quelques chapitres, nous allons au-delà des notions de base.

Soit dit en passant, ce livre ne parle pas de code ou d’outils. Seulement des principes et des pratiques utilisées pour communiquer les spécifications dès le début d’un projet logiciel jusqu’à sa fin.
Un des beaux résultats de cette approche est que tout le monde dans une équipe de développement logiciel travaille à avoir une « Documentation vivante » au lieu d’un tas de papiers classés quelque part dans un classeur.

Je recommande cette lecture à toute personne impliquée dans la création de logiciels. En particulier si utilisez les approches suivantes:  Behaviour Drive Development (BDD), Acceptance Test-Driven Development (ATDD), Test-Driven Development (TDD) et le Domain Driven Design (DDD).

Liens commandités du livre sur Amazon : France | Canada | USA

 

3. Techical Blogging par Antonio Cangiano

Si vous êtes sérieux à propos des blogues, ce livre est pour vous. L’auteur, Antonio Cangiano, couvre de nombreux aspects liés à l’écriture de blogue tels que la planification, la création de contenu, la promotion, le référencement, les avantages et les médias sociaux. Certains aspects sont directement liés à l’outil de blogage WordPress, mais la plus grande partie du contenu de ce livre peut être appliqué à n’importe quel type de blogue.

Liens commandités du livre sur Amazon : France | Canada | USA

 

4. Steal like an Artist par Austin Kleon

L’auteur, Austin Kleon, nous donne 10 règles pour développer notre créativité. Ces règles peuvent être utiles à toute personne, artiste ou non. En fait, pourquoi voler comme un artiste ? Parce que rien n’est original finalement… Le livre est aussi magnifiquement illustré et le papier utilisé pour imprimer le livre est de grande qualité. Le résultat: un excellent livre sur la créativité et la productivité qui se lit très bien. Inspirant !

Liens commandités du livre sur Amazon : France | Canada | USA

 

5. Impact Mapping par Gojko Adzic

Un 2e livre de Gojko Adzic dans mon Top 5 (eh oui !). Celui-ci est un peu différent toutefois. En fait, il s’agit plutôt d’un guide qu’un d’un livre en soit. L’auteur nous présente une technique pour mieux comprendre, mesurer et aligner les objectifs de l’entreprise avec la planification de la livraison d’un produit logiciel. Voici le « Impact Mapping » qui est une sorte de schéma heuristique (ou « Mind Map ») pour représenter les aspects suivants: But (pourquoi), Acteur (qui), Impacts (comment) et  le Livrable (quoi). Aussi, le livre est magnifiquement illustré. Je recommande vivement d’obtenir la version papier.

Liens commandités du livre sur Amazon : France | Canada | USA

Publicité

Routine de lecture

J’aime beaucoup les livres et peut-être même un peu trop. Je ne sais pas trop si vous être comme moi, mais je suis du genre à lire plusieurs choses en même temps.

Je commence des lectures au gré de mes besoins de connaissances à approfondir pour le travail, envies ou feeling du moment. Aussi, tout dépendant à quel moment de la journée je m’installe pour lire, le type de lecture peut varier. Exemple le soir, je préfère lire de la fiction ou quelque chose de léger. Une lecture théorique me fera la plupart du temps simplement m’endormir . Pour ce qui est de la fiction, un général je me limite à un livre de ce genre en même temps.

Par contre, je viens de me rendre compte que j’ai plus de huit livres en cours de lectures ! D’ailleurs, on le voit bien sur mon profil du site "GoodReads":

Ouin, je ne sais pas trop si c’est une bonne chose, mais bon, je suis comme cela. Afin de m’améliorer, je crois que je devrais limiter mes lectures simultanées afin d’en finir plus rapidement.

Et vous est-ce que vous avez des routines manières particulières de lecture ? Un seul livre à la fois ou plusieurs ?

Côté objectif, j’essaye de lire entre 15 et 20 livres par années. C’est certain qu’ils ne sont pas tous de la même longueur, mais cela me donne un ordre de grandeur.

Avez-vous des façons de vous fixer des objectifs de lectures ?

 

N’hésitez pas à commenter ce billet !

 

Référence:

Lectures à la plage

Lectures2011

J’aime bien me faire une nouvelle sélection de livre à lire pour l’été. Et ce, même si je mets de côté certains déjà entamés…

Et oui, c’est les vacances pour les lectures en cours aussi !

Donc, je vous présente ma sélection de lectures pour l’été:

Rework par Jason Fried et David Heinemeier Hanson: Livre des deux fondateurs de la compagnie 37signals. On y parle de comment ils ont bâtit leur compagnie en ne respectant pas les manières standards de faire. Très pragmatique et Lean dans leur approche, l’ouvrage semble intéressant à lire. C’est d’ailleurs David Heinemeier Hanson qui est derrière le framework web Ruby On Rails (RoR) qui a été utilisé pour bâtir un de leurs premiers produits: Basecamp. Ils ont fait par la suite de RoR un framework Open source.

Enchantment par Guy Kawasaki: J’aime bien cet ancien d’Apple et sa manière de présenter les choses. Quoi de mieux que de lire son dernier livre pour en apprendre davantage sur lui. On y parle ici de comment « charmer » les gens, de manière positive bien sûr, pour changer les choses, offrir ses services, vendre un produit, etc.

The Well Grounded Rubyist par David A. Black : Ayant récemment terminé un tutorial sur Ruby On Rails, je voulais poursuivre en apprenant davantage la base du langage Ruby. Ce livre semble bien fait pour cela. Par contre, je ne pense pas lire les quelques 500 pages pendant l’été. Passer à travers quelques chapitres serait déjà un bon pas d’effectué.

Et d’autres moins sérieuses pour se divertir, car c’est important aussi pendant les vacances. Étant un bon amateur de bandes dessinées ou Comics Books, voici ma sélection:

Dark Tower – The Gunslinger Born : J’ai toujours voulu lire la série « Dark Tower » de Stephen King. En voici l’occasion avec le premier volume de cette adaptation en bande dessinée qui me semble très bien réussi.

Justice League International: J’aime bien cette série des années 90 où l’humour est omniprésent chez un groupe international de super-héros. Hilarant.

Et vous, est-ce que vous avez des lectures particulières pour cet été ?

En passant, n’hésitez-pas à consulter mon profil et me suivre sur Goodreads:
http://www.goodreads.com/profile/karlmet

Critique du livre Linchpin

linchpinJ’ai vraiment hésité avant de lire ce livre. À chaque fois que je passais à la librairie pas loin de mon travail, je prenais le livre et je le feuilletais. Je regardais un peu les sections, le sujet de livre et j’hésitais. Un puis un jour, je me suis lancé et je l’ai acheté histoire afin d’en avoir le coeur net.

Je connaissais que vaguement l’auteur, Seth Godin, ayant lu auparavant quelques-uns de ces articles. Mais j’ai découvert en lisant ce livre un auteur passionnant et divertissant.

Bon, revenons au livre. Ce dernier parle de comment devenir un Linchpin. Un Linchpin ressemble à cela:

Mais on ne se sert que de l’analogie ici. C’est à dire devenir l’élément essentiel d’un rouage quelconque. L’idée central de ce livre est de donner des conseils et de la motivation pour être indispensable, sortir de l’ombre de la masse.

On y parle donc de notre société en général, d’éducation, d’initiative, d’innovation et de créer de l’art. L’auteur nous dresse ainsi un portait intéressant de notre vie de travail et du fait et qu’on peut toujours faire mieux et se dépasser.

Plusieurs anecdotes se retrouvent dans le livre et sont amusantes et inspirantes à lire.

On y retrouve les sections suivantes traduites librement:

  • Le nouveau monde du travail : On discute dans ce premier chapitre comment le travail à évoluer et que nous ne sommes plus à l’époque des usines et du travail répétitif.
  • Réfléchir à ses choix : Intéressante section qui parle des choix qui s’offre à nous et comme c’est bon de prendre des risques, d’être généreux et de vivre le nouveau rêve américain.
  • Indoctrination: Comment on est en rendu là ? L’auteur aborde ici les problèmes du système d’éducation et de la mentalité de travailleur d’usine qui y est parfois inculqué.
  • Devenir le Linchpin : La personne qui maintient le tout dans une entreprise est un Linchpin et le monde en a besoin de plusieurs. Il n’a pas peur d’amener de nouvelles idées et  à ce petit plus qui le distingue des autres.
  • Est-ce que c’est possible de faire du bon travail dans un cubicuble ?  Description du labeur émotionnel et comment ajouter de l’art dans notre travail
  • La Résistance : Probablement le chapitre le plus important. Notre cerveau détient toujours un peu de lézard dans sa composition. Ce dernier a pour objectif de nous faire survivre. De nos jours par contre, il nous guide à éviter à tout prix les erreurs et les menaces et à rechercher le confort. La résistance veut contrer ce lézard et plutôt nous faire réalisez des choses et apprendre de nos erreurs. Par exemple, on ne devrait pas avoir peur de parler en public afin d’expliquer nos idées. Pourtant, c’est épeurant pour bon nombre de personne.
  • La puissance pouvoir culturel des cadeaux : Donner un cadeau sans réciprocité; être généreux. On parle ici de rendre un service ou d’ajouter le petit quelque chose qui n’était pas demandé.
  • Il n’y a pas de carte : Faire son propre chemin sans se faire dire quoi faire tout le temps.
  • Faire un choix : Quelques exemples de Linchpin. Est-ce que l’on rentre dans les rangs ou on se démarque ?
  • La culture de la connexion : Un Linchpin ne peut réussir seul. Il se doit d’entretenir des connections sociales.
  • Les sept habilités d’un Linchpin : Liste de ce qui rend un Linchpin indispensables.
  • Quand cela ne fonctionne pas : On fait davantage d’art ou on donne des cadeaux.

Quelques passages intéressants tirés du livre:

New bargain: leverage talent and creativity and art more than obedience

Flexible in the face of change, resilient in the face of confusion

What they should teach in school ? Only two things: Solve interesting problem and Lead

Three words can kill an organization: « Not my job »

Bref, ce livre est un cadeau. Offrez-vous le ou à quelqu’un d’autre à qui cela pourrait intéresser car c’est un excellent livre.

Mes points clefs:

  • Il reste un peu de lézard dans notre cerveau. Apprenons à le dresser.
  • Combattre le Statu Quo est parfois nécessaire
  • Soyez créatif, oser, même si cela comporte des risques.

 

 

 

 

Références:

Critique du livre: The Passionate Programmer

 

The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life)

Êtes-vous passionnés par votre travail ?

Je me suis intéressé à ce livre un peu par curiosité et je voulais voir ce qu’il pouvait apporter à ma carrière. Autrefois intitulé My job went to India: 52 ways to save your job dans sa première édition, le livre a changé de nom pour sortit un peu du titre controversé et bien refléter son sujet principal: comment avoir une carrière remarquable en tant que programmeur. L’auteur Chad Fowler est développeur connu au niveau international. Il travaille principalement avec le langage Ruby et le Framework Ruby on Rails.

Le livre est composé de 53 conseils de carrière divisés en 5 sections dont voici leurs descriptions:

  • Choisir son marché : L’importance de bien choisir dans quelles technologies et quel domaine d’affaires on veut évoluer. Ne pas se limiter à une seule technologie et bien balancer les risques potentiels.
  • Investir dans son produit : Mise à part la programmation, il est aussi important de bien connaître son domaine d’affaires. Si on ne connait pas trop certaines notions, se trouver un mentor. Si on veut voir si on connaître bien son affaire, essayer de l’enseigner à quelqu’un d’autre. Et ne pas oublier de pratiquer, pratiquer et pratiquer.
  • Exécution : Se rappeler régulièrement pour qui on travaille et s’assurer d’apporter de la valeur à l’entreprise. Noter ses bons coups et savoir comment gérer ses erreurs sont aussi important.
  • Marketing, pas seulement pour les cadres : Les perceptions sont importantes, c’est d’ailleurs le facteur principal dans les évaluations de rendement. Être présent et communicatif. Parler le langage de nos interlocuteurs.
  • Maintenir son expertise : Nous sommes déjà obsolètes ! C’est donc nécessaire de faire son plan de carrière,  de surveiller les tendances et de s’évaluer régulièrement

J’ai particulièrement aimé les sections qui parlaient des notions de Généralistes et de Spécialistes. L’auteur raconte qu’il est important d’être les deux. Je m’explique:

  • Être un généraliste: L’idée est ne pas être seulement un programmeur. Si l’opportunité se présente, ne pas hésiter à faire aussi de l’analyse, de l’architecture, de la charge de projet ou administrateur de base de données. L’idée est d’être utile à l’équipe, peu importe les tâches. C’est un peu la même chose au niveau de la technologie. Il faudrait normalement que nos habiletés transcendent les différentes infrastructures. Si on maîtrise bien une plateforme, ne pas hésiter à approfondir une autre.
  • Être un spécialiste: Bien connaître à fond un type de technologie est important. On ne parle pas ici de tout connaître, mais d’avoir une bonne profondeur pour connaître environ 80 % des situations qui pourraient se présenter au programmeur. Exemple: Si vous êtes un spécialiste .NET, vous n’avez pas d’excuses de ne pas connaître tout sauf du .Net. Il faut aussi savoir comment redémarrer un serveur IIS, faire l’installation d’un gestionnaire de code source ou corriger des problèmes de performance.

En conclusion, j’ai beaucoup aimé ce livre et d’ailleurs cela m’a pris seulement deux semaines à livre. Je le recommande à tous ceux œuvrant dans le domaine de la programmation, de près ou de loin. Les conseils de Chad Fowler, bien que pas nécessairement applicable pour tous, sont intéressants. On voit aussi à travers le livre ce qu’ont vécu l’auteur et les choix de carrière qu’il a du faire et pourquoi il les a faits. Bref, soyez passionné et remarquable !

Point négatif: On parle beaucoup du contexte américain et des emplois volatiles surtout en crise économique. Cela ne s’applique pas trop au Québec où l’on manque d’informaticiens un peu partout.

 

Mes points clefs:

  • Investir dans sa carrière est important. Il ne faut pas attendre que son employeur le fasse.
  • Être un généraliste et un spécialiste en même temps.
  • Bien connaître le domaine d’affaire de son employeur est un atout important.

 

Références :

Critique du livre Brain Rules

Brain RulesEn ces temps où une multitude d’informations nous arrive chaque jour de toute part, il est bon de se donner des trucs pour mieux gérer tout cela. Ce livre traite de ce sujet et il a attiré mon attention pour deux raisons:

  • Pour faire suite de ma lecture de Pragmatic Thinking, je voulais en savoir davantage sur comment notre cerveau fonctionne
  • Brain Rules était un des livres recommandés par Mark Levinson lors de sa conférence donnée à Québec l’an passé: Learning Best Approaches for Your Brain.
    Je me suis d’ailleurs procuré les trois livres que Mark recommandait tellement cela m’intéressait. J’ai choisi de commencer par celui-ci parce qu’il me semblait le plus facile d’approche et le tout est divisé en 12 chapitres, une pour chaque règle de survie que j’ai traduite librement ici:
  1. Faire de l’exercice est important
  2. Évolution de notre cerveau
  3. Chaque cerveau est ficelé différemment
  4. L’importance des émotions
  5. Répéter pour bien s’en souvenir (mémoire court-terme)
  6. Se souvenir de répéter (mémoire long-terme)
  7. Qui dort bien pense bien
  8. Cerveau stressé n’apprend pas de la même manière
  9. Stimuler plusieurs sens
  10. La vision peut tromper tous les autres sens
  11. L’homme et la femme ont des différences
  12. Nous sommes tous des explorateurs

À travers le livre, l’auteur nous explique chacune des ces règles, il nous parle de l’origine de notre cerveau et de ses évolutions. J’ai bien aimé lire les histoires et anecdotes qui sont présentes un peu partout dans le livre. Je comprends mieux aussi pourquoi il est bon d’intégrer des images et du texte pour mieux se rappeler. J’ai été étonné des différences entre le cerveau des hommes et des femmes, dans leur fonctionnement et aussi de liens entre les deux hémisphères. Autre chose intéressante, c’est que toutes ces découvertes sur le cerveau humains sont assez récentes. Et les recherches scientifiques continuent de progresser.

En conclusion, je pense qu’idéalement ce livre devrait être lu par tous les enseignants et par les grands penseurs du ministère de l’Éducation. Les nombres de trucs et de notions qui y sont décrites pourraient grandement améliorer la manière dont on enseigne, particulièrement à nos enfants.

Avant de vous procurer le livre, regarder le webcast cité dans les références en bas de la page. Si cela fait le tour pour vous, tant mieux. Si vous voulez approfondir les 12 règles, n’hésitez pas à lire le livre. Il est amusant, très intéressant et se lit assez bien.

Mes points clefs :

1216652_darts

  • Savoir comment notre cerveau fonctionne est très utile, peu importe notre métier
  • Vos actions et vos apprentissages sculptent comment votre cerveau est ficelé
  • Apprendre c’est explorer et c’est notre manière d’innover dans la vie

Références :

Critique du livre Agile Samurai

The Agile Samurai: How Agile Masters Deliver Great SoftwareUn autre livre sur l’agilité ?

Bon, il parle de quoi ce livre, une autre méthodologie ?

Une autre manière différente d’appliquer l’agilité ?

Non, rien de tout cela.

Ce magnifique petit livre (250 pages environ) ne fait que nous réexpliquer les différentes facettes de l’agilité mais d’une manière un peu spéciale.

Tout est présentement de manière simple, abondamment illustré et drôle par moment.

Voici la description des différentes sections du livre :

  • Dans la première partie du livre, on commence avec la base, soit l’Introduction à l’agilité et la description d’une équipe agile et les rôles que l’on y retrouvre normalement.
  • Dans la deuxième partie, Agile Project Inception, j’ai particulièrement apprécié la section sur le début d’un nouveau projet et les choses à faire afin que l’équipe s’approprie davantage le projet. On y explique diverses activités telles que le Inception Deck, un Elevator Pitch et la conception d’un Product Box. Je vais sûrement tenter d’essayer ces techniques un jour au l’autre.
  • La troisième partie, Planification d’un projet Agile, on discute de User Stories, Estimation et comment être flexible avec le Scope d’un projet.
  • La quatrième partie, Exécution d’un projet Agile, le concept d’itération prend tout son sens et on aborde plusieurs notions pour aider à livrer régulièrement notre produit logiciel. On voit comment les notions des 3 premiers chapitres fonctionnent ensemble. Exemples:
    • Comme quoi faire à l’itération 0
    • Quand faire l’analyse fonctionnelle
    • Communiquer l’information à l’équipe
    • Faire un espace de travail visuel
  • Pour finir, la dernière partie, Création d’un logiciel Agile, on fait la revue des pratiques d’ingénierie Agile connues et éprouvées tels que les tests unitaires, le refactoring, le TDD et l’Intégration continue. Même si je connaissais très bien ces notions, c’était intéressant de les trouver résumé dans le livre en y mentionnant de bons arguments pour les pratiquer.

Donc, on revoit la plupart des notions de l’agilité, ses principes et ses pratiques. Mais remis au goût du jour avec plusieurs illustrations et de nouvelles manières d’expliquer l’agilité. Le livre est raconté de la manière étudiant-professeur (ou plutôt Maître Sensei et Aspirant Guerrier pour rester avec la thématique Samurai) afin de nous glisser de prodigieux conseils tout au long du livre. On sent que l’auteur, Jonathan Rasmusson, a fait plusieurs projets agiles et veux nous communiquer son savoir et ses trucs. Bref, on trouve ici un guide visuel sur l’agilité, rien de moins. Même si vous être expérimenté avec l’agilité, vous avez de quoi à apprendre que ce soit les conseils du maître Sensei ou certaines techniques moins couvertes ailleurs.

Certaines notions ne sont abordés qu’en surface, tels que les Users Stories et le Refactoring,  et pour bien les maîtriser, il faudra peut-être faire d’autre lectures.

Petit point à améliorer selon moi dans le chapitre 2 sur l’équipe Agile. Le rôle « Programmeur Agile » couvre un peu trop large. On aurait dû le diviser avec un autre rôle plus senior genre « Tech Lead » ou « Agile Architect ». C’est certain qu’à la base on veut effacer un peu les rôles traditionnels et rendre l’équipe multifonctionnelle. Sauf que cela prend quelqu’un qui se charge en autre du respect des normes, de coacher l’équipe, de faire le lien avec les autres systèmes de l’entreprise et d’avoir une vue globale de l’architecture.

Merci en passant Pragmatic Press de m’avoir donné une copie ebook du livre en version beta et finale afin que j’en fasse la revue.

Darts

Mes points clefs:

  • Avant de commencer un projet Agile, il a des activités à ne pas oublier
  • Toujours avoir en tête les principes du manifeste agile et comment les appliquer concrètement
  • Scrum et XP Programming y sont mélangés pour ne faire qu’un dans le livre.

Les références:

Mes prochaines lectures 2010

IMG_2447Avec les vacances, je prévois avoir davantage de temps libre pour faire de la lecture. On verra bien si cela va se réaliser ou non.

Histoire d’être mieux organiser, j’ai décidé d’aligner mes prochaines lectures afin de mieux suivre mes objectifs 2010. Je vais tenter d’en lire un ou deux pendant mes vacances et le reste, idéalement d’ici la fin de l’année.

Je vais aussi vous faire un résumé ici de ces prochaines lectures.

J’ai aussi terminés la lecture de plusieurs livres (Linchpin, Brain Rules, The art of Unit Testing) qui seront résumé aussi lorsque le temps me le permettra.

Bon, voici donc cette liste de mes prochaines lectures:

  • Made to Stick par Chip Heath & Dan Heath : Livre abordant la créativité et le pourquoi certaines idées “collent” davantage que d’autres. C’est une des suggestions de Mark Levison lors de son passage à Québec en mai dernier.
  • The Back of the Napkin et Unfolding the Napkin by Dan Roam: Pour en apprendre davantage avec le “Visual Thinking”. Dan Roam a écrit deux livres sur le sujet de comment illustrer ses idées de manière simple. Le premier de ces livres, The back of the Napkin, parle surtout de la théorie, et son deuxième, unfolding the napkin, est plutôt un guide de comment apprendre la technique par des exercices. Je me demande par lequel je vais commencer… La théorie ou la pratique ?
  • Simplicity par Edward de Bono: Ce livre vient d’être rééditer; il était auparavant difficile à trouver. J’ai déjà lu sur la simplicité avec le livre “Laws of Simplicity” et j’avais bien aimé. Daniel Lafrenière m’a recommandé celui de Edward de Bono pour approfondir davantage le concept de la simplicité qui peut s’utiliser un peu partout.
  • Presentation Zen par Garr Reynolds: Beau livre en couleur avec plein d’exemples de comment faire de bonnes présentations. Cela devrait bien accompagner le concept de Beyond Bullets points que je connais déjà bien.
  • Agile Coaching par Rachel Davies et Liz Sedley: J’ai ce livre depuis près d’un an et je ne l’ai pas encore lu. Il est grand temps que je m’y mettre donc. On y retrouve plusieurs bons conseils sur le coaching et comment introduire des nouvelles notions, comme l’agilité, au sein d’un équipe.
  • Programming F# par Chris Smith: Je voulais apprendre au moins un nouveau langage de programmation cette année. Ainsi avec le F#, je vais toucher le concept de la programmation fonctionnelle et aussi voir les nouveautés avec Visual Studio 2010.

Aussi, j’ai pris l’habitude de mettre les références à la fin de mes billets plutôt que répartis un peu partout dans le texte. Je trouve que cela rend le tout plus lisible. Qu’en pensez-vous ?

Références :

Critique du livre Pragmatic Thinking & Learning

J’ai lu le livre « Pragmatic Thinking and Learning: Refactor your Wetware » l’été passé (et oui, je suis un peu en retard dans mes critiques de livres, mais bon) et j’ai vraiment aimé ce petit livre. Son auteur, Andy Hunt, est aussi le co-auteur du fameux The Pragmatic Programmer . Le livre est bien présenté avec plusieurs chapitres, plusieurs images sont présentes pour illustrer certains concepts et on retrouve des capsules conseils un peu partout dans le livre.

Ce livre ne parle ni de programmation ni d’agilité (et oui !). On y discute principalement comment notre cerveau fonctionne et comment l’optimiser dans ce monde qui ne cesse d’évoluer et où nous sommes en apprentissage continue. Ce livre vise donc en particulier les personnes œuvrant dans le domaine informatique, mais pourrait aussi bien être très utile en générale pour quiconque.

Le livre commence en introduction en nous rappelant de toujours considéré le contexte car tout, d’une certaine manière, est inter relié. J’aime beaucoup aussi quand on décrit brièvement tous les chapitres du livre dans l’introduction. Cela nous permet d’avoir un bon aperçu du livre et voir ce qui va s’en venir. Autres sujets couverts dans les chapitres suivants : le modèle d’acquisition de connaissance Dreyfus, le fonctionnement de notre cerveau, comment apprendre délibérément, comment déboguer notre cerveau, acquérir de l’expérience et garder le focus.

J’ai particulièrement apprécié le chapitre 3 qui décrit comment fonctionne notre cerveau avec quelques analogies informatique. On y parle aussi de nos deux cotés du cerveau qui y sont rebaptisé mode linéaire (gauche) et mode riche (droit). L’idée n’est pas de connaître son côté dominant et de l’exploiter au maximum. Au contraire, nous avons besoins de deux côtés et il faut parfois se servir de l’un et l’autre pour arriver à nos fins. Par exemple, on peut partir quelque chose en mode riche (coté droit) pour générer des idées ou être créatif et par la suite retomber en mode linéaire (côté gauche) pour analyser le tout et faire des regroupements. Par contre, embarquer en mode riche n’est pas toujours évident, mais le livre mentionne plusieurs trucs et façons de faire pour y parvenir.

Un petit passage que j’ai bien aimé : Savez-vous que travaillez dans un cubicule détruit nos neurones ? La création de nouveaux neurones est davantage stimulée dans un environnement riche ou l’on peut observer, apprendre et interagir. Comme un animal dans une cage, un programmeur pris dans un cubicule ne fera pas la création de nouveaux neurones. Voilà pourquoi c’est important d’avoir un espace de travail ouvert et qui stimule nos sens. Voici quelques articles en référence à ce sujet :

Bref, j’ai beaucoup aimé ce livre et je le recommande à tous. Seul petit point négatif, certain sujets sont abordés très légèrement et aurait mérité qu’on y aille en profondeur. Pour ce, il faut donc me falloir d’autres lectures…

Mes points clefs : Darts

  • Nous avons besoin toujours besoin de nos deux modes de fonctionnement de notre cerveau : mode linéaire et mode riche.
  • Prendre en note chaque idée que nous avons. De cette manière on pourra en générer davantage
  • Lire et relire pour ne pas oublier. Utiliser des « mind maps » pour résumé le contenu.
  • Et ne jamais oublier le contexte, car tout est inter relié

Critique de livre : The Five Dysfunctions of a Team

FiveDysfunctionsCover Ce livre n’est ni technique et ne parle pas d’agilité. Pourquoi donc j’en ai fait la lecture ? Et bien tout a commencé cet été lors de mon passage à la conférence Agile 2009 qui a eu lieu à Chicago, lorsque j’ai assisté à la présentation suivante :

Scaling Up by Scaling Down: A (re)Focus on Individual Skills

Dans cette présentation sur le comment faire progresser une équipe pour la rendre hyper-performante, on mentionnait le livre en référence. Intrigué, je me suis procuré le livre en question sur les 5 dysfonctions d’une équipe. En passant, la présentation a été filmée et vous pouvez donc l’entendre au complet sur le site d’infoQ:

http://www.infoq.com/presentations/scaling-up-by-scaling-down

Je vous la recommande fortement si vous voulez en savoir davantage sur le leadership d’équipe et le lien avec l’agilité. Le conférencier, Ashley Johnson,  parle avec un anglais qui est en général très facile à comprendre.

Pour revenir au livre, c’est un bon livre et j’ai l’est vraiment aimé. Il est d’ailleurs utile pour tout ceux qui sont intéressé par le travail d’équipe, peu importe leur rôle. C’est une lecture assez facile, cela m’a pris environ 1-2 semaine pour le terminer. De plus, son contenu est présenté ainsi, de manière peu conventionnelle:

  • Les 184 premières pages du livre racontent une "fable" sur le leadership.
  • C’est dans les 40 dernières pages que le modèle des 5 dysfonctions nous est décrit.

J’ai trouvé très instructif ce format. On nous fait découvrir graduellement la théorie des 5 dysfonctions d’une équipe à travers une histoire fictive, mais très réaliste. On devient rapidement accroché à l’histoire et on a hâte de voir la suite et comment l’équipe va réussir à corriger ces 5 dysfonctions. Ce format nous permet de comprendre la théorie à travers une histoire au lieu d’y aller directement avec la théorie sans trop de concret. Ah si les écoles fonctionneraient de cette manière…

Pour les 5 dysfonctions d’une équipe je les résume ainsi avec une traduction libre :

  • Manque de confiance envers les autres (Absence of trust)
  • Peur des conflits (Fear of conflicts)
  • Manque d’engagement (Lack of commitment)
  • Éviter la responsabilisation (Avoidance of accountability)
  • Inattention aux résultats (Inattention to results)

On doit commencer idéalement par résoudre la première dysfonction, ici le manque de confiance, et résoudre les autres en ordre par la suite pour finir avec le dernier, soit l’inattention aux résultats.

Vous trouverez le détail de ces dysfonctions dans les documents suivants disponibles:

Autre bon résumé si vous avez moins de 5 min, écouter l’auteur du livre, Patrick Lencioni, nous décrire brièvement les 5 dysfonctions:

 

Pour poursuivre mon habitude des points clefs, voici ce que je retiens de cette lecture :Darts 

  • Si on se retient de dire des choses de peur de confronter les autres, cela nuit grandement à rendre une équipe fonctionnel
  • Viser le consensus de toute l’équipe n’est pas toujours la bonne chose à faire. L’important c’est que tous les membres de l’équipe aient eu l’occasion de s’exprimer. Après, la décision passe beaucoup mieux au sein de l’équipe.
  • Je vois bien intégrer ce genre de modèle aux pratiques de rétrospective et d’amélioration continue d’une équipe Agile. À essayer donc lors d’un prochain projet.