Améliorer la communication pour livrer vos logiciels dans le respect des spécifications

Improve communication to deliver your software on specification

En tant que Product Owner (PO), je ne supporte pas que mon Ă©quipe ne livre pas l’incrĂ©ment (dans son intĂ©gralitĂ© !) qu’elle avait promis Ă  la fin du sprint. En effet, je passe du temps avec mes clients pour dĂ©couvrir ce qu’ils veulent. Ensuite, je conçois des fonctionnalitĂ©s utilisateur que je transforme en work packages. J’Ă©tablis ensuite les prioritĂ©s, je les affine et je les planifie avec l’Ă©quipe. Nous concluons mĂȘme un accord ensemble avant de commencer un nouveau sprint. AprĂšs tout cela, lorsque mon Ă©quipe ne fournit pas tout ce Ă  quoi elle s’Ă©tait engagĂ©e, j’ai la dĂ©sagrĂ©able impression que tout ce travail de prĂ©paration n’a Ă©tĂ© qu’un effort inutile. Tous ces frais gĂ©nĂ©raux SCRUM pour rien ! Je me sens comme Rigor Mortis dans Oui, Seigneur des TĂ©nĂšbres:

rigor mortis

« – Nous n’avons pas vu venir ce problĂšme »
« – Cela a pris plus de temps que prĂ©vu »
« – La bibliothĂšque est mal documentĂ©e »
« – Notre systĂšme de rĂ©fĂ©rence Ă©tait en panne »
« – Nous ne l’avons pas compris de cette façon »
« – Quelqu’un de l’Ă©quipe a Ă©tĂ© malade pendant trois jours »,

would say, for example, my teams of goblins to creatively justify why they don’t deliver on specification at the end of the sprint. Because they failed, some features have to be postponed to a later sprint, therefore they are not delivered on time. Sometimes, bugs would be discovered during software demonstrations to our customers. Suddenly, the software just doesn’t work, « for no reason », and the goblins invoke the « demo effect ». In the end, Rigor Mortis has no other choice than doling out the withering look.

withering-look-hidora-news

Bien sĂ»r, je peux aussi, en tant que PO, ĂȘtre responsable de l’Ă©chec. Parfois, je guidais mes Ă©quipes de lutins vers les mauvaises fonctionnalitĂ©s. Nous connaissons tous, en effet, la caricature de la gestion de projet en forme de balancier:

tree swing on hidora website

Il est assez facile pour un PO de mal comprendre les besoins des clients et mĂȘme lorsqu’il les comprend correctement, le PO peut Ă©chouer dans sa mission de communiquer ce qu’il veut Ă  l’Ă©quipe. De mĂȘme, lorsque le PO utilise des moyens inappropriĂ©s pour suivre les progrĂšs de l’Ă©quipe, il est entiĂšrement responsable de l’Ă©chec. Discuter avec les membres de l’Ă©quipe (par exemple, lors des rĂ©unions quotidiennes) ne suffit pas pour avoir un aperçu de ce qui se passe. Au contraire, ce dont le PO a besoin, ce sont des chiffres pour Ă©valuer les progrĂšs. Comme l’a dit Lord Kelvin, « lorsque vous pouvez mesurer ce dont vous parlez et l’exprimer en chiffres, vous en savez quelque chose ; mais lorsque vous ne pouvez pas le mesurer, lorsque vous ne pouvez pas l’exprimer en chiffres, votre connaissance est maigre et insatisfaisante ». Dans le dĂ©veloppement de logiciels, « le logiciel fonctionnel est la principale mesure du progrĂšs », comme l’indique le 7e principe agile. Par consĂ©quent, nous devons trouver un moyen de relier ce que notre client veut avec ce que notre Ă©quipe dĂ©veloppe d’une maniĂšre mesurable, et c’est prĂ©cisĂ©ment ce que je voudrais aborder maintenant en prĂ©sentant … un outil de communication gratuit.

Il est temps d’Ă©chapper Ă  l’enfer de la rigiditĂ© cadavĂ©rique.

Fermons la parenthĂšse agile pour l’instant et concentrons-nous sur les problĂšmes rĂ©els. Supposons qu’un client vienne et demande :

« – hĂ©, je voudrais que vous ajoutiez une fonctionnalitĂ© de connexion Ă  ma plateforme »

Nous avons deux problĂšmes. D’une part, nous devons dĂ©terminer exactement ce qu’ils veulent. D’autre part, nous devons nous assurer que notre Ă©quipe logicielle comprend prĂ©cisĂ©ment ce que nous voulons et qu’elle trouve elle-mĂȘme comment y parvenir de maniĂšre efficace et fiable.

Du client aux « trois amigos ».

Selon le client, la fonctionnalitĂ© peut ĂȘtre rĂ©sumĂ©e par l’histoire d’utilisateur suivante :

