If you want to really change culture you have to start with changing structure, because culture doesn’t really change otherwise

Craig Larman

Publicités

L’invention du mot « ordinateur »

C’est Jacques Perret qui, le 16 Avril 1955 inventa le mot « ordinateur », suite à une sollicitation d’IBM pour trouver une traduction Française au mot anglo-saxon (« computer » pour les machines scientifiques et EDS soit « electronic data system » pour les systèmes de gestion) ! Il faut en effet savoir qu’IBM a l’habitude de traduire l’intégralité de ses notices techniques sans y laisser traîner d’anglicisme.

Alors professeur à la faculté des lettres de Paris, il fut sollicité par un de ses anciens élèves pour cette traduction. Comme on le voit il proposa plusieurs termes, « ordinateur », ou plus exactement son pendant féminin « ordonnatrice » ayant sa préférence.

IBM a tout d’abord protégé le nom. Puis, rapidement adopté par les utilisateurs, la société a finalement décidé de le laisser dans le domaine public, quelques mois plus tard seulement.

Cette anecdote nous montre aussi que notre langue, que nous jugeons souvent inapte à capturer des termes liés à la technologie peut aussi faire naître des mots qui s’avèrent supérieurs à leur pendant anglo-saxon ! Il en va de même pour moi du mot « tableur », bien plus parlant que « spreadsheet »…

Cher Monsieur,

Que diriez vous d’ « ordinateur » ? C’est un mot correctement formé, qui se trouve meme dans le Littré comme adjectif désignant Dieu qui met de l’ordre dans le monde. Un mot de ce genre a l’avantage de donner aisément un verbe « ordiner », un nom d’action « ordination ».

L’inconvénient est que « ordination » désigne une cérémonie religieuse ; mais les deux champs de signification (religion et comptabilité) sont si éloignes et la cérémonie d’ordination connue, je crois, de si peu de personnes que l’inconvénient est peut-être mineur. D’ailleurs votre machine serait « ordinateur » (et non ordination) et ce mot est tout a fait sorti de l’usage théologique. « Systemateur » serait un néologisme, mais qui ne me parait pas offensant ; il permet « systémation » ; mais systemer ne me semble guère utilisable ; « Combinateur » a l’inconvénient du sens péjoratif de « combine » ; « combiner » est usuel donc peu capable de devenir technique ; « combination » ne me parait guère viable a cause de la proximité de « combinaison ». Mais les Allemands ont bien leurs « combinats » (sorte de trusts, je crois), si bien que le mot aurait peut-être des possibilités autres que celles qu’évoque « combine ». « Congesteur », « digesteur » évoquent trop « congestion » et « digestion » ; « Synthétiseur » ne me parait pas un mot assez neuf pour designer un objet spécifique, déterminé comme votre machine.

En relisant les brochures que vous m’avez données, je vois que plusieurs
de vos appareils sont désignés par des noms d’agent féminins (trieuse,
tabulatrice). « Ordinatrice » serait parfaitement possible et aurait même
l’avantage de séparer plus encore votre machine du vocabulaire de la
théologie.

Il y a possibilité aussi d’ajouter a un nom d’agent un complément :
« ordinatrice d’éléments complexes » ou un élément de composition, par ex. : « selecto-systemateur ». « Selecto-ordinateur » a l’inconvénient de 2 “o" en hiatus, comme « électro-ordinatrice ».

Il me semble que je pencherais pour « ordinatrice électronique ». Je souhaite que ces suggestions stimulent, orientent vos propres facultés d’invention. N’hésitez pas a me donner un coup de telephone si vous avez une idée qui vous paraisse requérir l’avis d’un philologue.

Votre

J. Perret

Note de lecture : Programmer sous Windows 95 (4ème édition), par Charles Petzold et Paul Yao

Note : 9 ; Plus qu’un livre : une institution

