THE TOYOTA WAY, JEFFREY K. LIKER

Après avoir lu plusieurs livres sur le Lean appliqué au développement logiciel, tels Lean Software Strategies, Implementing Lean Software Development et Lean Software Development, j'ai eu besoin de pousser plus loin ma compréhension de cette philosophie pour aider à sa pratique sur notre projet.
En insistant que le Lean s'apprenait par la pratique avec un mentor praticien et non dans les livres, Régis Médina m'a tout de même conseillé la lecture de The Toyota Way.

Le Toyota Way est la philosophie de gestion pratiquée par Toyota. Elle est structurée en 4 parties: la philosophie à long terme, le processus, collaborateurs et partenaires et la résolution des problèmes.

Nos années de pratique de l'eXtreme Programming, de Scrum et du Lean Software Development nous ont conduit à mettre l'accent sur l'aspect processus du Lean. Notre pratique s'appuie essentiellement sur les nombreux outils du Lean, tels le flux continu, le kanban, le jidoka, les andon, le heijunka, le management visuel, etc. Le dernier billet de Régis Médina révèle que nous ne représentons pas un cas isolé.

La lecture du Toyota Way nous a permis de comprendre que nous avions - non pas négligé - mais plutôt sous-estimé - les 3 autres facettes: la philosophie à long terme, les collaborateurs et les partenaires et la résolution des problèmes.

En réaction, nous sommes actuellement en train de travailler sur la résolution des problèmes. Sur ce thème, nous travaillons actuellement sur plusieurs axes en parallèle:

1. Rendre visibles les problèmes de l'équipe (voir billet);
   
2. Mettre en place une résolution systématique et structurée des problèmes (voir billet) ;
3. Animer régulièrement des chantiers d'amélioration de type Kaizen (billet à venir!);
4. Avec des praticiens qui enseignent le métier, pratiquer un leadership de terrain (billet à venir!).

A bientôt pour les billets annoncés!

CLEAN CODE, ROBERT C. MARTIN

J'avais énormément appris en lisant le précédant livre d'Uncle Bob, Agile Software Development: Principles, Practices and Patterns. Son catalogue des principes avancés de conception objet et ses métriques de couplage ont été une aide pour développer mieux.

Autant dire que j'attendais le livre suivant Clean Code, traduit en français sous le titre Coder Proprement.

Malheureusement, j'ai été déçu. Le livre est bien, mais j'ai appris bien moins qu'avec le précédant. Aussi, les chapitres rédigés par différents auteurs sont assez irréguliers en qualité. Voici la synthèse de ce qui m'a plu et de ce que j'ai appris.

QUELS SONT LES CRITÈRES DE QUALITÉ D'UN BON CODE?

Voici la définition qu'en donne l'eXtreme Programming:

Par ordre de priorité, le bon code respecte les critères suivants:

1. Il passe ses tests;
2. Il ne contient pas de redondance;
3. Il est explicite;
4. Il est minimal.

Malheureusement, l'auteur insiste peu sur le fait que les critères 3 et 4 peuvent être contradictoires et que l'ordre des priorités entre ces deux critères est très important. En effet, un code explicite tend à être plus modulaire et à être découpé en petites classes ayant chacune une seule responsabilité et en courtes opérations ayant un seul niveau d'abstraction. Ceci amène à plus de déclarations et donc à plus de code, ce qui s'oppose au critère 4.
D'ailleurs, dans tous les exemples de remaniement du livre, on constate que le code remanié est toujours 2 fois plus volumineux que le code d'origine! Cela ne me choque pas, mais je pense qu'il est important de le souligner clairement.

LIRE ET ÉCRIRE

Nous passons plus de temps à lire du code qu'à en écrire. En rendant le code facile à lire, nous le rendons plus facile à écrire.

LA RÈGLE DU BOY SCOUT

Lorsque nous ouvrons un fichier de code source, nous devons le laisser plus propre que nous l'avons trouvé.

LA LIGNE VIDE

