Note de lecture : MDA en action : Ingénierie logicielle guidée par les modèles, par Xavier Blanc

Note : 7 ; Un très bon livre, pour comprendre les concepts clés de MDA, les métamodèles associés et leurs mécanismes de transformation.

Mon snobisme naturel m’incite généralement à préférer les livres américains à leurs équivalents français. Le fait que je m’intéresse aujourd’hui à un ouvrage bien de chez nous ne doit rien à une quelconque cabale hexagonale, mais bien aux qualités intrinsèques dudit ouvrage.

MDA est un sujet complexe, qui nécessite d’en comprendre les fondements afin de pouvoir saisir les nombreux « buzzwords » que sont OCL, Semantic Actions, et autres CIM, PIM, PSM et MOF ! C’est exactement l’approche de ce livre : après un chapitre de présentation générale de MDA, on aborde tout de suite la pierre angulaire du MDA : le MOF (méta-object facilities) encore appelé méta-métamodèle ! Si il est un sujet ardu dans MDA, c’est bien ce fameux MOF (vous l’avez probablement compris rien qu’en lisant la phrase précédente). Mais l’auteur s’en tire fort bien, de manière exemplaire devrais-je même dire car au chapitre 6, on se plonge même dans la manipulation d’un métamodèle construit à l’aide du framework EMF d’Eclipse (celui-là même qui est au cœur de Rational Software Modeler / Architect) : bravo ! Bien sûr, il vous faudra avoir le goût des métamodèles, mais dans le cas contraire, MDA n’est probablement pas pour vous. UML2 est bien entendu abordé, et si vous n’aviez pas encore compris ce que sont UML infrastructure et superstructure (on ne saurait vous en blâmer) et la fameuse dépendance « merge », l’explication est ici. Je met juste un bémol sur les explications dédiées aux classes du métamodèle UML2 qui sont un peu fastidieuses.

Les standards connexes, si ils sont traités brièvement ne le sont pas moins clairement, avec une mention spéciale pour le traitement de XMI et DI (diagram interchanges) ce dernier sujet n’étant même jamais abordé dans les autres textes. De même, si vous êtes noyés dans les problèmes d’incompatibilités de XMI, la réponse est ici. La clé de voûte de MDA, la transformation de modèles n’est pas en reste, puisque l’auteur développe les 3 approches possibles : transformation par programmation, par « templates » et par règles de programmation, la 1ère et le 3ème approche étant par la suite illustrés dans la prise en compte des plates-formes d’exécution, J2EE et PHP respectivement, la transformation entre 2 métamodèles différent (car l’auteur présente un métamodèle PHP simplifié pour l’occasion) est carrément la cerise sur le gâteau ! On est pas loin du tour de force.

Sur le fond, l’approche de l’auteur (fusion des informations de transformation avec le modèle) s’oppose avec l’approche de Kleppe & Warmer qui est de séparer les informations de transformation du modèle. Personnellement je préfère cette dernière approche. Cela ne retranche rien à la qualité de cet ouvrage, que je conseille à la condition que vous recherchiez l’approche « en profondeur » et soyez friand de métamodèles !

L’étude cas et la présentation de deux outils MDA (Rational Software Architect et Objecteering MDA Modeler) ne sont pas la meilleure partie de l’ouvrage, mais elles complètent utilement celui-ci en donnant une illustration concrète.

Voilà donc un livre solide et complet sur MDA. Il requiert un peu e motivation pour aborder le sujet sous l’angle métamodèle, mais il équilibre de façon fort heureuse les principes et la pratique, le tout dans un volume raisonnable, puisque le livre compte 260 pages.

MDA en Action

Référence complète : MDA en action : Ingénierie logicielle guidée par les modèles – Xavier Blanc – Eyrolles 2005 – ISBN : 2-212-11539-3

MDA en Action


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

Note de lecture : Succeeding with Agile, Software development using Scrum, par Mike Cohn

Note : 8 ; Réussir la transition vers l’agilité

