敏捷影响的量化

本文是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。有关我的个人介绍,请看这里

Comments
Write a Comment