Une opération ne doit pas contenir de ligne vide. Une ligne vide dans une opération sert à aérer son code en regroupant les instructions contribuant à une même action. Une ligne vide est donc un indice indiquant que l'opération passe à autre chose et qu'il y a plusieurs niveaux d'abstraction au sein de la même opération.
Alors, il plus cohérent d'exporter chaque groupe d'instructions contribuant à une même action dans une nouvelle opération nommée selon cette action et à appeler cette nouvelle opération dans l'opération d'origine. Ainsi, il ne reste dans l'opération d'origine que des instructions d'un même niveau d'abstraction.

LIRE LE CODE D'UNE OPÉRATION

Les étapes d'une opération doivent se trouver à un même niveau d'abstraction en dessous du nom de l'opération. Le code d'une opération bien écrite doit pouvoir se lire de la manière suivante:

POUR nom_de_l_opération IL FAUT première_étape_de_l_opération PUIS deuxième_étape_de_l_opération PUIS troisième_étape_de_l_opération PUIS ...

Les différentes étapes de l'opération sont des instructions du langage de programmation ou des appels d'opérations d'un même niveau d'abstraction.

CLASSES ET STRUCTURES DE DONNÉES

Depuis quelques projets, nous remarquons qu'il semble par endroit plus adapté d'écrire un code procédural plutôt qu'un code orienté objet. Est-ce une hérésie? Le constat suivant d'Uncle Bob m'a beaucoup rassuré.

Un code procédural (un code qui utilise des structures de données) facilite l'ajout de nouvelles fonctions sans modifier les structures de données existantes. Un code orienté-objet facilite l'ajout de nouvelles classes sans modifier les fonctions existantes.

Un code procédural complexifie l'ajout de nouvelles structures de données car toutes les fonctions doivent être modifiées.
Un code orienté objet complexifie l'ajout de nouvelles fonctions car toutes les classes de l'arbre d'héritage doivent être modifiées.

Par conséquent, ce qui est difficile pour l'orienté objet est facile pour le procédural, tandis que ce qui est difficile pour le procédural est facile pour l'orienté objet!

Dans un système, nous avons parfois le besoin d'une souplesse d'ajout de nouveaux types de données et choisissons alors une implémentation fondée sur les objets. Si nous voulons disposer d'une souplesse d'ajout de nouveaux comportements, alors nous optons pour les structures de données et les procédures.

Les programmeurs expérimentés savent très bien que l'idée du tout objet est un mythe. Les bons développeurs de logiciels abordent ces questions sans préjugé et retiennent l'approche adaptée à leurs besoins.

DES TESTS PROPRES

Le code de test est aussi important que le code de production. Il doit rester aussi propre que le code de production.
J'avais consacré un billet intitulé Les Tests Sont du Code à ce sujet et c'est d'ailleurs le thème du livre que je suis actuellement en train de lire : xUnit Test Patterns: Refactoring Test Code. Je reviendrai plus longuement sur ce livre car il améliore grandement ma pratique du test automatisé.

L'EVOLUTION DES SYSTEMES LOGICIELS

Les systèmes logiciels sont uniques si on les compare aux systèmes physiques. Leur architecture peut évoluer de manière incrémentale si nous maintenons la séparation adéquate des préoccupations (et le test de leurs constituants!).

SUR LA CONCURRENCE

Incroyable, deux chapitres du livre sont dédiés au développement de logiciels avec traitements concurrents! Malheureusement, il n'y a rien de bien nouveau. Néanmoins, c'est rassurant de lire des recommandations que nous appliquons déjà (voir mon précédant billet Extreme Programming Embarqué). Voici ces constats et recommandations:

La conception d'un système concurrent peut être très différente de celle d'un système monothread. Le découplage du quoi et du quand a généralement un impact très important sur la structure du système.

Gardez le code lié à la concurrence séparé de tout autre code. Ne tentez pas de pourchasser à la fois les bogues du code normal et ceux du code multithread. Assurez-vous que votre code fonctionne en dehors des threads.

CONCLUSION

