什么是敏捷开发Scrum及其适用场景？

笔者根据自己对敏捷开发Scrum的理解，总结了敏捷开发从开始到结束的流程以及其适用的场景。

一、敏捷开发到底是什么

很难用一两句话说清楚敏捷到底是什么，也许因为它只是一套松散的框架，有原则却无具体方法，1000个项目可能有1000种敏捷的工作方式。敏捷只有在实践中才有意义，一旦脱离实际去学习就变得近乎玄幻。

最常被讨论的敏捷框架有3套：Scrum、Agile、看板。涉及到软件开发，尤其是面向C端Scrum和Agile更常见，看板方法擅长把繁杂琐碎的工作一目了然，例如客户支持这类事务性工作。

谈论Scrum不得不提到PDCA循环（如下图），这是一种擅长探索和创造的工作 方式，我认为Scrum正是围绕PDCA循环方式衍生出来的的一系列理念、原则和实践（如backlog、sprint、user story）。它不是方法论，更不是公式，也有一些方法体系，但可供参考却不该照搬，不同的项目可能需要非常不同但都可称为Scrum的工作流程。

（PDCA循环）

如果只用一句话描述Scrum，我认为是：充分接纳前景的不确定性，采取探索式前进，以为客户实现价值为最终目的的开发方法。重探索轻预测，这是和线性开发方式的本质区别。

Scrum步骤由一个接一个Sprin(迭代)组成，因此新手想要快速上手Scrum的话，也许最该学习的是一个Sprint(迭代)从哪里开始和结束，如下：

1. 拟定和评估待办事项清单

待办事项即backlog，我的团队叫需求列表/需求池，指可能要开发的功能列表。待办事项有时来自需求方，但更应该来自产品经理的远见和洞察。所有被提出的事项（无论是否看起来有价值）都不妨先放入清单，再进行维护。维护包括：

①评估需求价值、工期和紧急程度，去伪存真

②值得做的真需求排定优先级

③追踪处理进度。

如何维护一个健康的backlog涉及细节很多，不妨参阅我的另一篇文章《如何维护健康的需求池》

虽然我的团队习惯把待办事项称为“需求”，但我自己更喜欢《Scrum精髓》中的叫法——”价值“或者“特性”。”需求”在团队沟通中多指运营方而非用户的需求，暗示产品对运营负责，而且暗示了团队能预测产品的成功，这更符合瀑布式而非敏捷式方法；“价值”的叫法突出了敏捷的价值导向，为实现用户价值每个角色都负有不可推卸的的责任。“特性”的叫法则突出了敏捷的探索精神，承认当前在做的未必是用户真正需要的，只有检测后才有定论。“价值”和“特性”都更能体现敏捷原则。

2. 冲刺启动会

在上一步厘清需求优先级后，团队所有人（至少所有角色）坐下来规划下个迭代要做的需求，也就是消化需求表里优先级最高的需求。实际工作中，一些优先级不太高但是简单易做的需求也会见缝插针安排到下个迭代中，以求达到最大工作量。

经过充分沟通后，对于下个冲刺应该完成哪些内容大家都应该达成共识。启动会标志着冲刺的开始，一旦启动任何人都不应该改动冲刺内容。也就是需求一旦进入需开发阶段任何人不能进行改动。

为什么共识是进行敏捷的前提？

如果没有共识，重视沟通，多方参与——容易扯皮，允许在“冲刺”前修改方案——容易推卸责任或拖延工期，每个冲刺交付最小可行化产品——基于各自利益对最小可行化无法定义，测试和迭代时也难对成果和方向达成一致。

举例说明，如果某公司的开发团队承接来自ABC三个不同产品线的需求，ABC对用户价值的理解不同（都想让自己的产品线占用尽可能多资源），在整个公司层面实现敏捷是很困难的。但是可以通过融合方式——关键点评审+尽可能晚确定最终方案，来结合两种开发的优点

3. 每日立会

每天固定时间召集所有角色开一个简短会议，尽量不超过15分钟，目的是公告工作进展。

4. 成果展示和评估

开发完成并测试后，再次召集所有角色，展示成果，之后投入使用。

5. 冲刺回顾和新冲刺规划

已完成的事项，大家坐下来回顾看看哪些比较顺利，哪些可以做的更好。

回顾完成后立即开始下一个冲刺的规划。

二、敏捷和线性的本质区别

如上文所说，个人认为冲探索轻预测是敏捷和线性开发方式的本质区别。如下所示：

• 敏捷开发：关照不确定性→探索式，注重应变→价值中心
• 线性开发：关照确定性→遵守规程，注重良好设计→过程中心

敏捷开发承认环境、团队、用户和自身的不确定性，认为市场需求难以预测，因此包容试错、探索前进，在小步快跑中实时校对方向。校对的参照点是用户价值，是否能为用户创造价值作为评价工作的关键指标。

相对而言，线性开发关注确定性的内容，强调准确预测市场，根据预测进行尽可能完美的设计，设计出来的蓝图必须严格呈现，因此评价工作的标准也是蓝图实现程度，即使市场反馈可能并不尽如人意。

三、敏捷的适用场景

线性开发因为重预测，便于流程控制，但难点在于必须一开始就确定正确的设计范围；敏捷开发因为是探索导向的流程，可以不断深挖问题本质，提炼真正问题，但缺点是大项目跨部门时时间成本高。

由于敏捷方法以用户价值为目标，瀑布方法以完美呈现蓝图为目标，项目制团队中容易就价值达成一致，但是跨团队跨部门甚至跨公司的项目中，各方理解的价值未必一致。如果能就用户价值（也就是要交付的产品）达成共识，才能应用敏捷开发。如果无法达成共识，只能通过过程的控制减少沟通和时间成本，宜采用瀑布式开发。

根据优劣势，不管是敏捷还是线性开发都有其适用场景——常用于战略决策的Cynefin框架非常适合解释敏捷开发适用的场景，如下图：

1. 简单域（simple）-已知的已知

当因果关系显然而见时。处理手法为”感受－归类－反应” （Sense-Categorise- Respond），如导出销售额数据/制作巧克力蛋糕。Scrum不是好的选择，更应该选择已被证明正确的方法。

2. 繁杂域（complicated）-已知的未知

需要专家诊断后找出正确答案。处理手法为”感受－分析－反应” （Sense-Analyze- Respond），如搭建底层数据库/建造太空飞船。Scrum不是最佳方案，应该由专家处理。

3. 复杂域（complex）-未知的未知

因果关系只能从检讨中反映出来，难以预测，只能事后知道。处理手法是”试探－感受－反应” （Probe-Sense- Respond），如推出新产品/养育青少年。Scrum最擅长的领域。

4. 混乱域（chaotic）-不可知的未知

完全没有任何因果关系的混乱情况，需要快速做出反应，没有时间思考。需要的是”行动－感受－反应” （Act-Sense- Respond），如911事件/系统宕机。Scrum不是最佳方案，需要的是立即行动。

5. 如果连属于以上哪个情况都不清楚的，是一个无序的状态（disorder），等待参与者把情况安稳至上面四个其中之一的情况。

软件开发过程中可能涉及以上各个领域，但电商产品（尤其C端）大部分工作落在复杂域。需要实际工作中灵活适用。

本文由 @羊小双双 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: