Auteur : addinquy

Software Freethinker

Note de lecture : Inspired 2nd edt, par Marty Cagan

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 9 ; La référence sur le product management !

Si tous les chemins mènent à Rome, toutes les références à la démarche produit remontent à Marty Cagan, et plus précisément à son ouvrage vedette : Inspired. Non seulement l’auteur a construit une démarche produit tôt dans sa carrière dont se sont inspiré de très nombreux « purs players », mais il a accumulé une solide expérience et un regard très large sur les entreprises tech. Il nous livre ici sa vision sans retenue.

Avec plus de 300 pages, le texte peut paraitre conséquent, mais en réalité il s’aborde très bien. Avec 67 chapitres, chacun de quelques pages, le rythme de lecture est assez particulier, qui me rappelle un peu Kent Back qui aime bien procéder ainsi également. Mais l’auteur a structuré son propos en 5 parties, sous-découpées en sections pour certaines d’entre-elles, pour un total de 16 sections.

La première partie, « lessons from tech companies » compte 8 chapitres pour un total d’une trentaine de pages. L’auteur nous livre ici son analyse des facteurs de succès des entreprises « orientées produit », une analyse sans concession qui fait un peu mal aux entreprises classiques. Le chapitre 7, « beyond Lean and Agile » fait un peu mal, car si l’auteur est bien pro-agile, il tacle la manière dont cette agilité est mise en œuvre dans la plupart des entreprises, et je ne saurais lui donner tort. Les entreprises produit incarnent, nous dit-il, l’essence de l’agilité mais d’une manière peu reconnaissable par l’agilité corporate. D’accord, il ne le dit pas comme cela, mais c’est l’idée. Le chapitre 8 nous introduuit le « discover to deliver » qui sera un leitmotive pour la suite, et qui là encore est un marqueur différenciant de l’agilité classique.

Continuer à lire « Note de lecture : Inspired 2nd edt, par Marty Cagan » →

Note de lecture : Beyond Requirements, par Kent J. McDonald

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Spécifier, avec un vrai mindset agile

De prime abord, le titre fait penser au mariage du veau et du cochon. Mais très vite, on comprends qu’il n’en est rien, bien au contraire. Car ce volume va au-delà de la compilation de pratiques d’analyse agile, nous allons voir cela.

L’ouvrage est de taille moyenne avec ses 230 pages structurées en 3 parties pour un total de 15 chapitres. La première partie « Ideas » est forte de 75 pages sur 6 chapitres. Ici, on parle surtout de culture agile, certes centrée sur l’analyse mais sans entrer en profondeur dans les pratiques. Dans le premier chapitre « guiding principles », Kent McDonald nous distille ce qu’il a condensé en 7 principes directeurs sur lesquels s’appuient ses manières de raisonner et de prendre des décisions. Par la manière dont ces principes sont pensés et exposés, nous voyons rapidement que l’auteur est un agiliste de très haut niveau. Peut-être est-ce la 15ème fois que l’on vous assène des principes fondateurs ? Ne manquez pas ceux-cis. Au second chapitre, on entre plus spécifiquement dans le domaine de l’analyse. Et ce sont les concepts structurant de l’analyse agile qui sont développés ici. La référence au BABOK (Business Analysis Body of Knowledge) est certes austère, mais les 6 concepts évoqués ici serviront de cadre au reste de l’ouvrage. Il aborde aussi 2 piliers importants de l’approche produit moderne : outcome versus output et la dualité discovery / delivery.

Signe de l’influence de l’approche produit dans son cadre de spécification agile, l’auteur rend hommage au Lean Startup au chapitre 3. L’auteur ne se contente pas de paraphraser Eric Ries : il projette les concepts de l’approche au monde de l’entreprise. Un bel exercice. La prise de décision, sujet du chapitre 4 semble être un des thèmes favoris de l’auteur. Au menu de celui-ci, nous avons tout d’abord les mécanismes de la prise de décision elle-même, bien décomposés. Kent McDonald semble apprécier Chris Matts, c’est sans doute pourquoi nous avons un coup de projecteur sur les « real options ». C’est un bon teaser à « Commitment » ! Enfin, c’est un plaisir pour moi de voir que les biais cognitifs qui entachent si grandement les processus de décision ne sont pas oubliés.

Continuer à lire « Note de lecture : Beyond Requirements, par Kent J. McDonald » →

