敏捷洋葱规划不是银弹

原文先发在我的个人公众号上：https://mp.weixin.qq.com/s/5KdrEdOgWfX-EMP9RRVDmA

敏捷洋葱规划，这名字有点扯淡，我是生怕没法跟这几天的热词挂上钩，没人看我的文章，本来用技术化语言应该用“敏捷估算与规划”，考虑到比较熟悉，应该用“洋葱图”，思来想去，干脆拼在一起。追热点的效果如何，大家留言来跟我说说吧，喜欢不喜欢，尽管直言，不必顾忌。

前几天在敏捷教练小伙伴们群，一位小伙伴抛出了一篇文章“也谈敏捷需求”，另一位小伙伴则提出来说引用里面应该提到《Scrum 精髓》，因为文章里面的贝壳图案来自那本书。问题是，这个图也叫洋葱图，最早是在Mike Cohn的《敏捷估算与规划》书里面提出来的，至少我所知道的最早的出处是那里。对的，就是下面这本书：

对的，就是下面这张图，从外向内的英文意思分别是战略、产品组合、产品、发布/版本、迭代、每日：

然后群里就展开了比较激烈的讨论，100来条消息吧，也不算多，但紧接着，貌似好几个群里都在讨论类似问题。今天轮到我来抓住这即将消失的热度，再补上一篇文章吧。

我最开始实践敏捷，是2005年底或者说2006年1月的时候，在诺基亚杭州3G研发中心，也就是说是通信行业的背景。关于这段经历，可以看看“诺记敏捷之前世今生”这篇文章。直到2008或2009年左右，身边交流最多的，也都是通信行业的朋友们居多，或者说是一些稍微传统点的行业里面从事研发的人。对于我或者大家来讲，似乎对于这个敏捷规划的洋葱图并没有任何的不适感，觉得非常自然。

原因也简单，因为对于我所处的IPA2800产品（MGW/RNC 的平台）来说，就是从公司战略导出来多款通信产品的路线图，然后由路线图来制定各自产品的版本规划，而且往往同时会有多个版本并行，服务于不同客户或局点。

一个版本，在内部往往是以 Program（项目集/项目群）的性质进行管理，Program 可能会跨越多个系统，比如我们当时有个敏捷试点就是涉及米兰的驱动层、杭州的平台层和印度的应用层，Program 拆成各部分的项目进行管理，我们杭州部分当然就是按照 Scrum 的 Sprint 模式来运作啦，也就是洋葱图上的迭代部分。

而我们的Sprint，在试点阶段，1个星期、2个星期、4个星期的长度周期都尝试过，后来当领导们决定整个 IPA 产品部转型敏捷的时候，就是标准的9人Scrum团队、4个星期的Sprint，而通信产品的故事规模也大得很，我们团队做过最大的需求就是整个团队1个Sprint只能做1个故事，这种情况下，我们必须做每日的计划，也就是每天检查工作进展并调整计划，不然拖到最后，必然导致 Sprint 延迟或失败。

当时，我把这个模型当成是自然而然，无需质疑或者说认为它是普适的、绝对正确的。尤其是当时了解到PMI的主张，也是产品-项目集-项目的层级结构，就更是觉得这应该就是标准答案。后来跟西门子通信合并，在文化和工作方式磨合过程中，我意识到，西门子的项目模型和我们的不一样，他们是产品下面有项目，项目下面有 Program，术语看起来一模一样，就是大家理解的意思不同，沟通当然费劲。那是我第一次意识到，原来洋葱模型不是普适的，原来看似“你懂的”东西别人真的不懂，而这个差异靠“加强沟通”是无法解决的，它是在更深层地方存在着差异。

再后来，我离开诺基亚，开始自己的顾问生涯，接触到不同行业的客户。其中给大众点评服务的经历让我发现原来用户故事实践也不是普适的，当然，这里不是要讲用户故事。互联网的服务经历让我发现，互联网所说的版本、项目、产品跟我以前在通信行业以及其他一些较为传统的行业所说的意思，有很大的不同。

通信行业的版本，往往是大型产品的某个基线版本复制一份，针对某个客户或某批需求进行开发，版本与版本之间，没有必然的演进路线。版本不止意味着代码的某个分支或标签，还意味着管理大量的人力、任务、文档等各种东西。而我当时理解互联网所说的版本，就是指在前一版本基础上增加了部分功能的产品代码或软件包，版本与版本之间一般都是串行演进的关系，而且版本一般颗粒度都不大（尤其是跟通信行业相比），一两个星期甚至一天之内就会发布一个版本甚至多个版本。而且，Release 这个英文，本身就可以解释为版本、发布两个意思，然后这两个意思，放在不同行业语境下，差异又被放大了。在互联网行业，发布往往意味着发布上线，增加了功能的系统或产品是要部署到生产环境，让用户可以使用到新增功能的。而对于通信行业，或者更准确的说是当时通信行业所遵守的Scrum/敏捷的方法论和实践来说，则没有要求一定要系统上线，比如 Scrum 说的就是“潜在可发布的产品增量”。

至少对于通信行业和互联网行业来说，版本与迭代的关系是天差地别的不同。通信行业，版本可能包含一个到多个项目周期，一个项目周期可能包含一个到多个迭代，折算下来就是一个版本可能包含一个到多个迭代。对于互联网行业来说，这个关系是颠倒过来的，一个迭代可能发布一个到多个版本，而且迭代还比通信行业的短，一般1-2周的迭代居多。

所以，你说，敏捷规划的洋葱图，是不是宝典？是不是银弹？是不是普适的？

我觉得不是。

更不要说，在最开始那几年，我认为这种规划拆解结构的背后，还有一个潜在的需求，就是要从上往下对齐时间周期，保持统一步伐。接触敏捷较早的同志可以回想一下，有无探讨过多个团队的Sprint周期要不要对齐，同一天开始、同一天结束？

而对于彼时的互联网，如今的云化开发，这种结构，似乎已无意义。毕竟，都微服务了、两披萨团队了，解耦都解开了，还对齐个啥呢？就算要对齐，也不是采取这种自上而下的对齐模式，而是自下而上的信息共享、服务开放的对齐模式。

你说是不是？