3 décennies de « book of the decade »

J’ai posté il ya quelques jours une liste de mes “book of the year”. Voici une autre liste que j’entretiens: les “book of the decade”

Quels sont les livres qui ont vraiment fait changer votre façon de voir votre métier ? ceux qui ont réellement fait évoluer vos pratiques et peut-être même votre carrière ?

En découpant par tranche de 10 ans, j’ai relevé un livre qui fut chaque fois marquant. J’ai bien un peu triché dans mon découpage, mais que diantre: ce sont MES “books of the decade” ! On retrouve ces titres dans la liste des “book of the year”. C’est assez logique, mais en fait ce n’est pas un critère !

1981-1990 : Gödel, Escher, Bach: Les brins d’une guirlande éternelle – Douglas Hofstadter – InterEdition

1991-2000 : Design Patterns, Elements of reusable object oriented software – Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides

2001-2010 : Extreme Programming Explained: Embrace Change – Kent Beck – Addison Wesley

La quatrième décennie a déjà commencé. Rien n’émerge, mais il me reste 9 ans pour trouver cette perle rare.
Publicités

Note de lecture : Balancing Agility and Discipline, A guide for the perplexed par Barry Boehm & Richard Turner

Note : 6 ; Une vue pragmatique et construite du processus combinant les les avantages des approches agiles et planifiées.

Il était temps qu’un auteur dépasse le cantonnement des approches prescritives et agiles, chacune prétendant sauver le monde avec sa propre vision intégriste du processus. Boehm et Turner analysent avec beaucoup d’acuité les avantages et faiblesses de chacune des approches (dont ils ont une bonne connaissance), et font une analyse assez correcte des bénéfices que l’on peut tirer de leur combinaison, comment le faire et en quelles circonstances. Cela est illustré par 2 cas d’études « avant et après » sur des projets destinés à être soit plutôt agile, soit conduit par un plan.

Il reste à espérer que cette première pierre soit le début d’une tendance où l’ouverture d’esprit dominera sur l’esprit partisan. En ce qui me concerne, j’avoue y porter un réel intérêt. Néanmoins, l’ouvrage en lui-même est un peu frustrant, car les 160 pages du texte principal ne font guère office que d’introduction à cette approche convergente. Certains outils proposés comme le « home groud polar chart », ou le « sweet spot chart », sont assez intéressants, mais je suis plus perplexe face à la « risk based method », destinée à déterminer la combinaison d’agilité et planification à appliquer.

On notera également le volume particulièrement important des annexes (70 pages). Cela reste insuffisant pour conseiller sans réserve cet ouvrage qui renferme cependant un incontestable savoir-faire.

balancing-agility-discipline

Référence complète : Balancing Agility and Discipline, A guide for the perplexed – Barry Boehm & Richard Turner – Addison Wesley 2003 – ISBN: 0-321-18612-5

Balancing Agility and Discipline: A Guide for the Perplexed


http://www.goodreads.com/book/add_to_books_widget_frame/0321186125?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Réponse à « Test-Driven Development: un pacte diabolique »

On a attiré mon attention il y a quelque temps sur un article présentant les tests comme un “pacte diabolique”. Ce texte, accessible ici a été publié par le théoriquement très sérieux “Comité Français des Tests Logiciels”.

Imbécile un jour, imbécile toujours ?

Après le pathétique papier publié par Anne Aussem dans le Journal du Net, voici un nouvel exemple d’article diffusant de fausses vérités. Mauvaise foi ou manque d’information ? Je constate simplement qu’avec la rapide diffusion de l’approche agile ce genre d’article de désinformation se multiplie. C’est clairement un phénomène récent, on n’en voyait pas trace il y a quelques années. S’agit-il en d’une stratégie de défense de la part des promoteurs des approches classiques ?

De toute manière, seules deux raisons peuvent amener à commettre un tel texte: (1) la stupidité ou (2) la désinformation volontaire. Je vais partir du principe que l’auteur est honnête, ce qui me dirige vers l’hypothèse (1). Qualifier cela de stupidité peut sembler fort, mais pour moi pour attaquer un sujet, il faut commencer par être bien informé (je vais bientôt revenir là-dessus). Ce n’est clairement pas le cas ici. Avant de développer, je livre aussi deux petites réflexions:

  • Avec l’article d’Anne Aussem, je pensais que notre cher pays était déjà bien équipé en imbéciles (une idée en fait antérieure à l’article en question). Drôle d’idée d’avoir en plus besoin d’un produit d’importation…
  • L’auteur fait valoir son doctorat et sa chaire de professeur. Cela confirme une conclusion à laquelle j’étais arrivé depuis longtemps: le diplôme n’est pas synonyme d’autorité et de qualité. C’est aussi une conclusion rassurante. Par ailleurs faire valoir sa notoriété voir son autorité dans la signature d’un article hausse le niveau d’exigence que l’on peut avoir par rapport au texte. Ce texte n’est pas digne d’une chaire de professeur. Il n’est pas digne de grand chose, en fait. Voyons cela.

TDD, un processus ?

Ma première remarque concerne l’appellation “processus TDD” employé par l’auteur. TDD n’est pas un processus, mais une pratique. Une technique faite pour améliorer certains aspects du développement logiciel, à savoir s’assurer que le code écrit fonctionne bien suivant l’intention de l’auteur. C’est une technique qui vient en compléter d’autres venant du monde agile, comme les “acceptante tests”, le pair programming, etc… et pourquoi pas d’autres issues de l’ingénierie classique. On parle bien de pratique, donc de quelque chose qui est mis en oeuvre conjointement avec d’autres choses. TDD n’impose rien d’autre. Et même si TDD est souvent associé avec d’autres pratiques comme les “user stories” et le “refactoring”, le fait qu’il y ait des facteurs convergents (surtout avec le refactoring) n’en font pas des éléments obligatoires de la mise en oeuvre de TDD !

Ainsi non seulement cette première section diffuse une contre-vérité, mais la figure (1) est également fausse: on écrit pas un ensemble de cas de tests avant de coder la tâche, mais on écrit UN cas de test, puis du code, puis du refactoring si nécessaire, puis UN nouveau cas de test, etc. (cf “Test-Driven Development” par Kent Beck).

Viennent ensuite les fameux 12 points.

La montée en échelle de TDD

Comme je l’ai dit, TDD est une pratique en elle-même. Si pour un projet de grande taille ou critique, l’approche User Stories ne semble pas la bonne (bien que contrairement à l’affirmation de l’auteur, les user stories puissent être gérées de manière hiérarchiques cf “Scaling Lean & Agile Development” par Larman & Vodde), utilisez-en une autre mieux adaptée à votre contexte. Cela n’empêche pas de faire du TDD ! Non, car TDD est fait pour tester le code que l’on écrit.

