Présentation du Bounded Context Canvas

17 June 20201 March 2023 / one.hundred.acorns / Leave a comment

Le Bounded Context Canvas est un outil collaboratif créé par Nick Tune. Il aide à concevoir et documenter un Bounded Context.

Un Bounded Context (contexte borné), constitue une frontière autour d’un modèle et de son langage métier. À l’intérieur de cette limite, la signification des termes métiers utilisés est sans ambiguïté, bien définie et comprise par toutes les parties prenantes. Le modèle est clair et les règles sont cohérentes.

Le canvas vous guide à travers le processus de conception d’un Bounded Context en vous demandant de faire des choix sur les éléments clés de design : de son nommage et ses responsabilités à ses interfaces publiques et ses dépendances.

Vous pouvez retrouver l’article original de Nick, en anglais, sur son blog → ici.

The Bounded Context Canvas V3

Comment ça marche ?

Il n’existe pas de recette miracle pour découvrir les différents contextes bornés, mais une connaissance fine du domaine vous y aidera certainement ! La phase de découverte et d’exploration d’un domaine constitue la partie cruciale du Domain Driven Design. Sans une vision partagée par toute l’équipe, aucune chance d’aboutir au produit demandé.

Pour ce faire, il existe plusieurs outils collaboratifs qui vont vous permettre de découvrir le domaine visuellement et collaborativement :

Event Storming

Ma préférence va à l’Event Storming qui est, comme son créateur Alberto Brandolini le décrit : “un acte délibéré d’apprentissage collectif”. Le but de cet article n’est pas de vous expliquer comment dérouler un atelier Event Storming, si vous n’êtes pas familiers avec la pratique, je vous encourage à regarder cette vidéo ainsi que de lire le livre d’Alberto.

Commencez par modéliser le cas nominal en répartissant les événements métiers importants sur la ligne du temps. Essayez ensuite d’identifier les événements qui apportent de la valeur, ils vous aideront à coup sûr à découvrir vos contextes “cœur de métier”.

Heuristique

Cherchez les événements clés/pivots, ce sont des événements du domaine qui indiquent généralement des changements d’état entre les différentes parties du processus métier. Ce sont souvent des marqueurs de début et/ou de fin d’un contexte borné.

À la fin de cette session d’Event Storming en mode “big picture” vous devriez être en mesure de commencer à noter sur des post-it des noms de contexte borné candidats.

Domain Message Flow Modelling

Choisissez un des contextes bornés candidats que vous avez trouvé lors de l’Event Storming, identifiez une liste de scénarios clés de ce contexte et réalisez un diagramme de flux des messages pour chaque scénario (plus d’info → ici).

Ce diagramme aide à visualiser tous les messages (commandes, événements et requêtes) qui circulent entre les différents acteurs, contextes bornés et systèmes externes, pour un scénario donné.

La notation est volontairement très simple afin de s’assurer que tout le monde soit capable de participer à l’atelier sans avoir besoin de théorie :

Voici un exemple d’utilisation :

Diagramme de flux des messages – légende

Diagramme de flux des messages – exemple

Modéliser un diagramme de flux des messages vous permet d’avoir un feedback rapide sur la pertinence du choix de votre contexte borné. Vous visualiserez très vite la façon dont les contextes interagissent entre eux afin de satisfaire un scénario.

Heuristique

Si votre diagramme semble trop complexe avec beaucoup de dépendances et de relations bidirectionnelles, il se peut que vos choix de contextes bornés soient erronés. Voyez-là une bonne opportunité de retravailler votre design avant de vous lancer dans le code ;)

Il n’est pas nécessaire d’identifier tout de suite les données véhiculées dans chaque message, cela peut très bien être réalisé dans un second temps.

Le Bounded Context Canvas

Il est temps maintenant de s’atteler à remplir le canvas.

Chaque contexte borné candidat possède son propre canvas, vous pouvez d’ailleurs commencer par remplir le canvas du contexte borné qui vous semble le plus important dans votre domaine.

Voici la liste des différentes sections et pour chacune, des indications sur comment les remplir.

Nom

Le nom du contexte borné. Référez-vous au résultat de vos ateliers Event Storming et Domain Message Flow Modelling pour la liste des contextes bornés candidats.

Heuristique