Malgré quelques déceptions, je ne regrette pas la lecture de ce lire. Néanmoins, je conseillerais plutôt le livre précédant, bien plus enrichissant à mon avis.

THE ENTERPRISE AND SCRUM, KEN SCHWABER

En plus d'un an, nous avons beaucoup travaillé sur la mise en pratique de Scrum. Notamment, nous cherchons des solutions pour notre équipe qui monte encore en charge. Nous sommes dans le cadre d'un gros projet de développement.

Alors, je me suis beaucoup documenté sur Scrum et avec Nicolas Blanpain nous avons même effectué la formation certifiante ScrumMaster.

J'ai commencé par la lecture de Agile Software Development With Scrum puis de Agile Project Management With Scrum. Je viens de clore la trilogie de Ken Scwhaber avec The Enterprise And Scrum.

LA FOLIE DES GRANDEURS?

Ken a un sacré appétit. Il voit grand. De plus en plus grand.
Etape 1: Scrum permet de bien piloter un développement de logiciel (Agile Software Development With Scrum);
Etape 2: Scrum permet de bien piloter un projet. Scrum ne se limite plus au développement de logiciels. (Agile Project Management With Scrum);
Etape 3: Scrum permet de bien piloter une entreprise. (The Enterprise And Scrum).
La progression est notable.

AGILE WORLD MANAGEMENT WITH SCRUM?

Et bien, je dois avouer que la gestion d'entreprise avec Scrum m'a ennuyé. Je n'ai pas accroché. Je suis fan de Ken Schwaber et de son style mais il ne m'a pas convaincu. Je ne dois pas être la cible type de ces propos. Pour autant, je ne regrette pas la lecture de ce livre. Au lieu de m'étendre sur mes déceptions je vais me concentrer sur ce qui m'a plu.

QU'EST-CE QUI FREINE SCRUM?

Un chapitre est dédié aux comportements qui minimisent le retour sur investissement de l'application de Scrum. J'ai pu (malheureusement) reconnaitre dans mon expérience chacun des points identifiés. Je dois commencer à me faire vieux ... Notamment, j'ai bien reconnu l'engagement défiant les lois de la nature. Plus concrètement, une équipe identifie le restant à faire. L'équipe mesure et confirme sa vélocité sur plusieurs itérations. Mathématiquement, l'équipe voit qu'elle ne peut tenir le délai avec avec le contour souhaité par le client. Alors le management pousse à coup de "allez, on se retrousse les manches et on va réussir". Et bien non, on ne peut s'engager en défiant les lois de la nature. Cette attitude mène directement au point suivant.

LA DETTE TECHNIQUE

Dans ses conférences (chez Google et Agile 2006), Ken Schwaber explique comment une organisation peut accumuler une dette technique et se saborder en essayant d'être trop ambitieuse sur sa vélocité. Un chapitre du livre et consacré à ce sujet. En deux mots: l'équipe s'engage (ou est poussée à d'engager) au delà des lois de la nature. Pour tenir les délais l'équipe lâche sur ce qui ne se voit pas : la qualité. Cette réaction marche à très court terme. Par contre, à moyen et long terme la dette technique accumulée immobilise le développement.

SCRUM ET LES PRATIQUES TECHNIQUES

C'est le grand sujet du moment: Scrum n'est pas efficace sans l'ajout de sérieuses pratiques techniques. Ken Schwaber doit être lassé d'entendre cela car il insiste souvent sur le fait que tout incrément doit être potentiellement livrable. Cet objectif ne peut être tenu que si de solides pratiques techniques sont en place.

L'ORGANISATION DE GRANDES EQUIPES

