Cet article propose de faire le tour des principales approches afin de comprendre non seulement comment elles s’écrivent, mais surtout pourquoi elles existent.

1. La User Story n’a jamais eu de format officiel

C’est probablement ma première surprise.

Le Guide Scrum ne parle jamais du format (« En tant que… Je veux… Afin de…« ). Il ne définit pas non plus ce qu’est une User Story.

Le guide décrit simplement le Product Backlog comme une liste ordonnée d’éléments représentant le travail nécessaire pour améliorer le produit. Ces éléments peuvent prendre différentes formes : fonctionnalités, corrections de bugs, améliorations techniques, recherches, expérimentations, etc.

La User Story est donc une pratique, pas une règle de Scrum, et change donc avec les pratiques, équipes et produits.

Son origine remonteraiy à Extreme Programming (XP), où Ron Jeffries la résumait par la règle des 3C.

La user-story XP (Extreme Programming) :

• Format card : une carte contenant quelques mots, pour encourager la synthèse
• Conversation : retrace les échanges entre les personnes concernées
• Confirmation : les critères permettant de vérifier que le besoin est satisfait sont indiqués

Autrement dit, la carte n’était jamais censée contenir toute la spécification. Elle servait avant tout à déclencher une conversation.

Au fil des années, d’autres approches sont apparues : Lean, Product Discovery, Design Thinking, SAFe, Kanban… Chacune a fait évoluer la manière d’exprimer un besoin.

C’est pourquoi il existe aujourd’hui une grande diversité de formats. Ils ne sont pas concurrents ; ils répondent simplement à des situations différentes.

2. Les grandes familles de User Stories

Il existe des dizaines de variantes. Ce tableau m’aide à comprendre dans quel contexte chacune apporte de sa valeur.

Ce tableau montre une chose essentielle : le choix d’un format dépend davantage du problème à résoudre que de Scrum lui-même.

Une équipe qui développe une plateforme SaaS, un logiciel métier ou un produit grand public ne rencontrera pas les mêmes besoins, elles n’utilisent donc pas exactement les mêmes formulations.

En réalité, il est rare qu’un Product Backlog ne contienne qu’un seul type de User Story. Une Story classique peut côtoyer un Spike, un bug ou une amélioration technique sans que cela pose le moindre problème.

L’objectif n’est pas d’uniformiser les intitulés, mais de rendre le backlog compréhensible et utile pour tous les acteurs du produit.

3. Qu’est ce qui compte réellement ?

À force de parler de modèles, il est facile d’oublier l’essentiel.

Une User Story n’a jamais eu vocation à devenir une mini-spécification fonctionnelle. Son rôle est plutôt de faciliter les échanges entre les personnes qui conçoivent, développent et utilisent le produit.

Qu’elle commence par « En tant que… », « Lorsque… » ou qu’elle ne suive aucun modèle particulier importe finalement assez peu.

Les questions les plus importantes sont :

• Le besoin est-il compris par toute l’équipe ?
• La valeur recherchée est-elle clairement identifiée ?
• Les critères d’acceptation permettent-ils de savoir quand le travail sera terminé ?
• La Story est-elle suffisamment petite pour être réalisée dans un délai raisonnable ?
• Favorise-t-elle les discussions plutôt que de les remplacer ?

Si la réponse est oui, alors la forme utilisée est la bonne.

En définitive, il n’existe pas une seule bonne manière d’écrire une User Story. Il existe des pratiques adaptées à des contextes différents.

C’est peut-être là la plus grande leçon à retenir : une User Story est un outil au service de la collaboration, pas un exercice de mise en forme. Les équipes les plus efficaces ne sont pas celles qui appliquent un modèle à la lettre, mais celles qui choisissent consciemment la manière de formuler leurs besoins pour mieux construire leur produit.

Une histoire d’expression du besoin ?

La première version de cette image date des années 70, paraît-il. Pourtant l’image ne vieillit pas, et reste tellement représentative de ce qui peut se passer durant la gestion d’un projet digital. J’ai vu …

