Catégorie : Notes de lecture

Note de lecture : Pattern Languages of Program Design vol. 2, Vlissides, Coplien & Kerth edt

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Quelques bon (et même très bons patterns), toutefois noyés dans nombre de patterns de moindre intérêt.

Ce volume regroupe une sélection des contributions à la seconde conférence PLOP. La formule reste la même que pour le premier volume, avec une sélection de patterns ou de patterns languages regroupés par thèmes. La communauté se développant, la qualité de la matière utile progresse d’autant.

Une nouveauté, la première partie parle désormais d’idiomes, c’est à dire de patterns de bas niveau spécifiques à des langages. Toutefois il n’y a là rien de bien remarquable : les idiomes de Tom Cargill auront du mal à soutenir la comparaison avec ceux de Jim Coplien dans son ouvrage éponyme.

La seconde partie, les « general purpose patterns » regroupent ce que l’ouvrage a de mieux à proposer, avec spécifiquement deux patterns remarquables : Le Shopper de Jim Doble, mais surtout le Command Processor de Peter Sommerlad. Ce dernier n’est pas seulement désormais un classique, il est aussi simple, puissant et élégant.

La troisième partie « special purpose patterns » tait celle consacrée aux domaines métiers dans le volume précédent. On y trouve surtout des pattern languages qui sont intéressants sans être transcendants.

Peu de patterns dans la quatrième partie dédiée aux patterns architecturaux. Juste trois, seul « reflection » de Frank Buschmann retiendra mon attention.

Je ne suis toujours pas fan des patterns organisationnels qui nous sont proposés en cinquième et sixième parties. L’organisational Patterns for Team prélude certaines pratiques agiles. Episodes de Ward Cunningham est souvent référencé d’une part à cause du nom de l’auteur et d’autre part car certains patterns seront repris par Kent Beck dans l’extreme programming.

Le « concurrent programming / distributed systems » de la partie 7 est une excellente fournée. Je citerais juste le « half sync / Half-async » de Douglas C. Schmidt et Charles Cranor.

En comparaison, la partie 8 sur les « reactive systems » m’a parue un peu pauvre.

Si l’ouvrage est loin d’être indispensable, il pourra intéresser à ceux qui portent un intérêt actif aux patterns. Et un nombre non négligeable des patterns présentés sont loin d’être dénués d’intérêt.

PLOPD-vol2

Référence complète : Pattern Languages of Program Design, vol. 2 –  John Vlissides, James Coplien & Norman L. Kerth edt – Addison Wesley 1996 – ISBN : 0-201-89527-7

Pattern Languages of Program Design 2


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

Note de lecture : Object-Oriented SSADM, par Keith Robinson & Graham Berrisford

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Une vision d’un autre temps….

Je sais ce que vous allez me dire : « quel intérêt en 2012 de faire une note de lecture sur un vieux clou âgé de 18 ans et de toute façon obsolète ? ». L’histoire, mes amis, ceci est l’histoire. Cet ouvrage de 500 pages évoquant une méthode désormais délaissée fait partie de l’histoire des méthodes objet.

SSADM est une approche que l’on pourrait qualifier de « hautement structurée », voir même Tayloriste ! Elle s’appuie sur 3 schémas directeurs :

  • L’Internal Design : qui définit le schéma physique de la base de données, ainsi que les PDIs (process data interfaces).
  • L’External Design : Il comprend les définitions de format de données en I/O et les interfaces et dialogues utilisateurs
  • Le Conceptual Design : Définit les règles métier, le modèle comportemental de l’application et le modèle logique des données.

