Si oui pourquoi ? Combien ?
J’ai tendance à gonfler mine un peu parce que je peux être trop optimiste.
Réponses
Trop de publicités?
EBGreen
Points
14478
Tamas Czinege
Points
49277
Oh oui, j'ai appris à toujours multiplier mon estimation initiale par deux. C'est pourquoi l' outil de planification basé sur des preuves de FogBUGZ est vraiment utile.
Sarah Mei
Points
10673
Toute organisation qui demande à ses programmeurs d'estimer le temps pour les gros grains de fonctionnalités est fondamentalement brisé.
Étapes à unbreak:
- Location de technique, les gestionnaires de programme. Les développeurs peuvent doubler comme ces gens-là si nécessaire.
- Mettre toute demande de fonctionnalité, demande de modification, ou d'un bogue dans une base de données immédiatement quand elle vient. (Mon org utilise Trac, qui ne répond pas complètement à chier.)
- Votre PMs briser les demandes en suit que chaque de prendre une semaine ou moins.
- Lors d'une réunion hebdomadaire, votre PMs décider lesquels des billets qu'ils veulent faire de cette semaine (éventuellement avec la participation de marketing, etc.). Ils attribuent ces billets pour les développeurs.
- Les développeurs de finir comme beaucoup de ses billets que possible. Et/ou, affirment-ils avec le PMs sur les tâches qu'ils pensent sont plus d'une semaine dans la durée. Les billets sont ajustés, split, réaffectés, etc., en tant que de besoin.
- Le Code est écrit et vérifié chaque semaine. QA a toujours quelque chose à faire. La priorité la plus élevée des modifications se fait en premier. Le Marketing sait exactement à quoi s'en viennent, et quand. Et en fin de compte:
- Votre entreprise est sur le côté droit de l'20% de taux de réussite pour les projets logiciels.
Ce n'est pas la science de fusée. La clé est l'étape 3. Si le marketing veut quelque chose qui vous semble compliqué, votre PMs (avec le développeur d'entrée) comprendre quelle est la première étape, il faudra moins d'une semaine. Si le PMs ne sont pas techniques, tout est perdu.
Les inconvénients de cette approche:
- Lors de la commercialisation de demande: "combien de temps faut-il pour obtenir [X]?", ils ne pas obtenir une estimation. Mais nous le savons tous, et eux aussi, que les estimations qu'ils ont obtenu était de la pure fiction. Au moins maintenant, ils peuvent voir la preuve, chaque semaine, que [X] est en cours d'élaboration.
- Nous, en tant que développeurs, qui ont moins d'options pour ce à quoi nous travaillons sur chaque semaine. C'est sans aucun doute vrai. Deux points: tout d'abord, de bonnes équipes impliquer les développeurs dans les décisions sur ce que les billets seront attribués. Deuxièmement, l'OMI, cela rend ma vie meilleure.
Rien n'est plus décourageant que de réaliser à l'1 mois que les 2 mois de l'estimation que j'ai donné est complètement inadéquat, mais ne peut pas être modifié, car il est déjà dans le marketing officiel de la littérature. Soit je pisse au large de la plus-ups par mon changement d'estimation, de risquer une mauvaise critique et/ou manquant de mon bonus, ou je fais beaucoup d'heures supplémentaires non rémunérées. J'ai réalisé que beaucoup d'heures supplémentaires n'est pas la marque d'un mauvais développeur, ou la marque d'un "passionné" l'un - c'est le produit d'une culture toxique.
Et oui, beaucoup de ce genre de choses est couvert en vertu de (diversement) XP, "agile" SCRUM, etc., mais ce n'est pas vraiment compliqué. Vous n'avez pas besoin d'un livre ou d'un consultant pour le faire. Vous avez juste besoin d'avoir la volonté.
Steven A. Lowe
Points
40596
La règle de Scotty:
- faire de votre mieux
- arrondir au nombre entier le plus proche
-
double cequadruple (merci Adam!) - augmenter à l'unité de mesure immédiatement supérieure
Exemple:
- vous pensez que cela prendra 3,5 heures
- arrondis à 4 heures
- quadruple à 16 heures
- reporter à 16 jours
Ta-daa! Vous êtes un faiseur de miracles quand vous le faites en moins de 8 jours.
