由于各种原因，一些团队的Scrum开发节奏做成了下图1这个样子，前面有一个很长的Sprint做需求和架构准备，然后再进行所谓的开发Sprint。
图1
在Scrum的实践中的确有Sprint 0 的概念，但是使用它要很小心，它指的是在Sprint开始之前需要给团队一个小的提前量，让团队能够准备好一个初始的产品Backlog。这个初始的Backlog绝不是一堆大而全的需求说明书，而是根据产品的愿景和当前最高优先级的一些需求得到的一个足够团队1-2个Sprint开发的产品Backlog, 这个产品Backlog中最重要的需求都是经过细化、经过梳理和估算的。
使用Sprint 0 不当，就会导致打着Sprint 0 的旗号，在Sprint开始之前加上一个长期的需求、分析、甚至设计的阶段。这样就违背了敏捷及早交付、增量交付的初衷，有可能导致我们做了过多的前期工作，而没有及早获得客户、用户或者市场的反馈， 从而发生比较大的偏差。
那么有人会问，在Sprint开始之前是否需要做一些架构论证的工作？ 架构论证的工作的确是有必要做的，但是不建议在Sprint开始之前单独花很长的时间来论证。架构最终的目的是为了满足业务需求，特别是最重要的业务需求或者叫做关键业务点，比如是否有技术门槛或者是否可以满足用户体验的要求等，我建议把这个放到Sprint中来验证，因为迭代本身就是不断试错、不断验证的过程，基于业务目标的架构验证更有价值，我们要避免过度的架构设计，做过多的假设和猜测。
Sprint开始前的其它的一些工作，比如研究这个项目是否需要做、申请预算、组织调整、组建团队、购买设备、安装工作环境等工作的确是必备可少的，由于组织的各种原因，它的跨度可能比较长，但这些不属于项目的交付工作的范畴，可以考虑在Scrum项目启动之前设立单独的项目来运作。
本文作者：
廖靖斌 Eric Liao， CSP，CSM，知名敏捷教练、顾问、培训师
