Pyxis

Sprint planning

L’équipe commence à être efficace durant la planification de l’itération, j’ai moins à intervenir! En tant que tel, je trouve que c’est une bonne chose. Ca me fait penser que mes interventions précédentes ont porté fruit et que l’équipe devient indépendante. Du moins pour cette cérémonie…

Backlog maintenance

L’efficacité de l’équipe se propage aux autres cérémonies. Cette séance se déroule avec très peu d’interventions de ma part. Les membres de l’équipe discutent entre eux du contenu des stories, posent des questions au PO et s’entendent généralement, en 2 tours de planning poker, sur le pointage à mettre sur une carte. On pourrait penser que s’est une équipe formée depuis longtemps et qu’ils sont tous habitué de travailler ensemble.

Il reste un point qui risque de devenir problématique, le backlog n’est pas très garni. Ce qui fait qu’il n’y a pas de stories, ou même d’epics, d’avance pour les prochaines itérations. L’engagement de l’équipe pour la prochaine itération risque d’être limité par le contenu du backlog. Il y a de la sensibilisation à faire auprès du PO. À suivre…

Sprint review

Une autre review qui va bien! Cette fois, par contre, il n’y a que le patron du PO qui est présent, l’utilisateur n’est pas là. Ca n’empêche pas à l’équipe de recueillir tous les points auxquels elle était engagée. La patron pose quelques questions et semble satisfait. C’est une review express qui se déroule rapidement, mais ca n’empêche pas que tout le monde est content du résultat.

Sprint retro

Les membres de l’équipe s’attendaient à la formule des 2 sprints précédents; identifier les points forts et les points à améliorer. Un membre me demande en blague « C’est maintenant qu’on chiale ? ». Je lui réponds avec sourire que non, ce n’est pas aujourd’hui! J’ai autre chose de prévu. J’ai constaté que les membres de l’équipe travaillent beaucoup selon leurs spécialités respectives. Je pense que ca a un impact sur le déroulement des itérations, certains membres sont un goulot au début de l’itération et d’autres vers la fin. C’est un signe! Je questionne l’équipe sur le potentiel de travail de façon multidisciplinaire. Ils semblent s’opposer à ma proposition. Je comprends par leur réaction qu’ils ne sont pas contre, c’est qu’ils ne comprennent pas la même chose que moi. Ils entendent que tous les membres de l’équipe atteignent un même niveau d’expertise dans tous les domaines et que chacun peu faire le même travail au même niveau d’efficacité et de qualité. Ouf, je comprends qu’ils s’opposent. Ce que j’entends est plutôt que chacun peut faire du travail qui relève d’une autre discipline, ceci pour s’assurer que l’itération avance bien lorsque qu’un spécialiste n’est pas disponible (avec la saison des vacances qui approchent, ca va rapidement devenir une réalité!).

L’équipe me trouve dur avec mes questions, ils suivent quand même bien l’exercice de rétro. Il faut un peu d’encouragements de ma part, mais les équipiers finissent pas adopter l’idée de travailler en paire interdisciplinaire pour mieux partager la connaissance. On verra à la prochaine rétro comment ils ont apprécié l’expérience.

Sprint planning

J’apprends que le patron du PO a vraiment apprécié de participer à la review de la semaine dernière. Il veut être invité encore à la fin du sprint présent. C’est une bonne nouvelle!

Pour débuter, j’explique à l’équipe qu’à la dernière itération ils ont réussi à réaliser 4 points de story. En principe, ils devraient aussi être capable de réaliser 4 points à cette itération. À la review de l’itération 1, une story a été refusée par le PO. Je me souviens qu’ils étaient convaincus qu’il ne restait que peu de temps à faire pour la compléter. Alors, l’équipe pourrait s’engager à faire 6 points. Aahhhh! Soulagement collectif. Ils n’avaient pas bien compris qu’ils pouvaient s’engager à plus. L’équipe regarde le backlog, est confiante et s’engage à réaliser 10 points. J’aime ça les équipes optimistes!!

Backlog maintenance

