Note de lecture : Ingénierie des systèmes d’information avec Merise, par D. Nanci, B. Espinasse, B. Cohen & H. Heckenroth

Note : 4 ; Merise pour l’urbanisation du SI plus que pour les projets, même si Merise n’est pas votre business…

Voici une référence biblio avec laquelle je vais me faire “casser” allègrement. Ce n’est pas grave, j’en prends le risque. Amis fondus de l’objet, n’oubliez pas qu’il y a une vie au delà de l’objet. Plus concrètement, on est souvent amené à se connecter à des bases de données relationnelles, donc le plus souvent documentées à l’aide de Merise. Je vous recommande donc de posséder un verni culturel sur ce sujet. Cette référence est là pour couvrir ce besoin. Et on ne fait pas particulièrement dans la légèreté, avec un texte de 650 pages, subdivisé en 6 parties pour un total de 28 chapitres ! La moyenne par chapitre semble donc raisonnable. Passons cela en revue, partie par partie.

La première partie ne fait que 65 pages et s’intitule pompeusement « principes généraux et fondements théoriques de la méthode ». Elle compte 4 chapitres. Après un bref rappel historique, les auteurs replacent Merise dans ce qu’ils appellent la science des systèmes en structurant l’informatique d’entreprise en 3 sous-systèmes : opérant, système d’information et de pilotage. Vient ensuite une vue générale de la méthode et des fameux différents modèles : MCD, MCT, MOD, MOT, MLD, MLT, MPD et MPT (ouf !). Cette première partie se conclut sur la gestion des différents niveaux d’organisation du SI. Le tout est bien illustré, bien qu’avec des représentations un peu complexes et un style plutôt ampoulé, voir un peu prétentieux.

La seconde partie traite de la conception du système d’information organisationnel ( !).  Ce sont 145 pages et 6 chapitres qui couvrent ce sujet. Cette partie aborde la méthode Merise dans l’ordre logique d’utilisation. D’abord le modélisation de l’organisation en domaines et en flux, puis le modèle conceptuel des traitements (MCT), qui équivaut, à ce niveau, à un business model. Le modèle conceptuel des données (MCD) est traditionnellement un gros morceau de Merise, c’est pourquoi 60 pages lui sont consacré. Le modèle organisationnelle des traitements (MOT) est traité ensuite, ce qui fait peu de sens, car je l’aurais plutôt vu à la suite de l’organisation des traitements en flux… Le modèle organisationnel des données (MOD) qui est vu ensuite a une finalité qui ne me semble pas claire, j’ai du mal à le distinguer du MCD. Pour les auteurs, cela paraît évident et ils ne font aucun effort pour nous éclairer. Cette partie se clos par la confrontation traitements / données qui était latente sur toute la partie. Les grilles de cohérences proposées sont fort peu convaincantes.

En troisième partie on aborde la « conception du système d’information informatisé ». Drôle de titre. Avec 180 pages sur 4 chapitre, c’est la partie la plus importante de l’ouvrage en terme de volume. Si la partie 2 pouvait être assimilée à la première couche du modèle de Longépé, cette 3ème partie peut l’être sans aucun doute par rapport à la couche 2. On traite le Modèle logique de Traitement de données, pour ensuite s’intéresser au MCD, tout le chapitre 12 est en fait consacré à la modélisation des données suivant les formes normales de Codd. S’en suit un chapitre particulièrement bâclé sur les modèles physique des données et des traitements. On termine par un chapitre sur l’optimisation du modèle de données qui n’est ni convainquant ni cohérent avec le reste de l’ouvrage.

Les 110 pages de la quatrième partie traitent de la démarche Merise et couvrent 8 chapitre. C’est assez troublant car cela signifie que les parties précédentes n’étaient pas spécialement liées à Merise … de quoi être perdu ! Il s’agit en fait de décrire le cycle de vie du système d’information. Il part du sacro-saint schéma directeur, abordé dans la dizaine de pages du chapitre 15 où il n’est pas question de Merise pour aborder ensuite les études préalables (chapitre 16). Cela couvre le rétro-engineering de l’existant et le dimensionnement. Le lien avec Merise est fait, mais il est ténu et peu convainquant. L’étape suivante, l’étude détaillée évoque au chapitre 17 des « extensions du MCD » mais sans rentrer dans le détail. Le chapitre 18 dédié aux études techniques est pire, il est aussi très superficiel, on voit bien que ce n’est pas la tasse de thé des auteurs. Pour rester cohérent, les auteurs se sont sentis obligé de consacrer un chapitre à la production du logiciel (le moment où l’on programme) : il fait une page et demi. La mise en exploitation n’est pas occultée, mais si l’on écarte le fait que Merise n’y intervient pas, on voit bien également que ce n’est pas le domaine des auteurs. Quelques pages sont finalement consacré à la maintenance, ou plus exactement à un processus de gestion des changements.