10 ans après la 1ère édition, cette 4ème (qui ne fut pas la dernière) a encore pris de l’embonpoint pour atteindre 1200 pages. Malgré l’entrée dans le monde 32 bits, cette institution qu’est « le Petzold » reste fidèle à la programmation via les API héritées de Win16. Donc la part belle est faite aux applications fenêtrées : fenêtres, menus, tracés graphiques, impression, boites de dialogue, presse-papiers, etc… Il traite plus succinctement des aspects systèmes et des aspects spécifiques à Win32. Il est temps d’entrée dans le cœur du sujet. On parle de 20 chapitres regroupés en 5 parties.

La première partie comporte 4 chapitres totalisant 270 pages. Le livre ne commence réellement qu’au chapitre 2, qui s’articule autour du redoutable HelloWin.c ! Il faut tout le talent pédagogique de Charles Petzold pour démystifier les arcanes de la boucle d’événement et des handles de fenêtre, afin de donner une logique à l’ensemble. Utiliser le Canvas de fenêtre, l’événement WM_PAINT et autres invalidation de surfaces (sans parler des scroll barres) n’est pas non plus une sinécure, mais le chapitre 3 y vient à bout de manière méthodique. Une bonne base pour aborder la terrible complexité de la GDI au chapitre 4 ! Toutefois, le sujet mérite un livre (au moins) à lui tout seul et celui-ci ne saurait couvrir complètement le sujet…

La seconde partie est consacrée à la saisie. On parle de saisie au sens large : comptez 4 chapitres et 200 pages pour des sujets couvrant bien sûr le clavier et la souris, mais aussi l’horloge et les fenêtres enfant ! On ne se douterai pas au premier abord que la gestion du clavier puisse être si complexe, impliquant des messages clavier, mais aussi de focus de fenêtre, sans compter la prise en compte de paramètres OEM ! Un sujet parfaitement traité en profondeur ici. Heureusement, la gestion de la souris traitée au chapitre 6 génère moins de tracas, même quand on essaie de pousser le sujet dans ses retranchements : souris gérée au clavier, capture de la souris (si, si), etc.. La gestion de l’horloge abordée au chapitre 7 est pour une fois réellement simple sous Windows, peut-être est-ce pour cela que l’auteur a choisi un exemple complexifiant inutilement le sujet en y mettant de la GDI ? Par fenêtre enfants, il faut entendre les contrôles, essentiellement les boutons et la façon dont ils communiquent avec la fenêtre encadrante. Ce chapitre conclue cette partie.

C’est à la gestion des ressources qu’est consacrée la 3ème partie. 4 chapitres et pas loin de 450 pages sont nécessaires pour couvrir ce sujet hélas beaucoup plus compliqué qu’il ne devrait ! Icônes, curseurs et bitmaps que l’on fait figurer dans le fichier .res sont vite balayés au chapitre 9. La gestion des menus est menée de façon plus poussée au chapitre 10, avec quelque cas d’usage non orthodoxes ! Les boites de dialogues sont un sujet très large, allant des boites de messages et des CommonDlg aux boites de dialogues non modales. 90 pages pour couvrir cela de manière progressive et pédagogique ne sont pas de trop. Un sujet qui s’entend sur les 110 pages du chapitre suivant pour couvrir des aspects avancés qui sont une spécificité de cette édition « Windows 95 ». Hélas le sujet est traité avec beaucoup moins de pédagogie, c’est même un peu confus.

La 4ème partie pèse 150 pages et 3 chapitre et est entièrement dévolue aux fonction système. Le chapitre 13, très court donne une impression de bâclé pour traiter la gestion mémoire et des entrées sortie. Le chapitre consacré au multitâche l’est moins, mais on ne peut toutefois le considérer que comme une introduction au sujet. Il ne saurait faire concurrence au texte de Jeffrey Richter. On finit avec la gestion de l’imprimante, un sujet ridiculement compliqué, mais que la prose de l’auteur, encore perfectionnée depuis l’édition précédente, rend abordable.