Les parties 2 à 5 de ce livre viennent étayer cette vision quelque peu complexe de la modélisation des systèmes d’information.

  • La seconde partie du texte « Le besoin d’avoir plus que la modélisation de données » nous présente les concepts classiques de la modélisation orientée objet, bien qu’avec des qualités pédagogiques assez moyennes, pour nous emmener vers la modélisation dynamique, plutôt pauvre d’ailleurs avec SSADM. Bref, ce n’est pas encore ici que l’on va crier au génie.
  • La troisième partie modestement appelée « Le besoin d’avoir plus que la modélisation OO » couvre les concepts classiques de la modélisation OO (encapsulation, héritage, etc..) pour terminer avec les besoins liés aux « grands » systèmes d’information. Chapitre peu convaincant au demeurant. Au suivant, donc.
  • La quatrième partie est consacrée au modèle conceptuel (c’est aussi la plus importante du livre). On y détaille donc finalement la notation SSADM dédiée à cet aspect. On y aborde la réutilisation (quelle blague !) et certains patterns liés à l’entity data modeling qui constitue des règles d’usage de SSADM, même si leur bien-fondé reste en partie assez mystérieux pour moi. L’event modeling qui y est abordé offre certaines perspectives mais me parait aussi assez difficile d’emploi en l’état.
  • La cinquième partie est dédiée à l’external design. Assez curieusement, c’est ici que je trouve le plus d’éléments intéressants, liés à l’utilisation de techniques « RAD » ou d’event-driven interfaces, bien que les notations soient parfois ardues.
  • La sixième partie est quand à elle consacrée aux autres discussions comme les besoins concernant les ateliers de modélisation ou la réutilisation (encore ?) à l’échelle de l’entreprise.

On ne peut reprocher à cet ouvrage le traitement de SSADM, ce qui lui vaut sa note. C’est à SSADM lui-même que l’on peut reprocher des choses : cette vision du développement logiciel appartient à une autre époque, pour autant que cela ait été applicable à une époque donnée ? Ce découpage en tâche avec un formalisme si peu adapté à l’esprit humain ne semble guère convenir. Toutes ces méthodes datant de la fin des années 80 nous packageaient ensemble notation et approche structurée. Qui plus est, ici, cette approche ne s’adapte qu’à des cas identifiés d’architectures logicielles.

Bref, dans le genre, je préfère Bertrand Meyer.

ObjectOriented-SSADM

Référence complète : Object-Oriented SSADM – Keith Robinson & Graham Berrisford – Prentice Hall 1994 – ISBN : 0-13-3094444-8

Object Oriented Ssadm


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

Note de lecture : Effective Java, second edition, par Joshua Bloch

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Il fait honneur à la lignée « effective »

Le titre du livre ne laisse guère planer le mystère : il se veut le pendant Java du désormais célèbre « Effective C++ » de Scott Meyers. Eh bien, on peut l’avouer, le contrat est plutôt bien rempli. Il expose 57 items au long de 232 pages découpés en 10 chapitres. La présence d’un tel ouvrage afin de stigmatiser les bons usages du langage était sans nul doute nécessaire, car si Java  (au contraire du C++) passe pour un langage facile, il n’en est de ce fait que plus aisé (et d’ailleurs plus fréquent) de mal l’utiliser !

Le style du texte est sensiblement différent de celui de Scott Meyers. D’abord on n’y retrouve pas la pointe d’humour qui fait le charme de l’ouvrage C++. Il focalise également un peu moins sur le code de bas niveau, même si nombre d’items sont spécifiquement dédiés à ces aspects. Enfin, l’auteur qui fut « chief architecte » d’une bonne partie des librairies Java oriente souvent son propos par rapport à une vision développement de librairies, alors que c’est un biais somme toute marginal, par rapport au développement d’applications !

Malgré ces petits reproches, il ne fait nul doute que ce livre est un incontournable de toute bibliothèque Java un tant soit peu sérieuse, ne serait-ce que pour utiliser correctement les redéfinitions des méthodes dérivées de la classe Object, comprendre convenablement les « nested classes », certains principes de bases inhérents aux exceptions ou à la sérialisation. Le chapitre consacré aux threads est évidemment plus ardu et également moins pointu que le livre de Doug Lea consacré à ce sujet (et qui fait toujours référence).

Parmi les choses que j’apprécie particulièrement dans le texte : le style très clair, même narratif dirais-je car l’auteur nous guide réellement dans l’explication de l’item tel un conteur. Des fragments de code illustrent le texte et sont particulièrement bien pesés : avec assez de contexte pour donner du sens mais assez concis pour ne pas noyer le lecteur ni être ennuyeux. Globalement j’aime le style très « punchy » avec lequel l’auteur aborde chaque problématique pour nous faire tomber des nues sur tel ou tel comportement du langage, qu’il soit justifié ou non.

Cette seconde édition compte 300 pages pour 68 items. Vous aurez vite fait le calcul sur la taille moyenne de chaque item en nombre de pages ! De toute façon, c’est une lecture à laquelle on prend plaisir tout en apprenant.

