Catégorie : Notes de lecture

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

Note de lecture : Software Configuration Management Patterns: Effective Teamwork, Practical Integration par Stephen Berczuk & Brad Appleton

Le par addinquydans Notes de lectureLaisser un commentaire

Note: 8 ; Un “langage de patterns” bien construit, mais aussi une excellente référence sur la gestion de configuration.

On trouve deux types d’ouvrages sur la gestion de configuration : ceux développant des processus de gestion de configuration, souvent compliqués et éloignés des préoccupation quotidiennes des développeurs, et ceux traitant des outils, les détaillant en profondeur mais sans réellement expliquer comment les utiliser intelligemment. Cet ouvrage se démarque résolument de ces deux tendances en exposant les principes de la gestion de version et de configuration sous forme de « process patterns » qui sont autant de cas d’utilisation. Des cas d’utilisation résolument tournés vers le développeur, afin de l’aider dans ses tâches quotidiennes.

Une courte première partie introductive recadre la place de l’outil de gestion de versions et de configuration dans l’environnement de développement. Il présente également la structure des patterns et l’image globale de ce langage de patterns. On y distingue deux sous-ensembles : les patterns orientés « codeline » c’est-à-dire purement gestion de version, et les patterns liés à la gestion de l’espace de travail.

La seconde partie, forte de 120 pages, forme 16 chapitre, chacun présentant un pattern (donc, une moyenne de 7 pages par patterns). Je ne saurais tous les présenter, mais en voici quelques uns :

Active development line : Comment gérer une branche de développement suffisamment utilisable et stable à tout moment, afin de satisfaire les besoins de développement

Private build : Pensez de façon globale, et construisez localement. Ou comment, avant de soumettre des changements, construire et tester de manière identique au build d’intégration, mais sur l’espace privé de développement

Intégration build : Pour s’assurer que toutes les changements injectés dans le repository central sont construits et testés par un processus centralisé.

Task level commit : Pousser dans le gestionnaire de versions à chaque changement de faible granularité mais indissociable (résolution d’un problème, mise en conformité avec une évolution d’interface, etc.).

Comme c’est le cas avec les bons patterns, un bon nombre nous donne un goût de déjà-vu. D’autres moins. L’approche « patterns » est réellement utilisée à bon escient : le problème est évoqué, souvent étayé par une expérience vécue, pour déboucher ensuite sur le développement de la solution, soutenus par des références extérieures. On appréciera aussi, mine de rien, de voir relevé en vis-à-vis des patterns, les points non résolus ! Que vous soyez expérimentés ou débutant, vous devriez vous régaler à la lecture de ces patterns : on bénéficie réellement de l’expérience et de la qualité de synthèse et d’expression des auteurs. Connaître les commandes de votre outil de gestion de version n’est pas tout (bien que cela soit nécessaire), il faut savoir utiliser et organiser son travail au quotidien afin de travailler de façon efficace, coopérative et rigoureuse afin d’éviter les problèmes inhérents au travail en équipe. Ce langage de pattern est sans nul doute la réponse pragmatique, efficace et opérationnelle. Le tout en moins de 200 pages. Last but non least, les appendices si succincts soient-ils fournissent d’excellents liens Web et une ébauche d’évaluation des outils existants. Vous aurez compris : j’ai aimé.

Les DVCS ont certainement ajouté leur lot de patterns également, même si ceux évoqués ci-dessus restent d’actualité. J’adorerais voir une seconde édition de l’ouvrage intégrant cela. Une autre avancé possible est la prise en compte de la déliverie en continue (le devops) dans le cycle logiciel abordé.

Les auteurs travaillent à une seconde version de l’ouvrage, toutefois celle-ci est encore à l’état de projet. Il n’est d’ailleurs pas dit qu’elle sorte un jour.

soft-conf-mgt-patterns

Référence complète : Software Configuration Management Patterns: Effective Teamwork, Practical Integration – Stephen P. Berczuk & Brad Appleton – Addison Wesley / SP series 2002 – ISBN : 0-201-74117-2

Software Configuration Management Patterns: Effective Teamwork, Practical Integration

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

Note de lecture : Manage Your Project Portfolio, Increase your capacity and finish more projects, par Johanna Rothman

Le par addinquydans Notes de lectureLaisser un commentaire

Note:6 ; Pas aussi bien qu’espéré

Voilà un sujet qui m’intéresse au premier chef : comment gérer, non pas un projet, mais un ensemble de projets organisés en un « portefeuille ». La grande qualité de cet ouvrage est certainement de ne pas chercher midi à quatorze heures, et de rester simple et pragmatique. D’ailleurs le format du livre reflète cette concision : 11 chapitres couvrant 160 pages.

