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

Note de lecture : Scaling Software Agility, best practices for large entreprises, par Dean Leffingwell

Note : 4 ; Finalement, rien de neuf sous le soleil !

Dean Leffingwell n’est pas un nom inconnu pour moi. Autrefois consultant chez Rational, il est l’auteur d’un livre sur la gestion des exigences plutôt de très bonne facture et en tout cas fort bien écrit. L’autre facette de ce « passif » est que Dean Leffingwell semble plutôt être un opportuniste de l’agilité et qu’il vient de la vieille école ! Mais ne concluons pas trop vite.

Le sujet abordé nous change un peu : comment, avec l’agilité passer de la mise en œuvre au sein d’une équipe de moins de 10 personnes à l’usage au sein d’une organisation ? Le sujet a déjà été effleuré, mais sans que des principes vraiment convaincants soient révélés. Pour aborder cela, l’ouvrage de Leffingwell est divisé en 3 parties.

La première partie est consacrée à une vue générale de l’agilité. Ses 95 pages sont divisées en 8 chapitres. Cette introduction est surtout destinée aux lecteurs ayant éventuellement un verni de connaissance de l’agilité, mais pas une véritable connaissance des principes et des méthodes. Autant le dire, cette première partie est fort bien faite. Les principes sont clairement énoncés et expliqués, les principales méthodes qui sont passées en revues le sont de manière claire et synthétique. Le tout est exemplaire. Mais on n’a pas encore abordé la face « scaling ».

La seconde partie évoque les pratiques connues des méthodes agiles, dont l’auteur va nous montrer qu’elles fonctionnent au changement d’échelle. 7 pratiques sont présentées ici, couvrant 90 pages découpées en 7 chapitres (1 chapitre par pratique, ça coule sous le sens). Il s’agit de :

  • Component team : Il s’agit du « feature team » que l’on rencontre ailleurs, notamment dans Scrum. Rien de nouveau ici. On n’en sait guère plus sur le passage à une échelle supérieure. L’auteur se contente souvent de citer d’autres textes.
  • Two levels of planning and tracking : Ce chapitre est emprunté d’une collaboration avec Rallye Software (mais eux parlent de 4 niveaux de planification, ce que j’approuve). Globalement on y retrouve de manière moins approfondie la matière développée par Mike Cohn dans « Agile Estimating and planning ».
  • Mastering the iteration : Ce chapitre évoque la gestion d’une itération. Un sujet mille fois abordé. J’aurais espéré ici un développement sur la gestion concurrente des itérations entre plusieurs équipes. Rien de cela ici. Ici encore, Mike Cohn vous en dira plus long.
  • Smaller, more frequent releases : Là aussi, il s’agit d’un sujet qui n’a plus rien de neuf. Le volet « multi-teams » est traité en fin de chapitre sur une demi-page. J’arrête là.
  • Concurrent testing : Le chapitre est court, c’est dommage car il commençait bien. Il y aurait fort à dire sur la gestion des tests au sein de larges organisations.
  • Continuous integration : L’intégration continue au sein d’organisations réparties est un sujet à part entière, où plusieurs stratégies de mise en œuvre sont possibles. Il est dommage que l’auteur se cantonne à l’aspect « équipe unique » maintenant bien connu, qui n’a pas de plus value ici.
  • Regular reflexion and adaptation : Si les rétrospectives sont un mécanisme inhérent à l’agilité, pourquoi limiter le volet traité ici à l’aspect « métrique » ? On voit le coté « vieille école » de Dean Leffingwell pointer le bout de son nez. Un aspect de l’agilité mal compris.

La troisième partie, « creating the agile entreprise » est le cœur de l’aspect « changement d’échelle » du livre. C’est aussi la plus importante avec ses 130 pages séparés en 7 chapitres. Les 7 « pratiques complémentaires qui y sont abordées sont :

  • Intentional architecture.
  • Lean requirements at scale.
  • System of systems and the agile release train.
  • Managing highly distributed teams.
  • Impact on customers and operations.
  • Changing the organization.
  • Measuring the business performance.

