Bienvenue dans un autre épisode d’Armchair Architects dans le cadre de l’émission Azure Enablement. Alors aujourd’hui on va parler de quelque chose d’un peu théorique. Nous allons parler de la relation entre l’architecture et l’ambiguïté. Que faites-vous lorsque les spécifications ne sont pas entièrement claires ou que les plans ne sont pas entièrement clairs ? Ce dont les gens ont besoin n’est pas tout à fait clair ? Nous allons en discuter avec nos architectes.
Il n’est pas rare que les gens viennent aux architectes avec des déclarations très vagues ou des questions qui ne sont pas vraiment précises. Ou un problème doit être résolu, mais il n’est pas vraiment clair de quoi il s’agit.
Que peuvent faire les architectes pour remédier à l’ambiguïté ?
Selon la profondeur de votre expérience, vous devez être plus à l’aise avec l’ambiguïté. Je pense qu’en tant que « répondeurs », notre objectif est d’éliminer l’ambiguïté. Cela nous met mal à l’aise et la meilleure chose que nous puissions faire pour éliminer l’ambiguïté est de faire une hypothèse et d’y répondre, parfois dans le même souffle. Et c’est là que je pense que le terme “fausse précision” apparaît vraiment.
Vous donnez une réponse très précise à une question qui, selon vous, éliminera l’ambiguïté en fonction du système logiciel que vous essayez de construire. Et je pense que nous avons tous fait partie d’un projet logiciel dans lequel vous construisez cette incroyable merveille d’ingénierie technique, puis vous enlevez les couvertures, mais le client dit que ce n’est pas ce à quoi il s’attendait. Vous avez fait quelque chose de complètement différent et vous avez dit, eh bien, voici toutes nos hypothèses. Pourquoi avez-vous fait ces suppositions ? La fausse précision est donc un moyen d’extirper l’ambiguïté de manière incorrecte et parfois nuisible. Mais le meilleur conseil que je puisse donner est simplement d’être à l’aise avec cela, mais de chercher à le comprendre et à l’exciser au fil du temps.
Mais on pourrait dire, n’est-ce pas ce qu’Agile signifie ? N’est-ce pas ce que Agile est censé résoudre ? Où vous formulez un problème de vision North Star, puis vous vous y frayez un chemin en utilisant des artefacts de code et, idéalement, en impliquant les utilisateurs tôt dans ce genre de choses ? N’est-ce pas un problème résolu ?
C’est exactement là où nous devons nous diriger dans cette conversation. Ne soyez pas dans un sous-marin d’attaque. Ne collectez pas une petite quantité d’informations, puis n’allez pas sous l’eau, puis naviguez autour du monde et faites surface en disant : « Ta-da. J’espère que c’est génial. Définissez en permanence des attentes, supprimez l’ambiguïté via des sprints de développement et supprimez l’ambiguïté via des pics. Continuez à vous concentrer sur les résultats et la raison pour laquelle vous construisez la plate-forme logicielle. Ce sont les choses qui, je pense, vont vous aider tout au long de ce voyage. Et puis chuter continuellement dans un cycle Agile.
Pourquoi n’est-ce pas un problème résolu ?
Je pense qu’il y a deux éléments à cela. L’un est une personne ou une chose de personnes. Cela signifie que si vous êtes une personne qui aime la certitude, alors entrer dans une situation ambiguë peut être stressant. Vous ne savez vraiment pas comment gérer cela, et je pense que c’est quelque chose auquel vous devez penser lorsque vous êtes architecte. Vous devez être à l’aise avec l’ambiguïté et si vous ne pouvez pas l’être, alors vous devez trouver comment apprendre à faire cela et ne pas essayer de répondre aux questions avec trop peu d’informations. Et j’ai vu des gens qui sont de très bons techniciens qui sont vraiment nerveux quand ils ne comprennent pas tous les aspects et qu’ils ne peuvent pas répondre à toutes les questions qui pourraient se poser. Ils se sentent très malheureux. Il y a donc un aspect humain à cela et il y a une formation pour vous permettre de gérer l’ambiguïté. Vous devez vivre avec l’idée que vous devez apprendre de quoi il s’agit. Il faut comprendre les choses étape par étape. C’est une dimension.
La deuxième dimension est qu’Agile est évidemment un moyen très solide de traiter ce problème. La chose que les gens Agile ont réalisé, c’est que sans une étoile polaire claire, vous ne pouvez pas vraiment aller n’importe où parce qu’il n’est tout simplement pas possible de diriger une équipe sans savoir à peu près ce que vous voulez accomplir ou où vous voulez aller. Les gars Agiles appelaient cela “l’entreprise Agile”. Je l’appelle en plaisantant “water scrum”. Une fois que vous avez identifié le point, vous devrez peut-être le déplacer car la vision que vous avez excisée n’était pas tout à fait la bonne. Soit la vision était la bonne, mais la mise en œuvre s’avère complètement fausse.
Il y a un excellent exemple avec Visual Studio de Team Foundation Services, ou Server à l’époque. Ils avaient construit un système de gestion logicielle centralisé et décidé qu’ils devaient devenir une organisation de développement distribuée en termes de gestion du code source. À l’époque, Git n’était pas disponible lorsqu’ils ont pris cette décision. Ils ont donc emprunté cette voie, ont fait la planification, fait tout le travail et ont commencé à coder. Puis Git est apparu.
Ainsi, après un sprint, ils ont pu voir qu’ils avaient besoin d’un système de gestion de code source distribué, mais une implémentation propriétaire n’était pas la meilleure. Ils ont donc changé de direction et se sont retournés pour utiliser Git. C’est alors qu’ils ont intégré le système de fichiers Git dans Visual Studio Team Services. Et je pense que c’est un autre élément qu’Agile reconnaît que, oui, l’étoile polaire a peut-être encore raison, mais vous devez effectivement vous ajuster. Ce sont des scénarios ambigus avec lesquels les individus et les équipes doivent être à l’aise.
Des cours de formation sont disponibles pour vous permettre d’apprendre à prendre du recul, de supprimer votre instinct de vouloir tout savoir tout de suite et d’apprendre à laisser la situation évoluer avant de passer en mode solution complète.
Cela vient en grande partie de la discipline de l’expérience utilisateur et est associé au fait de s’assurer que vous arrêtez continuellement vos propres hypothèses. Les architectes doivent consommer la spécificité et quand il n’y en a pas, c’est presque comme une contre-pression qui se crée et nous remplissons simplement notre propre fausse précision dans le monde. Et quand vous faites ça, ça fait du bien à votre client, ça vous fait du bien, mais à la fin vous allez en quelque sorte construire ce monstre dont personne ne veut. J’appelle cela construire la mauvaise chose de la bonne manière. L’un des principaux moyens d’y parvenir est d’être conscient de vos préjugés. Soyez conscient des informations que vous ne possédez pas, puis essayez de chasser les bonnes personnes pour dénicher les bonnes informations.
Le biais de confirmation, par exemple, est celui dans lequel vous avez la réponse en tête et vous recherchez des personnes pour étayer vos points de vue. Et si quelqu’un ne soutient pas votre point de vue, alors vous ne voulez pas leur parler. Vous en trouvez d’autres qui soutiennent votre point de vue. Cela pourrait influencer par inadvertance les clients à vous dire ce qu’ils veulent, mais en réalité, vous êtes en quelque sorte à l’inverse en leur disant de vous dire ce que vous voulez. Tous ces dangers abondent si vous ne vous concentrez pas sur certaines de ces choses que l’on trouve dans la discipline de l’expérience utilisateur. Quels sont vos besoins satisfaits et non satisfaits ? Quels sont vos besoins non exprimés ? Quelles sont certaines des façons dont vous souhaiteriez pouvoir résoudre ce problème si vous disposiez d’un temps, d’argent et d’efforts illimités ? Et ensuite, en approfondissant la spécificité avec l’exercice Moneyball et des choses comme ça.
Comment pouvez-vous savoir quand vous êtes dans une situation de fausse précision ?
Vous ne pouvez pas toujours le dire dès le départ. Vous pourriez penser que vous avez trouvé la bonne réponse et que vous allez de l’avant. En fin de compte, vous voulez une validation, vous devez y faire couler de l’eau. Vous faites donc cette hypothèse d’architecture. Vous pilotez la conception. Maintenant, vous revenez à vos exigences pour vérifier si vous avez oublié quelque chose. Vous l’apportez à d’autres pour validation et obtenez des commentaires avant qu’il n’aille trop loin. C’est un modèle itératif où vous réfléchissez à quelque chose, proposez quelque chose, obtenez des commentaires et continuez à itérer. Et c’est la clé pour faire face à ce modèle trop ambitieux. La validation, à la fois externe et interne, est la bonne façon de procéder. Et puis à l’écoute.
Le biais de confirmation se produit également dans les entreprises de produits où les gens se rendent chez leur client amical pour validation. Il vaut mieux aller là où ils n’aiment pas vos produits car ils seront plus honnêtes et brutaux que votre ami. Vous voulez le point de vue de personnes qui ne sont pas nécessairement d’accord avec vous et qui ne sont pas convaincues que vos produits sont bons.
Ne soyez pas seulement un preneur de commande. Ne vous contentez pas d’écouter ce que les gens disent et de leur donner ce qu’ils ont demandé. C’est aussi avoir une opinion et les challenger suffisamment pour dire, bon, au final je ne veux pas vous donner des chevaux plus rapides. Je veux te donner une automobile. C’est donc ainsi que nous allons l’aborder.
De plus, parfois, si vous êtes dans un exercice logiciel alimenté par une fausse précision, vous ne le saurez peut-être pas tant que vous n’aurez pas fait Ta-da, n’est-ce pas ? Assurez-vous qu’en tant qu’organisation en pleine maturité, vous vous concentrez sur la traçabilité afin que chaque fonctionnalité que vous priorisez remonte à une exigence articulée, qui remonte et collabore avec la définition du produit, qui se concentre sur l’étoile polaire, et vous avez cette bibliothèque d’expérience utilisateur trucs qui y sont associés. La deuxième chose est que je demande souvent comment tu sais ça ? Comment savez-vous? À qui as-tu parlé? Où sont les données associées à cette conclusion ? Avez-vous pensé à cela ou est-ce ce que vous croyez et vous voulez être vrai? Alors pouvoir poser les questions est certainement une manière désarmante de contester une affirmation qui pourrait être porteuse de fausse précision.
Pour entendre toute la conversation, vous pouvez regarder la vidéo sur le lien ci-dessous.