Le texte fait de nombreuses références au manuel de référence du langage qui est un complément indispensable à ce livre.

effective-java-2edt

Référence complète : Effective Java, second edition – Joshua Bloch – Addison Wesley / Java Series 2001 – ISBN : 0-201-31005-8

Effective Java(tm) Programming Language Guide


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

Note de lecture : Pattern Language of Program Design, James Coplien & Douglas Schmidt edt

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Pour les “accros” des patterns, exclusivement.

Le mouvement des “Design Patterns” a donné naissance aux conférences PLOP d’abord (aux Etats-Unis, à l’université d’Urbana Champain, Illinois), puis EuroPLOP (Kloster Irsee, Allemagne). Ce volume regroupe une sélection des papiers soumis par les participants à la première conférence PLOP. C’était alors le début de cette conférence, en conséquence la sélection n’est pas sévère, les patterns soumis peu ou pas “compétitifs”, souvent très généraux, plus centrés sur les concepts (ce que l’on qualifie parfois d’approche Alexandrienne) que sur le design. Enfin, une place importante est prise par les patterns “organisationnels”.

Sans rentrer dans les détails, voici une idée générale de la structure de cette compilation :

La première partie « frameworks et composants » regroupe des patterns et patterns languages de niveau très conceptuels pour architecturer des applications.

La seconde partie « systems and distributed processing » regroupe des patterns à caractères architecturaux. C’est l’une des plus intéressante du livre.

Dans la troisième partie « business objects » on retrouvera des patterns et pattern language liés à des domaines métier.

La quatrième partie « process and organization » regroupe exclusivement des patterns languages. C’est celle qui m’a le moins accroché.

La cinquième partie « design patterns and catalogs » est dédiée aux papiers ayant trait à l’étude des patterns : catégorisation, mise en évidence, documentation. C’est intéressant dans le principe, mais hélas ennuyeux dans les faits.

La sixième partie « architecture and communication » promettait d’être intéressante, mais le traitement des patterns qui y figurent est trop littéraire à mon goût pour présenter un réel intérêt. Le « POSA book » adressera cela beaucoup mieux !

La septième partie « object usage and style » ne donne pas tellement lieu à commentaire, si ce n’est que les patterns qui y figurent ne resteront pas dans les annales.

La dernière partie « events and events handlers » a je pense été créée car plusieurs patterns apparaissaient dans cette catégorie.

Certains patterns se détachent du lot, par exemple :

  • Half-object + protocol de Gerard Meszaros
  • Master-Slave pattern de Frank Buschmann
  • Reactor de Doug Schmidt
  • Le CHECKS pattern language de Ward Cunningham qui est l’un des rares pattern language de cette édition à mériter le détour.
  • Dans les patterns organisationnels, une petite curiosité : le « Lifecycle and Refactoring Patterns that Support » qui est en fait une prémice du futur « Refactoring » paru en 1999.

Certes la substance utile est plus importante que celle que j’ai cité. Mais beaucoup des patterns et surtout des patterns languages sont plus des essais à l’intérêt académique que de la matière exploitable. Pour qui veut se plonger dans l’étude des Patterns, ce volume a un intérêt ne serait-ce qu’historique. C’est mon cas. Mais pour beaucoup, ce volume sera à la fois trop aride et pas assez pourvu de matière exploitable en regard de ses 550 pages.

En vérifiant sur Amazon, j’ai la surprise de constater que ce livre est toujours disponible 17 après sa parution ! Je ne le recommande toutefois qu’exclusivement aux aficionados des patterns ! 

PLOPD

Référence complète : Pattern Language of Program Design – James Coplien & Douglas Schmidt edt – Addison Wesley / Software Patterns series 1995 – ISBN: 0-201-60734-4

Pattern Languages of Program Design


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

Note de lecture : C++ Coding Standards, par Herb Sutter & Andrei Alexandrescu

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; N’écrivez plus vos règles de développement sur vos projets C++ !