Avant de débuter la séance, nous avons une petite discussion à propos d’une situation « particulière ». Le patron du PO ne peut pas être présent pour la review et demande à l’équipe de faire la présentation à un autre moment pour qu’il puisse y assister. Après discussion au sein de l’équipe, les membres proposent d’échanger les séances de planning et de review. Ai-je bien compris ? L’équipe veut s’engager sur le prochain sprint sans connaître le résultat du sprint actuel ? Il semble que j’avais bien compris… L’équipe justifie qu’elle se sent en confiance de réussir l’engagement et qu’il n’y aura pas de problème. Même si l’équipe ne réussi pas, les membres considèrent l’impact mineur. J’ai fait part de mes réserves, l’équipe connait les conséquences potentielles. Je leur laisse maintenant la décision.

Le backlog n’est pas très garni, ça a comme conséquence que peu d’items sont estimés. Nous avons prévu deux séances de backlog maintenance pour cette itération, pour permettre au PO de rédiger d’autres stories. Pour la séance de ce matin, l’équipe a réussi à estimer 4 stories. Ça ne semble pas beaucoup, mais les discussions entourant les stories étaient intéressantes. Elles ont permis de faire diviser une story en deux, afin de réduire la complexité, de clarifier des éléments et faire ressortir des points que le PO doit éclaircir pour la prochaine séance.

Sprint review

Comme au sprint 1, des intervenants ont assisté à la review. Il y a 3 stories à présenter et le résultat d’un spike. Le PO a pris contrôle du clavier dès le début de la séance. Première story à démontrer; le PO commence à faire le tour des écrans pour valider l’information transmises. Il ressort tranquillement qu’il n’est pas prêt pour la review, il cherche un peu quelles données utiliser et où sont certaines informations. Je prends note que je devrai un peu mieux accompagner le PO pour qu’il se prépare pour la review. Les membres de l’équipe semblent aussi l’avoir remarqué. Je ne serai pas seul à en parler au PO…

Sprint retro

Pour cette deuxième rétro je préfère rester au niveau des processus. Alors je garde une formule assez traditionnelle de faire ressortir les points forts et points à améliorer. J’oriente par contre la discussion autour des cérémonies de Scrum; planning, backlog maintenance, review, retro et le déroulement général des itérations. Des bons points ressortent sur les différentes cérémonies. À l’opposé, l’équipe trouve que la mêlée quotidienne est inefficace; les membres de l’équipe communiquent beaucoup et se synchronisent près du tableau de tâches à chaque matin avant l’heure de la mêlée, alors ils ont le sentiment de se répéter. Pourtant, à quelques reprises durant la mêlée quotidienne, d’après la réaction de certains autres membres face à la réponse à « Qu’as-tu accompli hier? », j’ai senti que de l’information nouvelle circulait dans le mêlée. Elle n’est peut-être pas efficace, mais elle semble utile!

Il y a un auditoire pour le premier sprint review, le patron du PO et un utilisateur expert sont présents. C’est encourageant!

Au début du sprint, l’équipe s’était engagée à livrer 3 stories, il y a 3 stories a démontrer. Bon départ! Un membre de l’équipe se prépare à démontrer le contenu de la première story. Je me permet d’intervenir et suggère que le PO prenne plutôt le clavier pour expérimenter lui-même le système et qu’il tente d’accomplir ses vérifications des stories (les conditions d’acceptation). Il vérifie la première story. Ca va bien! Les intervenants présents posent des questions. Il y a interaction entre les personnes présentes et ca sent l’intérêt envers la story livrée. Le PO navigue dans le système et confirme que le comportement est bon. Story acceptée. On passe à la deuxième story. Il y a autant de discussions dans la salle. On se rend compte qu’une règle n’est pas complètement respectée. Le PO hésite un peu, mais refuse la story. L’équipe est mécontente. « Ce n’est qu’un petit bug, on en a pour 30 secondes à le corriger, on pourrait quand même avoir 1.8 points (sur les 2 points que valait la story) ». Je fais mon méchant et je dis non; la story est refusée alors l’équipe n’obtient pas les points associés à cette story. L’équipe n’est pas contente! Je vais expliquer le principe plus tard, maintenant on termine le sprint review. Pour la dernière story, ca se déroule bien, les discussions continuent et le PO accepte la troisième story. L’équipe a réussi à livrer 4 des 6 points engagés. Ils gardent un mauvais goût de s’être vu refusé une story pour si peu. De mon côté je me dis que c’est l’apprentissage qui débute!

Release plan

