Comment évaluer son temps de travail ? Petit sondage

[flexbox]

Bonjour à tous,

“Combien de temps ça prend ?”

Je travaille en agence web (on fait de l’agile toussa toussa mais ce n’est pas le scope du sujet). On me pose cette question tous les jours. Personnellement plus j’avance et moins je suis capable de répondre à cette question.

Je vais prendre un cas concret :

• Intégrer un carrousel de photos

Facile me direz-vous un coup de bower install et on en parle plus, hop c’est “juste un carrousel met 2h”.
Sauf que l’équipe créa va pondre un design de la muerte, le responsable SEO des recommandations sur le DOM et le client veut absolument le partage Facebook de la photo courante.

J’aimerais savoir comment faites-vous pour évaluer les demandes ? Avez-vous un “framework”, des astuces ? J’essaye de découper au maximum les tâches mais ce n’est pas vraiment efficace (Et je parle pas de travailler sur du legacy code qui est à mon avis un autre sujet).

[ethan]

J’avais lu quelque part que les estimations de temps de dev étaient inutiles car incorrectes dans 90% des cas… Mais le fait est qu’on est bien obligé de fixer une date de livraison pour le client et donc d’estimer le temps que vont prendre les différents développements pour le prochain delivery.

J’essaie d’estimer par rapport à ma connaissance du projet sur lequel je travaille. Le soucis c’est qu’il faut aussi intégrer les temps de validation et de dev qui suivent si la validation ne donne pas de résultats concluants… Donc généralement c’est au feeling, par rapport à mon estimation de la complexité du développement (complexité métier, complexité du code, potentiels effets secondaires, etc).

[amarandon]

Une méthode qui marche pas trop mal :

1. découper en sous-tâches

• estimer chaque sous-tâche
• faire la somme
• multiplier le résultat par deux

[benjamin_bnds]

En amont, tu peux estimer davantage en amont et impliquer le client dans les phases d’avancée, notamment dans la spécification.

En aval, tu peux voir si globalement tes estimations ont été bonnes, si en moyenne elles sont à x% de la réalité (ex : moyenne à 80%, tu as estimé 8j mais livré en 10j).
Tu peux aussi avoir une idée globale de la vie d’une tâche, et faire sortir une moyenne avec une variance faible du temps de livraison.

[vdaubry]

Vous faites déjà de l’agile, je te conseille donc d’utiliser à fond les estimations par complexité relative :

• Garde une estimation en points de chaque tache de ton projet. Quand on te demande une estimation prend quelques taches et demande toi “est ce que ça semble plus complexe ou moins complexe”, ne fais pas ces estimations directement en heures ou en jours mais toujours en points.
  Pour prendre des engagements sur des dates de livraisons base toi sur la vélocité que tu constates après quelques itérations.
  Assez vite tu obtiens une estimation qui n’est plus basé sur tes prédictions (souvent fausses…) mais sur du constaté (la réalité ;)

• Idem pour estimer des projets, compare les à d’autres projets

• Les aléa que tu évoques sont toujours présents : un coup c’est le design, un coup c’est la feature cachée, un coup le bug mystique, plus tu auras de taches avec lesquels comparer, plus tu pourras faire une moyenne de ces problèmes et lisser ces écarts

Et comme ça a été dis plus haut prend toujours une marge d’erreur et annonce la dès le départ, c’est rassurant pour tout le monde de savoir si on a une marge d’erreur ou si le projet est en risque dès le départ.