Les pratiques et outils à utiliser sur un projet doivent être adaptées au contexte du projet. En fait de nombreux outils existent dans la boite à outil agile (epics, story map, release plan, design session, 5 niveaux de planification, requirements area), mais on peut aussi aller les chercher hors de l’univers agile. Et on peut toujours pratiquer TDD dans tous les cas ! L’approche agile nous apprend surtout à nous adapter et à utiliser ou ne pas utiliser certains outils en fonction du contexte. Bref, elle nous apprend à travailler avec notre intelligence, un concept visiblement étranger à l’auteur. Exit le point numéro 1.

Une (avant) dernière chose, pour ce qui est des applications critiques: TDD est la seule pratique, à ma connaissance, qui garantit que du test pertinant correspondant à du code. En effet avec TDD vous n’avez pas le droit d’écrire du code si le test correspondant n’existe pas préalablement. A ce titre, TDD devrait être une pratique obligatoire lors du développement des systèmes dits critiques, n’est-ce pas ?

Enfin, bien sûr, Mr Jorgensen a raison quand il dit qu’il y a une limite à ce qu’un développeur peut garder à l’esprit à un moment donné. C’est un des points que TDD traite avec succès: quand on développe quelque chose, on se focalise dessus avec le test accompagnant la chose. Une fois terminé, je peux l’oublier ! Si par malheur ce que je fais ensuite impact une réalisation précédente, mes tests vont me le rappeler en échouant. Je n’ai pas besoin de garder à l’esprit les dépendances entre objets ou fonction, mes tests unitaires font cela à ma place. Au contraire de l’affirmation de l’auteur, sans TDD je serais obligé de tout garder à l’esprit !

Comment TDD traite-t-il de la complexité applicative ?

Ah ! Je vais devoir rappeler que TDD n’est pas un processus, n’est-ce pas ? Il y a en fait plusieurs points à adresser ici.

Le premier points concerne la façon dont TDD adresse effectivement la complexité applicative: elle ne l’adresse pas. Ce n’est pas son rôle. Mais il y a de nombreux éléments de projet qui n’adressent pas la complexité applicative. Le document de Vision (ou elevator statement, quel que soit le nom que vous lui donnez), il n’adresse pas la complexité applicative, est-il mauvais pour autant ? Mais je vais revenir sur ce point en parlant d’une autre pratique: le refactoring.

Le second point concerne la matrice d’incidence dont l’auteur semble friand. Je connais un peu ce genre de technique, avec UML nous appelions cela des “use case realizations”. J’avoue que d’un point de vue intellectuel et académique, ce genre de référentiel croisé est très attrayant. C’est sans doute pour cela que je me suis efforcé de mettre cela en oeuvre, il y a une douzaine d’année. Finalement sans grand succès, hélas. Ce genre d’approche souffre de deux ou trois faiblesses:

1 – Avoir une matrice juste et à jour est un vrai challenge. On est toujours en retard sur le développement, pour autant que l’on soit juste ! Il faut sans relâche traquer l’évolution du développement pour être à jour.

2 – Difficulté d’automatiser cette matrice. Ce point fait suite au précédent. Mais à mon avis le seul moyen d’être à jour est de faire en sorte que ce genre de matrice s’entretienne automatiquement à partir du code. Hélas en l’absence de lien formalisé entre le code et les cas d’utilisation, ce n’est guère possible. Ce genre de lien se matérialiserait très bien à l’aide de tests d’acceptante automatisés (ATDD), mais visiblement le TDD, c’est l’antre du mal, donc oublions…

3 – Ca ne sert à rien. Certes les matrice éparses permettent de constater un design “diffus”. mais c’est juste une constations, qui intervient après coup. Idéalement il faudrait alors corriger le tir … en refactorant. Oui mais, en l’absence d’un harnais de sécurité mis en place grâce aux tests, c’est bien trop dangereux !

En fait, la boite à outil agile offre d’autres outils pour traiter cette fameuse complexité applicative. Ce sont juste des outils complémentaires de TDD ! Et finalement, si vous aimez les matrices d’incidence et pensez qu’elles peuvent apporter à votre projet: faites-les ! Il n’y a aucune contre-indication avec TDD !

Comment TDD traite-il la compréhension du système ?

Un petit éclaircissement d’abord: l’auteur amène ici les termes “projet TDD” et même “projet purement TDD”. Une telle chose n’existe pas. TDD est une pratique, parler de “projet TDD” est vide de sens.

TDD n’a pas pour objet de documenter un système de manière globale. Il a le double objectif de tester le code lui-même et de le documenter par l’exemple.

Contrairement à une croyance largement répandue, les projets agiles ne sont pas réfractaires à la documentation (cf “agile modeling” de Scott Ambler, ou “agile documentation” d’Andreas Rüping). Mais ils mettent l’accent sur la documentation “juste à temps” dont l’écriture vient d’un besoin de transmettre un niveau de compréhension du système ou d’éclairer un aspect particulier du système. Il est vrai que l’on ne réalise pas un type de document simplement parce que cela est demandé par la méthode. Au final, ce type de documentation (comme les documentations “générées”) finissent par être des documents en “write only”.

L’approche agile nest pas non plus hostile aux commentaires dans le code, à certaines réserves près:

  • Un commentaire ne doit pas être une excuse à du code mal écrit et difficile à lire par lui-même. Il faut toujours privilégié le code clair. Si celui-ci se lit naturellement, alors cela diminue ou élimine la nécessité d’écrire un commentaire à ce sujet. A ce titre, on peut souvent considérer la nécessité d’écrire un commentaire comme un aveu d’échec à l’écriture d’un code clair !
  • Le commentaire ne doit pas paraphraser le code ! Il doit apporter une information et un éclairage particulier.

Le commentaire amène avec lui un danger réel: celui de ne pas être à jour par rapport au code auquel il s’adosse ! En fait, en plus de 30 ans, je n’ai jamais vu, même sur les projets les plus disciplinés, un commentaire qui n’était pas, à un moment donné et/ou à un endroit particulier, divergent ou en retard par rapport au code. C’est un danger pour le mainteneur car il sera induit en erreur.

Un nommage et un design clair, de bons tests unitaires sont une forme de documentation qu’il faut privilégier. Ils ne mentent jamais et ne sont jamais en retard par rapport au code. jamais. Les développeur aguerris à la technique des tests unitaires prennent l’habitude de s’appuyer sur ceux-cis pour comprendre le code qu’ils abordent. 

Il y a-il une quelconque garantie que les cas de tests développés dans le processus TDD constituent réellement un bon test ?

Là encore, ce point en couvre plusieurs.

1 – Quelle garantie a-t-on qu’un test est vraiment un bon test ?