Posez-vous la question de la pertinence d’un nom de contexte qui contiendrait “Management/Gestion”. Bien souvent ce terme est employé comme fourre-tout et regroupe probablement plus d’un contexte. Ex : dans le cadre d’un domaine de location de trottinettes électriques, évitez “Gestion de la flotte”, cela regroupe certainement des contextes comme “Répartition de la flotte” et “Prévision de la demande” qui sont des candidats à part entière.

Description

Cette section sert à décrire brièvement le contexte borné, ses intentions et ses responsabilités. Quel est son rôle dans le domaine ?

Classification Stratégique

La classification stratégique contient 3 axes par défaut (Domaine, Business Model et Évolution). Il n’est pas forcément nécessaire de remplir les 3, ils servent avant tout d’exemple. Vous pouvez également ajouter les vôtres si cela vous semble plus pertinent.

1 – Domaine

Dans cette sous-section, le but est d’identifier l’importance que joue le contexte dans la réussite de l’organisation. Un moyen simple et efficace est d’utiliser le tableau ci-dessous :

CoreDomainChart-FR
Core Domain Chart

Ce tableau vous aide à visualiser l’importance stratégique d’un contexte borné (abscisses) et son niveau de complexité (ordonnées).

Le cœur de métier est la raison pour laquelle vous développez votre application au lieu d’en acquérir une sur le marché, c’est évidemment la partie qui nécessite le plus d’attention. Les contextes de support sont des contextes nécessaires au domaines, liés au business, mais qui ne possèdent pas un avantage compétitif équivalent au cœur de métier. Les contextes génériques représentent des concepts qui ne sont pas uniques au domaine (on y retrouve des choses comme l’envoi d’e-mails, le paiement, …) Il est totalement possible d’imaginer utiliser des services existants au lieu de développer ses propres domaines génériques.

2 – Business Model

Ici, vous décrivez quel rôle joue le contexte borné dans le business model de votre organisation.

Prenons l’exemple du business model d’un moteur de recherche comme Google. On pourrait imaginer que plus les utilisateurs effectuent des recherches, plus cela génère des revenus. Quand on y réfléchit bien, ce n’est pas le contexte de recherche qui est générateur de revenus, mais le contexte des publicités. Le contexte de recherche sert à l’attractivité. On peut aussi très bien penser qu’un contexte qui gère les problématiques de GPDR ait le rôle de conformité dans le business model.

3 – Évolution

L’idée de cette sous-section est d’imaginer à quel niveau de maturité se trouve le contexte, à l’aide d’une Wardley Map. Sur l’axe de l’évolution, plus un contexte est répandu ou commun, moins il aura de valeur ajoutée.

La 1e étape sur une Wardley Map représente la genèse. C’est là que vous pourrez placer votre contexte s’il constitue quelque chose d’innovant. Ensuite arrive l’étape du sur mesure. A ce stade on quitte l’état de POC (Proof of Concept) mais les développements sont encore très customisés. Si votre contexte se place dans l’étape produit, c’est peut-être que vous êtes assez matures et êtes en mesure d’offrir des services à d’autres contextes ou à l’extérieur de votre organisation. Enfin, lorsque le contexte se trouve à l’étape marchandise, c’est qu’il devenu un contexte très commun auquel tout le monde peut avoir accès facilement.

Cette carte sert avant tout à visualiser la chaine de valeur. Elle vous permettra dans un second temps d’imaginer comment vos contextes risquent d’évoluer dans le temps et ainsi d’anticiper au mieux les efforts à porter sur tel ou tel contexte.

Décisions Métier

Ici, vous noterez les contraintes, décisions et règles métier du contexte : Quelles sont les décisions importantes que le contexte borné doit prendre et pourquoi ?

Vous pourrez distinguer les règles métier des invariants.

Invariant : Un Invariant est une règle forte qui ne doit jamais être rompue. Ex : Vous ne pouvez pas prendre 2 rendez-vous le même jour avec le même médecin sur une plateforme de prise de rendez-vous médical en ligne.

Règle : C’est une règle métier dont on ne connait pas forcément à l’avance la vitesse à laquelle elle va être appliquée et donc, qui est sujette à compensation. Ex : Une personne commande une pizza en ligne, la « cooking policy » s’applique. On regarde si la pizzeria est en capacité de prendre la commande et on l’accepte, sinon, on annule la commande.

Langage Ubiquitaire

