108 votes

Comment évaluer une tâche de programmation si vous n'en avez aucune expérience

J'ai des difficultés avec la direction à demander des estimations sur les tâches de programmation qui utilisent des contrôles tiers pour lesquels je n'ai aucune expérience préalable.

Je comprends vraiment pourquoi ils voudraient le budget, mais j’ai l’impression que toute estimation que je donne sera soit a) trop courte et me fera paraître mauvais ou b) trop longue et me fera aussi mal paraître.

Quelle estimation ou quelle réponse pourrais-je donner à la direction pour les sortir de mon dos afin que je puisse continuer à faire mon travail!

95voto

RB. Points 17993

La meilleure réponse que vous pouvez donner est de demander plus de temps de frapper un prototype rapide pour vous permettre de donner une estimation plus précise. Sans quelques expérience avec un outil ou un problème, une estimation vous donner est essentiellement inutile.

En aparté, il y a très rarement un problème avec le donnant trop longtemps une estimation. Les problèmes imprévus se produisent, les priorités changent, et que les besoins sont "mis à jour". Même si vous n'utilisez pas tout le temps que vous avez demandé, vous aurez plus de temps d'essai, ou peut libérer "précoce".

J'ai toujours été beaucoup trop optimiste dans mes estimations, et il peut mettre beaucoup de stress dans votre vie, surtout quand vous êtes un jeune programmeur sans l'expérience et la confiance en soi de dire les patrons des vérités qui dérangent.

41voto

JohnFx Points 23761

Je vais vous laisser sur un secret. Même si vous étiez un expert avec cette technologie, votre estimation est susceptible d'être très imprécise. Il est de la nature de la bête lorsque vous faites quelque chose qui est en soi un R&D de la tâche. Malheureusement, gestion de la tente souvent d'appliquer un modèle manufacturier et de la demande des estimations précises. Pour illustrer mon point de vue, considérer la difficulté à estimer avec précision les deux efforts:

Une Fabrication à une autre 11K parasols qui sont exactement les mêmes que les 2K vous concocter le mois dernier. B) la Conception d'un nouveau type de parapluie et de la construction de la première.

Le développement de logiciels est B, mais ils sont demander un devis en supposant que A.

Le meilleur que vous pouvez faire est de décomposer la tâche dans les plus petites pièces possible (pas plus de 1/2 journée chacune) et puis de tripler le nombre final que vous venez avec.(Spolsky Méthode)

Alternativement, Steve McConnell a un livre en entier (sans doute plusieurs) sur cet aspect de l'ingénierie du logiciel. http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351

32voto

Jim Blizard Points 3785

Steve McConnell (et autres) en parle sur le cône d'incertitude. En gros vous fournir une estimation qui ressemble à quelque chose comme ceci:

Le travail prendra entre 3 et 9 semaines à 4 semaines étant la plus probable.

À mesure que le projet progresse, vous pouvez affiner votre devis. Comme vous le faire plus de travail et de comprendre les efforts requis mieux, vous pouvez affiner votre devis pour être plus précis.

Il a travaillé pour moi, mais il peut exiger un certain effort pour obtenir d'autres parties prenantes dans le projet, afin de comprendre le processus.

13voto

tvanfosson Points 268301

Vous pourriez envisager de donner à la fois une estimation et un niveau de confiance, c'est à dire, c'est 50/50 qu'il va prendre de 3 à 6 mois ou de 6 à 9 mois ou 75% de chance d'être fait en 9 mois et 90% qui vous sera fait dans un an.

Une autre chose que vous pourriez envisager est à l'aide de la "sagesse des foules". Aller autour et demander 25 à 50 personnes combien de temps ils pensent qu'il va prendre et la moyenne de leurs estimations. Mike Cohn du Planning Poker est, je pense, très similaire à cela, bien que difficile à plan avec un seul développeur.

12voto

Patrick Cuff Points 13362

Briser votre devis en:

  • Connu appelés; combien de temps cela prend-il pour faire ce que vous savez comment le faire. Vous devriez être en mesure de donner cette estimation avec un degré de confiance élevé.
  • L'inconnu connu; combien de temps pensez-vous qu'il faudra pour faire ce que vous ne savez pas comment faire. Vous pouvez utiliser une méthode comme dacracot est de donner différents niveaux de confiance sur cette estimation.
  • Inconnu inconnu; c'est le temps réel du trou noir. Ce sont les choses que l'arrière jusqu'au plus mauvais moment et vous mordre dans le cul. Fournir une gamme pour l'estimation, la justification fondée sur les risques que vous prévoyez.

Offre d'ajuster l'estimation et certaines étapes le long du chemin. Toute l'inconnu inconnu deviendra l'inconnu connu, l'inconnu connu devraient être connus appelés comme vous acquérir de l'expérience, et que l'estimation des vous connu appelés peuvent être ajustées sur la base des progrès réalisés à ce jour. Vous pouvez faire une estimation initiale, puis de le ré-estimer quand vous environ 25% de fait, puis de nouveau à 50%, puis de nouveau à 85%. À chaque étape de votre estimation devrait commencer à converger sur le temps réel les tâches à prendre.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X