Notes de lecture : Lean Change Management

Article publié précédemment sur ExcellenceAgile.com

leanchangemanagementNous avons beau avoir de bonnes intentions, être passionnés d’Agilité et dévoués à nos clients, mais l’humain étant ce qu’il est, il est fort difficile de prévoir comment il peut changer !

Comme dans tout bon projet informatique, on ne peut donc pas tout prévoir en détails la planification de la gestion du changement. Pour surpasser les résistances et obtenir des implémentations de changement avec succès, on doit donc adapter les techniques traditionnelles de gestion du changement en y mettant un peu d’Agilité et du « lean ».

On ne peut pas tout savoir ou prévoir au départ et il nous faut l’accepter. On doit donc se baser sur les principes et valeurs Agiles pour guider nos actions dans le changement.

C’est le sujet principal du livre « Lean Change Management – Innovative Practices for Managing Organizational Change » dont je vais vous parler aujourd’hui.

Son auteur, Jason Little, est un canadien, ancien développeur et maintenant conseiller en gestion du changement, il a mis à l’épreuve les différentes techniques décrites dans son livre pour une organisation publique canadienne.

Bien que ce soit un petit livre, il fait un peu moins de 200 pages, ce dernier est quand même rempli de processus, frameworks, conseils et autres outils pertinents pour une gestion du changement « lean » et Agile. Tout cela s’articule autour du cycle intitulé « Lean Change Management » que voici :

lean-change-cycle

En gros, voici ce que veut dire chaque étape traduite librement en français:

  • Aperçus (Insights): Comprendre l’état actuel des choses dans l’organisation. Pour collecter cette information, il y a plusieurs méthodes et outils tels que : sondages, entretiens, rétrospectives, etc. Une fois toutes ces informations recueillies, il faut les analyser dans sa vue globale et voir les options à essayer.
  • Options: Les options à mettre en action ont toutes un coût, une valeur et un impact. Prendre celles qui font le plus de sens dans le contexte actuel afin de valider les hypothèses émises.
  • Expérimentations: Introduire un changement via une option et voir comment il en résulte. Cette étape a aussi le sous-cycle suivant :
    • Préparation: Préparer à valider nos hypothèses et notre approche avec les personnes affectées par le changement.
    • Introduction : Le changement est introduit dans le processus.
    • Révision : On regarde les résultats après un certain temps. Selon ce qui s’est passé, on peut prévoir un autre cycle d’expérimentation.

Dans les premiers chapitres du livre, on introduit rapidement le cycle et ses origines. Pour le reste du livre, on décrit en détails chacune des étapes du cycle avec, bien entendu, les commentaires et l’expérience vécue de l’auteur. Ce qui en fait un livre captivant et intéressant à lire. Lors de sa lecture, il nous arrive de prendre note de plusieurs éléments et conseils qui pourront nous servir en tant que coach Agile. Tout ceci est valable autant pour des changements de processus que pour l’adoption de nouvelles techniques telles que le TDD. Un « must » donc à lire pour tout coach Agile impliqué dans une transformation Agile.

En résumé, voici mes trois leçons apprises suite à cette lecture:

  • Utiliser un cycle basé sur le feedback pour mesurer le changement.
  • Impliquer les gens affectés par le changement dans la conception du changement.
  • Bien mesurer nos options. Chacune d’entre elles a un coût, une valeur et des impacts.

Références :

Être réviseur de livres techniques

Savez-vous qu’il possible de faire partie des réviseurs d’un livre technique en cours d’écriture ?

Cela vous demande un peu de temps et de donner un feedback constructif à l’auteur. Est-ce que vous avez besoin d’être un expert pour faire une revue de code ? Non, pas vraiment. Il faut surtout être intéressé par le sujet et bien gérer son temps. Il faut parfois respecter des dates cibles pour envoyer nos commentaires.

Les avantages ?

La maison d’édition vous donne en général une copie gratuite du livre et vous avez votre nom inscrit dans la liste des réviseurs quelque part dans le livre. Vous aurez aussi la satisfaction d’avoir aidé l’auteur à rédiger son livre. C’est quand même très bien.

Et peut-être aussi qu’ils choisiront une de vos citations et l’afficheront à l’arrière du livre. C’est que Manning Press a fait dernièrement pour le livre « BDD in action ». C’est assez flatteur, pour mon cas, de retrouver son nom et celui de son employeur à côté de Dan North, inventeur du BDD.

BDDInActionSi être un réviseur technique d’un livre vous intéresse, regardez les liens suivants:

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

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:

Quelques lectures gratuites

J’ai fait quelques lectures intéressantes dans le dernier mois et je voulais vous en parler. Les petits documents mentionnés dans le tableau plus bas sont à mi-chemin entre un article et un petit e-book. Donc, assez facile à lire.  Les trois couvrent des sujets totalement différents, mais qui peuvent intéresser plusieurs. De plus, ils sont tous gratuits et téléchargeables. Les voici donc:

Getting Started with Kanban par Paul Kipp

