IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

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

Dernière mise à jour : 22 septembre 2013 

precedentsommairesuivant
  1. Industrialiser le test fonctionnel - Des exigences métier au référentiel de tests automatisés
  2. Beautiful Testing - Leading Professionals Reveal How They Improve Software
  3. 97 Things Every Programmer Should Know
  4. Merise - Guide pratique
  5. SCRUM - le guide pratique de la méthode agile la plus populaire
  6. Gestion de projet - Vers les méthodes agiles
  7. 97 Things Every Software Architect Should Know
  8. Architecture logicielle
  9. Beautiful Architecture
  10. The Art of Unit Testing - With Examples in .NET
  11. Le chef de projet efficace
  12. Visualizing Data - Exploring and Explaining Data with the Processing Environment
  13. Le développement informatique durable
  14. Becoming Agile - in an imperfect world
  15. Coder proprement
  16. Gestion de projet : 40 outils pour agir
  17. Object-Oriented Thought Process, 2nd edition
  18. Manager un projet informatique
  19. CMMI - Un itinéraire fléché vers le Capability Maturity Model Intégration
  20. Extreme programming - précis et concis
  21. Gestion de projet - EXtreme Programming
  22. Gestion de projet - Vers les méthodes agiles
  23. The Art of Agile Development
  24. Test-Driven Development - By Example
  25. SOA In Practice - The art of Distributed System Design
  26. Conduite de projet Web - 3 Etudes de cas
couverture du livre Industrialiser le test fonctionnel

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Industrialiser le test fonctionnel

Des exigences métier au référentiel de tests automatisés

de Bruno Legeard, Fabrice Bouquet et Natacha Pickaert

Résumé de l'éditeur

Cet ouvrage s'adresse à tous les chefs de projets et aux personnes qui ont à mettre en place une stratégie et une organisation de tests pour les applications dont ils ont la charge. Il concerne également les DSI, les responsables méthodes et qualité qui ont à guider les méthodes de travail de leurs équipes.

Ce livre traite du test fonctionnel au cours des différentes phases de qualification. Il montre comment la conception, puis la construction et la mise en ouvre des tests peuvent s'appuyer sur des processus systématiques et « industrialisables ».

Ce livre est prolongé par un site de référence sur le test fonctionnel accessible à l'adresse suivante : www.portaildutest.fr

304 pages, 2e édition, 1er novembre 2011 

Édition : Dunod

ISBN10 : 2100566563

ISBN13 : 9782100566563

Commandez sur www.amazon.fr :

33.25 € TTC seulement (au lieu de 35.00  € TTC : prix éditeur) livraison gratuite !

Situation du test fonctionnel

  • Qualité et qualification logicielle
  • Besoins d'industrialisation

Industrialiser le test fonctionnel - Processus et organisation

  • De l'analyse des besoins métier au référentiel des tests
  • Définition de la stratégie de test fonctionnel
  • Les outils du test fonctionnel
  • Production du référentiel de tests
  • Préparation et exécution des tests
  • Déploiement du processus
  • Industrialisation des organisations de test

Études de cas

  • Application OrangeHRM
  • Module de mise à jour dans e-Greta
  • L'application eTicketing Parkeon
  • Postambule

 
Critique du livre par la rédaction Nicolas Vallée (gorgonite) le 1er décembre 2011 

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 Donner une note à l´article (5)

 
couverture du livre Beautiful Testing

Note 4.0drapeau
Détails du livre
Critiques (1)
 
 

Beautiful Testing

Leading Professionals Reveal How They Improve Software

de Tim Riley, Adam Goucher

Résumé de l'éditeur

This unique book offers essays from 25 leading software testers that illustrate the qualities and techniques necessary to make software testing an art in itself. The latest entry in O'Reilly's successful series that includes "Beautiful Code" (9780596510046) and "Beautiful Teams" (9780596518028), this book demonstrates through personal stories and many examples the simplicity, maintainability, flexibility, and efficiency required to test every aspect of a software project.

Commentez Donner une note à l´article (4)

352 pages, 1re édition, 1er octobre 2009 

Édition : O'Reilly

ISBN10 : 0596159811

ISBN13 : 9780596159818

Commandez sur www.amazon.fr :

38,33 € TTC (prix éditeur 41,11 € TTC) livraison gratuite !
Critique du livre par la rédaction Matthieu Brucher le 1er septembre 2010 

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.

 
couverture du livre 97 Things Every Programmer Should Know

Note 4.0drapeau
Détails du livre
Critiques (2)
 
 

97 Things Every Programmer Should Know

de Kevlin Henney (Sous la direction de)

Résumé de l'éditeur

Tap into the wisdom of experts to learn what every programmer should know, no matter what language you use. With the 97 short and extremely useful tips for programmers in this book, you'll expand your skills by adopting new approaches to old problems, learning appropriate best practices, and honing your craft through sound advice.

With contributions from some of the most experienced and respected practitioners in the industry - including Michael Feathers, Pete Goodliffe, Diomidis Spinellis, Cay Horstmann, Verity Stob, and many more - this book contains practical knowledge and principles that you can apply to all kinds of projects.

Commentez Donner une note à l´article (4)

256 pages, 1re édition, 1er mars 2010 

Édition : O'Reilly

ISBN10 : 0596809484

ISBN13 : 9780596809485

Commandez sur www.amazon.fr :

22,84 € TTC (prix éditeur 25,78 € TTC) livraison gratuite !
Critique du livre par la rédaction Eric Reboisson le 1er août 2010 

"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.

Critique du livre par la rédaction Eric Siber le 1er août 2010 

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.

 
couverture du livre Merise

Note 3.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Merise

Guide pratique

de Jean Luc BAPTISTE
Public visé : Intermédiaire,Expérimenté

Résumé de l'éditeur

Ce livre sur la méthode Merise s'adresse tout particulièrement aux étudiants en premier cycle d'informatique, aux étudiants en école de gestion et à toute personne souhaitant une information simple, directe et pratique sur la méthode Merise et sur le langage SQL. Dans la partie sur la méthode Merise, vous découvrirez comment : - Réaliser les différents modèles (modèles conceptuels, modèles logiques, modèles physiques) mais aussi les modèles spécifiques aux traitements (modèles conceptuels des traitements, modèles organisationnels des traitements...). - Modéliser avec les extensions Merise/2. - Comparer certains modèles Merise à certains diagrammes UML. Le langage SQL est présenté de façon progressive et est illustré par de nombreux exemples. Dans cette partie vous apprendrez à : - Manipuler, filtrer, trier, regrouper les données. - Créer, modifier, supprimer des tables. - Affecter ou enlever des droits à certains utilisateurs. L'auteur n'a volontairement gardé que le côté concret de la méthode Merise et du langage SQL, pour permettre au lecteur une immersion immédiate. Il propose de nombreux exercices pour faciliter cette assimilation.

5 commentaires Donner une note à l´article (3.5)

262 pages, 2e édition, 1er mai 2009 

Édition : ENI

ISBN10 : 2746048450

ISBN13 : 9782746048454

www.editions-eni.fr : 28,40 € TTC seulement seulement (au lieu de 29,90 € TTC : prix public)

Commandez sur www.amazon.fr :

28,40 € TTC (prix éditeur 29,90 € TTC) livraison gratuite !
  • PRESENTATION DE LA METHODE MERISE
  • LES DEPENDANCES FONCTIONNELLES
  • LE MODELES CONCEPTUEL DES DONNEES
  • LE MODELE LOGIQUE DE DONNEES
  • LE MODELE PHYSIQUE DES DONNEES
  • LES FORMES NORMALES
  • LES DIAGRAMMES DE FLUX
  • LES MODELES CONCEPTUELS DES TRAITEMENTS
  • LE MODELES ORGANISATIONNEL DES TRAITEMENTS
  • LES EXTENSIONS MERISE

 
Critique du livre par la rédaction Ernaelsten Gérard le 1er avril 2010 

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

 
couverture du livre SCRUM

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (3)
 
 

SCRUM

le guide pratique de la méthode agile la plus populaire

de Claude Aubry

Résumé de l'éditeur

