Les grandes équipes ont souvent du mal à communiquer, coordonner, prendre des décisions et livrer des projets à grande échelle. Agile fournit un cadre pour aider à réduire ces problèmes, permettant aux équipes d’agir rapidement et de s’adapter aux changements. Cela encourage les équipes à travailler ensemble de manière plus collaborative, en divisant les grands projets en morceaux plus petits et gérables.
Agile permet également de hiérarchiser les tâches, d’identifier et de gérer les dépendances et de clarifier les objectifs généraux du projet. Cela aide les grandes équipes à rester organisées et sur la bonne voie et à s’assurer que tout le monde travaille vers les mêmes objectifs. Peut-être avez-vous entendu parler Cadres agiles à l’échelle et demandez-vous s’il vaut la peine d’investir dans l’un d’entre eux pour passer au niveau supérieur.
Mais jusqu’où peut-on aller avec les frameworks Agiles ? Certains angles morts doivent être pris en compte lors de l’utilisation de frameworks Agile. L’un des principaux problèmes des frameworks Agile est qu’ils structurent la communication de manière à ce que les experts du domaine soient au sommet et que leur volonté soit mise en production. Cela présente un risque car il n’y a aucune garantie que les ingénieurs logiciels mettront en œuvre la même chose que les experts du domaine attendent. Par conséquent, il est important de s’assurer que toutes les parties prenantes sont incluses dans la discussion, et les ingénieurs logiciels doivent avoir une compréhension claire de ce qui se passe comme le dit Alberto Brandolini :
Ce ne sont pas les connaissances de l’expert du domaine qui entrent en production, c’est l’hypothèse des développeurs qui entre en production.
Comment les développeurs sont-ils censés résoudre un problème lorsqu’ils ne savent pas quel est le problème ? Les hypothèses des développeurs sont-elles justes ? Existe-t-il une compréhension commune ? Cet article explique comment nous pouvons utiliser BDD et JDD des outils et des techniques pour surmonter les complexités, les angles morts et les malentendus pour bien analyser les connaissances et trouver un langage omniprésent.
La conception axée sur le domaine est linguistique
Afin de communiquer efficacement, les experts du domaine et l’équipe de développement doivent avoir une compréhension commune. Les développeurs n’ont pas besoin d’être des experts, mais ils doivent être familiarisés avec les termes et leur contexte dans ce domaine. Par exemple, s’ils travaillent dans le domaine de la santé, ils n’ont pas besoin de savoir comment traiter un patient, mais ils doivent connaître le sens exact du mot changement dans ce domaine. Il ne suffit pas de connaître la signification du terme ; ils doivent également comprendre le contexte dans lequel il est utilisé.
La séparation du même terme dans différents contextes est au cœur de la conception pilotée par le domaine. Bien qu’un terme puisse avoir la même signification dans deux contextes différents, ce n’est pas notre considération première. Au lieu de cela, c’est le contexte qui définit la signification du terme spécifique qui importe le plus.
Permettez-moi de clarifier davantage. Imaginez une tasse de café avec une tasse, un goût et même une marque spécifiques. Lorsqu’il est servi dans un café, il a de la valeur et vous le paierez. Mais, si le même café est laissé sur un banc dans un parc, le paieriez-vous ou même le boiriez-vous ? Bien sûr que non – c’est le même café mais dans un contexte différent. C’est pourquoi le contexte est important.
Si OOP est en termes d’objet, DDD est en termes de contexte.
De nombreux développeurs font des erreurs et pensent involontairement en termes de données et de prise en charge de certains états plutôt que de comportement. Le comportement n’est pas une donnée : les données sont le produit de comportements dans des circonstances fixes et c’est sur cette base que nous pouvons prendre une décision. En fait, le comportement qui mène à un certain état est plus important que l’état réel. Nous pouvons le prouver par les mathématiques : f(x) = y et g(x) = y =/=> f = g. Nous ne pouvons pas conclure F et g sont remplaçables en fonction de leur état final. Comme je l’ai mentionné ci-dessus, nous préservons le sens dans un contexte spécifique, au lieu de l’état final.
Rappelez-vous l’exemple du café : nous ne nous soucions pas de la façon dont le café est préparé (car il s’agit d’une tasse de café normale), mais nous nous soucions du contexte. Le café est nos données, et le café et le parc sont les contextes dans lesquels son comportement est défini. Peut-on les remplacer ? Je veux dire, nous voyons le résultat final comme une tasse de café normale – nous ne pouvons pas remplacer le parc par un café. Autrement dit, on ne peut pas dire, « Je veux une tasse de café, je peux la prendre au parc ou au café – qui s’en soucie ?”
Nous séparons le café du parc et le café du café à l’aide de contextes délimités dans Domain-Driven Design (DDD). Nous encapsulons et rendons omniprésent chaque terme dans son propre contexte. Cela signifie que nous n’aurions pas une langue mondiale omniprésente ; au lieu de cela, chaque contexte délimité aurait son propre langage omniprésent.
Une mauvaise communication pendant les séances de traitement des connaissances aurait différentes raisons, telles que biais cognitif, qui est un type d’erreur dans le raisonnement, la prise de décision et la perception qui se produit en raison de la façon dont notre cerveau perçoit et traite les informations. Ce type de biais se produit lorsque les processus cognitifs d’un individu l’amènent à tirer des conclusions inexactes ou à prendre des décisions irrationnelles. Par exemple, lorsque vous pariez sur une table de roulette, si les résultats précédents ont atterri sur le rouge, nous pourrions supposer à tort que le prochain résultat sera noir ; cependant, ces événements sont indépendants les uns des autres (c’est-à-dire que la probabilité de leurs résultats ne s’influence pas mutuellement).
De plus, l’apophénie est la tendance à percevoir des liens significatifs entre des choses sans rapport, comme les théories du complot ou le moment où nous pensons nous avons compris mais en fait, nous ne comprenons pas. Un bon exemple de cela pourrait être une image envoyée de Mars qui comprend une forme sur un rocher que vous pourriez penser être le visage d’un extraterrestre, mais ce n’est qu’une forme aléatoire d’un rocher.
Parfois, les gens mentent, pas dans le mauvais sens ; Je veux dire, pas exprès. Imaginez que pendant que vous travaillez sur votre ordinateur portable, votre colocataire peut vous demander quand vous devez aller dans la cuisine pour éteindre la lumière. Au bout de 20 minutes, vous partez mais oubliez d’éteindre la lumière, sans aucune intention. Ceux-ci sont inévitables lors des sessions de collaboration, et nous devons trouver des moyens de les réduire.
Les développeurs doivent collaborer efficacement pour créer un langage omniprésent et avoir une compréhension claire des différents termes du domaine pour créer des contextes délimités appropriés. Cependant, s’assurer qu’ils comprennent tous les problèmes du domaine est une tâche difficile. La bonne façon de résoudre ce problème ne peut être obtenue qu’en utilisant DDD et BDD. Ces approches ont différents outils pour couvrir chaque angle mort et minimiser l’ambiguïté.
Domaine (espace problématique)
Pour cet article, je définis un domaine simple pour une société de location de camping-cars imaginaire au Texas.
Le service principal de l’entreprise est la location de camping-cars, qui sont gérés au siège. Les clients ne peuvent louer que les camping-cars disponibles, chacun étant séparé par son étiquette de voiture unique. Ils doivent être récupérés ou rendus à l’une des gares de l’entreprise (par exemple, Houston, San Antonio, Dallas, Austin, etc.). Il n’y a aucune limitation concernant la station de retour; c’est-à-dire que les camping-cars peuvent être retournés à n’importe laquelle des gares. Les clients peuvent annuler leur location avant la prise en charge, ce qui signifie qu’ils ne pourront pas annuler après avoir pris en charge le camping-car. De plus, ils ne peuvent pas avoir trois annulations consécutives, sinon leur compte serait limité.
Mais, ils doivent être restitués avant la date d’échéance du loyer. Si le client revient en retard, il doit payer une pénalité. La pénalité est actuellement un prix fixe. Chaque camping-car peut être entretenu et réparé dans le garage de réparation de l’entreprise. Chaque fois qu’un camping-car est en cours de réparation, il n’est pas disponible à la location. Chaque camping-car doit être réparé après cinq locations ou trois mois après la dernière réparation.
L’entreprise dispose d’équipements portables (comme des toilettes portables, des draps, des sacs de couchage, des tables de camping, des chaises, etc.) ; des équipements sont ajoutés ou retirés avec leur stock respectif au siège de l’entreprise. Les clients peuvent réserver n’importe quel nombre et type d’équipements disponibles pour leur location, en plus de leur camping-car.
L’équipement est stocké dans les stations et a un nombre limité à un moment donné. Une fois qu’un client quitte la station, la quantité d’équipement disponible à cette station est réduite (par le nombre d’équipements que le client a emporté avec lui) et lorsque le client rend le camping-car, le nombre d’équipements à la station est augmenté en conséquence.
Étant donné que la quantité d’équipements est limitée et que pendant la haute saison, le nombre de camping-cars et d’équipements utilisés simultanément est le plus élevé, votre entreprise doit planifier à l’avance la quantité d’équipements nécessaires à chaque station par jour à l’avenir. Cela limite le risque de manquer de matériel. Pour plus de simplicité, j’ai omis la partie paiement. Utilisons Event Storming et BDD pour modéliser notre domaine.
Prise d’assaut d’événements
L’une des meilleures approches pour le traitement des connaissances est la tempête d’événements. Il s’agit d’un format d’atelier flexible pour l’exploration collaborative de domaines commerciaux complexes. Pour la prise d’assaut d’événements, je proposerai bientôt une série d’articles, mais pour cet article, j’en aurai un aperçu.
Qu’est-ce qui rend la prise d’assaut d’événements si efficace ? Il s’agit d’un atelier rapide, léger, intense, hautement interactif et collaboratif qui aide à construire un langage omniprésent. C’est la partie la plus importante de toute la prise d’assaut, où l’objectif commun est de partager le maximum de connaissances du domaine de chacun des participants. Les ateliers de prise d’assaut d’événements comportent différentes étapes : une vue d’ensemble, la modélisation des processus et la conception.
Une session d’image globale est généralement utilisée pour découvrir le domaine d’activité et partager les connaissances. La modélisation et la conception de processus sont davantage axées sur la conception de systèmes et la définition d’agrégats, et impliquent des développeurs, des propriétaires de produits, des concepteurs UX/UI et des responsables de l’ingénierie.
Commençons par une vue d’ensemble, comme un aveugle dans la pièce. Vous pouvez aborder l’ensemble de l’affaire dans cette session. Comme vous le savez, dans les entreprises, les connaissances sont partagées. Chaque département a son propre expert qui ne connaît pas les autres ou en sait peu. La valeur réelle de tout brainstorming réside dans les personnes et leurs connaissances. Par conséquent, pour un événement d’assaut réussi, inviter les bonnes personnes avec…