Quand j’ai besoin de mettre en place des règles de développement en C++, j’ai l’habitude de ressortir mon mètre linéaire d’ouvrages sur le C++, ainsi que mon édition quasi complète de C++ report, et de m’efforcer de dégager nombre de règles impératives, expliquées et détaillées, en fournissant nombre de références bibliographiques. Travail harassant (bien que passionnant), si il en est ! Bien sûr, avec les ans, j’ai amélioré la chose, et je ne repars plus de zéro, mais …. Mais voilà, CE livre est arrivé et a fort heureusement rendu mes efforts obsolètes !

Le livre de Sutter et Alexandrescu couvre plutôt efficacement les grandes lignes des choses à ne pas faire (mais en excluant les choses vraiment trop basiques). 101 règles, c’est plutôt solide, mais on pourrait aussi trouver cela insuffisant. Je pense, moi, que c’est un bon compromis. Si certains aspects doivent être mieux couverts dans votre projet, ou si le niveau de l’équipe nécessite des règles plus basiques pour blinder le développement, ajoutez-les à ce matériel de référence ! Agissez de même pour illustrer les points de l’ouvrage avec des exemples issus de votre domaine de travail. Mais le gros de la matière est là et bien là.

Pour rapport aux ouvrages de Meyers ou de Sutter, celui-ci se positionne différemment : au lieu de développer les items de façon pédagogique, on se contente de développer chaque item sur 1 ou 2 pages (parfois 3), avec des explications claires, mais sans le développement en profondeur de Sutter, ni l’approche pédagogique de Meyers. L’efficacité est privilégiée, et c’est très bien adapté à la finalité de ce livre (manuel devrai-je dire).

Les règles sont rangés sous plusieurs volets qui forment autant de chapitres :

  • D’abord des règles organisationnelles : gestion de version, niveau de warnings, etc… Les bases pourrait-on dire.
  • Des règles de conception, qui ne sont pas spécifiques au C++. Elles recoupent ce que l’on pourra trouver dans le « Designing Object-Oriented C++ Applications » de Robert Martin.
  • Le style de codage : usage des constantes, déclarations des variables, etc..
  • L’usage de fonctions et d’opérateurs.
  • Les règles d’usage et d’implémentation de l’héritage. Cela paraît curieux mais il y a effectivement beaucoup de subtilités possibles en C++.
  • Constructeurs, destructeurs et opérateurs de copie.
  • Utilisation des namespaces.
  • Utilisation des templates.
  • Gestion des exceptions.
  • L’utilisation de la STL couvre deux chapitres, pour les conteneurs d’abord puis pour les algorithmes.
  • Utilisation des opérateurs de cast modernes.

Si vous avez de la bouteille en C++, vous n’apprendrez rien. En fait, le but n’est pas d’enseigner des choses, mais de poser un socle solide de règles pour construire des développements en C++. Je recommande chaudement, bien entendu.

c++-coding-standard

Référence complète : C++ Coding Standards: 101 rules, guidelines, and best practices – Herb Sutter & Andrei Alexandrescu – Addison Wesley / C++ in depth series 2004 – ISBN: 0-321-11358-6

C++ Coding Standards: 101 Rules, Guidelines, and Best Practices

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

Note de lecture : Beginning SQL Server 2005 for Developpers, par Robin Dewson

Le par addinquydans Notes de lectureLaisser un commentaire

Note: 7 ; LE livre pour bien débuter avec SQL Server 2005

Attaquer une « grosse » base telle que SQL Server 2005 quand on n’a pas l’expérience de tels environnements n’est pas évident. Paramétrage, gestion des bases, exploitation et administration sont autant de sujets à découvrir autant sous l’aspect du « quoi » que sous l’aspect du « comment ». Ce livre répond parfaitement à cet objectif. En tout cas, il a bien marché pour moi. Il fait un tour d’horizon complet de la base de données en introduisant chacune de ses facettes, en expliquant par l’exemple comment faire, aussi bien avec les outils interactifs qu’avec le T-SQL. Bref, on est mieux armé à la sortie, et l’on sait dans quelle direction aller sur chacun des sujets, prêt à approfondir plus avant chaque sujet dont on a le besoin.

Les deux premiers chapitres présentent l’architecture de la base, ses options d’installation et le « management studio » qui est l’outil interactif permettant d’accéder à la plupart des fonctionnalités de la base.

Le chapitre trois nous guide pour ce qui est de la création des bases, les différentes options possibles et donne des clés pour configurer une base optimale en termes de performances.