Cet ouvrage s'adresse aux développeurs qui souhaitent s'initier aux méthodes de développement agile, et aux chefs de projet qui veulent améliorer l'organisation et l'efficacité de leurs équipes. Il sera également très utile à ceux qui ont déjà une première expérience de Scrum et qui souhaitent maîtriser la méthode en profondeur. Le but affiché d'une méthode agile est d'améliorer la qualité du produit, tout en réduisant les délais et les coûts. Aujourd'hui Scrum s'est imposée comme la plus répandue des méthodes agiles. Quand on applique Scrum les fonctionnalités sont collectées dans un backlog et classées par priorité. Une version (release) est produite à l'issue d'une série d'itérations, appelées sprints. Pendant un sprint des points de contrôle sont effectués par l'équipe au cours de " mêlées " quotidiennes appelées scrums. Cet ouvrage rassemble non seulement une présentation détaillée des pratiques, mais aussi de nombreux conseils concrets issus de la vraie vie. Il commence par une présentation des méthodes agiles et de Scrum. Il explique ensuite les rôles des deux personnages-clé que sont le ScrumMaster et le Product Owner. Les chapitres suivants expliquent comment organiser et mener à son terme un projet en appliquant Scrum.

9 commentaires Donner une note à l´article (5)

268 pages, 1re édition, 1er février 2010 

Édition : Dunod

ISBN10 : 2100540181

ISBN13 : 9782100540181

Commandez sur www.amazon.fr :

28,02 € TTC (prix éditeur 29,05 € TTC) livraison gratuite !
  • Scrum sous la bannière de l'agilité
  • Des sprints pour une release
  • Le Product Owner
  • Le ScrumMaster et l'équipe
  • Le backlog de produit
  • La planification de release
  • La réunion de planification de sprint
  • Le scrum quotidien
  • La revue de sprint
  • La rétrospective de sprint
  • La signification de fini
  • Adapter Scrum au contexte
  • De la vision aux stories
  • De la story aux tests d'acceptation
  • Estimations, mesures et indicateurs
  • Scrum et l'ingénierie du logiciel
  • Scrum avec un outil
  • La transition à Scrum
  • Scrum en France

 
Critique du livre par la rédaction nico-pyright(c) le 1er septembre 2010 

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".

Critique du livre par la rédaction Pierre Chauvin le 1er février 2010 

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".

Critique du livre par la rédaction Bruno Orsier le 1er février 2010 

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 !

 
couverture du livre Gestion de projet

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Gestion de projet

Vers les méthodes agiles

de Véronique Messager Rota

Résumé de l'éditeur

Cet ouvrage rassemble plus de dix années d'expérience en gestion de projet informatique, et compare les méthodologies traditionnelles - qui définissent à l'avance les besoins et organisent les activités à réaliser, leur séquencement, les rôles et les livrables à produire - aux méthodes agiles.

Ces dernières prennent le contre-pied des méthodes prédictives en évitant une définition trop précoce et figée des besoins ; elles ont montré une surprenante efficacité en pariant sur la souplesse des équipes. Ce guide aidera les chefs de projet, déjà familiarisés avec les méthodes traditionnelles de conduite de projet et attirés par les méthodes dites " agiles " ou débutant dans le métier, à évaluer et améliorer leurs compétences en gestion de projet. Il guidera également architectes, analystes, développeurs ou testeurs dans la conduite de leurs projets, ainsi que tous les clients ou experts métier non informaticiens souhaitant appréhender rapidement les enjeux et la répartition des rôles au sein d'un projet.

1 commentaire Donner une note à l´article (5)

272 pages, 2e édition, 1er mai 2009 

Édition : Eyrolles

ISBN10 : 2212125186

Eyrolles : 28,40 € TTC seulement seulement (au lieu de 29,90 € TTC : prix public)

Commandez sur www.amazon.fr :

28,40 € TTC (prix éditeur 29,90 € TTC) livraison gratuite !
  • Introduction - Chef de projet : un métier complexe
  • Diagnostiquer sa gestion de projet
  • Méthodes traditionnelles ou méthodes agiles ?
  • Recueillir efficacement les besoins
  • Planifier son projet
  • Suivre et piloter son projet
  • Gérer les hommes
  • Adopter une approche agile
  • Annexe A : Présentation des coachs
  • Annexe B : Les outils de gestion de projet
  • Annexe C : Glossaire
  • Annexe D : Bibliographie

 
Critique du livre par la rédaction Arnaud Lemercier le 1er octobre 2009 

"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.

 
couverture du livre 97 Things Every Software Architect Should Know

Note 4.0drapeau
Détails du livre
Critiques (1)
 
 

97 Things Every Software Architect Should Know

de Richard Monson-Haefel
Public visé : Tous

Résumé de l'éditeur

In this truly unique technical book, today's leading software architects present valuable principles on key development issues that go way beyond technology. More than four dozen architects -- including Neal Ford, Michael Nygard, and Bill de hOra -- offer advice for communicating with stakeholders, eliminating complexity, empowering developers, and many more practical lessons they've learned from years of experience. Among the 97 principles in this book, you'll find useful advice such as:

  • Don't Put Your Resume Ahead of the Requirements (Nitin Borwankar)
  • Chances Are, Your Biggest Problem Isn't Technical (Mark Ramm)
  • Communication Is King; Clarity and Leadership, Its Humble Servants (Mark Richards)
  • Simplicity Before Generality, Use Before Reuse (Kevlin Henney)
  • For the End User, the Interface Is the System (Vinayak Hegde)
  • It's Never Too Early to Think About Performance (Rebecca Parsons)

To be successful as a software architect, you need to master both business and technology. This book tells you what top software architects think is important and how they approach a project. If you want to enhance your career, 97 Things Every Software Architect Should Know is essential reading.

Commentez Donner une note à l´article (4)

220 pages, 1re édition, 17 mars 2009 

Édition : O'Reilly

ISBN10 : 059652269X

ISBN13 : 9780596522698

Commandez sur www.amazon.fr :

31,96 € TTC (prix éditeur 31,53 € TTC) livraison gratuite !
Critique du livre par la rédaction Eric Reboisson le 1er août 2009 

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 !

 
couverture du livre Architecture logicielle

Note 4.0drapeau
Détails du livre
Sommaire
Critiques (2)
 
 

Architecture logicielle

de Jacques Printz
Public visé : Architecte professionnel - expert

Résumé de l'éditeur

Ce livre s'adresse d'abord aux architectes, et aux décideurs DSI, maîtrise d'ouvrage, chefs de projets. Il intéressera également les élèves ingénieurs des grandes écoles et les étudaints au niveau du master.

Il explicite la place de l'architecture logicielle dans les projets et justifie pourquoi les contraintes de simplicité, de disponibilité et d'évolutivité doivent être prises en compte dès la conception.

Cet ouvrage propose des modèles d'architectures indépendants des technologies utilisées qui permettent de garantir la qualité. Il replace les concepts architecturaux récents (client/serveur, SOA, MDA, WSDL, BPM, BPEL, REST...) sur les bases solides que sont les traducteurs, la communication inter-processus, les transactions, les machines virtuelles. Il est structuré en quatre parties :

  • La première présente la problématique de l'architecture logicielle dans sa globalité en insistant sur les correspondances entre lde mond réel et les modèles.
  • La deuxième explique les concepts fondateurs que sont l'architecture des compilateurs, l'architecture des processus et leur synchronisation.
  • La troisème définit les principes des architectures fonctionnes logiques et de leur construction méthodique.
  • La dernières explique comment parvenir à respecter les quatre propriétés fondamentales des architectures : la simplicité, la disponibilité et la sûreté de fonctionnement, l'adaptabilité et l'évolutivité et enfin la construction des interfaces.

Dans cette deuxième édition, un nouveau chapitre est consacré au métier d'architecte, à la façon d'aborder la complexité, et à la logique sous-jacente pour résoudre les problèmes d'architecture.

4 commentaires Donner une note à l´article (4.5)

451 pages, 2e édition, 1er mars 2009 

Édition : Dunod

ISBN10 : 210052674X

ISBN13 : 9782100526741

Commandez sur www.amazon.fr :