Get started with Kanban, a free eBook by Paul Klipp

Petit document qui résume bien ce qu’est l’outil ou la technique Kanban. Utile si vous ne connaissez rien au Kanban ou pour le résumer à quelqu’un d’autre.Issue de la méthodologie « Lean », le Kanban peut être appliqué dans plusieurs domaines: informatique, ingénierie, vente, tâches familiales, études, gestion, etc.

En gros, le Kanban consiste à suivre les 3 règles suivantes:

  • Visualize Workflow
  • Limit Work in Progress (WIP)
  • Measure and Improve Flow

 

The New Time Management

par Francis Wade

45

Intéressante lecture qui nous suggère de revoir les 7 principes fondamentaux de la gestion du temps. Malgré les outils et techniques, si on ne maîtrise et si on ne pratique pas la base, on risque d’être davantage stressé et plus ou moins productif.L’auteur mentionne qu’il est normal d’essayer de nouvelles techniques, de se mesurer et de s’ajuster régulièrement. Tout cela dans le but de trouver la bonne solution selon notre style de vie professionnelle et personnelle.

Donc, pas de recette unique pour tout le monde.

The Accountability Effect

par Basam Tarazi

image

Introspection pertinente sur qui nous sommes, nos buts dans la vie et l’importance de prendre soin de nous même. Sinon, la vie passe vite et on risque d’accumuler plusieurs regrets.Aucun « timming » n’est parfait pour faire les choses dont on parle souvent. L’auteur nous montre ce qu’il faut être « présent » et prendre les responsabilités de nos actions ou le manque de celles-ci.

Lecture très intéressante qui amène des réflexions que nous n’avons malheureusement pas assez souvent.

 

Bonne Lecture !

 

Notes de Lecture: The Art of Unit Testing

J’ai lu ce livre il y a un an ou deux, mais il est toujours d’actualité et je trouvais important de vous en parler. D’une certaine manière c’est toujours bon de revoir ses bases de temps à autre. Ce livre est en quelque sorte un « must » pour tout développeur, notamment ceux qui font du .Net. Il existe aussi une version inspirée de ce livre chez le même éditeur avec les exemples en Java intitulé « Unit Testing in Java » qui sera publié cette année.

Premièrement, pour bien situer ce livre, ce dernier se concentre surtout sur l’aspect « Test unitaire » et non le TDD (Développement piloté par les tests). Ce dernier y est mentionné un peu, mais l’accent de ce livre n’est pas tout simplement pas sur cet aspect.

L’auteur, Roy Osherove,  nous fait découvrir de manière pédagogique plusieurs notions essentielles lorsque l’on veut progresser dans les tests unitaires, notamment vers des cas plus complexes. Et ce, dans l’environnement de développement .Net, malgré que la plupart des notions peuvent être adaptées pour un autre environnement de développement orienté-objet.

Le TDD avec des cas simples c’est bien beau et facile, mais cela peut se corser assez vite merci. On y voit alors dans ce livre plusieurs trucs, notions et techniques tels que:

  • Les techniques de base
    • Les Stubs
    • Les Mocks
    • Les différents frameworks d’isolation
  • Le code de test
    • L’organisation et la hiérarchie des tests…
    • Les bonnes pratiques pour les tests
  • Processus et conception
    • Intégrer les tests dans l’organisation
    • Travailler avec du « Legacy Code »

J’aime le fait que l’auteur dans les premiers chapitres s’occupe de bien définir les termes essentiels qui seront utilisés tout au long du livre tel que:

  • Test Unitaire
  • Test d’intégration
  • State-based testing / vérification d’état
  • Interaction testing / vérification de l’interaction avec d’autres objets
  • Système sous test
  • La régression
  • C’est quoi du « Legacy Code » ? (en fait c’est du code sans tests unitaires)
  • Refactoring
  • Seams
  • Fake
  • Dynamic Fake

Point que je trouve important et qui est aussi abordé dans ce livre, c’est comment nommer nos méthodes de tests. J’aime bien la formule que l’auteur suggère, soit de nommer en trois parties séparées par le caractère « _ »:

  • Nom de la Méthode
  • État du test
  • Comportement prévu

Ex.: IsValidFileName_ValideFile_ReturnsTrue()

Si vous avez beaucoup de tests dans votre projet, vous allez voir que ce type de nommage aidera le classement et permettra de facilement déduire le test d’après son nom.

Le Pattern AAA est aussi abordé dans le livrer et c’est un de mes préférés. Donc, je vais vous en parler un peu. Il s’agit en fait de faire notre méthode de test en trois « sections » fonctionnelles qui sont les suivantes:

  1. Arrange: On prépare les variables nécessaires et autres préalables.
  2. Act: Action sur l’objet ou la méthode que l’on teste
  3. Assert: On compare le résultat attendu versus celui obtenu.

Exemple:

[Test]
 public void CalculateSalesBonus_VendorWithSalesBonus_BonusMade()
 {
 // Arrange
 int salesNovember = 10000;
 var calculator = new BonusCalculator();

 // Act
 var result = calculator.CheckBonus(salesNovember);

 //Assert
 result.ShouldEqual(100);
 }

