?
大部份管理者都说关心项目的延误（或项目总工作量），也说很关注产品的质量（例如：金融/银行 /保险等）。
但是当问到过去一年项目的实际延误情况如何质量如何r> 很多管理者没有头绪。
怎样做才能解决上述问题呢strong>
做好项目估算(estimation)
管理者说：项目经理都有做预估——按每个项目功能数量，识别其中的复杂度，再乘以相关的生产率便得出项目的总工作量（人天），难道这样不是做好了项目估算吗p>
解答:
复杂度怎样制定/定义r> 生产率用多少是什么r> 过程有没有记录strong>
(聪明的您应可猜后面的对话,. . . .注意：我接触过的，用公式来估算的公司已是很少，更大部分是直接“估算”项目工作量和工期）
软件开发估算为什么不简单strong>
一个好的估算应该是不同的人做出来的差不多。但现实是，有很多因素会影响，例如：
项目规模的大小，会因为理解不同，估算结果也不同。
此外，人手与生产率的关系是否成正比一倍人手，生产率就提高一倍吗p>
其实软件开发中有不同的阶段，生产率在编码时候达到高峰，但到了系统测试阶段，因没有新增代码，生产率反而变下降，所以在软件开发中,用以下的基本方程没有想象那么简单:
工作量= 规模 / 生产率
成本(人力) = 工作量 * 人工率
日常我们进食时会考虑食物的卡路里；
使用汽油时会考虑汽油每公升可跑多少公里；
使用电脑时，会考虑它的CPU速度
以上的度量有三个共同点：
– 都是直接可看见或可数得出的
– 95%以上的人都会觉得重要
– 低于1%的人会了解背后的真正计算方程式
既然关心进度、生产率、质量等，让我们看看软件开发可以如何做好度量与估算:
从管理角度，软件开发主要关心下面几个指标：
– Schedule 时间 / 进度
– Effort 工作量 / 成本
– Size 规模大小
– Quality 质量
– Process Productivity 生产率
它们之间的关系在30年前已经有人研究过了：关系是一定有的，但并非简单的线性关系，还会因项目性质不同、行业不同等，有很大差异。
所以没有一套全球通用的计算法则，但公司可以依据下图：
先估算项目的总规模 (图左上角)，依据以往历史项目数据，调整预测模型 (calibrate)，便可以估算出项目的时间、工作量和缺陷率等 (图右面的估计)。
备注一：团队人数——如果是几个人的小团队时候，通常是所有人从头到尾参与项目，这些人的个人生产率高低会影响项目进度、工作量等，即影响图的右面，所以个人生产率也是其中一个输入。如果是大型项目人数会从少到多，达到一个峰值，再减少；项目高峰时的人数会影响右面的估算。
备注二：软件规模——估算应该在每个主要阶段都要做，例如：开始时要进行初步估计；需求确定后，可依据功能点进行具体估算；开发完成后，可以从实际代码算出规模。不要把规模和项目总人天混淆，因前者和人员的能力无关。
问题：这种度量方法是否只适用于传统的大型开发项目，但我们现在很多项目都走迭代和敏捷，是否还适用span>
回答：
虽然这些是依据传统的中大型项目得出，但道理是一样，但需要变通。因在敏捷中，一般团队人数少而且较固定，所以是估计整个项目的所需时间（多少次迭代）。
以前分阶段的工作（需求、设计、编码、测试等）都合在一个迭代中，简单来看可以看成把N个瀑布叠在一起，每次包含了瀑布的所有阶段，例如以前缺陷是分到不同阶段中（单元测试、集成测试、系统测试），现在每次冲刺可能只记录了最终的缺陷数。
每次迭代测试找出来的缺陷数，下一次同类的迭代，预计缺陷数也类似。
大家可以利用以上的框架不断收集公司的历史数据优化。便可以有系统地改善项目的估算模型。
问题：如何度量软件开发的规模大小span>
回答：
最早是用代码行，但有不少缺点。
从70年代开始出现了功能点数，它解决了：可否重复 (repeat)、可否全项目周期前后都适用等不足。
但有些人觉得比较复杂，要花时间学习。
可能正是这原因，在敏捷中出了很多规模/总工作量估算的简化版：故事点、 T恤码、扑克牌. . . 但主要依靠团队一起判断，缺乏公司级历史数据，与公司生产率标杆的概念。
问题：为什么我们建议使用功能点来估算规模span>
回答：
无论做任何事，都是一个从0到1的过程。首先建立0，再向1前进。
用功能点来代替故事点或者代码行，只是一个零的概念，就他们两个是对等的，因此实现了之后并没有增值。
但如果指出做了功能点之后，到底又会发生什么事情些事情是原来完全做不到的，那么这时候就出现了1。
从实际应用层面来看，使用了功能点以后：
我们就可以横向比较公司和团队的生产率，从而进行绩效管理；
从质量的角度，规模可作为质量的分母，可以算出每功能存在多少缺陷数；
也可以让客户更理解项目的大小，用来合理地 价。
一位老师很开心地说：“本来以为功能点要教个两三天，但昨天在一堂课中只花了两个半小时便简单地教懂了。开发主管很感兴趣，希望再安排现场辅导。”
总结
度量与估算可能一直都是困扰软件开发管理者的一个重要课题，但总觉得太复杂，以上我们分享的只是冰山一角。
Weinberg先生在《咨询的秘密》中说得好，如果过程中所需的数学是高数程度或以上，你应该问问自己是否需要r> 度量在软件开发中一直未被重视其中主因是太复杂了，人们搞不懂所以就不用。
这方面，我们急需的不是如何利用大数据分析、神经 路、machine learning 等把估算的准确度降低10-20% ，而是如何简单地让大家做项目管理的快速用上。
如果您正好有这方面的需求，我们会有一系列关于度量与分析、估算的FAQ/模板等， 让大家可以快速简单地用于项目中。
有兴趣，可到我们 站：http://www.processis.org/Home/Index/coursesflist看相关的培训信息，也可以以下列方式联系我们，获得资料。
联系我们
电话：18921395967QQ：1228021190微信：processis2009地址：香港/北京/江苏官 ：www.processis.org邮箱：claire@processis.org
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！