En fait, cette question est une bonne question ! Une réellement bonne question ! mais vous aurez  peut-être remarqué que j’ai volontairement omis la partie “TDD” dans ma reformulation ? En effet cette question se pose autant aux tests TDD qu’aux autres ! Répondons à ce premier volet complètement éludé par l’auteur

a) La pratique du “pair programming”.

Contrairement à l’idée parfois admise qu’une personne super-compétente sera quasi infaillible, la communauté agile a développé ses pratiques sur l’idée que nous sommes tous faillibles, mais que ces failles se trouvent compensées ou évitées en travaillant ensemble (cf “Pair Programming Illuminated” par Williams & Kessler). L’une des pratiques mises en oeuvre est le travaille en binôme. La revue de pair est considérée comme l’une des méthodes de vérifications les plus efficaces (cf “Peer Reviews in Software, a pratical guide” par Karl Wiegers). Pour donner à cette technique le maximum d’efficacité, le pair programming propose de faire de cette activité une pratique systématique et continue, qui s’applique à l’écriture de code et de tests ! Ce n’est pas une garantie, mais cela s’en rapproche

b) Des “workshop” de cas de tests.

Il ne s’agit pas en soi d’une pratique agile largement documentée, mais d’un exemple de mise en oeuvre que l’on peut imaginer mettre en oeuvre sur un projet agile. C’est une chose que j’ai fait en pratique. L’idée est la suivante: sur la base de besoins exprimés on réunit un petit commando regroupant différentes facettes du projet: développer, équipe de validation, utilisateur, analyste, etc… Ce petit groupe produit, par le biais de discussions et contradictions un semble de cas de tests passants et non-passants. la présence de points de vue différents permet de combler les lacunes inhérentes à une vision partielle du projet !

c) Des testeurs dans l’équipe de développement.

Les équipes agiles font grand cas de la polyvalence des membres qui composent l’équipe. Cela ne signifie pas que l’on ne puisse avoir recours à des experts. Le test du code via TDD ne constitue qu’une partie des tests que l’on va appliquer au logiciel développé. L’une des mantra des approches agiles est d’avoir du feedback le plus tôt possible. Le test est une forme de feedback, on s’évertuera à avoir ce feedback au plus tôt en incorporant les testeurs à l’équipe de développement (cf “Agile Testing” par L. Crispin & J. Gregory) qui travailleront en étroite collaboration pour développer et outiller les tests nécessaires.

2 – Qu’en est-il des différents niveaux de tests ?

TDD, comme son nom l’indique se focalise sur le test du code, donc le test “boite blanche”. Cela ne signifie pas que l’on effectue pas d’autres types de tests sur les projets agiles. Non seulement ils sont fait, mais d’une manière générale mieux faits que sur des projets classiques. Pour développer ce point, il me faudrait évoquer une autre pratique (la 4ème de ce papier, je pense): l’intégration continue. En intégration continue, le logiciel est construit de manière continuelle, à chaque “commit” dans le gestionnaire de source, et les tests automatiques (que ce soient des tests unitaires ou non) sont exécutés à la suite. Fini d’attendre de long cycles d’intégration pour savoir ce qui va mal ! A chaque changement, on obtient un feedback presque immédiat !

Revenons un moment sur les différents types de tests. Hélas, je ne suis pas un spécialiste de la taxonomie des tests, mais je vais essayer.

  • Les tests unitaires: il s’agit du focus principal du TDD. L’unité de test est la méthode. C’est le focus principel de l’approche TDD. La mise en place de ces tests s’appuie traditionnellement sur des frameworks de test de la famille xUnit (cf “xUnit Test Patterns” de Meszaros).
  • Les tests de composants: C’est un type de tests assez proche du précédent, on emploie d’ailleurs souvent les mêmes outils. C’est aussi un test de type “boite blanche”, pas très facile à décrire à mon avis, car la notion de “composant” est elle-même difficile à établir à l’aide d’une définition fermée ! De manière générale, on peut dire que ces tests s’appliquent à des groupes de classes, donc à des scénarios mettant en oeuvre l’interaction entre ces différentes classes. On peut parfois réaliser ces tests en TDD, mais dans la pratique cela s’avère plus difficile à faire que pour les tests unitaires. Beaucoup de développeurs écrivent ces tests juste après avoir écrit le code.
  • Les tests d’intégration: On peut voir d’une part ces tests comme des tests de composant à plus grande échelle, traversant toute l’architecture du système, mais souvent ces tests intègrent l’interaction avec les systèmes externes (base de données annuaires, etc…). Les agilistes essaient souvent de mener leurs tests le plus loin possible sans y intégrer de système externe, en “mockant” ces systèmes externes, puis de réaliser des tests plus ciblés adressant uniquement les couches d’interfaçage avec le système externe ! Quoi qu’il en soit, ces interactions avec les systèmes externes doivent être adressées. Je n’ai personnellement jamais vu ces tests d’intégration réalisés en TDD, mais en principe rien ne l’interdit ! Au niveau de l’outillage, on voit soit des solutions spécifiques, soit des adaptations à base de xUnit. Certains systèmes viennent aussi parfois accompagnés de librairies ou d’outils facilitant ces tests d’intégration, c’est le cas de certaines solutions open-source.
  • Les tests de performance: Il n’y a guère de différence de mise en oeuvre de tests de performance entre un projet agile et un projet non-agile. Dans un projet agile, on essaiera simplement de mettre en place ces tests au plus tôt, puis d’intégrer ceux-ci à la plateforme d’intégration continue. Les tests de charge, de par leur nature sont eux, hélas, difficile à concilier avec une logique d’intégration continue. Que ce soit pour les tests de charge ou pour les tests de performance, on est plutôt dans une logique de “test after”. Peut-être il y a-t-il là matière à progrès ? Les outils destinés à ce type de tests sont spécifiques à ces problématiques, souvent hélas un peu lourd de mise en oeuvre.
  • Les tests d’acceptance: Il s’agit de tests fonctionnels, donc de type “boite noire”. Au niveau de l’approche outillée, il y a deux courants de pensée:
    • Une approche de tests par l’IHM, comme cela est fait avec des outils tels que Selenium. La difficulté étant alors la combinaison de problématiques de comportements dynamiques d’interface avec le comportement purement fonctionnel. L’avantage est que ces tests garantissent effectivement ce qui est perçu par l’utilisateur.
    • Une approche s’abstrayant de l’IHM, testant le comportement fonctionnel au niveau de la couche sous-jacente à la couche présentation. L’avantage est une meilleure stabilité comportementale, car le comportement dynamique de l’IHM est exclu. S’il permet de se focaliser sur l’aspect métier, il ne s’agit pas ici d’un test applicatif. L’émergence de technologies telles que HTML 5 et de librairies Javascript lourdes comme JQuery mettent aussi à mal cette approche par ailleurs attrayante.

          L’une des pratiques agiles qui fait l’objet de plus en plus d’attention est l’ATDD, ou Acceptance Tests Driven Development. Il s’agit d’une pratique complémentaire au TDD, focalisé ur l’aspect fonctionnel. Dans cette approche, on perçoit les cas de tests comme une information complémentaire au recueil des besoins, lui donnant à la fois une concrétisation (une expression de besoin est par nature abstraite) et des précisions pour traiter des cas particuliers ou ambigües. L’expression des besoins est donc alors le recueil des besoins initial (les User stories ou autre chose) plus les cas de tests d’acceptante. Dans l’approche ATDD, les cas de tests sont écrits en grande partie et implémentés avant que le travail de développement commence, à l’image de ce que l’on fait pour le TDD. Ces cas de tests ne sont pas écrits par le développeur mais par toutes les parties prenantes à l’expression du besoin (le développeur peut y participer). La mesure du suivi de l’accomplissement de l’itération devient alors le suivi du passage au vert des cas de tests, permettant un suivi du projet hors pair !

  • Les tests exploratoires: Ce sont les seuls tests qui ne peuvent être automatisés, ils sont laissés au jugement humain. La découverte de cas de figure non couverts par des tests d’acceptante peut participer à la consolidation de la couverture de tests.

