Étiquette : bookReview

Note de lecture : Lean from the Trenches, managing large-scale projets with Kanban, par Henrik Kniberg

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 10 ; Efficace, pertinent, intelligent !

J’ai acheté ce livre avec de grosses attentes. Non pas sur le contenu, car je ne me suis même pas préoccupé d’en connaître la teneur en l’achetant, mais simplement de par la connaissance des autres écrits d’Henrik Kniberg.

Henrik Kniberg aime faire court. Une tendance qui s’agrave avec l’âge : ce texte fait 150 pages. Et encore la partie principale (celle qui vient des tranchées) n’en compte que 100. A l’arnaque me direz-vous ? Il n’en est rien. L’auteur boucle en 100 pages ce qui en demande 250 à d’autres ! Ca tombe bien : notre temps est précieux, quand l’auteur va droit au but et fait que chaque ligne compte et donne de l’information, cela fait vraiment la différence. A ce jeux, Henrik Kniberg est le meilleur.

A l’image de Scrum from the trenches, l’auteur nous livre un retour d’expérience. Il nous livre ce qu’il a fait, ce qui a marché et ce qui n’a pas marché, comment son équipe en est arrivé là et qu’est-ce qui reste imparfait. Le texte est un modèle de clarté, de pertinence et d’honnêteté. Il est éclairant de par ses bonnes idées, par la démarche et l’analyse fine qui sous-tend cela. Mais que recèle donc ce texte ?

En fait les 16 (oui, 16 chapitres sur 100 pages !) tournent autour du tableau Kanban : la façon dont il est construit, comment a-t-il évolué, quelles sont les dynamiques de travail qui gravitent autour, quelles métriques en sont extraites. Bien sûr le texte est naturellement illustré par des photos (parfois auxquelles des indications sont supperposées) du Kanban ou de l’équipe. L’auteur n’a pas essayé de décrire de manière approfondie la façon de travailler de l’équipe (à la façon de ce qu’il avait fait dans « Scrum from the Trenches »), mais plutôt de se focaliser sur les dynamiques de l’équipe et du projet.

La seconde partie consacre 4 chapitres sur 50 pages pour évoquer certains aspects plus informatifs auxquels le texte principal se rapporte : ce qu’il y a dans XP, Scrum, Lean et Kanban ; l’automatisation des tests ; le planning poker et les diagrammes de cause-effets. Chaque chapitre est un modèle de pertinence et de concision.

Je ne vais pas passer du temps à décrire ce que contient le livre : il vous faut simplement le lire vous-même. Si vous êtes agiliste, débutant ou expert, il n’y a simplement aucune raison, aucune excuse pour ne pas consacrer du temps à vous plonger dedans !

lean-from-trenches-pragprog

Référence complète : Lean from the Trenches, managing large-scale projets with Kanban – Henrik Kniberg – Pragmatic Bookshelf 2011 – ISBN : 978-1-934356-85-2

Lean from the Trenches: Managing Large-Scale Projects with Kanban


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

Note de lecture : Effective C++, 55 specific ways to improve yours programs and designs, 3rd edition, par Scott Meyers

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 10 ; Un texte à l’écriture hors pair, remis à jour en prenant en compte la STL, mais toujours irréprochable!

Je sais que vous pouvais être surpris de voir une note de relecture sur un livre dédié à C++ ici ! Sachez deux choses:

  • Ayant pratiqué C++ pendant 12 ans, j’ai un très important fond de commerce de livres, et donc de notes de lectures, sur C++.
  • Discutant l’autre jour avec une de mes collègues, nous parlions de style d’écriture de livres, et de ce à quoi ressemble un très, très bon style d’écriture. De ceux qui vous accrochent, vous passionne, vous font comprendre les choses et vous font rire, quel que soit la complexité ou l’aridité du sujet. L’exemplarité dans le domaine existe, de mon point de vue. Parmi plusieurs centaines de livres, il s’agit de cet auteur là, de ce livre là. Sans aucun doute possible.