Un aspect important quand on établit notre code de test, c’est de commencer par l’assertion (et oui, on commence par la fin !). Cela rend plus clair par la suite la réalisation des étapes d’Arrange et d’Act. Ce conseil me vient de JR Rainsberger que j’ai eu l’occasion de rencontrer au Code Retreat à Québec en 2011.

Personnellement, je trouve que faire des mocks peut parfois être utile, mais il faut faire attention car cela peut nous amener à faire beaucoup de code. J’aime bien dans ces cas appliquer la règle de Pareto, ou celle du 80/20, c’est-à-dire qu’on ne fera pas du code 80% plus gros pour tester un 20% de notre application. Il faut y aller alors de manière pragmatique.

L’auteur parle aussi au chapitre 8 des manières d’introduire les tests unitaires automatisés dans une organisation, encore là, une bonne section du livre. Le facteur humain n’est pas à négliger ici, car le TDD et les tests unitaires, qui introduisent une nouvelle manière de concevoir notre code, peuvent provoquer des bouleversements au passage.

Bref, si vous faites du développement avec .Net ou Java, et que particulièrement vous trouvez que c’est dur de faire des tests unitaires (et vous avez raison, car ce n’est pas une mince tâche), ce livre peut vous aider.

J’ai fait un résumé des idées de ce livre (avec une certaine adaptation) dans le mind map suivant (cliquer pour l’agrandir) :

 

 

 

 

 

 

 

Mes points clefs:

  • C’est important de bien connaître les techniques de base (stub, mock et framework) afin de progresser dans la programmation des tests unitaires
  • Organiser les tests (nomenclature, projets), n’est pas à négliger pour établir un standard dans l’équipe de programmeurs
  • Pour implanter le TDD et les tests unitaires dans une organisation, il faut être prêt. Ex.: répondre aux questions, identifier les champions, gérer avec les « bloqueurs, avoir des buts spécifiques, etc.

 

Références:

Est-ce que votre code est S.O.L.I.D. ?

CrackDans ce billet, je vais vous décrire brièvement les principes SOLID pour la programmation orientée-objet avec quelques commentaires et vous suggérer quelques ressources pour approfondir ce sujet qui devrait être connu de tous les programmeurs sérieux et professionnels.

Je suis toujours surpris lorsque, la plupart du temps, à chaque fois que je parle de ces principes à de nouveaux collègues, mon interlocuteur hausse les épaules et ne sait pas de quoi je parle.

 

S.O.L.I.D. est acronyme regroupant les principes suivants:

  • Single Responsability Principle (SRP): Une classe devrait avoir une et une seul raison (responsabilité) d’être modifiée.
  • Open Closed Principle (OCP) : Chaque classe devrait être ouverte pour des extensions et fermé autant que possible pour des modifications.
  • Liskov Substitution Principle (LSK) : Les classes dérivées peuvent être substitué de leur classe de base
  • Interface Segregation Principle (ISP) : Nos classes ne doivent pas hériter, via une interface, de méthodes qu’elles n’utilisent pas.
  • Dependency Injection Principle (DIP) : On doit dépendre de classes abstraites et non de classes concrètes

De tous ces principes, le plus important à suivre selon moi est le Single Responsability Principle (SRP). Ne pas respecter ce principe peut apporter plusieurs maux, notamment lorsque l’on fait évoluer le code.  Dans mon équipe actuelle, nous avons fait du SRP le principe de base et le plus important à suivre. De cette manière nous l’avons toujours en tête et il nous sert en quelque sorte de règle de base lorsque l’on se questionne sur la grosseur de classes et de méthodes ou autre.

C’est important aussi de connaitre les autres, mais on y fait référence un peu moins souvent à mon avis.

Pour en savoir plus, sur SOLID, vous pouvez commencer par les deux références suivantes sur Internet :

Pour approfondir SOLID, je recommande fortement le livre suivant (Liens Amazon.ca commandités) de Bob Martin qui se décrit en deux versions, tout dépendant si vous êtes de type Java/C++ ou .Net:

Agile Software Development, Principles, Patterns, and Practices

Type .Net (C#/VB)

Type Java/C++

Dans ce livre, l’oncle Bob nous explique les pratiques agiles, on y voit un peu de modélisation et aussi de nombreux chapitres sont dédiés aux principes orientés-objet. Ce livre d’environ 700 pages fait un très beau livre de référence à mettre sur son bureau pour le lire au complet ou le consulter à l’occasion.

En passant, nous aurons la chance de recevoir Bob Martin en tant que conférencier principal lors de l’Agile Tour Québec 2011. Les inscriptions devraient commencer en septembre. Pour info sur l’Agile Tour : http://at2011.agiletour.org/fr/at2011_Quebec.html

Autres articles intéressants avec exemples d’application de SOLID:

Référence pour l’image utilisée:

http://www.sxc.hu/photo/954598

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 :