什么是敏捷开发？

敏捷开发到底是什么

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

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

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

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

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

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

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

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

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

③追踪处理进度。

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

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

2. 冲刺启动会

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

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

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

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

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

3. 每日立会

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

4. 成果展示和评估

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

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

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

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

Tracup - 便捷的团队协作，轻量的项目管理， 完备的问题系统，大容量的文件存储，Tracup 都是您更加优雅高效工作的理想的团队协同平台 - 软件开发团队协作系统，帮助您连接整个公司，连接任务、沟通、文档、代码等工作场景为您规划、跟踪和发布卓越的软件。