La dernière partie de l’ouvrage est consacrée aux différents modes d’échange de données. 250 pages sur 5 chapitres leur sont consacrés. 2 chapitres sont consacrés respectivement au presse-papier et au très malcommode DDE. Je m’étonne de le trouver encore là, car son remplaçant (OLE) point le bout de son nez un peu plus loin… L’interface MDI, dont c’était le chant du cygne a encore doit à son chapitre également. Pas de changement non plus pour le chapitre consacré aux DLL, je continue à trouver que la gestion « sans import » n’est pas sérieusement traitée, alors que c’est la seule réellement utile ! Enfin le chapitre 20 nous fait découvrir OLE, nouveauté de cette version. Disons que c’est un chapitre introductif à la question, mais il est plutôt bien fait, eut égard au sujet dont la courbe d’apprentissage est plutôt raide ! Notons aussi que c’est le seul chapitre dont les exemples sont en C++. Bien sûr la couverture du sujet est très loin d’être à la hauteur du Brockschmidt, mais celui-ci n’est pas non plus extraordinairement pédagogique…

Bien sûr, cela semble dépassé de s’intéresser à la programmation Windows aujourd’hui, surtout à aussi bas niveau. Néanmoins, comprendre le fonctionnement d’une interface fenêtrée au niveau de ses fondamentaux n’est pas ridicule. A l’époque où le développement Windows battait son plein, je considère que la connaissance du développement au niveau des API était un savoir fondamental, même à une époque où l’on développe confortablement avec les MFC et des assistants (beurk !). Le Petzold est un modèle de pédagogie, c’est pourquoi j’avais élu l’édition précédente (celle de 1992) « book of the year ».

image

Référence complète : Programmer sous Windows 95, 4ème édition – Charles Petzold & Paul Yao – Microsoft Press 1996 – ISBN : 2-84082-195-8 (VO : ISBN 1-55615-676-6)

Programmer sous Windows 95

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

Note de lecture : Analyse orientée objets, par Peter Coad et Edward Yourdon

Note : 4 ; Typique de l’approche objet des années 80

Il s’agit ici de l’approche objet typique des années 80. L’emphase est mise sur l’identification “à priori” des objets, ainsi que des attributs et des services attenants, en ne prenant que faiblement en compte le contexte de leur utilisation. Avec 180 pages pour 10 chapitres, ce n’est pas un gros volume. Un second tome, dédié à la conception le complète.

Le premier chapitre est un très classique argumentaire de l’intérêt de l’objet par rapport à la décomposition fonctionnelle en rappelant les grands traits de l’objet : héritage et encapsulation principalement.

Les chapitres 2 et 3 s’articulent autour de l’identification des objets. On notera aussi passage l’évocation de Smalltalk par les auteurs. Les méthodes suggérées sont plutôt empiriques, et surtout on reste sur l’idée d’identifier les objets « à priori », symptomatique du courant de pensée de cette époque.

Le chapitre 4 consacré à l’identification des structures est en fait consacré à l’héritage. Il répond à la question : qu’est-ce qui est et qu’est-ce qui n’est pas un héritage. Question dont la réponse est : ce qui obéit à la relation « est un ». On n’avait pas besoin de 30 pages pour cela ! La notion de « sujet » qui est l’objet du chapitre 5 correspond plus ou moins à celle de package. Elle est curieusement mêlée avec l’idée d’une classe parent qui porterai le même nom… On est décidément dans la mouvance « montrez-moi votre arbre d’héritage !

Attributs et relations sont abordés au chapitre 6. J’ai trouvé que c’était le plus intéressant arrivé à ce point de la lecture, car il répond au moins à des questions de structuration concrètes.

La notion de « service » abordée au chapitre 7 correspond au volet dynamique de la modélisation. Son focus n’est pas très clair car assemble plusieurs concepts, y compris des notions d’architecture et de diagramme d’état. Bref, je n’ai pas accroché.

Le chapitre 8 consacre quelques pages futiles aux outils de modélisation. De même le chapitre 9 est succinct et prétend traiter le passage à la conception orientée objet. Si l’auteur disent bien qu’il s’agit d’un continuum, on ne voit rien de tangible. Le livre se conclut sur un chapitre 10 qui traite de considérations générales sur la mise en œuvre de l’analyse orientée objets.

