Nous avons vu comment réaliser un MVP pour un événement spécifique en 40 heures, désormais nous allons voir comment aller un peu plus loin dans le concret et réaliser une première version d'un produit en seulement quelques semaines.

Just do it !

Le nerf de la guerre

Le nerf de la guerre, c'est le temps.

Pour tenir les délais, il va falloir optimiser les décisions et les choix techniques pour mener à bien la mission. Cet article va s'articuler autour de 3 thématiques :

  1. La définition des spécifications et de la méthodologie.
  2. Le choix de technologies.
  3. Contrôler et comprendre la dette technique et ses conséquences.

Cette fois, il n'est plus question de faire du jetable, on part sur du concret, extensible que l'on va conserver un bon moment dans le projet.

Les fondations qui vont être posées vont impacter la vie du projet dans sa globalité.

I — La définition des spécifications et de la méthodologie

Avant d'agir, il convient de savoir où l'on va.
Photo de Estée Janssens / Unsplash

La définition des spécifications est la première étape qui vous permettra de démarrer du bon pied.

La méthodologie Agile est la méthode recommandée pour tout projet informatique qui se respecte aujourd'hui.

Scrum, Kanban ou Scrumban, je ne rentrerais pas dans les détails ici mais vous trouverez de nombreuses informations sur Internet à ce sujet.

En bref, il va falloir fonctionner par itérations pour :

  • Donner de la visibilité à ses collègues.
  • Pour pouvoir réagir ensemble et évaluer les choix qui devront être faits pour les prochaines itérations.
  • Afin de maîtriser l'atterrissage, c'est-à-dire les délais de livraison, le budget et le périmètre fonctionnel du produit.

Basé sur une étude de marché, il va falloir isoler ce qui est essentiel pour lancer le produit. Ensuite, il serait judicieux de procéder à la rédaction détaillée de petites unités de tâches représentant ces fonctionnalités.

Les questions à se poser font partie du champ lexical suivant :

Est-ce que je suis en train d'écrire est essentiel au fonctionnement de mon produit ? Est-ce que ce n'est pas un peu gadget ?
Quelles possibilités puis-je envisager pour obtenir le meilleur rapport temps investi/utilité/qualité ? (en proposer plusieurs)

Il faut également savoir faire l'avocat du diable et se dire que l'idée la moins bonne que l'on pense à première vu est peut-être la bonne ? Savoir essayer de trouver des arguments pour utiliser cette solution.

Bien trop souvent, on est convaincu d'un truc, mais l'on fait fausse route, le cas échéant cela vous renforcera le choix initial.

Avoir des tâches fonctionnelles unitaires permet de libérer tout le potentiel de l'équipe de production, qui n'a plus alors à se poser 100 000 questions lors du développement ou naviguer à l'aveugle. La productivité est alors décuplée.

II — Le choix de technologies

Moins de code, c'est moins de chances de bugs et moins de maintenance.
Photo de la NASA / Unsplash

Pour aller vite, pas de secrets, il faut écrire le moins de code possible, plus vous avez de code, plus vous risquez d'avoir des bugs.

Préférez donc les outils que vous maîtrisez, si vous passez par ici vous êtes certainement adepte de Javascript. Parfait, c'est un très bon outil.

Utilisez dès que possible des solution tierces, type « Software As A Service » pour gérer vos outils.

Les personnes qui les réalisent ces outils ont du recul et une communauté que vous n'avez pas sur ces derniers. Ils mettent généralement en place des tests automatiques sur le code, ce qui vous garanti une meilleur chance de stabilité que si vous faites tout vous-même.

Pensez à créer une architecture client / serveur avec une API web qui sert du JSON.

Utilisez un framework comme ReactJS (ou NextJS) ou VueJS (ou NuxtJS).

III — Contrôler et comprendre la dette technique et ses conséquences

Dans la vie, tout est question d'équilibre. Il y a le bon et le mauvais endettement.

Derrière le terme de dette technique, se cache le fait qu'il va falloir prendre des raccourcis et délaisser volontairement en toute conscience certains éléments de l'application afin de pouvoir vous concentrer sur l'essentiel. J'insiste sur le fait d'en être conscient, c'est très important. En effet un risque est bon à être pris si il est mesuré.

Le mot-clé ici est Timeboxing, il faut savoir se fixer des limites de temps et faire le meilleur usage de ce dernier avec les moyens qui nous sont donnés.

Illustration de la dette technique en une image

‌Afin de pouvoir progresser vite, il va falloir accepter certaines choses qui ne sont pas parfaites et traiter progressivement ces choses dans les prochaines itérations du projet.

En fait, c'est un peu comme faire un crédit à la banque que l'on rembourse petit à petit, c'est un effet de levier. À la différence même qu'ici vous ne serez pas poursuivit pour un non-remboursement, mais que vous pourrez probablement couler votre boite si vous ne la gérez pas bien.

La première impression est la bonne, surtout si elle est mauvaise. — Inconnu

Alors attention, tout endettement n'est pas bon à prendre, choisissez méticuleusement les parties sur lesquelles vous souhaitez vous endetter.

À titre d'exemple, l'endettement le plus fréquent réalisé par une équipe de projet est de ne pas faire de tests automatisés, permettant de limiter l'impact des régressions à mesure que le projet grossit.

Maîtriser la dette est une action essentielle, sa non-maîtrise peut conduire à l'explosion du budget, des délais et de la satisfaction client.

Bref vous l'aurez compris, réfléchissez à ce que vous faites avant de le faire et bon courage pour vos réalisations :)