[原创]项目简要总结

作者：人月&神话

2007/9/28 20:31:23

过程无法让你成熟，过程是帮你发现问题，通过团队和自我学习走向成熟。

过程和结果谁重要，着眼于短期利益结果重要，但基于长远专业化发展必须注重过程得规范和积累。

强调过程不是扼杀个性，正如强调法律是为了获取更大的自由。

1.项目进度和周期

估算，变更和未知风险对项目进度有重要的影响
项目大多数任务的粒度周期应该为项目周期的10%－15%
在项目前期跟踪频率适合为项目周期的10-15%,后期适合为5-10%
在发现进度偏差后要选择根源而不是仅仅应急的解决偏差

2.缺陷和Bug的密度

系统测试阶段的Bug密度为3-5个/KLOC代码比较适宜。
对Bug的分析很重要，应该转换为后期的培训和规程的完善。
Bug本身也有质量，对Bug本身质量的关注应该多于对单纯缺陷密度的关注。

3.缺陷泄漏和缺陷移除

需求缺陷的泄漏和发版后的泄漏故障是两个重要的关注点。
对缺陷泄漏的关注应该多于对缺陷密度本身的关注。
COPQ是重要的考察指标，当COPQ和估算差距不大的时候说明缺陷移除较好。

4.需求变更情况

需求变更引起实际工作量增加才是一个重点考察指标。
用户需求挖掘，非功能性需求，业务规则是最容易引起需求变更地方。

5.开发生产率

编码生产率在250-300行/天。总生产率在100-150行/天。
统一开发模式和框架，能够复用的全部抽取为黑盒复用是形成组织PCB基础。

6.软件产品的规模

规模是整个估算的基础，规模估算不准确直接影响到总体工作量估算。

迫切需要统一需求用例编写的粒度，形成可用的规模数据。最近改进中已经形成以用例总流数作为规模的改进。

7.评审的作用

对可设计和实现性评审比较好。但对于可测试性和非功能性评审需要加强。
评审是从多角度看问题，重点是发现遗漏，而不是帮作者解决责任心的。
缺陷的泄漏情况是评审是否有效的关键指标。
要在评审有效情况下尽量减少评审工作量，现阶段数据看评审工作量比重偏大。

责编：人月&神话