Note de lecture : Pragmatic Unit Testing, in Java with JUnit, par Andrew Hunt & David Thomas

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 6 ; Des conseils simples, avisés et … pragmatiques, pour bien commencer avec les tests unitaires.

Dans la veine des « starter kits » écrits par les « pragmatic programmers », voici un opuscule consacré aux tests unitaires en général et à JUnit en particulier. L’objectif est très clair : mettre le pied à l’étrier de manière pragmatique, sans s’encombrer de beaucoup de théorie. De fait le livre est court, avec 125 pages (hors annexes), mais quand même découpé en 9 chapitres, chacun étant donc court.
Le premier chapitre est une prose introductive au « pourquoi » des tests. Il s’étend largement sur les contre-arguments à leur écriture, et permet de balayer les objections les plus courantes. Toujours une bonne chose de faite. Au second chapitre, nous pratiquons l’équivalent du très classique « hello world ». C’est minimal et le chapitre est très court. Ce n’est pas le cas du chapitre 3 qui nous accoutume aux autres éléments utilisés classiquement lors de l’écriture de tests unitaires : setup, tear down, test suite et assertions en tout genre. Nous sommes armés pour écrire des tests plutôt standard mais qui répondent aux besoins courants.

A partir du chapitre 4, il est davantage question d’écrire de bons tests et une bonne couverture de test. Les auteurs proposent l’acronyme Right-BICEP. Tout d’abord il s’agit de définir ce qu’est un résultat juste, puis d’appliquer les règles du BICEP (que je ne vais pas développer ici). Toutefois le « B » pour boundary va être l’objet plus spécifiquement du chapitre 5 où il va être développé selon un autre acronyme, le CORRECT. Les conditions aux limites sont souvent source d’erreur, les auteurs font un bon travail à bien cerner l’ennemi. Le chapitre 6 est consacré aux Mock objects. Ce chapitre est juste une introduction au sujet, utilisant EasyMock, mais elle est consistante. Elle marque aussi la temporalité du livre, car l’exemple choisi est le mock d’une servlet !

Le chapitre 7 va aborder les propriétés d’un bon test et c’est l’occasion d’un nouvel acronyme : A-TRIP. Car si un test doit être Automatique, il doit aussi complet (Thorough) en testant ce qui peut casser, Répétable en remettant le système en conditions initiales en fin d’exécution, Indépendant en ne supposant pas de séquence d’exécution et enfin Professionnel ! Cette dernière propriété est énoncée de manière bien curieuse. Les auteurs veulent simplement dire que le code du test doit respecter les mêmes qualités de conception et d’implémentation que le code de production. Il n’y a guère de code au chapitre 8. Celui-ci est consacré à l’organisation du code de test et au cycle de développement. Rien que de très classique ici, puisque l’on organise le code façon Maven et que l’on préconise le test en continu sans toutefois aborder le TDD. Le livre se referme sur un chapitre 9 consacré à la conception, plus précisément aux implications du test unitaire sur la conception, ce que les auteurs appellent le « test-driven design ».

Continuer à lire « Note de lecture : Pragmatic Unit Testing, in Java with JUnit, par Andrew Hunt & David Thomas » →

Note de lecture : The Incremental Commitment Spiral Model, par Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong & Richard Turner

Le par addinquydans Notes de lectureLaisser un commentaire

Note 3 : Se retrouver à lire un livre que l’on n’a pas envie de lire…

Et ainsi donc, le développement itératif et incrémental est désormais acquis au développement agile ! Tout le développement itératif et incrémental ? Non ! Un village résiste encore et toujours : il s’appelle « spirale de Boehm ». Cet ouvrage est peut-être son chant du cygne, l’avenir nous le dira.

L’ouvrage que nous allons explorer nous présente l’ultime version du modèle en spirale. Il compte environ 250 pages découpés en 16 chapitres, eux-mêmes structurées en 4 parties. Si ces caractéristiques laissent présager une lecture pas trop longue et bien rythmée, c’est sans compter sur l’austérité de la prose ! Il est temps de s’y attaquer. L’introduction permet aux auteurs de positionner le « incremental commitment spiral model » que nous nommerons maintenant ICSM sur le même créneau des méthodes adaptatives que les approches agiles qui sont d’ailleurs citées. Elle ne cherche pas à s’y opposer, mais à se positionner différemment en s’appuyant sur 4 principes sur lesquels nous reviendront. Le but est de se tailler une place dans les environnements plus classiques et « legacy » qui sont quand même prêts à accueillir un cycle itératif. En prime, ce chapitre 0 nous propose une belle vue actualisée du cycle en spirale : l’ouvrage aura ainsi au moins une valeur archéologique !