Durant le sprint 0, une seule epic avait été estimé. Alors une première version d’un release plan a été fait avec une hypothèse farfelue. Elle est farfelue, mais avec l’information que nous avons à ce point du projet, c’est la meilleure que j’ai trouvée.  Mon hypothèse est que toutes les epic ont la même complexité (en considérant que même s’il y en a des plus petites, il y en aurait des plus grosses, donc le tout s’équilibrerait). Dans notre cas, la somme des valeurs des stories qui composent l’epic est 31 points. En faisant des calculs savants de conversion de points en heures selon le découpage en tâches des stories, ça mène à une date de fin potentielle à la mi-juin 2011. Nous allons voir avec le temps si mon hypothèse tient moindrement la route…

Une livraison “pilote” dans un certain nombre de magasins (1 à 3, le nombre reste à déterminer) est prévu pour la fin de l’année 2010. Alors une deuxième itération sur le release plan est nécessaire pour vérifier ce qui peut être réalisé pour le pilote. Une nouvelle estimation des epic est faite en les comparant à la première (celle-ci a été développée durant la première itération). Pour faire la ré estimation, la première epic a été considérée comme un 5, ensuite les autres ont été estimée selon l’échelle de presque Fibonacci habituelle. En refaisant encore des calculs savants, le release plan a été révisé pour mener la fin potentielle du projet vers la mi-mai 2011*, et anticiper que le pilote est réalisable pour le début décembre. Il faudra sûrement jouer sur l’étendue de l’epic, c’est à dire sur les éléments qui composent les epic “essentielles” pourront être livrées pour le pilote.

* l’hypothèse farfelue du départ ne semblait pas être si farfelue puisque la date de fin n’a bougée que d’un mois, ce qui ne me semble pas significatif comme changement.

Pour terminer, nous avons mis sur une échelle du temps la date où certains dépendances externes (interactions avec des systèmes externes) devraient être abordées/mis en place, ceci afin de ne pas risquer les dates anticipées.

Backlog maintenance

Le PO a rédigé quelques stories et bougé des priorités dans le product backlog. L’équipe doit maintenant estimer ces nouvelles stories. Nous avons 4 stories d’estimées (3 qui ont été développées durant la première itération, et 1 non amorcée) qui serviront de base de référence pour les nouvelles estimations.

Je laisse l’équipe estimer 4 stories avant de leur faire part d’une inquiétude. La première itération contenait 6 points. Les nouvelles stories estimées sont de 5, 13 ou 20 points. En principe, ces stories ne pourront donc pas être réalisées durant une itération puisqu’elle dépasse la capacité de l’équipe. On arrête pour une quinzaine de minutes la maintenance pour discuter de la taille des stories et voir si elles peuvent être découpées en plus petites. Le PO dit que les stories ne peuvent pas être découpées plus parce que (par exemple) “une commande ne peut pas être exécutée complètement si on n’a pas les SKU et les items”. D’accord! On discute pour voir si on peut quand même le découper en 2, question de diminuer le risque. Pas certain. Pour ne pas détourner l’objectif du backlog maintenance trop longtemps, la discussion sur le découpage des stories est reportée. On continue à estimer des stories restantes. Même si on n’a pas complètement conclu le sujet, la discussion a portée fruit; on se question si on peut découper les stories suivantes lorsqu’elles semblent un 5 ou plus. Aussi, une nouvelle story est rédigée pour traiter un cas plus spécifique, réduisant ainsi la taille d’une story du PO.

Il y aura de travail à faire avec le PO pour qu’il écrive plus de stories qui sont réalisables dans une itération. Il pense qu’il y a assez de travail pour occuper l’équipe pendant plusieurs itérations, alors ce n’est pas nécessaire d’ajouter des stories. La logique n’est pas fausse, mais la faille est que le travail semble trop gros pour être réalisé dans 1 itération. Si les stories restent de cette taille, elles ne seront que partiellement développée durant une itération. L’équipe s’est d’ailleurs questionnée sur la durée des itérations (présentement 2 semaines). Nous allons probablement (si l’équipe veut aborder le sujet!) en rediscuter durant la rétro d’itération.