L’approche agile ne limite pas les tests au test du code. En fait, tout ce qui a été identifié comme nécessitant des tests doit l’aide en utilisant la technique adéquat. Que dit l’approche agile à ce sujet ? Si quelque chose a été identifié comme nécessaire, alors faites-le ! Sinon ne le faites pas (donc ne faites pas quelque chose par simple dogmatisme). Simplement, faites-le le plus tôt possible et le plus souvent possible ! C’est une question de bon sens.

Comment TDD traite-til des exigences non-fonctionnelles, telles que la performance, la fiabilité, la sécurité, la capacité de débit ou la bande passante et la maintenabilité ?

Sur ce point, l’auteur de l’article est à la fois dans l’erreur mais répond lui-même à une partie de ces questions.

1 – Performance, fiabilité et sécurité

Pour ce qui est des autres types de tests, encore une fois s’ils ont besoin d’être fait, alors il faut les faire. Je me répète mais il n’y a aucune incompatibilité ni contre-indication entre TDD et des tests de performance ou de sécurité ! Bien au contraire, ils sont complémentaires !

2 – A propos de l’analyse

Mais qu’en est-il de traiter avec succès ces points avec “une analyse rigoureuse” ? Je répondrais en deux points:

  • Qui a prétendu que l’on ne faisait pas d’analyse sur les projets agiles ? Encore une fois j’y vois une ignorance complète de ce qu’est un projet agile de la part de l’auteur !
  • Cette fameuse “analyse rigoureuse” est-elle une garantie de succès ? Ayant audit des projets, j’ai eu mon compte de modélisations malheureuses et d’analyses erronées. 

En filigrane, j’y vois une faiblesse majeure des approches classiques: substituer une description prescriptive des processus à la compétence ! Cela conduit ces équipe à construire des équipes en “optimisant les coûts” donc avec des personnes moins chères mais moins expérimentés et/ou peu brillantes en pensant que les lourds classeurs descriptifs des méthodes vont compenser cela. C’est faux ! Il n’y a pas de substitut à la compétence !

3 – Et enfin, au sujet de la maintenabilité

Le dernier point concerne la maintenabilité. Le problème majeur qui se pose lors de la manigance logicielle est: qu’est-ce que je risque de casser en modifiant le code existant ?

Sur un projet classique, on commence par lire la documentation. Puis on lit le code (souvent peu clair, car il y a peu de contraintes sur la lisibilité du code), de toute façon en fait, on ne fait pas confiance à la documentation ! Finalement, on opte souvent par l’écriture de “rustine” interagissant à minima avec le code existant, conduisant le plus souvent à de la duplication de code et de fonctionnalité. Celle-ci amplifie encore le problème de maintenance car les prochains correctifs devront agir au niveau de toutes les portions de code dupliqués !

Sur un projet mettant en oeuvre TDD, on commence aussi par lire la documentation existante (car il y en a souvent, même si elle est plus synthétique). Puis on exécute les cas de test pour comprendre le comportement du code existant. On ajoute de nouveaux cas de tests correspondant aux évolutions ou corrections à implémenter et on s’assure avant tout que ces tests ne passent pas. On effectue les évolutions / corrections dans le code existant en s’assurant que les codes préexistant ne cassent pas. On vérifie aussi qu’il n’y a pas de duplication de code et que le design est “clean” en terminant chaque cycle d’implémentation par du refactoring. On n’a aucune crainte à le faire, car contrairement à un projet sans tests unitaires, on a les garanties qu’il n’y aura pas de régression ! On s’assure régulièrement, à chaque “commit” de code que les tests d’intégration et d’acceptante passent tous, y compris les nouveaux tests d’acceptante. On s’assure que tout est au vert sur la plateforme d’intégration continue.

TDD n’est peut-être pas l’arme absolue en ce qui concerne la maintenabilité, mais c’est sans aucun doute possible ce qui s’en rapproche le plus ! Aucun autre outil ne peut nous donner de meilleurs assurances à ce sujet. L’auteur propose comme outil de l’analyse et de la modélisation rigoureuse, mais en quoi peut-on être sur que ces documents sont à jour avec le code ? Est-on certain que les évolutions ont été faites sur les deux fronts ? Y compris lors des correctifs d’urgence (ce n’est pratiquement jamais le cas) ? Et finalement en quoi ces outils aident-ils le développeur à s’assurer de la non-agression ?

En fait, c’est bel et bien l’approche classique qui ne sait pas répondre aux problématiques de la maintenabilité. En tout cas l’auteur de l’article n’y répond pas !

L’approche non-agile ne donne aucun outil réellement opérationnel par rapport à la problématique de la maintenabilité. Pire, elle occulte cette lacune avec une illusion simplement à même de tromper un management qui finira, si cette maintenance devient problématique ou trop coûteuse, par blâmer le développeur !

Vu que les cas de tests au niveau des tâches dirigent le processus TDD, que se passe-t-il si ces tests sont inadéquats, par exemple incomplets, insuffisants ou incorrects ?

C’est une question assez générale: que se passe-t-il si les tests sont inadéquats, etc… Pas seulement en TDD, mais en général ! Quelle réponse apporte les processus classiques ? Visiblement on parle de vérification croisée !