La première partie compte 4 chapitres sur 80 pages. Ils vont détailler les 4 principes de l’ICSM que nous avons mentionné. Le premier chapitre aborde la question de la valeur pour les parties prenantes. Il s’appuie sur les leçons tirées de 2 histoires, notamment de la conception d’un équipement hospitalier. Ce principe est adossé au « success critical stakeholder » ou SCS. Ce principe est un mélange de modernité (la mesure du succès est le succès du SCS) et de choses plus anciennes avec une approche en phases qui rappelle étrangement Unified Process ! On n’échappe d’ailleurs pas à une matrice critères de succès / parties prenantes ! Au second chapitre, on aborde la notion d’engagement incrémental : c’est le cône d’incertitude qui est mis à l’honneur ici. Cette fois encore le propos est illustré de deux histoires, un succès et un échec, le succès étant le projet TRW débuté en 1978 qui fut à l’origine du cycle en spirale ! Le chapitre fait apparaitre l’approche comme très technocratique et la prose est plutôt lourde. Le volet intéressant de ce chapitre est la comparaison de modèles incrémentaux allant du « prespecified » au « evolutionary concurrent ».

Le 3ème principe que nous découvrons au chapitre 3 est le « concurrent multidiscipline engineering ». Nous avons aussi droit à deux histoires, celle illustrant le succès étant le développement d’un drone. Le propos est alambiqué et assez lourd. Il s’éclaire vers la fin du chapitre quand l’auteur nous déclare que l’utilisateur peut rarement spécifier clairement ce qu’il veut au début du projet et qu’il nous faut donc mener de front l’affinage des besoins, la conception et le développement. Il s’agit bien du fonctionnement multidisciplinaire que nous connaissons en agile. Il est simplement exprimé de manière obscure ici. Le dernier principe est celui des décisions basées sur les risques, le sujet du chapitre 4. Le propos se concentre sur la valeur apportée par les études de faisabilité. L’auteur met aussi en perspective l’approche de Walker Royce intégrée à Unified Process comme étant un progrès par rapport au cycle en spiral initial ! Globalement la coloration « pré-agile » y est assez évidente.

Continuer à lire « Note de lecture : The Incremental Commitment Spiral Model, par Barry Boehm, Jo Ann Lane, Supannika Koolmanojwong & Richard Turner » →

Note de lecture : Application Security Program Handbook, par Derek Fisher

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Pour nous guider dans la mise en place de la cybersécurité.

Il faut commencer par ouvrir ce livre pour en comprendre le titre. Il s’agit bien de sécuriser les applications, mais plutôt sous l’angle de la gouvernance et de la mise en place de cette sécurisation. Dit ainsi, cela n’a rien d’attrayant et le texte aurait pu être terriblement rébarbatif. Il n’en est rien, et nous allons voir pourquoi.

L’ouvrage est parfaitement rythmé : il compte 260 structuré en 3 parties, chacune d’entre elle comptant 3 chapitres. La première partie sert à camper le décor, elle sert à nous permettre d’appréhender ce qu’est la sécurisation d’une application. Le chapitre 1 réponds au « pourquoi » de la sécurisation, mais en réalité va bien plus loin. Tout d’abord en introduisant le fameux « security program » qui est la raison d’être du livre, mais surtout en introduisant le securisation pipeline qui est l’apport majeur du texte et défend une approche « shift left » qui parlera bien aux agilistes.

Le second chapitre « understanding the problem” adresse deux sujets majeurs, le premier sera mon préféré, j’ai parlé de la triade CIA : confidentialité, intégrité, disponibilité (availability). L’auteur rentre en profondeur sur chacun de ces thèmes, détaillant la manière de les adresser. Un excellent boulot. Le second thème traite des risques : si j’ai aimé la classification et la présentation des types d’attaquants, la gestion des risques elle-même, s’appuyant sur le NIST, est plus austère. Le dernier chapitre de cette première partie est consacré aux composants de la sécurisation des applications. Tout d’abord on y trouve une excellente introduction à la modélisation des menaces, puis un panorama des outils d’analyse et enfin une évocation des différents types de test. Bref, ce chapitre est une petite mine d’or !