Le premier sprint n’aura pas sa pleine capacité puisque des membres doivent terminer des assignations sur d’autres projets ou seront absents. Malgré ceci, la capacité du sprint n’est pas trop handicapée, principalement parce que le sprint comporte 2 jours calendrier de plus. L’équipe a choisi ainsi pour que les sprints débutent le lundi et se terminent le vendredi. Comme l’équipe n’a pas rédigé beaucoup de stories, elle prend presque toutes celles rédigées durant le sprint 0 pour le sprint 1, et y ajoute 2 spike. Même si théoriquement la sommes des heures estimées peut être fait durant le sprint 1, l’équipe n’est pas confiante de pouvoir tout réaliser les stories correspondantes. Finalement, peut-être que les estimations n’étaient pas aussi bonne qu’elles en avaient l’air… Alors l’équipe laisse une story de côté. Il l’amorceront s’ils ont assez de temps.

La pression est beaucoup sur le PO qui devra rédiger beaucoup de stories pour remplir le backlog, sinon le sprint 2 sera mince.

Pour la deuxième partie du planning, l’équipe discute de détails plus technique dont la mise en place des environnements nécessaires. L’équipe sent qu’elle a assez d’information pour débuter, alors on applique de façon collective la loi des 2 pieds!

L’équipe semble déjà prendre des bons plis. Au diner, il y avait 3 membres de l’équipe, le ScrumMaster et moi. Le bureau du ScrumMaster est physiquement dans un autre édifice que le reste de l’équipe, alors les membres de l’équipe ont lancé au ScrumMaster “Pourquoi tu ne demandes pas que ton bureau soit amené avec nous?” J’aime ca!

jour 3

Malheureusement, je ne peux être présent pour cette 3e journée. L’équipe procède quand même au découpage des items du backlog.

jour 4

Dernière journée du sprint 0. Une grosse journée en perspective. Seulement 1 story du backlog est découpé en tâches et il y en a très peu d’écrites (3 ou 4 autres stories). Selon le plan initial, il nous reste à faire le release plan, un plan d’actions pour les risques, la définition de terminé et la rétro du sprint 0. Tout ça et il n’y a pas assez d’éléments du backlog de découpés pour remplir le premier sprint!! Je propose de modifier le plan de la journée et de travailler à remplir le backlog. Sans ça, on ne pourra pas vraiment (pas du tout même) débuter le sprint 1. Le release plan et le plan d’actions sont repoussés dans l’itération 1 comme des tâches non-fonctionnelles. Je suis conscient que cette proposition n’est pas idéale, mais c’est le mieux qui me vient à l’esprit pour que l’équipe ait des stories à sprinter.

On prend donc les stories écrites. On s’assure de bien comprendre la portée et les conditions de succès. Puis on les place à mesure sur la table selon leur complexité relative aux autres stories déjà décrites. Ça combine en quelque sorte la compréhension de stories par l’équipe et le “wall/table poker planning”. L’équipe n’a pas de difficulté à placer les stories en relation entre elles pour évaluer la complexité relative. Lorsque c’est terminé, je place alors au hasard des points sur les stories, ce qui donne 1,2,3,5 et 8 comme pointage. L’équipe est assez confortable avec ces pointages, sauf pour le 8. L’équipe propose que cette story est plus que 2 fois plus complexe et comporte assez d’inconnu que celle qui est à 5. Le 13 ne suffit pas, alors on la met à 20. Wouah! Ensuite, le découpage des stories en tâche débute. D’abord par celle qui vaut 1, puis 2 et ainsi de suite. Celle de 20 n’est pas touchée. Selon le découpage en tâche, on arrive à une approximation que 1 point = environ 16 heures. Ah! d’accord.

Enfin le lunch! Ça va faire du bien!

Au retour, l’équipe se détermine une définition de terminé. Je la trouve correcte. Pas trop ambitieuse, mais suffisamment d’éléments pour qu’on sente qu’ils mettent de la qualité. C’est à ce moment que l’équipe demande, est-ce que les tests intégrés, je fais une tâche ou ça va dans la définition de terminé ? J’ai le goût de répondre simplement: oui! Hélène sent mon ambivalence et lance une chanson (elle n’a pas vraiment chanté, mais ça aurait pu) “Write it until it’s a habit”; comprendre “faites-en un tâche jusqu’à ce que ca devienne une habitude (mais mettez-le aussi dans la définition de terminé – ceci est en sous entendu)”.

Comme tout au long du sprint 0, l’équipe se pose des bonnes questions, auxquelles j’ai assez souvent une suggestion de réponse. Dans les cas incertains, je fais un Éric Laramée de moi-même et je réponds “ça dépend” et à ce moment, quelqu’un de l’équipe propose quelque chose qui fait ressortir un élément de réponse intéressant.