Sur ce point, TDD est utilement complété du pair programming. Si votre développement est réalisé en pair programming, vous avez l’assurance que tous les tests sont toujours revus par une autre personne, tout le temps, au moment où ils sont écrits ! Est-ce parfait ? Non ! Mais au moins a-t-on l’assurance que tous les tests sont revus contrairement aux processus de revue croisé à postériori qui ne sait garantir (à moins de coûts exorbitants) que tous est toujours revu !

ATDD complète aussi utilement cet arsenal grâce à des tests s’appuyant et complétant les spécifications. La garantie que ces tests sont “parfaits” n’existe pas. On réduit simplement le risque en faisant participer à leur écriture toutes les personnes qui peuvent être concernées. Fini l’approche taylorisme du testeur écrivant ses tests dans un coin en s’appuyant sur une lourde spécification envoyée par mails, le cahier de test étant ensuite lui-même envoyé par mail aux personnes en charge de l’exécuter ! L’approche agile croit en la collaboration et la communication.

L’affirmation d’effet tunnel est aberrante: au contraire, les projets agiles donne une visibilité idéale sur le projet: on connait à tout instant le nombre de tests unitaire qui passent, les tests d’acceptante qui sont OK, la plateforme d’intégration donne un statut sur la qualité d’intégration et souvent d’autres métriques qualité. Les projets Scrum donne aussi une visibilité en continu sur les tâches en cours et réalisées via un “kanban” des tâches. On parle ici de visibilité à l’heure, voir à la minute. Sur aucun des 4 volets que j’ai cité, les processus classiques ne peuvent prétendre donner le même niveau de visibilité et de feedback. Il y a bien un problème d’effet tunnel, mais il est du côté des processus classiques.

Les défauts qui ne peuvent être détectés que par le test de flux de données…

J’avoue ma méconnaissance de cette technique. C’est une des nombreuses choses que la communauté des tests peut enseigner à la communauté agile !

Je n’ai qu’une chose à dire: si ce type de test est utile, alors faites-les ! Il n’y a aucune incompatibilité avec la pratique de TDD.

Quel est le processus de TDD qui garanti que les composants créés et testés isolément avec succès seront sujet à une forme de test d’intégration ?

Tester l’intégration est l’affaire des tests d’intégration ! TDD est une pratique de développement, donc les tests d’intégration ont toujours lieu, comme je l’ai dit précédemment.

En ce qui concerne l’intégration, les projets agiles s’appuient sur des plateformes d’intégration continu qui jouent tôt et souvent les tests d’intégration. Ce qui dans des projets classiques correspond à une phase d’intégration pouvant durer plusieurs mois est ici littéralement réduit à zéro !

Comment la documentation délibérément parcellaire, supporte-t-elle le besoin éventuel de maintenance du programme ?

J’ai répondu à ce point précédemment. Le problème majeur de la maintenance est la non-regression. La documentation n’aide en aucune manière sur ce point.

Maintenant, il est utile d’avoir une compréhension de haut niveau, pour comprendre l’organisation des modules, le style architectural, le cinématique des services. Documenter cela de manière compréhensible et synthétique est souvent utile. Et dans ce cas, il faut le faire, tout simplement ! Certaines équipes emploient même à plein temps un “technical writer”.

Mais pour ce qui est de garantir la non-regression, la documentation n’est d’aucune aide. Les tests unitaires développés et maintenus tout au long de la vie du programme avec TDD sont le meilleur outil que je connaisse, de très loin.

La maintenabilité des projets développés avec TDD sont incomparablement plus maintenables que les projets non-agiles. En fait, ils sont simplement maintenables, alors que les projets sans tests unitaires ne le sont pas.

Comment la refactorisation répétée produit-elle une conception élégante ?

L’auteur parle de controverse. Je partage ce point de vue mais de mais de manière inverse: Je reste dubitatif sur cette affirmation que la conception émergente ne produit pas des architectures élégantes. A l’appui des dires de Mr Jorgensen, il y a une étude qu’il a mené dans son université. Mais on ne sait rien de cette étude (et l’on sait qu’on leur fait dire ce que l’on veut, aux études): sur quelles critères ? Avec qui ? Sur quelle base ? Répondre au “comment” que nous soumet l’auteur est difficile. Mais je peux soumettre des éléments de réponse !

  • Un très grand nombre de projets open-source, notamment dans la fondation Apache sont le fruit d’une conception émergente, je pense que c’est une base sur laquelle s’appuyer pour parler d’élégance.
  • La qualité d’une conception ou d’une architecture est essentiellement subordonnée au savoir-faire du développeur. Le raffinement d’une architecture par le biais de refactoring demande effectivement un savoir-faire à part entière. Au final, c’est le talent et le savoir-faire qui sont la garant d’une bonne conception.
  • Les architectures fruit d’une conception initiale “à priori” souffrent d’un manque de recul sur le sujet:
    • Des couches dont on a décidé à priori qu’elles seraient utiles s’avèrent surnuméraires et génèrent des lourdeur et de la dette technique.
    • Certains modules ou concepts n’ont pu être identifiés au départ, encore une fois par manque de recul. Les fonctionnalités correspondantes finissent sous forme de code utilitaire “rustiné” ailleurs ou pire encore sous forme de traitements dupliqué !
    • On fait fi d’une réalité du développement informatique: il s’agit d’une activité de découverte et d’apprentissage. Les idées naissent et murissent en travaillant sur le sujet. Il ne faut pas hésiter à remettre en cause des idées premières à la lumière de ce que l’on a appris.
  • En commençant petit, avec le niveau et la complexité de conception correspondant à ce que l’on fait sur le moment, on s’assure de ne pas faire de “sur-conception”, on ne fait pas d’hypothèse sur des évolutions futures dont on ne sait pas si elles auront lieu et enfin on écrit uniquement du code qui sert, que l’on peut tester, et non pas un dette technique et peut-être même une bombe à retardement.

Ayant répondu à ce point, j’attire maintenant l’attention sur le fait que TDD et refactoring s’ils sont complémentaires et se marient bien ensemble, sont deux pratiques différentes ! TDD n’a pas pour but de traiter la qualité de la conception.

Par contre, une constatation que j’ai pu faire au début des années 2000, c’est que le noyau dur de la communauté agile s’est construit à partir de la communauté “design patterns” donc des personnes particulièrement affutées en conception et qui ont voulu mettre en place des méthode de travail permettant l’émergence de conceptions de qualité !

Comment une “vision tunnel” générée par TDD peut-elle amener une conception qui traite efficacement de la performance

Ce point nest pas un nouveau point, car l’auteur a déjà évoqué ces points en (4) et en (5). La réponse reste la même: TDD est une pratique de développement, elle ne prétend pas couvrir les tests de performance, ni résoudre la crise économique ou établir la paix dans le monde. les projets agiles font des tests de performance dans la mesure où ces critères ont été identifiés. Et dans ce cas, ces tests sont intégrés à la plateforme d’intégration. On peut alors suivre heure par heure l’impact des évolutions ou des refactoring sur ces performances. Les projets classiques peuvent-ils prétendre la même chose ?