37,05 € TTC (prix éditeur 39,00 € TTC) livraison gratuite !
  • PARTIE 1 - QU'EST-CE QUE L'ARCHITECTURE DU LOGICIEL ?
  • L'architecture dans les sciences de l'ingénieur
  • Les matériaux de l'architecture logicielle
  • Propriétés indésirables des entités architecturales
  • Représentations de l'architecture - Symboles architecturaux - Diagrammes d'architecture
  • Place de l'architecture dans les projets informatiques
  • PARTIE 2 - ANALYSE DE DEUX CHEFS-D'OEUVRE D'ARCHITECTURE
  • Principes d'architecture des compilateurs
  • Architecture des processus et de leurs interactions dans une machine
  • PARTIE 3 - ARCHITECTURE FONCTIONNELLE LOGIQUE
  • Principes et règles de construction des architectures fonctionnelles logiques
  • Propriétés sémantiques des intégrats - Transactions - Services
  • Quelques modèles d'architectures
  • Clients et serveurs
  • PARTIE 4 - PROPRIÉTÉS D'UNE BONNE ARCHITECTURE
  • Simplicité - Complexité
  • Disponibilité - Sûreté de fonctionnement
  • Adaptabilité - Évolutivité
  • Interfaces
  • Le métier de l'architecte : complexité, logique, intuition
  • CONCLUSION
  • Sigles et acronymes utilisés
  • Glossaire commenté
  • Bibliographie

 
Critique du livre par la rédaction benwit le 1er mai 2010 

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.

Critique du livre par la rédaction Doeraene Sébastien le 1er juillet 2010 

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.

 
couverture du livre Beautiful Architecture

Note 3.0drapeau
Détails du livre
Critiques (2)
 
 

Beautiful Architecture

de Diomidis Spinellis, Georgios Gousios
Public visé : Tous

Résumé de l'éditeur

What are the ingredients of robust, elegant, flexible, and maintainable software architecture? Beautiful Architecture answers this question through a collection of intriguing essays from more than a dozen of today's leading software designers and architects. In each essay, contributors present a notable software architecture, and analyze what makes it innovative and ideal for its purpose.

1 commentaire Donner une note à l´article (3)

426 pages, 1re édition, 1er mars 2009 

Édition : O'Reilly

ISBN10 : 059651798X

ISBN13 : 9780596517984

Commandez sur www.amazon.fr :

40,14 € TTC (prix éditeur 40,86 € TTC) livraison gratuite !
Critique du livre par la rédaction Eric Reboisson le 1er août 2009 

"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...

Critique du livre par la rédaction Matthieu Brucher le 1er août 2009 

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.

 
couverture du livre The Art of Unit Testing

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

The Art of Unit Testing

With Examples in .NET

de Roy Osherove
Public visé : Spécialiste, Expérimenté

Résumé de l'éditeur

Unit testing, done right, can mean the difference between a failed project and a successful one, between a maintainable code base and a code base that no one dares touch, and between getting home at 2 AM or getting home in time for dinner, even before a release deadline.

The Art of Unit Testing builds on top of what's already been written about this important topic. It guides you step by step from simple tests to tests that are maintainable, readable, and trustworthy. It covers advanced subjects like mocks, stubs, and frameworks such as Typemock Isolator and Rhino Mocks. And you'll learn about advanced test patterns and organization, working with legacy code and even untestable code. The book discusses tools you need when testing databases and other technologies. It's written for .NET developers but others will also benefit from this book.

Commentez Donner une note à l´article (5)

320 pages, 1re édition, 28 mars 2009 

Édition : Manning

ISBN10 : 1933988274

ISBN13 : 9781933988274

Broché, 898 x 94 x 748

www.manning.com : 39.99 $ seulement

Commandez sur www.amazon.fr :

28.57 € TTC (prix éditeur 28.16 $) livraison gratuite !

Part 1 Getting started

  • 1 The basics of unit testing
  • 2 A first unit test

Part 2 Core techniques

  • 3 Using stubs to break dependencies
  • 4 Interaction testing using mock objects
  • 5 Isolation (mock object) frameworks

Part 3 The test code

  • 6 Test hierarchies and organization
  • 7 The pillars of good tests

Part 4 Design and process

  • 8 Integrating unit testing into the organization
  • 9 Working with legacy code
  • Appendix A : Design and testability
  • Appendix B : Extra tools and frameworks

 
Critique du livre par la rédaction Philippe Vialatte le 26 juillet 2009 

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.

 
couverture du livre Le chef de projet efficace

Note 3.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Le chef de projet efficace

de Alain Fernandez

Résumé de l'éditeur

Ce guide pratique, conçu à partir de la connaissance cumulée de plusieurs dizaines de chefs de projet, réunit les conditions nécessaires pour maîtriser l'art de la subtile symbiose entre les hommes, les techniques et les enjeux : 8 témoignages sur le vif ; 12 pratiques de bon sens pour réussir ; 21 recommandations détaillées ; une méthodologie complète. En complément, documents, dossiers et livres blancs sont téléchargeables depuis le site www.chef de-projet.org.

Commentez Donner une note à l´article (4)

200 pages, 3e édition, 1er décembre 2008 

Édition : Eyrolles

ISBN10 : 2212542488

ISBN13 : 9782212542486

Broché

http://www.eyrolles.com : 16.15 € TTC seulement seulement (au lieu de 17 € TTC : prix public)

Commandez sur www.amazon.fr :

16.15 € TTC seulement (au lieu de 17  € TTC : prix éditeur) livraison gratuite ! (voir conditions)
  1. Introduction Manager un projet : une affaire de « bon sens »
  2. En préambule Conduire un projet : une démarche d'entrepreneur
  3. AXE 1 Maîtriser l'organisation du projet
    1. Témoignage de Charles Il n'y a pas que des copains dans l'entreprise
    2. 1ère pratique de bon sens - Construire le référentiel de valeurs
    3. Témoignage de Hans Passer du comptable au pit-bull, une bonne recette pour échouer
    4. 2ème pratique de bon sens - Privilégier la réactivité
    5. Sept recommandations pour mieux maîtriser l'organisation
  4. AXE 2 Dynamiser la coopération étendue
    1. Témoignage de Cécile Le chef de projet est le chef d'orchestre
    2. 3ème pratique de bon sens - Synchroniser les rôles
    3. 4ème pratique de bon sens - Abandonner le management autoritaire
    4. Témoignage de Clara Le nouveau est un tire-au-flanc' qui sait aussi tirer les bonnes ficelles
    5. 5ème pratique de bon sens - Favoriser la coopération interne et externe
    6. Trois recommandations pour dynamiser la coopération des équipes
  5. AXE 3 Développer les outils d'assistance à l'anticipation
    1. Témoignage de Sabrina De la précision des informations collectées
    2. 6ème pratique de bon sens - Mesurer la performance pour assister la prise de décision
    3. Témoignage de Rémi Comment j'utilise mon tableau de bord
    4. 7ème pratique de bon sens - Assurer le suivi des enjeux
    5. 8ème pratique de bon sens - Adopter une démarche d'amélioration continue
    6. 9ème pratique de bon sens - Anticiper les risques d'échec
    7. Quatre recommandations pour bâtir une assistance efficace à l'anticipation et au pilotage
  6. AXE 4 Faciliter l'intégration
    1. Témoignage de Dominique Le mépris ne paie pas
    2. 10ème pratique de bon sens - Intégrer les projets dans la chaîne de valeur
    3. Témoignage de José-Miguel Pour réussir le changement, éviter les classements a priori
    4. 11ème pratique de bon sens - Assurer un pilotage actif du changement
    5. 12ème pratique de bon sens -Intégrer les coûts directs et indirects du processus d'intégration dans les budgets initiaux
    6. Quatre recommandations pour réussir l'intégration du nouveau système
  7. Conclusion
    1. Coopérer, ce n'est pas toujours si simple
    2. La méthode de calcul du ROI conditionne le type d'investissement
    3. Trois recommandations complémentaires d'une portée plus globale
  8. Bibliographie
  9. Index

 
Critique du livre par la rédaction Emmanuel Lecoester le 1er juillet 2009 

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.

 
couverture du livre Visualizing Data

Note 3.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Visualizing Data

Exploring and Explaining Data with the Processing Environment

de Ben Fry
Public visé : débutant

Résumé de l'éditeur