Trente pages et 3 chapitres, c’est ce qui est dévolu à la cinquième partie qui évoque les moyens à mettre en œuvre avec Merise. C’est un volet très méthodologique, qui évoque en premier lieu les rôles et la structure organisationnelle, puis les activités et la façon dont les responsabilités se ventilent, pour terminer avec les outils et artefacts avec un gros focus sur les fonctions attendues d’un AGL.

La sixième et dernière partie est consacrée à l’étude de cas d’une société X. En fait, il s’agit plutôt de la présentation du domaine fonctionnel de cette société qui est utilisée comme support sur un certain nombre des exemples. Il est très malencontreux d’avoir structuré cela ainsi : il aurait mieux valu mettre cette partie beaucoup plus en amont et utiliser ce cas d’étude tout au long du livre, en tant que fil rouge. Ni l’un ni l’autre n’ont été fait et celui nuit grandement à la qualité pédagogique de l’ouvrage.

Je pensais avoir acquis un livre pour comprendre l’utilisation de Merise dans un projet. Il n’en est rien et cet aspect est en fait peu ou mal appréhendé. C’est un peu de ma faute, car en fait, le titre du livre est clair : il s’agit plutôt d’une démarche d’urbanisation du système d’information avec Merise ! Hélas, en tant que tel, cela n’est pas non plus très convainquant. Il n’en reste pas moins que l maîtrise de l’outil Merise par les auteurs, leur expertise devrais-je dire, est incontestable. La façon plutôt académique dont ils abordent le processus en fait un texte assez peu opérationnel à mon goût. Ce n’est probablement pas ma pire acquisition, d’autant plus que celui-là, je l’ai eu en fin de série, chez Gibert, à 60 balles.

Ingénierie des systèmes d'information avec Merise

Référence complète : Ingénierie des systèmes d’information avec Merise, vers une deuxième génération – D. Nanci, B. Espinasse, B. Cohen & H. Heckenroth – Sybex 1992 – ISBN : 2-7361-0747-7

Ingénierie des systèmes d'information avec Merise


http://www.goodreads.com/book/add_to_books_widget_frame/18301390?atmb_widget%5Bbutton%5D=atmb_widget_1.png

Résultats du sondage : comment traduiriez-vous « The People’s Scrum » ?

Tout d’abord un grand merci à tous ceux qui se sont livrés à l’exercice !
Au total, j’ai eu 24 réponses. On peut dire que c’est peu, mais je ne comptais de toute façon pas sur des centaines de réponses, sans compter que nous sommes au milieu de l’été… De toute façon, ce n’est pas la quantité, mais la qualité qui compte !

Une mention spéciale à Julien Tort qui a d’abord lu une partie du livre avant de faire une proposition !

Voici les résultats bruts

Résultat du sondage

C’est à dessein que je n’avais pas laissé visible les résultats, même temporaires afin de n’influencer personne. Cela a peut-être eu un effet sur l’affluence… tant pis !

J’en tire temporairement 3 conclusions :

  • Une des propositions n’a pas du tout retenu l’attention : “Scrum et le peuple” n’était de toute manière pas une très bonne proposition. La 5ème proposition apparait aussi avec un total de zéro, mais c’est une erreur due à une mauvaise utilisation de polldady de ma part !
  • “Le Scrum du peuple” est largement en tête ! Il faut aussi dire que c’est la traduction la plus littérale. Donc, cela ne veut pas dire que je retiendrais ce résultat, mais je ne peux non plus l’ignorer.
  • Il y a un grand nombre de propositions alternatives, elles représentent presque 60% des réponses.