Si l’auteur est dans le vrai sur les sujets abordés, le traitement de ceux-ci est quand même décevant. En effet, la solution proposée ici est bel est bien de réduire la voilure de l’agilité et de remettre un peu plus de principes « top down ». On notera aussi au passage l’aspect gestion des exigences, largement inspiré des écrits précédents de l’auteur. Ce n’est d’ailleurs pas le plus mauvais chapitre.

En bref, j’ai été frustré par ce livre. J’ai de plus largement l’impression qu’il est le fruit d’une unique expérience chez BMC, ce qui est un peu léger pour justifier un livre. Je déconseille donc cette lecture.

scaling-soft-agility-Leffingwell

Référence complète : Scaling Software Agility, best practices for large entreprises – Dean Leffingwell – Addison Wesley / ASD series 2007 – ISBN : 0-321-45819-2 ; EAN : 978 0 321 45819 3

Scaling Software Agility: Best Practices for Large Enterprises


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

Note de lecture : DSDM, Business focused development, 2nd edition, par Jennifer Stapleton edt.

Note : 5 ; L’agilité, vue par nos voisins anglais.

Tout comme le « XP explained » de Kent Beck, cet ouvrage peut être vu comme l’argumentaire de DSDM que comme la synthèse de la méthode qui est plutôt montrée en filigrane ! N’hésitons pas à le dire, cela nuit beaucoup à la qualité de l’ouvrage (sans préjuger de la qualité de la méthode). Je pense que la raison principale de ce choix est de ne pas empiéter sur les documents du consortium DSDM réservés aux adhérents. Ce genre de choix est toujours délicat, mais un peu malheureux ici, en l’occurrence. Au niveau de la qualité du texte, on remarquera que pour un ouvrage collectif, celui-ci est agréable à lire, il n’est pas trop long, comme c’est souvent le cas dans ce genre de situation, les chapitre sont courts et l’on ne perçoit ni redondance ni différence de style, hormis dans la partie dédiée aux retours d’expérience.

Car l’une des originalités intéressantes de ce livre est de consacrer une moitié de l’ouvrage à des retours d’expérience, judicieusement choisis afin d’éclairer des aspects particuliers de la méthode. Une bonne idée qui devrait être plus souvent reprise.

Si vous vous intéressez à DSDM, ce livre est tout simplement incontournable, car c’est le seul qui existe. Il ne saurait suffire toutefois, et c’est bien dommage, à la compréhension de la méthode. Il faudra pour cela aller surfer sur le site Web ci-dessous, ce qui était probablement un des buts inavoués. Mais cela est franchement un peu pusillanime.

DSDM

Référence complète : DSDM, Business focused development, 2nd edition – The DSDM consortium, Jennifer Stapleton edt. – Addison Wesley / ASD series 2003 – ISBN: 0-321-11224-5

DSDM: Business Focused Development


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

Note de lecture : More about Requirements, par Karl E. Wiegers

Note : 7 ; Karl Wiegers n’a pas tout dit !

Comme son nom l’indique, ce petit opuscule (185 pages) est un complément au classique « Software Requirements » du même auteur, et plus précisément à la seconde édition de cet ouvrage. Plus que d’être un livre par lui-même, ce texte fait un peu l’effet d’être un complément d’information. Aussi je déconseille fortement de plonger dans cette lecture si vous n’avez pris d’abord le temps d’étudier le premier ouvrage. Si vous l’avez fait et l’avez apprécié (ce qui est mon cas), cette lecture poursuit le plaisir.

Le format du livre est réellement inhabituel, il rappelle celui, un peu déconcertant, de Kent Beck : l’ouvrage compte 23 chapitres répartis en 7 parties. Pour un livre de 185 pages. Faites le calcul, la moyenne de chacun d’entre-eux se situe aux alentours de 8 pages ! En fait, je trouve cela fort agréable, car on a le sentiment que chaque chapitre a un objectif « tactique » et que celui-ci doit être atteint le plus efficacement possible. Et cela rythme bien la lecture. Par contre, on a aussi l’impression que chaque chapitre est traité assez superficiellement. En fait les renvois vers le livre principal sont assez nombreux, on est parfois aux limites de la FAQ.