Ce livre est symptomatique de l’approche objet de la fin des années 80 : une emphase sur les aspects objet liés à l’héritage, plus encore qu’à l’encapsulation (évoquée, mais pas vraiment mise en œuvre). On y voit beaucoup de formalisme et une grande rigidité dans la démarche, ce qui rend cette démarche (comme les autres) bien peu opérationnelle.

L’ouvrage, aujourd’hui ne présente plus qu’un intérêt historique, mais sa lecture ne présente plus d’intérêt pour lui-même. Qui plus est, la prose, du moins dans sa traduction est plutôt aride.

image

Référence complète : Analyse orientée objets – Peter Coad & Edward Yourdon – Masson 1993 (V.O.: Object Oriented Analysis, 2nd edition – Prentice Hall 1991) – ISBN: 2-225-82562-9

Analyse orientée objets

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

Note de lecture : The C++ Answer Book, par Tony L. Hansen

Note : 6 ; Un compagnon de route au Stroustrup.

Il s’agit, comme son titre l’annonce d’un livre d’exercices corrigés. Aujourd’hui c’est un texte fort ancien. Ancien peut-être, mais volumineux, certainement. On en prend pour 520 pages sur 8 chapitres seulement, sans compter les annexes ! Voyons ce qu’il a dans le ventre.
On passera rapidement sur le 1er chapitre qui est introductif (5 pages) pour nous tourner vers le 2nd qui traite des déclarations et des constantes. Les exercices sont tous très simples, c’est aussi l’occasion d’évoquer des éléments connexes à la questions en plus de répondre à celle-ci.

Si le chapitre 2 ne comptait qu’une trentaine de pages, c’est près de cinquante que nous offre le chapitre 3 dédié aux expressions. On y a droit inévitablement aux ordres d’évaluation de expressions, mais aussi aux comportements « limite » du langage, y compris à ceux causant des problèmes de portabilité. Une partie significative du chapitre est dédié à la manipulation de chaine de caractères, à l’ancienne façon « C ». Le niveau de difficulté augmente significativement, il était au maximum à 1.5 au chapitre 1, il monte ici à 2.5 selon l’échelle exponentielle de l’auteur ! La dimension algorithmique des exercices n’est pas triviale. De quoi se rafraichir les neurones !

Au chapitre 4, on évoque les fonctions et les fichiers. Du moins c’est ce que dit le titre. 60 pages sont consacrées à cette partie qui, en fait a surtout trait à la manipulation de structures : listes, graphes ou tableaux bi-dimensionnels avec les inévitables tris et manipulation. On parle en fait assez peu de fichiers et si on évoque les différences entre C et C++, cela reste du code à affinité C. Bien sûr, le niveau de difficulté augmente sensiblement et culmine à 3.

Le chapitre 5 marque notre véritable entrée dans le C++ car il y est question de classes ! Transition en douceur, car les premiers exercices font suite au chapitre précédent et l’on commence par faire des classes avec des struct ! D’un point de vue utilisation du langage, les 80 pages de ce chapitre restent dans la simplicité. Finalement on travaille surtout à encapsuler la complexité algorithmique dans des classes, ce qui n’est pas si mal. D’un point de vue conception, l’exercice le plus complexe est l’implémentation d’un interpréteur d’expressions à l’aide d’un pattern composite (l’un de mes exercices préféré).

Il me semble assez curieux que le chapitre suivant soit consacrée à la surcharge d’opérateur, car il ne m’a jamais semblé que ce soit une fonctionnalité fondamentale. On trouve quand même 125 pages à lui consacrer ! On commence à rentrer dans le dur du comportement du langage. Il est d’ailleurs troublant de constater que la notion de référence est abordée ici chemin faisant… La classe LINT (large int) nous occupe pas mal de temps, notamment pour comprendre les comportements au limite du langage. Après avoir plafonné à 3 au chapitre précédent, le niveau de difficulté culmine à 4.

Ce sont 90 pages qui sont dédiés à la question des classes dérivées dans cet avant-dernier chapitre. L’exercice sur la classe process nous vaut le niveau de difficulté maximum, mais le chapitre me semble globalement simple. Si on y trouve de l’héritage privé (une fonctionnalité dont l’usage est rare), ainsi que des enum et des classes « friend », nulle trace d’héritage multiple et d’héritage virtuel ! Mais je ne dois pas oublier que le livre date de 1990…

