敏捷方法中采集的度量数据

原因分析与解决方案（CAR）是对选中的现象识别原因，并采取纠正措施或预防措施。 基本的思想：组织内的好事和坏事都可以做CAR，并非仅仅是对坏事做CAR。可以在计划阶段做CAR，也可以在事情发生后再做CAR， 前者是根据估计的结果做CAR，后者是根据实际执行的结果做CAR。在做原因分析时，是从现象，到数据，然后再到原因。数据准确刻画了现象，并有助于识别真正的原因。原因有浅层次的直...

很多公司头疼需求变更，如果我们采用定量的技术该如何分析需求的变更呢？首先定义什么叫需求变更？在客户方与开发方共同认可需求之后的需求修改、增加、删除都是需求变更。需求变更对象可以从多个维度划分: 维度一: 功能需求、非功能性需求、接口需求、界面需求、技术约束等； 维度二：业务逻辑、数据对象、控制逻辑等；其次，可以从3个层次分析需求变更：层次1： 需求变更率分析。需求变更率有多种定义方法。 方法一：需求变更率=需求变更的个数/交付的需求个数；...

  合理的度量需求变更的规模是COSMIC方法比第一代的功能点估算方法更科学的亮点。在度量需求的变更时，首先需要明确我们的度量目的，即我们要度量的是本次变更的规模，而不是变更之后的规模。明确目的后，要将变更的需求按照功能处理拆分，在一个需求变更中，可能存在几种情况：  1 新增的功能处理，此时按照前面讲的度量方法识别功能点即可；  2 删除的功能处理，被删除的功能处理的功能点个数即是本次变更的规模...

         在CMMI2.0发布之前就想针对2.0的每个PA进行解释，但是拖延了下来，恰好春节之前有客户开始实施了CMMI2.0，有客户和同事与我探讨2.0中的内容，在解释的过程中，就形成了文字，索性就想把每条实践都解释一下。于是，就给自己定了目标，在春节期间把20个PA都解释完成。实际去做的时候，发现没有那么容易。一是时间是否有保证，二是我自己也需要对模型的某些描述反复阅读，提炼，查阅资料...

某公司承担一个大型软件项目的开发，该项目的计划工期为2年，实际工期为2.5年。该项目为本公司新进入的一个行业，公司在其他行业里有相近软件的开发经验，但是对进入的这个行业并不熟悉。本项目采用了瀑布模型，高峰期70多人参与，最少时也有30多人参与。投入了接近100人年的工作量，而浪费的工作量大概在25人年，需求返工的比例占了40-50%。项目结束后做了复盘，我作为外部咨询顾问参与了项目回顾...