La première partie est consacrée aux concepts : ce qui est vrai ou faux concernant la gestion des exigences et aussi la « big picture » des types d’exigences vue par Karl Wiegers, que j’aime particulièrement.

La seconde partie se focalise sur la partie management des exigences : comment peser le retour sur investissement ? Comment en estimer l’effort ? Comment planifier ce travail et le répartir tout au long du projet ?

L’interaction avec les utilisateurs est abordée dans la troisième partie. Ici c’est l’élément humain qui est décortiqué, et l’on s’intéresse à la meilleure façon de collaborer avec un utilisateur.

La quatrième partie est dédiée aux cas d’utilisation : que sont-ils, quels sont les concepts importants et quand est-il utile de compléter ce formalisme par un autre ou tout simplement de l’abandonner au profit d’un autre !

La rédaction des exigences est un problème crucial, car elle détermine la qualité et l’utilisabilité effective du produit final. La cinquième partie est dédiée à ce sujet.

Karl Wiegers reste un homme de processus, et la sixième partie recadre la gestion des exigences dans un processus projet : définition de la portée du projet, gestion du changement, etc..

Enfin la dernière partie aborde le volet « gestion » : de quels indicateurs peut-on avoir besoin ? Comment gérer les exigences à travers plusieurs releases d’un projet ou comment aborder le choix d’un outil de gestion des exigences.

Cet ouvrage n’est certainement pas un ouvrage de référence, comme peut l’être le « Sotware Requirements, 2nd edition », mais c’est une bonne lecture complémentaire. Le propos de Karl Wiegers fait souvent mouche et apporte grandement au sujet. Je vous engage donc à poursuivre la lecture du premier ouvrage cité par celui-ci !

more-about-requirements

Référence complète : More about Requirements – Karl E. Wiegers – Microsoft press 2006 – ISBN: 0-7356-2267- 1

More About Software Requirements: Thorny Issues and Practical Advice: Thorny Issues and Practical Advice

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

Note de lecture : Scaling Lean & Agile Development, par Craig Larman & Bas Vodde

Note : 9 ; Enfin un ouvrage sur le Lean développement qui renouvelle les idées ! Book of the year 2010 !

Le problème des ouvrages sur le Lean développement, c’est qu’ils ne savent guère que tourner en rond, exposer et (dans le meilleur des cas) développer les idées sous-jacentes aux principes Lean. Bien que le Lean soit à la mode, chaque lecture d’ouvrage sur ce domaine tend à se transformer en ennui annoncé.

J’ai donc une excellente nouvelle pour vous : ici, il n’en est rien ! Cet ouvrage de 330 pages est complété d’un « companion book » plus imposant, écrit par les deux mêmes auteurs. Mais nous allons nous concentrer sur celui-ci pour l’instant. Si l’ouvrage est écrit par deux auteurs, l’un des deux au moins, ne m’est pas inconnu : Craig Larman est « chief scientist » de mon employeur précédent, mais aussi un auteur émérite. Bref, il sait écrire, et je n’ai jamais été déçu par ses textes jusqu’à présent. Et disons que la série se poursuit.

Avant d’attaquer le contenu, je vous livre une de mes petites manies permettant d’avoir des indices sur la qualité du livre, avant et après lecture. Avant de commencer la lecture, je regarde les 1ère et 4ème de couverture. Une proportion importante des meilleurs ouvrages y propose des schémas ou des tableaux récapitulatifs du livre, ou même des aides mémoire. On a ça ! Après lecture, je compte le nombre de post It que j’ai placé sur le livre : ici j’en ai posé 22, c’est très très bon.

Après la forme, le fond. Le livre se découpe en 3 parties constituées de 12 chapitres, ce qui fait donc une moyenne de moins de 30 pages par chapitre. Ca va.