J'ai retenu de bons conseils pour l'organisation de grosses équipes en petites sous-équipes Scrum. Pour minimiser les dépendances, les sous-équipes doivent produire des fonctionnalités orthogonales. Par contre, cela implique qu'aucune équipe n'est réellement responsable de la production d'un incrément de produit complet incluant toutes les fonctionnalités développées dans le sprint par les sous-équipes. C'est pourquoi Ken Schwaber recommande d'utiliser une sous-équipe Scrum chapeau ayant une vision produit complet. Cette équipe comprend le Product Owner du produit complet ainsi que toutes les compétences nécessaires pour transformer les fonctionnalités développées dans le sprint en un produit complet. Par exemple, cette équipe peut être responsable des moyens d'intégration et de recette du produit complet.

SCRUM POUR LES PRODUITS CRITIQUES

Dans le cadre du développement de logiciels critiques, Ken Schwaber recommande une pratique que nous appliquons déjà depuis plusieurs années. Chaque incrément doit être livré avec une traçabilité des exigences à jour.

EN CONCLUSION

Finalement, je pense avoir bien fait de lire ce dernier livre de la trilogie. Je vais essayer d'en appliquer certaines recommandations concernant l'organisation des grosses équipes. Par contre, je vais désormais me remettre aux livres abordant des sujets techniques! C'est parti avec le pavé sur le remaniement des tests xUnit.

PLANNING EXTREME PROGRAMMING, KENT BECK ET MARTIN FOWLER

Ce livre a été conjointement écrit en 2001 par Kent Beck et Martin Fowler et préfacé par Tom DeMarco. Cela fait trois grosses signatures pour un seul et même ouvrage.

LA GESTION DE PROJET

Les auteurs consacrent le livre à la planification et au pilotage d'un projet mené dans une démarche XP. Ils cherchent à montrer qu'en plus de pratiques techniques, la panoplie XP contient toutes les pratiques nécessaires et suffisantes pour planifier et piloter un projet.

XP + SCRUM OU XP?

On dit souvent que Scrum apporte aux pratiques techniques d'XP les pratiques de pilotage de projet et d'équipe. Ce livre tend à montrer que XP est déjà auto-suffisant pour la gestion de projet. La sur-couche Scrum ne fait que recouvrir avec son propre vocabulaire et ses rôles des pratiques pré-existantes dans XP. Ceci dit Scrum apporte plus de formalisme et de cérémonial, ce qui est une bonne chose à mon avis.

DE L'EAU DANS LE VIN

D'une manière générale, Martin et surtout Kent ont mis de l'eau dans leur vin. Dans ce livre, je trouve que l'aspect extrême d'XP est diminué. Déjà, en préface, les auteurs rappellent que XP n'est pas une destination mais un parcours. Une pratique conforme au livre d'XP doit servir à identifier ce qui dans la démarche doit être adapté au contexte du projet.

La durée de l'itération est devenue un sujet d'expérimentation. Le cycle hebdomadaire n'est plus une référence. L'essentiel est de rester en dessous du mois et de ne pas glisser!

De même, la pluridisciplinarité de chaque membre de l'équipe n'est plus encadrée par une rotation systématique des binômes sur toutes les parties de l'application. La spécialisation des développeurs est même encouragée à partir du moment qu'elle est liée à une motivation personnelle.

Aussi, les auteurs sont plus permissifs quand à l'existence de bugs dans le produit. La correction de bugs mineurs n'est pas nécessairement une priorité pour l'équipe.

Enfin, les auteurs sont moins impératifs sur la nécessité de développer les fonctionnalités de bout en bout. L'essentiel est désormais que tout ce qui est développé dans l'itération soit testé à la sortie de l'itération.

Personnellement je désapprouve le calcul d'une vélocité individuelle pour chaque développeur. Je suis peut-être un peu Bisounours, mais je ne vois pas comment cela peut rester compatible d'un esprit d'équipe efficace. Je préfère calculer la vélocité de l'équipe pour mesurer sa capacité de travail par itération et éventuellement diviser cette vélocité par le nombre de développeurs pour surveiller l'impact de l'intégration de nouveaux membres dans l'équipe.

Enfin, j'ai apprécié le désaccord entre Kent et Martin portant sur la priorité des fonctionnalités à développer. Kent accorde une plus grande priorité à celles qui apporte le plus de valeur au client alors que Martin accorde les plus hautes priorités à celles qui comportent le plus de risques. C'est le pilotage par retour sur investissement contre le pilotage par les risques.