En quelques années et avec 2 livres remarquablement écrits, Mike Cohn s’est imposé comme l’in des leaders du mouvement agile. Voilà donc un livre qui pouvait difficilement passer inaperçu au sein de la communauté !

Globalement, le livre est assez pesant, dans tous les sens du terme : avec ses 450 pages, d’abord, ensuite parce qu’il est composé presqu’exclusivement de texte. Ce n’est pas un texte qui s’avale en un week-end ! Heureusement, Mike Cohn sait écrire et il fait mieux qu’aligner des platitudes, mais je pense quand même que la présente prose n’est pas aussi efficace que celle de l’excellent « agile estimating and planning ». C’est aussi que j’attends beaucoup d’un auteur capable de délivrer un livre d’excellente qualité.

L’une des premières impression qui m’est venue à l’esprit, est le parallèle entre ce livre et celui de Craig Larman « agile & itérative development ». Le livre est divisé en 5 parties, il nous faut bien les passer en revue, car le contenu s’avère au final plutôt riche !

La première partie « getting started » compte 5 chapitres qui totalisent 92 pages. Ce n’est hélas pas la meilleure partie de l’ouvrage. Un large focus est mis sur les communautés de transition vers Scrum, sujet qui m’est apparu abstrait et hélas peu convaincant. Cette première partie se termine sur le choix du projet pilote. Certainement cela s’adresse à ceux qui ont ce choix, donc un public assez restreint pour autant qu’il existe. Heureusement, les parties suivantes reprennent du poil de la bête.

La seconde partie adresse les individus. Longue de 80 pages, elle compte 4 chapitres. Mes deux chapitres préférés sont le chapitre 6 sur le traitement des résistances au changement : agrémenté d’exemples, j’ai trouvé le tour d’horizon complet et pertinent. La façon d’adresser les différents types de résistances est aussi fort judicieuse. J’ai également apprécié le chapitre sur le changement des rôles, il va plus loin que le simple « oubliez ce qui existait avant ». Le rôle du « functionnal manager, par exemple, simplement méprisé par la littérature agile en général, est bien pris en compte.

Avec près de 150 pages et 7 chapitres, la 3ème partie consacrée à l’équipe est la plus longue du livre. Elle traite à la fois la structure de l’équipe et les pratiques de Scrum. Il s’agit justement du chapitre le plus « Scrum » du livre, et l’auteur y livre sont point de vue subjectif sur nombre de pratiques Scrum. Bien que n’étant pas en accords avec tous les points de vue de l’auteur, je n’en considère pas moins cette partie extrêmement riche : elle nous guide littéralement vers la mise en place de Scrum. A noter le chapitre sur la planification qui est un résumé du livre précédent de l’auteur … et une invitation à lire celui-ci !

La quatrième partie est consacrée à l’application de Scrum aux organisations. J’avoue m’être moins intéressé à cette partie qui ne fait pas partie de mes préoccupations. Les 100 pages découpés en 4 chapitres de cette partie évoquent surtout Scrum appliqué en équipes multiples, la coexistence avec d’autres approches et toutes ces sortes de choses..

La cinquième partie a forme de conclusion, avec ces 2 chapitres et ses 20 pages. L’auteur nous signifie simplement qu’on n’est pas au bout du chemin. On ne l’est jamais. On y voit quels outils utiliser pour s’évaluer et quels horizons il reste à explorer.

Comme je l’ai dit au début, le livre est assez lourd, parfois fastidieux à lire. Néanmoins il n’en reste pas moins un ouvrage majeure de cette littérature Scrum encore naissante. Et je pense qu’il le restera. Comment, vous ne l’avez pas encore commandé ?

succeeding-with-agile-Cohn

Référence complète : Succeeding with Agile, Software development using Scrum – Mike Cohn – Addison Wesley 2010 – ISBN : 0-321-57936-4 ; ISBN13 : 978-0-321-57936-2

Succeeding with Agile: Software Development Using Scrum


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

Note de lecture : Software Development for Small teams: A RUP centric approach, par Gary Pollice, Liz Augustine, Chris Lowe & Jas Madhur

