标签:软件估算
估算项目周期,软件行业做项目必备节目,也是每个开发人员在职业生涯中无限循环的痛。
没有经验的开发人员对估算任务这件事来说都带有深深的恐惧,估多了显得自己无能,估少了deadline做不完脸上无光。怎么办?
其实项目的所有干系人,都想得到一个靠谱的估算:
1. 老板需要需要一个估算衡量根据公司现有资源值不值得做这个项目。
2. 市场人员需要根据估算来计算招标成本。
3. 项目经理希望更准确的估算来规划工期。
4. 开发人员希望自己准确的估算来告别无休止的在“最后期限”前的加班。
如何精确的估算项目,这在以前是个玄学,因为有大量因素影响估算结果:
1. 老板说这个项目对公司很重要,一定要在XX月前完成!
2. 销售说竞争对手功能比我们多,报价比我们低,我们也要赶上!
3. 项目经理被老板搞得压力很大,也要求开发估算“时间扣的紧点,不行咱就加班”。
4. 开发被要求1,2天内给个大致结果,没有足够的时间分析需求。
5. 此处省略若干
现在仍有大量公司的项目或多或少存在以上问题(拍脑袋定日期),那么作为工程鼻祖的基建工程是怎么做的呢?
先看下传统工程领域的方式。工程领域对基建项目的概预算计算已经有很成熟的一套做法,并且有国标手册可以查。如我要建设一个通信基站,里面要安装几套设备,设计院如何估算开支?
分2个步骤:
1.估工作量
这些东西都可以根据手册先查出这些东西的工作量(如大到某个工程机械的工时,小到安装一个设备需要技工多少工时)。根据工作性质还能查出做这个需要几个工人,得到总工时。这些最后都能根据一个价格表对应上查出最终预算价格。
2.估材料损耗
做这些活,要用多少材料,材料的价格,也可以根据手册来查,查完了计算器一算,填表计算即可。
量和价是分开的,无论什么年代,人干的量基本是不变的,变的就是每若干年调整一下的人工材料价格,充分体现了面向对象封装变化的思想。
工程上能这么做是因为大部分项目脱不出这些看得见的工作,前期报价能根据以往经验大致估出一个差不多的造价成本。
软件领域由于没有实体易修改的特殊性,估算则不确定性比较多,如:
1. 客户开始也不知道自己要什么
2. 客户知道自己要什么,但做着做着想法就变了
3. 开发组织自身的情况制约(人力资源,硬件资源,内部支持)
4. 开发人员水平参差不齐(多出现于临时拼凑的团队)
5. 组织对于质量的看重程度,越重视则流程越重,速度越慢
6. 双方企业文化的契合度(直接影响合作)
7. 不熟悉的项目领域
8. 不熟悉的技术领域
9. 新的编程工具
10. 团队成员能否不受打扰全神贯注
如果还不知道自己在谈论什么,那么期望谈
论的事达到精确是没有意义的。
— 约翰·冯·诺依曼
做估算首先要要知道估算的目的,估算的首要目标并不是预算项目的结果,而是确定项目目标是否能实现,并且在实施中通过项目控制来可控的达到目的。
业内常用的估算方法有:专家估算,功能点估算,story point估算等。总体的思路都是一样,将粗粒度的需求拆成细粒度的技术功能点,反复递归直到任务为一天到半天的量,再汇总, 标准的分而治之策略。这里就不讨论具体的方法,可以直接看下《软件估算:黑匣子揭秘》这本书,很多疑问可以在这本书里得到解答。
计算机科学是一门实践科学,先有理论支持,再通过实践进行论证及研究。现在一线开发人员都在忙于业务系统的开发,干的是“编码工人”的活,甚至将同样的代码从一个项目挪到另一个项目,认为满足工作需要就行;其实遇到问题适当进行一些理论的研究,就像练内功,内功扎实了,才能无招胜有招。
文章来自微信平台「麦芽面包」。转载请注明。
标签:软件估算
原文地址:http://blog.csdn.net/darkjune/article/details/46495225