Enormous quantities of data go unused or underused today, simply because people can't visualize the quantities and relationships in it. Using a downloadable programming environment developed by the author, Visualizing Data demonstrates methods for representing data accurately on the Web and elsewhere, complete with user interaction, animation, and more. How do the 3.1 billion A, C, G and T letters of the human genome compare to those of a chimp or a mouse? What do the paths that millions of visitors take through a web site look like? With Visualizing Data, you learn how to answer complex questions like these with thoroughly interactive displays. We're not talking about cookie-cutter charts and graphs. This book teaches you how to design entire interfaces around large, complex data sets with the help of a powerful new design and prototyping tool called "Processing." Used by many researchers and companies to convey specific data in a clear and understandable manner, the Processing beta is available free. With this tool and Visualizing Data as a guide, you'll learn basic visualization principles, how to choose the right kind of display for your purposes, and how to provide interactive features that will bring users to your site over and over. This book teaches you: The seven stages of visualizing data -- acquire, parse, filter, mine, represent, refine, and interact How all data problems begin with a question and end with a narrative construct that provides a clear answer without extraneous details Several example projects with the code to make them work Positive and negative points of each representation discussed. The focus is on customization so that each one best suits what you want toconvey about your data set The book does not provide ready-made "visualizations" that can be plugged into any data set. Instead, with chapters divided by types of data rather than types of display, you'll learn how each visualization conveys the unique properties of the data it represents -- why the data was collected, what's interesting about it, and what stories it can tell. Visualizing Data teaches you how to answer questions, not simply display information.

2 commentaires Donner une note à l´article (4)

382 pages, 1re édition, 11 janvier 2008 

Édition : O'Reilly UK

ISBN10 : 0596514557

ISBN13 : 9780596514556

Commandez sur www.amazon.fr :

28,83 € TTC (prix éditeur 31,85 € TTC) livraison gratuite !
  • The seven stages of visualizing data
  • Getting started with processing
  • Mapping
  • Time series
  • Connections and correlations
  • Scatterplot maps
  • Trees, hierarchies and recursion
  • Networks and graphs
  • Acquiring data
  • Parsing data
  • Integrating processing with java

 
Critique du livre par la rédaction hiko-seijuro le 13 mars 2008 

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.

 
couverture du livre Le développement informatique durable

Note 4.0drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Le développement informatique durable

de Félix Guillemot

Résumé de l'éditeur

Au coeur de cette discipline complexe qu'est le développement informatique, l'ingénieur d'étude est le garant de la qualité de nos systèmes d'information trop souvent mal menés. La sous-traitance à prix minimal de son travail jugé non stratégique, l'adoption de méthodologies de gestion de projet diverses sont les moyens aujourd'hui employés pour reprendre le contrôle des coûts et de la qualité. Or, le SI a besoin de retrouver ses maîtres d'oeuvre : des esprits dotés de savoir et de bon sens conduits par la méthode.

Le développement informatique durable propose une série de méthodes fondamentales telles l'écriture analytique, la méthode pas à pas ou le débogage par la division. La clé de la réussite réside dans la combinaison de ces méthodes. Les appliquer à notre travail de tous les jours jusqu'à ce qu'elles soient installées dans nos comportements nous amène à des performances et des facilités insoupçonnées.

9 commentaires Donner une note à l´article (4)

202 pages, 1re édition, 1er avril 2009 

Édition : Hermes Science Publications

ISBN10 : 2746222469

ISBN13 : 9782746222465

15,5 x 23

Lavoisier : 49 € TTC seulement

Commandez sur www.amazon.fr :

46.56 € TTC seulement (au lieu de 49  € TTC : prix éditeur) livraison gratuite !
  • Avant-propos.
  • La problématique du développeur.
    • L'informaticien en bleu de travail.
    • Le cycle de l'achat des développements.
    • Le nouvel âge du développement.
    • IDE, Framework et l'éloignement de la machine.
    • 2000 et la naissance d'un nouveau développeur.
    • Le développement conduit par la méthode.
  • L'alpha et l'oméga du développement.
    • L'écriture analytique.
    • L'utilité des commentaires du code enfin révélée.
  • La méthode pas à pas.
    • Présentation.
    • L'ordre du code.
    • L'écriture d'une chaîne procédurale : un processus récursif.
    • L'incursion des tests.
    • Le rétroraisonnement.
  • La forme qui structure.
    • L'utilisation des couleurs.
    • Le sens par la forme.
    • La présentation du code.
  • Diviser pour mieux débugger.
    • La division des difficultés.
    • Le débuggage par dichotomie.
    • Le débuggage par réduction.
  • Apprendre à chercher.
    • Définir la question.
    • Définir les mots-clés.
    • La recherche par association d'idées.
    • Exemple de recherche.
    • Schéma récapitulatif.
  • La gestion du temps.
    • La notion de limite.
    • La division du temps et la ponctualité.
  • Conclusion
  • Cas d'étude.

 
Critique du livre par la rédaction Laurent Dardenne le 1er juin 2009 

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.

 
couverture du livre Becoming Agile

Note 5.0drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Becoming Agile

in an imperfect world

de Greg Smith, Ahmed Sidky
Public visé : Débutant, Intermédiaire

Résumé de l'éditeur

Agile principles have been a breath of fresh air to many development teams stuck in the middle of a rigid, process-driven environment. Unfortunately, it's not easy to bring Agile into an existing organization with established people and practices. Becoming Agile shows you practical techniques and strategies to move from your existing process to an Agile process without starting from scratch.

Many books discuss Agile from a theoretical or academic perspective. Becoming Agile takes a different approach and focuses on explaining Agile from a ground-level point-of-view. Author Greg Smith, a certified ScrumMaster with dozens of Agile projects under his belt, presents Agile principles in the context of a case study that flows throughout the book.

Becoming Agile focuses on the importance of adapting Agile principles to the realities of your environment. While Agile purists have often discouraged a "partial-Agile" approach, the reality is that in many shops a "purist" approach simply isn't a viable option. Over the last few years, Agile authorities have begun to discover that the best deployments of Agile are often customized to the specific situation of a given company.

As well, Becoming Agile addresses the cultural realities of deploying Agile and how to deal with the needs of executives, managers, and the development team during migration. The author discusses employee motivation and establishing incentive that reward support of Agile techniques.

Becoming Agile will show you how to create a custom Agile process that supports the realities of you environment. The process will minimize risk as you transition to Agile iteratively, allowing time for your culture and processes to acclimate to Agile principles.

Commentez Donner une note à l´article (4)

410 pages, 1re édition, 1er mai 2009 

Édition : Manning

ISBN10 : 1933988258

ISBN13 : 9781933988252

www.manning.com : 44.99 $ seulement
Version PDF à $27.50

  • Part 1: Agile fundamentals and a supporting case study
    • Chapter 1 Moving to agile
    • Chapter 2 The story of Acme Media
  • Part 2: Getting started
    • Chapter 3 Are you ready for agile ?
    • Chapter 4 The fitness test: all about readiness assessments
    • Chapter 5 The importance of obtaining executive support
    • Chapter 6 Improving buy-in by creating a core team
    • Chapter 7 The mindset of an agile leader
    • Chapter 8 Injecting agility into your current process
    • Chapter 9 Selecting a pilot project
  • Part 3: Kicking off
    • Chapter 10 Feasibility: is this project viable?
    • Chapter 11 Aligning the pilot team with the project
  • Part 4: Populating the product backlog
    • Chapter 12 Feature cards: a tool for "just enough" planning
    • Chapter 13 Prioritizing the backlog
    • Chapter 14 Estimating at the right level with the right people
  • Part 5: Enough information for scheduling
    • Chapter 15 Release planning: envisioning the overall schedule
    • Chapter 16 Iteration planning: the nitty-gritty details
  • Part 6: Building the product
    • Chapter 17 Start your engines: iteration 0
    • Chapter 18 Delivering working software
    • Chapter 19 Testing: did you do it right?
  • Part 7: Embracing change
    • Chapter 20 Adapting: reacting positively to change
    • Chapter 21 Delivery: bringing it all together
    • Chapter 22 The restrospective: working together to improve
  • Part 8: Moving forward
    • Chapter 23 Extending the new process across your company
  • Appendix
    • appendix A: Readiness assessment tables by practice
    • appendix B: Agile concepts from a phase perspective
    • appendix C: Agile process overview in text
    • appendix D: Example: determining process and document needs for a project
    • appendix E: Quantitative feedback on the SAMI

 
Critique du livre par la rédaction Eric Siber le 30 mai 2009 

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.

 
couverture du livre Coder proprement

Note 5.0drapeau
Détails du livre
Sommaire
Critiques (3)
 
 

Coder proprement

de Robert C.Martin
Public visé : Tous niveaux (savoir lire du Java est recommandé)

Résumé de l'éditeur

Nettoyez votre code et devenez plus performant !

Si un code sale peut fonctionner, il peut également compromettre la pérennité d'une entreprise de développement de logiciels. Chaque année, du temps et des ressources sont gaspillés à cause d'un code mal écrit. Toutefois, ce n'est pas une fatalité.