Pour ceux qui seraient inquiets quand à cette 3ème édition de l’ouvrage, le style de l’auteur est resté égal à lui-même : un régal ! En fait, l’écriture de Scott Meyers est l’exemple même de ce que devrait être l’écriture d’un texte technique. La première fois que j’ai lu cet auteur, j’ai dû avaler le livre en 2 ou 3 jours. On s’y accroche tel en bon roman, peut-être ai-je surpris des personnes dans le métro en éclatant de rire… Il m’a fallu un moment pour que je prenne conscience, une fois la dernière page tournée, que j’avais lu un texte très technique !

Alors c’est vrai : j’ai sauté la seconde édition ! Je devrais donc me contenter de comparer cette 3ème mouture avec la seconde édition. Dix ans ont passé depuis, et l’auteur a fait bien plus qu’un simple rafraichissement des items présentés, il a effectué un travail d’introspection en réévaluant la pertinence des items (9 ont disparus), en créant de nouveaux (15 items complètement nouveaux), en fusionnant certains et en découpant d’autres. Au-delà de ce remaniement, le texte est complètement revu, eut égard au niveau des compilateurs actuels, de la librairie standard et même du futur standard, et même de la librairie Boost. On trouve aussi des inspirations nouvelles : ainsi le « copy and swap », les 3 types de garanties (basic guarantee, strong guarantee et no-throw guarantee) ainsi que le NVI idiome sont directement inspirés des « exceptional C++ » de Herb Sutter, d’ailleurs largement cité en préface.

Ce volume est plus épais que les précédents, avec ses 280 pages, en impression bicolore, s’il vous plait ! Je vois une double raison pour céder à la lecture de cette seconde édition : se rafraichir la mémoire sur les bonnes pratiques de Meyers, dans le contexte actuel du C++ et découvrir de nouvelles choses non traitées dans les éditions précédentes (dans les nouveaux items comme dans les items existant). Je vous laisse deviner la conclusion qui s’impose…

Pour ceux qui n’ont rien à faire du C++ mais rêvent de devenir auteur, et même auteur hors pair, voici ce à quoi vous pouvez vous mesurer. Je n’ai aucune meilleure référence à vous proposer.

effective-c++-3edt-Meyers

Référence complète : Effective C++, 55 specific ways to improve yours programs and designs, 3rd edition – Scott Meyers – Addison Wesley / Professional Computing series 2005 – ISBN: 0-321-33487-6

Nb : La première édition de ce livre était mon “book of the year” 1994.

Effective C++: 55 Specific Ways to Improve Your Programs and Designs


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

Note de lecture : Software Project Manager’s Bridge to Agility, par Michele Sliger & Stacia Broderick

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Du PMI à l’agilité par des auteurs qui savent de quoi ils parlent !

Franchir le pas entre les approches classiques et l’agilité est un thème désormais classique. Mais la littérature traitant sérieusement de cette transition est plutôt rare. Les auteurs de ce livre ont un passé (ou un passif) lié au PMBOK plutôt sérieux, elles ont donc largement la crédibilité nécessaire pour attaquer le sujet sous cet angle.

L’agiliste accompli apprendra peu de choses à la lecture de cet ouvrage. Cela ne signifie pas pour autant que la lecture ne puisse en être profitable : si votre besoin est de pouvoir expliquer ou argumenter le passage à l’agilité aux managers classiques, voici un texte sérieux sur lequel s’appuyer !

Cela dit, la cible privilégiée du livre n’est pas celle-ci. Le texte s’adresse directement aux managers et aux « middle managers » issus de la culture de la gestion de projet en cascade. Il s’adresse directement à eux pour expliquer comment passer à l’agilité, quels en sont les bénéfices, la façon de changer les différentes pratiques et la nouvelle posture qu’ils doivent prendre dans cet environnement changé.