EN CONCLUSION

Bref, si on connait déjà XP et Scrum, il ne me semble pas que la lecture de ce livre soit si importante. Par contre, si on croit que XP ne contient que des pratiques techniques, alors ce livre est une occasion de se détromper. Il se lit très vite gràce au style reconnaissable de Kent: une succession de petits chapitres de 2 ou 3 pages au plus.

SCRUM AND XP FROM THE TRENCHES, HENRIK KNIBERG

J'ai profité de la traduction en français de ce livre pour enfin le lire.

Loin de la théorie de Scrum, l'auteur décrit de manière très pragmatique son implémentation de la démarche en révélant plein de petits conseils pratiques.

Après avoir lu un ouvrage de Ken Schwaber, ce livre est idéal pour se faire une idée concrète de comment Scrum peut être appliqué au jour le jour. Étant déjà praticien, j'ai trouvé très intéressant de confronter nos pratiques à celles de Henrik. Aussi, dans la multitude de petit conseils pratiques, tout le monde trouvera bien un petit quelque chose à expérimenter sur son projet.

Les 150 pages se lisent tranquillement et agréablement le temps d'un week-end.

Merci à Emmanuel Etasse, Bruno Orsier et leurs compères pour ce travail de traduction. Le livre est gratuitement et légalement téléchargeable ici.

AGILE RETROSPECTIVES: MAKING GOOD TEAMS GREAT, par Esther Derby et Diana Larsen

Dans notre équipe, nous conduisons une réunion de rétrospective d'itération par mois, le dernier jour du sprint.
Je trouve que ces réunions ne sont pas évidentes à mener. Comment garder les participants concentrés? Comment amener chaque équipier à s'exprimer? Il faudrait que chaque participant ait le sentiment que le temps qu'il a accordé à la rétrospective serve l'équipe et le projet. Comment assurer ce retour ce investissement?

Je suis un grand fan de la collection Pragmatic Bookshelf. Les ouvrages My Job Went To India, Practices Of An Agile Developer, Pragmatic Project Automation, Ship It, et The Pragmatic Programmer m'ont beaucoup aidé à améliorer mes pratiques de développement ainsi que celles de l'équipe.

Alors, quand j'ai vu que la collection proposait un ouvrage sur la conduite des rétrospectives, je m'en suis procuré un exemplaire. J'attendais beaucoup de la lecture de ce livre d'autant plus que nous planifions une grande rétrospective de version en équipe élargie.

Et bien, sur plus d'une vingtaine de livres sur le génie logiciel, c'est la deuxième fois que je suis très déçu ...
Certes, le livre indique clairement et utilement quels sont les objectifs et les différents temps d'une rétrospective. Les auteurs donnent de très bons conseils sur la manière de préparer et conduire la réunion.
Malheureusement, la grande majorité du livre est un catalogue d'outils à utiliser en rétrospective. Ce devrait être une bonne chose - sauf que je ne vois pas notre équipe (pourtant TRES ouverte et innovante) en appliquer plus de deux ou trois. Il s'agit d'exercices très (trop?) anglo-saxons pour nous autres du vieux continent. Ces séances de travail en binômes, ces prises de paroles de type Alcooliques Anonymes et ces exercices proches de la psychothérapie de groupe ne me semblent pas (encore?) adaptés à notre approche du travail d'équipe.
Peut-être nous ne sommes pas assez ouverts? Peut-être nous prenons-nous trop au sérieux? Peut-être avons nous du mal à reconnaître la part des sentiments dans la vie professionnelle? Peut-être nous ne sommes pas encore prêts?

Toujours est-il que je ne recommande pas ce livre ...
Au prochain!

AGILE PROJECT MANAGEMENT WITH SCRUM, Ken Schwaber

Ce livre a été publié deux ans après Agile Software Development with Scrum (Ken Schwaber et Mark Beedle). Par rapport au premier livre, celui-ci insiste moins sur la théorie de Scrum pour donner davantage de cas d'application de la démarche.