Enfin durant la rétro du sprint 0, il ressort que :
points positifs

• l’utilisation d’un taskboard pour gérer les taches du sprint 0 est efficace et utile
• assigner un timebox en avance sur les éléments facilite l’avancement
• l’équipe a une bonne idée du projet grâce aux épics
• une bonne chimie de groupe est déjà présente dans l’équipe
• utile de mettre immédiatement en pratique les notions de Scrum par la pratique

points à améliorer

• il n’y a pas de date de release à présenter au patron du PO
• l’équipe part facilement dans des discussions un peu à côté du sujet – le modérateur ne modère pas assez!
• peur de perdre les cartes et post-it des stories, aurait préféré écrire tout dans Excel
• sprint 0 un peu une perte de temps (pour l’analyste et le PO) parce que ce sont tout des éléments qui étaient connus

questions sans réponse

• quel outil utiliser pour gérer tout ça
  • Urban Turtle (puisqu’ils ont un environnement TFS)
  • Excel devrait suffire aux premiers sprints, on réajustera quand on sentira des douleurs

On amorce la deuxième journée avec un absent. Un développeur a eu un feu à son domicile, il sera absent pour la journée et probablement une partie de la semaine prochaine. On pense à lui.

Nous débutons en retournant au backlog pour découper les epics. Je ne veux pas tout de suite les transformer en stories, je tente d’amener à découper en étapes. La première epic attaquée est “Charger les informations de base”. Selon le PO, les étapes à suivre sont très techniques, du style “prendre tous les produits du système X et les amener dans le système Y”. Ouff! En creusant, on se rend compte qu’il y a trois types de chargement possible; initial, mise à jour et automatisation. Plus tard, un quatrième apparait; synchronisation. À ce point, le découpage manque de détails, mais à force de discussion, après 1 bonne heure, on réussit à écrire la première story accompagnée de ses conditions de succès. La deuxième story suit dans l’heure suivante. Sur ce, l’avant midi prend fin. Je suis plutôt satisfait, l’équipe a sorti 2 stories et des règles d’affaire qui semblaient évidentes ont fait surface; par exemple quand le PO parle de charger “tous les produits”, ça ne veut pas dire tous les produits, mais bien tous les produits d’un certain type et qui sont actifs. Quand même une distinction intéressante.

Durant l’avant-midi, la patron du PO est passé faire un tour dans le local du sprint 0. Son arrivée correspondait pas mal au moment de prendre une pause, alors il n’a pas vraiment interrompu le déroulement. Une chose intéressante s’est produite, il a regardé le backlog, a discuté avec le PO et ils en sont venu à modifier la valeur/priorité associée à certains items du backlog. Wouhou! C’était des items au bas du backlog, alors ça n’a pas eu d’impact sur les items en cours de travail, mais c’est quand même beau de voir cette collaboration. Ceci a soulevé l’importance, pour moi, que le PO discute avec les intervenants du projet de façon régulière, avant de faire un planning, pour s’assurer qu’il apporte vraiment la valeur attendue pour le projet.

Au retour du diner, nous décidons comment nous allons gérer les autres jours du sprint 0. Étant donné le congé de Pâques qui tombe en plein milieu. Certaines personnes sont en congé vendredi, d’autres lundi. Ce n’est pas idéal selon moi, on fait une pause jusqu’à mardi (4 jours d’arrêt, incluant la fin de semaine). Une fois ceci clarifié, on se lance dans les règles d’équipe. Ça se passe assez bien. L’équipe hésite sur les timeboxes à se donner et se fie pas mal sur nos recommandations. Ils ne se donnent pas trop de règles autres que ce qui entoure les cérémonies de Scrum et se laisse de la place pour en découvrir durant l’itération (qui durera 2 semaines).

En fin de journée, il reste un petit peu de temps. J’en profite pour faire un petit rappel sur ce qu’est la dette technique. Ceci pour préparer l’équipe si elle décide de composer sa définition de terminé mardi. J’ai pris cette avance, parce que (autre chose que ne me plait pas) je dois être absent du sprint 0 mardi. L’équipe va quand même continuer, mais pour cette journée elle sera coachée par Hélène. En principe, l’équipe va continuer à découper le backlog et Hélène se sent en confiance pour cette partie.

