Reprendre le contrôle de vos développements, sans l'illusion des estimations
Faire le deuil des estimations
Que vous vouliez l’entendre ou non, personne ne sait estimer quoi que ce soit tant les incertitudes sont grandes : il y a les incertitudes techniques, d’autant plus importantes que la dette n’est pas maîtrisée ; mais, bien avant les incertitudes techniques, il y a l’inconnu fonctionnel, qu’on lève au fur et à mesure que l’on conçoit l’application et que l’on acquiert du retour d’usage.
Autrement dit, les estimations sont faites avant de savoir quoi développer. Relisez lentement cette phrase, elle n’a aucun sens. Pourtant, c’est ce que nous faisons au quotidien, et c’est bien là le fond du problème. Exemple : « Je souhaite développer le MVP pour dans un an, est-ce faisable ? » Toute personne sensée devrait objecter : « Je n’en sais rien, ça dépend de ce que vous voulez mettre dedans ».
D’autre part, les estimations sont un vaste jeu de dupes, parce qu’elles sont prises pour argent comptant et deviennent engageantes. Alors on se protège en prenant des marges démesurées, ou bien l’on dit ce que la personne qui commande a l’air de vouloir entendre, et advienne que pourra.
Si vous voulez mon avis, mieux vaudrait ne pas trop construire de planning là-dessus, d’autant que l’erreur d’estimation croit avec la charge estimée. De 25% pour un mois de travail (conception et développement), l’erreur passe à 50 ou 75%, parfois plus, pour une estimation initiale d’un an. Si cela vous choque, comprenez que chaque logiciel est une pièce unique, et que l’inconnu réside d’abord dans le choix de ce qui devra être développé, bien avant d’envisager le moindre aspect technique.
Quand l’imprévu est la seule certitude
Malheureusement, le tableau ne s’arrête pas là. En fait, vous ne savez même pas toujours de combien de temps vous disposez réellement, ni quels sont vos moyens. Vous pouvez effectivement envisager une livraison de votre MVP au terme d’un an de travail, mais considérez tout de même ce qui peut arriver :
- La concurrence vous oblige à livrer plus tôt que prévu, au bout de 6 mois par exemple ;
- Une personne quitte l’équipe, ce qui est d’autant plus gênant que la personne concentre le savoir (truck factor élevé) ;
- Vous avez surestimé votre capacité à produire : 8 heures de travail quotidien sont rarement autant d’heures de travail productif.
Ces « imprévus » vous mettront systématiquement en mauvaise posture si vous abordez le problème par le seul angle du temps, parce que le temps, vous allez en manquer.
Que faire, alors ? Êtes-vous condamné à subir ?
La réponse est un « non » catégorique. Certes, vous ne pouvez pas contrôler les aléas précédemment évoqués ; certes, les estimations sont une vaine tentative de retrouver du contrôle ; mais vous pouvez en revanche agir sur le cours des choses en découpant finement le travail à réaliser et en établissant des priorités claires, quotidiennement.
Autrement dit, votre seule solution est d’avoir toujours quelque chose sous le coude, au cas-où. Comme les Scouts, vous devez être « toujours prêts ». Qu’est-ce à dire ?
Reprenez le contrôle grâce à un découpage fin et des priorités claires
Si vous avez un an devant vous et que vous devez attendre 6 mois pour apprécier enfin l’avancement des travaux, il est probable que vous fassiez quelques insomnies. Votre problème, c’est l’effet tunnel : quand une voiture s’engouffre dans un tunnel, l’observateur extérieur ne sait rien de sa position tant que la voiture n’est pas ressortie. Autrement dit, tant que tout n’est pas fait, c’est comme si rien n’était fait.
Vous voulez donc de plus petits tunnels. Des tunnels d’un mois seraient déjà mieux, mais pourquoi ne pas viser le meilleur et envisager des tunnels d’une semaine, voire moins encore ? La beauté de la chose, c’est que cela ne tient qu’à vous, vous qui pouvez découper les fonctionnalités de l’application en fonctionnalités plus petites, que nous appellerons User Stories.
Ce découpage doit nécessairement apporter de la valeur à l’utilisateur : découper en tâches techniques est le principal écueil à éviter. Exemple : votre front end est parfait, mais il n’y a pas encore le back end qui va avec. Voilà qui vous fait une belle jambe : vous êtes pris par le temps et n’avez rien à mettre en production. Mieux vaudrait considérer une fonctionnalité plus petite et faire « un peu » du front end et « un peu » du back end.
Une User Story doit donc pouvoir être mise en production et apporter de la valeur à vos utilisateurs, même si c’est très peu. Et d’ailleurs, mieux vaudrait que ce soit très peu, car vous pourrez toujours faire plus après, mais au moins vous aurez déjà quelque chose à livrer en cas d’aléa.
En guise d’exemple, considérons une application de type CRUD (Create / Read / Update / Delete), c’est-à-dire un recensement d’items sans beaucoup de complexité de gestion. Pensez à Marmiton (des recettes de cuisine) ou au site de la SPA (des animaux en attente d’adoption). Si vous deviez mettre en place un tel site, comment découperiez-vous votre travail ?
- Create d’abord, puis Read : autoriser la création d’un item sans permettre sa lecture n’est d’aucune utilité pour personne, c’est la fausse bonne idée !
- Create et Read, simultanément : déjà mieux, on peut créer et lire des items. La valeur ajoutée est certaine, mais à la réflexion, on peut encore faire mieux ;
- Read d’abord, puis Create : surprenant, mais oui, parce qu’on peut temporairement faire des insertions à la main en base de données avant de faire une interface graphique pour cela. Un vrai premier pas dans l’Agilité.
- Et l’on pourrait aller plus encore dans le détail en redécoupant le Read : commencer par une simple liste et ajouter progressivement un pattern master/detail, des filtres, du tri, de la recherche full text, de la pagination etc.
Conclusion
Ayez donc pour objectif d’avoir le plus tôt possible quelque chose à livrer en production, même si ce n’est pas tout, même si ce n’est pas idéal, ce sera toujours mieux que rien. Priorisez agressivement : vous voulez A et B, bien sûr. Mais lequel voulez-vous si vous n’avez le temps d’en faire qu’un ?
Vous l’aurez compris, on ne gagne pas contre le temps. Découper finement votre travail et prioriser au jour le jour est votre meilleure arme pour retrouver du contrôle, et accepter par la même occasion une part de responsabilité dans le cours des choses.