Grâce à cet ouvrage, vous apprendrez à rédiger du bon code, ainsi qu'à le nettoyer "à la volée", et vous obtiendrez des applications plus robustes, plus évolutives et donc plus durables. Concret et pédagogique, ce manuel se base sur les bonnes pratiques d'une équipe de développeurs aguerris réunie autour de Robert C. Martin, expert logiciel reconnu. Il vous inculquera les valeurs d'un artisan du logiciel et fera de vous un meilleur programmeur.

Coder proprement est décomposé en trois parties. La première décrit les principes, les pratiques et les motifs employés dans l'écriture d'un code propre. La deuxième est constituée de plusieurs études de cas à la complexité croissante. Chacune d'elles est un exercice de nettoyage : vous partirez d'un exemple de code présentant certains problèmes, et l'auteur vous expliquera comment en obtenir une version saine et performante. La troisième partie, enfin, sera votre récompense. Son unique chapitre contient une liste d'indicateurs éprouvés par l'auteur qui vous seront précieux pour repérer efficacement les défauts de votre code.

Après avoir lu ce livre, vous saurez
  • faire la différence entre du bon et du mauvais code ;
  • écrire du bon code et transformer le mauvais code en bon code ;
  • choisir des noms, des fonctions, des objets et des classes appropriés ;
  • mettre en forme le code pour une lisibilité maximale ;
  • implémenter le traitement des erreurs sans perturber la logique du code ;
  • mener des tests unitaires et pratiquer le développement piloté par les tests.

Véritable manuel du savoir-faire en développement agile, cet ouvrage est un outil indispensable à tout développeur, ingénieur logiciel, chef de projet, responsable d'équipe ou analyste des systèmes dont l'objectif est de produire un meilleur code.

15 commentaires Donner une note à l´article (5)

450 pages, 1re édition, 1er février 2009 

Édition : Campus Press / Pearson

ISBN10 : 2744023272

ISBN13 : 9782744023279

Commandez sur www.amazon.fr :

36,10 € TTC (prix éditeur 38,00 € TTC) livraison gratuite !
  • Code propre
  • Noms significatifs
  • Fonctions
  • Commentaires
  • Mise en forme
  • Objets et structures de données
  • Gestion des erreurs
  • Limites
  • Tests unitaires
  • Classes
  • Systèmes
  • Émergences
  • Concurrence
  • Améliorations successives
  • Au coeur de JUnit
  • Remaniement de SerialDate
  • Indicateurs et Heuristiques

 
Critique du livre par la rédaction benwit le 1er août 2010 

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.

Critique du livre par la rédaction Baptiste Wicht le 1er juillet 2009 

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.

Critique du livre par la rédaction Doeraene Sébastien le 4 mai 2009 

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.

 
couverture du livre Gestion de projet : 40 outils pour agir

Note 3.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Gestion de projet : 40 outils pour agir

de Fouad Bouchaouir, Yannick Dentinger, Olivier Englender
Public visé : Intermédiaire

Résumé de l'éditeur

- De l'idée à sa finalisation, optimisez les 3 variables de votre projet : coûts, délais et moyens
- Temps, intervenants, composantes financières et techniques, qualité. sachez analyser, anticiper, réagir ou valider
- Exemples concrets, modèles de documents transposables et adaptables à tous les environnements

Construire un ensemble immobilier, concevoir une voiture, lancer un produit sur le marché, agrandir un entrepôt de stockage. tout projet professionnel, quelle que soit sa di-mension, nécessite que soient maîtrisées et structurées les phases successives qui le composent : avant-projet, définition, conception, test, communication et bilan. Sans oublier que cette organisation du projet, pour garantir son succès, devra intégrer trois variables indissociables et essentielles : les coûts, les délais et les moyens, également appelées « le triangle de la performance ».

Que vous soyez client, fournisseur, constructeur ou prestataire de service, si vous devez piloter un projet en tant que maître d'ouvrage ou, en tant qu'intervenant, y participer, votre but sera toujours de mener à bien votre entreprise en limitant les écueils.

Pour éviter les risques inhérents à des objectifs mal identifiés, un cahier des charges incomplet, des délais irréalisables, une sous-estimation des charges de travail. ce livre vous propose de suivre une méthodologie rigoureuse s'appuyant sur des « livrables », documents contractuels ou informels qui jalonneront la progression de votre projet.

Accompagnés d'exemples concrets, ces outils ont été utilisés dans le cadre de projets réels. Véritables notices d'utilisation, ils vous seront d'une aide précieuse pour, à tout moment, analyser, anticiper, agir et réagir, puis enfin pour valider votre projet.

335 pages, 1re édition, 1er mai 2006 

Édition : Vuibert

ISBN10 : 2711791777

ISBN13 : 9782711791774

Commandez sur www.amazon.fr :

23,75 € TTC (prix éditeur 25 € TTC) livraison gratuite !
  • Phase de l'avant-projet (Outils n°1 à n°7)
  • Phase de définition (Outils n°8 à n°15)
  • Phase de conception (Outils n°16 à n°17)
  • Phase de test (Outils n°18 à n°19)
  • Phase de bilan - Evaluation (Outils n°20 à n°21)
  • Outils de communication (Outils n°22 à n°25)
  • Outils transversaux (Outils n°26 à n°40)

 
Critique du livre par la rédaction Lecoester Emmanuel le 28 avril 2009 

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é.

 
couverture du livre Object-Oriented Thought Process, 2nd edition

Note 3.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Object-Oriented Thought Process, 2nd edition

de Matt Weisfeld
Public visé : débutant

Résumé de l'éditeur

By the Professional, for the Professional!

The Object-Oriented Thought Process is a concise and readable primer.

Matt Weisfeld's years of programming, teaching, and writing have given him a flair for presenting highly technical topics in a clear and interesting manner. He is able to blend abstract concepts with ingenious examples and clear illustrations to quickly teach powerful OOP techniques.

The code examples are written in Java and UML but are designed in such a way that a reader with no previous experience will still understand them.

The Object-Oriented Thought Process is a clear and accessible alternative to the often dry and overly dense books available on the market today.

Matt Weisfeld has 18 years of software development and project management experience in COBOL, Pascal, C, C++, Smalltalk, and Java. He has taught programming classes for more than 10 years and has been published extensively in leading industry magazines, including Dr. Dobb's and Java Report including many more!

A concise but complete introduction to object-oriented concepts with code examples in Java and UML.

Excellent primer for professional developers moving to object-oriented languages, as well as CS students.

304 pages, 2e édition, 1er décembre 2003 

Édition : Sams Publishing

ISBN10 : 0-672-32611-6

Commandez sur www.amazon.fr :

28,53 € TTC (prix éditeur 28,53 € TTC) livraison gratuite !
  • Introduction to Object-Oriented Concepts
  • How to Think in Terms of Objects
  • Advanced Object-Oriented Concepts
  • The Anatomy of a Class
  • Class Design Guidelines
  • Object-Oriented Modeling
  • Designing with Objects
  • Mastering Inheritance and Composition
  • Frameworks and Reuse: Interfaces and Abstract Classes
  • Building Objects
  • Patterns
  • XML
  • Objects and the Net
  • Objects and the Enterprise
  • Objects and Databases

 
Critique du livre par pseudocode le 13 février 2004 

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.

 
couverture du livre Manager un projet informatique

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (3)
 
 

Manager un projet informatique

de Olivier Englender, Sophie Fernandes
Public visé : Confirmé, expert

Résumé de l'éditeur

Présentation de l'éditeur
Comment organiser un projet informatique ? Quels méthodes et outils utiliser et à quel moment ? Comment recueillir les besoins, identifier les risques, définir les coûts ou encore exploiter les données ? Ces questions et bien d'autres traitées dans cet ouvrage font l'objet d'une attention quotidienne du chef de projet informatique. Les auteurs proposent une démarche originale, en traitant des sujets habituellement oubliés tels que le droit, la gestion des connaissances, l'intégration de progiciel ou encore la sous-traitance. Grâce à une approche thématique, agrémentée de conseils, d'astuces et de références aux textes de loi et aux normes en vigueur, le lecteur pourra se forger sa propre idée du management de projet et utiliser les thèmes proposés pour mettre en place sa méthodologie pour la conduite de son projet. Ce livre s'adresse autant aux maîtrises d'ouvrage ou étudiants qui cherchent à approfondir leurs connaissances, ou simplement à se familiariser avec la gestion de projet, qu'aux maîtrises d'ceuvre/chefs de projet (débutants ou confirmés) qui ont besoin de piloter tout projet informatique de façon optimale.