Autant nous occuper tout de suite de la 3ème partie, « miscellany » essentiellement constituée du dernier chapitre « Scrum Primer », qui n’est en fait pas écrite par les auteurs, mais par des auteurs du site http://www.scrumprimer.com ; Pour distinguer ce texte de celui des auteurs, le corps de la police utilisée est différent, plus petit. Il s’agit d’un bon « Scrum primer » qui présente l’avantage d’être assez direct et succinct et de bien recadrer ce qui fait partie du corpus de la méthode et ce qui n’en fait pas partie mais est généralement utilisé ! En plus de ce chapitre, on trouve les annexes habituelles (index et bibliographie), accompagné d’un « recommanded readings » assez sympa.

La première partie est consacrée aux « thinking Tools ». Il est long de 140 pages découpées en 5 chapitres (je n’ai pas compté le chapitre d’introduction, qui précède cette première partie). Le chapitre 2 (system thinking) est essentiellement un tutorial aux « causal loop diagram », même si les « fishbone diagrams » sont aussi évoqués. Le diagramme de boucles causales sera d’ailleurs utilisé ultérieurement dans le livre. Très réussi. On poursuit au chapitre 3 (Lean thinking) où l’on présente « Lean thinking house ». Les principes sont déclinés en pratiques. Les pratiques sont développés et illustrées. Impeccable là aussi. La théorie des queues est un volet important du Lean thinking. Le chapitre 4 qui lui est consacré est assez ardu à suivre. Mais on coupe court aux idées fausses de manière abrupte et l’on en a pour son argent ! Le chapitre 5 (false dichotomies) est sans doute l’un des plus abstraits par sa nature. Il s’agit là aussi de couper court aux idées fausses et de réfuter certaines idées prétendument opposées. Enfin le chapitre 6 (be agile) termine cette première partie en promouvant l’idée « d’être agile », donc de s’adosser aux valeurs, plutôt que de « faire de l’agilité » et donc de ne voir que les pratiques.

La seconde partie est dédiée aux « organizationnal Tools ». De taille égale à la premier (5 chapitres pour 150 pages), il focalise chaque chapitre sur une pratique Scrum inspirée de Lean, et adaptée aux projets de grande taille. Le chapitre 7 (feature team) met en exergue l’idée d’équipes pluridisciplinaires, par opposition aux organisations orientées composant. Le chapitre 8 (teams) est la poursuite de cette idée, avec une emphase sur le caractère auto organisée des équipes et sur la gestion des dépendances externes. Le chapitre 9 (requirements area) introduit une idée nouvelle sur la gestion de très gros backlogs. Dommage que ce chapitre de seulement 9 pages n’ait pas été plus développé ! Le chapitre 10 évoque l’extension de l’organisation agile au niveau de l’organisation de l’entreprise. J’y ai surtout aimé la distinction projet / produit, souvent incomprise et source de problème, tandis que les aspects ressources humaines sont du déjà vu et hélas une appréhension bien trop idéaliste du sujet. Enfin le chapitre 11 (large scale Scrum) évoque une partie du sous-titre de l’ouvrage et dit en substance que l’adaptation de Scrum aux grands projets … n’existe pas en tant que tel !

Finalement, j’ai retardé la lecture de cet ouvrage ne me sentant pas tellement concerné par le « large scale Scrum ». C’était une erreur, car en fait pu de choses dans ce livre sont vraiment dédiées spécifiquement aux grandes équipes. Au contraire, la littérature agile qui me semble rabâcher les mêmes propos depuis quelques années retrouve un peu de fraicheur ici. J’ai hâte de lire la suite, et bien sûr je recommande chaudement, sans aucune réserve !

scaling-lean-agile-dev-Larman

Référence complète : Scaling Lean & Agile Development, Thinking and organizational Tools for large-scale Scrum – Craig Larman & Bas Vodde – Addison Wesley 2009 – ISBN : 978 0 321 48096 5

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum

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