Note: 2 ; « J’écris un programme avec 3 potes, et j’en profite pour écrire un bouquin là-dessus ».

On pourrait presque s’écrier : à l’arnaque ! On n’en est pas loin, et une note de « 2 », c’est plutôt bien payé. Mais commençons par le commencement. Le livre ne porte pas sur l’adaptation d’UP aux petites équipes, mais d’un seul et unique projet sur lequel les auteurs ont essayé UP, c’est donc d’avantage une étude de cas qu’une synthèse d’experts. D’ailleurs, en fait de projet, il s’agit plutôt d’un développement fait en marge de l’activité professionnelle des auteurs, on est donc très loin des conditions normales d’un projet, mais par contre très proche des conditions de développement en « open source », ce qui n’est malheureusement pas identifié, et devrait être valorisé dans le titre. Il y a bien peu de chose à retirer de cet ouvrage ; les conditions de projet ne sont pas là, l’utilisation d’UP est plus expérimentale qu’autre chose, l’outillage employé (et éhontément promu dans le texte) inapproprié n’était-ce le fait que les auteurs les connaissent parfaitement et en disposent gratuitement. Une fois que l’on a lu cela, on peut à juste titre se dire que l’on peut tous se mettre à écrire son livre.

Les 2 seuls points intéressant sont la description du développement de type open source / distribué et l’aspect « post mortem » particulièrement bien abordé. En bref : ne perdez pas votre temps sur ce bouquin.

soft-dev-small-teams-RUP

Référence complète : Software Development for Small teams: A RUP centric approach – Gary Pollice, Liz Augustine, Chris Lowe & Jas Madhur – Addison Wesley / O.T. series 2004 – ISBN: 0-321-19950-2

Software Development for Small Teams: A Rup-Centric Approach


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

Note de lecture : Patterns of Enterprise Application Architecture, par Martin Fowler & al.

Note: 8 ; J’ai des scrupules à le juger excellent …

Franchement, rien que la première partie justifie l’achat du livre. En une centaine de pages, l’auteur parvient à faire le tour des aspects sur lesquels il faut opérer des choix d’architecture et les contraintes qui peuvent nous guider vers telle ou telle solution. Le tout est exposé clairement et simplement, avec limpidité devrai-je même dire, par comparaison aux autres ouvrages dédiés à l’architecture logicielle. Voilà qui devrait être une saine source d’inspiration pour les auteurs des pavés de 1000 pages !

L’auteur prend des positions nettes par rapport à ces choix, et c’est tant mieux. Cette première partie, par sa qualité et son narratif me rappelle “UML distilled” du même auteur.