Sur le fond, nous avons un matériel assez dense accusant 330 pages, donc une taille de livre moyenne, mais malgré une bonne illustration du propos, cela reste du tassé du point de vue texte. Fort heureusement, les 300 pages du texte principal sont très bien découpés en 17 chapitres d’une part, eux même regroupés en 3 parties formant une progression logique. Chaque chapitre est élégamment introduit avec de surcroit une ou deux citations toujours fort bien choisies. Pour clore les chapitres, nous avons aussi chaque fois un résumé reprenant sous forme de liste à points les éléments passés en revue et une liste des références présentes dans le texte. Un travail de très bonne facture, le découpage en chapitres de moins de 20 pages en rend la lecture plaisante.

La première partie « an agile overview » consacre 3 chapitres à la présentation du monde agile au manager PMI. On commence pour les principes de l’agilité, le manifeste, etc… Bref, les grands classiques. La suite est plus originale, car on passe vers un « mapping » des principes PMI vers les principes agiles. Pour finir on fait un tour du propriétaire du projet agile (itération planning meeting, stand-up, etc…) en le comparant à son pendant PMI.

La seconde partie est la plus conséquente du livre, elle compte 9 chapitres sur 160 pages. Elle aborde les différentes facettes d’un projet en se calquant sur l’approche PMI des différents domaines à couvrir : intégration, cadrage, gestion du temps, gestion des coûts, qualité, ressources humaines, communication, gestion du risque, sous-traitance. Malgré cet angle d’attaque, jamais les auteurs n’abdiquent sur l’approche agile et ils présentent l’alternative agile avec beaucoup d’à propos et de pertinence. J’ai peu à dire là dessus, car si j’ai peu appris, le tout est fort bien ficelé.

La 3ème partie évoque la problématique de la transition. 80 pages sur 5 chapitres y sont consacré. Cela va du changement dans le type de management, à la façon de vendre l’agilité jusqu’aux écueils dans lesquels ne pas tomber. Personnellement, c’est la partie qui m’a le plus apporté.

Au final, un livre qui n’apprendra probablement rien à l’agiliste confirmé, mais pourra aider un coach à faire changer un manager classique vers une approche agile. Mais surtout, c’est probablement la meilleure lecture que l’on puisse proposer à ce dernier pour réussir son changement. Bien entendu, cela nécessite au préalable le bon état d’esprit !

soft-PM-bridge-agility

Référence complète : Software Project Manager’s Bridge to Agility – Michele Sliger & Stacia Broderick – Addison Wesley ASD series 2008 – ISBN : 978 0 321 50275 9

The Software Project Manager's Bridge to Agility


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

Note de lecture : Ship it ! A practical Guide to Successful Software Projects, par Jared Richardson & William Gwaltney Jr

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Dans la continuité des « pragmatic programmers », mais en manque d’originalité.

