管理层要求对使用我之前没有经验的第三方控件的编程任务进行估算时遇到困难.
我当然明白为什么他们会想要这些估计,但我觉得我估计任何估计要么a)太短而且让我看起来很糟糕或者b)太长并且让我看起来很糟糕.
我可以给管理层什么估计或回复让他们离开我的背部,这样我就可以继续做我的工作了!
您可以给出的最佳答案是花时间敲一下快速原型,以便您提供更准确的估算.没有一些工具或问题的经验,你给出的任何估计基本上都没有意义.
另外,给出太长的估计很少有问题.出现意外问题,优先级发生变化,需求"更新".即使你没有使用你所要求的所有时间,你将有更多的测试时间,或者可以"提前"发布.
我的估计总是过于乐观,它会给你的生活带来很大的压力,特别是当你是一个没有经验和自信的年轻程序员告诉老板不舒服的真相时.
我会告诉你一个秘密.即使您是该技术的专家,您的估计也可能非常不准确.在做一些固有的研发任务时,这就是野兽的本性.不幸的是,管理层经常试图应用制造模型并要求准确的估算.为了说明我的观点,请考虑准确估算以下两项工作的难度:
A)制造另外11K的雨伞,与上个月生产的2K完全相同.B)设计一种新型伞并建造第一种伞.
软件开发是B,但他们要求估计假设A.
你能做的最好的事情是将任务分解成可能的最小部分(每个不超过1/2天),然后将你想出的最终数量增加三倍.(Spolsky Method)
或者,Steve McConnell在软件工程的这方面有一本完整的书(可以说是几本). http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
史蒂夫麦康奈尔(和其他人)谈论了不确定性的锥体.基本上你提供的估计看起来像这样:
这项工作需要3至9周,最有可能是4周.
随着项目的进展,您可以优化您的估算.当您完成更多工作并更好地理解所需的工作时,您可以将您的估算更精确.
它对我有用,但可能需要一些努力才能让项目中的其他利益相关者理解这个过程.
您可能需要考虑同时给出估计值和置信度,即50/50表示需要3-6个月或6-9个月或75%的机会在9个月内完成,90%表示您将在在一年内完成.
您可能想要考虑的另一件事是使用" 群众智慧 "方法.到处询问25-50人他们认为需要多长时间并平均他们的估计.我认为迈克科恩的计划扑克非常类似于此,尽管只有一个开发人员难以计划.
将您的估算细分为:
已知的知识 ; 做你知道怎么做的需要多长时间.你应该能够高度自信地给出这个估计.
已知的未知数 ; 你认为做你不知道该做什么需要多长时间.你可以使用像dacracot这样的方法对这个估计给出不同程度的置信度.
未知的未知数 ; 这是实时黑洞.这些是在最不合时宜的时候出现的事情并且在屁股上咬你.根据您预期的风险提供估算范围和理由.
提供调整估计和沿途的某些里程碑.任何未知的未知数都将成为已知的未知数,已知的未知数应当在获得经验时成为已知的知识,并且可以根据迄今为止的进展调整已知知识的估计值.您可以进行初步估算,然后重新估算约25%完成后,再重新估算50%,然后再重新估算为85%.在每个里程碑,您的估计应该开始收敛任务的实际时间.
我为我的估计使用了一个明确的标签系统...... A类,B类和C类.
C级估计是他们得到的第一个.由于未知数,它被公开表示为正负50%.如果他们希望我继续给他们一个B级,那么我需要钱来研究.
B级为正负25%.有时这很好,他们给我钱建设.如果没有,更少的钱和更多的研究.
A级是正负10%,最后一个是去还是不去.如果它是一个去,我偏离估计太远我经常和早期承认.
我认为,如果您删除"正在使用我之前没有经验的第三方控件"这一短语,您可能会更好地描述您的大问题.
如果"敏捷"告诉了我们任何事情,那就是,如果管理层希望你持续不断地估算项目,如果你说因为你没有,那么你会"看起来很糟糕"足够的信息,你在失败的高速公路上.
最大的问题是你无法控制的问题,以及你还没有确定的问题.你多久回头一次对自己说:"好吧,我在按钮上做出了我的估计 - 在第三次尝试之后,我发现了......我需要版本......并且dba将会打开假期一个星期,项目经理需要我......一个星期,而我的妻子怀孕了......".
我真的很难说,"我可以确定关键的风险因素,并提出一份可交付成果清单,以便在xx天内对其进行测试.届时我会给你另一个增量估算."
如果你可以建议他们应该"请坚持认为我将来不会试图给你一个可信的估计类型,那将是非常好的.如果我尝试的话就解雇我."
(过分夸大,但只是略微.)
甚至不要试图估计.您的估计没有任何正确的方法.毕竟这只是一个估计.
我建议您将功能分成小块(不超过1-2天),并尝试将这些部分作为工作,完整,可测试和有价值的代码提供给客户/经理.这样他就能亲眼看到你日常的进步.这也意味着他实际上可以决定一旦满意就停止开发并考虑完成,即使它可能没有达到所有目标.
查看敏捷实践"发布计划"和"迭代计划",以获得有关此方法的更深入信息.
请记住,如果您要求更长的时间估计但是在时间上做出来,它看起来比估计时更好并且不得不要求延期.
我会尝试模拟原型,以便您更好地了解它将花费的时间.诚实地对待您的管理层,以便他们可以预算学习曲线中的意外延迟.
编辑:您可能还会看到是否可以获得更"迭代"的截止日期.在"务实的思考与学习"中,安迪·亨特提出了一个很好的观点,即人们是项目专家,接近项目的最后阶段,而且从一开始就知之甚少.当每个人都对项目知之甚少时,从一开始就进行所有的设计和时间估算没有多大意义.如果你"迭代"截止日期并以块的形式解决问题,你将获得更多成功.
很多准确的估计是自我认知.如果您编写了大量代码,如果您必须学习很多API,那么您就会开始感受到以下问题:
学习新API需要多长时间？
学习一门新语言需要多长时间？
学习新工具集(编译器/链接器/ IDE)需要多长时间？
实施典型任务需要多长时间？
我需要多长时间来测试我的工作？
部署我的工作需要多长时间？
在整个过程中,您应该了解以下事项:
您创建了多少典型的错误以及它们的分类方式(即简单,困难,不可能)
引入了多少并发症(即,由于缺少第三方API或错误的API需要重构;需要重新设计,因为对功能的误解;非标准工具/构建过程)
由于中断/外部问题而损失了多少时间
基于所有这些事情,您将能够了解某事物需要多长时间并且能够陈述您的假设("假设API是理智的......"),即使面对可悲的不完整信息.
估计你需要多长时间来学习,以便做出更好的估计,例如,"我不知道:我以前从未使用过这个.我可能会在这里插入你的估算,以便弄清楚是什么你需要先了解一下我必须知道的事情,然后才能给你一个很好的估计,用它来完成你的项目."
京公网安备 11010802040832号 | 京ICP备19059560号-6 