En revanche c’est à “Refactoring” que me fait penser la seconde partie du livre, car Martin Fowler a utilisé ici la même présentation pour ses patterns. C’est plutôt une qualité, car j’avais déjà trouvé cette présentation claire et intéressante, même si elle tend à mettre beaucoup d’emphase sur le code (nous avons le droit à du Java – essentiellement – et aussi du C#) et parfois pas assez l’accent sur l’essence de la solution. Ces patterns (il y en a tout de même 51) sont regroupés en “thèmes” qui font le pendant aux chapitres de la première partie :

  • Organisation de la logique métier.
  • Architecture des sources de données
  • Mapping comportemental objet-relationnel
  • Mapping structural objet-relationnel
  • Mapping objet-relationnel des métadonnées
  • Présentation Web
  • Distribution des traitements
  • Gestion transactionnelle
  • Gestion des états
  • Patterns de base

Ce qui m’a certainement le plus troublé (et même choqué, devrais-je dire), c’est l’absence de référence aux autres ouvrages ! Et pourtant il devrait y en avoir. Pire : nombre de patterns présentés ici ne sont guère que des reprises de patterns déjà publiés. Les indécrottables de la galaxie Patterns (j’en fais partie) s’en offusqueront. C’est ce dernier point qui m’incite à ne pas attribuer un 10 à cet excellent livre. Il y a toutefois un aspect pratique : nous avons un livre complet et auto-suffisant de patterns applicatifs dans lesquels faire notre marché pour les applications d’entreprise. Et cet ouvrage est de haute qualité, cela mérite certainement quelques concession… Martin Fowler nous a plus ou moins suggéré qu’il pourrait y avoir un second volume: nous l’attendons toujours…

patterns-enterprise-architecture

Référence complète : Patterns of Enterprise Application Architecture – Martin Fowler with David Rice, Matthew Foemmel, Edward Hieatt, Robert Mee and Randy Stafford – Addison Wesley / Signature series 2002 – ISBN: 0-321-12742-0

Patterns of Enterprise Application Architecture


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

Note de lecture : Tika in Action, par Chris A. Mattmann & Jukka L. Zitting

Note : 6 ; Comment faire un livre correct à partir d’un Framework qui ne le justifierait à priori pas !

Tika est un framework de l’écosystème Apache Lucene. Il s’agit d’un framework facile à utiliser, permettant d’extraire des informations de contenu et des métadonnées depuis de nombreux formats de fichiers. Les chapitres 5 et 6 nous disent presque tout ce que l’on a besoin de savoir pour utiliser Tika : extraire le texte et les métadonnées depuis un format de fichier en utilisant la très pratique façade Tika ! Les auteurs sont parvenus à passer de deux chapitres à 15 (200 pages) sans tomber dans le simple remplissage. Ils ont su explorer différentes facettes du Framework en gardant un propos intéressant.

La première partie « getting started » nous met au parfum des problématiques inhérentes aux différents formats de fichiers, à leur détection, à la lecture de leur contenu et des métadonnées. On y couvre aussi une description haut niveau de l’architecture de Tika et la façon de l’intégrer dans un projet. Cette partie se termine par la description de l’étude de cas Lucene : comment Tika s’intègre dans une architecture de moteur de recherche.

La seconde partie est le cœur de l’ouvrage : l’exploitation de Tika. On passe en revue successivement la détection de format, l’extraction du contenu puis des métadonnées pour aborder une intéressante description des algorithmes de détection de langage ! Le dernier chapitre de cette partie « what’s in a file » ne m’a pas laissé un souvenir impérissable.

La troisième partie est consacrée à l’intégration. Bien entendu on aborde la façon dont Tika s’intègre avec Lucene puis on aborde en détail la « search stack » Lucene, ce qui m’a donné une bonne compréhension du rôle des différents frameworks ! Le chapitre sur la façon d’étendre Tika est passé un peu vite à mon gréé et j’aurais aimé voir abordé l’intégration en utilisant Tika packagé en bundle OSGi : dommage !

Les quatre études de cas figurant en quatrième partie n’étaient certainement pas indispensables, surtout qu’elles restent assez superficiellement décrites. Mais elles sont une façon agréable de clore le livre.

Voici un livre qui n’est probablement pas indispensable pour simplement utiliser Tika. Mais les auteurs ont eu l’intelligence d’intégrer du matériel donnant plus de perspective : standards des métadonnées, détection de types, détection du langage, intégration dans une architecture de recherche, etc… Ce n’est donc pas une lecture indispensable, mais elle pourra être source d’inspiration quand à l’usage que l’on peut faire de ce type de fonctionnalités.

tika-inaction-manning

Référence complète : Tika in Action – Chris A. Mattmann & Jukka L. Zitting – Manning 2012 – ISBN : 978 1 935182 85 6

Tika in Action


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

Note de lecture : Extreme Programming Installed par Ron Jeffries, Ann Anderson & Chet Hendrickson

Note : 8 ; La mise en pratique réelle et concrète d’un projet XP.

La littérature ne manque pas, concernant l’extrême programming. Aussi, il peut être difficile d’y faire son choix. Le mien s’est arrêté sur « Extrême Programming Installed ». En effet, celui-ci se distingue des autres ouvrages par son coté résolument pratique, intégrant les retours d’expérience au texte. Les auteurs ont en effet partagé le même projet, ils nous font profiter de l’expérience issue de leur collaboration, ainsi que de projets XP antérieurs. Il est souvent difficile de se faire une idée concrète de la mise en œuvre d’un processus décrit non par le menu, mais par ses principes. Ici, les auteurs nous livrent des extraits de dialogues, des exemples de « user stories », des « minutes » d’une séance de test-first design et des exemples de tests unitaires, entre autre choses. Autre point intéressant : le livre répond clairement à certaines questions souvent laissées sans réponses : qui écrit les jeux de tests d’acceptation, qu’en est-il des erreurs provenant non des classes elle-même, mais de la collaborations entre classes, etc.. On regrettera cependant les prises de positions parfois “élitistes”, la pire d’entre elle étant le choix d’expliquer des choses en Smalltalk, qui ne peut être guère considéré comme un standard du marché. Le XP doit sortir de sa position de dédain envers le monde extérieur !

Ce livre, relativement succinct, comme tous les volumes de la « XP series » d’Addison Wesley, avec ses 240 pages ne compte cependant pas moins de 34 chapitres ! Seuls 23 d’entre eux (175 pages) constituent la partie principale de l’ouvrage, les 11 derniers sont considérés comme des « bonus tracks ». Celles-ci rassemblent des techniques particulières alternatives qui furent marquantes au cours du projet. Pour ma part, je retiendrais « It’s Chet’s Fault », où comment couper court aux stériles recherches de coupables afin d’aller vers l’avant. Les 23 chapitres principaux ne sont pas organisés de façon chronologique comme on aurait pu s’y attendre, mais par principes et techniques d’XP, considérant les valeurs fondamentales de la méthode comme acquises.

Finalement, plus que “Extreme Programming explained”, j’ai trouvé que cet ouvrage, par son coté vécu et le retour d’expérience qu’il relate, était le mieux à même de faire comprendre l’essence de l’Extreme Programming. Le style est vivant et le propos concret, c’est tout ce dont on a besoin pour se faire une idée de la méthode. Une lecture critique est cependant nécessaire, car le propos souvent dogmatique est quand même gênant.

XP-installed

Référence complète : Extreme Programming Installed – Ron Jeffries, Ann Anderson & Chet Hendrickson – Addison Wesley / XP series 2001 – ISBN: 0-201-70842-6

Extreme Programming Installed


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

Note de lecture : Kanban and Scrum, making the most of both – Henrik Kniberg & Mathias Skarin

Note : 7 ; L’une des meilleures références pour comprendre le Kanban, pour les praticiens de Scrum

La lecture de ce bref ouvrage avait deux objectifs pour moi : étrenner mon Kindle DX (mais je n’en parlerais pas ici) et rédiger une note de lecture sur la version française pour le French SUG.

Ouvrir un nouveau texte signé Henrik Kniberg était forcément pour moi un moment fort attendu, tellement le livre précédent était excellent. Mon premier réflexe est de voir la taille du livre : 128 pages d’une couverture à l’autre pour la version française, contre 122 pour la version originale. Ça va. Cette fois, Henrik s’est associé à Mathias Skarin, également consultant chez Crisp. La table des matières montre une répartition remarquablement symétrique : 50 pages nous viennent d’Henrik Kniberg et traitent de la comparaison de Kanban et de Scrum sur 16 chapitres. La seconde partie, rédigée par Mathias Skarin, est une étude de cas. Elle couvre également 50 pages sur 16 chapitres. On aura bien sûr compris que ces chapitres sont très courts, chacun couvrant 3 pages en moyenne !

Kanban et Scrum, s’ils peuvent être complémentaires, se distinguent fortement l’un de l’autre. Scrum se focalise sur l’itération, lui donnant un périmètre au départ et s’organisant de façon à ce que celle-ci aboutisse positivement en suivant l’avancement des tâches et en acquièrant du fedback à la fois au cours de l’itération et à sa fin. Kanban en revanche ignore pratiquement le concept d’itération, et se focalise sur le flux des tâches, sur les limites d’accumulation de celles-ci aux différents stades d’avancement et en organisant le travail des différents membres de l’équipe en fonction des goulots d’étranglements pouvant apparaître.

Continuer à lire « Note de lecture : Kanban and Scrum, making the most of both – Henrik Kniberg & Mathias Skarin » →

Note de lecture : Software Project Survival Guide, par Steve McConnell

Note : 5 ; Une approche seulement à demi itérative plutôt décevante

Steve McConnell fait partie des auteurs que je lis systématiquement, ce faisant j’ai fort peu de chances d’être déçu. C’est hélas le cas ici ! Pour « survivre » McConnell nous propose d’adopter le « stagged delivery », sorte d’approche à mi-chemin du mode itératif « time-boxed », sans toutefois lui être équivalent. Sans être à coté de la plaque, on sent que ce livre est antérieur aux publications sur les approches agiles : ici, on s’appuie beaucoup sur de la formalisation, je serais curieux de voir si l’auteur maintiendrai aujourd’hui ses positions, ou si il intègrerait ce nouvel éclairage. Au final, l’approche est assez proche du RUP, sans s’en réclamer. On reste sur sa faim.

L’ouvrage, en lui-même, est divisé en quatre sections principales :

  • The survival mind-set : Cette partie nous amène à prendre con science de plusieurs facteurs: quel est notre niveau de maturité actuel ? Quelles sont les compétences nécessaires et les facteurs clés de succès des projets.
  • Préparations : Cette section balaye les disciplines d’ingénierie des projets: gestion des exigences, architecture, assurance qualité, etc. L’auteur expose ici des vues particulières : utilisation intensive de prototypes dans la capture des exigences, gestion et contrôle des changements explicites via des CCBs, etc.
  • Succeeding stage by stage: On suit ici les phases de réalisation du projet. C’est certainement un des aspects les plus “vieillots” du texte, où l’on parle conception détaillée, précédent l’implémentation, elle-même précédant d’abord les tests puis le déploiement.
  • Mission accomplished: Cette partie indispensable couvre la rétrospective de projets.

Autant j’ai pu être ébloui par « Rapid Development » et son incroyable richesse, autant celui-ci m’a déçu. Evidemment tout est relatif, le contenu reste extrêmement pertinent et Steve McConnell reste un auteur très solide, ce qui justifie cette note franchement moyenne.

mcconnel-proj-survival-guide

Référence complète : Software Project Survival Guide – Steve McConnell – Microsoft press 1998 – ISBN: 1-57231-621-7

Software Project Survival Guide


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

Note de lecture : Agile Software Development Ecosystems, par Jim Highsmith

Note: 6 ; Le tribun des méthodes agiles … mais quelle longue narration !

Si vous souhaitez avoir une vue d’ensemble sur les méthodes agiles, quelle en est leur essence, quelles sont-elles et quelles sont leurs différences, alors voici LE livre. Jim Highsmith est lui-même l’auteur d’une de ces méthodes, mais cela ne l’empêche pas de présenter les autres avec une grande honnêteté et égalitarisme. En fait, bien qu’il joue sans ambiguïté dans le camp des agiliste, il met en vis à vis des méthodes présentées les approches traditionnelles plus prescriptives (analyse structurée, UP et basées CMM), toujours avec honnêteté.

Le plus grand défaut de ce livre, à mon avis, c’est sa longueur: il est étonnant de voir cet ouvrage s’étendre sur 400 pages alors que les différentes approches sont seulement survolées (seul leur “essence” est vraiment décrite, et c’est bien). Mais Jim Highsmith est un bavard, et même si leurs valeurs des méthodes agiles tiennent en une poignée d’idée, cela n’empêche pas l’auteur de s’étaler sur de longues pages de texte (les 400 pages ne comprennent quasiment pas de diagrammes ni autres illustrations). Fort heureusement, le style du narrateur n’est pas ennuyeux et sa longue expérience et son importante culture gardent le texte agréable, tout comme les interviews (eh oui!) des gourous des méthodes agiles. La moitié du volume aurait suffit, mais la lecture ne m’a cependant pas paru pesante.

Si un tour d’horizon de l’agilisme vous intéresse, nul autre ouvrage ne saurait remplacer celui-ci.

agile-soft-dev-ecosystems-Highsmith

Référence complète : Agile Software Development Ecosystems – Jim Highsmith – Addison Wesley / ASD series 2002 – ISBN: 0-201-76043-6

Agile Software Development Ecosystems


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

Note de lecture : Practical Project Initiation, a handbook with tools, par Karl E. Wiegers

Note : 6 ; Moins bien que d’habitude

Karl Wiegers nous a habitué à des ouvrages de qualité, aussi bien par la forme que sur le fond. Cet ouvrage de moins de 200 pages s’avérait donc prometteur car j’apprécie les auteurs qui savent s’exprimer avec concision. Finalement l’ouvrage manque sensiblement de corps. S’il passe bien en revue les différents aspects de la gestion de projet, il nous laisse largement sur notre faim en ce qui concerne le contenu. La plupart des 15 chapitres se concluent par des conseils de mises en pratiques et des templates, mais ni les uns ni les autres ne m’ont paru extrêmement pratiques, du moins pas assez pour que j’ai envie de m’y référer. Le livre se découpe en 5 parties.

La première partie est consacrée aux fondamentaux de la gestion de projets. Les 3 chapitres qui le composent couvrent 35 pages et peuvent être vus comme un survol du reste de l’ouvrage, c’est en tout cas l’objectif du chapitre 1, le « primer ». Le chapitre 2 se focalise sur les principales bonnes pratiques / mauvaises pratiques de la gestion de projet. Très pertinent et une bonne référence quand on veut prendre un peu de hauteur, tandis que le 3ème chapitre nous aide à considérer les priorités.

La seconde partie s’intitule pompeusement « preparing for success » et s’étale sur 65 pages soit 5 chapitres. Cette partie se devait d’être la plus solide mais elle n’est pas ma préférée. Le chapitre 4 s’intéresse aux critères de succès et aux objectifs d’un projet, un sujet important qui aurait pu être mieux traité. Le chapitre 5 considère la mesure de l’avancement (bonne idée). Le chapitre 6 évoque le « risk management », sujet important de l’aveu même de l’auteur mais bien légèrement traité. Le chapitre 7 suggère le développement d’une charte que je trouve bien peu convaincante.

La troisième partie s’intitule « vivre avec la réalité » et n’est longue que de 27 pages représentant 3 petits chapitres. Le chapitre 8 traite de la négociation des objectifs et est particulièrement intéressant. Au chapitre 9 l’auteur nous propose de mettre en place des « buffers » pour contrer les imprévus, ce que je désapprouve, mais c’est une question de point de vue. Le chapitre 11 est une nouvelle source de frustration car il aborde la dualité estimation / réalisation, mais de manière bien plus superficielle que Steve McConnell dans son art de l’estimation (auquel Karl Wiegers se réfère beaucoup, justement).

La quatrième partie évoque la mise en place de métriques. Le « Software metrics primer » du chapitre 12 est encore une fois bien léger ! Le chapitre 13 sur les pièges à éviter est bien plus instructif.

La dernière partie traite du retour d’expérience. Tout d’abord via le chapitre 14 qui évoque les « best practices »… et renvoie vers le « Rapid Application Development » de Steve McConnell ! Le chapitre 15 enfin fait état des rétrospectives, mais ne sert guère que d’introduction au remarquable ouvrage de Norman Kerth !

Mon propos montre pas mal de frustration à la lecture de cet ouvrage ! C’est le lot des bons auteurs que l’on en attende toujours les meilleurs. Cet ouvrage n’est certes pas l’œuvre la plus marquante de Karl Wiegers, mais étant assez condensé, il pourra servir d’ouvrage introductif au chef de projet junior, car il renvoie utilement vers des textes plus complets.

wieger-pract-proj-initiation

Référence complète : Practical Project Initiation, a handbook with tools – Karl E. Wiegers – Microsoft Press 2007 – EAN : 978 0 7356 2521 1

Practical Project Initiation: A Handbook with Tools


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