Le dernier chapitre est consacré aux streams. Un sujet souvent bien mal traité. Ici ce sont 90 pages qui lui sont consacrées. Après un démarrage en douceur on aborde vite des exercices compliqués comme l’implémentation de la librairie IO C en C++ et vice-versa !

Les exercices traitant des parties cœur du langage sont toujours valables, ils mériteraient une réactualisation par rapport à la librairie standard, bien sûr. C’est donc un bon bouquin pour solidifier les bases.

Les exercices sont souvent courts et les explications précises. Les plus complexes nécessitent qu’on leur consacre beaucoup, beaucoup de temps ! Par bien des côtés, je retrouve là l’approche du Kernighan & Ritchie. Avec 550 pages il est quand même moins digeste que son aîné. De fait, c’est plutôt un texte dans lequel aller picorer des exercices, plus qu’à être lu de bout en bout ! Le texte fait référence au Stroustrup orignal (1er édition) que je ne possède pas, ayant débuté avec la seconde édition en français.

image

Référence complète : The C++ Answer Book – Tony L. Hansen – Addison Wesley 1990 – ISBN : 0-201-11497-6

The C++ Answer Book

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

En Finir avec le Planning meeting ?

Je vous avais laissé sur la remise en cause des estimations. Natrellement, le sujet suivant ce dvait être le planning meeting. Nous allons nous y attaquer aujourd’hui !

Autopsie du planning meeting

Le planning meeting de Scrum, c’est une composante importante de la démarche, du moins dans le Scrum Su (). De là découle tout ce qui sera fait durant le sprint. Aussi intéressons-nous à ce qui le constitue.
Tel que décrit initialement, le planing meeting comporte 2 parties, c’est donc en fait 2 meetings en un seul [1] :

  • Une présentation des fonctionnalités souhaitées pour le prochain sprint
  • Une planification de l’execution de ces fonctionnalités pour la durée du sprint

Les textes ultérieurs ont ajouté un peu de détail, comme la présentation de l’objectif de sprint et la détermination de la capacité de travail [2]

image

Au fait, quelle est la durée de ce meeting ? Ken Schwaber nous parle d’une durée de 8 heures pour un sprint de 30 jours ! Personnellement, un tel marathon dépasse mes forces et de très loin. Heureusement, bien que les créateurs de Scrum clament la même durée de Sprint depuis 20 ans, je ne connais personne planifiant des sprints aussi long. Mais même ramené au pro-rata à 2 semaines, une durée de 4 heures me semble excessive !

Hélas, il n’y a pas que la durée qui ne va pas. Ce serait même plutôt le moindre de nos soucis. Commençons donc notre travail de dépeçage.

A faire pour le prochain Sprint

La première partie du planning meeting est, nous dit-on consacrée à l’exposé de ce qui est attendu pour le prochain sprint [4]. C’est vrai que je préfère comprendre mon sujet avant de m’y attaquer. Je crois pouvoir dire sans trop me tromper qu’il en va de même pour la plupart d’entre-nous. Par contre, il y a autre chose que je me sens incapable de faire : c’est donner une réponse sur la manière d’entreprendre la réalisation une fois l’explication terminée !

J’ai besoin de réfléchir à ce que l’on vient de me dire, de poser des questions, ruminer à nouveau, en discuter, échanger sur les alternatives, etc. Ca ne nécessite pas des semaines et des mois, ni même beaucoup de charge, mais un peu de délai, disons quelques jours. Me trouver bloqué dans une salle pour mener le processus de bout en bout ne me convient pas. C’est pourquoi je préfère séparer les choses en deux.

image

Débarrassé de la discussion fonctionnelle, le planning meeting ne contient plus que le plan d’action du sprint, il est donc deux fois moins long (on passe de 4 heures à 2 heures pour un sprint de 2 semaines, parfois même moins). Et on n’y évoque donc que les sujets auxquels on a été initiés.