Listez ici la terminologie clé du contexte ainsi qu’une définition de chaque terme.

Heuristique

Prêtez une attention particulière au langage et à la signification de chaque terme dans un contexte. Si vous luttez pour trouver une bonne définition à un terme particulier du contexte, c’est peut-être parce qu’il cache plus d’une signification. Dans ce cas, la découpe de votre contexte est certainement à revoir. Pensez au terme “livre” qui peut avoir de nombreuses définition en fonction du contexte dans lequel il est employé (imprimerie, édition, librairie, simple lecteur, …) comme en parle si bien Grégory Weinbach dans cette vidéo.

Caractéristiques du Modèle

Cette section est vraiment ouverte et vise à définir la nature des comportements internes du contexte et/ ou le type du modèle.

Le type de modèle est une notion très intéressante qui a été déjà présentée à de nombreuses reprises par Alberto Brandolini. En 2012, en 2016 et tout récemment lors de la conférence en ligne D-DDD-D dans son talk Extreme Context Mapping (partie “the three archetypes”). L’idée est de montrer que des modèles similaires peuvent avoir des comportements très différents. Alberto parle de modèles “draft“, “execution” et “metrics“. Les modèles de type “draft” et “execution” partagent une structure de données très proche mais leur comportement diffère. Sur un modèle “draft“, il y aura des validations de structure et la donnée sera consolidée de manière incrémentale. Prenons l’exemple d’un panier sur un site e-commerce. On y ajoute des articles au fur et à mesure, des vérifications de surface sont faites, mais ce n’est pas avec un panier que le site va gagner de l’argent. Le modèle “draft” passe à “execution” suite à un événement de transition (cherchez-les sur votre Event Storming !) Notre panier devient alors une commande, avec laquelle le site e-commerce pourra gagner de l’argent. Ce modèle deviendra alors pratiquement read-only. Un 3e type de modèle, le type “metrics“, avec une structure semblable, servira à des fins de reporting ou d’analyse.

Nick fournit également une liste de type de comportements applicables à un modèle, dont vous trouverez la version française → ici.

Messages Consommés et Produits

On trouvera dans cette section la description de l’interface publique du contexte. Que produit-il comme message et que consomme-t-il ?

Voici les types de messages :

Commandes :
Le contexte qui produit une commande, demande au contexte destinataire de faire quelque chose, de réaliser une action. Une commande peut échouer.
Événements :
Un événement important pour le domaine qui est arrivé dans un contexte et qui peut intéresser d’autres contextes.
Requêtes :
Un contexte demande des informations à un autre contexte.

Stuff - Interface du BC
Interface du contexte borné

De nouveau, n’hésitez pas à jeter un œil à votre Event Storming, vous trouverez de quoi alimenter cette section !

Dépendances et Relations

Ici on listera les contextes et les systèmes externes depuis lesquels les messages arrivent – les fournisseurs – et les contextes qui consomment les messages publiés – les consommateurs -.

La relation est un texte libre où vous pourrez décrire succinctement la raison pour laquelle une dépendance existe.

Référez-vous à votre diagramme de flux des messages afin de voir avec quels autres contextes et systèmes externes votre contexte interagit.

Et après ?

Une fois que vous aurez rempli votre 1e canvas, profitez-en pour prendre un peu de recul avant de remplir le suivant. Regardez si les décisions que vous avez prises lors de vos discussions, n’ont pas d’impact sur la liste des contextes candidats que vous aviez imaginé au départ. Refaites un tour sur votre Event Storming et rectifiez au besoin.

N’oubliez pas que la modélisation est une activité itérative, comme Eric Evans le dit lui-même “il faut trois mauvais designs avant d’avoir trouvé le bon !”

Le canvas a été créé pour vous guider dans la découverte, la conception et la documentation des contextes bornés de votre domaine. Vous n’êtes toutefois pas obligés de le suivre à la lettre. Libre à vous de le modifier et l’adapter en fonction de vos besoins.

Tout au long de cette activité, pensez à noter les heuristiques que chacun a utilisé pour trouver et affiner la liste des contextes bornés de votre domaine. Cette liste, que vous pourrez mettre à jour régulièrement, vous servira à chaque fois que vous repartirez en mode exploratoire à la découverte des contextes bornés d’un domaine.

Bonne modélisation ! :)

Consultant et formateur

