一、需求池统一

无论是小团队，还是由多个小团队组成的大团队，一个团队应该只面对一个需求池而不是多个。
拿SAFe为例：一列发布火车（多个小团队组成的大团队）只有一个需求池Program Backlog，一个小团队只有一个需求池 Team Backlog。
道理很简单，因为我们需要把这个团队要做的所有工作放在一起混合排序，才能够避免不小心先做了优先级低的工作，因为多个需求来源会导致需求之间的相对优先级不可见或者识别困难。

二、需求描述采用用户视角

需求从用户的角度拆分和描述，而不是从技术的角度。这样一条需求完成了，就能够提供价值，甚至是能够上线。


三、需求进出顺序一致

需求进入团队的顺序要大体上跟需求从团队出来的顺序是一样的。否则需求的排序就会失去意义，也就无法尽早交付更高价值的东西。

这一条看起来简单，实际上是一个综合指标，团队至少要：

  • 按需求优先级启动工作；
  • 协作顺畅。团队成员之间或团队之间的依赖和阻碍识别要早，排除要快，等待要少；
  • 互相帮助。如果某个优先级高的需求在中间卡壳了，那么整个团队要想办法快速排除障碍，个人自扫门前雪是不会达成这个效果的。

四、需求流转时间短

需求从进入团队到出来的时间越短越好。
这一条反映了团队的响应速度。这是一个综合指标，团队至少要：

  • 需求拆小；
  • 同时进行的工作少；
  • 风险识别早；
  • 阻碍清除快；
  • 重流动效率，轻资源效率；
  • 工作不过周末（否则白白增加2天时间）；
  • 互相帮助。

    五、迭代完成百分比高

这一条反映团队兑现承诺的可能性。不要求100%，不过80%还是需要有的。
这也是一个综合指标，团队至少要：

  • 需求拆小；
  • 计划合理（不能不顾过往的能力，使劲儿往迭代里面塞活，寻求心理上暂时的“踏实”）；
  • 依赖识别和处理到位；
  • 风险识别和处理到位；

  • 工作流畅。

    六、迭代速率平稳

    这一条反映团队的工作的稳定性，不要求每个迭代速率相同，但要大体在某个中心值上下合理波动。平稳的迭代速率有助于做出更加合理的规划。
    这是一个综合指标，团队至少要：

  • 人员稳定；

  • 跨职能团队；
  • 互相补位；
  • 工作有节奏；
  • 坚守完成的定义。

说明
这里只是列出了一些典型的研发侧的考量点。真正的端到端的业务敏捷还要考量价值以及业务侧敏捷的行为和参与度，这些就不在本文中赘述。
另外，数据的获取也是一个难题，因为很多数据是可以造假的，给数据观察带来干扰，这是另外一个维度的话题了。