背景

目前，Scrum和看板已成为了帮助团队贯彻敏捷的重要方法，我们也能经常看到敏捷爱好者在关于二者在各类社区、场合的讨论。无论是交流分享还是企业的咨询实施，关于Scrum和看板的讨论就一直没有停歇过。那么，对于一个正准备实践敏捷的团队，到底应该如何选择呢？

问题分析

一般来说，客户会纠结Scrum和看板的选择问题，主要是因为不清楚Scrum和看板方法的区别，不知道哪种更适合目前的项目或团队，也不清楚Scrum和看板方法能应对哪些场景。

首先，从Scrum和看板方法的比较来了解两者的不同，见下表：

描述	Scrum	看板方法
目的	探讨未知，处理新的、复杂项目	自我检讨、消除浪费、得到好的效能
团队角色	产品负责人，Scrum Master，开发团队	没有指定的角色
度量指标	团队速率	生产周期、WIP（在制品）
多变性	承诺在Sprint周期不发生改变	变化随时可能发生
交付周期	固定的Sprint时间盒	完成一项工作的时间

表： Scrum和看板方法的特征比较

如上表所示，Scrum和看板方法在不同方面特征有所不同，企业在选择使用Scrum和看板方法的时候，可以根据上表中二者的特征并结合不同的实际情况，做出选择，具体参考如下情况和详细解释：

情况	Scrum	看板方法
团队所做的项目VUCA、需要一定的可预测性	√
团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级		√
项目需要有固定的迭代交付时间（2到4周）	√
项目的初期探索迎合市场的阶段	√
团队规模较小（不足5人）或较大(9人以上)		√

表： Scrum和看板方法的选择

情况1：团队所做的项目VUCA、需要一定的可预测性

在VUCA（详见参考附录中的解释）的时代，很多团队做的是易变的、不确定的、复杂的、模糊的项目，如互联网项目。针对于这样的特性，团队如果需要在某特定的时间发布或推广产品，以达到一定的市场预期的话。团队一般会将需求进行拆分和细化，如 Epic、 Feature、 User Story 、Task后，制定发布计划。随着拆分为较小的需求后，团队可以通过检查每个Sprint的进度并进行调整，从而预测交付时间，进而确保整个项目成功交付，Scrum是首选的方式。

情况2：团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级

Scrum的价值观之一是，承诺在Sprint内对计划不做修改，如果团队经常会应对紧急情况或者修改任务的优先级，那么看板方法因其灵活的工作流程可以更好的适应。

情况3：项目需要有固定的交付时间（2到4周）

在Scrum中每个Sprint的时间长度是固定（2到4周），并且每个Sprint结束后会交付潜在可交付产品增量，如果项目需要有固定的交付时间（2到4周），那么Scrum是比较好的选择。

情况4：项目的初期探索迎合市场阶段

以市场为导向的产品，产品越年轻，使用Scrum方式就越可能受益。因为在开发全新产品，尝试实现PMF（产品市场契合）或努力保持产品增长时，通常面临许多未知因素以及大量不确定性和变化。要通过迭代不断的输出增量以获取市场的反馈，进而更快更好的迎合市场的需求，所以Scrum是比较好的选择。（详见参考附录中的Scrum适合你的项目吗？）

情况5：团队规模较小（不足5人）或较大（9人以上）

Scrum团队理想的规模是2个披萨团队，给出的建议是5到9人，如果团队不足5人，在人员方面可能无法发挥Scrum的最大功效或存在一定上的浪费，那么建议使用看板方法。（Scrum of Scrums 不在此FAQ讨论范围内。）

解决措施

目前很多企业和团队，都是通过工具在实践Scrum或看板方法，华为云的DevCloud也是基于敏捷思想设计的DevOps工具链（更多了解请见附件或官网），以DevCloud为例，在DevCloud中提供了更加鲜明化的Scrum项目和看板项目的选择，具体可以参考根因分析中针对不同情况选择不同的项目（详见，表： Scrum和看板方法的选择）

从目的来说，Scrum主要是为了探讨未知，处理复杂（VUCA）项目从而提升效率，而处理和效率的字眼往往是和时间关联起来的，如要在一个什么样的时间得到什么样的结果，这也是要求了时间把控上或者说做计划的能力，当团队所做的项目为了这样的目的，那肯定是选用Scrum，哪怕团队的规模没有达到Scrum所推荐的5到9人，或者是团队要为估算所浪费的时间开销而苦恼，又或者说在一个Sprint中需求经常变更等情况。因为不管是人数的问题也好、还是估算的问题也好、又或是需求变更的问题都是可以通过团队在回顾中不断的分析、复盘、总结慢慢优化的，如估算问题，那就提高估算能力减少开销；如时间开销问题，可以通过熟练度的提升、形式的改变来较少开销。总之，只要核心是不变的或者说关注点是围绕Scrum目的就应选择Scrum项目，典型项目有：新的应用程序开发、品牌发展、营销活动、具有季度/定时发布时间表的大型企业等。

相反，如果团队的关注点就是以优先响应需求的能力，需求是必须要随时跟进和变更的，项目的可预测性、产品市场的契合度等的优先级并没有成为超过响应能力的话，那么看板项目就是一种更好的选择，因为这正是看板方法的优势，让价值能够快速的流动起来，以更快的满足客户的需求，典型项目有：生产支持、补丁发布、UX设计、营销宣传材料、新闻稿等。

所以，对Scrum项目和看板项目的选择上，一定参考的是客户认为最重要的关注的点是什么。以目的驱动做响应的选择。

另外，在DevCloud的Scrum项目也提供了看板的视图，可以很好的在Scrum的项目中使用看板方法，进而让Scrum可以和看板有效的结合起来，发挥更强大的效能。

在DevCloud中， Scrum项目是以Scrum框架为核心的，提供用于处理探讨未知，处理新的、复杂项目的项目类型。Scrum项目提供了类似思维导图的方式，用来整理需求做项目规划，并提供了Epic 、Feature 、Story、Task的四级需求划分，如下图。

【DevCloud · 敏捷智库】Scrum和看板如何选择