Justement, ces propositions alternatives, quelles sont-elles ? En voici le détail

  • Scrum: (Quand) le peuple s’en mêle
  • Scrum pour le peuple
  • Gens mêlés
  • Scrum pour tous (c’est la proposition de Julien Tort que j’avais évoqué précédemment)
  • Le Scrum des masses
  • Le Scrum populiste
  • Scrum pour les individus
  • Le peuple du/de Scrum (2 réponses)
  • Le Scrum des gens / Scrum sur le terrain / Démocratisation de Scrum ; ces 3 propositions m’ont été faites par une même personne.
  • Le Scrum pratiqué par les gens
  • Les agilistes
  • Scrum : des gens, un mouvement
  • Le Scrum des gens

Depuis, j’ai même encore eu une idée carrément différente : Notre Scrum. Reste maintenant à choisir. On en reparle donc plus tard !

Note de lecture : Object oriented I/O using C++ iostreams, par Cameron Hughes, Thomas Hamilton & Tracey Hughes

Note : 5 ; Une source d’information sur les Iostreams moins médiocre que le Teale. Vaut le détour (même si le sujet aurait pu être mieux traité) pour la bibliothèque GDI développée à base de streams !

Très déçu par le médiocre « C++ iostreams handbook » et vu la rareté des ouvrages sur le sujet, il ne m’a pas fallu à l’époque beaucoup de temps pour m’intéresser à celui-ci : il ne pouvait qu’être meilleurs ! En fait, il s’est surtout avéré très différent !

On pourrait appeler ce livre “variations sur les iostreams”. Les auteurs abordent le sujet en développant une bibliothèque iostream pour la GDI Windows. Voyons de plus près le contenu.

Le texte principal de l’ouvrage couvre 300 pages. A hauteur de 10 chapitres, cela nous fit une moyenne un peu élevée de 30 pages par chapitre, mais il faut tenir compte de la proportion importante de code. Il ne faut pas non plus oublier les annexes qui ne sont pas anecdotiques, car elles tiennent 70 pages.

Entrée en douceur pour ce premier chapitre qui présente le concept de streams en commençant par exposer son équivalent avec la bibliothèque C. Bien sur les iostreams sont comparées (aventageusement) par rapport à cette approche et on termine sur quelques perspectives qui annoncent les chapitres futur. Peu de code pour cette introduction de 33 pages, du texte qui se laisse lire, essentiellement.

Le but des 30 pages du chapitre est de faire le lien entre l’approche orienté objet et la bibliothèque iostream. Ce n’est pas tellement réussi et je pense qu’il aurait fallu simplement faire l’impasse sur la description du modèle objet. Les concepts en sont connus du public visé par le texte.

Heureusement les 80 pages du chapitre 3 vient à la rescousse. C’est sans conteste le chapitre le plus utile du livre pour comprendre la librairie iostream, du moins l’ancienne, celle d’avant le standard 98. La structure et l’architecture de la librairie sont très bien expliqués. En fait, c’est la première référence que jai l’heur de croiser qui m’ait apporté une telle clarté. Par contre les détails sont expliqués sinon moins clairement, du moins plus laborieusement.

Les chapitres 4 et 5 nous offrent des interludes d’une dizaine de pages chacun. Le premier pour expliquer simplement le mécanisme de friendship qui permet d’étendre la librairie iostream de manière externe. Le second pour nous présenter un autre concept clé de la librairie : les manipulateurs. C’est mieux fait que dans le Teale, mais hélas encore une fois un peu court.

Etendre la librairie iostream afin de permettre de manipuler les devices graphiques Windows comme des streams est le véritable objectif du livre ! C’est ce qui est abordé dans les 4 chapitres suivants. Le chapitre 6, le premier d’entre eux est là pour expliquer le mécanisme d’évolution de la librairie iostream sur la base des classes ios et streambuf. Hélas c’est loin d’être claire et franchement abstrait. Et bien entendu c’est aussi un pau à réviser avec la norme.

Les 35 pages du chapitre 7 ont pour objectif d’aborder le wrapping des GDI Windows et OS2 en iostream. La plus grande partie de ce chapitre est consacrée à en expliquer le fonctionnement. Il finit par aborder timidement l’implémentation d’une classe de wrapping : textspace (qui étends ostream).