Le chapitre 4 est consacré à la sécurité et à la gestion des utilisateurs. Il présente clairement les différents modes d’authentification et donne des conseils pragmatiques quand aux configurations à adopter, surtout pour les bases d’exploitation. Un sujet habituellement aride, traité ici avec pragmatisme et intelligence.

Les chapitres 5 et 6 sont dédiés au design des bases : création de tables et d’index. Là encore, on a une information détaillée et précieuse, même si le chapitre 6 ne s’avère pas si clair que ça.

Le chapitre 7 est consacré à l’administration : les procédures de backup et de maintenance. On y trouve juste ce dont on a besoin : Les clés pour assurer la mise en place de procédure de gestion classiques de sauvegarde et de maintenance. Indispensable !

Avec les chapitres 8 à 13, on aborde le gros de la troupe : travailler avec T-SQL. Même si le langage a été abordé avant pour la mise en œuvre des différentes fonctions dans ce langage, c’est de manipulation de données dont il est question ici ! Le chapitre 8 nous donne le bagage de base pour traiter les données : select, update et delete avec les différentes clauses de base. Le chapitre 9 traite d’un sujet plus pointu : les vues. Hélas ce n’est pas le meilleur chapitre du livre. Les procédures stockées (comment y échapper ?) sont couvertes par le chapitre 10. Même s’il manque pas mal de briques pour faire tout ce que l’on souhaiterait, on a de quoi démarrer. Les chapitres 11 et 12 terminent le tour d’horizon du T-SQL d’abord en le balayant en largeur, puis en abordant les aspects moins usités du langage. J’avoue avoir largement décroché au chapitre 12 (et aussi un peu au chapitre 11). Le chapitre 13 clos l’affaire avec les triggers et des conseils fort pertinents quand à leur usage.

Un peu en décalage, le chapitre 14 aborde Reporting Service. Il nous permet de désirer en savoir plus, car le traitement qui en est fait ici est vraiment superficiel.

Bref, voilà un ouvrage qui, en 400 pages, nous permet d’avoir une vue globale de l’outil, et m’a permis de porter mon attention sur ce qui était mal fait ou pas fait sur la façon dont nous l’utilisions. Sous cet angle, il a déjà dix fois justifié son achat, et je sais qu’il continuera encore à me rendre service.

Le problème inhérent aux livres liés à des technologies particulères est qu’il vieillissent à la vitesse de celles-ci. Cet ouvrage a déjà connu deux mises à jour, pour SQL Server 2008 puis SQL Server 2012 (que je n’utilise pas encore). La troisième édition a d’ailleurs enflé jusqu’à 700 pages ! Cela voudra certainement dire une petite mise à jour dans un avenir certainement pas trop lointain.

beginning-sqlserver2005-dev-apress

Référence complète : Beginning SQL Server 2005 for Developpers, from novice to professional – Robin Dewson – Apress 2006 – ISBN : 1-59059-588-2 ; EAN : 978 1 59059 588 6

Beginning SQL Server 2005 for Developers: From Novice to Professional


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

Note de lecture : Gestion de projet agile, avec Scrum, Lean, Extreme Programming, par Véronique Messager-Rota

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Un point de départ pour le chef de projet débutant, complété par des évolutions mineures, au fil des éditions.

Il est certainement une chose plus difficile que donner une note et un avis sur un ouvrage auquel on a participé : c’est se livrer au même exercice sur un livre dont on est l’auteur ! Je n’en suis pas là, mais cet exercice reste bien assez difficile pour moi.

Ce livre n’est pas une bible de la gestion de projet agile. Je doute d’ailleurs qu’une telle chose puisse exister. Il s’adresse plutôt à un publique junior ou en tout cas nouveau venu dans l’agilité et adresse deux questions essentielles :

  • Quelles sont les activités que doit mener ou maîtriser le chef de projet : Ce sujet est traité tout au long du livre, car les différents chapitres traitent chacun un aspect spécifique des disciplines à maîtriser : ébauche de la vision, gestion des besoin, suivi des hommes et pilotage du projet. Il manque hélas une partie consacrée aux tests, et je regrette de mon coté que la facette plus technique du projet ne soit pas abordée, car je considère le rôle du chef de projet comme davantage holistique.
  • Quel style aborder pour gérer les projets ? Le titre du livre réponds à cette question, bien que parfois le texte ne nous laisse pas clairement comprendre quelle approche est la bonne. Toutefois mettre les approches classiques et agiles en perspective est un bon exercice.

