Mois : avril 2025

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 » →