Ce sont 45 pages qui cette fois sont consacrées à la classe ioscontext qui étends ios, au chapitre 8. Ce chapitre est construit sur le même modèle que le précédent.

Le chapitre 9 consacré aux Blobstreams aurait été fort intéressant s’il était allé jusqu’au bout du propos, à savoir l’implémentation sous forme d’extention de la librarie iostream. Mais il fait un boulot décent à présenter les différents formats images et son.

Un peu à part, le chapitre 10 nous présente le wrapping de la gestion du port série RS 232C sous forme d’iostream. C’est original et intéressant (bien que l’on utilise plus guère cette norme). Mais on est hélas frustré car le chapitre ne va pas au bout de la question.

Les annexes, quoi que volumineuses ne s’avèrent guère utiles. Les deux premières expliquent la notation graphique bizarre utilisée tout au long de l’ouvrage, tandis que la troisième se veut un guide de réfernce de la librairie iostream. A l’usage elle ne s’avère guère opérationnelle.

Au final se livre cherche à atteindre 2 cibles :

  • Faire comprendre la librarie iostream. Cet objectif est plutôt bien atteint par la première partie du livre. En tout cas, c’est mieux que le Teale !
  • Présenter une étude de cas de librarie utilisable sous forme d’interfaces stream. C’est original et même très intelligent et pourrait servir de source d’inspiration pour bon nombre de librarie. Mais le livre est un peu court sur le volet pédagogique pour expliquer la construction de la librarie. Il se noie dans pas mal de sujets connexes comme l’explication de la GDI.

Bref, un avis un peu mitigé au final. Bien sûr l’aspect « manuel de référence » a trouvé mieux depuis, je pense surtout au livre d’Angelika Langer. L’étude de cas aurait mérité un traitement plus structuré, probablement en 3 partie, avec une pour chaque environnement système (Windows et OS2) expliquent le fonctionnement des contexte graphique et permettant d’aborder des wrappers. Et une troisième partie pour construire les extensions de la librarie iostream et des exemples de mise en œuvre.

Le livre échoue finalement à bien sélectionner son objectif. Il y en 2 ici et il ne me semblait guère possible de bien les traitre tous les deux en 300 pages.

Object-Oriented I/O using C++ iostreams

Référence complète : Object oriented I/O using C++ iostreams – Cameron Hughes – Thomas Hamilton & Tracey Hughes – John Wiley & sons 1995 – ISBN: 0-471-11809-5

Object-Oriented I/O Using C++ Iostreams


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

En finir avec la démo ?

Après nous être occupé dernièrement du Scrum Master, j’aimerais maintenant retourner vers les éléments, cérémonies et artéfacts, constitutifs de Scrum. Vous vous rappelez peut-être à cet égard que nous avions abordé le product backlog l’an dernier ?

La démo, puisqu’il le faut…

La démo ? C’est bien !

Crowd waving

La démo, c’est vraiment bien !

La démo, c’est du feedback. Et le feedback c’est le nerfs de la guerre des projets agiles.

Alors, si c’est tellement bien, pourquoi ne fait-on cela qu’une fois par itération ? On devrait faire ça tout le temps !

Mais ce n’est pas le cas.

En fait, comme nous le rappellent Emilie Franchomme et Caroline Damour-Nobi, on ne parle pas de démo, mais de revue de Sprint. Ou plutôt, la démo est (ou est sensée être) juste une partie de la revue de Sprint.

Un anthropologue qui butinerait d’équipe Scrum en équipe Scrum rencontrerait 2 types de populations :

  • Ceux qui sont heureux d’aller à la démo.
  • Ceux qui appréhendent la démo.

En fait, dans les deux cas nous avons un problème. Commençons par le premier, même s’il vous parait probablement curieux d’identifier une équipe heureuse d’aller en démo comme un problème potentiel. Mais ce cas va nous permettre de répondre au point que nous avons laissé en suspens.

La démo c’est cool, on va pouvoir montrer ce que l’on a fait !

Oui, c’est parfois (même souvent) ainsi que l’on aborde la démo : on va dévoiler ce qu’on a réalisé.

Voilà une grave erreur. Nous sommes déjà au coeur du problème. Et ce problème s’appelle “définition of done” !