Nous reviendrons bientôt sur cette question du plan d’action. J’aimerais pour l’instant évoquer la discussion fonctionnelle que j’ai séparé du planning meeting proprement dit.

Goodbye, Product Owner…

J’ai un peu culpabilisé quand j’ai pour la première fois proposé de séparer la discussion fonctionnelle : j’avais l’impression de faire une suggestion sur la base de mon inaptitude à explorer complètement un sujet en séance ! Très vite, je me suis cependant aperçu que les membres de l’équipe avaient le même inconfort que moi. D’autres discussions avec des confrères et autres relations m’ont appris que cette gêne était bien plus répandue que je ne le pensais, pour ne pas dire généralisée.

C’est donc avec bonheur que je me suis mis à faire des points d’exploration fonctionnelle (parfois plusieurs) quelques jours avant le planning meeting. Avec quand même deux sujets d’insatisfaction :

  • Explorer tous les sujets d’un sprint, c’est quand même du boulot, surtout si on veut le faire correctement.
  • Une fois que nous avons analysé les user stories, on a parfois tendance à ne plus voir le Product Owner durant tout le sprint.

La réponse à ces deux sujets est commune. Mais je voudrais avant tout affiner le second point : Pourquoi parfois ne parle-t-on plus (ou en tout cas moins) au Product Owner durant le sprint ? Après tout, Scrum nous dit bien que l’équipe de développement et le PO doivent collaborer ! A qui est-ce la faute [5] ?

La faute n’en incombe à aucune des parties spécifiquement. Elle incombe plutôt au processus. En balayant tous les sujets en amont, on instille insidieusement l’idée que nous avons vu tout ce que nous avions à savoir sur le sujet et que nous pouvons vivre notre vie chacun de notre côté pour la durée d’une itération !

Ah oui ! Et aussi, incidemment, nous avons transformé notre sprint en un mini cycle en « V » [6] !

Voyons maintenant le sujet sous un autre angle en tentant de réponde au premier point énoncé plus haut.

La promesse d’une conversation

Quand on balaye tous les sujets d’un sprint, ça fait pas mal de boulot, disais-je. Non seulement cela, mais on discute vraiment très en amont de user stories qui seront traitées vers la fin du sprint !
Mais au fait, c’est quoi exactement une user story ?

Si l’on se réfère à ce que disait l’extrême programming où ce concept a été créé, la user story est « la promesse d’une conversation » [7]. C’était facile, c’est le titre de la section !

Et l’idée de cette promesse, c’est de parler de cette user story « juste à temps », pas de traiter un « stock de discussions ». Interagir autour de cette user story juste à temps présente plusieurs avantage, et aussi au moins un inconvénient que nous verrons plus tard :

  • L’exploration de chaque user story devient un travail plus concis. Plus la peine de programmer de grande pleinières !
  • On aborde chaque user story que préalablement à sa réalisation, le sujet reste frais dans notre esprit et les informations ne se sont pas encore estompées.
  • Puisque l’on retarde le moment où l’on explore le sujet, on bénéficie de tout ce que l’on a appris entre temps. Comme les sujets ont tendance à être traités au sein d’un même sprint, il y a une bonne chance pour que cet acquisition d’information nous bénéficie effectivement.

Il y a bel et bien un inconvénient, cependant : Si l’on doit fourbir notre plan d’action lors du planning meeting (vous savez, la moitié du planning meeting que nous avons conservé jusqu’à présent), cette approche ne convient pas, car nous n’aurons pas évoqué les user stories avant d’avoir à en faire le découpage en tâches !

Le choix est cornélien. Rassurez-vous, nous avons un autre problème inhérent au volet « plan d’action » de notre planning meeting !

Le planning meeting, un plan d’action ?

Nous sommes parés concernant la connaissance fonctionnelle de nos user stories. Allons-y, découpons tout ça en tâches pour faire le plan de notre itération [8]. Comme nous sommes agiles, nous saurons aussi nous adapter, bien entendu. Sauf, que l’on se demande bien comment, car nous avons tous coulé dans le béton à l’instant !