En tant que directeur de magasin,

je veux me connecter au tableau de bord de gestion,

afin de pouvoir accéder aux données sensibles de mon magasin.

Mais, bon, cette histoire d’utilisateur comporte de nombreux aspects. Pour commencer, le client doit dĂ©cider du type d’informations d’identification qu’il souhaite utiliser. Un ensemble nom d’utilisateur / mot de passe ? Le nom d’utilisateur peut-il ĂȘtre un courriel ? Veut-il activer l’authentification multifactorielle (AMF)? Par ailleurs, accepte-t-on n’importe quel mot de passe ou applique-t-on une politique de mot de passe? En outre, combien de temps une connexion doit-elle rester valide ? Faut-il une fonction « se souvenir de moi » ? Enfin, Ă  quoi doit ressembler visuellement cette fonction ?

Une discussion avec le client pourrait aboutir à la spécification suivante du Gherkin:

C’est un rĂ©sumĂ© de notre discussion avec le client. Nous nous sommes mis dans la situation d’un manager utilisant le systĂšme et nous avons proposĂ© des cas d’utilisation ou des scĂ©narios. Notez que la spĂ©cification ci-dessus est Ă©crite avec la syntaxe Gherkin mais vous pouvez choisir la syntaxe de votre choix. En ce qui me concerne, j’aime utiliser la syntaxe Gherkin, qui est prise en charge par de nombreux langages de programmation, ou la syntaxe gauge markdown, qui est prise en charge par moins de langages de programmation (C#, Java, Javascript, Python et Ruby, au moment de la rĂ©daction de cet article). Vous pouvez trouver plus d’informations sur ces deux possibilitĂ©s ici, ainsi que sur d’autres choix.

En plus de la spĂ©cification ci-dessus, le client nous donne carte blanche pour les aspects visuels. C’est tout pour les cas d’utilisation de haut niveau. En substance, ils ne veulent pas de MFA ni de fonction « se souvenir de moi ». Au lieu de cela, ils veulent rester simples et stupides, avec une authentification de base par email / mot de passe et une politique de mot de passe simple.

Cependant, l’histoire ne s’arrĂȘte pas lĂ . La fonctionnalitĂ© doit ĂȘtre mise en Ɠuvre et c’est lĂ  que nous impliquons les « trois amigos ». Bien qu’il soit agrĂ©able d’avoir dĂ©fini clairement ce que le client souhaite, il peut manquer des scĂ©narios permettant de vĂ©rifier « ce qui se passerait si… ». Par exemple, nos dĂ©veloppeurs et testeurs pourraient trouver d’autres mots de passe non conformes. En outre, les caractĂ©ristiques de haut niveau ci-dessus ne couvrent certainement pas l’ensemble de la fonction de connexion. Par exemple, qu’est-ce que cela signifie d’ĂȘtre connectĂ© ? Comment pouvons-nous valider la connexion ? L’Ă©quipe peut choisir (mais ce n’est pas une obligation) d’opter pour une authentification paseto ou JWT, pour laquelle la fonctionnalitĂ© suivante, plus technique, pourrait ĂȘtre conçue :

Notez au passage comment notre user story initiale correspond Ă  trois fonctionnalitĂ©s Gherkin diffĂ©rentes. Il n’y a pas de correspondance entre les user stories et les fonctionnalitĂ©s Gherkin, sauf, peut-ĂȘtre, dans la phase initiale d’un projet. Les user stories sont un outil de planification alors que les fonctionnalitĂ©s Gherkin sont un outil de communication. Ils ne vivent pas sur la mĂȘme couche.

Nous pouvons imaginer toutes sortes de processus agiles / v-model / autres pour discuter de la spĂ©cification mise Ă  jour avec le client ou les parties prenantes et accroĂźtre la clartĂ© de la fonctionnalitĂ©. Il s’agit d’une communication commerciale de haut niveau sur ce Ă  quoi la fonctionnalitĂ© doit ressembler.

NĂ©anmoins, bien que nous puissions dire que nous avons clarifiĂ© ce qu’il y a Ă  faire, il est encore difficile d’estimer quand la fonction de connexion sera livrĂ©e, car nous n’avons pas encore rĂ©flĂ©chi Ă  la maniĂšre de la rĂ©aliser. Afin d’Ă©tablir cette estimation, mettons en Ɠuvre les tests ci-dessus. En effet, nous disposons maintenant de fichiers texte contenant la façon dont la fonctionnalitĂ© est censĂ©e se comporter. Pourquoi ne pas Ă©crire un code qui Ă©mulerait un manager essayant de se connecter Ă  son tableau de bord ? Lorsque l’Ă©quipe de dĂ©veloppement le fera, elle dĂ©couvrira les interfaces, les objets et les API de haut niveau avec lesquels elle doit interagir, ce qui permettra de dĂ©finir l’architecture globale de notre fonctionnalitĂ© de connexion. Comme l’Ă©crit Oncle Bob dans son livre Agile Software Development, Principles, Patterns, and Practices, « le fait de commencer par Ă©crire des tests d’acceptation a un effet profond sur l’architecture du systĂšme » (chapitre 4, « Testing »). C’est en quelque sorte le mĂȘme genre d’expĂ©rience que celle de l’oncle Bob et de Robert S. Koss dans The Bowling Game : An example of test-first pair programming, sauf que cette expĂ©rience se concentre sur les tests unitaires, donc sur les dĂ©tails d’implĂ©mentation, plutĂŽt que sur l’architecture globale du systĂšme. Selon la structure de votre organisation, l’ensemble de l’Ă©quipe, les architectes ou les chefs d’Ă©quipe Ă©criront ces tests pour prĂ©parer la planification. Ce faisant, ils tomberont sĂ»rement sur des surprises et pourraient mĂȘme mettre Ă  mal la fonctionnalitĂ©, afin d’acquĂ©rir les meilleures connaissances sur le sujet. Si nous pouvons Ă©viter un « poker » de planification (ou Ă©quivalent), nous rĂ©duisons considĂ©rablement le risque de tromper nos parties prenantes. Plus l’Ă©quipe obtient d’informations sur la mise en Ɠuvre, moins le poker sera risquĂ©.

Prenons un scĂ©nario simple comme exemple pour illustrer comment la spĂ©cification pourrait ĂȘtre liĂ©e au code de test. Supposons que nous voulions implĂ©menter

Scénario : Un JWT valide

Étant donnĂ© un utilisateur enregistrĂ©
Et l’utilisateur s’est connectĂ© avec des informations d’identification valides
Lorsqu’il valide son JWT
il obtient son identifiant d’utilisateur

Une implémentation possible en python pourrait ressembler à ceci (par exemple, avec la bibliothÚque behave) :

Ce code est le rĂ©sultat des dĂ©bats architecturaux de l’Ă©quipe. Les membres de l’Ă©quipe trouvent des compromis, recherchent des technologies et font des pointes, jusqu’Ă  ce qu’ils arrivent Ă  un ensemble complet d’Ă©tapes Gherkin implĂ©mentĂ©es dĂ©clenchant la mise en Ɠuvre la plus pragmatique, la plus minimaliste et la plus rentable des fonctionnalitĂ©s souhaitĂ©es.

L’extrait de code python ci-dessus utilise le logiciel que votre Ă©quipe va dĂ©velopper. Avant le dĂ©but d’une itĂ©ration de dĂ©veloppement, les scĂ©narios ne s’exĂ©cutent pas, en raison de l’absence d’implĂ©mentation. Au fur et Ă  mesure que le temps passe, de plus en plus de ces scĂ©narios Gherkin fournissent un feedback de rĂ©ussite. Lorsque l’Ă©quipe en a terminĂ© avec la mise en Ɠuvre, ce code fonctionne parfaitement et fournit une documentation vivante sur ce qui se passe dans le logiciel. Cette documentation est trĂšs puissante. Chaque fonctionnalitĂ© peut ĂȘtre fournie avec des dĂ©cisions architecturales, des croquis et un lien direct avec l’exĂ©cution d’un code productif.

Nous disposons dĂ©sormais d’une spĂ©cification et de ses tests sous-jacents. Notre Ă©quipe sait ce qu’ il faut faire et comment le faire. Lorsqu’elle exĂ©cute ces tests, elle sait Ă  quel point elle a progressĂ© vers son objectif. La planification / l’attribution des tĂąches est facile car les fonctionnalitĂ©s ont Ă©tĂ© affinĂ©es et mises en Ă©vidence. Si l’Ă©quipe de dĂ©veloppement met en Ɠuvre l’intĂ©gration continue, Rigor Mortis peut mĂȘme obtenir un retour d’information en direct sur la progression du dĂ©veloppement. Lorsque ses lutins sont en mission, il peut surveiller leurs activitĂ©s et avoir une meilleure idĂ©e de ce qu’ils font et de la façon dont ils le font, par exemple au moyen d’un tableau de bord du type suivant, qui serait mis Ă  jour Ă  chaque poussĂ©e de lutin vers la branche principale du rĂ©fĂ©rentiel :

pickles report on hidora website

Ce sont prĂ©cisĂ©ment les chiffres dont nous avons parlĂ© plus tĂŽt dans ce post. Le tableau de bord montre clairement combien de scĂ©narios sont rĂ©ussis, Ă©chouĂ©s ou non concluants. Nous pouvons mettre des chiffres sur la progression du dĂ©veloppement. Nous pouvons mesurer la quantitĂ© de logiciel fonctionnel que l’Ă©quipe a produit jusqu’Ă  prĂ©sent. D’aprĂšs les rĂ©sultats dĂ©crits par ce tableau de bord particulier, nous pouvons en dĂ©duire que l’Ă©quipe est bientĂŽt prĂȘte Ă  livrer les histoires d’utilisateur qu’elle s’est engagĂ©e Ă  livrer.

Il est assez facile de mettre en place ce reporting et cette documentation en direct. Par exemple, avec le serveur Gitlab de la place de marché Jelastic sur Hidora,

gitlab marketplace on hidora website

ou avec le remarquable Gitlab as a Service de Hidora, vous pouvez dĂ©finir des tĂąches de pipeline sur votre dĂ©pĂŽt qui effectuent les tests Gherkin, emballent leurs rĂ©sultats dans un fichier xml, gĂ©nĂšrent le rapport pickles et le publient d’une maniĂšre ou d’une autre. En supposant que vous disposez d’une image docker pouvant ĂȘtre extraite d’un registre docker, par exemple

vous pouvez par exemple complĂ©ter vos pipelines gitlab comme ceci dans .gitlab-ci.yaml pour un projet de test d’acceptation SpecFlow:

Le rapport pickles, ainsi que la spĂ©cification html dynamique pickles, peuvent ĂȘtre publiĂ©s sur une page gitlab comme dans l’extrait ci-dessus ou un conteneur docker qui peut ensuite ĂȘtre dĂ©ployĂ© sur votre cluster kubernetes, votre environnement Jelastic ou votre cdn.

DerniĂšres paroles

Pour en revenir Ă  la mĂ©taphore agile, j’espĂšre qu’il est clair pour toute Ă©quipe SCRUM que « Product Owner » est un synonyme de « M. / Mme Clarté ». Un PO doit avoir ses exigences claires comme de l’eau de roche avant de les remettre Ă  ses Ă©quipes de dĂ©veloppement pour la mise en Ɠuvre. En outre, pour Ă©viter les surprises Ă  la fin d’un sprint, un PO a besoin d’une mesure claire et en direct de la façon dont le sprint se dĂ©roule. Et un tableau d’Ă©puisement du sprint ne signifie absolument rien quant Ă  la quantitĂ© de logiciel fonctionnel que l’Ă©quipe a produit. Bien sĂ»r, ma suggestion ne permettra pas d’Ă©viter les Ă©checs Ă  tout moment, mais elle contribuera au moins Ă  rĂ©duire les Ă©checs et Ă  rendre les parties prenantes plus heureuses.

Par ailleurs, lorsque de nouveaux arrivants rejoignent votre Ă©quipe de dĂ©veloppement et que vous souhaitez qu’ils soient immĂ©diatement productifs, vous pouvez considĂ©rer les fonctionnalitĂ©s de Gherkin et les implĂ©mentations des Ă©tapes correspondantes comme une sorte de « bricolage » avec des conseils de haut niveau. Lorsqu’ils exĂ©cutent les tests des fonctionnalitĂ©s, ils obtiennent un retour d’information autonome sur l’Ă©tat d’avancement de leur mise en Ɠuvre. L’architecture globale a dĂ©jĂ  Ă©tĂ© dĂ©finie, le nouveau venu n’a plus qu’Ă  combler les lacunes par des dĂ©tails de mise en Ɠuvre. Il en va de mĂȘme lorsque vous devez dĂ©lĂ©guer le dĂ©veloppement d’un logiciel Ă  une sociĂ©tĂ© tierce. Au lieu de rĂ©diger de longs documents Word, vous pourriez essayer la mĂ©thodologie dĂ©crite dans ce billet. Le code ne ment pas et ne peut pas ĂȘtre mal interprĂ©tĂ©. Les documents Word peuvent l’ĂȘtre, surtout lorsque vous ĂȘtes, par exemple, une entreprise suisse qui rĂ©dige ses documents en anglais pour une entreprise de RĂ©publique tchĂšque. Dans ce cas, mĂȘme si tout le monde a un bon niveau d’anglais, les contextes culturels font qu’il est parfois difficile pour des personnes de diffĂ©rents pays de se comprendre clairement, ce qui transforme la dĂ©lĂ©gation du dĂ©veloppement logiciel en un jeu de chuchotements chinois.

Écrit par

Laurent MICHEL
17/11/2021

Product owner chez Softozor et client Hidora depuis 2017, utilisant le PaaS jelastic et le ci/cd gĂ©rĂ© gitlab pour rĂ©duire les frais gĂ©nĂ©raux d’infrastructure de leur plateforme e-commerce.

Recevoir nos actualités