Si vous recherchez un accompagnement pour votre équipe ou une formation, je suis à votre disposition pour plus d’information, n’hésitez pas à me contacter !

Everybody likes options!

9 November 2015 / one.hundred.acorns / 2 Comments

Who doesn’t?

In our day-to-day life, whenever you have to take a decision, you almost always have lots of options. If your goal is to go somewhere, if it’s near from where you are and if it’s sunny outside, you can go for a walk or by bicycle. If it’s rainy, you can pick up your car or take public transportation. If it’s far away, then you’ll have to book a train or a plane. Now your goal becomes booking a ticket and you still have tons of options! You don’t have too much money? Go with low cost companies! You still want to reduce the price? Well, do not put any luggage in the plane’s hold and take only your backpack. Then you can choose the flying class: economy, first, business, … you can choose whether to use your miles or any other loyalty card, choose between different flight schedule, even choose where you want to sit! And it’s almost the same for the train! Everything is up to you!

The same goes when your goal is simply to eat! You’re lazy? Go at the restaurant! What restaurant? You have tons of options: fast food, Asian food, Italian food, … unless you live somewhere where there’s no restaurant at all, then the only options you have stand in your fridge! But when you’re at the restaurant, have a look at the menu: you see all the options?

Whenever you have a goal, something to accomplish, you always think about all the possible ways to reach it. And if for any reason the option you did choose doesn’t work, well, you simply pick up the next one on the list.

We love to have all those options; we love to be able to pick up the one that fits to our need.

So why the hell, don’t we have such options when it comes to software development?

I don’t speak about the way you will implement something, I don’t speak about the technical decisions here. You might have some technical options in mind depending on what needs to be done (unless there’s an enterprise architect in the way…) I Speak about how to reach a business goal.

Worst-case scenario: you only have specifications that tell you what to do. In this nice MS Word document where everything is written in advance, you don’t need to search for options: you won’t find a single one. Just do it like it’s described, the choice have already been made. Even if you’d like to do something else, you cannot, simply because you don’t know the business goal to reach and what are the measurements to check to know if you succeed. Just shut up and code! :-)

At best, you have a user story:

As a Customer, I want a brand new Refer A Friend page so that I can invite my friends to join and receive a 10% discount

Actually, the real customer need behind this user story might tell you another story instead:

We really need to increase the number of our customers because if we don’t then we might be in big trouble pretty soon.

The thing is that the user story doesn’t tell you that.

Creating a “Refer A Friend” page is just an option amongst others to gain more customers. It’s no more than an assumption that this option will do the job. It has been chosen upfront by some business people. But what if they’d have asked you? Would you have chosen to create a “Refer A Friend” page or something different? At least I guess you would have brought some other options on the table.

It seems obvious but you cannot have options without knowing the goal to reach.

So to answer my own question: we don’t have options when it comes to software development just because we often don’t know the real goal behind a user story or some piece of specifications. We don’t know what really is the customer need we’re trying to fulfill when developing a new feature.

Usually, what is written is specifications or described in user stories is not a goal; it’s just a way to reach a goal, it’s just a single option an assumption that it will work.

Think about how things would go if military ground troops would act like developers. They’d receive their orders as specifications from the military command saying exactly what to do. A nice and clear step-by-step procedure, written a couple of months before the d-day in order to guide them once on the field. Just like a poor developer they would only have one way to succeed in hand, just a single option. But in the meantime things have changed. Once on the ground the troops got quickly caught in a trap. It’s not their fault, though: it was not written in the specs!

Military do the contrary instead: they mainly receive the goal to reach from the commanders. They might have some options to start with, but it’s also up to them to bring some new ones as the mission evolves. The commanders trust the troops! They know that they were trained to react and adapt the right way as things change.

To solve this problem in software development, well, there’s no secret: you’ll need to bridge the communication gap between business stakeholders and dev teams. Communication and trust are key to success.

If business wants to keep up with specifications, why not suggest going a bit further with Gojko Adzic‘s Specifications by example. This will help you to to cooperatively define the specifications based on real examples.

If you’re tied to user stories, then they should definitely sound like business goal instead of solution ideas (which is often the case). One simple way would be to find out two options that bring the same benefit. But an easier way would be to look into impact mapping where stories are not considered as commitments but options!

But the best thing to do might be to follow Jeff Patton‘s advice:

We don’t need an accurate document, we need a shared understanding

Discovering things collaboratively using Jeff’s User Story Mapping or Alberto Brandolini‘s Event Storming might be the best way to find options. Working together with business people will obviously let you know the real customer goal to reach.

Now take your shovel and dig up some options!

Does your code speak business?

14 January 201515 January 2015 / one.hundred.acorns / Leave a comment

There are many books and manifestos or even books about those manifestos :-) the aim of which is to teach you how to be more efficient. They provide you with diverse recipes and tools to be more efficient as a person, as a developer but also as organizations.

All those writings also have another important thing in common; they all say that in order to be more efficient you constantly need to focus on delivering value or even steadily adding value.

I did a presentation during a Paris Software Craftsmanship Meetup, where I tried to define what exactly value is and the kind of things you could put in place (and things to avoid!) to bring it down to your code or even within your tests.

Here you go!

Bridge the gap between dev team and business people! – Idea #3

10 July 20149 November 2015 / one.hundred.acorns / Leave a comment

This article is the third out of an unlimited series (let’s say at least 5!) where I’m gonna try to give you some ideas and easy things to put in place in order to bring your team closer to business people so that you can work collaboratively and efficiently with them.

Written so far:

Event Storming

In the previous post you read how Impact Mapping gives you the goal to reach and what are your options to do so, now it’s time to get more into how the system works.

An Event Storming session will involve almost the same people as for an Impact Mapping’s one but the aim is quite different!

Event Storming is about to find out all the events that occur in the system -> the business processes.

As Alberto Brandolini says:

Ideally, one would like to have participants coming from two fields: people with questions and people with answers. They provide the perfect mix of curiosity and wisdom.

Domain experts, the business people, know the system by heart and their job here will be to answer to a lot of questions! Those questions will be asked by a mix of different people (including developers, team leaders, testers, …), bring the curious ones!

After an ES session, everyone should be able to share the same vision on how the system behaves and the icing on the cake: everyone should share the same language to describe this (see the Ubiquitous Language).

First of all, you’ll need to find a big wall that you’ll cover with plotter paper or electrostatic sheets in order to be able to put sticky notes and maybe draw some lines and write text. Get some markers and different colors sticky notes. Decide to focus on a particular part of the domain (unless this could last more than a day!) and start by asking this simple question to your domain experts: “What’s the most important event that should occur in the system?”. If you’re working for a company that sells things on the Internet, and that you’re focusing on the ordering process, the answer should sound like “Cart checked out” or something similar. Now that you have that specific event, act as a time machine and try to find out together with the domain experts, what happened before this one. Write every single event on sticky note and put them in the right order.

Follow Alberto’s advice: Here’s the dogmatic color coding for #eventstorming follow it or perish! :-) (source)

This first part of an ES session really focuses on outcomes. Here’s a simplified version of what you should have:

CustomerLoggedIn->ItemSelected->ShoppingCartValidated->DeliveryAdressConfirmed->PaymentAccepted->CartCheckedOut

Now that you know everything that happens before a cart is completely checked out you can focus on the causality: the corresponding commands that lead to those events. Put another color – blue if you don’t want to perish ;-) – sticky note on every events and write the command name (you can also draw the actor that fires the command – User/Job/Time/…). Here’s another simplified version of what you should have:

LogCustomerIn->SelelectItem->ValidateShoppingCart->ConfirmDeliveryAddress->ValidatePayment->ConfirmOrder

Look what we have here? The method names of the not yet written application code! How could you be more close to business people if even your code speaks business? ;-) That’s the point where your code really brings business value!

And where the magic happens is when the QA tester can even start to write BDD styled tests during the ES session:

Given a Customer Logged In
When he Selects an Item
Then the Item should be selected in the Cart

I must admit this is a too simplistic example but you get the point, right?

At the end of an ES session every people involved knows exactly how the system works and behaves, what are the events that should occur and their corresponding command (and actor). You should be able to point out potential conflicts or missing concepts but new opportunities as well! Last but not least, everyone shares the same language and did speak together!

Mission accomplished!

Bonus: If you’re into DDD, Event Storming can even bring more than that as you’ll be able to find out the Bounded Context and Aggregate Roots of your system.

The Ubiquitous Language

20 May 201415 January 2015 / one.hundred.acorns / Leave a comment

