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