Continuer à lire « Note de lecture : Application Security Program Handbook, par Derek Fisher » →

Note de lecture : Effective Software Testing, par Mauricio Aniche

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Une stratégie de tests gravitant hélas uniquement autour des tests unitaires, mais faisant un excellent travail pour en systématiser l’approche.

En matière d’ingénierie logicielle moderne, la littérature sur les tests tend à se concentrer sur les tests unitaires et les tests d’acceptation. Les ouvrages qui englobent les pratiques de manières plus larges ciblent surtout l’aspect méthodologique. C’est donc avec intérêt que j’aborde ce texte qui se focalisent sur les différents types de tests que l’on peut mettre en œuvre au niveau des équipes de réalisation. Et nous allons le voir, cela ne se limite pas aux deux types de tests que nous venons d’évoquer.

Avec 274 pages hors annexes, cela reste un ouvrage de taille raisonnable. Il est structuré en 10 chapitres. Le premier chapitre annonce la couleur : les développeurs qui testent versus ceux qui ne testent pas. L’idée est ici d’avoir un tour d’horizon des types de tests qui vont être abordés et de l’aspect méthode et automatisation qui, même si on ne parle pas d’agilité, restent dans la même idée. Mon désaccord principal, sur ce chapitre et sur le livre, est d’utiliser la pyramide de tests comme boussole, une idée absolument dysfonctionnelle. Bien sûr, l’auteur met l’accent sur les petits tests qui s’exécutent rapidement (donc les tests unitaires), je ne saurais lui reprocher. Mais les autres tests sont pour lui : les tests d’intégration (quels tests d’intégration ?), les tests système et les tests manuels et c’est tout ! Pas de tests fonctionnels ou au moins de tests d’acceptation. C’est une vue erronée du paysage des tests, mais cela ne veut pas dire que l’ouvrage n’a pas d’intérêt.

En fait le chapitre 2 aborde le « specification-based testing ». Mais pas au sens des tests d’acceptation. Il s’agit ici de mettre en place des tests unitaires pour tester les règles de gestion à bas niveau. L’auteur y propose une démarche très systématique en 7 étapes allant des premiers tests passants aux tests aux limites puis « créatifs » sans oublier l’automatisation ! C’est de fait une approche très disciplinée des tests unitaires, peut-être trop, mais cela reste une très bonne source d’inspiration. Le texte ne s’arrête pas là puisqu’il aborde le traitement des bugs. Le propos est largement adossé à de très nombreux exemples en Java. Mais à mon avis l’illustration a travers de règles de validation sur une chaine de caractère n’est pas assez significatif d’un véritable projet.

Continuer à lire « Note de lecture : Effective Software Testing, par Mauricio Aniche » →

Note de lecture : Grokking Continuous Delivery, par Christie Wilsonci

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Pour s’initier sérieusement au continuous delivery

Cette série « grokking », c’est un peu le « pour les nuls » de Manning. Et tout comme cette série, ce n’est pas nul du tout. L’ouvrage rentre en profondeur dans le sujet, avec simplicité et pragmatisme, mais certainement pas avec simplisme. Comme nous le verrons, il s’avère même étonnant, en plus d’être abondamment illustré. Cela nous explique les 360 pages de cet ouvrage (hors annexes). Aussi, si la lecture est aisée, elle demande quand même un certain temps !

Le livre, justement, parlons-en. Il est structuré en 4 parties pour un total de 13 chapitres. La première d’entre-elles est une introduction sur 2 chapitres et un peu plus de 30 pages. Comme on peut s’y attendre, le premier chapitre est purement introductif, définissant le concept et ses concepts adjacents et lui donnant une perspective historique. C’est en fait une bonne idée, tellement il peut y avoir de subtilité entre les concepts et le texte ne fait pas l’impasse dessus. Il est précis et concret. C’est un bon chapitre. Le second chapitre s’inscrit en parfaite continuité pour décrire un pipeline de base en s’appuyant sur un cas d’étude, en l’occurrence des photos de chat. L’auteur nous prends par la main pour construire progressivement ce qui est un pipeline CI, finalement loin d’être basique. Tout ce fait progressivement en expliquant les concepts tels que guichet et transformation, progressivement. Seules les notifications par Webhook sont un peu spécifiques dans le paysage.

