Les livres sur les méthodes et processConsultez tous les livres

Cet ouvrage aborde un sujet trop souvent négligé dans l'univers du développement "non critique" : la validation, ici aperçue essentiellement via les tests fonctionnels (c'est d'ailleurs dans le titre).

La première partie resitue la phase de validation au sein du flot de conception et justifie son caractère indispensable, bien que trop souvent négligé. La seconde partie présente une démarche ayant pour but de mettre en place une méthodologie de tests fonctionnels au sein d'un projet industriel. La troisième et dernière partie expose trois études de cas et justifie le retour sur investissement (ROI) d'une phase de validation bien gérée.

La lecture est aisée, les concepts semblent décrits et illustrés via des schémas correctement. Les auteurs proposent même des exemples "pratiques" et des copies d'écran de l'utilisation de trois outils différents adaptés à cette tâche.
Toutefois, je regrette que cet ouvrage reste trop "haut-niveau" dans la pure description utile pour appréhender des concepts, mais totalement déconnectée d'une mise en place dans un contexte industriel contraint par un existant souvent conséquent. Par ailleurs, les illustrations "pratiques" ne sont souvent qu'une représentation via des outils relativement onéreux masquant, selon moi, beaucoup trop la réalité pour être utile aux personnes réellement en charge de cette mission. Au final, comme indiqué sur le site de l'éditeur, il est adapté pour les DSI et les responsables méthode, mais aurait gagné à l'être également aux personnes de terrain.

Commentez

Tester est une des bases de la création d'applications robustes et efficaces. O'Reilly a publié dans sa série "Beautiful" un grand nombre de livres sur des parties différentes du process de développement. Ici, il s'agit de la partie sur les tests.

D'après ce livre, il y a 3 aspects aux tests : les testeurs, les processus et les outils.

Peut-être que le problème le plus important dans les tests est l'obtention de testeurs motivés. La première partie du livre n'a que 3 chapitres, j'imagine qu'il n'y a pas de baguette magique pour avoir une équipe de testeurs, il faut surtout que les personnes s'entendent.

