Catégorie : Notes de lecture

Note de lecture : Peopleware: Productive projects and teams (2nd edition), par Tom DeMarco & Timothy Lister

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 10 ; De la gestion de projets à la création de communauté : une aventure humaine. Book of the year 2001 !

J’aurais pu ranger ce livre dans la catégorie “méthodes agiles”, tant le propos développé dans cet ouvrage est proche de l’extrême programming. Ce livre concerne le management, ou plutôt la gestion de projets mais dans le sens où la gestion d’un projet est d’avantage une question de faciliter la synergie de groupe que de méthodologies formelles. Qu’ont donc en commun les projets ayant abouti à des succès remarqués ? Une gestion du projet et des ressources particulièrement méticuleuse ? Parfois. La formation d’un groupe d’experts hautement qualifiés ? Pas toujours. L’utilisation d’un processus élaboré distribuant tâches rôles et responsabilités de façon rigoureuse et détaillée ? Rarement. Peopleware expose les traits communs de ces projets : la formation d’une équipe soudée, volontaire, complémentaire. Mais aussi la fierté d’appartenir à un groupe d’excellence, d’évoluer dans un environnement où la contribution individuelle et collective est reconnue.

Parler de la dynamique humaine dans les organisations ou les projets est presque devenu un lieu commun, que peu de personnes nient. Toutefois, cet aspect essentiel est presque immédiatement mis de coté au démarrage des projets, car « cela n’est pas applicable aux réalités du terrain ». Ce texte n’est pas une théorie sur les relations humaines, mais une suite d’essais adressant des aspects particuliers du sujet et s’appuyant sur des exemples concrets issus de la longue expérience de consulting des deux auteurs. Même si ils n’en ont pas la forme, ces essais sont pratiquement des patterns, ce qui en fait un ouvrage en avance sur son temps, car publié en 1987 pour la première édition. D’avant-garde, ce livre l’est encore d’avantage car il pose tout les fondements des méthodes agiles tels que l’extreme programming ou le lean development, par exemple.

Le livre est découpé en 6 parties totalisant 34 chapitres (ou essais). Le total n’étant que de 226 pages vous comprendrez que chaque chapitre n’excède pas quelques pages, ce qui renforce encore leur analogie avec les patterns. Les thèmes abordés au long de ces 6 parties sont : gestion des ressources humaines, l’environnement du bureau, le choix des bonnes personnes, la croissance des équipes productives, l’épanouissement dans le travail et quelques sujets connexes regroupés en dernière partie.

Il n’y a pas de recette miracle au succès des projets ou des organisations : la réussite passe par l’utilisation intelligente de la matière première principale : les hommes. Si vous souhaitez mieux appréhender cette dimension, ce grand classique est pour vous. Attention toutefois, le style un peu littéraire rend la lecture en anglais légèrement plus ardue que celle des autres ouvrages américains à finalité technique que nous avons d’avantage l’habitude de croiser.

peopleware

Référence complète : Peopleware: Productive projects and teams, 2nd edition – Tom DeMarco & Timothy Lister – Dorset House 1999 – ISBN: 0-932633-43-9

Peopleware: Productive Projects and Teams


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

Note de lecture : Professional Software Development, par Steve McConnell

Le par addinquydans Notes de lectureLaisser un commentaire

Note: 8; Comment faire du développement logiciel une profession… et une carrière!

L’informatique constitue-t-elle une véritable profession d’ingénierie ? C’est à cette difficile question que tente de répondre Steve McConnell dans ce livre. Le constat initial est plutôt sévère, c’est l’objet de la première partie du livre. Les pratiques d’usage les plus répandues sont encore et toujours le « code and fix » et le noyau de connaissances universellement partagé par les professionnels reste considérablement plus faible que dans les disciplines d’ingénierie classiques établies de longue date. Ce constat amène l’auteur à considérer deux dimensions à la mesure de maturité de la profession :

  • Le corpus de connaissance : il se décline en un noyau stable (pour lequel la demi-vie des connaissances est de 50 ans) et un « body of knowledge », plus large, dont la demie-vie est de 10 ans.
  • Les éléments statutaires de la profession : certification, code d’éthique, sociétés professionnelles (telles que IEEE et ACM), développement professionnel, licences et accréditations.

Le second thème développé par l’auteur est le « professionnalisme individuel », où comment, à titre individuel, s’engager dans une voie de développement personnel. Là encore l’auteur présente ce développement en étapes, depuis le « mode héros », auquel succède la prise de conscience, le partage au sein de communautés, l’étape la plus haute étant le partage par la publication de textes.

Après le professionnalisme individuel, viennent les organisations professionnelles : comment structurer, favoriser la montée en compétence et la reconnaissance du professionnalisme des membres d’une organisation ? Plutôt que de passer en revue les chapitres de cette partie, intéressons-nous plutôt au « Construx Professional Development Program ». Dans ce programme de développement que l’auteur a mis en place dans sa propre société, les consultants sont évalués et évoluent sur des échelles de compétences par discipline d’ingénierie. Ces disciplines d’ingénieries sont définies au sein d’un organisme, le Swebok (Software Body Of Knowledge, émanation de l’IEEE). Il définit une échelle allant de 9 à 15, 10 “knowledge area” déclinés en 4 niveaux (introduction, compétence, leadership et maitrise). Chaque étage de l’échelle définit le nombre de KA pour lesquelles il faut avoir l’un des 4 niveaux. Cette échelle permet de définir des plans de progression professionnelle, définissant les actions à mener, les formations à suivre, etc..

Si cet ouvrage est surtout une source de réflexion plus profonde sur ce que veux dire ou devrait vouloir dire être un professionnel de l’informatique. Il établit les bases de ce que devrait être une véritable reconnaissance de l’informatique en tant que profession. Et c’est là une réflexion que devraient mener toute société de service informatique. Il est clair que nous en sommes loin.