L’une des particularités du livre est certainement de laisser une part importante aux retours d’expériences (y compris ceux de votre serviteur) pour éclairer le propos. Sans être réellement aride ni académique, celui-ci est souvent un peu trop formel à mon goût.

Ce livre en est maintenant à sa 3ème édition. Que dire des évolutions entre la première mouture et le dernier rejeton ?

Tout d’abord que ces deux nouvelles éditions répondent en premier lieu au « business model » d’Eyrolles consistant à publier très régulièrement de nouvelles éditions de ses best-sellers. Donc il s’agit d’un best seller ! Comme chacun sait, cela n’est pas synonyme de qualité, mais en l’occurrence ce texte atteint bien sa cible (celle que j’ai évoquée plus haut) et le succès du livre en est témoin.

Dans la seconde édition, l’auteur a profité de l’occasion pour rafraîchir sa prose, même si c’est de façon mineure. Cela se voit dès la pagination, le volume total passant de 230 à 250 pages (hors annexes). Il s’agit surtout d’ajouts à l’intérieur des chapitres existant, le texte de base me paraissant inchangé. Ainsi le chapitre 2 qui exposait déjà de manière synthétique et avec brio les différentes méthodes agiles, ajoute « Lean » à sa panoplie. Le chapitre 3 se voit étoffé d’un court comparatif entre les users stories et les cas d’utilisation. Utile en soi, ce comparatif est je pense matière à débat. En clair : il faut qu’on en reparle, Véronique ! Le chapitre 7, consacré à l’adoption des méthodes agiles est celui qui bénéficie le plus d’ajouts : mesure de l’adoption et accompagnement de la conduite du changement.

L’apport le plus important à l’ouvrage est la section consacrée aux apports du coach (toujours dans le chapitre 7). Ces quatre pages supplémentaires ciblent les apports du coach par rapport à l’équipe et au management sur le « savoir être ». Il s’agit d’une prémices du prochain livre de Véronique !

La troisième édition qui n’apporte à nouveau que des bribes de nouveautés. On notera ainsi :

La section dédiée aux organisations agiles, au chapitre 2, qui permet de valoriser les idées avancées par Jérôme Barrand. Le chapitre 4, se voit lui, gratifié d’une page consacrée au pomodoro, ce qui est un ajout original et sympathique. Au chapitre 6, un petit ajout est fait sur le thème de la facilitation.

Sans avoir réellement vieilli, le livre voit son public se restreindre d’année en année : s’il adressait un public d’early adopter lors de sa sortie, il s’agirait maintenant plutôt de late adopters, pas forcements enclins à aller rechercher activement de l’information. Véronique Messager ne semble guère souhaiter poursuivre la politique de retouche mineures du texte et c’est à son honneur.

Si vous débutez en gestion de projet et vous posez la question de l’adoption d’une approche agile, ce livre est pour vous. Il vous permettra de poursuivre plus facilement votre apprentissage par des textes plus avancés ensuite.

Gestion de projet agile avec Scrum, Lean et XP

Référence complète : Gestion de projet agile, avec Scrum, Lean, Extreme Programming, 3ème édition – Véronique Messager-Rota – Eyrolles 2010 – EAN : 978 2 21212750 8

Gestion de projet agile avec Scrum, Lean, eXtreme Programming...


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

Note de lecture : Pair Programming Illuminated, par Laurie Williams & Robert Kessler

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Plutôt bon, mais un livre qui ne présente pas le même niveau d’intérêt pour tous les publics !

Laurie Williams est reconnue dans la communauté agile pour être une grande spécialiste des aspects collaboratifs, il est donc logique qu’elle soit l’auteur de l’ouvrage de référence sur le pair programming, avec Robert Kessler, son mentor.

Le « pair programming » est probablement la pratique qui fait l’objet du plus de résistance lors de la mise en place d’une méthode agile. A cet égard, il n’est pas illogique de chercher à blinder la mise en place de cette pratique, par exemple à l’aide de ce livre. On reconnaitra que le texte cherche vraiment à traiter toutes les facettes du pair programming.