J’avais abordé il y a quelques temps la question de la définition de terminé. Je vais reprendre ce point de manière légèrement différente :

L’objectif de la démo est de montrer ce qui a été terminé durant l’itération, n’est-ce pas ?

Ce qui est considéré comme terminé doit correspondre à la “définition of done”.

Donc si les utilisateurs (et à fortiori le Product Owner) découvrent en démo les fonctionnalités implémentées, nous avons un problème !

Et ce problème, c’est que la définition de terminé ignore le feedback des personnes utilisant réellement le système. Oh, bien sûr on peut toujours se dire que le trait que nous traçons dans le sable pour délimiter notre responsabilité, c’est l’implémentation du backlog, pas la valeur perçue par les utilisateurs. Ou en tout cas que l’écart de cette valeur perçue sera traité plus tard, à l’itération suivante au mieux.

Bonjour, je voudrais voir mon burndown chart

Bref, si notre objectif c’est de délivrer de la valeur et non du code correspondant à des spécifications nous avons un problème.

Illustrons cela par un bon vieux burndown chart.

Burndown Chart de la démo

Donc, si vous avez tranquillement exclus le feedback utilisateur de la définition de terminé, votre burndown ressemble à la droite en vert. Le petit détail c’est que votre définition de terminé corresponds à de la livraison de fonctionnalité, mais pas nécessairement à de la livraison de valeur.

Si la livraison de valeur est votre focus, justement, alors votre définition de terminé doit inclure ce feedback et à ce moment là votre burndown a l’allure de la courbe en rouge. C’est tout de suite moins classe.

En fait, il y a bien un processus de développement qui met à disposition l’ensemble de produit en fin de cycle de développement : le cycle en cascade !

Grâce à la démo, retrouves le charme oublié du “cycle en V” !

En stigmatisant la démo en fin d’itération, Scrum nous ouvre une brèche pour retomber dans nos vieux démons du cycle en cascade. Oh, bien sûr, telle n’est pas l’intention des géniteurs de Scrum.

En fait, la définition de terminé permet de remettre un poids du bon côté de la balance. Mais la cérémonie de la revue de sprint étant très structurante elle tend à occulter le premier.

La revue de Sprint, en fixant un point de rendez-vous en fin de sprint nous laisse penser que nous pouvons avoir un produit “en chantier” durant l’itération. Traduisez : un produit qui n’est pas stable. Une impression qui est accentuée par l’idée qu’il faut laisser l’équipe tranquille pendant l’itération. On ferme les portes, ce qui se passe pendant cette durée de Sprint ne regarde pas les autres !

Cette pente glissante se traduit par deux symptômes étroitement liés:

  • Une difficulté à pouvoir montrer un produit stable à la démo. Un paradoxe !
  • Un choix de l’équipe d’établir une “période de freeze” avant la démo pour corriger le tir. C’est parfois quelques heures, le plus souvent une demi-journée, voir une journée. Parfois même on augmente la dose.

Ce n’est pas une bonne façon de faire, ce ne sont pas les bonnes mesures préventives. On a juste transformé le Sprint en mini cycle en V ! Et c’est la démo qui nous a tranquillement amené là.

Continuous integration

Oubliez la démo ! Le produit doit être stable tout le temps. Scrum nous dit de faire remonter les problèmes à la surface : supprimez la période de freeze. La démo suivante sera calamiteuse. Travaillez alors la stabilité du produit, non pas une fois par sprint, mais tout le temps.

Nous nous sommes occupé de ceux qui sont heureux d’aller en démo. Que pouvons-nous dire de ceux pour qui c’est la hantise ? Bien sûr, c’est pire !

Direction le tribunal

Parfois, la revue de Sprint, cela ressemble à ça :

Cours de justice

Dans ces moments-là, la revue de sprint n’est plus seulement le moment les utilisateurs découvrent ce qui a été fait mais jugent et statuent sur ce qui ne va pas. Je ne parle pas ici de feedback, c’est à dire d’une dynamique où les invités de la revue de sprint aident à identifier les apports positifs et les points sur lesquels il faudra concentrer l’effort, mais d’un simulacre de revue de sprint où les utilisateurs, les consommateurs devrais-je dire, viennent noter ce qui a été réalisé.