En y regardant de plus près, notre problème d’adaptation se situe même à deux niveaux :

  • Pouvoir adapter le contenu du sprint (donc les stories) à l’objectif du sprint. C’est vrai, nous n’avons pas parlé d’objectif de sprint jusqu’à présent. Un peu de patience, ça va venir.
  • Permettre d’explorer et pouvoir décider de la manière dont on conçoit un pan du système pendant que l’on travaille dessus.

Arrêtons-nous un instant sur ce dernier point. Implicitement, le planning meeting induit que nous devons décider tôt, au moins dans les garndes lignes, la conception d’une fonctionnalité à réaliser. C’est ce qui sous-tend le découpage en tâches des fonctionnalités. Or parfois, même cette décision est difficile à arrêter tôt. Parfois encore, nous avons plusieurs options à notre disposition [9], pourquoi devrions-nous opter pour l’une d’entre-elle à un moment où nous n’avons pas suffisamment d’informations à notre disposition pour décider [10] ?

image

Vous l’aurez peut-être compris, en nous obligeant à fixer nos choix tôt, le planning meeting va à l’inverse de ce que le Lean nous enseigne. En fait, il va aussi à l’encontre de la notion de conception émergente inscrite dans les principes agiles !

Ce n’est hélas pas fini, il y a plus grave ! Ce qui est vrai à l’échelle d’une user story l’est aussi à l’échelle supérieure : l’objectif de sprint !

Vers une planification orientée objectifs

La version 2013 du Scrum Guide reconnait l’importance de la notion d’objectif de sprint [11]. Il n’est pas seulement évoqué au sein du planning meeting, il l’est aussi au niveau du stand-up : il est maintenant la boussole qui nous permet des réajustements ! De mon point de vue, il s’agit d’un pas important dans la bonne direction, celle de la finalité du produit construit.

Maintenant, il faut que le reste du framework Scrum soit en harmonie avec cette idée !

Le plan d’action que nous dresserons lors du planning meeting sera en accord avec l’objectif de sprint, n’en doutons pas. Mais qu’advient-il des nouvelles idées qui naissent de la réalisation des premières fonctionnalités ? Que fait-on des nouvelles options qui germent au grée de la réalisation ? C’est vrai, initialement Scrum nous assène que tout changement ne peut être pris en compte que dans le sprint suivant ; au sein du sprint courant, on va en ligne droite et on ne change rien ! Mais justement, focaliser le sprint sur la finalité plus que sur la fonctionnalité, c’est accepter l’adaptation en cours de sprint et remettre en cause la nature irrévocable de ce qui est décidé en planning meeting.

image

Maintenant que nous avons remis en cause le plan d’action du planning meeting, que nous reste-t-il ? Au moins la synchronisation entre le PO et l’équipe, certes, mais quoi d’autre ?

Il n’y a pas qu’une façon de faire notre planning meeting

Comme souvent, la réponse sera : ça dépend ! Cela dépend de la part d’inconnu que recèle intrinsèquement le projet. Par exemple, à quel point le projet est innovant, mais pas seulement.

Si l’on proclame, et je le fais, que la réalisation d’un projet en agile se justifie d’autant plus qu’un projet est innovant, n’oublions tout de même pas que l plus grande part de nos projets informatiques ne le sont que faiblement : il s’agit en très grande partie de logiciels de gestion. Les besoins d’adaptation de ce type de logiciels sont à la marge et surtout au niveau de détails (ergonomie, règles de gestion, etc..) mais rarement au niveau des grandes fonctions. Dresser un plan d’action complet du sprint lors du planning meeting a pleinement du sens dans ce contexte. C’est même confortable.

A l’autre bout du spectre se tiennent les intrépides explorateurs [12] : ils recherchent le nouveau paradigme, veulent créer l’océan bleu d’un marché à créer de toutes pièces [13] ! Construire un plan de sprint devient contre-productif. Ce dont on a besoin là, c’est d’une direction à suivre à court terme, d’hypothèses à vérifier et d’options à explorer. Le planning meeting devrait graviter autour de cela. Le Daily meeting peut alors devenir une réunion de réajustement du planning meeting, où sont éliminées les hypothèses non vérifiées, sélectionnées les options les plus intéressantes, etc..

