C’est Laurent Charles, CEO d’enalean, qui a animé cette rencontre d’avril, face à un public passionné bien que peu nombreux. L’objectif n’était pas de parler des méthodes, mais plutôt de comprendre quels problèmes elles permettent de résoudre.
Basée sur son expérience cette présentation s’appuie principalement de développement logiciel ou informatique. En préambule il est rappelé qu’aujourd’hui le développement logiciel « pour les ordinateurs » ne représente qu’un tiers des logiciels produits.
Constats
- un projet, ça merde
- un logiciel, c’est inutile à 45%
- la vérification, ça coute cher et on la fait mal
Ces constats nous amènent à nous poser trois questions :
- quel est le besoin ?
- comment faire de l’utile ?
- comment réduire le coût de vérification ?
Qu’est ce qu’on fait ?
La première étape est de définir ce qui est utile, c’est-à-dire ce qui a de la valeur.
Les 5 pourquoi
Bien souvent le client n’exprime pas un besoin, mais un fantasme, ou encore une proposition de solution. La technique des 5 pourquoi permet de creuser la demande du client, de trouver son vrai besoin, « là où ça gratte ».
What if not
Une fois les vrais besoins définis il faut trouver l’importance, l’impact du besoin. L’identification de l’impact défini la valeur. La question « et si on ne le fait pas, il se passe quoi ? » va permettre de définir l’importance, la valeur.
Nous parlons ici d’importance et pas d’urgence, si ce n’est pas important on ne le fait pas, si c’est urgent, c’est le process préétabli qui doit gérer. Le travail doit s’effectuer dans la zone important, pas urgent afin de pouvoir travailler en toute sérénité.
Il est évident que ces deux méthodes peuvent fonctionner uniquement si le client est intelligent.
Quelles ressources ?
La deuxième étape est d’estimer la consommation des ressources, argent, temps, points, …
L’estimation est toujours fausse, sauf éventuellement, quand on utilise une technologie obsolète et qu’on a déjà fait 500 fois le travail, ce qui n’existe pas. Il existe deux méthodes pour estimer moins mal.
Évaluer collectivement
En combinant ses compétences, c’est l’équipe qui va se charger du développement qui évalue collectivement le besoin.
Faire du relatif
Éviter d’utiliser des heures, mais préférer une unité arbitraire, les points, les patates, les storypoints et se baser sur des choses déjà faites : cette tâche est plus longue celle-ci que j’ai déjà réalisée.
Ces deux techniques permettent un delta de 1,6 entre l’estimation et le réel, qui serait quatre voire six fois plus important sans.
Le coût de vérification ?
Plus on vérifie tard, plus ça coute cher.
L’industrie nous a habitué à ne pas faire d’erreur et donc à engager une kyrielle d’ingénieur pour passer en revue tous les problèmes qui pourraient hypothétiquement arriver, c’est le mode pessimiste. Pour diminuer les coûts de vérification, soyons optimistes.
Mode optimiste
Acceptons l’erreur, ne l’empêchons pas d’arriver, mais donnons nous les moyens de la détecter, de l’observer et de la corriger.
Un bon exemple du mode optimiste sont les rovers, les robots envoyés sur les comètes. Ils étaient programmés uniquement pour être reprogrammé, le logiciel a été développé pendant le trajet.
On peut également citer le problème intervenu sur les logiciels des voitures Ford et Tesla. Les premiers ont rappelé tous les modèles concernés pour faire la mise à jour, les seconds avaient prévu la possibilité de mise à jour à distance.
Ne pas avoir de bug
Ne pas avoir de bug est bien évidemment la meilleure solution pour ne pas avoir d’erreur, ou les minimiser. Il existe dans les « méthodes agiles » de nombreux procédés permettant un développement optimisé :
- l’intégration continue
- le pair programming
- la revue de code
- …
Scrum
Méthode qui agit exclusivement sur le management du projet, elle est parfaitement adaptée à la R&D. Scrum ne dispose pas de pratique d’ingénierie, d’outil.
Avec scrum :
- on fait de l’utile
- l’évaluation est raisonnablement bonne
Pour une bonne vélocité des équipes cette méthode ne supporte pas l’interruption.
Kanban
Méthode de gestion de flux, de maximisation du nombre de « choses » traitées. On cherche à trouver le débit optimal.