• Un commercial et un technicien être d’accord et employer les mêmes mots pour décrire une fonctionnalité, mais être en désaccord total lors de la validation de celle-ci.
  Dialogue de sourds : le commercial indique que, non, ça ne fonctionne pas en toute bonne foi, le technicien répondant que, oui, tout fonctionne bien pourtant.

• Des commerciaux décrire la mécanique de précision d’un site à des clients (la pensée positive vous connaissez ?), alors que les enjeux stratégiques ne prévoyaient même pas d’explorer ce chemin.

• Des développeurs être impliqués à 300%, et pourtant livrer une balançoire à terre. Ils étaient déjà positionnés sur les starting blocks, ‘full-motivés’ à itérer une nouvelle fois pour le nouveau défi : relever la balançoire ! (lol)

• Le manque de temps, créant des spécifications dans lesquelles la balançoire est ‘peut-être un peu trop proche du tronc ‘, rendant l’utilisation quasi impossible et ‘poussant’ gentiment l’effort à l’équipe de développement. Dommage pour les dév …

• Je me rappelle des devis épais, impressionnants, colorés, mais peu personnalisés en fonction de nos différents projets.

• Et le client, avec un sourire béat, se balancer sur son nouveau jouet : la ‘balançoire-pneu’ !
  En dépit de sa demande initiale de balançoire à trois étages, la ‘balançoire-pneu’ reflétait totalement son originalité et lui allait si bien.

À qui la faute ? Biais cognitif ?

C’est facile de se dire que ‘l’autre’ n’a pas compris, ‘c’est normal, il n’y connaît pas grand chose ‘, qu’il n’a pas su écouter ou prêter attention, mais ça ne résout rien.

Alors comment faire ?

Chaque personne ‘imagine’ le projet à travers ses propres lunettes. Il ne s’agit pas de manque de connaissances, de compétences ou de communication, nous avons tous notre vécu et nos filtres d’interprétation : nos biais cognitifs.

Quelques pistes pour visualiser, clarifier et prioriser

• Avant de parler de fonctionnalités, quel problème résout-on ? Pour qui ?
• Quel changement CONCRET, PHYSIQUE doit-on observer comme preuve de résolution du problème ?
• Quels sont les objectifs de chacun des acteurs du projet et comment chacun comprend ces objectifs ?
• Quels sont les contraintes de chacun ?
• Quels visuels, maquettes rapides peuvent rendre visible ce que des mots peinent à montrer ?

On entend souvent qu’il faut plus ou mieux communiquer.
Là aussi, augmenter ou changer de communication ne sera pas déterminant tant que l’équipe ne travaille pas ensemble.
Il ne s’agit pas non plus de travailler constamment ensemble, mais plutôt de créer des plages d’ateliers aussi courtes que possible pour prendre le diapason et le temps de s’accorder.

Car un projet ne déraille pas faute de compétences.
Il déraille faute d’alignement.

Et l’alignement ne se décrète pas.
Il se construit, volontairement.

Kaizen ça veut dire quoi?

Une rapide recherche sur mon dictionnaire en ligne préféré m’indique que ‘kaizen’ est la fusion entre deux mots japonais : ‘kai’, qui signifie ‘changement’ et ‘zen’ ‘meilleur’. Mais encore?

Kaizen c’est quoi?

J’apprends aussi que que ce n’est pas un outil. Ce n’est pas une méthode ou une organisation prête à être reproduite. Le Kaizen est une philosophie dont le concept aurait été utilisé au sortir de la deuxième guerre mondiale, alors que le peuple Japonais avait à sortir la tête de l’eau pour penser à reconstruire.

Philosophie de la ‘corvée d’entraide’?

Cette philosophie / activité « s’apparenterait à la « corvée d’entraide », où un groupe d’individus s’entraide pour rapidement passer au travers d’une problématique. »

Et là mon imagination s’envole. Je vois ces jeunes étudiants (environ 8 ans) distribuer eux-même le repas dans leur classe à midi, chacun ayant un rôle, puis après avoir mangé dans la bonne humeur, ils débarrassent bols et miettes, balaient le sol, lavent les tables, font la vaisselle sans l’intervention du professeur.
Surprise par ces gestes, je ne comprends pas cette scène sur le coup.