prof-sofware-dev-mcconnell

Référence complète : Professional Software Development – Steve McConnell – Addison Wesley 2004 – ISBN: 0-321-19367-9

Professional Software Development: Shorter Schedules, Higher Quality Products, More Successful Projects, Enhanced Careers


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

Note de lecture : Collaboration Explained, facilitation skills for software project leaders, par Jean Tabaka

Le par addinquydans Notes de lectureLaisser un commentaire

Note: 7; Tout pour devenir le facilitateur de compétition!

Cet étonnant ouvrage compte 360 pages, uniquement pour développer les techniques collaboratives au sein des équipes de développement. Le cœur du sujet est bien entendu le meeting. L’auteur développe les différents types de meetings, comment les organiser, établir un agenda et des objectifs. Il est très agréable de constater que l’auteur a le sens du détail: Jean nous proposes des listes de matériels à utiliser, des astuces comportementales et souligne les points importants.

Ce livre n’est pas une lecture légère: si le nombre de pages le classe dans une bonne moyenne, le texte est pratiquement dépourvu de toute illustration, et c’est dommage! La lecture aurait gagné en clarté avec quelques diagrammes bien pensés, mais surtout avec des photos illustrant l’organisation des meetings telle qu’elle est décrite. Ceci est d’autant plus dommage que Jean fait cela très bien Durant ses présentations. Pour nous autres, pauvres français, il y a aussi une autre difficulté: le texte est écrit dans un anglais assez élaboré, avec des phrases assez longues. Pour en finir avec les reproches, disons que le propos est parfois un peu abstrait et gagnerai en facilité d’abord avec des exemples concrets. Fort heureusement, les “anecdotes” de l’auteur compensent au moins en partie cette lacune, en plus d’être agréables à lire.

Collaboration Explained est une réelle somme de connaissance sur le sujet, sans nul doute la référence sur le sujet. C’est pour cela que je le conseille sans réserves. Soyez toutefois conscient qu’il ne s’agit pas là d’une lecture légère !

collaboration-explained

Référence complète : Collaboration Explained, facilitation skills for software project leaders – Jean Tabaka – Addison Wesley / ASD series 2006 – ISBN: 0-321-26877-6; EAN: 978-0-321-26877-8

Collaboration Explained: Facilitation Skills for Software Project Leaders


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

Note de lecture : 97 Things Every Project Manager Should Know, Barbee Davis edt.

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Hétéroclite et peu convaincant

Ce livre qui fait partie de la collection « 97 things » n’est guère marquant. On y trouve des conseils de chefs de projets ou personnes apparentées, venus de tous horizons. C’est là que le bât blesse : il n’y a aucune cohérence entre les différentes interventions. Certaines viennent du monde « commande & contrôle » nous avisant de mieux définir les rôles les frontières et de rendre le processus plus définis, tandis que d’autres nous guident vers des processus agiles. Il en va de même pour les aspects évoqués : depuis la vision jusqu’au suivi d’avancement en passant par les estimations, la collaboration avec les utilisateurs. Tous ces sujets méritent d’être traités, mais ici on a plus un patchwork d’intervention avec des conseils parfois contradictoires que la couverture du sujet !

Certaines interventions sont toutefois très pertinentes. Si l’on prend cet opuscule pour ce qu’il est, une sorte de menu à la carte où l’on retient ce que l’on veut, on peut retirer disons 10% à 20% de matière donnant à réfléchir. Ce n’est pas sensationnel, mais on a vu pire.

97-things-PM-oreilly

Référence complète : 97 Things Every Programmer Should Know – Kevlin Henney edt. – O’Reilly 2010 – ISBN : 978 0 596 80948 5

97 Things Every Programmer Should Know: Collective Wisdom from the Experts


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

Note de lecture : Peer Reviews in Software, a practical guide, par Karl E. Wiegers

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Une approche qualité “à la CMM”, toutefois claire et efficace. Mais le livre n’atteint pas la qualité des autres livres de l’auteur!

Que cela soit bien clair: Karl Wiegers est un auteur remarquable. C’est pour cela que je dirai que ce n’est pas le livre le plus remarquable de cet auteur, mais cet ouvrage assez court donne toutefois une bonne idée d’une approche “processus ” (mais alors vraiment processus !) De la revue de pairs. Le propos est un peu moins concret que ce que l’auteur a l’habitude de nous livrer, mais il faut bien dire qu’écrire un livre sur la revue de pairs est probablement un exercice difficile.

Du coté positif, l’auteur a une connaissance et une vision exceptionnellement large du sujet, et il est capable de synthétiser très efficacement cette vision. Coté négatif, je regrette que l’ouvrage se focalise exclusivement sur une approche “processus lourd”, à la CMM, ce qui ne conviens guère à toute les organisations, et surtout aux plus petites qui ont quand même des besoins de revue. J’ai aussi été un peu gêné tout le long de l’ouvrage par l’absence de cas d’étude concret. Cela dit, le livre est assez bien complété par des artéfacts disponibles sur le site Web.

Ce livre pourra vous convenir, si vous savez ce que vous allez lire, c’est à dire un livre très orienté processus. Vous apprécierez alors la capacité de l’auteur à s’exprimer efficacement en moins de 200 pages.

peer-reviews-software

Référence complète : Peer Reviews in Software, a practical guide – Karl E. Wiegers – Addison Wesley / I.T. series 2002 – ISBN: 0-201-73485-0

Peer Reviews in Software: A Practical Guide


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

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

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

Le par addinquydans Notes de lectureLaisser un commentaire

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

Le par addinquydans Notes de lectureLaisser un commentaire

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