J’ai récemment débuté un mandat d’accompagnement d’une équipe, travaillant pour un fournisseur de pièces automobiles, vers une transition agile. Je rédige un carnet résumé de mes interventions afin d’avoir une base de référence pour mes prochains mandats. Maintenant, quoi de mieux comme apprentissage que de partager ces carnets et pouvoir obtenir des commentaires.

Sprint 0 jour 1

La journée débute et je suggère certains livrables à accomplir durant le sprint 0 (et l’équipe décide combien de temps elle s’alloue).

Je propose de réaliser:

• Charte de projet (2h)
• Product backlog (11h)
• Règles d’équipe (2h)
• Définition de terminé (3h)
• Release plan (3h)
• Planifier le sprint 1 (hors portée)
• Rétro du sprint 0 (2h)

L’équipe préfère ne pas faire la planification du sprint 1 durant le sprint 0. Elle préfère plutôt faire une séance de planning “normale” la première journée du sprint. D’accord!

Hier nous (moi, grandement supporté par Éric Laramée) avons donné Scrum par la pratique. L’équipe a, entre autres, retenu qu’une journée réelle de travail était de 5 ou 6 heures, pour laisser du temps pour la routine administrative. Ils ont bien retenu ceci et compte des journées de 6 heures pour le sprint 0. Suite à ceci, il est décidé de faire un sprint 0 de 4 jours et de limiter le temps des activités.

Une partie de la charte de projet est maintenant rédigée (le release plan viendra plus tard dans le sprint 0), les risques et les objectifs du projet sont clarifiés:

1. Avoir la bonne information, au bon moment, afin de centraliser les achats des magasins.
2. Avoir l’information nécessaire afin de suivre mes indications d’inventaire sur tous les produits (locaux et nationaux)
3. Intégrer les données magasins aux outils d’analyse existants (Cognos, cube, etc.)

Nous en profitons à mesure pour établir un glossaire. Pour l’instant ce sont principalement des explications d’acronymes.

En après-midi, le PO nous parle plus en détails de ses objectifs. Ceux-ci sont transformés en epics. La journée se termine sur ceci.

Objectif pour demain; petite présentation sur les user stories, découper les epics et avoir une première estimation d’éléments du carnet de produit.

Dans le cadre de notre atelier Simulation Scrum avec prototypage papier à Confoo, 17 participants ont produits un incrément de logiciel en 2 heures. Ceci en s’amusant!

Dans cet atelier, Nicholas Lemay et moi avions comme objectif de présenter Scrum et le prototypage papier. Même plus! L’objectif était de faire connaitre Scrum en mode condensé et d’utiliser le prototypage papier comme livrable des itérations. Les participants ont pu découvrir la force des prototypes papier comme outil de communication, de modélisation d’un logiciel et ce, sans même avoir à écrire une ligne de code.

Durant les 2 heures de l’atelier, les participants ont prototypé, communiqué, fait avancer les concepts d’interfaces utilisateurs et validé le résultat de leur itération à travers des mini tests d’utilisabilité. À la fin des 2 itérations, les membres des équipes avaient une compréhension commune du concept en cours et avaient amélioré les fonctionnalités offertes par les prototypes qu’ils ont réalisés.

Est-ce qu’on peut en dire autant d’une équipe qui aurait tenté le même exercice en codant des interfaces fonctionnelles ou même en prototypant avec Photoshop ?

Curieux de voir les bénéfices du prototypage papier en action dans votre organisation ? Vous avez envie de vivre un atelier similaire avec votre équipe de travail ? Contactez-nous!

Le Texas Hold’em Poker est très à la mode, et je n’ai pas pu résister à la tentation de m’inscrire à PokerStars. J’étais tellement motivé de m’inscrire que j’ai passé par dessus le piège que m’a tendu PokerStars : “* – Optional fields”.

Les champs optionnels sont marqués d’un astérisque alors que le standard est plutôt de marquer ainsi les champs obligatoires. En respectant mes habitudes, j’ai d’abord rempli tous les champs marqués d’un astérisque. C’est seulement à l’affichage d’un message d’erreur me demandant d’inscrire une ville que j’ai réalisé qu’ils brisent le standard.

Auriez-vous fait la même erreur dans le même contexte?