敏捷影响的量化

本文是Rally公司2013年从9629个使用Rally软件的团队中总结抽取的报告，（所有的报告是基于数据的，所以）非常有参考价值。

我简单翻译总结了一下：（英文版的报告）

全文分为四个维度:

1. 生产力翻倍

关键发现：稳定团队带来如下结果 –

• 提高60%的生产力
• 提高40%预测性
• 提高60%的响应能力

建议：

• 每个人全心投入到一个团队中
• 保持团队完整稳定

我的反思：

• 针对上面的发现和建议，结合软件开发的现状。应该加强产品化思维，减少项目方式（做项目的时候是一个团队，做完了团队就散了）。

2. 质量提升250%

关键发现：

• 做全Scrum的团队比不做估算的团队质量提高250%
• 轻型Scrum团队（只估算故事点而不估算任务小时数）整体表现更好。（文中提到针对成熟的敏捷团队）

建议：

• 有经验的团队可以从轻型Scrum获得最好的结果。
• 如果是敏捷新手，或非常注重质量，选用全Scrum

我的反思：

• 虽然最近一年，看板（Kanban）方法越来越火，但个人感觉看板虽然简单，实施起来实属不易（比Scrum用起来更难–貌似越简单的东西，用起来越难）。所以如果我个人推荐的话，还是考虑先从Scrum入手。

3. 上市时间（Time to Market）缩短一半

关键发现：有效控制在制品（WIP）的团队—

• 流程中的时间（比如用户故事在研发流程中）缩短一半
• 只有1/4的缺陷
• 但是生产力低34%

建议：

• 如果在制品太高了，那就降低它
• 如果在制品已经很低了，考虑经济驱动因素：
  • 如果生产力到达底线（注：生产力已经不能再低了），那么不要降低在制品数量
  • 如果上市时间（TTM）到达底线，继续降低在制品数量

我的反思：

• 在制品数量不能无限度的降低，当每个人的在制品是0-1时，生产力会大幅下降。经济合理的在制品数量是每个团队成员1-2
• 总结上面两条，当降低在制品数量没有显著影响到生产力时，继续降低在制品（WIP）
• 针对软件行业的大多数团队，在制品数量都是较高的。因此，降低WIP往往能带来意想不到的效果。
• 推荐一本好书，Don Reinertsen的《The Principles of Product Development Flow》。详细介绍了产品开发中的经典理论，有很多都是反思维了，看了很受启发。

4. 均衡的团队效能

关键发现：较小的团队（1-3人）比建议规模的团队（5-9人）具有如下特征–

• 质量下降17%
• 但是生产力提高17%

建议：

• 建议5-9人规模的团队，以得到均衡的团队效能
• 如果当前较大规模的团队运行良好，则不需要变化。

我的反思：

• 根据沟通路径复杂度，当团队成员增加时，沟通路径成指数增长。所以当团队规模超过15人时，团队内往往会形成信息孤岛，不利于团队的效能。

最后贴个小广告，如果您需要敏捷培训–请联系我：jiangxb@gmail.com。有关我的个人介绍，请看这里。