Dans les cas extrêmes, certains des invités sont là dans le but de “prendre l’équipe en faute” ! Vous pensez que j’exagère ? Hélas non.

On ne saurait reprocher à Scrum des perversions qui ne viennent pas du framework, mais des personnes qui sont impliquées. Cela pose plusieurs questions :

  • Lorsqu’une dynamique des personnes impliquées dans la définition du produit ne fonctionne pas, qui doit corriger le tir ? Le Scrum Master ou le Product Owner (car on est côté définition du produit…) ?
  • Le Scrum Master doit-il fixer des protocoles plus cadrés lors de la revue de sprint si elle ne fonctionne pas correctement ?
  • Est-ce une option valable de ne plus inviter une partie prenante si elle affiche sciemment une position négative ?

De temps en temps aussi, le biais ne vient pas des invités de la revue de sprint, mais de l’équipe.

Revue de sprint ou réunion de spécification

“dites-nous ce que vous voulez”. C’est ainsi qu’un Scrum Master a ainsi conclut la partie démo d’une revue de Sprint où les invités avaient été particulièrement silencieux.

Ca part d’une bonne intention. Et effectivement il faut à un moment poser la question, même s’il s’agit plus de comprendre ce dont ils ont besoin plus que ce qu’ils veulent.

Hélas cette simple phrase va changer la nature de la revue de sprint en une seconde. On n’y évoque plus ce qui a été fait, mais ce qui aurait pu être fait. C’est parfois, assez souvent même, intéressant. Cela aurait d’avantage sa place dans un atelier du type “design thinking”. Parfois ce travail d’exploration n’a pas été correctement fait et la revue de sprint en est le symptôme. Mais la revue de sprint n’est le lieu, ni pour collecter les spécifications, ni pour refaire le monde.

Micro-démo

Nous avons vu ce que nous ne devons pas faire, et pourquoi la démo de fin de sprint qui donne une odeur de cycle en V me gêne terriblement. Il est temps de voir ce qu’on peut faire.

N’attendez pas pour avoir du feedback sur les fonctionnalités, la démo de fin de sprint. La “définition of done” doit figurer le feedback sur l’utilisation de la story (que ce soit par le PO ou par les utilisateurs), pas seulement les acceptante tests. Pour cela on organise une petite démonstration impromptue dès que la story est achevée et les acceptante test sont passés. C’est ce qu’on appelle parfois la “micro démo”.

Voici la recette dans les grandes lignes:

  • La micro-démo s’organise “à la volée” dès la story terminée. Pas le lendemain ou dans 2 jours, mais le jour même et si possible dans l’heure qui suit l’achèvement de la story. Avant que le développeur ou le binôme se soit replongé dans la story suivante…
  • Pas de setup particulier: on fait ça sur le poste du développeur, on ne perd pas de temps à mettre des choses en place dans une salle de réunion.
  • On va vite, on limite le temps imparti à 10 minutes environ. Pas de bla-bla. On exécute le scénario sur lequel on s’est mis d’accord en début de sprint. On réponds aux questions précises s’il y en a.
  • S’il y a des ajustements à faire qui apportent de la valeur, l’équipe discute avec le PO de la pertinence de les prendre en compte (cela remet-il en cause le contenu de l’itération…). Si cela est pertinent, on prends ces modifications en compte et cela donnera lieu à une autre micro-démo.
  • Un public limité : développeur, P.O., Scrum Master, testeur, et un ou deux utilisateurs clés s’il y a lieu. Pas plus. De toute façon la place autour du poste du développeur est limitée.

Grâce à la micro-démo, on valide non seulement le fonctionnement de la story (acceptante test), mais son utilisation. Il n’y a plus de surprise lors de la démo.

Mais alors, a-t-on encore besoin de la démo ?

La substantifique moelle de la revue de sprint

La revue de sprint, ce n’est pas seulement la démo. C’est aussi :

  • Exposer la vélocité de l’équipe [Aubry12], p. 125
  • Demander formellement l’acceptation du produit de l’itération [Lacey12], p. 186 ; franchement, c’est moins difficile si l’on est passé par des micro-démo avant !
  • Montrer le produit à des personnes non impliquées dans la définition du produit mais qui ont besoin de constater que celui-ci progresse.