Je ne vais pas m’étendre sur l’accusation d’effet tunnel qui met simplement en lumière la complète ignorance du sujet auquel s’attaque Mr Jorgensen.

Comment détecter des inconsistances, même légères entre les tâches d’une user story ou entre les user stories elle-même ?

Qu’est-ce qu’un découpage en tâche dans un développement agile ? C’est simplement une façon d’organiser le travail afin de le répartir et de voir le développement progresser. Bien sûr, lorsque l’on découpe en tâches on s’évertue à donner une définition du “done” de la tâche. mais au final, quand les tâches constituant une user story sont terminées, ce sont les tests d’acceptance qui font foi du bouclage de la user story. Possédant cette indication, quelle valeur il y a-t-il à relier des incohérences “même légères” entre les tâches ? Si cela ne va pas, les tests d’acceptance sauront nous le dire, car il ne passeront pas. Si ils passent ces que ces incohérences sont sans importance, ou alors peut-être du point de vue académique … mais sur les projets agiles, on refuse de passer du temps sur des choses qui ne servent à rien.

Les incohérences entree user stories sony des choses qui peuvent arriver. Je vois deux moyens de contrer ce problème

  • Sur les user stories, la communauté agile a développé deux techniques: les “epics” et le “story zapping” afin de regrouper et analyser de manière transversales les user stories.
  • La seconde technique n’a rien de novatrice mais elle marche toujours très bien: le peer-review.

L’utilisation des “user story” est indépendante de TDD. Même si cette technique est très répandue dans la communauté agile, elle n’est pas “obligatoire”. Et si elle est utilisée, elle peut être complétée par nombre de formalismes ou techniques qui peuvent s’avérer pertinentes sur le projet. 

L’heure du bilan ?

Le premier point que que l’on retiendra est la méconnaissance totale du sujet par Mr Jorgensen. Il présente TDD comme un processus alors qu’il s’agit d’une pratique. Une erreur qu’il n’aurait pas faite s’il avait lu quelque ouvrage sur le sujet ! On comprend maintenant pourquoi il n’y a aucune référence bibliographique à l’appui de ses observations.

Ma réponse est beaucoup plus longue que l’article d’origine. J’ai voulu étayer chaque point d’explications et non asséner des affirmations. Pourtant j’aurais aimé développer encore plus !

Cette approche éronée explique pourquoi certains points ne sont pas “traités par TDD”. Dans un projet agile on utilise un ensemble de technique pour couvrir ces différents aspects, comme une plateforme d’intégration pour vérifier en permanence la qualité d’intégration. On voit alors que les points en questions sont adressés de manière pertinente et efficace.

Pour ce qui est des points sur lesquels TDD présente une plus-value, on a vu que, contrairement aux affirmations de Mr Jorgensen, TDD donne une réponse de très bonne qualité, bien supérieure aux approches classiques. Est-ce un manque d’information, une erreur de jugement ou une volonté délibérée de tromper qui ont conduit Mr Jorgensen à ces conclusions ?

Les dangers de juger sans savoir

Vous aurez surement noté que j’ai appelé l’auteur “Mr Jorgensen” et non “Professeur Jorgensen”. A la lumière de cette oeuvre édifiante, il ne mérite pas ce titre. Il y a de réels dommages qui naissent de la diffusion de la désinformation et de la diffusion de contre-vérités auprès d’un public non encore au fait du sujet. Cela est encore aggravé lorsque cela est fait en s’appuyant sur une soi-disante autorité !

Et pourtant !

Pourtant, il y a beaucoup à gagner d’un véritable dialogue. Il est utile que des pratiques ou des approches nouvelles soient critiquées, challengées. Parfois, effectivement, de nouvelles idées s’avèrent de mauvaises idées et les bonnes idées sont améliorées car elles ont été poussées dans leurs retranchements ! Ces débats, cette stimulation est importante ! Mais elle doit se faire intelligemment, en connaissant le sujet, avec un esprit d’ouverture. Avec la confrontation constructive d’experts, et même en mettant face à face experts, moins experts et débutants !

Utiliser intelligemment les richesses d’une communauté vers une autre

De nombreux domaines d’ingénierie possèdent une très grande richesse de pratique et d’expérience, forte de décennies de travaux, de publications. La communauté des tests fait partie de celle-ci ! La communauté agile a beaucoup à apprendre de cette richesse et de cette expérience, sans devoir renoncer à ses conviction.

Dans l’autre sens, la communauté des tests a certainement des idées à emprunter au jeune courant agile. On a souvent besoin d’idées disruptives pour ortie du carcan des idées reçues ! De cette rencontre devrait naitre un renforcement mutuel.

Note de lecture : Test Driven, practical TDD and acceptance TDD for Java developers par Lasse Kolkela

Note : 6 ; Infatigable bavard!

Lasse Kolkela est un fervent pratiquant de l’extreme programming, c’est dans cet esprit qu’il nous livre cet opuscule. Le texte est long (hélas, vraiment long) de 470 pages hors annexes, et ne compte que 12 chapitres, chacun étant donc également assez long. Ces 12 chapitres sont eux-mêmes regroupés en 3 parties qui forment comme on le verra une progression assez logique dans le texte.

La première partie, intitulée « primer » est une introduction au TDD, tel que l’on peut en voir par ailleurs. Les 4 chapitres qui composent les 150 pages de cette première partie ne sont ni meilleurs, ni moins bons que ce que l’on peut voir par ailleurs. En fait, 3 de ces quatre chapitres sont même carrément longs, l’auteur ayant visiblement beaucoup de difficulté à exprimer son propos avec concision. Cela rend la lecture franchement pénible.

La seconde partie, consacrée à l’application de TDD à différentes technologies est sans contestation la meilleure. Elle sauve le livre. L’auteur nous montre comment on peut effectivement avoir une approche TDD dans des environnements complexes (applications Web, accès aux bases de données, programmation multi-threads et développement Swing). Là où beaucoup d’auteurs (y compris Kent Back) se contentent de nous donner des exemples triviaux, Lasse Kolkela nous expose « par a + b » comment faire du TDD dans la vraie vie, avec des problématiques réelles. Les exemples sont pertinents, bien expliqués avec une progression logique.

La troisième partie est consacrée à « acceptance TDD » et tourne autour de FIT. Si le propos est intéressant, quoique trop raccroché à XP à mon goût, la verbosité de l’auteur rend de nouveau la lecture peu plaisante.