La deuxième partie est la plus importante, elle a obtenu le plus d'attention dans le livre. Avec du recul, grâce à ce livre, j'ai réalisé que beaucoup d'aspects des tests n'étaient jamais abordés, et je pensais que certains codes ne pouvaient même pas être testés. J'avais naturellement tort. Par exemple, le test de code mathématique peut être effectué, un chapitre donne de bonnes pistes à suivre. D'autres chapitres parlent du fuzzing et donc d'un angle qui est surtout corrigé après la découverte d'un bug (le fuzzing permettrait de corriger le problème avant qu'il ne soit découvert), ou encore le test d'application sur réseau. En fait, l'étendue des projets qui ont participés me donnent de l'espoir et me rendent aussi honteux (parce qu'il y a beaucoup de choses que je n'avais testé, que je n'avais pas anticipé, ...).

La dernière partie s'occupe des outils utilisés pendant les tests. Il ne s'agit pas des usuels xUnit, mais bien de quelques-uns des outils qui ont commencés petits et qui ont fini comme des piliers de leurs projets parents, d'outils Open Source (valgrind, ...) ou encore d'autres.

A champ très large de projets, de personnes et de workflows sont décrits dans ce livre. S'il a beaucoup de beaux processus, il n'y a pas beaucoup de moyens de rassembler de belles personnes dans des équipes de tests. De plus, il semble que beaucoup de beaux outils étaient de petits outils qui étaient écrits pour un objectif très rapidement puis refactorés dans quelque chose bien plus puissant.

J'ai particulièrement apprécié quelques chapitres dans la deuxième partie, et surtout celui sur les tests statisques. Il est parfois très difficile de tester ces codes, et même si le chapitre ne résoud pas le problème des statistiques lui-même, il aide à la création d'un framework qui ressemble à des tests aléatoires réels.

Et je ne verrai plus les équipes de Q&A de la même manière.

Testing is one of the basis to create robust and correct code. O'Reilly has published in its "Beautiful" series a lot of books on different parts of the development process. This is the testing part.

According to this book, testing has three aspects: testers, process and tools.

Perhaps the biggest issue in testing is getting motivated testers. The first part of the book has only three chapters. I guess there is no silver bullet for getting a beautiful team of testers, it's mainly about people getting along.

The second part is the one that got the most attention in the book. In retrospective, thanks to this book, I've discovered many aspects of testing are never addressed , and I thought that some code couldn't even be tested. I was obviously very wrong. For instance, testing mathematical code can be done, a chapter gives a pretty good direction to follow. Several chapters address fuzzing and thus an aspect of testing that is mainly done after discovering a flaw (whereas fuzzing may give a shot at fixing the bug before it is discovered), or also software testing over a network. In fact the broad scope of projects that participated in this part gives me hope and shame at the same time (because there are many things I didn't test for, didn't anticipate, ...).

The last part handles tools that are used during testing. It's not about the usual xUnit, but more about some of the once-upon-a-time small tools that morphed into one of the pillars of testing in its project, or Open Source tools (valgrind, ...) or even others.

A very broad scope of projects, of people and of workflow are depicted inside this book. If there are many beautiful processes out there, there are not so many ways of getting beautiful people inside test teams. Also, it seems that many beautiful tools were mainly small project tools that were written for a simple crude purpose and that were progressively refactored into something more powerful.

I especially liked some chapters in the process part, for instance the statistical one. It's something very difficult to test, and although the chapter doesn't solve the ultimate issue of statistics, it helps creating something that looks like real random tests.

Also, I won't see Q&A the same way now.

"97 Things Every Programmer Should Know" présente 97 conseils d'auteurs talentueux et célèbres (Kirk Pepperdine, Uncle Bob Martin...) aux programmeurs de tous horizons.

97 conseils pour 97 chapitres, 2 pages pour chacun, le livre présente 2 sommaires, le premier par ordre alphabétique des titres de chapitres et un second classement par catégories (Bugs and Fixes, Build, Deployment, Desgn, Coding, Error handling, Performance, Testing...) On peut donc lire ce livre linéairement ou par thème, pratique selon son besoin au moment de la lecture.

La lecture est facile, intéressante, passionnante et abordable pour un large panel de lecteurs. Par contre, bien que s'adressant à un public technique, il ne faut pas s'attendre à trouver beaucoup d'exemples de codes (voire quasiment aucun, à part "Code in the Language of the Domain" de Dan North ou "Missing Opportunities for Polymorphism" de Kirk Pepperdine), mais plus généralement des bonnes pratiques à suivre dans le quotidien du développement d'un projet informatique.

Certains conseils se répètent, mais je dirais qu'ils sont présentés sous des angles différents, apportant une certaine ouverture sur l'appréciation d'un conseil. Bien sûr, les développeurs rodés aux bonnes pratiques penseront que les conseils prodigués enfoncent des portes ouvertes, mais applique-t-on toujours réellement ce qu'on peut apprendre en théorie ? La lecture de "97 Things Every Programmer Should Know" sera peut être l'occasion de me faire mentir !

Parfois les auteurs auront des avis contradictoires, c'est aussi la richesse de cet ouvrage, une ouverture à la réflexion et le fait qu'il faille réfléchir avant d'appliquer bêtement la bonne parole.

Mes chapitres préférés ? Ou plutôt quelques uns parmi d'autres :

• "The Boy Scout Rule" de Robert C. Martin (Uncle Bob), ou comment laisser un code meilleur après que vous l'avez trouvé ;
• "Check your code first before looking to blame others" de Allan Kelly, ou l'art de balayer devant sa porte avant celles des autres ;
• "Two heads are often better than one" de Adrian Wible, ou l'art du pair programming ;
• "Write test for people" de Gerard Mezsaros, ou comment la lecture de ce chapitre par mes prédécesseurs aurait pu m'aider sur un projet actuel pour comprendre mieux l'aspect métier.

Développeur depuis plusieurs années déjà, j'ai retrouvé dans ce livre beaucoup de choses que je pratique déjà mais j'ai également beaucoup appris à la lecture d'autres chapitres et au delà des conseils aux programmeurs on pourra aussi trouver application de certaines bonnes pratiques dans la vie quotidienne.

Pour les débutants en programmation ce livre est à posséder absolument, pour les plus expérimentés je suis sûr qu'ils y trouveront leur compte ou tout du moins se rafraichiront la mémoire avec cette passionnante lecture. À noter également que le contenu de ce livre est sous licence Creative Commons accessible sur le site officiel, ça permet de se donner une idée avant l'achat physique du livre.

L'idée est simple, le résultat assez intéressant. Prenez une grosse poignée d'experts, demandez leur des conseils, rassemblez le tout sous la forme de 97 fois 2 pages par conseil, et vous voilà avec un contenu tout autant riche que dispersé sur une large gamme de sujets.

Cet ouvrage vous apporte avant tout des sujets de réflexion, certains vous étant peut-être déjà connus : les tests, les pratiques collaboratives, les outils de développement et de productivité, l'apprentissage, le professionnalisme, les performances, la prise en compte des besoins utilisateur, etc.

Selon votre expérience dans le milieu, certains conseils vous paraîtront sans doute évidents (utilisation d'un gestionnaire de sources), d'autres pas assez développés (design d'API) pour vous servir dans l'immédiat.
Difficile dès lors de donner la même satisfaction à tout type de lecteur : les moins expérimentés auront l'occasion d'en faire un livre de chevet qui les accompagnera pendant un bon moment, les plus aguerris seront sans doute confortés dans l'idée qu'ils sont sur la bonne voie.

En ce qui me concerne, si je devais reprendre l'un des conseils, celui qui m'a le plus marqué, ce serait l'un de ceux émanant de Robert C. Martin (Uncle Bob) et intitulé "The professional Programmer".
Robert C. Martin nous y explique que le trait marquant d'un développeur professionnel est son niveau de responsabilité individuelle (par rapport à son évolution de carrière, au code qu'il écrit, au fonctionnement de l'équipe à laquelle il contribue, etc.).
Dans ce qu'il affirme, une seule chose m'a énormement surpris (la culture française ?) et m'a longtemps fait réfléchir : "your are responsible for reading and learning". Uncle Bob nous encourage à ne pas compter sur nos employeurs pour nous former et, en tirant le parallèle avec des métiers comme docteur ou juriste, nous invective sur le fait que notre employeur n'est là que pour nous payer pour faire du bon boulot.
Un peu abrupt..., néanmoins force est de constater que, même si l'employeur joue le jeux des formations, ce sont bien en général ceux qui prennent les choses en main et exploitent les différentes pratiques de veille qui ressortent du lot.

Seule déception, même si un index propose un regroupement des conseils par thème, j'ai regretté que les conseils n'aient pas été regroupés en chapitres. J'ai également eu par moment le sentiment que certains conseils se recoupaient ce qui en soit n'est pas forcement très grave, mais rappelle qu'il ne suffit pas seulement de juxtaposer les différents avis pour créer un ensemble cohérent (les conseils sont classés par ordre alphabétique, selon le titre).

Cela n'enlève pour autant rien au rapport qualité / prix du livre et au contenu que tout professionnel du développement informatique devrait lire.

Jean-Luc Baptiste, nous livre ici un livre sur la méthode « Merise » orientée modèle de données. Ce livre est destiné à un public ayant déjà une petite notion de la méthode. En effet l'auteur, tout au long des quatorze chapitres, navigue dans les rappels de la méthode.

Dans le premier chapitre, nous retrouvons les étapes d'une analyse de projet avec la méthode « Merise », en passant par l'interview, la lecture des documents internes/externes, les informations calculées, les traitements, les différents niveaux conceptuels, organisationnels, logiques et physiques.

Le deuxième chapitre nous apprends les dépendances fonctionnelles, les contraintes d'intégrité et, élément essentiel, le dictionnaire des données.

Les trois chapitres suivants se concentrent sur la génération des MCD,MLD et MPD, le tout agrémenté de nombreux exemples et graphiques afin de faciliter la compréhension de la matière.

Le sixième chapitre est vraiment très bien structuré et explique de façon claire et précise les cinq premières formes normales. Celles-ci sont suivies d'un exemple nous aidant à assimiler cette partie de façon pédagogique.

Les chapitres suivants font une rapide introduction sur les modèles conceptuels et organisationnels des traitements.

Au chapitre dix, nous avons droit à une introduction sur Merise 2 et l'apport de l'héritage dans le système d'analyse.

Un excellent chapitre sur l'analogie des méthodes Merise et UML est également présent.

Nous terminerons le livre sur une introduction au langage SQL. Ici nous regrettons le choix des outils proposés pour s'exercer, MySQL au travers de Wamp Server, ainsi que PhpMyAdmin pour l'outil de manipulation de données.

En conclusion, nous avons ici un livre qui fait une rapide découverte de l'analyse via la méthode « Merise », qui permet de se remémorer les bases de cette méthode, avec un gros plus sur les formes normales et l'analogie UML/Merise

Ecrit par un consultant renommé et expert en méthodes agiles, Claude Aubry, cet ouvrage constitue un guide dans la découverte et l'approfondissement de la méthode SCRUM.

Dès les premiers chapitres, on ressent la pédagogie de l'auteur (également professeur à l'université) où il explique clairement les points clés de la méthode et parle en détail du backlog de produit.

Il décrit les différents rôles de cette dernière en insistant notamment sur le Product Owner et sur ScrumMaster en couvrant l'étendue des responsabilités de chacun. Il propose également des conseils issus de ses expériences pour éviter certains pièges et proposer des axes d'amélioration de ces rôles.

On lira avec intérêt les chapitres sur la planification de release et la planification des sprints qui sont très clair et très pragmatique et constituent un élément important pour tout "chef de projet en transition".

Il met ensuite en avant les rituels SCRUM (daily scrum meeting, revue de sprint, rétrospective de sprint, ...) en détaillant leurs fonctions et leurs buts. Ici encore, on retrouve le style léger et pédagogue de l'auteur.

J'ai été par contre un peu plus déçu par les paragraphes suivants où l'auteur essaie de nous décrire comment passer de la vision aux stories et des stories aux tests d'acceptation. Le style devient un peu moins précis et perd en clarté.

Cependant, on appréciera le chapitre sur les indicateurs, toujours utile pour rassurer la direction ainsi que l'aperçu de l'outil IceScrum qui donne envie d'être découvert.

Enfin, l'auteur propose des pistes pour une transition à SCRUM et son intégration dans les processus d'ingénierie logiciel à ne pas négliger.

En conclusion, j'ai beaucoup apprécié cet ouvrage que je recommande chaudement à toute personne souhaitant découvrir ou approfondir la méthode SCRUM. Il est le compagnon idéal pour toute équipe SCRUM qui souhaite être efficace et éviter les pièges de la conduite de projet informatique "à l'ancienne".

Hasard ou non, cette publication de Claude Aubry coïncidait la semaine passée avec ma participation à une formation ScrumMaster, sanctionnée par un examen (certes discutable) pour une certification de même nom. J'étais donc déjà plongé dans Scrum depuis plusieurs semaines lorsque l'on m'a proposé cette lecture. Lors de cette formation j'avais rencontré des consultants de Akka TechnologiesAkka Technologies, vecteurs d'une bonne dynamique Scrum dans le bassin toulousain, avec qui j'ai eu l'occasion de parler des projets de Claude Aubry et de son investissement sur le sujet. Entre les guides officiels, la littérature de Schwaber, Sutherland et Cohn, il ne me manquait donc plus qu'un livre en français. C'est chose faite, et plutôt bien faite suis-je tenté de souligner.

Bien sincèrement, le livre de Claude Aubry aborde Scrum d'une manière moins dogmatique, mais assurément plus pragmatique. En fait je n'avais pour le moment pas encore lu d'ouvrage structuré qui dispense de manière aussi complète des conseils sur la pratique de Scrum. Le retour d'expérience de l'auteur sur chaque précepte Scrum (les artefacts, les rôles, meetings) est très intéressant, et chaque ScrumMaster ou membre d'une équipe Scrum y trouvera des éléments de réflexion de qualité (comme la vie du backlog, la phase de conception, la planification de release, etc.). Je pense que je serais amené à relire certains chapitres ou paragraphes sur des sujets précis si je suis pris en défaut, car les explications et exemples sont clairs et invitent à l'essai.

Vous retrouverez ainsi les rappels des fondamentaux de ce processus empirique, une description des différents rôles (Product Owner, ScrumMaster, l'équipe), du Product Backlog, des différents timeboxes (planification de release, planification de sprint, daily scrum, rétrospective de sprint), mais aussi des définitions pratiques comme la notion de travail fini, le contexte du projet, les mesures et indicateurs. On notera également le chapitre sur les outils pour Scrum, ou IceScrum est présenté, ainsi qu'un chapitre utile pour les décideurs : "La transition à Scrum".

J'ai apprécié ce livre en français de Claude Aubry, qui apporte une contribution de qualité à la compréhension, à une application pragmatique, et à l'adoption de Scrum en France. Je pense ne pas me tromper en précisant que se livre est relativement accessible à tout acteur de l'IT, sensible aux méthodes agiles et à l'optimisation des développements logiciels, qu'il soit décideur, chef de projet, développeur, ou futur "Product Owner".

Ce livre très attendu est écrit par Claude Aubry, un représentant particulièrement actif de la communauté agile française, et préfacé par Francois Beauregard, un "agiliste" francophone de la première heure.

J'ai découvert avec plaisir un livre clair et passionnant sur un processus de développement, ce qui est rare : la simplicité et l'élégance de SCRUM y contribuent certainement, mais l'auteur a fait preuve de beaucoup de pédagogie. En particulier tous les concepts, entités, rôles, responsabilités sont clairement expliqués et bien reliés les uns aux autres, et leurs aspects temporels et dynamiques sont bien couverts. L'ouvrage montre donc bien la grande cohérence de SCRUM.

Et l'auteur a fait des choix appréciables : les chapitres courts et faciles à lire, les nombreux schémas qui facilitent la compréhension du texte, les dessins humoristiques... Il a également tiré parti de son expérience considérable pour mettre en garde le lecteur contre divers risques et pièges qui l'attendent dans la mise en pratique : bien que simple, Scrum n'est pas facile à pratiquer.

Les 11 premiers chapitres, soit environ 150 pages, décrivent complètement Scrum. Suivent ensuite 7 chapitres qui donnent des conseils pratiques sur de nombreux aspects, comme l'adaptation au contexte de votre entreprise, l'élaboration de la vision d'un produit (avant donc les sprints), la relation features-stories-tests, la traçabilité, l'ingénierie du logiciel, les indicateurs. Le dernier chapitre est un panorama de Scrum en France.

Un livre assez orienté "processus" tout de même, et qui passe peut-être un peu vite sur les aspects "équipe" et "individuel", auxquels on est forcément conduit à s'intéresser si l'on veut tirer complètement parti de Scrum : peut-on faire l'économie d'approfondir ce que veut dire être un développeur professionnel dans ce nouveau contexte ? Ken Schwaber a d'ailleurs mis en garde contre le fait qu'appliquer Scrum avec des gens qui faisaient du sale boulot avant permettait juste de produire du sale boulot à intervalles réguliers !

Un regret au niveau de la bibliographie : elle est un peu légère. Je trouve dommage de ne pas voir cités des auteurs essentiels comme les Poppendieck (Lean Software Development), Esther Derby (les rétrospectives), Larman et Vodde (Scaling Scrum), Lencioni (les dysfonctionnements d'une équipe), Robert C. Martin (sur Clean Code), Lisa Crispin, Janet Gregory (Agile Testing). Une meilleure bibliographie aurait contribué au caractère de référence que va prendre cet ouvrage.

En conclusion, ce livre est un excellent guide pour démarrer avec Scrum, ou pour revisiter les bases si vous avez déjà pratiqué. Il contient suffisamment de matière pour vous accompagner pendant de nombreux sprints. Même si vous vous intéressez déjà à des questions qui relèvent plus de la bibliographie ci-dessus, vous achèterez certainement le livre pour vos collègues et partenaires !

"Gestion de projet : vers les méthodes agiles" est un livre décrivant les rôles du chef de projet (au sens large) et les différentes façons d'appréhender les problématiques liées aux projets informatiques.
Il montre l'apport des méthodes agiles (Scrum, XP, DSDM, Crystal...) par rapport aux méthodes classiques et compare leurs avantages et leurs faiblesses.

Ce livre est illustré par de nombreux témoignages de spécialistes qui répondent à des problématiques courantes dans la vie d'un projet. Un véritable retour d'expérience qui ne manquera pas de vous faire évoluer.
Véronique Messager Rota nous amène à réfléchir aux sources d'échecs d'un projet et définit des bonnes pratiques organisationnelles, humaines et techniques.
Elle détaille également les différentes étapes d'un projet et identifie leur but et les problèmes récurrents.
Pourquoi le client n'arrive t-il pas à exprimer son besoin ?
Pourquoi seulement 30% de l'application sont réellement utilisés ?
En quoi le pilotage par les tests est un facteur de réduction des coûts ?
Comment estimer la charge d'un projet ?
Quelle doit-être la charge allouée à l'estimation d'un projet ?

Bien que ce livre soit tourné vers la découverte des méthodes agiles, certaines notions de pilotage de projet sont parfois complexes pour un débutant.

Pour conclure, ce livre est un très bon outil.
Il répond à beaucoup de questions que se posent les chefs de projet informatique et constitue un recueil d'expériences très enrichissant. Attention tout de même à ne pas tomber dans l'apologie aveugle des méthodes agiles.
Ayez toujours en tête que ce ne sont que des bonnes pratiques, que vous devez les utiliser si vous en sentez l'utilité, et non parce que vous pensez que c'est à la mode.

Pourquoi 97 trucs ? A vrai dire, je ne sais pas et je pense qu'il faut y voir la même astuce que le célèbre slogan de Magritte que l'on trouvera dans un chapitre du livre "Ceci n'est pas une pipe" (je vous laisse découvrir), à savoir que l'essentiel n'est pas toujours dans les apparences.

Un livre court (220 pages) et qui va à l'essentiel, 2 pages et la biographie des auteurs/architectes pour chaque sujet. Pas techniquement orienté, ce livre est plutôt axé sur la communication, et les ressources projet. On trouvera des conseils sur comment choisir les composants d'un projet, la gestion des équipes, savoir convaincre et communiquer au sein d'une équipe mais aussi avec le client.

Parmi mes sujets favoris (seulement quelques uns car j'ai marqué pas mal de pages) :

• "Stand Up!" de Udi Dahan qui explique que se mettre debout permet de mieux se faire écouter, comprendre, essentiel pour un architecte.
• "Architects Must Be Hands On" de John Davies expose que l'architecte pour être reconnu, et appuyé dans ses décisions devra faire ses preuves sur le terrain et non depuis sa tour d'ivoire.
• "Fight Repetition" de Niclas Nillson, un titre pas trop difficile à comprendre, quand on rencontre plus d'une fois la même situation il faut penser à automatiser.

Certains reprocheront que les explications fournies dans cet ouvrage relèvent simplement du bon sens de l'architecte (mais un rappel ne fait pas de mal), sûrement, mais je pense qu'il est bon de mettre le focus sur des points clés qui devraient être un credo pour tous les architectes.

Bien sûr, certains sujets ne m'ont pas intéressés, souvent parce que je n'en ai pas l'utilité actuellement, certains chapitres sont même répétés ("Architects Must Be Hands On" et "Before Anything, an Architect is a Developper") mais au final je pense que ce livre est une très bonne ressource à garder à portée de main. La granularité des sujets est parfaite pour une relecture rapide ultérieure lorsque le besoin de guider ses choix se fera sentir. Facile à lire, j'ai opté pour un rythme de lecture "4 à 5" sujets par soir (en plus les titres font presque penser à des contes), mais "1 ou 2" le matin avant de commencer la journée de travail ira aussi. A mon sens, un bon achat à faire !

Ce livre est très riche, il aborde de nombreuses notions théoriques. Pour autant, l'auteur n'entre pas dans le détail de chacune d'entre elles, il les présente pour les intégrer dans une vue d'ensemble de l'architecture logicielle.

L'approche à certes quelques inconvénients. Elle peut paraitre indigeste à celui qui voudrait tout enchaîner d'une traite ou bien superficielle à un informaticien spécialisé (compilateur, ETL, MVC, SOA, ...)

Cependant, l'approche a également ses avantages. Elle fait découvrir une palette de sujets plus ou moins connexes et laisse le soin au lecteur intéressé de se reporter aux ouvrages indiqués dans la bibliographie. Elle explique bien les objectifs, les motivations, les propriétés de ce qu'est l'architecture logicielle ou tout du moins de ce qu'elle devrait être.

J'ai trouvé la deuxième partie qui analyse deux chefs-d'oeuvres d'architecture la plus intéressante. Certes, elle m'a un peu laissé sur ma faim mais comme il est fort probable qu'on pourrait écrire un ouvrage rien que pour chacun d'eux, je comprends les contraintes éditoriales.

A noter également dans cette deuxième édition un tout nouveau chapitre dédié au métier d'architecte logiciel dans lequel j'ai particulièrement apprécié la description qui en est faite.

Ce livre très érudit, très théorique, est difficile et s'adresse plutôt à un public averti, des professionnels qui veulent comprendre le fonctionnement d'un système d'information complexe d'une grande entreprise ou bien qui recherchent un ouvrage de référence, synthétique sur le sujet.

Wouf ! Voici probablement le livre traitant d'informatique le plus théorique que j'ai jamais lu ! Certainement pas adapté à tout le monde, cet ouvrage est particulièrement dédié aux architectes, maîtrises d'ouvrage ou d'oeuvre, tout à fait professionnels. Il ne conviendra pas au développeur amateur. Il s'agit bel et bien d'une étude théorique des acteurs, comportements, risques, coûts, etc., qui surviennent dans le monde du développement à grande échelle.

Cet ouvrage est écrit sous une forme très scientifique, théorique, et est remarquable sur ce plan. On notera une excellente bibliographie, ainsi que la présence fort appréciée d'un glossaire complet et d'une table des sigles et acronymes utilisés.

La plupart - si ce n'est l'entièreté - des problèmes et difficultés liés au métier d'architecte y sont traités. On regrettera peut-être, malgré cela, un peu plus de conseils pratiques. Le 100 % théorie est malgré tout peu digeste, bien que d'un intérêt certain.

Je recommanderais donc cet ouvrage à tout professionnel de l'informatique ayant à gérer de grandes équipes de développement. Mais probablement pas à une autre catégorie de lecteurs.

"Beautiful Architecture" est un ouvrage composé de 14 chapitres sur le sujet de l'architecture logicielle. Un vaste domaine de l'industrie logicielle qu'il est assez difficile de définir, si je devais en faire une peinture basique, ce serait l'art de définir la structure d'un système, de ses composants et des relations entre les différents éléments qui la composent.

Le livre commence ainsi sur un premier chapitre qui tente de répondre à la question de ce qu'est l'architecture, question maintes fois posée, mais sur laquelle apparemment plane toujours le doute. Un second chapitre compare 2 applications, un mauvais exemple, puis un bon (selon les auteurs) puis suivent 12 derniers chapitres couvrants des thèmes très différents (facebook, emacs, KDE...) et toujours étroitement liés à l'architecture (quoique).

Les bons points du livre

• Un contenu plutôt intéressant avec lequel on apprend parfois
• Des sujets tendances ou qui sauront toucher : facebook , MMORPG, KDE, emacs...

Les moins

• Une lecture quelque peu ennuyeuse et rébarbative (j'ai eu parfois l'impression d'un simple remplissage des pages)
• Une mise en page triste
• Quel crédit donner aux architectes mentionnés dans le livre ?
• Manque de cohésion entre les chapitres et finalement sur le livre en entier, plusieurs auteurs donc plusieurs visions différentes et pas toujours de concert
• En principe l'architecture n'est pas le code, on pourrait alors se poser la question de la présence de bout de code dans le livre
• Un bon bagage est nécessaire avant d'entamer la lecture, développeur junior passe ton chemin...

J'ai au final un avis très mitigé sur cet ouvrage, partagé entre le fait d'avoir appris à la lecture de "Beautiful Architecture" car on a quand même un bon livre pour se donner des idées et de l'information sur l'architecture logicielle, mais l'ennui à la lecture était trop présent pour en faire un "must-have". Comment utiliser ce livre ? pour ma part certains chapitres m'ont plus intéressé et j'en ai retenu de l'information immédiatement, pour d'autres j'ai repéré de l'information qui me servira peut être un jour...

Beautiful Architecture est une sorte de suite de Beautiful Code que j'ai eu l'occasion de lire par le passé. Bien plus petit, ce livre est dédié à l'architecture, même si Beautiful Code proposait aussi certains aspects sur l'architecture. La question qui restait était de savoir si le livre était aussi bon que son prédécesseur.

L'éditeur du livre l'a découpé en 5 parties. La première est très générale et courte. Le principal sujet est la raison pour laquelle il est nécessaire d'avoir une bonne architecture, avec des expériences réelles sur une bonne et une mauvaise architecture. C'est une introduction nécessaire, même si le contenu est plutôt convenu.

La seconde m'a laissé quelque peu déboussolé. Lorsqu'on connait un peu des ouvrages sur l'architecture, on apprend peu. OK, c'est un ouvrage sur l'architecture logicielle, mais de vraies architectures sont attendues, et certaines de celles présentées (comme les web services) sont plutôt évidentes, même si le chapitre sur Facebook est intéressant à ce niveau.

La partie suivante est dédiée au matériel, émulé, virtualisé ou le vrai. Cette partie était vraiment intéressante, avec beaucoup de détails sur des projets connus (Xen) ou moins connu (Guardian, bien connu il y a quelques années et très intéressant quant à sa philosophie). J'ai eu moins d'intérêt pour les deux projets Java, comme il ne s'agit pas d'une technologie que j'utilise tous les jours, mais l'approche était plaisante.

Après le matériel, deux chapitres sont dédiés à deux projets très connus et très différents : Emacs et KDE. Le chapitre est plus consacré à l'équipe et à comment l'architecture a émergé de discussions, qu'à l'architecture elle-même, et je pense que l'autre message derrière cette partie est d'apprendre à communiquer à l'intérieur d'une équipe de développement.

Enfin, la conclusion commence par une discussion sur les langages orientés objet (le type le plus utilisé actuellement) contre les langages fonctionnels, écrite par une référence dans le domaine, Bertrand Meyer. Il faut être bien concentré pour comprendre son message. Pour cette démonstration, Meyer utilise un langage orienté objet réel, Eiffel, non pas un des langages "incomplets" comme C++ ou Java. Par conséquent, certains concepts peuvent échapper au lecteur. Et le dernier chapitre discute des architectures surfaites, générant des programmes incomplets avec des exemples où des architectes en bâtiment célèbres ont créé de superbes architectures tout en perdant de vue l'objectif principal qui était le logement (et non la beauté extérieure). Comme chaque livre sur l'architecture ou la conception logicielle, il est nécessaire d'expliciter que le mieux est l'ennemi du bien.

Moins surprenant que son prédécesseur, plus court et moins impressionnant, ce livre est parfois ennuyeux. D'un point de vue culturel, il est très bon, avec des exemples de domaines différents. Certains chapitres sont trop évidents si on est déjà habitué au sujet, et cela gâche le plaisir de la lecture.

Beautiful Architecture is a kind of follow-up of Beautiful Code, which I reviewed some time ago. Far smaller, the book is aimed at architecture, although Beautiful Code also presented some aspect of architecture. The question I've asked myself whether or not it is as good as its predecessor.

The editor split the different architecture topics in 5 parts. The first is very general, and short. The main topic is why you should have a good architecture, with some real experience with good and bad architectures. It's a necessary introduction, even if the content is to be expected.

The second part left me with mixed feelings. If you're used to architectural readings, you won't learn much, in my opinion. OK, it's a book on software architecture, but actual architectures are expected, and some displayed architectures (like web services) are obvious, although Facebook's chapter is interesting in that matter.

The third part is dedicated to hardware, emulation, virtualization or real one. This was really interesting, with a lot of details on known projects (Xen) or lesser-known ones (Guardian, which I didn't hear about until the book, but which was really interesting in its philosophy). I had less interest in both Java projects, as it's not something I deal with on a regular basis, but the approach was enjoyable.

After the hardware, two chapters are dedicated to two well-known projects with really different teams, Emacs and KDE. KDE's chapter is almost more about the team and how the architecture emerged from team's discussions than architecture itself, and I think that another message behind this part is to learn to communicate inside the developer team.

Finally the conclusion starts with a discussion on object-oriented languages (the kind that is mainly used) versus functional ones, by a reference in that field, Bertrand Meyer. One has to be focused to fully understand Meyer's message. For his demonstration, he uses a real object-oriented language, Eiffel, and not one of the usual not-fully object-oriented languages like C++ or Java. So some concepts may be missing to you. And the last chapter is about overdoing an architecture and finishing with a half-baked software with examples from the buildings architecture where some famous architects overdid their work and losing sight of the buyer's needs. Like every book on architecture or software conception, it is best to explicitely state that too much is the enemy of a good program.

Less surprising than its predecessor, shorter and with less magnificence, this book is sometimes more boring. From a cultural point of view, it's a good one, with examples for very distinct fields. Some chapters are too obvious if one is familiar with the field, and this spoils a little bit the pleasure of reading.

Version française

On ne présente plus l'intérêt des tests unitaires. En effet, cette technique devient de plus en plus répandue dans le monde informatique, quel que soit le langage, et permet, lorsque ces tests sont bien faits, d'améliorer nettement la qualité du logiciel produit, tout en facilitant la maintenance du produit. Des tests unitaires bien codés permettent de détecter rapidement tout nouveau bug introduit dans le projet, et peuvent donc éviter des régressions dans le code.

La question qui reste souvent en suspens est de savoir comment produire de "bons" tests unitaires. La littérature informatique contient un nombre important de livres parlant de méthodologies (Agile, XP, Scrum), mais il manquait (en tout cas, en .NET), un livre explicitant clairement comment produire des tests unitaires de qualité. C'est l'objectif de The Art Of Unit Testing.

Le livre commence par une introduction aux tests unitaires, à NUnit, et par un ensemble de définitions. On passe ensuite assez vite à un peu de pratique avec un premier test unitaire.

La partie suivante approfondit la notion de mock et de stubs, et aborde en profondeur le Framework Rhino Mocks. Cette partie présente de plus un ensemble de bonnes pratiques liées à l'utilisation de ce Framework, ou de tout autre Framework d'isolation.

Après avoir abordé les éléments constitutifs des tests unitaires, la troisième partie présente un ensemble de bonnes pratiques pour les tests eux-mêmes, pour éviter (entre autres) que le coût de maintenance des tests ne dépasse le gain procuré par leur existence.

Enfin, la dernière partie du livre se place à un niveau au-dessus, et présente les différents points à garder à l'esprit lors de l'introduction des tests unitaires au niveau d'une organisation et plus particulièrement dans un projet déjà existant, ce qui peut représenter une bonne partie des cas lorsque l'on introduit les tests au sein d'une équipe ou d'un ensemble de projets.

Ma plus grande crainte avec ce livre était que, Roy Osherove travaillant pour TypeMock, il parle surtout des outils commerciaux de TypeMock (Isolator, Ivonna et compagnie). En fait, ces outils ne sont que très peu mentionnés dans cet ouvrage, qui se concentre sur les "standards" que sont NUnit et Rhino Mocks.

L'un dans l'autre, ce livre est probablement la meilleure introduction aux tests unitaires que j'ai jamais lue, et devrait, à mon avis, être une lecture obligatoire pour toute équipe décidant de commencer à utiliser les tests unitaires. En tout cas, personnellement, c'est le livre que j'aurais aimé avoir il y a deux ans, quand j'ai commencé à écrire des tests.

Cela dit, ce livre requiert une certaine expérience du développement avec le framework.NET pour l'apprécier correctement, je le conseillerais donc à des personnes ayant au moins 2 ou 3 projets derrière eux.

English version

It is no longer needed to discuss the need for unit tests. Indeed, this technique becomes increasingly widespread in the computer world, whatever the language, and, when those tests are well crafted, they can significantly improve the quality of software, while facilitating the maintenance of the product. Unit tests can detect any new bug introduced in the product, and can therefore avoid regressions in the code.

The question that often remains unresolved is how to produce "good" unit tests. The literature contains a large number of books discussing methods (Agile, XP, Scrum), but there was no (in any case, for. NET) book explaining clearly how to produce some quality unit tests. That is the goal of The Art Of Unit Testing .

The book begins with an introduction to NUnit, and a set of definitions. It then moves quickly enough to a bit of practice with a first unit test.

The next section develops the concept of mock and stubs, and discusses in depth the Rhino Mocks framework. This part furthermore presents a set of good practices related to the use of this Framework, or any other isolation framework.

After discussing the building blocks of unit tests, the third part presents a set of good practice for the tests themselves, to avoid (among other issues) that the maintenance cost of the tests exceeds the advantage gained by their existence.

The last part of the book is looking at a level above, and presents the different points to keep in mind when introducing unit tests in an organization and especially in an existing project, which can represent a large proportion of cases when introducing unit testing in a team or project.

My biggest apprehension with this book was that, with Roy Osherove working for TypeMock, he would speak mostly of the commercial tools develpped by TypeMock (Isolator, Ivonna and co.). In fact, these tools are only marginally mentioned in this book, which focuses on 'standards' such as NUnit and Rhino Mocks.

All in all, this book is probably the best introduction to unit tests I've ever read, and should, in my opinion, be required reading for any team or person decided to start unit tests. In any case, personally, this is the book that I would have loved to have two years ago, when I started writing tests.

That said, this book requires some development experience with the .NET framework to appreciate it properly, therefore I recommend it to people having at least 2 or 3 projects behind them.

Ce livre est avant tout une compilation de bonnes pratiques (12 pour être précis). On y trouve ce qui va apporter au chef de projet une efficacité de manière pragmatique. Néanmoins aucune des bonnes pratiques n'est détaillée pour montrer son intérêt de mise en oeuvre. Cet aspect m'amène à penser que la cible de ce livre est bien le chef de projet débutant qui souhaite partir sur de bonnes bases. Les interventions de chefs de projets aguerris agrémentent les bonnes pratiques et une fois de plus le lecteur ne manquera pas de retrouver une de ses expériences dans ces témoignages. Un plus : vous pouvez téléchargez gratuitement le "Ebook gestion du temps PDF" (guide de 20 pages) sur le site de l'auteur.

Visualizing Data est un livre dont l'objectif est d'introduire au lecteur les techniques de visualisations de données. Pour cela, l'auteur se base sur 7 étapes fondamentales qui seront introduites dès le premier chapitre. A chaque introduction d'un nouveau type de données, ou d'un nouveau concept à modéliser, ces étapes seront précisées. Cela permet au lecteur de savoir à quel niveau de la méthode il se situe et donc de pouvoir se référer à la partie du premier chapitre si nécessaire. Je trouve cela plutôt judicieux.

Pour ma part, je dirais que livre se découpe en 3 parties principales: introduction de la méthode (et du langage utilisé), types de donnée/types d'affichage et enfin traitement des données en vue d'un affichage plus approprié.

La première partie présente les 7 étapes de la méthode et le langage utilisé. Il s'agit d'un dialecte Java développé par l'auteur afin de faciliter la visualisation, nommé "processing". Dès cette première partie, le principal défaut de l'ouvrage est présent : l'auteur ne va pas au bout des choses. La méthode est néanmoins présentée de manière compréhensible et claire grâce à l'utilisation d'un exemple extrêmement simple. Et il s'agit ici de l'atout principal du livre : il est riche en exemples.

La seconde partie liste simplement des exemples pour les différents types de donnée. Je pense qu'il aurait été judicieux de rajouter des exemples un peu plus "tordus" afin de montrer comment quelquechose de complexe, une fois bien analysé, peut se représenter de manière extrêment simple. Les exemples, en revanche, couvrent presque tous les domaines et donnent toutes les bases. Par contre, vous risquez d'avoir besoin de complément pour certains problèmes plus spécifiques (toujours le même défaut !).

La dernière partie aurait pu être la plus intéressante, car elle présente comment traiter les données, si elle n'avait pas été si pauvre. Encore une fois, seules les bases d'acquisition et de traitement des données sont présentées. Il faut néammoins laisser à la charge de l'auteur qu'un approfondissement de cette partie revient à écrire un livre traitant de la fouille de données!

En conclusion, je soutiens que le livre est intéressant mais ne présente en réalité qu'un ensemble d'exemples et n'approfondit pas les choses. Il aurait été vraiment intéressant d'aller plus loin, beaucoup plus loin... Ce livre se révèle une excellente acquisition, si il est couplé avec un livre traitant des fouilles et de l'acquisition des données.

Ce livre, d'une part plaide, auprès des responsables des services informatiques donneurs d'ordre, la cause du métier de développeur en leur proposant une perception différente des développements informatiques.

Et d'autre part, s'adresse principalement aux informaticiens en quête d'efficacité, sans avoir à imposer à leur équipe de développement, une méthodologie projet de plus.

La méthodologie de l'auteur ne nécessite pas de modifier l'organisation d'un service ou d'une équipe, ce qui est appréciable.
L'objectif est d'acquérir une démarche méthodique, ce qui est loin d'être le cas pour tous les développeurs comme certains peuvent le constater au cours de leurs différentes missions (je parle d'esprit méthodique pas d'incompétences).

Cet ouvrage est un condensé de ficelles du métier, voir un vade-mecum de méthodes. Les plus expérimentés en retrouveront certaines sans avoir conscience que leurs pratiques constituent une méthode en soi.
Un livre que je conseille aux débutants qui y trouveront des méthodes de travail simple et efficace. Par exemple la méthode d'écriture analytique, ou comment réfléchir tout en avançant dans le travail, est judicieuse.
Les expérimentés envisageant de travailler en indépendant y trouveront, je pense, de bonnes pratiques préventives contre certains risques liés à leur pratique, car comme le dit l'éditeur au dos de l'ouvrage, l'important n'est pas connaître les méthodes, mais de les appliquer quotidiennement !
De mon coté j'aurais aimé une liste d'ouvrage annexe ayant nourri la réflexion de l'auteur, car on peut apercevoir lors de la lecture que le développement logiciel est d'abord le déroulement d'idées avant d'être une production de code.

Dans la préface, Mary Poppendieck annonce la couleur : l'agilité ce n'est pas qu'un truc de développeur, ce n'est pas une recette miracle à appliquer de manière normalisée sans tenir compte de la culture d'entreprise et de ses acteurs.
Pour autant, il est rappelé qu'il y a un noyau dur indispensable à la mise en oeuvre d'un environnement agile, résumé par le manifeste agile.

Voilà ce que les auteurs tentent de couvrir dans cet ouvrage, tout en pratique et regorgeant de conseils pour vous aider à mettre en place "un" processus agile adapté à votre entreprise/project.
Becoming Agile n'est pas un autre livre à classer dans la pile des livres traitant des méthodologies agiles, il s'agit d'un des rares ouvrages qui va vous accompagner dans l'adoption et la mise en place / transition vers un processus agile.
Par conséquent, ne vous attendez pas à un contenu exhaustif sur des pratiques agiles précises (TDD, intégration continue, etc.) : d'autres ouvrages en abondance le font déjà très bien.

Au programme de cet accompagnement :
- des conseils et outils pour analyser l'environnement de départ
- accompagnement à la composition du processus agile adapté, et migration sans remise en cause de l'ensemble de l'existant

Après avoir introduit la pensée agile et l'avoir projetée sur les différentes dimensions économiques et stratégiques d'une entreprise, les auteurs introduisent l'étude de cas d'un projet pilote qui nous accompagne tout au long de l'ouvrage à travers 9 étapes d'adoption d'un processus agile.

Le livre se présente certes comme théorique, crainte largement atténuée par la présence de l'étude de cas qui se lit très facilement, comme une histoire.
De plus, les auteurs n'en oublient pas d'introduire un certain nombre d'outils, en particulier un guide méthodologique complet pour évaluer votre potentiel à faire la transition vers un processus agile (pour en savoir plus : http://www.dragile.com/).
On mentionnera notamment la Tradeoff Matrix (laquelle illustre bien l'importance d'identifier et hiérarchiser les contraintes pour n'en avoir qu'une seule qui guidera l'organisation de projet), les Feature Cards (et leurs équivalents informatisés pouvant par exemple être mises en oeuvres avec des outils comme SharePoint, VersionOne, ou Rally), le Planning Poker (pour en savoir plus : http://www.planningpoker.com/, le Burndown Chart, ainsi que la Progress Matrix.
On n'oubliera bien sur pas l'équivalent "CMMI" pour les pratiques agiles : le SAMI (Sidky Agile Measurement Index), une initiative de l'un des auteurs.

Cet ouvrage traite à la fois la problématique d'un point de vue organisationnel et d'un point de vue pratique.
Ainsi tout en alimentant la réflexion sur la difficulté dans une entreprise à faire adopter les pratiques agiles (les auteurs soulignent notamment un gouffre entre la population d'Early Adopters et celle d'Early Majority), ils proposent des solutions et une méthodologie (à commencer par exemple par analyser son "potentiel" et se tester via un projet pilote).
Ce véritable Must Have, bible de l'agiliste, se lit très bien et vous accompagnera dans votre transition vers des pratiques agiles, mais bien au delà dans votre quotidien.

English version :

In the foreword, Mary Poppendieck declare trumps: agility is not only a developers thing, it's not a magical recipe to apply in a normalization manner without taking into consideration enterprise and people's culture and knowledges.
Despite that, it's reminded that a fixed core is essential to the setup of an agile environment, summarized by the agile manifesto.

That's exactly what the authors try to cover in this book, very concrete and holding a lot of recommendations to help you setup "an" agile process which fits to your enterprise/project.
Becoming Agile is not another book to be classified in the existing ones handling agile practices, it's one of the rare writings which will go with you in the adoption and setup / migration to an agile process.
As a consequence, don't expect an exhaustive content on some particular agile practices (TDD, continuous integration, etc.) : plenty existing books already handle these topics very well.

What can you find ?
- some advices and tools to analyse your current situation
- a companion guide to build your dedicated agile process, and migration without fully challenging your legacy

After having introduced the agile thinking and projected on different economic and strategic angles a company has, the authors introduce the study case of a pilot project which will help to illustrate the talk all along the book during 9 steps of agile process adoption.

Although the book appears as theoretical, this fear is widely attenuated thanks to this study case which can be read very easily, like a story.
Moreover, the authors don't forgent to introduce a few tools, in particular a complete methodological guide to evaluate your potential to do the transition to an agile process (for more information: http://www.dragile.com/).
We can also mention the Tradeoff Matrix (which illustrate well the necessity to identify and put an order on the constraints, so that only one will define the guidelines of your project organisation when you will face some hazards), the Feature Cards (and their computerized counterpart which would be manageable thanks to tools like SharePoint, VersionOne, or Rally), the Planning Poker (for more information : http://www.planningpoker.com/, the Burndown Chart, and also the Progress Matrix.
By the way, I'm not forgetting the "CMMI" like model built for agile practices: the SAMI (Sidky Agile Measurement Index), an initiative of one of the authors.

This publication handles at once the problematic from an organisational point of view and from a practical one.
Thereby, while bringing some input to the reflection on difficulites in companies to have people adopt agile practices (the authors emphasize a chasm between the Early Adopters and the Early Majority), they suggest some solutions and a methodology (which begin by an analysis of a one's "potential" and a first contact through a pilot project).
This real Must Have, agilist's bedside book, reads very well and will companion you in your migration to agile practices, but well beyond in your daily working (or not only) life.

Je dois avouer que j'ai eu envie de lire "Coder proprement" suite aux critiques dithyrambiques précédentes mais contrairement à elles, la mienne sera un peu moins élogieuse.

Non pas que je n'ai pas aimé, bien au contraire ! Si je me fie à ma règle de proportionnalité intérêt/vitesse de lecture, je dois conclure comme eux mais venant après, mes attentes plus élevées ont aiguisé mon sens critique.

Mes attentes étaient probablement excessives mais j'ai appris moins de choses que je l'imaginai. Ceci s'explique peut être par le fait qu'avec l'expérience, j'ai découvert par moi même de nombreuses règles édictées.

L'intérêt pour moi est donc tout autre. Perfectionniste à la base, j'ai tendance à être un peu pinailleur, à chercher le meilleur nom, à faire chauffer le refactoring, à casser du code qui fonctionne parce que je vois une meilleure solution, ... N'ayant que rarement rencontré pareille obsession chez mes collègues, je croyais être atteint d'une curieuse maladie ! Ce livre a agit un peu comme une thérapie en me montrant que je n'étais pas seul, que je suis en train de muter en développeur professionnel !!!

Le livre est bien structuré :

• Il explique d'abord pourquoi il faut être propre (je suis un lecteur convaincu)
• Il montre ensuite comment faire à travers des exemples (le papier n'est peut être pas le meilleur support pour cet aspect dynamique ? vivement une version électronique avec animation intégrée !)
• Il récapitule les règles (à garder à l'esprit).

Coder proprement n'est pas spécifique à un langage donné mais il faut reconnaître que les langages typés statiquement et les outils adéquates aident grandement. J'ai donc particulièrement aimé que les exemples soient en Java.

Reprendre le code de quelqu'un d'autre pour l'améliorer n'est pas chose aisé et cela pourrait froisser plus d'un égo. Il prend donc des précautions oratoires dans le chapitre où il expose fièrement une de ses oeuvres et il a bien fait car on peut également lui appliquer la règle du boy-scout! Il est donc appréciable que l'auteur modère son point de vue en parlant d'école de pensée. Néanmoins, il manque de cohérence avec sa règle J1 sur l'importation des classes dans Java. D'une part, il dit qu'une longue liste d'importation effraie le lecteur mais c'est oublier que les chers IDE modernes (qu'il invoque quand ça l'arrange) les cachent automatiquement. D'autre part, dire que le caractère générique crée moins de dépendance que l'import spécifique d'une classe, je vois vraiment pas en quoi ???

Mon autre petite reproche est quelques petites erreurs de traductions.

En conclusion, ce livre est à mettre entre les mains de tous débutants, cela ne fait aucun doute. Pour les développeurs plus aguerris, c'est déjà plus discutable, je leur conseillerai cependant pour découvrir l'argumentaire de cette école de pensée ou pour soulager leur névrose.

Un livre tout simplement indispensable pour apprendre à coder proprement. En plus de nous apprendre à coder proprement, il nous apprend également pourquoi il faut le faire, ce qui est indispensable pour motiver quelqu'un à programmer proprement. Ce livre m'a beaucoup appris sur la bonne manière de coder. Tous les éléments théoriques du livre sont mis en pratique via des exemples concrets de code. En plus de cela, un chapitre entier est consacré au remaniement d'une classe et un autre au remaniement d'un petit programme.

Le premier chapitre tente de spécifier ce qu'est un code propre. Vous y trouverez l'avis de nombreuses personnes (Bjarne Stroustrup ou Grady Booch) sur ce qu'est un code propre. Ensuite, le chapitre suivant traite de l'importance d'utiliser des noms significatifs pour les variables, classes et méthodes. Le chapitre 3 est à mon avis l'un des chapitres les plus importants du livre. En effet, il traite des fonctions et de l'importance de les faire le plus court possible, de leur faire faire une seule chose et à un seul niveau d'abstraction, ce qui augmente clairement la lisibilité des méthodes.

On passe ensuite aux commentaires. On y apprend notamment quels sont les commentaires vraiment utiles et quels sont ceux qui ne font que surcharger le code. On passe ensuite à la mise en forme de votre code, c'est à dire l'indentation, la taille des fichiers, la largeur d'une ligne, ...

Après cela, on en vient aux objets et structures de données, à la gestion des erreurs et à la gestion des limites. Puis on passe à un autre chapitre très important, les tests unitaires. Ce chapitre m'a fait redécouvrir les tests unitaires et leur utilité.

On apprend ensuite à concevoir de bonnes classes. Avant de passer au niveau supérieur, celui du système. Avec lequel, on apprendra à concevoir également les préoccupations transversales. Puis on passe à un ensemble de règles permettant de faciliter l'émergence d'un code propre.

Le chapitre suivant est consacré à la concurrence et à la conception d'un code concurrent propre et fonctionnel. Ce chapitre sera poursuivi en annexe par un deuxième chapitre sur la concurrence.

Puis, on passe à 3 chapitres pratiques. Le premier traitant des améliorations successives d'un programme fonctionnel, mais pas propre. Le chapitre suivant est entièrement consacré au refactoring d'une classe de JUnit et enfin le troisième chapitre va traiter du remaniement de la classe SerialDate de JCommon.

Le dernier chapitre fournit une liste d'indicateurs et d'heuristiques permettant d'avoir rapidement à portée de mains une liste de bonnes pratiques pour coder.

En conclusion, ce livre vous permettra, soit de commencer à bien coder, soit de redécouvrir la façon de coder, suivant que vous soyez débutant ou expérimenté. L'auteur pouvant parfois être très radical dans ces dires, il est possible que certaines de ses recommandations ne vous plaisent pas du tout ou vous semblent trop extrémistes. Néanmoins, ces recommandations viennent, comme l'auteur l'indique, d'une école de pensée. Il est donc possible que d'autres systèmes de code propre vous satisfassent plus que celui-là, mais pour ma part, j'ai trouvé ce système de code propre des plus intéressants.

Je ne vois pas ce que l'on peut reprocher à ce livre. Véritable guide de la programmation propre, il commence par justifier au lecteur l'utilité d'un code propre. Ensuite, il explique ce qu'est un code propre, avant de démontrer comment il est possible de rendre propre un code qui ne l'est pas.

La structure et le fil conducteur du livre sont limpides, et les explications d'une clarté irréprochable. Avec peu d'efforts, le lecteur intègre les besoins et les solutions liés à la propreté du code.

Il me faut toutefois noter que l'auteur adopte un point de vue très radical (pour ne pas dire extrémiste). Certains lecteurs pourront être rebutés contre l'une ou l'autre recommandation. Cependant, je les invite à essayer de suivre scrupuleusement les conseils de ce livre dans un projet, si petit soit-il, avant de juger. J'ai moi-même eu l'occasion d'appliquer pleinement ces notions dans un concours, très réputé pour voir fleurir des codes illisibles en peu de temps : le code construit en suivant les techniques de cet ouvrage est resté d'une clarté exceptionnelle, sans perte de temps.

Pour ceux qui, malgré cela, ne peuvent accepter un point ou l'autre, l'auteur signale explicitement que son enseignement est celui d'une école de pensée, et qu'il est parfaitement possible que d'autres systèmes de code propre fonctionnent aussi bien.

C'est donc un livre à mettre en toutes les mains, du plus jeune débutant afin qu'il prenne de bonnes habitudes dès le début, au plus expérimenté qui redécouvrira une autre manière de coder : plus simple, plus claire, plus durable.

Un livre pour nous présenter 40 outils de gestion d'un projet de A à Z sous forme de condensé ? Oui c'est bien de ce livre que nous parlons. Les auteurs nous rappellent les concepts du projet. Depuis l'idée jusqu'au bilan d'un projet, toutes les phases et jalons nous sont présentés. Chaque chapitre est présenté de manière sobre et efficace! Mes plus : le résumé en fin de chapitre avec les "a éviter" (que nous avons tous déjà rencontré dans certains projet!), les bons conseils...
Ce n'est pas un livre spécialisé pour des spécialistes de gestion de projet mais bien un livre de bonnes recettes.
On pourra reprocher le coté "passe partout" des documents présentés mais cela permet d'avoir une présentation formelle du concept présenté.

A mon avis un ouvrage à lire absolument pour comprendre les concepts objets, avant de parcourir des ouvrages plus spécifiques du genre "Object-Oriented Design in Java" ou "Thinking in C++". Même si les exemples dans cet ouvrage sont ecrits en java, les explications sont applicables a tous les langages OO (C++, C#, ...)

Ce livre donne les "clés" pour modéliser et implémenter un logiciel dans un langage Objet. Une mention spéciale pour le chapitre 6 où l'auteur fait l'analyse et la conception d'un jeu de black-jack en partant de la règle du jeu (description textuelle) pour finir aux diagrammes UML en utilisant la méthode des CRC-Cards.

Comment gérer un projet informatique ? N'importe quel développeur s'est inévitablement posé cette question un jour ou l'autre. La gestion de projets informatique, sujet vaste et complexe, est traitée avec pragmatisme dans cet ouvrage au titre concis. En effet, la structure de ce livre est particulièrement efficace : chaque étape essentielle d'un projet est analysée dans un chapitre qui lui est dédié.

Sans expérience professionnelle, c'est avec appréhension que j'ouvrais les premières pages de ce livre. Manque de connaissance, manque de recul, tant de facteurs qui pouvaient me faire passer à côté de l'essentiel.

Malgré cela, la lecture s'est avérée agréable, facilitée par les nombreuses définitions et explications concrètes des auteurs.

Voilà pour le point "personnel". En tant que développeur, le livre a parfaitement répondu à mes attentes, c'est une excellente introduction à la gestion de projets : expression des besoins, cycle de vie, qualité, droit juridique, gestion des finances, même le facteur humain est analysé (les auteurs donnent par exemple quelques conseils pour une bonne organisation de vos réunions de suivi de projet).

L'ouvrage reste modeste et ne s'enlise pas dans des sujets trop vastes qui alourdiraient la lecture, mais on peut remercier les auteurs d'avoir pertinemment préciser les références de nombreux livres qui satisferont les assoiffés de connaissance.

S'il faut trouver un défaut, ce sera sur la couverture. Couleurs peu attrayantes, textes mal présentés, l'apparence n'est définitivement pas représentative de l'excellent contenu de ce livre.

Moins de 300 pages pour expliquer comment manager un projet informatique, c'est la difficile mission de ce livre à l'intitulé surprenant d'imagination "Manager un projet informatique". Difficile car les étapes d'un projet sont nombreuses, leurs approches différentes, et ce ne sera sûrement pas le sujet de discussion majeur sur la plage cet été.

"Manager un projet informatique" est structuré très simplement : c'est un balayage de toutes les phases et informations relatives à la gestion d'un projet informatique. Le livre explique donc l'avant-projet, présente quelques cycles de vie (à vous de choisir celui qui convient le mieux au type d'exercice), les ressources documentaires et contractuelles, le suivi, les chiffrages (charges, risques, ROI, etc.), les aspects décisionnels, la sécurité, le droit, la qualité, l'intégration de progiciels, bien connue dans nos chères SSII, etc. Je pense avoir trouvé dans cet ouvrage toutes les phases que j'ai pu expérimenter dans les projets où je suis intervenu, expliquées très simplement mais aussi très précisément (attention ce n'est cependant pas exhaustif, et ce n'est pas le but, on peut par exemple trouver des oeuvres entières sur la méthode XP), je trouve que l'équilibre est parfait. Les illustrations sont claires, le contenu jamais ennuyeux à lire, la mise en page aérée, et quelques bonnes idées (sous la forme d'encarts "Conseil" et "Bon à savoir") viennent agrémenter le fil pédagogique. J'ai découvert aussi plus en détail ce qu'était la méthodologie Scrum, un exemple parmi les nombreuses informations du livre qui ont comblé mes lacunes.

Ce livre s'adresse donc aux chefs de projet en herbe, aux expérimentés qui désirent se mettre à jour, aux développeurs qui souhaitent mieux comprendre leur hiérarchie. Encore une fois, "Manager un projet informatique" est extrêment accessible, des contenus orientés "pratique" permettent une application directe à la réalité du travail (formules de ROI, tableaux de suivi, méthodes d'estimation des charges, etc.).

Vous l'aurez compris, j'ai adoré ce livre et je mets donc la note maximale pour ce qui constitue selon moi le meilleur moyen de comprendre comment gérer un projet de A à Z. Merci beaucoup aux auteurs pour ce petit OVNI !

J'ai hésité un moment avant de me procurer ce livre car j'avais peur qu'il ne me concerne pas suffisamment, moi, simple développeur. Et pourtant, à sa lecture, je me suis vite rendu qu'il m'aiderait à participer aux projets auxquels je suis attaché.
Au fur et à mesure que les mots défilent, le lecteur ressent l'expérience des auteurs par rapport à la gestion de projet et y retrouve le descriptif des siens, qu'ils soient de petits projets ou des grands. Le livre commence en effet par décrire la vie d'un projet, de l'idée qui émerge dans la tête de quelqu'un, jusqu'au déploiement et mise en production dudit projet. Peu à peu, il nous fait repérer les principaux points faibles d'un projet, ceux que l'on rencontre un jour où l'autre dans la vie de chef de projet et qui font, qu'à un moment donné, le projet prend soit du retard, soit est carrément mis en péril.

Le reste du livre est encore plus captivant, il reprend chaque étape en expliquant les intérêts de celle-ci, ses points forts et faibles, et les moyens de la mener à bien de la façon la plus réussie possible. Ce livre n'est pas la solution miracle pour réussir sans soucis tous vos projets mais il est pour sûr, la recette qui vous permettra de bien encadrer vos projets pour les réussir au mieux.

Ainsi donc, je conseille ce livre à toutes les personnes faisant partie d'un projet informatique, qu'elles soient MOE, MOA, chefs de projet ou simples développeurs car elles y trouveront beaucoup d'informations pour mieux comprendre le pourquoi des adaptations qu'on leur demande.

Moins de 200 pages, mais pas le plus facile à lire ;-).
Le francophone Richard Basque s'attaque à un exercice peu évident: démystifier CMMI (Capability Maturity Model Integration) et CMM en général. Ses explications, ses retours d'expérience emprunts de modestie sont très enrichissants. On comprend mieux les enjeux de ce que l'auteur présente comme un "compendium de bonnes pratiques" pour le développement de systèmes basés sur le logiciel.

Un chapitre complet détaille la terminologie utilisée dans les spécifications des "normes" CMM (CMMI, SW-CMM) du SEI (Software Engineering Institute) et permet de mieux assimiler les chapitres suivants. CMM se basant en partie sur la représentation "étagée" d'une organisation en matière de développement logiciel et de maîtrise des processus, chaque "étage" ou "niveau" est défini et détaillé dans un chapitre (domaines de processus, objectifs, pratiques, produits de sortie typiques, sous-pratiques...).

Si votre organisation souhaite développer une approche orientée CMM, le chaptitre 10 "Un cas concret" est fait pour vous, et pourrait pratiquement être lu en introduction (évaluation SCAMPI...).

Un ouvrage dans l'ensemble trés théorique et destiné aux décideurs, ingénieurs en qualité logicielle, et curieux des pratiques, méthodes et approches en matière de développement et d'intégration logicielle.

Les sites pour mieux comprendre CMMI:

• Le site du SEI (Software Engineering Institute)
• CMMI et SW-CMM
• Alcyonix

L'extreme programming (XP), plus qu'une méthodologie, est une approche globale, presque une religion.

Mener un projet grâce à l'XP relève plus du bon sens que du processus systématique: c'est ce que l'on appelle une méthode agile.

Les crédos de l'XP sont faire simple, coller aux besoins, et réagir au plus tôt en collaboration avec tous les intervenants d'un projet.

En suivant ces préceptes, vos projets devraient être menés à bien dans les délais et budgets prévus, et ce avec une qualité acceptable.

Au delà des aspects opérationnels, XP est aussi un moyen de créer de la valeur pour l'entreprise en assurant la cohésion des équipes et l'élévation du niveau global.

En résumé, XP apporte un regard neuf sur les cycles d'un projet logiciel.

L'ouvrage Extreme programming - précis et concis n'est pas une référence en la matière. Il se veut plus être un aide mémoire. Les concepts de l'XP y sont brièvement exposés et catalogués sans valeur ajoutée particulière pour qui connait déjà l'XP, et sans suffisamment d'exemples pour le néophyte.

En conclusion, il s'agit d'un ouvrage (trop ?) concis qui peut s'avérer utile mais pas indispensable pour tous les acteurs d'un projet informatique.

Que dire à part que mon impression est mitigée après avoir lu cet ouvrage.

L'eXtreme Programming n'est en rien comparable à tout autre processus de développement logiciel.
Pas de documentation ou très peu, un feedback permanent de la part de l'ensemble des acteurs actifs au sein du projet, travail en binôme, propriété intellectuelle du code,...

Ce qui me choque (je ne suis pas outré mais étonné) c'est que, si je suis la ligne de conduite de la démarche, tous les développeurs peuvent être amenés à développer ou modifier toute partie de code. Donc prenons l'exemple d'une application multi-tiers basée sur jsp, javascript, css, servlet, ejb,... les web designers ainsi que les spécialistes métiers doivent pouvoir maitriser l'ensemble des domaines d'expertises faisant partie de ce projet informatique. Je suis sceptique !!
A moins que je me trompe et cela est tout à fait possible.
Mais c'est la première réaction que j'ai après la lecture de ce condensé sur la méthode XP.

Je pense que je vais devoir approfondir mes recherches, pour confirmer ou infirmer mes dires.

Voilà la raison pour laquelle mon impression est mitigée.

Soit je me trompe et alors cet ouvrage est trop condensé que pour arriver à expliquer pleinement la démarche logicielle.
Soit ma première impression est la bonne, et je reste dubitatif sur le bien fondé de cette technique de développement.

Ce livre constitue une présentation de la méthode XP (eXtreme Programming). Bien que le titre du livre soit « gestion de projet », les thèmes récurrents de la gestion de projet classique (planification, gestion, suivi, pilotage ...) ne sont pas abordés. Il s'agit plutôt d'un ensemble de conseils et de bonnes pratiques coordonnées autour d'une méthode qui permet de faciliter la réussite d'un projet. En tous cas, c'est ce que ce livre se propose de vous démontrer.

Bien que relativement ancien (2002), ce livre est toujours d'actualité dans un monde où la gestion de projet classique semble atteindre ses limites. Les auteurs passent en revue toutes les pratiques d'XP en se focalisant dans un premier temps sur le développeur, qui est au centre de la réalisation d'un projet. Un fort accent est mis sur la programmation en binôme ainsi que sur le développement dirigé par les tests. Les valeurs d'une conception simple ainsi que le refactoring sont mises en avant.

Une deuxième partie se consacre à la présentation de l'adéquation de la méthode XP avec l'entreprise (culture d'entreprise, processus de qualité, ...). Enfin, les auteurs présentent des études de cas concrets où des projets ont suivi avec succès (et déboires) la méthode XP.

Tout au long de la lecture de cet ouvrage, on est transporté au cour de cette méthode. L'envie d'appliquer les préceptes d' XP se fait grandissante au fur que l'on tourne les pages. Ce livre détaille non seulement les différents concepts de la méthode mais permet aussi d'obtenir des arguments très précieux lorsqu'il s'agit de convaincre un public (responsables, membres de la future équipe) des bienfaits de la méthode.

Très agréable à lire et bien écrit, je recommande vivement ce livre aux personnes désireuses d'en apprendre plus sur la méthode XP. On notera quand même un manque d'illustrations, même si l'organisation synoptique des paragraphes facilite son appréhension.

Un ouvrage très bien organisé, alliant théorie et cas concret, qui devrait convenir à n'importe quel profil.
Le guide de lecture en début de livre est extrêmement appréciable et saura vous guider si vous souhaitez aller à l'essentiel.

Ce livre décrit très bien les valeurs et concepts de l'XP et les illustre de fort belle manière.
Vous y trouverez toutes les réponses à vos questions, et bien plus, des acteurs aux pratiques, en passant par les aspects contractuels.

Les études de cas en fin d'ouvrage sont très précieuses et permettent de se voir matérialiser sur des cas concret une large partie de ce qui a été introduit tout au long du livre.

Un véritable livre de chevet qui saura vous accompagner dans votre quête des pratiques Agiles.

Retrouvez la critique complète ici.

L'auteur souhaite guider le lecteur, déjà habitué aux méthodes traditionnelles de gestion de projet, vers l'utilisation des méthodes agiles. Vaste ambition.

On commence par un sommaire qui annonce une didactique plutôt encourageante. Cependant, on déchante assez rapidement pour se retrouver avec un livre somme toute classique, quoique bien écrit. Certains outils de gestion de projet classique y sont plutôt bien décrits (planification, suivi, pilotage, gestion des ressources ...) mais le lecteur déjà familiarisé avec les méthodes traditionnelles de gestion de projet connaît normalement déjà tout ca. On retrouve de temps en temps un petit pont pour se lancer dans les méthodes agiles, mais à mon avis, les accents n'y sont pas assez pragmatiques.

On appréciera tout de même les nombreuses interventions d'experts en méthodes agiles (coach xp, ScrumMaster, ...) qui viennent ponctuer les propos de l'auteur.

Ayant lu ce livre en étant déjà convaincu par les méthodes agiles, peut-être n'y ai-je pas vu assez d'enthousiasme pour ces méthodes, mais il est vrai qu'une migration doit se faire en douceur avec des chefs de projets peu enthousiastes ou des directions réfractaires.

Je reste sur une impression plutôt mitigée car je m'attendais à ce que cet ouvrage contienne plus de conseils pratiques.

Ciblant plutôt une population de chefs de projets, managers, clients ou experts métiers, décideurs, cet ouvrage se propose de faire découvrir les méthodes agiles en partant de constats faits sur les méthodes appelées traditionnelles.
Saupoudré par des interventions de professionnels reconnus du monde agile, l'ouvrage propose un guide méthodologique autour de la mise en oeuvre de projets agiles allant du recueil de besoins jusqu'à la gestion contractuelle et la gestion du changement.

C'est une gestion de projet moderne qui nous est proposée, redonnant un rôle plus humain au chef de projet qui devient un "facilitateur", centré sur une collaboration, une autonomie des intervenants et une responsabilité collective.
Les différents courant de pensée agile sont présentés, notamment Scrum, XP et UP, avec un focus progressif sur la méthode Scrum (l'auteur étant ScrumMaster et membre d'une organisation mettant en oeuvre cette méthode).
L'auteur n'oublie cependant pas de présenter de nombreux concepts agiles, la plupart du temps communs aux différentes méthodes agiles, notamment les techniques d'estimation ou les indicateurs (avancement, coût, etc.), ou encore le suivi des risques.

Scrum étant centré sur les process et les hommes, l'absence de description d'un outillage (qui peut sans doute manquer à un lectorat plus technique) s'explique assez aisément.
La présence de ces fréquentes interventions d'experts permet de conserver une portée plus globale, donnant même l'opportunité au lecteur de comparer les différentes pratiques sans que la comparaison n'ait à se matérialiser par un tableau comparatif.

Je ne sais pas si l'absence de tout nom de méthodologie agile dans le descriptif de l'ouvrage est volontaire, mais tout du moins Scrum aurait mérité de figurer de manière plus explicite sur la couverture ou le sommaire.
Cet ouvrage introduit la gestion de projet agile de manière progressive et sur un ton pédagogique, fournissant un guide de découverte très intéressant aux non initiés. Les connaisseurs de pratiques agiles y trouveront sans doute des compléments sans passer par une lecture linéaire mais en veillant à lire le premier chapitre.
Ces 230 pages, saupoudrées par des interventions régulières et appréciables d'expert dans les méthodes agiles, constitue un condensé d'informations et un tout permettant de s'initier à la gestion de projet agile. Le lecteur pourra de plus revenir régulièrement sur l'ouvrage dans sa mise en pratique des méthodes agiles.

Partant du constat que seul un faible pourcentage des projets informatiques sont de véritables réussites, de nouvelles méthodologies projet ont vu le jour pour pallier les manques et améliorer les méthodes dites traditionnelles. "Gestion de projet : vers les méthodes agiles" a donc pour vocation principale la synthèse des principales méthodes agiles utilisées actuellement (Scrum, XP...), présentées au travers de toutes les étapes qui constituent un projet informatique.

L'auteur commence par dresser le portait-type du chef de projet (à qui s'adresse principalement ce livre), et liste les composantes d'un projet (besoins, développements, rôles...). Vient ensuite une définition des méthodes agiles et une comparaison avec les méthodes traditionnelles, puis l'application dans le monde concret de la gestion projet.

Véronique Messager Rota fait donc naviguer le lecteur sur les différentes étapes d'un projet informatique en expliquant les pratiques agiles à mettre en place pour gérer, entre autres, son équipe, le client, le planning, les ressources, autrement dit : l'avant, le pendant et l'après-projet. Tout au long de ces étapes on lira les témoignages, sous la forme d'interviews, d'acteurs et d'utilisateurs reconnus de ces méthodes, expliquant leur retour d'expérience sur des questions précises de la vie d'un projet. Côté logiciel, quelques pages en fin d'ouvrage listent les outils incontournables (payant ou gratuit) pour la gestion d'un projet, une bonne base pour se jeter dans le grand bain.

Au final, ce livre est un bon compagnon pour introduire les concepts agiles (même si on sent (trop ?) la partie prenante de l'auteur pour Scrum), pour connaître les erreurs à éviter ainsi que les implications humaines et techniques qu'il faut absolument considérer. C'est cependant un livre un peu court (232 pages) qui reste une introduction et qui parfois enfonce des portes ouvertes en expliquant que le bon sens et la pratique sont nécessaires au succès d'un projet. La lecture est aisée car l'ouvrage est vraiment très proche de la réalité. Et même si le sujet s'adresse principalement aux chefs de projet (ou futurs chefs de projet) à convertir, le développeur trouvera également matière à satisfaire sa curiosité dans le domaine.

Si tout comme moi, vous ne connaissez les méthodes agiles que de nom, ce livre est pour vous. Il est très clair, agréable à lire et honnête.
Au fur et à mesure que l'on avance dans la lecture, on sent que les auteurs ont une expérience certaine des méthodes agiles. Ils proposent des moyens qu'ils ont mis en pratique, ils ne cachent pas les risques, et posent même des conditions pour que cela fonctionne.

Pratiquement, ce livre est composée de trois partie :

La première est une présentation des méthodes agiles, sous une forme très intéressante. En effet, au lieu de faire du bourrage de crâne sur des concepts théoriques, les auteurs présentent l'Extreme Programming par le biais de l'intégration d'un nouveau arrivant dans une équipe agile.
L'équipe nous est présentée petit à petit, au fur et à mesure des rencontres que ce nouvel arrivant fait. Le chef d'équipe lui présentant le rôle de chacun, tout en lui laissant la possibilité de poser des questions.
Le genre de question qu'un non initié se poserait réellement.

La seconde partie présente plus en détail les pratiques des méthodes agiles ( Programmation en binôme, Integration continue, Client sur site, .. ). Les auteurs présentent encore une fois des exemples basés sur leur expérience.
Ils présentent aussi les conditions pour que cela marche, et des alternatives si ces conditions ne sont pas réunies.
De plus, chaque pratique ne s'adresse pas à tout les membres de l'équipe, ils ciblent les rôles intéressés en début de chapitre. Et comme une pratique est souvent en relation avec d'autres, dès que c'est le cas, les auteurs proposent un renvoi vers celles-ci.

La dernière partie est un peu plus poussée, et propose les valeurs sur lesquelles se basent les méthodes agiles.

C'est pour moi, un excellent ouvrage, et en tout cas, il m'a convaincu sur les méthodes agiles, et m'a donné l'envie d'essayer.

Bien que pas assez synthétique à mon goût, "The art of Agile Development" reste un ouvrage de référence car il contient de très nombreux conseils et rappels sur les bonnes pratiques à adopter pour effectuer un développement logiciel maîtrisé, en amenant de la valeur ajoutée et en se focalisant sur les individus. Vous y retrouverez une analyse des préceptes du Agile Manifesto, croisé avec le "Manifesto for Software Craftsmanship".

Les auteurs ne se sont pas cependant limités à cette analyse et le livre porte également des conseils issus de leur expérience. Il vous aidera à mieux comprendre ce que représente "l'agilité" en termes d'ingénierie logicielle, ce qu'est XP et les analogies avec les autres approches "agiles" comme Scrum ou le Lean. Il est divisé en nombreux sous-chapitres qui contiennent, pour chaque description de la bonne pratique (presque des patterns parfois), les questions les plus fréquentes sur l'application du principe, les résultats attendus et observables, les contre-indications, ainsi que les alternatives. Très "Open-minded" donc.

Concrètement, vous serez amené à découvrir XP et ses différentes phases (Planning, Analysis, Design et Coding, Testing, Deployment), les rôles nécessaires, des recommandations pour renforcer la cohésion des équipes et l'organisation des bureaux, la maîtrise des espaces d'information, l'art d'effectuer des rétrospectives et Kaizen efficaces, les Stands-Up meetings, l'intérêt d'une forge logicielle pratique et résolument orientée vers le testing et l'intégration continue, TDD, etc.

Mon avis est ainsi particulièrement positif, et j'aurai certainement l'occasion de relire des parties de ce référentiel. Une lecture appropriée à tout développeur, mais également aux DSI qui souhaitent développer une informatique reposant sur des valeurs très fortes de participation, de confiance, de développement personnel, et de valeur ajoutée logicielle.

On parle Java dans tout le livre, mais chaque conseil est pour tous les langages. De plus, le framework a été porté pour fonctionner avec presque tous les langages. L'approche de Kent Beck est agréable et didactique. On construit vraiment au fur et à mesure, petit pas par petit pas. Le premier exemple est simple, gérer de l'argent dans différentes devises, et ce petit exemple nous mène déjà loin.

En fait, les exemples servent juste à bien nous asséner le principe de Beck, tester en construisant progressivement. Si on a compris qu'on doit toujours tout tester et qu'aucun code ne doit être buggé quand on arrête le travail, on a compris le livre. Ensuite, l'auteur nous donne des astuces, des patterns pour avancer, comme écrire des tests isolés, ne dépendant pas de toute l'architecture afin de ne pas déprimer - important... -, faire des raisonnements inductifs pour généraliser une réponse, ...

Depuis la lecture de ce livre, je me suis mis aux tests. J'avoue qu'avant, c'était la dernière de mes préoccupations. Maintenant, mon code est plus propre - on dirait une pub de lessive, là -, et surtout bardé de tests au cas où j'aurai une modification au niveau de l'architecture à faire - refactoring, et ça arrive souvent -. En même temps, je n'applique pas sa solution à 100%, c'est tout de même très difficile, ça demande du temps d'écrire le test avant d'avoir la solution qui va avec, mais on voit aussi comment on avance, c'est bien ;)

Cet ouvrage a pour objectif de présenter l'ensemble des concepts des architectures orientées services (SOA) en se concentrant sur leurs aspects pratiques. La première constatation est que le livre est bien structuré. Après une présentation générale en quelques pages de SOA, puis ses concepts principaux il se concentre progressivement sur les différents concepts liés à ce type d'architecture. On notera également que l'auteur justifie d'une bonne maîtrise du sujet. .De nombreux exemples tirés de situations professionnelles viennent illustrer l'ensemble des pièges qu'il est possible de rencontrer à la mise en place d'une architecture SOA. L'auteur cherche ici à mettre en avant, pour chaque choix à effectuer, les différentes possibilités en mettant sur la balance les pour et les contres dans un souci constant de neutralité. L'auteur cherche ici à argumenter dans un souci constant de neutralité les avantages et les inconvénients de chaque architecture proposée.

S'il est vrai que cette neutralité nous évite de tomber dans les travers d'une solution présentée comme miracle, sans souci et capable de résoudre tous les maux, il reste cependant qu'au fil de la lecture, on finit parfois par ne plus savoir quel choix serait le plus judicieux dans une situation donnée. En ce sens, cet ouvrage ne peut être considéré comme un guide mais plutôt comme un panorama qui s'adressera essentiellement aux personnes souhaitant se familiariser avec SOA. Il accompagnera ceux qui, ayant jeté leur dévolu sur cette architecture, souhaitent avoir à l'esprit l'ensemble des pièges à éviter. Mais il ne pourra répondre aux attentent de ceux qui tentent de mettre en pratique certains aspects précis d'une architecture SOA. Le titre donné à cet ouvrage "SOA In practice » peut donc induire en erreur.

On pourra reprocher également aux chapitres 2 et 3 de s'appuyer sur l'évolution des définitions Wikipedia pour présenter les concepts de SOA. On regrettera également que, bien que l'auteur nous répète tout au long du livre que les Services Web ne sont pas l'unique moyen d'implémenter des services dans une architecture SOA, on termine l'ouvrage sans avoir une vision claire de ce à quoi peut ressembler un service non web dans SOA. Enfin, bien que l'auteur insiste tout au long du livre que les Services Web ne sont pas l'unique moyen d'implémenter des services dans une architecture SOA, on regrettera de ne pas avoir au final une vision claire de ce à quoi peut ressembler un service non web dans SOA.

"Conduite de projet Web" est avant tout un retour d'expérience de 4 professionnels, chacun spécialisé dans ses domaines. Ils nous montrent les enjeux d'un projet web, les différentes phases de la conduite de projet, le rôle de chacun, les choses à faire et celles à éviter, les aspects techniques, organisationnels, financiers, marketing, juridiques... L'ouvrage est très bien structuré ce qui le rend extrêmement facile à intégrer. Vous disposez d'un guide de lecture qui vous permet de sélectionner certains chapitres selon votre profil (étudiant, chef de projet, dirigeant, etc.), et selon vos objectifs (sensibilisation, maîtrise des aspects juridiques, etc.). Beaucoup d'apartés vous sont proposés en plus, on trouve par exemple les multiples définitions, les questions clés, les repères, les check-lists, les bonnes pratiques, ainsi que les avis d'expert.

Un des atouts de ce livre est le travail fait autour des livrables. Après avoir vu la spécification technique, le cahier des charges, la maquette graphique, l'étude de faisabilité (...) vous allez directement pouvoir les réutiliser en entreprise grâce au Cd-rom d'accompagnement qui contient 60 modèles de document.

Pour finir, les études de cas (site institutionnel, B-to-B, portail d'entreprise) présentes dans les derniers chapitres apportent une dimension pratique à ce livre porté principalement sur la théorie.