Biographie de l'auteur
Analyste informatique, Sophie Fernandes assure la conception et la réalisation de solutions techniques pour répondre aux demandes de la maîtrise d'ouvrage. Elle prend aussi en charge l'élaboration de tableaux de bord de pilotage utiles au suivi de l'activité. Responsable de projet, Olivier Englender est en charge des compétences informatiques décisionnelles. Il pilote la restitution des données du système d'information de structures publiques et enseigne la gestion de projet à l'université. Co-auteur d'un livre sur les outils de la gestion de projet.

275 pages, 1re édition, 23 août 2007 

Édition : Eyrolles

ISBN10 : 2212539134

Commandez sur www.amazon.fr :

30,40 € TTC (prix éditeur 32,00 € TTC) livraison gratuite !
  • Introduction
  • 1. Les étapes projet
  • 2. Les cycles de vie
  • 3. Le suivi de projet
  • 4. Expression des besoins
  • 5. Estimation de charges
  • 6. Risques
  • 7. L'exploitation des données
  • 8. ROI/Coûts
  • 9. Intégration de prologiciels
  • 10. Sécurité
  • 11. Qualité
  • 12. Droit
  • 13. Les moyens
  • 14. La sous-traitance
  • Conclusion

 
Critique du livre par la rédaction Gabriel Malkas le 13 mars 2008 

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.

Critique du livre par la rédaction Eric Reboisson le 10 juillet 2008 

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 !

Critique du livre par la rédaction MORAND Louis-Guillaume le 14 septembre 2008 

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.

 
couverture du livre CMMI

Note 3.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

CMMI

Un itinéraire fléché vers le Capability Maturity Model Intégration

de Richard Basque
Public visé : avancé, expert

Résumé de l'éditeur

La qualité en informatique, tout le monde la souhaite, beaucoup en parlent, certains l'appliquent, mais rares sont ceux qui peuvent réellement la mesurer. Aujourd'hui la situation est en train de changer avec l'entrée du CMMI (Capability Maturity Model Integration) dans la pratique des entreprises. Ce modèle d'évaluation des processus de développement d'un produit logiciel permet de classer en cinq niveaux de maturité les pratiques de l'entreprise en termes de délai, de qualité, de coûts et de fiabilité. Rédigé par l'un des meilleurs spécialistes francophones du sujet cet ouvrage est une synthèse précise et précieuse sur ce sujet stratégique.

216 pages, 1re édition, 1er octobre 2004 

Édition : Dunod

ISBN10 : 2-10-008308-2

Commandez sur www.amazon.fr :

33.25 € TTC seulement (au lieu de 35.00  € TTC : prix éditeur) livraison gratuite !
  1. La genèse d'un modèle de meilleures pratiques
  2. L'étoile CMMI dans la galaxie des modèles
  3. Une échelle de maturité organisationnelle
  4. Terminologie particulière au CMMI
  5. L'architecture du modèle
  6. Le niveau 2
  7. Le niveau 3
  8. Le niveau 4
  9. Le niveau 5
  10. Un cas concret
  11. Les bénéfices pour l'industrie du logiciel et ses clients
  12. Utilisations possibles du CMMI

 
Critique du livre par la rédaction Petrus le 13 mars 2005 

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:

 
couverture du livre Extreme programming

Note 3.0drapeau
Détails du livre
Sommaire
Critiques (2)
 
 

Extreme programming

précis et concis

de Chromatic
Traducteur(s) : Michel Casabianca
Public visé : Débutant, Moyen, comfirmé

Résumé de l'éditeur

L'Extreme Programming, ou XP, est une nouvelle approche du développement logiciel. Cette méthode met l'accent sur la simplicité, le feedback et l'implication de tous les membres d'un projet. Si vous êtes en retard dans votre projet, si vous avez dépassé votre budget, si vous avez perdu des heures et des heures à déboguer votre code, pourquoi ne pas envisager l'approche XP ? Ce guide présente ce qu'est XP et vous montre comment elle peut améliorer réellement votre manière de travailler. Il explique les différentes composantes de cette méthode les règles de base, les bonnes pratiques, la manière de coder (du code simple et réutilisable), l'organisation du travail en équipe, les relations avec le client, la gestion du calendrier. Si vous rencontrez des difficultés pour mener à bien vos projets, que vous soyez développeur, manager ou client, ce précis & concis vous montrera que XP peut vous aider à créer de bons systèmes répondant aux attentes métier et cela avec les ressources à votre disposition. XP a quelque chose à vous apprendre, ne serait-ce qu'à retrouver le plaisir de la programmation.

103 pages, 1re édition, 1er mars 2005 

Édition : O'Reilly

ISBN10 : 2841773582

11 x 1 x 18

Commandez sur www.amazon.fr :

9 € TTC (prix éditeur 8,55 € TTC) livraison gratuite ! (voir conditions)
  • Pourquoi XP ?
  • Pratiques de l'Extreme Programming.
  • Evénements XP
  • Les artefacts de l'XP
  • Les rôles de l'XP.
  • Style de développement XP.
  • Adopter XP.
  • Ressources.

 
Critique du livre par la rédaction Lionel Roux le 13 mai 2005 

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.

Critique du livre par la rédaction Stessy le 23 juillet 2005 

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.

 
couverture du livre Gestion de projet

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (2)
 
 

Gestion de projet

EXtreme Programming

de Jean-Louis Bénard, Laurent Bossavit, Régis Médina, Dominic Williams
Public visé : Tous

Résumé de l'éditeur

Comme toute méthode de développement, l'Extreme Programming propose un cadre pour l'ensemble des aspects du projet logiciel, de l'analyse des besoins aux tests en passant par la conception. Mais à la différence de processus prédictifs, XP ne se fonde pas sur une définition exhaustive et précoce des besoins. En découle une redéfinition de la relation entre clients et fournisseurs, avec de surprenants résultats en termes de qualité de code, de délais... et de retour sur investissement !

298 pages, 3e édition, 1er décembre 2004 

Édition : Eyrolles

ISBN10 : 221211561X

Broché

Commandez sur www.amazon.fr :

33,25 € TTC (prix éditeur 35 € TTC) livraison gratuite !
  1. Introduction
    1. Les limites des démarches "par phases"
    2. Un changement de référentiel
    3. Les pratiques d'XP
    4. Les quatre valeurs d'XP
    5. Racines historiques et acteurs d'XP
    6. Guide de lecture
  2. Organisation de l'équipe
    1. Les principaux rôles XP
    2. Répartition des rôles
    3. Comparaison avec une organisation d'équipe classique
    4. Quelle taille pour les équipes XP ?
    5. Comment s'y prendre ?
  3. Programmation
    1. Survol des pratiques de programmation
    2. Développement piloté par les tests
    3. Conception simple
    4. Remaniement (refactoring)
    5. Atour des pratiques de programmation
    1. Les outils : la famille xUnit
    2. Comment tester avant de coder
    3. Conseils pratiques
    4. La qualité par les tests
  4. Pratiques collaboratives
    1. Une approche fondée sur le travail d'équipe
    2. Rôle de la métaphore
    3. La programmation en binôme
    4. Apprendre à travailler en binôme
    5. Responsabilité collective du code
    6. Règles de codage
    7. Intégration continue
  5. Gestion de projet
    1. Principes de la démarche
    2. Les pratiques XP de gestion du projet
    3. Client sur site
    4. Ryhtme durable
    5. Livraisons fréquentes
    6. Planification itérative
  6. Plan d'accès et formation
    1. Les facteurs de succès d'un projet XP
    2. Ordre de marche
    3. Panorama des formations
    4. L'esprit XP et la culture d'entreprise
  7. Coûts et retours sur investissement
    1. Le succès d'XP passe par une perception économique favorable
    2. Quatre variables clés
    3. Dépendance entre les variables
    4. Maîtrise des variables par adaptation du périmètre fonctionnel
    5. Les coûts d'un projet informatique
    6. Les coûts indirects
    7. Un projet XP coûte-t-il plus cher qu'un projet traditionnel ?
  8. Aspects contractuels
    1. La problématique contractuelle, passage obligé de l'Extreme Programming
    2. Contrats forfaitaires
    3. Contrats d'assistance technique (ou "régies")
    4. Contrats d'assistance forfaitée : la combinaison des modèles régie-forfait ?
    5. Mise en oeuvre d'XP dans un cadre d'assistance technique forfaitée
    6. Indicateurs de suivi possibles
    7. Difficultés de mise en oeuvre en France
  9. Qualité, processus et méthodologie
    1. De la qualité au processus
    2. L'ISO et le management de la qualité
    3. XP et les autres méthodologies de développement logiciel
  10. Un projet Web en XP
    1. Un projet est une histoire
    2. Naissance : avant le projet
    3. Itération 0 : calibrage
    4. Itération 1 : mise en production
    5. Itération 2 : croissance
    6. Itération 3 : stabilisation
  11. Un projet industriel en XP
    1. Le contexte
    2. L'opportunité
    3. Susciter l'adhésion
    4. Premiers par
    5. Vitesse de croisière
    6. L'heure des bilans
    7. Epilogue
    8. Conclusion
  1. Annexe 1 : Glossaire
  2. Annexe 2 : bibliographie
    1. Livres XP
    2. Livres sur la gestion de projet
    3. Ouvrages généraux
    4. Sites Internet
    5. Organismes de formation
  3. Annexe 3 : Exemples de code
  4. Annexe 4 : Aide-mémoire XP

 