En conclusion : il y a de la matière, et l’on trouvera plus spécialement utile la seconde partie. Mais j’aurais d’avantage apprécié le livre (et donc mieux noté) si il avait comporté 150 pages de moins !

test-driven

Référence complète : Test Driven, practical TDD and acceptance TDD for Java developers – Lasse Kolkela – Manning 2008 – ISBN : 1-932394-85-0 ; EAN13 : 978 1932394856

Test Driven: Practical TDD and Acceptance TDD for Java Developers

http://www.goodreads.com/book/add_to_books_widget_frame/1932394850?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture: The Art of Project Management par Scott Berkun

Note : 6 ; Intéressant, mais verbeux et désordonné.

Scott Berkum se moque des outils de gestion de projet ou des principes de management. Ou plutôt : peut-être ne s’en moque-t-il pas (sa culture est d’ailleurs plutôt étendue), mais il a décidé de ne pas baser son livre là-dessus. Il préfère s’appuyer sur son expérience et développer son texte autour de thèmes issue de celle-ci. Le cocktail est plutôt intéressant et est loin de limiter la portée de celui-ci à la simple gestion de projets.

La première partie est consacrée aux « plans », à la façon de les aborder et pourquoi ils échouent de façon récurrente. Avec les plans vient la Vision. Celle-ci est partie intégrante du rôle de chef de projet et du leadership qu’il doit avoir par rapport à l’équipe.

La seconde partie évoque les « savoir-faire » spécifiques au rôle du chef de projet : spécifications, décisions et communication.

La troisième partie traite le management. Le management est avant tout affaire de Leadership et de confiance.

Bien que le plan montre une certaine structure, le propos en a globalement assez peu. Le livre se présente d’avantage comme une longue causerie de l’auteur, celui-ci souhaitant partager son expérience et son savoir-faire, qui sont certains. Il s’appuie aussi pour cela sur son expérience personnelle, et ses anecdotes (dont il est parfois la victime) illustre parfaitement le propos. Long, le livre l’est sans aucun doute, avec ses 340 pages pratiquement vides d’illustrations (on en a bien quelques une de l’auteur, faites à main levée, mais…).

La verbosité de l’auteur rend hélas l’ouvrage un peu long à lire, surtout en langue anglaise. Une version française existe, sur laquelle je ne peux me prononcer. Essayez-là, elle allège peut-être le poids d’une lecture par ailleurs instructive ?

art-project-management-oreilly

Vous pouvez également aller voir le site de l’auteur

Référence complète : The Art of Project Management – Scott Berkun – O’Reilly & associates 2005 – ISBN: 0-596-00786-8

The Art of Project Management

http://www.goodreads.com/book/add_to_books_widget_frame/0596007868?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

31 ans de « book of the year »

En réponse à Dimitri Baeli, je dévoile ici ma ma liste complète de “book of the year”. En voici les principes:

  • Il s’agit d’un livre que j’ai lu pendant l’année en question. Ce n’est pas nécessairement un livre édité durant l’année en question !
  • C’est une question de coup de coeur, en principe il fait partie des mieux notés de l’année, mis en fait je ne vérifie même pas ça ! C’est complètement subjectif et je ne cherche même pas à me justifier !
  • J’ai le droit de changer d’avis jusqu’au 31 décembre de l’année. Mais après c’est trop tard, c’est gravé dans le marbre.
  • Je peux avoir plus d’un book of the year ! C’est mon classement à moi, je fais ce que je veux.
  • Il y a toujours un book of year. Si je n’ai lu que des navets, c’est le moins pire qui gagne.

Bon après, il y a aussi des “books of the decade”. Si vous être sages, ce sera pour un autre post !

1981 : Cours de Basic, analyse et programmation – D. Lautier & J.P. Lerner – Masson

1982 : La pratique du TRS-80, volume II, compléments basic & programmation Z80 – Pierre Giraud & Alain Pinaud – Editions du PSI

1983 : Suites pour PC 1500 : 20 programmes en Basic – Jean-François Sehan – Editions du PSI

1984 : Le Pascal par la pratique – Pierre Le Beux & Henri Tavernier- Sybex

1985 : Programmation du 6809 – Rodnay Zacks & William Labiak – Sybex

1986 : Gödel, Escher, Bach: Les brins d’une guirlande éternelle – Douglas Hofstadter – InterEdition

1987 : Au cœur de l’Atari ST – Laurent Besle – Eyrolles

1988 : PostScript par l’exemple – Adobe systems inc. – InterEdition

1989 : La bible PC, 2nd édition – Michael Tischer – Micro Application

1990 : Le langage C – Brian W. Kernighan & Denis M. Ritchie – Masson

1991 : Développer avec Turbo Pascal pour Windows – S. Van Gelderen – Sybex

1992 : Programmer sous Windows 3.1, 3ème édition – Charles Petzold – Microsoft press

1993 : Le génie logiciel – Ian Sommerville – Addison Wesley

1994 : Effective C++ – Scott Meyers – Addison Wesley

1995 : Design Patterns, Elements of reusable object oriented software – Erich Gamma, Richard Helm, Ralph Johnson & John Vlissides – Addison Wesley

1996 : OMT, Modélisation et conception orienté objet – James Rumbaugh, Michael Blaha, Frederick Eddy, William Premerlani & William Lorensen – Masson

1997 : MFC Programmation sous Windows – Jeff Prosise – Microsoft press

1998 : Applying Use Cases, a practical guide – Geri Schneider & Jason P. Winter – Addison Wesley

1999 : Mastering the Requirements process – Suzanne Robertson & James Robertson – Addison Wesley

1999 : Refactoring, Improving the design of existing code – Martin Fowler & al. – Addison Wesley

2000 : The Usability Engineering Lifecycle – Deborah J. Mayhew – Morgan Kaufman

2000 : Extreme Programming Explained: Embrace Change – Kent Beck – Addison Wesley

2001 : Peopleware: Productive projects and teams, 2nd edition – Tom DeMarco & Timothy Lister – Dorset House

2002 : Rapid Development, taming wild software schedules – Steve McConnell – Microsoft press

2002 : The Pragmatic Programmer: From journeyman to master – Andrew hunt & david Thomas – Addison Wesley

2003 : Agile Software Development: Principles, Patterns & practices – Robert C. Martin, with James W. Newkirk & Robert S. Koss – Addison Wesley

2004 : Enterprise Patterns and MDA, Building better software with Archetype Patterns and UML – Jim Arlow & Ila Neustadt – Addison Wesley

2005 : Effective Enterprise Java – Ted Neward – Addison Wesley

2006 : Project Retrospectives, a handbook for team reviews – Norman L. Kerth – Dorset House

2007 : Release it! – Michael T. Nygard – Pragmatic Bookshelf

2008 : More Joel on Software – Joel Spolsky – Apress