Qu’est-ce qui fait que certaines équipes s’enlisent, tandis que d’autres parviennent à délivrer ? Cette question est le point récurent des méthodes agiles, c’est le fer de lance de cet ouvrage qui n’a donc pas grand-chose d’original à cet égard. Le texte reprend les bonnes pratiques du « pragmatic programmers », en les unissant dans un processus agile découpé en 3 sous-ensembles (formant autant de chapitres du livre :

Techniques ; Cette partie regroupe 5 pratiques : Technical Lead (en fait le chef de projet), The List (la « feature list » de Scrum), Daily Meeting (le daily meeting d’XP), Code Reviews et Code Change Notifier. Il y a peu d’originalité dans ces pratiques communes à la plupart des méthodes agiles. Toutefois la description du « Technical Lead », à la fois gourou technique et gestionnaire des hommes et des plannings me laisse perplexe, tandis que le manager est vu comme un espèce de VRP…

Infrastructure ; Cette partie regroupe 6 pratiques dont 4 sont liées à l’automatisation : Version Control, Script Builds, Write and Run Tests et Continuous Builds. On remarquera que « continuous build » et « script builds » sont sinon liés, au moins dans la continuité l’un de l’autre. Les deux dernières pratiques sont Track Features et Track Issues, là encore 2 pratiques très liées et intimement liées à « The List », mais vu sous la facette Infrastructure !

La partie Process regroupe 5 pratique liées au développement de l’architecture : Propose System Objects, Propose Interfaces, Connect Interfaces, Add Functions et Refactor Refine Repeat. Le but de cette approche est de définir une architecture par découpage n composants majeurs, puis de définir ces composants par leurs interfaces que l’on connecte ensuite, pour finalement les « étoffer » avec la mécanique. Le réfactoring ajoute la touche finale de raffinement de l’architecture.

Comme je l’ai dit au début, il y a peu d’originalité dans ce livre, même si en soi il constitue un texte valable, il a du mal à sortir du lot. Parmi les particularités, je note toutefois les itérations de longueur variable, mais de contenu fixe. Un point de vue qui, hélas, me laisse également perplexe…

ship-it-pragprog

Référence complète : Ship it ! A practical Guide to Successful Software Projects – Jared R. Richardson & William A. Gwaltney Jr – The Pragmatic Bookshelf 2005 – ISBN : 0-9745140-4-7

Ship It!: A Practical Guide to Successful Software Projects


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

Note de lecture : Applying Use Cases 2nd edition, par Geri Schneider & Jason P. Winter

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 9 ; Un simple raffinement d’un livre déjà excellent, mais qui va dans le bon sens.

J’ai quelques références sur les Use Cases dans ma bibliographie. Ce texte-ci est l’un de mes préférés, sinon mon préféré. Historiquement, à mon échelle, c’est par la note de lecture de la 1ère édition de ce livre que j’ai commencé ma compilation bibliographique il y a maintenant 14 ans.

C’est un ouvrage succinct (environ 170 pages hors annexes), exclusivement destiné aux uses cases, à leur utilisation, leur développements (use case scénarios, diagrammes d’activité, liens vers la modélisation), leur documentation. Le propos est très clair, très direct et bien illustré à l’aide d’un exemple développé au long du livre. La taille réduite du livre fait partie de ses qualités, la substance utile étant très importante. 

Pour cette seconde édition, je m’attendais à d’avantage d’évolutions. En fait, les auteurs ont simplement repris leur matériel de base, en le réorganisant et en mettant à jour certains concepts (relations “includes” et héritage, ainsi que cas d’utilisation subordonnés).  La partie la plus faible de l’édition précédente (documentation des cas d’utilisation) a désormais atteint la qualité des autres chapitres et certains nouveaux thèmes ont été abordés comme les Use Case “CRUD” et les exigences complémentaires. La lourde description de l’étude de cas qui encombrait un peu l’ouvrage a été rejeté en annexe ou elle figure désormais de façon plus complète. Finalement, les auteurs ont réussi le tour de force de remettre à jour cet ouvrage sans nous pénaliser de l’augmentation de volume qui en est le corollaire. Toujours excellent, donc.

Un livre que je conseille très fortement, sans arrières pensés.

applying-usecases-2

Référence complète : Applying Use Cases, second edition, a practical guide – Geri Schneider & Jason P. Winter – Addison Wesley / O.T. series 2001 – ISBN: 0-201-70853-1

Nb: La première édition de cet ouvrage était mon “book of the year” 1998

Applying Use Cases: A Practical Guide


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

Note de lecture : Crossing the Chasm, par Geoffrey A. Moore

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 5 ; Un grand classique du marketing des produits High tech.

Geoffrey Moore est célèbre pour sa fameuse courbe d’adoption des produits High Tech, et c’est bien de cela qu’il est question ici : de l’adoption des produits. Ou plutôt, pour être exact, de la transition séparant les visionnaires et innovateurs des pragmatiques (et des frileux) constituant la « early majority ».

Cet ouvrage est un livre de marketing, il n’y a pas de doutes à avoir là-dessus, aussi les sujets abordés peuvent être troublants parfois pour des techniciens. Mais c’est aussi l’intérêt de ce type de livres : aborder un sujet qui nous est familier avec un regard complètement différent de ce à quoi nous sommes habitués.

Ce grand classique se focalise finalement sur un sujet précis : comment franchir le fossé qui sépare les innovateurs des pragmatiques. Tout d’abord le texte identifie précisément pourquoi ce fossé existe et en quoi il est difficile à franchir car l’approche envers les innovateurs n’est en rien une aide à conquérir les pragmatiques, c’est en fait même souvent l’inverse. La première partie du livre est entièrement consacrée à cet éclairage.

En seconde partie, Geoffrey More nous propose une tactique de conquête de cette autre rive de la courbe : cibler une niche très précise pour y prendre pied, prendre une position dominante sur cette niche étroite en proposant un « produit complet » adapté à la problématique métier, et non simplement un « bel outil » comme l’apprécie les innovateurs. Les chapitres 3 et 4 traitent de cet aspect.

Les derniers chapitres évoquent la façon de vendre ce produit aux pragmatiques et les choix à faire par rapport à la dualité de marché innovateurs / pragmatiques. Quels canaux de vente privilégier, quel profil de force commerciale rechercher.

En ce qui me concerne, deux choses m’ont rendu la lecture un peu difficile : le peu de structure que l’auteur apporte à son propos : Geoffrey Moore adopte un style assez littéraire, fonctionnant plus par association d’idée que par structuration de la pensée. Cela fonctionne certainement assez bien pour des lecteurs baignant déjà bien dans le sujet et qui y possèdent des repères. En revanche, pour les nouveaux venus comme moi, c’est bien plus dur ! Un autre point également, à mettre en perspective avec les livres d’informatique en Anglais que j’ai l’habitude de lire : la variété du vocabulaire. Cela a parfois ralentit ma lecture. Heureusement que le Kindle dispose d’un dictionnaire intégré !

En bref, je n’ai certainement pas perdu mon temps. Les petites difficultés d’immersion dans le texte ont certainement un peu réduit mon plaisir, mais je dois admettre que l’auteur m’a fait découvrir tout un nouveau pan de connaissances relatives à un monde qui est mon quotidien.

CrossingTheChasm

Référence complète : Crossing the Chasm – Geoffrey A. Moore – HaperCollins Publishers 2001 – ISBN : 0-06-008718-8 (Kindle édition)

Crossing the Chasm: Marketing and Selling Technology Project


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

Note de lecture : Dynamics of Software Development, par Jim & Michele McCarthy & Michele McCarthy

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Difficile à lire…

Cet ouvrage (plutôt succinct, moins de 200 pages) a été originellement écrit en 1995. L’auteur fut chef de produit sur Visual C++ 1.0, produit que j’ai personnellement trouvé fort peu convaincant, mais il est vrai moins « has been » que son prédécesseur MSC 7.0 ! Le texte est donc assez ancien, datant d’une époque de croissance des applications Windows, et il ignore donc le nouveau paysage créé par l’Internet (dont le texte ne parle pas du tout). Curieusement, dans cette mise à jour, la prose originale n’a pas été touchée, hormis parfois une petite note.

Le livre est structuré en 2 parties, plus une « troisième partie » sous une forme de vidéo de l’auteur. La première partie compte 154 pages divisés en 5 chapitres (de tailles très inégales) plus une annexe, eux-mêmes structurés en 54 items. Ces chapitres correspondent aux phases de développement, non pas calquées sur les classiques et fort peu réalistes « recueil des besoins, analyse, conception, etc… », mais plutôt sur une analogie du jeu d’échec :

• Opening moves : on parle ici du lancement du projet, de son organisation et de ses objectifs.

• The middle game : il représente le « ventre mou » du projet, la partie la plus longue durant laquelle le projet est sur les rails, mais où les features doivent être construites.

• Ship mode : Qu’est-il nécessaire de faire pour livrer le produit, une fois le développement complété ? Ce chapitre traite des activités de fin du projet.

• The launch : Comment gérer une arrivée sur le marché, comment créer un évènement de lancement ?

J’ai trouvé le texte intéressant par endroit, certaines des idées sont franchement précurseur des principes agiles (je pense entre autre aux « feature teams », mais l’aspect historique est généralement de peu d’intérêt pour le lecteur. Le problème le plus ardu est celui de l’anglais, trop recherché et surtout souvent trop imagé qui en diminue l’impact pour le lecteur français. Que penser de « don’t flip the bozo bit », par exemple ?

Bref, malgré sa réputation, je ne saurais conseiller cet ouvrage, pas assez (ou plus assez) original par lui-même et trop difficile à lire, nonobstant son petit volume.

The Dynamics of Software Development

Référence complète : Dynamics of Software Development – Jim McCarthy & Michele McCarthy – Microsoft press 2006 – ISBN : 0-7356-2319-8 ; EAN : 978-0-735-62319-4

Dynamics of Software Development


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

Note de lecture : The Human Interface: New directions for designing interactive systems, par Jef Raskin

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Le testament du père du MacIntosh

Ce livre ne traite pas d’une démarche de conception d’interface homme-machine, pas plus qu’il ne propose un guide de réalisation de ces interfaces. Non, en fait cet ouvrage traite du fond du problème, c’est-à-dire comment concevoir une interface adaptée à la façon de fonctionner de l’esprit humain. C’est ainsi qu’avant toute chose Jef Raskin aborde le conscient et l’inconscient et le fonctionnement de la mémoire immédiate et de la « localisation de l’attention ». Les solutions que propose Raskin sont radicales et rompent avec le courant actuel des interfaces fenêtrées et s’appuient sur des paradigmes tels que des interfaces non modales (dont le comportement ne dépend pas du contexte d’utilisation) et une navigation par zooming plutôt que par défilement. Plus encore que ce qu’il avait fait pour le MacIntosh, Raskin veut « enfouir » le système d’exploitation pour le rendre invisible, par exemple via une manipulation centré sur l’appel des fonctionnalités plutôt que sur le lancement d’applications, en abandonnant la manipulation de fichiers et même l’invocation directe de l’enregistrement des données sur le disque.

Bref, c’est un nouveau bond que l’auteur veut accomplir pour une « interface humaine », ses préconisations sont de fait troublantes, voir dérangeantes, eut égard à ce que nous connaissons, mais c’est aussi ce que nous recherchons des visionnaires, qu’ils remettent en cause nos certitudes. Nombre des concepts exposés sont démontrés sur un ordinateur qu’a conçu l’auteur : le Canon Cat. Ce n’est pourtant pas la machine la plus connue qu’il ait développé. Le créateur du MacIntosh est décédé le 26 Février 2005.

Ce livre n’est pas facile à lire, beaucoup de concepts sont difficiles à appréhender et nécessitent une bonne capacité d’abstraction pour suivre l fil de l’auteur. Mais les idées qu’exposent l’auteur n’existent nulle part ailleurs.

human-interface

Référence complète : The Human Interface: New directions for designing interactive systems – Jef Raskin – Addison Wesley / ACM press 2000 – ISBN: 0-201-37937-6; EAN: 978-0-201-37937-2

The Humane Interface: New Directions for Designing Interactive Systems


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

Note de lecture : Software Requirements, 2nd edition, par Karl E. Wiegers

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 9 ; Encore meilleurs avec le temps … et toujours une référence sur la gestion des exigences!

Je l’avais dit ailleurs, mais j’estime qu’un ouvrage dans sa seconde édition qui ne s’améliore pas mérite une note en baisse ! Vous pouvez donc déjà conclure qu’en gardant la même note que j’avais attribué à la première édition, cette nouvelle mouture a amélioré le texte original. Pas seulement amélioré d’ailleurs, mais aussi amplifié car l’ouvrage est augmenté de 100 pages. Après presque 10 ans de perspective sur les écrits concernant la gestion des exigences, Karl Wieger et les Robertson restent mes ouvrages de référence sur le sujet. Ce n’est pas rien et cette mise à jour (qui est en fait plus que cela) remet le livre en selle pour autant qu’il fût jamais détrôné.

La structure du livre est passée de 3 parties à 4 et le découpage a également évolué. Je ne vais pas rentrer dans le détail des chapitres, mais tenter de parler de chacune des parties.

La première partie est intitulée « Software requirements : What and Why ». A priori cette partie est dévolue aux nouveaux venus dans la partie. Erreur, cette partie mérite d’être également étudiée par les analystes expérimentés tout autant ! A la place des banalités convenues, l’auteur explique clairement et nettement les différents types de besoins et les différentes perspectives à considérer sur leur expression. On y aborde avec honnêteté les attentes des utilisateurs et la façon concrète et pragmatique dont on peut les aborder dans le cadre d’un projet. Les « bonnes pratiques » nous renvoient aux droits et aux devoirs de l’analyste et de l’utilisateur durant l’expression des besoins. Sans jamais réellement évoquer l’approche agile, l’état d’esprit y est et je conseillerais sans hésitation la lecture de cette première partie à tout agiliste !

La seconde partie porte tout simplement comme titre « Software requirements developpement ». Avec ses 220 pages et ses 12 chapitres, c’est la plus longue du livre ! Il s’agit d’une approche « par facette » plus que par activité et qui couvre remarquablement toute l’activité de recueil du besoin : établissement de la vision, dialogue avec les utilisateurs, règles métiers, scénarios d’usage, documentation, validation, qualification, etc… Chaque chapitre est clairement focalisé sur un point de vue, clair et riche sans se perdre dans des considérations stériles.

La troisième partie est consacrée au « requirements managements », où comment gérer l’évolution des exigences dans le temps. Cela couvre l’outillage, la gestion des changements et de la traçabilité. Si cela ne couvre que 65 pages, ne croyez pas pour autant que le sujet est traité avec légèreté car l’essentiel est dit, même si il peut être complété par ailleurs.

La dernière partie « implementing requirements engineering » est nouvelle et certainement moins passionnante (sans être mauvaise). Mais on est plus loin des processus agiles.

La première édition était bonne, la seconde l’est plus encore. L’ouvrage couvre avec succès toutes les facettes du recueil des besoins et peut figurer comme seul ouvrage sur la gestion des exigences dans votre bibliothèque si vous ne souhaitez qu’un livre.

wieger-soft-reqt

Référence complète : Software Requirements, 2nd edition – Karl E. Wiegers – Microsoft press 2003 – ISBN: 0-7356-1879-8; EAN: 978 0 7356 1879 4

Software Requirements: Practical Techniques for Gathering and Managing Requirements Throughout the Product Development Cycle

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

Note de lecture : Writing Effective Use Cases, par Alistair Cockburn

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; D’excellents conseils rédactionnels et une bonne approche “adaptative” de la modélisation des systèmes.

Ce livre se focalise entièrement sur la rédaction textuelle des cas d’utilisation. A ce titre, il relativise la description graphique comme étant une vue synthétique du périmètre fonctionnel. Alistair prêche une approche par décomposition fonctionnelle dans laquelle on part des business cases pour descendre jusqu’à des uses cases de type sous routines. A chaque niveau (représenté par une icône) on détermine l’objectif de l’acteur principal comme étant la force essentielle dans la détermination du cas d’utilisation.

Le livre est excellent pour ce qui est de décrire des Use Cases optimaux et clairs, donc suffisamment courts et concis pour être lus et compris. Qui plus est, des mémentos permettent de se rappeler quelles sont les règles à suivre dans l’écriture des Use Cases. Ce livre est d’avantage dédié aux personnes pratiquant déjà les cas d’utilisation et désireuses de progresser qu’aux nouveaux venus qui risquent de se retrouver quelque peu noyés. Enfin certains aspects tels que la décomposition fonctionnelle utilisant abondamment les relations d’inclusion sont critiquables voire dangereuses lorsque utilisées à mauvais escient.

writing-effective-use-cases

Référence complète : Writing Effective Use Cases – Alistair Cockburn – Addison Wesley / Crystal Collection for Software professionals 2001 – ISBN: 0-201-70225-8; EAN: 978-0-201-70225-5

Writing Effective Use Cases


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