Groupe de lecture en entreprise

J'apprends essentiellement par la lecture de (bons) livres: nouveaux langages, pratiques de développement, management... Or j'ai toujours éprouvé beaucoup de difficultés à faire lire ces mêmes livres à des collègues. Il semble de notoriété publique qu'un livre qui touche de près ou de loin à l'informatique est forcément difficile et ennuyeux à lire (pour être poli). Si de plus rédigé en anglais ...

Pour se donner le courage d'étudier un livre ensemble, d'apprendre et d'échanger autour de nouvelles connaissances, nous avons formé il y a deux mois un groupe de lecture dans mon entreprise. Nous avons commencé à trois personnes et maintenant nous sommes cinq, je croise les doigts pour que ça continue !

Voici la démarche que nous avons adopté:

1. Sélectionner un ouvrage:

• Choisir un domaine dans lequel le groupe veut acquérir de nouvelles connaissances. Par exemple: Ruby, Python, Scrum, ...
• Chercher et proposer une liste réduite de livres et/ou essais sur un thème donné. Se fier aux critiques des lecteurs pour avoir la certitude que le livre est bon. Attention aux mauvaises traductions: les budgets de traduction entre un Harry Potter et un livre d'informatique semblent très différents ;).
• Acheter les livres (ou le PDF et imprimer). Chacun doit avoir son exemplaire.

2. Choisir une organisation:

A quelle heure se rencontre t'on ? Combien de fois par semaine ? Quels jours ? Quelle est la durée de la session ?
Dans notre cas, nous nous réunissons tous les Lundi et Jeudi à 12h, pendant 45 mn maximum.

Une personne doit être leader du groupe et s'assurer du respect de l'organisation (un Scrum Master du groupe de lecture en quelque sorte).

3. La préparation de la prochaine rencontre:

On choisit collectivement ce qui doit être lu pour la prochaine rencontre: les trois sections suivantes, le prochain chapitre.

Une personne doit être désignée (à tour de rôle) pour faire le résumé de la partie à lire.


4: La rencontre:

Tout le monde se retrouve autour d'une table. La personne en tâche de faire le résumé s'exécute. L'objectif est d'échanger, débattre et clarifier chacun des points abordés.

A la fin de la rencontre, retour au point 3 pour préparer la rencontre suivante.


Nous avons commencé cette pratique par la lecture de l'essai How to be a Programmer: A Short, Comprehensive, and Personal Summary de Robert L.Dead. Cela nous a permis de nous mettre en jambe avec un document court (quatre rencontres) et de valider notre fonctionnement.

Nous sommes ensuite passés à Plonger au cœur de Python (traduction de Dive Into Python de Mark Pilgrim) qui a l'avantage d'être ludique (et en français me diront certains).

Les lectures de l'été

Je me suis fait une nouvelle petite cure pragmatique cet été. Les ouvrages du Pragmatic Bookshelf me plaisent toujours autant: bien construits, écriture fluide. Le soucis c'est que le livre finit on s'aperçoit qu'on a encore bien plus à apprendre qu'avant de commencer...

The Passionate Programmer: Creating a Remakable Career in Software Development de Chad Fowler adopte une structure similaire à Pragmatic Programmers: From Journeyman To Master. Chacune des 53 sections détaille une pratique, une attitude, une réflexion pour améliorer la prise en main de notre carrière de développeur et être reconnu par les différentes "tribus" (programmeurs, managers, clients, ...) avec lesquelles on se doit de communiquer. Le livre est très intéressant, convaincant, avec quelques bonnes anecdotes.
J'ai surtout aimé les parallèles avec l'apprentissage d'un instrument de musique et les habitudes, aspirations des musiciens. En musique on se doit de pratiquer régulièrement notre instrument et de travailler aux limites de ses possibilités pour progresser. L'amélioration de ses compétences de programmeur nécessite aussi d'adopter un rythme d'entraînement pour pratiquer sa technique.
Apprendre un instrument de musique différent de celui qu'on joue constitue un bon moyen de s'améliorer. Par exemple, un saxophoniste gagnera beaucoup à apprendre la basse ou la batterie, un bassiste le piano, ... Il est en effet plus rapide d'acquérir un jeu rythmique avec la basse ou la batterie, un jeu polyphonique avec le piano ou la guitare, ... De même, un développeur C peut apprendre Python, un développeur Java le Lisp, Erlang, ... pour découvrir des techniques plus facilement qu'avec le langage qu'il connaît. Si vous voulez comprendre la méta-programmation, utilisez Ruby. Pour l'objet prenez Smalltalk....