La première partie a trait à la compréhension de ce qu’est vraiment le pair programming. C’est sur cette partie qu’il faudra construire l’argument pour convaincre. L’auteur s’attaque aux mythes justifiant l’opposition à cette pratique avant d’évoquer les aspects bénéfiques. Vient ensuite le plat de résistance : convaincre le management. J’avoue que c’est du solide, avec des arguments, des chiffres et tout et tout. Cette partie se termine par l’évocation des difficultés qui peuvent se rencontrer à la mise en place du pair programming. Somme toute, cette première partie est une sorte de préambule à la mise en place de la pratique : pour convaincre, anticiper les obstacles et les objections, etc… Il n’y a rien à jeter et on a vraiment des choses solides sur les 60 pages de cette partie.

Longue d’une trentaine de pages, la seconde partie intitulée « getting started » m’a paru moins utile. Beaucoup d’éléments qui y sont présentés viennent simplement du bon sens et l’on a guère besoin du texte pour y arriver. Mais peut-être n’est-ce pas si mal d’avoir cela écrit quelque part ? Une mention particulière au chapitre 11 « tips ‘n tricks » qui donne pas mal de trucs utiles.

La troisième partie est la plus longue du livre avec une centaine de pages. Elle est écrite sous forme de patterns avec les différentes configurations de pairing (expert / novice, expert/expert , etc…) et différentes situations émotionnelles. L’idée est de fournir des solutions sous forme de scénarios afin de rendre possible ces différentes dynamiques de travail. Je ne suis pas convaincu que tout cela marche d’une manière aussi simple, mais au moins cela donne des pistes de réflexions.

La dernière partie enfin évoque différents aspects rassemblés ici de manière un peu hétéroclite : aspects économiques, les bonnes habitudes, pair programming versus code inspection, etc..

Le texte n’est pas mal écrit et plutôt plein de bon sens. De plus il est abondamment émaillé de références bibliographiques (l’auteur les a même fait figurer en fin de chaque chapitre). La première partie est littéralement de l’or en barre et on trouve clairement du matériel intéressant dans les autres. Beaucoup de matériel reste surtout intéressant pour ceux qui portent un intérêt académique au sujet (c’est mon cas). C’est un livre que je conseillerais sans hésiter au coach qui va y trouver beaucoup de matière première pour guider les pratiques d’une équipe. Le manager va y trouver des arguments pour défendre cette pratique, mais le développeur aura sans doute la sensation de perdre son temps à cette lecture.

pair-prog-illuminated

Référence complète : Pair Programming Illuminated – Laurie Williams & Robert Kessler – Addison Wesley 2002 – ISBN: 0-201-74576-3

Pair Programming Illuminated


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

Note de lecture : 97 Things Every Software Architect Should Know

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Un concept intéressant, avec un contenu plutôt hétéroclite, mais aussi certaines entrées plutôt pertinentes

Voilà un concept vraiment original : un livre collaboratif, publié en open source, compilant 97 conseils écrits par presque autant d’auteurs différents, chaque conseil tenant en 2 pages (en réalité plutôt un peu moins, environ 1 page et demi). L’intérêt de ce concept est que chaque « thing » est nécessairement concise, efficace et se doit d’aller au but, on n’a guère le temps de s’ennuyer. Le volume du livre reste aussi de taille plus que raisonnable : 195 pages dont j’estimerais que cela correspond à 150 pages d’un ouvrage plus classique.

L’ouvrage souffre quand même d’une faiblesse due au sujet traité : qu’est-ce qu’un architecte et quel est son travail ? Ainsi les conseils traitent d’aspect très diversifiés, ce qui peut être vu comme un bénéfice en élargissant le spectre des aspects traités : aspects fonctionnels, humains, performances, infrastructure matérielle, conceptions, technologies et frameworks, etc… Mais cela ressemble finalement à un grand « melting pot » qu’à un tout cohérent.

Il est d’ailleurs intéressant de voir à quel point les avis d’experts sont variés, allant de la figure paternaliste aux travail d’architecture réparti chez les développeurs eux-mêmes. Parmi les tendances que je vois se dessiner au long de ces 97 conseils :

  • La nécessité de connaître la substance de base : les patterns, qu’ils soient architecturaux ou de conception.
  • L’importance du facteur humain.
  • L’importance des facteurs « environnementaux » : le lien avec le contexte métier, la contrainte d’entropie du système, etc..

