Partage d'expérience sur l'établissement d'un devis de réalisation logicielle
Bien le bonjour,
Aujourd'hui, je souhaiterais lancer une discussion qui aurait pour issue aucune bonne ou mauvaise réponse. Le but est juste de partager son expérience sur un sujet qui fait souvent peur/râler/fuir les développeurs : la création de devis et estimer des tâches.
Peut-être que ce type de discussion a déjà été lancé auparavant. Si oui, modérateurs, faites-vous plaisir.
Pour commencer, je vous présente ma manière de calculer aujourd'hui. Pour être honnête, elle change très régulièrement.
Mon contexte est que je dois effectuer un devis pour toute une équipe de développeurs.
----
Définition du besoin avec le client
La première chose que je fais est que je pars à la recherche d'informations auprès du client.
Ma stratégie est donc qu'une fois que le client exprime son point de vue, je le transforme avec plus détails que je lui repropose. Ce n'est pas une spécification mais on s'y approche. Cela permet de stimuler le client sur son idée/sa réflexion. Ici, déjà, beaucoup de développeurs râlent déjà du fait que ce n'est pas à eux de définir le besoin mais au client. Personnellement, je pense que c'est naïf de penser cela. N'hésitez pas à réagir là-dessus.
La durée de cette échange ne doit pas être trop long. Il ne sert à rien de rédiger des spécifications dès maintenant. Ça crame du temps potentiellement pour rien si le client n'en veut finalement pas.
Ensuite, à partir des éléments retenus, je commence la phase estimation.
Manière de calculer
Pour une demande, j'identifie généralement 4 types d'activités : dev, test, doc, autre.
Pour chaque activité de type dev, j'y rajoute 75% de temps en plus pour les tests unitaires.
Pour chaque activité de type doc, j'y rajoute 20 à 30% de temps d'aller-retour avec le client.
Avec le total de tout ça (dev + test + doc + tests unitaires + échange doc), je rajoute :
- 20% de temps de maintenance (correction, support interne, support CI, etc) ;
- 15% de temps de gestion (Product Owner, préparation des tickets, etc) ;
- 30% de temps d'incertitude (mauvaise estimation, imprévus, montée en compétence, etc) ;
Au total de tout cela, du fait que l'équipe fonctionne en Agile avec la méthode SCRUM en sprint de 2 semaines, je rajoute 25% de temps de réunions.
Ce chiffre comporte les cérémonies Scrum (Sprint planning metting, Sprint review, Sprint retro, dailys = ~1j / personne tous les 4 jours) et toutes les autres réunions & discussions de l'équipe (~1j /personne tous les 4 jours). Ce chiffre a été confirmé par l'expérience sur plusieurs sprints.
Donc au final, pour une activité de type :
- dev = dev * (1 + 0.75) * (1 + 0.20 + 0.15 + 0.3) * (1 + 0.25) = dev * 3.61
- doc = doc * (1 + 0.30) * (1 + 0.20 + 0.15 + 0.3) * (1 + 0.25) = doc * 2.68
- test = test * (1 + 0.20 + 0.15 + 0.3) * (1 + 0.25) = test * 2.06
- autre = autre * (1 + 0.20 + 0.15 + 0.3) * (1 + 0.25) = autre * 2.06
On constate un facteur entre 2 et 3 pour chaque estimation de réalisation. Pour le moment, ce chiffre est confirmé par l'expérience. Mais en fonction des projets, des équipes, du client, ça peut changer.
Par ailleurs, à tous cela, je rajoute des temps de livraison (freeze du code, validation, livraison).
Manière d'estimer
Lorsque j'estime une activité dev, test, doc, autre, je prend en compte ma connaissance, ce que j'imagine, l'expérience des imprévus (même sur les tâches faciles), que quelqu'un avec un niveau différent s'y collera, etc.
Une fois que j'ai estimé tous les besoins du client, je vais embêter l'équipe avec une réunion dédiée afin qu'ils stressent mes chiffres. Ainsi, du fait des expériences et des connaissances différentes de chaque, nous obtenons des chiffres plus réaliste. Le fait de faire une première estimation de mon côté en premier permet de stimuler l'équipe lorsque nous en parlons. Sinon, on risque d'avoir des réactions du type "bof", "c'est impossible", "je ne sais pas", "ça dépend", etc.
Pour moi, la personne qui gère le devis doit faire partie de l'équipe de réalisation. Sinon, c'est sûr que ce sera faux/truqué.
Validation du devis
Si une activité est détectée comme trop imprécise en l'état, hop, je vais embêter le client. Mais toujours en lui proposant des solutions/actions. Sinon, il ne saura pas répondre/statuer.
Ensuite, je vais proposer ces chiffres au client. On en parle, discute, défend nos idées. Normalement, le client sélectionnera des idées et d'autres non.
Je refais un devis en enlevant les idées non-retenues. Le client, normalement, signe. Et seulement là, j'écris les mini-spec pour que l'équipe sache où aller. Celles-ci sont indicatives. Autrement dit, elles peuvent évoluer en fonction des événements dans l'équipe ou du client => Agile.
A vous
Cela peut paraître complexe comme cela. Mais au final, cela répond plutôt bien à la réalité de mon équipe. Peut-être que cela pourrait être simplifié et/ou amélioré.
Le sujet est très complexe, et aucune méthode ne sera générique. Voici donc mon partage d'expérience.
J'espère que le sujet intéressera.
A vous !
