Ce matin en arrivant à sont travail à 09h00 pile, Paul s’est assis devant son poste de travail et a commencé à regarder ses mails. 30 minutes plus tard, il s’est levé pour aller prendre son café et discuter un peu avec ces collègues des résultats de Roland-Garros. A 10H, il revient à son poste et trouve Éric, son binôme, en train de lire une portion de code. Il s’assoie à coté de lui et commence à trier un peu ses papiers.

Jean-Pierre : Dans quel arrondissement de Paris se trouve le Parthenon ? Joueur : 5 ème Jean-Pierre : C’est votre dernier mot ? La culture, c’est comme ça, quand on ne connaît pas la réponse, la question parait très difficile, alors que si l’on sait, elle parait évidente. C’est ce qu’on pourrait appeler l’”effet contraste”. Mais avant de continuer, voyons un peu les différentes réponses que le joueur aurait pu donner : - comme ici, il a pu choisir un arrondissement au hasard (mais il doit pour cela connaître le nombre d’arrondissements parisiens, pour ne pas répondre 32 ème !

par Geoffrey A. Moore. Edition HarperBusiness Essentials Je crois qu’on pourrait dire que XP1 est une innovation discontinue (pardon si j’enfonce des portes ouvertes). La solution : trouver une niche, un segment de marché… Où est la niche ? Je suis très enthousiasmé par XP et j’aimerais pouvoir pratiquer plus cette méthode. Je rêve d’un monde où je puisse mettre sur mon CV “praticien XP” et qu’on me recrute pour ça en pleine connaissance de cause.

par Tom DeMarco et Timothy Lister. Edition Dorset House Reflexions trés interessantes sur la productivité des équipes de développement logiciel.

Je voudrais ajouter quelque chose d’autre au sujet de ma première remarque, sur le fait qu’il est difficile de faire comprendre la méthode Extreme Programming aux développeurs. Je crois que le frein principal est la peur. La peur de ne pas y arriver. Les développeurs d’un projet ont très souvent peur de ne pas savoir faire ce qu’on leur demande. Peur de ne pas finir à temps. C’est aussi cette peur qui fait qu’on bâcle le travail ou qu’on prend des raccourcis comme de copier-coller une section de code plutôt que de se poser la question du design.

Anne : Ho non, l’ordinateur ne marche plus. Etienne (depuis la salle de bain) : qu’est ce qui ce passe ? Anne : y plus rien qui marche. Etienne (depuis la salle de bain) : qu’est ce qui ce passe, vraaaiment ? Anne : Can’t reach P.O.P.3 server, contact your administrator… Etienne (Depuis la salle de bain, rassuré de savoir que l’ordinateur démarre en fait) : J’arrive, mais apparemment, ce n’est pas de ma faute pour une fois.

Par Joshua Bloch, édition Vuibert Ouvrage de référence, indispensable.

Par Kent Beck, édition Addison-Wesley Incontournable pour qui veut apprendre à faire des tests unitaires de façon efficace et productive.

1. Quel est l’objectif de la documentation ? Quand on travaille dans un labo de R&D, on ne côtoie que des cervelles en ébullition. Notre métier est de penser. Comme le dit Tom Demarco1 nous sommes des « Knowledge Worker ». A ce titre, nous pouvons prendre l’habitude de réfléchir sur la forme et l’utilité des différentes pratiques qui constituent notre « process » de travail. Pourquoi faisons-nous de la documentation ?

Par Tom Demarco, édition Hardcover DeMarco étudie les grands défis que rencontre la plus part des entreprises qui produisent du logiciel : aggressive schedules, expected overtime, change management, motivating employees, et risk management…