Au final, il y a certes des choses à jeter, mais aucun article n’est mal écrit (ils sont courts, donc les auteurs doivent faire très attention), et il y a nécessairement des choses valables.

Ce n’est pas le livre de l’année, mais je le classerais volontiers dans les « lectures amusantes ».

97-things-soft-architect-oreilly

Référence complète : 97 Things Every Software Architect Should Know – Richard Monson-Haefel edt. – O’Reilly 2009 – ISBN : 978 0 596 52269 897

97 Things Every Software Architect Should Know: Collective Wisdom from the Experts


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

Note de lecture : The Usability Engineering Lifecycle, par Deborah J. Mayhew

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Book of the year 2000! Un processus complet et à l’ancienne pour l’interface homme machine, complété d’un matériel prêt à l’emploi.

L’ergonomie fait, partie du recueil des besoins est rarement intégrée au processus de développement logiciel. C’est là une grande part du mérite de cet ouvrage: proposer un processus complet de gestion des exigences ergonomiques intégré à la capture des besoins fonctionnels par le biais des Use Cases. Oui, c’est vrai je viens de parler de processus et cela a une odeur pas très agile. Et effectivement dès les premières pages l’auteur propose un « usability lifecycle » qui ferait facilement froid dans le dos. Nous pouvons nous y arrêter un peu car ce cycle de vie structure le livre lui-même.

  • La première étape est le recueil des besoins. Elle est couverte par 6 chapitres sur 160 pages. Elle couvre les 4 facettes identifies de cette étape : l’analyse des profils utilisateur, l’analyse des tâches, les objectifs d’utilisabilité et les principes généraux de l’IHM.
  • La seconde étape est bien plus dense car le schéma du processus nous montre pas moins de 7 sous étapes regroupés en 3 cycles internes. C’est presque une surprise de voir cela couvert en seulement 180 pages, sur 10 chapitres ! Les activités proposées vont du modèles conceptuel à la reconception des tâches en passant par la conception d’écrans.
  • La dernière étape a trait à l’installation. Il n’y a qu’un seul chapitre, mais il fait 50 pages ! Cette partie couvre le feedback utilisateur.
  • Enfin une dernière partie de l’ouvrage est consacrée aux aspects organisationnels. Elle est longue de 100 pages sur 4 chapitres avec en plus des aspects strictement organisationnels, l’évocation de la planification de projet ou la justification des coûts (une des spécialité de l’auteur).

Au total, le livre est quand même très lourd, car il totalise 560 pages ! Sa structure est entièrement guidé par le processus proposé par l’auteur ce qui tend à rendre la prose très longue, je l’ai déjà constaté. Ce fil extrêmement rigide est tout sauf agile. Mais le contenu est loin d’être inintéressant. En effet le texte est méritoire par le fait qu’il accompagne chaque activité proposée du processus de gestion des exigences d’artéfacts (plans types, questionnaires, etc…) et de guidelines immédiatement applicables. J’ai rarement vu des livres donner autant de matière directement utilisable.

Chaque chapitre traite des aspects de la spécificité des applications Web dans une section et propose des “activités alternatives” si le processus a besoin d’être abrégé.

Outre que le livre reste très lourd (même en considérant le matériel inclus) et qu’il est structuré par un processus très rigide, il prend aussi un sérieux coup de vieux avec la seconde vague du Web. Mon conseil ? Prenez du recul par rapport au texte, démontez les morceaux du processus. N’utilisez pas le processus, mais réutilisez les morceaux, les idées et la matière première d’une manière plus légère et plus agile. L’auteur a beaucoup d’expérience et de savoir-faire dans son domaine qu’il serait dommage de snober.

Un très bon ouvrage que je recommande fortement, surtout si vous n’avez pas de connaissances préalables dans le domaine de l’ergonomie.

usability-engineering-lifecycle

Référence complète : The Usability Engineering Lifecycle – Deborah J. Mayhew – Morgan Kaufman publishers 1999 – ISBN: 1-55860-561-4; EAN: 978-1-558-60561-9

The Usability Engineering Lifecycle: A Practitioner's Handbook for User Interface Design


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