2009 : Scrum and XP from the Trenches, how we do Scrum – Henrik Kniberg – InfoQ

2010 : Scaling Lean and Agile Development – Craig Larman & Bas Vodde – Addison Wesley

2011 : Système Lean 2nd edition, penser l’entreprise au plus juste – James Woomaack & Daniel Jones – Village Mondial

Note de lecture : Système Lean, 2ème édition, par James Womack & Daniel Jones

Note: 9 ;La transition vers le Lean : en pratique (mon “book of the year 2011)

Que n’ai-je lu ce livre avant ? Pourquoi l’ai-je laissé prendre la poussière ? Passé mon enthousiasme initial, j’ai simplement mis le bouquin de côté attendant le jour propice pour me lancer dans une lecture qui s’annonçait rébarbative. La lecture n’a rien de rébarbative, les auteurs connaissent leur sujet, il savent comment le découper et le présenter, ils savent écrire … et ils savent raconter des histoires !

Je ne détaillerais pas les chapitres un à un . Le livre en lui-même est divisé en 3 parties.

La première partie « les principes de la démarche Lean » couvre 5 chapitres et totalise 83 pages. On y traite successivement de la valeur, de la chaine de valeur, du flux, du système tiré et de la perfection. Chaque chapitre étant une introduction au chapitre suivant. Cette première partie permet de comprendre les principes globaux qui guident Lean : ce qui est valeur contre ce qui est gâchis, pourquoi s’intéresser à la chaine de valeur complète depuis la matière première jusqu’au consommateur et donc la nécessité de passer à un système « tiré » ! La logique de raisonnement est limpide, seul le 5ème chapitre détonne un peu et est un peu moins fluide dans sa compréhension.

Dans la seconde partie « de la théorie à la pratique », les auteurs couvrent des exemples de transition vers le Lean. Il s’agit de loin de la partie la plus passionnante de l’ouvrage. On y voit concrètement et de manière magistralement racontée la façon et les personnes ayant conduit à ce changement. Des anecdotes émaillent les récits et l’histoire des entreprises y est même racontée. Afin d’éclairer le sujet, les auteurs ont couvert de très diverses typologies d’entreprises : depuis l’entreprise familiale, à l’entreprise de moyenne taille jusqu’au géant industriel. Puis afin de couvrir la diversité culturelle, ces 3 exemples sont complété d’un cas de figure Allemand (Porsche en l’occurrence) et d’un cas au Japon. Ces 160 pages passent vraiment très vite !

La troisième partie qui couvre 65 pages sur 4 chapitres sert de synthèse et de conclusion au livre. Elle reprend les éléments de la seconde partie pour en tirer des leçon et des tendances.

Même s’il couvre uniquement le volet « système de production » du Lean, cet ouvrage est sans doute le premier que je lis qui m’a permit de toucher du doigt la véritable nature de l’approche Lean. Les récits sont édifiants à cet égard.

Le seul véritable reproche que je puis faire est que les parties 1 et 2 n’ont guère été retouchées depuis la première édition, c’est à dire depuis 1996 ! C’est bien dommage, car il aurait été intéressant de poursuivre chaque histoire jusqu’à la traversée de la bulle Internet, alors que le récit s’achève ici avant le véritable avènement du Web. Cet dimension n’est d’ailleurs jamais évoquée dans la seconde partie. Ce livre n’est par ailleurs pas un livre de recette de mise en place du Lean, il n’a pour but que de faire comprendre la nature fondamentale de cette approche. Ce n’est pas facile car ce mouvement est très souvent mal compris et dévoyé, je pense donc que cet ouvrage devrait être la lecture préalable à la mie en œuvre des outils Lean.

Une excellent lecture que je recommande fortement et a mérité son label « book of the year » !

systeme-lean

Référence complète : Système Lean, 2ème édition, penser l’entreprise au plus juste – James Womack & Daniel Jones – Village Mondial 2005 (V.O. : Lean Thinking ; Simon & Schuster 2003) – ISBN : 2-7440-6136-0

Système Lean, penser l’entreprise au plus juste


http://www.goodreads.com/book/add_to_books_widget_frame/2744061360?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : The Clean Coder, A code of conduct for Professional Programmers par Robert C. Martin

Note : 8 ; Les enseignements de 40 ans d’expérience

Ce livre se veut la suite du « clean code » parut dans la même collection. L’approche de l’auteur y est différente, car il y parle de son expérience personnelle, de ses réussites mais surtout de ses échecs ! Ce livre, écrit sur le ton de la confidence est vraiment très agréable à lire. Le propos se rapproche beaucoup de celui du « pragmatic programmer » : que devez-vous faire pour vous comporter en vrai professionnel du développement ? J’avoue que je préfère le livre d’Andy Hunt et Dave Thomas, mais celui-ci apporte nombre d’enseignements avec lesquels je me sens en phase, même si uncle Bob vend ici son « software crafmanship » et qu’il s’agit somme toute d’un autre exercice tournant autour de son ego…

Le livre comporte 14 chapitres totalisant 185 pages. C’est donc un ouvrage assez court.

Les 3 premiers chapitres tournent autour de l’éthique du travail : qu’est-elle, quand doit-on savoir dire « non » et qui signifie réellement dire « oui ».

Les chapitres 4 à 7 sont focalisés sur le cœur des pratiques de développement. Certaines des idées mises sont curieuses, comme l’idée d’éviter l’état de concentration intense pour développer (le « flow ») ! Par contre l’idée de la pratique et des « coding dojos » sont elles, intéressantes.

Les chapitres 8 à 10 ont trait aux pratiques projet : stratégies de test, gestion du temps et des estimations. On n’y trouve pas grand chose de nouveau, du moins qui n’ait été développé ailleurs (dans les ouvrages de McConnell ou de Mike Cohn, par exemple). Mais le propos reste plaisant.

Enfin les chapitres 11 à 14 sont relatifs aux pratiques d’équipe : gestion de la pression, collaboration ou mentoring.

Le livre ne recèle pas d’apport nouveau. Il s’agit plutôt d’un condensé d’idées reprises d’ailleurs. Souvent synthétisées, par fois avec des raccourcis. Le livre conviendra aux praticiens agiles lisant peu, pour qui ce texte court et facile à lire donnera de nombreux pointeurs vers les différents sujets constituant le quotidien du projet, tout en donnant un guide pour ce qui est du professionnalisme du développeur.

clean-coder

Référence complète : The Clean Coder, A code of conduct for Professional Programmers – Robert C. Martin – Prentice Hall / Robert C. Martin series 2011 – ISBN : 978 0 13 708107 3

The Clean Coder: A Code of Conduct for Professional Programmers

http://www.goodreads.com/book/add_to_books_widget_frame/0137081073?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on