|
锁定老帖子 主题：估算那点事
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-03
1.永远不要做过于乐观的估计。因为程序员天生傲气，以为所有的问题都不是问题；其实你只要碰到一个难题，就会打乱你的进度。
2.估计是要经验的，类似的项目做的越多，估算越准。 3.考虑公司的平均工作效率；哪怕你确实只需要一周，但是你估计同样的需求在公司一般需要一个月，你应该说一个月；然后在第三周末交付。 |
| 返回顶楼 | |
|
发表时间：2012-01-04
njbble 写道 可以借鉴一下敏捷开发原则，构建周期越短越好，交付周期越短越好，最好2周一个版本，小计划精确到小时，大计划最多1、2个月，频繁的跟客户、产品经理、需求人员沟通，让他们也参与到项目中来，这样最大可能避免了交付时出现大量未达到共识的问题，防止项目进入恶性循环。
这个不错啊~但是有个问题呀~。每次开发完毕之后，客户有可能增加了新的模块，新模块又比较重要，但是你之前定好的一些功能还没有做，这样，你又不得不重新去排一下项目模块的顺序。“频繁的跟客户、产品经理、需求人员沟通” 这个比较难！构建周期也不是说越短越好把。。看具体项目而定。 兄弟，推荐你看本书<Head First软件开发>还不错.呵呵~ |
| 返回顶楼 | |
|
发表时间：2012-01-09
写的挺好的！！我现在听到估算，我都头大！！
|
| 返回顶楼 | |
|
发表时间：2012-01-10
研究过点估算的飘过
写写我的感觉 1. 坚持一个原则，绝对不要拍脑袋估算。也就是说，在只有一个概要设计的时候，绝对不可以看看文档，估个三五个人月。 如果你只能这样估，我可以教你个诀窍。估完后记下来，和最终结果做个比较。一般来说会少估50%甚至66%。你将来再报的时候可以根据你的想法把你的第一念头乘以2或者3再报出去。 2. 一定要计算。所谓的计算，就是利用历史数据估算出总的规模数，这个规模数可以任意。可以是代码行数，功能点数，你喜欢那个就哪个。 然后你可以根据历史算出你的组员的平均生产效率。具体来说就是你计算用了多少人日完成了多少代码行。完成不是说Coding完成，而是从设计到测试全部完成。 这个数字由于是从历史数据统计出来，所以可以非常精确。比如平均一个人1个月完成2000行代码。结果就是2000行左右，项目越大越接近平均值。 总的规模数除以平均生产效率你就可以得出所需要的人月数。这个数字还要经过调整，一般时间紧迫，运用没掌握的技术的情况下，需要适当的分别加5%-10%。 难估的是总的规模数，这个你需要利用行业数据，根据自己公司的情况调整，或者最好的就是利用公司数据。一般都是利用参数法或者FP算出总的规模数。如果你参数选的准确，可以达到非常精确的水平。我们项目的最好情况是和实际情况的误差在1%。 接下来可以提供一点行业数据。 当你只有一份概要设计，一般就是一个PPT文件的时候，估算误差可以在正负50%之内，一般比较好的项目管理的话应该在正负30%之内。这是必须和客户说明的。 当你有一份外部设计的时候，估算误差不应该大于正负10%，当误差超过15%的时候，项目失败的风险非常大，你必须及时纠正，切记！！！ 最后和你签署的合同也有关系。如果签署的是闭口合同，切记一定要明确需求，不能明确需求的情况下要做好风险预案，留出缓冲。 |
| 返回顶楼 | |
|
发表时间：2012-01-10
估算过大或者估算过小都是失败的，估算过大意味着你浪费了资源，抬高了成本。很多人会把1个人日的工作量估2,3天，这是不容许的。放纵这种行为意味着你会被老板骂。切记！
估算失败是很经常发生的事情，这种情况需要及时纠正。加班是最后的手段。 因为加班一般也就多工作2,3个小时。从整体的人月数来说，一般最多能cover掉10%-20%的工作量。而估算失败一般都是偏差在50%以上。所以切记不要一有问题就加班。先要分析，然后重做计划。 |
| 返回顶楼 | |
|
发表时间：2012-01-11
lenozhi 写道 llyzq 写道 我个人的经验是，很多项目做到最后才明白这个项目为什么要做，要做成什么样子，哪些人会左右项目 哈哈，顶这句。企业应用，电子政务类的项目更是如此。 有的项目在开始的时候，没有人知道该做成什么样子，这个时候就需要需求方直接参与到项目中来，进行快速的迭代，让需求方在验证软件的时候慢慢清晰自己的需求，应该要超越原型开发。 |
| 返回顶楼 | |
|
发表时间：2012-01-11
个人经验，按照三点估算方法来做，先估计一个最乐观的时间A,再估算一个最可能的时间B，再估算一个最糟糕的时间C，然后做加权平均处理。 那么完成这件事情比较准确的估算时间为：(A+4B+C)/6
|
| 返回顶楼 | |
|
发表时间：2012-01-13
momoko8443 写道 教你个歪门邪道。
做计划时候用两份schedule，一份给程序员看，一份给老板看。都懂得~~ 此乃正道，给自己预留一些buffer是必须的 |
| 返回顶楼 | |
|
发表时间：2012-01-17
最后修改：2012-01-17
个人观点，软件项目不管怎么估算，结果都是不靠谱的，因为这里面不确定因素太多，而可以作为基准的因素却太少。
比如，工程量的度量标准是什么？ 这就没有定论。代码行数or特性数？不同语言的代码行数能等价换算么？不同的特性工作量可能相差几个数量级。 人的因素是估算的最大难点， 开发人员的生产率度量标准又是什么？ 这取决于程序员的工作经验、工作态度、对该项目用到的技术的熟练程度、目前的身体状况、心情和精神状况。上述几个因素都是没有度量标准的，而事实是不同开发人员生产率也可以相差几个数量级，那还估算个球啊！ BA、架构师、测试人员也与此类似。 外部因素也导致无法做出靠谱的估算，比如客户业务水平、配合度、办公环境、遗留系统的情况…… |
| 返回顶楼 | |
|
发表时间：2012-01-18
小项目 适合 敏捷开发，频繁的跟客户、产品经理、需求人员沟通，让他们也参与到项目中来， 大项目不太适合，再说，敏捷开发 适合 大公司，小公司的人员水平可能不够。。。。。。
|
| 返回顶楼 | |