Parmi les points que j'ai particulièrement apprécié dans ce livre, je citerai l'affirmation selon laquelle Scrum ne permet pas d'assurer qu'un projet se déroule comme prévu - par contre la démarche assure que le déroulement du projet suit une voie qui maximise la réussite.
Aussi, un des derniers chapitres donne des pistes pour appliquer Scrum sur des projets qui dépassent le cadre idéal de 7+/-2 développeurs dans l'Equipe. L'auteur présente comment monter en charge et comment gérer un grand projet.

PEOPLEWARE, Tom DeMarco & Timothy Lister

Si j'étais responsable de mon entreprise, j'offrirais ce livre aux managers et aux équipes. Je leur conseillerais avec insistance de le lire.
Certes, je n'ai pas l'impression d'avoir beaucoup appris, mais sa lecture m'as fait du bien pour deux raisons:

• le livre est drôle, ce qui est rare pour un ouvrage concernant le développement logiciel, et
• le livre met des mots clairs sur des impressions issues de mon expérience.

Le passage sur les bureaux, l'aménagement des locaux et la police du mobilier m'a bien fait rire d'autant plus que notre projet est actuellement en cours de déménagement. En effet, il existe des gens qui décident de l'organisation des locaux et de leur occupation alors qu'il n'ont aucune idée de la manière dont les gens travaillent!

Voici une petite sélection de vérités bonnes à retenir:

