过程无法让你成熟，过程是帮你发现问题，通过团队和自我学习走向成熟。
过程和结果谁重要，着眼于短期利益结果重要，但基于长远专业化发展必须注重过程得规范和积累。
强调过程不是扼杀个性，正如强调法律是为了获取更大的自由。
1.项目进度和周期
估算，变更和未知风险对项目进度有重要的影响
项目大多数任务的粒度周期应该为项目周期的10%－15%
在项目前期跟踪频率适合为项目周期的10-15%,后期适合为5-10%
在发现进度偏差后要选择根源而不是仅仅应急的解决偏差
2.缺陷和Bug的密度
系统测试阶段的Bug密度为3-5个 OC代码比较适宜。
对Bug的分析很重要，应该转换为后期的培训和规程的完善。
Bug本身也有质量，对Bug本身质量的关注应该多于对单纯缺陷密度的关注。
3.缺陷泄漏和缺陷移除
需求缺陷的泄漏和发版后的泄漏故障是两个重要的关注点。
对缺陷泄漏的关注应该多于对缺陷密度本身的关注。
COPQ是重要的考察指标，当COPQ和估算差距不大的时候说明缺陷移除较好。
4.需求变更情况
需求变更引起实际工作量增加才是一个重点考察指标。
用户需求挖掘，非功能性需求，业务规则是最容易引起需求变更地方。
5.开发生产率
编码生产率在250-300行/天。总生产率在100-150行/天。
统一开发模式和框架，能够复用的全部抽取为黑盒复用是形成组织PCB基础。
6.软件产品的规模
规模是整个估算的基础，规模估算不准确直接影响到总体工作量估算。
迫切需要统一需求用例编写的粒度，形成可用的规模数据。最近改进中已经形成以用例总流数作为规模的改进。
7.评审的作用
对可设计和实现性评审比较好。但对于可测试性和非功能性评审需要加强。
评审是从多角度看问题，重点是发现遗漏，而不是帮作者解决责任心的。
缺陷的泄漏情况是评审是否有效的关键指标。
要在评审有效情况下尽量减少评审工作量，现阶段数据看评审工作量比重偏大。转贴于：http://www.leadge.com