Certes, il n’y a pas que la démo dans la revue de sprint, mais quand même… Cela a-t-il toujours un sens de faire une démo dans la revue de sprint si l’on pratique les micro-démo ?

En fait, oui !

Tout d’abord c’est l’occasion de montrer le produit à des personnes que l’on ne peut toucher qu’occasionnellement, ou qui ne sont pas directement impliquées dans le produit. Ensuite, si la micro-démo permet de voir les fonctionnalités indépendamment, la démo de fin de sprint permet de mettre les pièces du puzzle ensemble et de faire des démonstrations de scénarios plus larges.

Une question de boucle de feedback

En développement agile, tout peut être ramené au niveau de la boucle de feedback. L’achèvement d’une story ne se termine pas avec la boucle de feedback des tests d’acceptance, elle doit inclure celle sur l’utilisation de cette story. Différer ce feedback à la fin d’itération, c’est créer un stock pour la fin d’itération sur lequel on risque de devoir revenir.

Les équipes travaillant en mode Kanban ou en mode mixte Kanban / Scrum tendent à mettre plus d’emphase sur le bouclage des stories, car il y a moins (ou pas) de poids sur ce qui se passe en fin d’itération. En fait, les cérémonies de fin et début d’itération traitent les éléments de travail par lots (un lot étant ce que contiendra le sprint), tandis que le Kanban travaille par flux. Et il est naturellement difficile de combiner travail par flux et travail en lots.

Alors, la démo, c’est mal ?

La démo, ou plutôt la revue de sprint s’avère une bonne chose. Elle permet :

  • De montrer l’avancement du produit à un public large.
  • De collecter du feedback global sur l’itération et l’état du produit.
  • De mettre les pièces du puzzle ensemble

Mais il ne doit pas être l’outil qui transforme le sprint en mini cycle en V. Ne remettez pas le feedback des stories à plus tard, il doit faire partie de la “définition of done” !

Références

[Aubry12] : Scrum, le guide pratique de la méthode agile la plus populaire, 2nd édition – Claude Aubry – Dunod 2011 – ISBN : 978-2-10-056320-3

[Lacey12] : The Scrum Field Guide, practical advice for your first year – Mitch Lacey – Addison Wesley 2012 : ISBN : 978-0-321-55415-4

Note de lecture : SADT, un langage pour communiquer, par I.G.L. Technology

Note : 2 ; Rébarbatif et de peu d’intérêt

Hé oui, j’ai décidé de vous faire lire mes fonds de tiroir ! Celui-ci n’est pas le plus glorieux, je le crains. Mais au début de ma carrière, mon boss a décidé de nous faire suivre une méthode pour le développement de notre projet, et il ne connaissait que SADT ! Ci-git le livre par défaut dont j’ai fait l’acquisition pour me mettre à niveau.

Il y a d’autres méthodes au delà des méthodes objet. Celle-ci, employée dans le monde industriel (sur les automates, entre autre) s’adapte particulièrement mal aux concepts objet. Pour gâter le tout, ce livre qui se rapproche plus du mode d’emploi coréen traduit depuis le serbo-croate, n’a rien pour rendre la méthode sympathique. Voyons ce qu’il a dans les tripes.

La bête accuse un peu plus de 330 pages séparées en 11 chapitres. Mais outre le format légèrement réduit par rapport à la moyenne, il faut notre que le texte est imprimé avec une taille de police assez importante et qu’il s’émaille de tout plein de diagrammes SADT bien sympa. Ce n’est donc pas une lecture très lourde.

Le premier chapitre est une introduction de 3 pages. L’une d’entre-elle est entièrement occupée par un beau diagramme de cycle en V. On sait où on habite ! Le second chapitre est à peine plus long et introduit SADT avec un ensemble de définitions bien chiantes. Pardon ! Le 3ème chapitre rentre un peu plus dans le vif car il introduit les différents concepts et notamment les actigrammes et datagrammes, mais aussi l’équipe SADT … car il y a un concept d’équipe SADT ! Le propos n’est pas palpitant mais au moins est-il raisonnablement clair.