Project Manager: -"Hey, I found a bug on that page" Developer: -"mmm, where exactly?" PM: -"There, the market is not displayed correctly" Dev: -"The what? Oh, you mean the football match name?" PM: -"Yes..." Dev: -"I see, I'm gonna warn the tester" Tester: [BUG2435 Status: Reported] The event name is not displayed correctly on homepage

Here’s the kind of familiar example you might hear every week. This short dialog illustrates one of the most common problems we experience in software development: people do not share the same vocabulary. In this brief example the different characters have used 3 different ways to name things. It’s easy to imagine that business people have their own way to name that too, and members within the same development team could have different naming as well!
This might not look like something really important here, but think about a more complex system that deals with concepts ways more complicated than a single football match. What would happen if people do not share the same vocabulary?

I had a colleague that had a 2 columns sticky note he uses as reminder where he wrote on the left side the word his team is used to use and on the right side the corresponding business term. Well, this might help but wouldn’t be easier to share one common way to name things?
The worse thing I saw was that brilliant developer. He was that guy in the corner. The less he was dealing with business people and the less he was bothered by someone else, the more he was happy. This guy was so away from the reality that he was inventing his own terms! This kind of behavior is extreme of course, but it illustrates quite well the problem. If people don’t share the same vocabulary, the code will be very hard to read and understand thus maintenance costs will increase… just for a matter of vocabulary.

I recently participated in an Event Storming workshop animated by Jef Claes & Tom Janssens at NCrafts conference. First aim of Event Storming is to talk with a domain expert and try to find out all the events that occurs in the system (Event Storming has many other benefits, but that’s a bit off-topic, have a look at Alberto Brandolini‘s blog here to learn more). We wrote the first events just after a short description of the subject by the expert. Those events were looking like “Shop Keeper Registered” or “Shop Keeper Account Updated”. After having talked a little bit more with the domain expert, it appears that the “Shop Keeper” term was not correct. The expert was using the “Partner” term instead. What if this was real life and that developers were keeping on using “Shop Keeper” instead of “Partner”? Let’s imagine the developer that needs to fix a bug on the Partner Registration process: he will search for any “partner” occurrence in the code and this will produce no result! He will need to struggle a bit to find the right place to fix the bug and then, he might add “Shop Keeper” = “Partner” on his 2 columns reminder sticky note ;-)

How could your code bring value if it doesn’t speak business?

Uncle Bob said that names in code “are the most powerful tool that programmers have to communicate with each other” and that “developers should use names to Reveal Their Intent and Avoid Disinformation“. Makes pretty much sense!

People often neglect the need to share the same vocabulary, they simply do not care.
Won’t you think that it would be easier for every person involved in a project to share a common way to name things?
What if the same vocabulary would be use from the business requirements to the software code or even the test code? Wouldn’t it ease the communication and the understanding of every one involved?

People always complain about communication between business guys and developers. Start by speaking the same language!

The Ubiquitous Language is the term used by Eric Evans in his Domain Driven Design book. The idea is to build a common language shared by everyone involved. As Martin Fowler said: “the language needs to be rigorous, since software doesn’t cope well with ambiguity” :-)

There are several ways to build the Ubiquitous Language, model storming and event storming workshop are one of them. But the successful ingredients of Getting-The-Ubiquitous-Language recipe are always almost the same:

find out the domains experts
put them in a room
ask a couple of colleague to join (another developer, a tester, …)
ask as much as you can about one specific part of the domain
put everything on sticky notes
it should not take more than 30mim
repeat until you think you’re done!

You don’t have to know about DDD in order to start Event Storming workshops.

One of the nice side effects of Event Storming session is that the more you’ll go deeper in details, the more you’ll see different part of the system naturally appear. You will get a pretty good idea of what components you’ll have to build (DDD speaking you’ll find out Bounded Context and Aggregate Root).
You will also be able to define your GivenWhenThens. As sticky notes are chained as events that must occur to get from one state to the other, it’s kinda easy to write your BDD styled tests! And that’s where having a tester in the loop is becoming interesting! Sounds like we have our 3 amigos meeting here ;-)

Hope all this gave you some ideas about things to try on your side in order to let you and your code speak business!

There are obviously other pretty good techniques to bring business and dev people close to each other but enough for now, I’ll have surely the opportunity to talk about this later in another post!