Les variantes situées entre ces deux extrémités restent à inventer, lorsqu’elles ne l’ont pas déjà été.

Alors le planning meeting, c’est mal ?

Sortir du planning meeting avec les post-it de stories et de tâches, et pouvoir les afficher sur le Scrum Board mural, je dois avouer, j’apprécie cela ! Tout le monde peut voir durant l’itération où l’on en est, rien qu’en observant le volume de post-its déplacés à droite par rapport à ceux restant à gauche. La plupart du temps, le burndown n’est même pas nécessaire. Comme nous l’avons dit plus haut, cela signifie que le sprint est assez linéaire et plutôt sans surprise !

image

Alors oui, dans ce cas le planning meeting, plus ou moins comme prévu dans Scrum a du sens. Doit-on en conclure que cette cérémonie n’a plus de sens quand le niveau d’incertitude augmente ? Certainement pas ! Mais il faut en adapter le format.

Que penser alors du « mode Kanban » qui bascule complètement le fonctionnement de l’équipe en flux tiré, rendant toute forme de planning meeting sans objet [14] ? J’ai tendance à trouver que dans le cas du développement de produits au moins, une certaine forme de planning meeting fait défaut. Si Kanban excelle à établir le SLA d’une équipe de développement, il lui manque quelque chose pour établir le cap, synchroniser l’équipe et le demandeur à intervalle régulier autour du cap pour favoriser la collaboration entre les acteurs autour du produit. Un planning meeting orienté « roadmap produit » au sens que lui donne l’Impact Mapping [15] pourrait jouer ce rôle, par exemple.

Donc oui, j’aime bien le planning meeting, mais un planning meeting « lean » adapté à la typologie du projet et non une vision rigide, voir tayloriste, de celui-ci !

Ressources

[1] : Agile Software Development with Scrum – Ken Schwaber & Mike Beedle – Prentice Hall / series in agile software development 2001 – ISBN: 0-13-067634-9 ; p. 46

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

[3] : Agile Project Management with Scrum – Ken Schwaber – Microsoft Press 2004- ISBN: 0-7356-1993-X ; p. 8

[4] : Essential Scrum, A practical guide to the most popular agile process – Kenneth S. Rubin – Addison Wesley / Signature series 2013 – ISBN : 978 0 13 704329 3 ; p. 338

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

[6] : Water-Scrum-Fall Is The Reality Of Agile For Most Organizations Today – Dave West – Forrester 2011 ; p. 9

[7] : Extreme Programming Installed – Ron Jeffries, Ann Anderson & Chet Hendrickson – Addison Wesley / XP series 2001 – ISBN: 0-201-70842-6 ; p. 28

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

[9] : Commitment – Olav Maassen, Chris Matts & Chris Geary – Hathaway te Brake Publications 2013 – ISBN : 978-90-820569-0-7

[10] : Leading Lean Software Developemnt – Mary Poppendieck & Tom Poppendieck – Addison Wesley / Signature series – ISBN: 978 0 321 62070 5 ; p. 87

[11] : The Scrum Guide – Ken Schwaber & Jeff Sutherland – Scrum.org 2013 ; p.10

[12] : The People’s Scrum, Agile ideas for revolutionary transformation – Tobias Mayer – Dymaxicon 2013 – ISBN : 978 1 937 965150 ;p. 49

[13] : Blue Ocean Strategy: How To Create Uncontested Market Space And Make The Competition Irrelevant – W. Chan Kim & Renée Mauborgne – Havard Business Press 2004 – ASIN : B001E5207M

[14] : Scrumban, Essays on Kanban systems for lean software development – Corey Ladas – Modus Cooperandi Press 2008 – ISBN : 978 0578002149 ; p. 99

[15] : Impact Mapping : Making a big impact with software products and projects – Gojko Adzic – Provoking Thoughts Ltd. 2012 – ISBN : 978-0-9556836-4-0