Critique du livre par la rédaction Nico-pyright(c) le 1er décembre 2008 

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.

Critique du livre par la rédaction Ricky81 le 29 août 2007 

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.

 
couverture du livre Gestion de projet

Note 3.5drapeau
Détails du livre
Sommaire
Critiques (3)
 
 

Gestion de projet

Vers les méthodes agiles

de Véronique Messager Rota

Résumé de l'éditeur

Cet ouvrage rassemble plus de dix années d'expérience en gestion de projet informatique, et compare les méthodologies traditionnelles - qui définissent à l'avance les besoins et organisent les activités à réaliser, leur séquencement, les rôles et les livrables à produire - aux méthodes agiles.

Ces dernières prennent le contre-pied des méthodes prédictives en évitant une définition trop précoce et figée des besoins ; elles ont montré une surprenante efficacité en pariant sur la souplesse des équipes. Ce guide aidera les chefs de projet, déjà familiarisés avec les méthodes traditionnelles de conduite de projet et attirés par les méthodes dites " agiles " ou débutant dans le métier, à évaluer et améliorer leurs compétences en gestion de projet. Il guidera également architectes, analystes, développeurs ou testeurs dans la conduite de leurs projets, ainsi que tous les clients ou experts métier non informaticiens souhaitant appréhender rapidement les enjeux et la répartition des rôles au sein d'un projet.

251 pages, 1re édition, 1er novembre 2007 

Édition : Eyrolles

ISBN10 : 2212121652

Eyrolles : 28,41 € TTC seulement seulement (au lieu de 29,90 € TTC : prix public)

  • Introduction - Chef de projet : un métier complexe
    • Le chef de projet multicompétent
    • La solitude du chef de projet
    • La certitude de l'incertitude
    • Gérer un projet : mission (im)possible ?
  • Diagnostiquer sa gestion de projet
    • Les questions à se poser
    • Analyser la tendance de vos résultats
  • Méthodes traditionnelles ou méthodes agiles ?
    • Limites des approches classiques
    • Une alternative : les méthodes agiles
    • Synthèse des différences fondamentales entre approche traditionnelle et approche agile
  • Recueillir efficacement les besoins
    • Pourquoi est-ce si difficile ?
    • Partager une vision
    • Vers une collaboration efficace avec le client
    • Faire émerger les besoins
    • Formaliser les besoins
    • Hiérarchiser les besoins
    • Ce qu'il faut retenir
  • Planifier son projet
    • Pourquoi planifier ?
    • Définir sa stratégie de planification
    • Définir une enveloppe globale
    • Planifier avec une démarche prédictive
    • Planifier avec une démarche agile
    • Ce qu'il faut retenir
  • Suivre et piloter son projet
    • Quels indicateurs suivre ?
    • Comment suivre ces indicateurs ?
    • Comment présenter ces indicateurs ?
    • Comment piloter le projet ?
    • Ce qu'il faut retenir
  • Gérer les hommes
    • Constituer l'équipe
    • Animer l'équipe
    • Développer la collaboration
    • Créer un environnement de travail efficace
    • Gérer des équipes multiples ou distantes
    • Gérer les sous-traitants
    • Ce qu'il faut retenir
  • Adopter une approche agile
    • Dresser l'état des lieux
    • Fixer des objectifs réalistes
    • Comment démarrer ?
    • Initialiser la conduite du changement
    • Et dans le cadre...
    • Ce qu'il faut retenir
  • Annexe A : Présentation des coachs
  • Annexe B : Les outils de gestion de projet
  • Annexe C : Glossaire
  • Annexe D : Bibliographie

 
Critique du livre par la rédaction nico-pyright(c) le 1er janvier 2009 

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.

Critique du livre par la rédaction Eric Siber le 1er février 2008 

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.

Critique du livre par la rédaction Eric Reboisson le 1er août 2008 

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.

 
couverture du livre The Art of Agile Development

Note 4.0drapeau
Détails du livre
Sommaire
Critiques (2)
 
 

The Art of Agile Development

de James Shore, Shane Warden
Public visé : Débutant, Intermédiaire

Résumé de l'éditeur

The Art of Agile Development contains practical guidance for anyone considering or applying agile development for building valuable software. Plenty of books describe what agile development is or why it helps software projects succeed, but very few combine information for developers, managers, testers, and customers into a single package that they can apply directly.

This book provides no-nonsense advice on agile planning, development, delivery, and management taken from the authors' many years of experience with Extreme Programming (XP). You get a gestalt view of the agile development process, including comprehensive guidance for non-technical readers and hands-on technical practices for developers and testers

The Art of Agile Development gives you clear answers to questions such as:

  • How can we adopt agile development?
  • Do we really need to pair program?
  • What metrics should we report?
  • What if I can't get my customer to participate?
  • How much documentation should we write?
  • When do we design and architect?
  • As a non-developer, how should I work with my agile team?
  • Where is my product roadmap?
  • How does QA fit in?

The book teaches you how to adopt XP practices, describes each practice in detail, then discusses principles that will allow you to modify XP and create your own agile method. In particular, this book tackles the difficult aspects of agile development: the need for cooperation and trust among team members.

Whether you're currently part of an agile team, working with an agile team, or interested in agile development, this book provides the practical tips you need to start practicing agile development. As your experience grows, the book will grow with you, providing exercises and information that will teach you first to understand the rules of agile development, break them, and ultimately abandon rules altogether as you master the art of agile development.

430 pages, 1re édition, 1er octobre 2007 

Édition : O'Reilly

ISBN10 : 0596527675

Broché

Commandez sur www.amazon.fr :

28,60 € TTC (prix éditeur 28,60 € TTC) livraison gratuite !
  • Part I : Getting Started
    • Chapter 1: Why Agile?
    • Chapter 2: How to Be Agile
    • Chapter 3: Understanding XP
    • Chapter 4: Adopting XP
  • Part II : Practicing XP
    • Chapter 5: Thinking
    • Chapter 6: Collaborating
    • Chapter 7: Releasing
    • Chapter 8: Planning
    • Chapter 9: Developing
  • Part III : Mastering Agility
    • Chapter 10: Values and Principles
    • Chapter 11: Improve the Process
    • Chapter 12: Rely on People

 
Critique du livre par la rédaction Gildas CUISINIER (hikage) le 13 janvier 2008 

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.

Critique du livre par la rédaction Pierre Chauvin le 3 mars 2008 

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.

 
couverture du livre Test-Driven Development

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

Test-Driven Development

By Example

de Kent Beck
Public visé : Intermédiaire

Résumé de l'éditeur

Du code propre qui fonctionne - tout de suite. Ceci est apparemment une contradiction responsable de beaucoup de souffrances en programmation. Test-Driven Development, ou développement basé sur les tests, répond à cette contradiction par un paradoxe : testez le programme avant de l'écrire.

Une nouvelle idée ? Pas du tout. Depuis l'aube des calculs sur ordinateur, les programmeurs ont spécifié les entrées et les sorties de leur programme avant de l'écrire précisement. TDD reprend cette vieille idée, la mixe avec les langages modernes et les environnements de programmation et en fait un mets vous garantissant d'être rassasié de code clair qui fonctionne - tout de suite.