La partie 2 couvre les mises en œuvre nécessaires pour conserver un logiciel dans un état délivrable tout le temps. Elle pèse 5 chapitres sur 140 pages. Le chapitre 3 adresse la gestion de version et la startup de Sacha et Sarah va nous aider à y voir plus clair. Le texte fait le choix d’utiliser Github comme exemple. Il en fallait bien un, et il parait raisonnable. Cela permet de se familiariser avec les concepts de push et pull request. Le texte ne s’arrête pas là, il fait la transition avec le pipeline, et pourquoi pas dans le cloud ? Il adresse aussi la gestion de configuration en gestion de version en imaginant la connexion à une base de données également dans le cloud. Les auteurs vont plus loin que la gestion de version sensu-stricto. C’est un choix de l’auteure que nous retrouverons régulièrement.

Continuer à lire « Note de lecture : Grokking Continuous Delivery, par Christie Wilsonci » →

Note de lecture : Exploring Requirements: Quality before design, par Donald C. Gause & Gerald M. Weinberg

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 7 ; Pour capturer et écrire plus efficacement des exigences.

Le moins que l’on puisse dire est que ce livre ne date pas d’hier ! Il attire toutefois l’attention par au moins deux aspects : le premier est la cosignature de Gerald Weinberg. Le second se situe dans le titre car il y est question non pas de gérer, de collecter ou de capturer des exigences, mais de les explorer. C’est sans doute pour cela qu’il va être moins questions de processus que de pratiques centrées sur l’humain et l’aspect psychologique de cette exploration. Par certains côtés, on y côtoie l’agilité avant l’heure !

L’ouvrage en lui-même n’est pas anodin : il totalise près de 300 pages structurés en 25 chapitres, eux-mêmes regroupés en 5 parties. Toutefois l’ensemble se lit bien. La première partie compte un peu moins de 50 pages pour 4 chapitres et son thème attire tout de suite l’attention, car il y est question de négocier une compréhension commune ! Le premier chapitre prend le contrepied des méthodologies, mais en fait c’est des notations qu’il s’agit. Et les auteurs, à l’aide d’exemples très simples mettent en évidence à la fois la difficulté sous-estimée de compréhension des notations et introduisent la notion d’ambiguïté des exigences, qui sera particulièrement le sujet du second chapitre. Ce second chapitre est plutôt court et va se limiter à définir cette notion d’ambiguïté dans le domaine du recueil des besoins, et ses conséquences. Mais ce thème reviendra au long de l’ouvrage.

D’ambiguïtés, il est toujours question au chapitre 3, qui va adresser les sources d’ambiguïté : observation, interprétations dans lesquelles le facteur humain vient s’insérer. Les recherches de Daniel Kahneman n’étaient pas encore popularisées mais elles auraient pu être citées ici. Les auteurs mettent néanmoins en relief ces biais au travers d’exercices pratiqués en séminaire. Pour refermer cette première partie, les auteurs s’attaquent à la pratique des questions directes au travers d’arbres de décision. Sans citer les biais cognitifs, ils mettent en question le postulat sous-jacent : la nécessité de s’adresser à des « êtres humains parfaits ». S’ils ne sont pas opposés à leur emploi, le verdict est que cette pratique ne suffit pas.

Continuer à lire « Note de lecture : Exploring Requirements: Quality before design, par Donald C. Gause & Gerald M. Weinberg » →

Note de lecture : Making Sense of Cybersecurity, par Thomas Kranz

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 8 ; La cybersécurité pour les nuls, mais sans être nulle. Une lecture riche et passionnante à lire.

La cybersécurité, ce n’est pas nécessairement très facile de comprendre ce que c’est. Même une fois cette étape passée, il s’agit d’appréhender ce que cela recouvre et comment cela se décline en termes de mise en œuvre. Le présent ouvrage a pour objectif de s’attaquer à cette tâche pour le moins ardue, et à ma grande surprise il le fait bien, avec un propos accessible sans être débilitant et même avec une pointe d’humour. Bien sûr, comme le texte est émaillé d’anecdotes issues de l’expérience de l’auteur tout cela devient bien plus vivant.