Le chapitre 4 compte 30 pages dont de nombreux diagrammes. On y traite le modèle SADT, donc la notation avec la sémantique associée. Il faut du courage pour aller au bout du texte, car il n’y a apparemment aucune volonté pédagogique sous-jacente ! Cela me rappelle les plus beaux manuels de référence écrits sous la menace…

Le chapitre 5 « création d’un modèle SADT » est la partie processus de la méthode, et plus exactement elle décrit les activités de « l’auteur ». C’est un processus parfaitement prescriptif et les auteurs s’évertue a bien le traiter de manière Tayloriste en décrivant de manière détaillée et décomposée ce que l’Auteur a à faire. Pas de quoi faire briller les yeux. C’est vrai pour la prose aussi, d’ailleurs.

Après les 30 pages du chapitre 5, le chapitre 6 nous offre un interlude d’une douzaine de pages sur le cycle auteur / lecteur. C’est moins pénible à lire, et pas seulement parce que le chapitre est plus court. Je ne parles pas du fond, de toute façon de ce côté, il n’y a rien à sauver.

Le chapitre 7 « comment créer un modèle SADT » couvre 90 pages. C’est simplement le chapitre le plus indigeste que j’ai rencontré dans ma carrière. Apparemment, il s’agit d’une étude de cas. Je dis apparemment, car il n’y a pas un mot d’explication (au sens littéral) simplement une suite de diagramme avec laquelle on doit se débrouiller et dont la séquence doit présenter une logique. Je pense que c’est la photocopie de ce que l’on des auteurs a du produire sur un projet (et dont il a été content car il n’a eu aucune remarque, vu que c’est illisible). Bonne affaire, on a produit une partie du livre à pas cher. Mais comment dire ? Ah oui, je sais : c’est de la merde !

A contrario, le chapitre 8 veut expliquer en 5 pages la notion de « mécanisme SADT ». 3 de ces pages sont occupés par de gros diagrammes incompréhensibles. D’ailleurs, j’ai rien compris.

Le chapitre 9 nous donne un « exemple de kit » sur 55 pages. C’est reparti pour une suite de diagrammes sans explications. C’est pas possible : ce doit être le même larron qu’au chapitre qui a produit cela. Cela n’améliore pas l’odeur de l’ouvrage.

Le chapitre 10 évoque le modèle Entité-Relation pour lever les ambiguïtés du modèle SADT. Et visiblement le marier à SADT ajoute encore à la complexité de la méthode. A moins que ce soit le propos qui ne soit confus. Mais je pense qu’en fait le problème est des deux côtés.

Le chapitre 11 est en fait une annexe qui propose quelques templates SADT, au cas où vous n’en auriez pas bouffé assez…

Je ne me suis pas marré quand je l’ai lu (car je l’ai lu !). La prose est déroulée sans aucun talent ni même une quelconque qualité d’expression. Et je ne parle pas des fameux chapitres 7 et 9 qui atteignent des sommets de nullité. J’ai oublié d’évoqué l’emploi pour le moins excessif des majuscules et du gras (et souvent des deux combinés) qui ajoutent encore un peu plus à l’illisibilité. Vous pensez que j’ai été un peu dur en notant avec un 2 ? Je pense au contraire avoir été assez sympa.

SADT, un langage pour communiquer

Référence complète : SADT, un langage pour communiquer – I.G.L. Technology – Eyrolles 1989 – ISBN : 9782212081855

Harry Potter and the Goblet of Fire (Harry Potter, #4)

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

C++ en 1983…

J’ai posté il y a peu une note de lecture sur l’Annotated Reference Manual (l’ARM pour les intimes). Cela m’a incité à aller chercher plus loin. C’est ainsi que j’ai mis la main sur un document dont on devine à sa seule apparence qu’il est plutôt ancien. Je ne peux résister au plaisir, en passant, de vous livrer la photo de famille du premier meeting du groupe de travail sur C++.

Initial meeting Group C++

Bjarne Stroustrup n’a pas tellement changé, vous allez le reconnaitre facilement !

Voici le document en question.

On ne peut pas vraiment parler de norme, ce document décrit le langage C++ d’une manière que l’on dirait aujourd’hui sommaire. Certains éléments du langage sont absent de cette version préhistorique. Les plus remarquables sont l’absence des mots-clé pour les visibilités private et protected !