J’image aussi une ville au sortir de la destruction d’une bombe, partagée entre pleurs, peurs, et l’envi de redresser la tête coute que coute pour demander à son voisin comment il va et lui porter secours. Je me demande : si chacun fait un geste pour tenter d’améliorer cette ville de gravas, à quelle vitesse la vie reprendrait?

Même si le Japon ne correspond qu’à 0,28 % de la superficie terrestre, le pays est le site de 18,5 % des séismes de magnitude 6 ou plus. Autant dire que tous les ans, chaque japonais subit plusieurs secousses dont la plupart laissent que peu de dégâts car le Japon a appris à vivre avec (constructions antisismiques, gestes de survie appris et répétés à l’école ou en entreprise, kit de survie obligatoire, éducation constante, …).
Tout ceci pour me rappeler la réalité des japonais : vivant sur plusieurs failles sismiques en activités, ils ont du s’adapter naturellement à leur milieu et pour s’en sortir sans trop de casse, chacun doit veiller sur son voisin, c’est-à-dire la société, au quotidien.

C’est sans doute ce que ces écoliers essayent de transmettre : apprendre la « corvée d’entraide », où comment un groupe d’individus s’entraide pour passer rapidement au travers d’une problématique.

Kaizen dans l’entreprise

La méthode ‘kaban’ et le diagramme de Pareto, utilisée entre autre dans la gestion de projet, seraient nés des antres de cette philosophie Kaizen.
Simplification des flux, amélioration de la qualité, amélioration des délais, amélioration de la productivité, amélioration des conditions de travail, cette philosophie sans âge pointe le bout de son nez dans tous les services d’une entreprise pour observer, reporter, agir.

Les détracteurs de cette méthode insisteront sur le fait que appliqué sans se pencher sur la pensée à l’origine du concept, l’entreprise s’automatise parfois en produisant plans, méthodes, tableaux, … oubliant peut-être parfois que seule la présence de tableaux et diagrammes se suffisent pas à faire entrer l’entreprise dans un cercle vertueux d’amélioration vers le succès.

Kaizen? Laisser l’homme observer et agir

L’essence du Kaizen est au delà de la méthode. C’est une production humaine et douce qui consiste à apporter de petites améliorations tous les jours de manières constante et avec une volonté inébranlable afin d’atteindre la perfection, en prenant le risque de ne jamais l’atteindre et de toujours améliorer.
Ce n’est pas un travail. Ça ne se compte pas en heure mais peut-être en minutes que chacun pourra exploiter demain, après-demain, dans 10 ans, … créant de vrais changements humains sur le long terme.
On peut l’utiliser en entreprise, mais pour que cet esprit soit installé dans un service, c’est qu’il aura d’abord eu une valeur personnel importante.
La question a se poser est alors comment donner l’information aux individus afin d’adhérer (ou non) à ce principe de vie? Ou comment développer l’esprit Kaizen au delà de la méthode?

Concrètement, ça peut être de ne pas s’attacher aux plans ou tableaux d’hier s’ils ne servent pas et les reconstruire aujourd’hui, si notre emploi du temps le permet, pour voir s’ils peuvent être plus utile.
Ou s’assoir sur le murée d’en face, lever son nez, observer son environnement, dire bonjour à son voisin et finir par avoir une conversation passionnée sur l’utilisation des gants sur son poste de travail.
Une à une, à la vitesse d’un goutte d’eau qui rempli l’océan. Rien de plus mais tout est dis.

Les 10 règles Kaizen à méditer

Mazaaki Imai diffusa les règles de Kaizen dans ces deux livres ‘Kaizen’ et ‘Gamba zaizen’ (1997). Il y définie 10 règles Kaizen comme clé du succès à long terme, toutes à méditer avant d’en saisir le sens et domaines d’application.
Une d’entre elle vous fera peut-être sourire vous rappelant une sagesse interne oubliée. Ma règle du moment est la numéro 3 : tellement vrai.