Le livre lui-même est de taille moyenne, avec ses 256 pages. Il est structuré en 12 chapitres, dont 2 d’introduction suivi de 2 parties. Le premier chapitre « cybersécurity and hackers » commence en douceur pour nous faire prendre conscience des enjeux de la cybersécurité. En commençant par l’histoire du château de Warwick, il nous entraine vers les défis de la défense du système d’information. Le style de l’auteur coule tout seul et préfigure le reste de l’ouvrage. Le second chapitre nous assène dans le titre que la cybersécurité est le problème de tout le monde. L’auteur nous y présente son mantra qu’il répètera au fil des chapitres : la mise en œuvre des mesures doit être adaptée, proportionnelle à la menace et soutenable dans le temps. Elle se met en œuvre au travers de 3 questions simples : Quels assets possédez-vous ? Qui peut vouloir vous attaquer ? Quelles défenses mettez-vous en œuvre ? Au travers de ce discours épuré, l’auteur nous montre une autre de ces qualités, celle de présenter un discours clair, simple et pertinent.

La première partie, même si elle n’a pas de titre, est consacrée aux attaques. Elle comporte 5 chapitres sur 125 pages. Elle s’ouvra sur un chapitre 3 sobrement intitulé « comprendre les hackers ». L’auteur a choisi la classification white hat, grey hat et black hat. Son but est de nous faire comprendre l’état d’esprit des hackers. Il le fait en nous dressant de courtes biographies et quelques exemples. Avec la concision qui le caractérise, il résume la démarche du hacker : comment est-ce que cela fonctionne ? Comment je peux le casser ? Qu’est-ce que je peux lui faire faire d’autre ? Qu’est-ce que cela signifie comme possibilités pour moi ? Le chapitre 4 est consacré aux attaques externes. Il s’ouvre sur la boucle OODA (observe, orient, decide, act) et sa déclinaison en 4 questions que nous avons vu précédemment. Mais tout cela va mieux en le faisant. Ainsi l’auteur décline la manière d’opérer d’abord sur une infrastructure domestique, puis sur une architecture d’entreprise. Le chapitre ne serait pas complet sans un panorama des différentes attaques, que ce soient des classiques de l’OWASP, du mobile, du Wifi, etc. A chaque fois cela est expliqué avec clarté et une dose de légèreté qui nous ferait presque oublier que nous apprenons des choses au fil des pages.

Continuer à lire « Note de lecture : Making Sense of Cybersecurity, par Thomas Kranz » →

Note de lecture : Requirements by Collaboration, par Ellen Gottesdiener

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 4 ; Malheureusement bien pauvre sur la substance même de cette collaboration !

J’ai été attiré par ce titre, aussi bien par le thème aussi original qu’important dans les pratiques d’identification du besoin, que par des recommandations tierces. La littérature adressant la manière de collecter, structurer et formaliser les exigences est très importante. Nombre de ces ouvrages sont d’ailleurs excellents ! Mais les textes traitant des interactions entre personnes pour les faire émerger est beaucoup plus réduite. Le présent ouvrage est peut-être le seul entièrement dédié à ce sujet ! Le texte n’est pas récent, il date du début des années 2000 alors que l’agilité en était à ses débuts. Aussi n’y trouverons-nous aucune référence à ce mouvement, même si de nombreuses idées sont convergentes.

Le livre lui-même comprends près de 280 pages. Il est structuré en 3 parties pour un total de 12 chapitres. La première partie nous promet un tour d’horizon des ateliers de définition des exigences, sur 3 chapitres pour environ 65 pages. Elle s’ouvre sur un très classique « getting started », en guise de premier chapitre. Il a pour but de cadrer la suite du sujet, tout d’abord en définissant les différents types et niveaux d’exigences. Ensuite en clarifiant la notion d’ateliers, ceux abordés ici s’inspirent du Join Application Design (JAD) qui nous conduisent à considérer différents types d’ateliers en fonction de leurs finalités. Le chapitre fait bien le travail, on y voit bien plus clair en l’ayant terminé.

Au chapitre 2, nous allons rentrer plus en profondeur sur ce que nous cherchons obtenir des ateliers, donc les artéfacts. Pour ceux qui ne sont pas familiers de la littérature sur la gestion des exigences, ce sera sans doute une découverte de voir le nombre et la variété de ces artéfacts. Bien que l’on ne rentre pas encore dans le cœur du sujet, le propos est intéressant et bien construit. Cette première partie se clôt sur l’aspect préparatoire des ateliers : l’espace, les invitations, l’état d’esprit avec lequel il faut venir. C’est un peu verbeux et enfonce parfois les portes, mais cela reste bien fait.

Continuer à lire « Note de lecture : Requirements by Collaboration, par Ellen Gottesdiener » →