Ne demandez plus "combien de temps ça va prendre ?"
Demandez-vous plutôt si vous pouvez découper encore un peu plus votre travail.
Déjà, que vous vouliez l'entendre ou non, personne ne sait estimer quoi que ce soit tant les incertitudes sont grandes : les incertitudes fonctionnelles, que l'on devrait pouvoir minimiser, et les incertitudes techniques, notamment dues à la dette.
D'autant que les estimations sont un 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 en disant ce que la personne qui a l'air de commander veut entendre, et advienne que pourra.
My two cents: mieux vaudrait ne pas trop construire de planning là-dessus, et ce d'autant plus que la charge envisagée est grande. Vous pouvez effectivement envisager une livraison au terme de 3 mois de travail, mais considérez tout de même ce qui peut arriver :
- Vous devez livrer plus tôt que prévu (parce que la concurrence, parce que telle autre fonctionnalité urgente dépend de vos développements) ;
- Vous perdez une personne dans l'équipe (départ, réaffectation sauvage due à votre chef bien-aimé ou que sais-je) ;
- Vous avez bêtement moins de temps que prévu à consacrer au développement (parce que ces fichues réunions, quelle surprise).
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.
Quel est le problème, au juste ? 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.
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 ne pouvez pas faire cette mise en production a minima, qui vous aurait pourtant sauvé la mise.
Votre seule solution est donc d'avoir toujours quelque chose sous le coude au cas-où. Cela signifie découper encore, toujours, plus, si si j'insiste, votre travail.
L'exemple précédent ne fonctionne pas parce que "front-end" et "back-end" sont des tâches techniques. Nous voulons au contraire des User Stories, dont on rappelle la définition :
-
Dans "User Story", il y a "user". Une User Story doit donc apporter de la valeur aux utilisateurs et pouvoir être mise en production ;
-
Une User Story est atomique : il n'est pas possible de la redécouper en User Stories. En tâches techniques oui, mais pas en User Stories.
Exemple : une application de type CRUD (Create, Read, Update, Delete), comme Marmiton (des recettes de cuisine) ou le site de la SPA (des animaux disponibles à l'adoption). Comment découper ça ?
- C + R + U + D : la fausse bonne idée, parce que permettre la création sans la lecture, ça ne sert à rien ;
- CR + D + U : déjà mieux, on peut créer et lire, mais CR ça fait peut-être un peu beaucoup d'un coup (front-office + back-office) ;
- R + C + D + U : un vrai premier pas dans l'agilité, parce qu'on peut temporairement faire des insertions à la main en base de données avant de faire un back-office pour ça ;
- Mais en fait il faudrait aller encore plus dans le détail et redécouper le R : partir sur une simple liste et ajouter progressivement un pattern master/detail, des filtres, un moteur de recherche, de la pagination etc.
Accessoirement (ou pas), découper plus vous permettra d'avoir plus de feedback utilisateur, vous évitant bien des développements inutiles. Le temps est précieux, autant ne pas le gaspiller.