1. Osez remettre en question les pratiques actuelles
2. Voyez comment réussir un projet plutôt que de dire que cela ne fonctionnera jamais
3. Il ne faut jamais chercher des excuses à un problème et encore moins des coupables mais remettez les pratiques actuelles en cause
4. Ne visez pas la perfection du 1er coup, mais cherchez simplement l’amélioration
5. N’attendez pas pour corrigez les erreurs, il faut réagir dès qu’elles apparaissent
6. Prioriser les solutions qui ne nécessitent pas d’investissement
7. Même si cela fonctionne bien, cherchez des idées pour toujours améliorer votre travail
8. Identifiez la cause première de votre problème et posez-vous la question « pourquoi » 5 fois de suite
9. Avant de prendre des décisions, demandez les idées de 10 personnes plutôt que le savoir d’une seule
10. L’amélioration est infinie

Pourquoi un certificat SSL?

Le certificat SSL est un protocole pour sécuriser les données sur les serveurs. Cette certification sera à demander auprès d’une société tierce, et ce n’est qu’une fois installé sur votre serveur et votre site configuré, que vos visiteurs bénéficieront du fameux https sécurisé.

Le moteur de recherche Google a largement contribué à sa généralisation. Les sites e-commerce ou entreprises gérant des données très sensibles se sont aussitôt penchés sur le certificat SSL et la migration de leurs sites en https. On pouvait alors reconnaître les sociétés ayant fait le pas en examinant la forme de l’url dans le navigateur.

On trouve encore certains sites en http mais ils se font rares car le moteur de recherche, leader incontournable, Google accorde des points négatifs qui ont un impact handicapant pour le référencement naturel (SEO).
Vous avez certainement déjà atterri sur une page comportant un horrible message ‘Échec de la connexion sécurisée’ : la porte d’entrée d’un site sans SSL ressemble à ça.
Pour résumer, pas de certificat SSL, et vous n’existez plus face à vos concurrents.

Il existe plusieurs types de certificats

Très souvent, les hébergements de sites web sur serveur mutualisé, inclut (ou propose) un certificat SSL. Si vous gérez vous-même votre serveur, il faudra installer le certificat par vous même.

Comme rien n’est simple en matière de web (c’est bien connu ), plusieurs types de certification s’offrent à vous. Les trois premiers facteurs pour faire votre choix seront sans doute le prix, le niveau de sécurité nécessaire, le niveau technique dont vous disposez.

Que valent les certificats gratuits?

Notons que certains certificats sont totalement gratuits. Il s’agit de Let’s encrypte et de Cloudflare (octobre 2020).
Inutile de paraphraser l’article très clair de www.tophebergeur.com/tutoriels/seo/https-traditionnel-letsencrypt-cloudflare qui détaille bien les différences. Mon but ici est de résumer et de faire écho. N’hésitez pas à faire un tour sur le site lorsque vous aurez besoin de plus de renseignements ou d’une comparaison avantages/inconvénients des certificats payant / gratuit Lets’ encrypte / gratuit Cloudflare.

Pourquoi pas Cloudflare ?

Pour un grand nombre de blog ou de site ‘vitrine’ ne proposant pas d’ouverture de compte, d’achat en ligne, le certificat Cloudflare peut largement suffire. La procédure est simple mais elle demandera de respecter 3 étapes : créer un compte Cloudflare et demander son certificat; attendre que votre site soit ‘reconnu’ par Clouflare; télécharger le plugin WordPress ‘Really simple SSL’ et le configurer. (j’ajoute en fin d’article des vidéos qui m’ont accompagné pour l’installation).

Je résume ici les avantages du certificat Cloudflare :

• Gratuit,
• Rapide à mettre en place, pas tracas de configuration,
• Certificat sans durée de vie (90 jours pour let’s encrypte; ou 1 an pour les certificats payants), dont pas de renouvellement à programmer,
• Optimisation du chargement des pages de VOTRE site à travers l’auto-minifier JS, CSS et HTML que propose Cloudflare,
• Une sécurité pour des blogs et sites ‘vitrine’

Ressources pour l’installation de Cloudflare

Ces vidéos pourront aider à installer le certificat (bah oui, moi je partage, moi!). Ces deux vidéos se complètent pour une installation de a à z. (et j’ajoute à ma to-do list : ‘trouver comment faire un tuto vidéo’).