Scrum度量的一些想法

今天看《平衡敏捷与规范》，想到另外一些可以着手准备的度量，先记录下

Scrum上的需求和任务都是明确的，Sprint会议应该做一些基础的度量，比如Task，可以根据下面的表来识别是否太粗的容易更容易延期，或者相反。（如图，数据是我杜撰的）

如果把任务按照设计、研究、开发、UI、测试等来分，可以得到更多的任务估算准确度数据。

另外，从需求方面来考虑，每个需求都会要分解成若干个任务，也可以从这里着手，来分析需求的变迁曲线，比如A需求，Sprint会议中确定的Task是否足够，最终完成时消耗的总资源和初始的资源比例，来识别最可能有把握的需求大约多大颗粒度。