Les deux premiers chapitres nous font découvrir ce qu’est un portefeuille de projets, comment le structurer et comprendre le cycle de vie de ses projets.

Dans les chapitres 3 et 4, on apprend tout d’abord à organiser ses projets : quel doit être leur granularité ? Les projets doivent-ils être structurés en programmes ? On y voit finalement quoi envisager de l’avenir d’un projet commit, kill, transform) en fonction de sa nature.

Prioriser et travailler en groupe pour décider du devenir du portefeuille sont l’objet des chapitres 5 et 6. L’auteur y propose plusieurs techniques à cet égard.

Les chapitres 7 à 9 s’avèrent moins originaux : ils traitent de la vie et de l’évolution itérative du portefeuille. Ce qu’on y lit, bien qu’intéressant, ne diffère guère de ce que l’auteur a pu dire de la gestion de projets dans « Manage It ». Même si le propos sur l’approche agile en général, et le Lean en particulier sont clairement intéressants, ils n sont pas spécialement originaux dans le contexte de ce sujet en particulier.

Le chapitre 10 sur les mesures peut également aussi bien s’appliquer au niveau d’un portefeuille que d’un projet. Je pense quand même qu’appliquer ces métriques au niveau de l’itération relève d’une granularité trop fine. Simple question d’appréciation personnelle.

Fort heureusement, on termine avec une note plus originale : définir sa mission, en tant qu’équipe ou en tant que manager. C’est un exercice à la fois simple et dans le principe et difficile dans la mise en œuvre. Mais il éclaire beaucoup dans la ligne de conduite et la façon d’évaluer son portefeuille de projets.

En bref, voici un livre qui donnera un certain nombre de clés pour réussir à gérer son portefeuille de projets. En fait, j’ai déjà utilisé une partie de ce que l’auteur propose pour travailler mon propre portefeuille de projets, avec succès. Je suis toutefois un peu déçu par ce que j’y ai trouvé, mais certainement parce que mes attentes se situaient assez haut, eu égard à ce que l’auteur nous a livré jusqu’ici.

Ma note reflète surtout mon niveau d’exigence par rapport aux textes écrits par Johanna Rothman : il est bien plus élevé que pour le commun des auteurs. Malgré une notation qui peut paraître modérée, c’est un livre que je recommande sans réserves.

manage-project-portfolio-pragprog

Référence complète : Manage Your Project Portfolio, Increase your capacity and finish more projects – Johanna Rothman – The Pragmatic Bookshelf 2009 – ISBN: 978 1 93435 629 6

Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects


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

Note de lecture : Software Estimation, Demystifying the Black Art, par Steve McConnell

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; Steve McConnell frappe encore!

Les ouvrages de Steve McConnell sont parmi les seuls que j’achète sans les ouvrir : quand je vois un nouveau titre, je ne cherche même pas à savoir ce qu’il y a à l’intérieur, j’en fais juste l’acquisition ! Celui-ci, colle à l’accoutumée (ou presque) et ne m’a pas déçu.

McConnell différencie l’art de l’estimation et la science de l’estimation. La « science », ce sont les méthodes d’estimation permettant, à l’aide de formules, d’euristiques et de facteurs d’ajustement d’obtenir des chiffrages de projet ; les approches telles que FPA et Cocomo II se rangent dans cette catégorie. Ce livre traite de l’autre partie : l’art de l’estimation.

La première partie est consacrée aux concepts de l’estimation. Cette partie est particulièrement précieuse pour comprendre et justifier les facteurs d’incertitude, les facteurs influençant les estimations et les sources d’erreur.

La seconde partie constitue le cœur du livre, puisque l’auteur y livre son approche des estimations. Celle-ci est basée sur un simple processus : compter, calculer et juger. Autour de cette approche, Steve McConnell développe plusieurs techniques, telles que l’utilisation de données historiques, le jugement d’experts, l’estimation par analogie ou en groupe.

La dernière partie se focalise sur les challenges particuliers de l’estimation : estimer la taille, évaluer l’effort associé et estimer une planification. Au-delà des estimations elle-mêmes, le problème le plus souvent rencontré est la présentation des résultats et le traitement des problèmes politiques entourant les estimations.

Les estimations sont un problème épineux, peu d’ouvrages traitent ce problème. Ceci fait de ce livre un ouvrage particulièrement précieux sans être inutilement compliqué. C’est pour cela que je conseille ce livre sans réserves aucune.

mcconnell-software-est

Référence complète : Software Estimation, Demystifying the Black Art – Steve McConnell – Microsoft press 2006 – ISBN: 0-7356-0535-1

Software Estimation: Demystifying the Black Art


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