• Les projets de développement échouent très rarement pour des raisons techniques;
• Les principaux problèmes affectant les projets de développement sont d'ordre sociologique et non technique;
• Les managers promus managers savent comment le travail est fait - pas comment il faut le gérer;
• Plus le projet est risqué et plus il faut prendre le temps de réfléchir à la manière dont on travaille;
• Les gens "pressurisés" ne travaillent pas mieux - juste plus vite;
• Viser un très haut niveau de qualité est un moyen pour gagner en productivité;
• Les managers ne doivent pas faire travailler leurs équipes. Ils doivent permettre à leurs équipes de travailler;
• N'importe quoi peut être mesuré d'une manière plus bénéfique que ne pas mesurer (Gilb's Law);
• Pour réussir un projet, il faut prendre des gens compétents et motivés et adopter un style de management délégatif;
• Plus un processus est déterministe et moins il est adaptatif;
• Un standard doit être consigné à postériori, c'est à dire après avoir fait ses preuves;
• Le management par les objectifs individuels est destructeur pour l'efficacité des équipes (cf Deming);

LEAN SOFTWARE STRATEGIES, Peter Middleton et James Sutton

J'ai honte, mais je n'ai pas réussi à finir ce livre ... Cela m'arrive très rarement.
Ce n'est pas les 400 et quelques pages qui ont eu raison de moi, mais le style et la manière de traiter le sujet.

A mon goût, le style manque de fluidité et de simplicité. C'est peut-être un objectif ambitieux pour un livre sur le développement logiciel, mais certains auteurs y arrivent très bien - comme Martin Fowler, Kent Beck, Andy Hunt ou Mary Poppendieck.

Enfin, j'ai trouvé la démarche trop théorique et analytique. Il manquait le pragmatisme pourtant si cher aux américains.

Néanmoins, j'ai appris plusieurs choses très utiles:

• Le livre décrit très clairement les 5 piliers du Lean (value, value stream, flow, pull & perfection);
• Les caractéristiques des modèles industriels de l'artisanat, de la production de masse et du Lean sont décrites et comparées.
  
• La démarche d'amélioration continue du CMMi est comparée à celle du Lean. Cette partie m'a beaucoup intéressé car elle a mis des mots sur des choses que je ressentais (suite à un audit CMMi), mais que je n'arrivais pas à formaliser. J'écrirai un billet sur cette comparaison.
  

Bref, si vous souhaitez lire sur la transposition du Lean au développement logiciel, je vous conseille plutôt les 2 très bons livres de Tom et Mary Poppendieck:

• Lean Software Development, et
  

• Implementing Lean Software Development
  

VERS LES METHODES AGILES

Ce livre est une bonne synthèse de ce qui se pratique en terme de gestion de projet Agile.
On trouve un bon comparatif des différentes démarches Agiles les plus répandues. En fil continu, l'auteur compare la démarche classique et prédictive de gestion de projet par rapport à la démarche empirique propre aux méthodes agiles.
Il y a notamment un bon chapitre sur la gestion de l'équipe où l'auteur insiste sur la différence entre le chef de projet directif et le facilitateur.
Le discours est ponctué de nombreuses interventions de coachs francophones connus: Laurent Bossavit, Régis Médina, Dominic Williams, Claude Aubry ...

THE MYTHICAL MAN-MONTH, de Frederick P. Brooks, Jr

A force de voir ce livre cité en bibliographie de mes lectures, je me suis enfin décidé à le lire.
J'avoue que j'étais très curieux. Comment un livre sur le développement logiciel peut-il être autant référencé - après trente ans de parution?
Cette nouvelle édition contient quatre nouveaux chapitres, dont le fameux article "No Silver Bullet".

J'avoue avoir été un peu déçu, car je trouve que certains chapitres ont mal vieilli. Après tout, rien de plus normal : il s'en est passé des choses en trente ans de développement informatique et logiciel!

Par contre, certains passages restent vraiment brillants. Le fameux chapitre intitulé "The Mythical Man-Month" est absolument génial. On se régale de la nature optimiste du programmeur, on constate la confusion entre effort et avancement, on reconnait que l'effort de communication croit avec le nombre de développeurs et que le mois-homme n'a rien de linéaire. On retiendra la loi de Brooks:

Adding manpower to a late software project makes it later.

J'ai également adoré le chapitre "Why did the Tower of babel Fail?". L'auteur constate la si grande importance de la communication et d'une organisation souple et adaptative pour les projets de développement logiciel.
Dans le chapitre "The Documentary Hypothesis", j'ai adoré la si pertinente loi de Conway:

Les architectures sont à l'image des organisations qui les crééent.

C'est si vrai! Et la suite est fabuleuse:

On constate que la première architecture est invariablement pas la bonne. Que faut-il en déduire sur l'organisation qui l'a créé (à son image)?

Bref, pour une architecture adaptative il faut prévoir une organisation adaptative. Enfin, j'ai retenu:

How does a project get to be a year late? ... One day at a time.

Dès 1975, tout ceci et plusieurs références au pilotage par les tests nous amène déjà vers le développement logiciel Agile!

AGILE SOFTWARE DEVELOPMENT WITH SCRUM, by Ken Schwaber and Mark Beedle

I read this book to improve our current practices, which are already very close to Scrum.
I particularly appreciated:

• the emphasis on continuously removing impedents to effective work;
• the tips to deal with scaling projects, organizations and teams;
• the comparison between organizations and software. Organizations must emerge and grow in increments, just like software.
• add all tasks to the backlog, not only the functional requirements. However, each Sprint must contains a functional increment.
• the fact that requirements remain complicated even if they are understood by the domain and business analysts as long as they are too complicated for the developpers.

However, I do not agree with the fact that code is own forever by the programmer who wrote it. I prefer the collective ownership approach of eXtreme Programming.
Also, I still find that 30 calendar day Sprints are too long ... I prefer shorter iterations, mostly because of the the queueing theory. Smaller items go faster in the workflow. I believe a project will be faster completed if it is managed into shorter iterations.
But, I do really recommend this book. It made me want to read Agile Project Management With Scrum, also written by Ken Schwaber some years later.

PRAGMATIC PROJECT AUTOMATION, Mike Clark

This book explains step by step how to automate builds, tests, continuous integration, release, installation and monitoring of software.
The examples are given for Java applications, using tools such as ant, JUnit and CruiseControl on a Unix platform.
However, the advice may (must?) be set into practice for other languages and using other tools.

THE PRAGMATIC PROGRAMMER, by Andrew Hunt and David Thomas

This books exposes lots of great advice. It is a sort of catalog of tips and pragmatic practices.

I was really glad to read a book where the authors insist so much on Design By Contract, the interest of Crashing Early and the wise use of Assertions. Among all the books I have read, few deal with these effective practices.

The authors insist alot on the DRY principle: Don't Repeat Yourself and on the absolute necessity to reduce coupling and dependencies.
Great advice!

I RECOMMEND THIS BOOK.

IMPLEMENTING LEAN SOFTWARE DEVELOPMENT, by Mary and Tom Poppendieck

This is a GREAT book!

I appreciated LEAN SOFTWARE DEVELOPMENT, AN AGILE TOOLKIT so much a I had to read the next sequel.

I was glad to have read the first sequel before the second, as the second assumes the first is read and understood, and as there is no duplication between the sequels.

Reading this book wasn't pure pleasure. Indeed, it helped me realize the extend of improvement to perform in my organization. The waste and suboptimization is revealed and is now difficult to tolerate. This should be encouraging, but the book reveals some improvements are way out of control of a development team. It implies the full value stream. This is where the book may become quite discouraging: can you extend the improvements out of the development team? In a big corporate company, this can be more than a challenge...

Among many other things:

I learned that defects waiting in a list are waste, as they are unfinished work and hide other potential bugs.

I really enjoyed the part saying that tests are there to prevent bugs, not find them.

I understood that our practice of design by contract with assertions was a great way to implement the "stop-the-line" culture and to build mistake-proof code.

I learned A LOT on the use of slack to speed-up the time inside a process.

I recognized what I experienced through a CMMi certification.

I RECOMMEND THIS BOOK.

DESIGN PATTERNS EXPLAINED, Alan Shalloway and James Trott

I really enjoyed the way the design-patterns are brought into the code to solve a current problem.

This book helped me understand some patterns, like Bridge for example.

DESIGN PATTERNS, Gamma, Heml, Johnson and Vlissides

This is a must read. I didn't manage to read it in one-go. I haven't even read it all. I find this book hard to read, sometimes hard to understand - but full of great information. I use it as a reference manual, or a catalog.
What I put into practice:
+ Singleton;
+ Facade;
+ Mediator;
+ Observer;
+ Abstract factory;
+ Template method;
+ Adapter;
+ Responsability chain;
+ Proxy;
+ Command;
+ State;
+ Strategy;
+ Visitor;

UML2 ET LES DESIGN-PATTERNS, Craig Larman, Pearson Education

I read this book some years ago.
I enjoyed the GRASP analysis patterns and the lightweight modelling the author uses.
What I put into practice:
+ lightweight modelling using UML.

SHIP IT! by Jared Richardson and William Gwaltney Jr, The Pragmatic Programmers

Another great book from The Pragmatic BookShelf.

When I received the book, I was a little afraid as it is rated for readers having a skill range from beginner to medium.

Finally, I found great insights - very well explained.

What I put into practice:

+ We added a cross-platform build to our one action build;

+ I plan to build a smoke test for our current project;

+ We configured our Continuous Integration tool to send build and change notifications by eMail to the team-members.

I RECOMMEND THIS BOOK.

C++ CODING STANDARDS. 101 RULES, GUIDELINES, AND BEST PRACTICES, Herb Sutter, Andrei Alexandrescu

This book is full of great advice - even if you don't code in C++! I read it in parallel of a one-week training session in advanced C++. The training sessions contents and the books chapters matched quite precisely. It enabled me to put a name on a coding "pattern" I was unsing on my project: the Non Virtual Interface (NVI). Coupled with a design-by-contract practice (refer to Bertrand Meyer) implemented in code through assertions, this pattern can really improve your code.

What I put into practice:

+ NVI pattern.

+ Pimpl idiom.

+ RAII idiom.

I RECOMMEND THIS BOOK, EVEN IF YOU DON'T PROGRAM IN C++.