敏捷的本质在于短和小

预计阅读时间:3分钟

敏捷开发有什么特别的?早几十年前就有迭代开发的概念了。

用户故事和需求文档里的功能点有什么区别?瀑布模式也是一个个功能点做的呀。

持续交付有什么特别?就算是瀑布模式,也经常分阶段(Phase)发布。

产品小分队(Pod)和传统的团队(Team)有什么区别?所有的IT团队都是对齐业务的边界,对接一个大的产品或服务范围的啦。

以上问题都忽略了一个重要问题,就是规模(Size)。

不错,迭代开发真的不是新的概念,其历史几乎跟瀑布模式一样久远,但是敏捷开发的不同之处就在于它是迭代开发。短迭代意味着反馈周期短,从而实现快速试错,持续演进,确保产品完全满足业务需要。如果可以,迭代的周期应该越短越好,可以一周一个迭代就不要两周(当然需要根据实际平衡相应带来的开销)。每日站会、持续集成、测试驱动编程等实践也是为了把反馈周期缩到最短,实现快速反馈。

用户故事最重要的特点之一就是。它应该是可以实现一定业务价值的最小可交付工件,是一个短迭代内能够交付的东西,否则就需要进一步拆分。用户故事是否足够小,也是实现真正敏捷和持续交付的重要条件之一。

在瀑布模式下确实也经常分阶段发布,但每个阶段的间隔可能是一个月甚至几个月,每次发布的范围依然很大,风险很高,其惊吓程度和一次性发布(Big Bang)不相伯仲。持续交付的不同之处就在于把发布周期缩短到每月、每周甚至每日,由于每次发布的范围非常,风险小,回滚也容易,这也是最有效的风险控制手段。

产品小分队也必须是可以独立交付特性的最队伍,也就是所谓的“两个烧饼团队”(2-pizza team,两块披萨能喂饱这个团队)。队伍越大,沟通成本就越高,步伐也越慢(同样到达一个地方,5个人一同前进一定比20个人要快得多,也灵活得多)。在满足能够独立交付一个特性,对外依赖小,具备自治能力的前提下,维持最小的队伍规模,保持内部沟通和交付的高效率。

因此,要说敏捷和传统模式有什么最本质的区别,答案就是(不要想歪)。所谓量变带来质变,不要小看这个“规模效应”。如果你的交付效率出了问题,请审视:

你的迭代周期和反馈周期是否太长了?

你的用户故事是否太大了,能不能进一步拆分?

你的发布周期是否太长了,每次发布范围是否太大了?

你的队伍是否太大了,有没有进一步拆分的余地?

关于作者

早期敏捷践行者

起步于极限编程

熟悉极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发

关注公众号

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180429G10K1U00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券