Les développeurs font tous les jours face à des défis, pourtant ils ne sont pas toujours préparés à trouver la meilleure solution. Le plus souvent, de grands projets génèrent beaucoup de stress et du mauvais code. Pour obtenir la force et le courage de surmonter cette tâche apparemment herculéenne, les programmeurs devrait regarder vers TDD, un jeu de techniques qui encourage les designs simples et les tests qui inspirent confiance.

En développant avec des tests automatiques puis en éliminant les doublons, chaque développeur peut écrire du code dans lequel on peut avoir confiance, sans bug quelque soit sa complexité. De plus, TDD encourage les programmeurs à apprendre rapidement, communiquer plus clairement et à obtenir un feedback constructif.

Les lecteurs apprendront à:

  • Résoudre des tâches compliquées, commençant par la simplicité et continuant vers plus de complexité.
  • Ecrire des tests automatiques avant de programmer
  • Définir un design en refactorant pour ajouter des éléments petit à petit.
  • Créer des tests pour de la logique plus complexe.
  • Utiliser des patterns pour décider quels tests doivent être écrits.
  • Créer des tests à l'aide d'xUnit, l'architecture au coeur de plusieurs outils de tests orientés vers les programmeurs.

Ce livre suit 2 projets à l'aide de TDD, du début à la fin, illustrant les techniques que les programmeurs peuvent utiliser pour améliorer facilement et de manière importante la qualité de leur travail. Les exemples sont suivis de références aux patterns TDD et au refactoring. Avec son accent sur les méthodes dites agiles et les stratégies de développement rapide, TDD encouragera les lecteurs à embrasser ces techniques sous-utilisées mais puissantes.

240 pages, 1re édition, 1er novembre 2002 

Édition : Pearson Education

ISBN10 : 0321146530

Commandez sur www.amazon.fr :

22,77 € TTC (prix éditeur 22,77 € TTC) livraison gratuite !
  • I. THE MONEY EXAMPLE.
    • 1. Multi-Currency Money.
    • 2. Degenerate Objects.
    • 3. Equality for All.
    • 4. Privacy.
    • 5. Franc-ly Speaking.
    • 6. Equality for All, Redux.
    • 7. Apples and Oranges.
    • 8. Makin' Objects.
    • 9. Times We're Livin' In.
    • 10. Interesting Times.
    • 11. The Root of All Evil.
    • 12. Addition, Finally.
    • 13. Make It.
    • 14. Change.
    • 15. Mixed Currencies.
    • 16. Abstraction, Finally.
    • 17. Money Retrospective.
  • II. The xUnit Example.
    • 18. First Steps to xUnit.
    • 19. Set the Table.
    • 20. Cleaning Up After.
    • 21. Counting.
    • 22. Dealing with Failure.
    • 23. How Suite It Is.
    • 24. xUnit Retrospective.
  • III. Patterns for Test-Driven Development.
    • 25. Test-Driven Development Patterns.
    • 26. Red Bar Patterns.
    • 27. Testing Patterns.
    • 28. Green Bar Patterns.
    • 29. xUnit Patterns.
    • 30. Design Patterns.
    • 31. Refactoring.
    • 32. Mastering TDD.
  • Appendix I: Influence Diagrams.
  • Appendix II: Fibonacci.

 
Critique du livre par la rédaction Miles le 13 janvier 2003 

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 ;)

 
couverture du livre SOA In Practice

Note 4.5drapeau
Détails du livre
Sommaire
Critiques (1)
 
 

SOA In Practice

The art of Distributed System Design

de Nicolai M. Josuttis

Résumé de l'éditeur

This book demonstrates service-oriented architecture (SOA) as a concrete discipline rather than a hopeful collection of cloud charts. Built upon the author's firsthand experience rolling out a SOA at a major corporation, SOA in Practice explains how SOA can simplify the creation and maintenance of large-scale applications. Whether your project involves a large set of Web Services-based components, or connects legacy applications to modern business processes, this book clarifies how -- and whether -- SOA fits your needs.

SOA has been a vision for years. This book brings it down to earth by describing the real-world problems of implementing and running a SOA in practice. After defining SOA's many facets, examining typical use patterns, and exploring how loose coupling helps build stronger applications, SOA in Practice presents a framework to help you determine when to take advantage of SOA. In this book you will:

Focus squarely on real deployment and technology, not just standards maps

Examine business problems to determine which ones fit a SOA approach before plastering a SOA solution on top of them

Find clear paths for building solutions without getting trapped in the mire of changing web services details

Gain the experience of a systems analyst intimately involved with SOA

324 pages, 1re édition, 1er septembre 2007 

Édition : O'Reilly

ISBN10 : 0596529554

ISBN13 : 9780596529550

Commandez sur www.amazon.fr :

27,66 € TTC (prix éditeur 41,11 € TTC) livraison gratuite !
  1. Motivation
  2. SOA
  3. SERVICES
  4. LOOSE COUPLING
  5. THE ENTERPRISE SERVICE BUS
  6. SERVICE CLASSIFICATION
  7. BUSINESS PROCESS MANAGEMENT
  8. SOA AND THE ORGANIZATION
  9. SOA IN CONTEXT
  10. MESSAGE EXCHANGE PATTERNS
  11. SERVICE LIFECYCLE
  12. VERSIONNING
  13. SOA AND PERFORMANCE
  14. SOA AND SECURITY
  15. TECHNICAL DETAILS
  16. WEB SERVICES
  17. SERVICE MANAGEMENT
  18. MODEL-DRIVEN SERVICE DEVELOPMENT
  19. ESTABLISHING SERVICE DEVELOPMENT
  20. ESTABLISHING SOA AND SOA GOVERNANCE
  21. EPILOGUE

 
Critique du livre par la rédaction Morgan Bourgeois le 1er avril 2008 

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.

 
couverture du livre Conduite de projet Web

Note 5.0drapeaucdrom
Détails du livre
Sommaire
Critiques (1)
 
 

Conduite de projet Web

3 Etudes de cas

de Bordage Stephane
Public visé : Tout public

Résumé de l'éditeur

Comment gérer avec efficacité un projet Web ? Comment préparer au mieux son déroulement et garantir la réussite de chaque phase ? Nourri par la grande expérience de l'auteur, cet ouvrage vous fournira les moyens d'y parvenir, en proposant des solutions concrètes et opérationnelles pour chaque étape. Émaillé de nombreuses check-listes et grilles d'analyse, ce guide très concret synthétise les principales pratiques rencontrées sur le terrain pour chaque type de site : sites catalogues, marchands, institutionnels, de marques, communautaires, éditoriaux, portails d'entreprise, intranets...
Toutes les phases de gestion d'un projet Web y sont développées : stratégie, définition de l'offre, construction du business plan, suivi du budget, étude de faisabilité, appel d'offres, choix des prestataires, cahier des charges, réalisation du site, promotion, hébergement, référencement, aspects juridiques... Complétée par trois études de cas détaillées et des interviews d'experts, la quatrième édition de cet ouvrage a été enrichie et mise à jour, s'attardant davantage sur les aspects juridiques et le référencement du site.

407 pages, 4e édition, 1er mai 2008 

Édition : Eyrolles

ISBN10 : 2212123256

ISBN13 : 9782212123258

Eyrolles : 33,25 € TTC seulement

Commandez sur www.amazon.fr :

33,25 € TTC (prix éditeur 35,00 € TTC) livraison gratuite !
  • LES PROJETS WEB
  • Qu'est-ce qu'un projet Web ?
  • Les acteurs du projet
  • La dimension juridique du projet Web
  • Rassembler les facteurs clés de succès
  • LA CONDUITE DES PROJETS WEB
  • La stratégie
  • Le business plan
  • La faisabilité
  • L'appel d'offres
  • La conception
  • La réalisation
  • La mise en service
  • Référencement et positionnement
  • Impact du Web 2.0 sur les projets Web
  • Étude de cas 1 : site institutionnel
  • Étude de cas 2, site B-to-B
  • Étude de cas 3, portail d'entreprise

 
Critique du livre par la rédaction LEMERCIER Arnaud le 10 septembre 2008 

"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.

 
precedentsommairesuivant

Voir également :
Tous les livres sur UML
  

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2004-2013 Developpez.com Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site ni de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.