Les 9 principes du
Minimum Viable Technology (MVT)

Comment avancer vite & délivrer pour l'entreprise.

Cet article est la suite de Minimum Viable Technology (MVT).
Il liste des principes à destination des développeurs, CTO, lead dev ...

1. MVP + MVT + Agile = 💪

MVP : minimisation du scope fonctionnel.
MVT : minimisation du scope technique.
Agile : approche itérative.

2. Tout bouge

Et dans le vrai monde de l'entreprise, aucune vérité n'est éternelle.
Il faut avancer avec prudence en classant les décisions prises en 2 catégories : les réversibles et les irréversibles. (Lire Jeff Bezos, two types of decisions).

“It’s important to internalize how
irreversible, fatal, or non-fatal a decision may be.
Very few can’t be undone.”
— Dave Girouardbr
🤔

Choisi de façon judicieuse comment te préparer pour chaque cas de figure.
Spoil alert : la majorité de tes actions doivent être réversibles.

3. Célèbre le travail non-réalisé

Le code non-réalisé n'a aucun défaut.
Aucun bug, aucun retard, et sa maintenabilité est excellente.

Il est bien plus sain, mais aussi difficile de ne pas faire quelque chose,
et de trouver une solution plus élégante avec l'existant à la place.

4. Sois rapide et cost effective

Fais le minimum syndical pour livrer un produit viable (et ses itérations validées). Préfère des technos qui te sont familières et opérationnelles.

Ne plonge pas dans les dernières modes et autre buzzword.
En plus, c'est un signe flagrant de manque d'expérience.

5. Aime le refactoring

Le refactoring : c'est le signal d'un produit à succès.
On a besoin de refactorer les développements qui sont vraiment utilisés et dont le périmètre a évolué avec le business.

Un code inutile n'a jamais besoin d'être refactoré.

“The best code you can write now
is the code you will discard in a couple of years time.”
— Martin Fowler
🗑️

Ne tombe pas amoureux de ton code.
Dis-toi qu'il sera probablement refactoré et peut-être même remplacé si cela est justifié. Et ce sera une bonne chose. Cela prouvera que ton travail aura été utile.

6. Pense long terme, agis court terme

La limite entre under-engineering et l'approche MVT est ténue. Attention.

Ne plonge pas la tête la première dans l'exécution : tu créeras de la dette technique non-justifiée et donc un gaspillage de ressources/temps plus tard. Réfléchis bien et discute avec les autres de tes idées de simplification.

Méthode efficace :
Discute de la solution techniquement idéale/maximale avec les autres.
Puis décidez ensemble quoi tailler dedans pour la rendre "MVT".

7. Rapidité et qualité vont de pair

Bon... il n'est pas possible de justifier la mauvaise qualité d'un travail par sa rapidité d'exécution. MVT est une minimisation du scope technique, pas une réduction de la qualité !

MVT != "à l'arrache"

8. MVP + MVT sur chaque itération

On a tendance à penser que l'approche MVP ne concerne que la première version d'un produit. Mais non : cela s'applique à toutes les versions du produit.
MVP/MVT doivent rester vrais durant toutes les versions du produit.

Il n'est jamais OK de gaspiller du temps et des ressources.

9. Aie de l'assurance, des convictions et maîtrise le projet

Dire "oui, d'accord" (et livrer en retard ou hors budget) est bien plus naturel et accepté que de dire "non". De plus, il faut beaucoup plus de matière grise pour avancer en arbitrant en permanence, plutôt que de suivre sagement le backlog.
Dans les écoles d'ingénieurs, les profs répètent souvent : “un bon ingénieur est un ingénieur fainéant”.

Les approches MVP ou MVT requièrent donc un minimum de séniorité et d'assurance.
Pour le bien du projet, on va souvent devoir se confronter avec le Product-Owner ou avec certains dev plus juniors.
Sois le contradicteur constructif, sois l'ingénieur astucieux.

10. L'alignement des équipes est primordial

En direct lien avec le point précédent.
A cause des problèmes de confiance et de frictions, les différentes équipes vont se retrouver à pointer les erreurs des uns et des autres.
C'est naturel et humain mais c'est également toxique à la longue.
Si on ne fait pas attention, cela pousse l'équipe technique à devenir défensive et à sur-préparer les choses pour éviter des erreurs : et donc livrer moins vite.

---

Pour résumer

Hormis quelques parties-clé (l'auth, l'ORM ... qui de toute façon seront gérées par ton framework),
20% des dev seront vraiment utiles mais tu ne peux pas le savoir à l'avance,
80% des dev seront inutiles (ou presque).

Quand tu codes,
Garde en tête qu'il y a 4 chances sur 5 que cela finisse à la poubelle dans les 12 mois
Soit décomplexé à coder de façon simple (et donc rapidement).

Quand tu reviens dessus (au bout de quelques mois),
C'est que ce développement fait officiellement parti des 20% utiles, c'est top,
Tu pourras facilement refactorer car tu l'avais codé simplement.

---

Continuer la lecture avec Que ce que la "Minimum Viable Technology" (MVT).

---