Il commence d’ailleurs son livre en nous expliquant la façon dont il a été conçu, c’est-à-dire de manière agile, et donc en nous encourageant à lui fournir un retour afin qu’il puisse l’améliorer.

L’existence de ce billet implique que cette explication atteint parfaitement son objectif, en plus d’humaniser l’ouvrage puisque Thierry nous explique en prime ce qui l’a poussé à se lancer dans l’écriture de ce livre et le chemin qu’il a suivi pour parvenir à sa publication.

Cette humanisation se poursuit d’ailleurs dans les deux chapitres suivants, Thierry nous y expliquant dans le premier le rôle du « product owner » tandis qu’il pose les bases d’une mise en application de l’agilité en terme fonctionnel dans le cadre d’un cas pratique théorique.

Mais malheureusement, son discours devient beaucoup plus académique dans les chapitres suivants, et je le regrette.

En effet, je pense que la transmission de son message aurait été beaucoup plus efficace s’il s’était servi de cette base de départ pour illustrer au moins une partie des concepts présentés par la suite de son livre, sinon la totalité.

Ainsi, la digestion de cette masse d’information serait certainement plus facile et accessoirement favoriserait potentiellement sa mémorisation en offrant des repères mnémoniques.

Cela ne veut cependant pas dire que les chapitres suivants sont pour autant inintéressants, bien au contraire.

Le vocabulaire agile relatif à l’aspect fonctionnel du développement d’un logiciel est parfaitement expliqué, associé à une dose pertinente de concept psychologique relatif à la communication dans le cadre d’un groupe.

Malheureusement, les références illustrant ces concepts sont bien souvent succinctes, mais je pense avoir été handicapé à ce sujet par le fait que je n’utilisais pas la version numérique du livre qui doit, contrairement à la version papier, contenir des liens vers les articles correspondants.

Les chapitres relatifs à la « valeur métier » ainsi qu’à la « vision » du produit sont ceux qui m’ont le plus interpellé, et pas uniquement parce que dans mon contexte de l’époque, ces deux concepts étaient complètement ignorés.

En effet, d’après ce que j’ai pu constater au cours de ma carrière ou des discussions que j’ai pu avoir à ce sujet, les développeurs savent bien souvent plus ou moins approximativement ce qu’ils doivent faire, mais ne savent en général pas pourquoi ils doivent le faire. En clair, ils n’ont que trop rarement connaissance de l’objectif que leur travail est censé permettre d’atteindre à un niveau plus global (bien souvent parce que le client n’en a lui même qu’une vague idée, mais c’est un autre débat).

Or, je suis persuadé qu’un développeur doit savoir à la fois ce qu’il doit faire et pourquoi il doit le faire afin de pouvoir trouver dans la combinaison de ces deux informations la motivation pour sortir de sa zone de confort, se surpasser, évoluer et ainsi ne plus être juste un « pisseur de code » bête et méchant.

Ainsi, le client y trouve son compte, car son produit répond mieux à ses besoins et le développeur gagne en compétence et en estime de soi, car il sait à la fois à quoi et comment il a contribué.

Et enfin, la vision peut permettre aux développeurs de résoudre leur problème en plus d’être pour eux un redoutable outil d’aide à la décision.

Ainsi, si la vision du produit met en avant la performance, ils choisiront les technologies qu’ils mettront en œuvre en conséquence, et lorsqu’un consensus ne peut être atteint au sein des développeurs sur un point ou un autre, se référer à la vision peut permettre de dénouer la situation en remettant les choses en perspective par rapport à l’objectif à atteindre.

Il est donc important que les fonctionnels et les développeurs disposent d’une vision commune du produit correspondant à celle du client, et Thierry insiste donc à juste titre sur ces deux notions bien souvent trop occultées durant la vie d’un projet.

Et pour le coup, j’aurais trouvé très pertinent d’illustrer à minima ce chapitre relatif à la vision à l’aide du cas pratique mis en place dans le second chapitre.

J’ai également aimé que Thierry évoque dans son ouvrage la problématique de la prise de décision et présente une méthode permettant d’y parvenir en y impliquant tous ceux devant y prendre part, tout en n’occultant pas le fait que cela n’est pas simple pour autant, tant s’en faut.

Au passage, pour ceux que la problématique de la prise de décision intéresse, la conférence d’Olivier Sibony à ce sujet est remarquable.

L’un dans l’autre, j’ai donc trouvé mon compte en lisant le livre de Thierry, et je ne peux donc qu’en recommander la lecture aux développeurs ou aux fonctionnels qui veulent améliorer leur façon de travailler avec « celui d’en face », qu’il soit développeur ou fonctionnel, ne serait-ce que parce qu’il permet à un développeur de mieux comprendre les contraintes et la façon de travailler d’un fonctionnel dans un tel contexte, et réciproquement.

En effet, si la forme du livre serait à mon avis beaucoup plus agréable si l’ambiance des deux premiers chapitres était propagée aux autres, reste que son fond est plus qu’intéressant puisqu’il propose des solutions et des pistes à suivre pour résoudre des problèmes que l’on rencontre communément lorsque l’on développe un logiciel.

Alors, à 23 € ou à partir de 7 € au format numérique, faites-vous une faveur, offrez ou offrez-vous Spécifiez agile  (et non, ce billet n'est pas sponsorisé) !