Pragmatic Version Control Using Git de Travis Swicegood fait partie du Pragmatic Starter Kit (contrôle de version, test unitaires, automatisation) qui constitue la boîte à outil de base du développeur pragmatique ;). Travis Swicegood présente les différents types de VCS puis détaille l'utilisation de Git jusqu'à des concepts avancés. Le livre est bien structuré, les exemples manquent parfois un peu de profondeur à mon goût. J'ai bien aimé la présentation de l'interface Subversion de Git (git svn) qui permet de synchroniser son dépôt Git local avec un dépôt Git central. Cela permet de profiter des apports de Git même si l'équipe utilise Subversion, ou bien faire une migration en douceur. Les fonctionnalités de séparer un commit en plusieurs et vice-versa constituent un bon complément aux lacunes de Subversion sur ce point (par exemple en période de mise au point où on corrige plusieurs bugs en même temps et qu'on veut faire un commit par correction de retour au bureau).

Enfin, Andy Hunt et Dave Thomas décrivent différentes techniques de test unitaires dans Pragmatic Unit Testing in C# with NUnit. Le livre détaille les cas auxquels nous sommes couramment confrontés dans l'écriture de tests unitaires (mocks, travailler avec des bases de codes non testées, le test d'interfaces graphiques) et liste exhaustivement les points à vérifier pour avoir des tests complets. Ceci dit, pour apprendre le développement piloté par les tests, je conseillerais plutôt l'ouvrage de Dave Astels "Test Driven Development: A Practical Guide". Le livre de Hunt et Thomas, certes de qualité, me paraît moins accessibles par les développeurs qui n'ont jamais écrit de tests.

Pomodoro technique et cerveau droit

La "Pomodoro technique" permet d'optimiser sa gestion du temps. Elle se présente comme un moyen d'éliminer son anxiété (de manque) du temps, d'améliorer son attention et sa concentration.
Pomodoro signifie tomate en italien et fait référence au minuteur de cuisine de l'auteur Francesco Cirillo en forme de tomate.
La technique s'apparente aux méthodes agiles, itératives. Là où les méthodes agiles s'attachent beaucoup à l'équipe, Pomodoro s'intéresse plus à l'individu. La technique peut néanmoins s'utiliser en groupe. Henrik Kniberg décrit le processus comme un Scrum individuel basé sur des itérations de 25 mn, qui en garde la plupart des avantages (cf le billet sur son blog).
Le Pomodoro nous contraint (dans le bon sens du terme) à exercer la même activité sans interruptions pendant une tranche de temps courte et de durée fixe. L'objectif est de maximiser sa concentration sur ces 25 minutes et nous apprendre à gérer rapidement les interruptions (un mail qui arrive, coup de téléphone, question d'un collègue) et à les reporter sur un Pomodoro suivant.
Le livre téléchargeable "The Pomodoro Technique" en décrit les règles:

• Un Pomodoro (unité de mesure) dure 25 minutes, plus 5 minutes de pause.
• On prends une pause de 15 à 30 minutes tous les 4 Pomodori.
• Un Pomodoro est indivisible. Il n'existe pas de demi ou quart de Pomodoro.
• Un Pomodoro commencé doit obligatoirement se terminer:
• Si un Pomodoro est stoppé car on n'a pas su gérer la perturbation / interruption, on doit le considérer comme nul.
• Si une activité se termine avant la fin d'un Pomodoro, on ne change pas d'activité et on utilise le temps restant pour passer en revue cette activité.
• Protégez le Pomodoro. Informez efficacement, négociez rapidement la planification de l'interruption, rappelez la personne qui vous a interrompu au moment convenu.
• Si vous estimez une tâche à plus de 5-7 Pomodori, divisez la. Les tâches complexes doivent être décomposées en plusieurs tâches.
• Si vous estimez une tâche à moins d'un Pomodoro, combinez la avec d'autres tâches simples.
• Les résultats sont enregistrés après chaque Pomodoro.
• Le Pomodoro suivant se déroulera mieux.

A noter que Staffan Nöteberg prépare un livre sur le sujet, "Pomodoro Technique Illustrated", et propose de télécharger les ébauches sur http://www.pomodoro-book.com/.

---

Quel rapport avec le cerveau droit ? L'obligation des pauses de 5 et 15-30 minutes m'a intéressé.
Dans "Pragmatic Thinking & Learning", Andy Hunt détaille le fonctionnement du cerveau et explique les avantages qu'on peut tirer quotidiennement de cette connaissance, comment nous pouvons améliorer l'utilisation de notre matière grise. La distinction cerveau droit et gauche symbolise deux fonctionnements identifiés. En simplifiant à l'extrême:

• le cerveau gauche fonctionne par logique (si dans X je mets Y alors j'obtiens Z), s'occupe du langage, analyse les détails. C'est la voix qui nous parle.
• le cerveau droit fonctionne par synthèse, avec une vision globale. Il nous fait rêver et nous apporte de nouvelles idées. C'est un cerveau créatif, riche.

Andy Hunt nomme ces deux manières d'utiliser notre cerveau L-Mode (pour left et linéaire) et R-Mode (pour right et riche). Si quelqu'un a un moyen mémotechnique en français...
Nous ne pouvons pas utiliser nos deux cerveaux à la fois. Lorsqu'on programme, tape sur le clavier, on utilise notre cerveau gauche, linéaire, analytique. Lorsqu'on bloque sur notre programme, on s'éloigne du clavier, regarde ailleurs, arrêtons de nous parler. Nous laissons travailler notre cerveau droit pour qu'il nous donne une solution.
Malheureusement, l'éducation et l'entreprise nous ont forgés à sur-utiliser notre cerveau gauche au détriment du droit. On ne nous paye pas à méditer, rêver, dessiner ou jouer de la musique. Ce sont pourtant ces activités qui nous permettent de développer nos idées et nos manières de penser. Ceci dit, des entreprises prennent conscience de ce phénomène et intègrent des activités sportives, artistiques ou de relaxation au quotidien.
Mais revenons au Pomodoro. Une itération dure 25 minutes puis nous prenons 5 minutes de pause, ou 15-20 minutes tous les 4 Pomodori. Pendant ces pauses, il ne faut pas penser à l'activité que nous venons d'exercer. Rêvez, allez marcher dans un endroit tranquille, dessinez sur une feuille... activez votre cerveau droit ! C'est à ce moment là que les idées arrivent et peut-être une meilleure solution aux problêmes que nous tentions de résoudre. Dès qu'une idée apparaît, notez-là pour ne pas la perdre. Combien de fois avons nous eu des idées géniales sous la douche que nous avons perdu cinq minutes après...

---

Le pair-programming, deux développeurs pour un ordinateur, permet d'utiliser les deux modes de fonctionnement en même temps. La personne qui tape est en mode analytique (cerveau gauche) et celui qui pilote en mode synthétique, il garde le recul sur le développement. Il me reste à essayer la combinaison pair-programming + Pomodoro et voir si les deux pratiques se combinent bien...

Modèle Dreyfus

Je viens de recevoir "Pragmatic Thinking and Learning" de Andy Hunt (co-auteur du célèbre "The Pragmatic Programmer: From Journeyman to Master"). Le livre s'annonce passionnant.

Le second chapitre présente le modèle Dreyfus d'acquisition de compétences. Cette théorie dit que le passage de novice à expert d'un domaine donné passe par cinq étapes.

étape 1: Novice

• l'activité change sa manière de penser car il acquiert de l'expérience dans un domaine qu'il ne connaît pas, ou peu.
  
• il focalise sur le besoin, l'objectif immédiat.
• l'accomplissement de ses tâches nécessite des recettes, une marche à suivre.
  
• il n'a pas d'intuition sur la manière de résoudre les problématiques

étape 2: Débutant avancé

• il fait preuve d'indépendance technique et sait chercher l'information nécessaire à l'accomplissement de ses tâches.
  
• il sait choisir quelle démarche et technique appliquer selon le contexte.
• il ne comprends pas ou peu la stratégie globale du système, de l'entreprise; il ne voit généralement pas les liens avec son travail quotidien.

étape 3: Compétent

• il peut développer et utiliser des modélisations des problématiques et travailler par abstractions.
• il peut résoudre des problèmes qu'il n'a pas rencontré auparavant.
• on dit d'eux qu'ils font preuve d'initiative.
• il ne réfléchit pas ou peu sur ses méthodes de travail, ne rentre pas dans un processus d'amélioration continue.

étape 4: Spécialiste

• il ressent le besoin de comprendre la vue générale et les détails, la sur-simplification le frustre.
  
• il corrige ses erreurs.
• il apprend par l'expérience des autres, étudie des cas, des projets et prends ce qui peut améliorer son expertise.
  
• il comprends et applique des maximes, vérités essentielles "Fait le minimum qui peut fonctionner", "Ne te répète pas", "Teste tout ce qui peut casser", ...
• il sait utiliser les modèles de conception quand nécessaires (ce ne sont pas des recettes) et les adapter .
• il utilise les avantages de la réflexion et du retour d'informations qui sont au cœur des méthodes agiles

étape 5: Expert

• il cherche continuellement des nouvelles méthodes et manières de mieux faire les choses.
• il travaille par (bonne) intuition.
• il peut avoir du mal à expliquer ses choix: ils lui semblent "naturels".
• il distingue les détails futiles de ceux très importants.
  
• peu d'experts existent: certainement entre 1 et 5 pourcent de la population.
  

A noter qu' on peut être expert dans un domaine et totalement novice dans un autre.

Si le novice ne cherche pas à diversifier son expérience (ou ne suit pas de formation), il peut rester novice dans ce domaine quelque soit le nombre d'années d'activité. De même pour passer de débutant à compétent.

Nous tendons à penser que la plupart d'entre nous est au niveau "Compétent". Or il apparaît en pratique que la grande majorité est au stade "Débutant avancé".

Nous nous estimons aisément expert d'un domaine et sûr de nos choix lorsqu'on possède peu de compétences et connaissances de ce domaine. Un novice ne connaît peu ou pas les limites de son savoir. Plus on est expert, plus on doute, on se sent ignorant.

Cette citation (approximative) de Ghandi (je crois) me revient à l'esprit:
"Vivez comme si vous alliez mourir demain. Apprenez comme si vous étiez immortels."