导言：在产品攻略系列文章中，我们已经介绍了门径管理、精益产品开发、IPD三种产品开发方法。从特点上来看，这三种方法都是相对完整的一套体系，覆盖了产品研发中的大多数要素。但是，面对快速变化和充满不确定性的市场环境，产品研发体系也需要补充新的方法以解决新的问题。接下来，我们将探讨两种能够更好应对不确定性的开发方法，本文介绍其中之一：敏捷方法。
文/张炜（华沣管理研究院研究员、资深咨询师）
在日常工作中，我们都遇到过这种情况：你需要在短时间内完成一份报告，没有参照模板、应该写成什么样也不完全清楚。你迅速完成了第一稿并提交给上司审核；上司给予修改意见，也可能要求你推倒重来；你按照意见再完成一稿，然后再次提交。如此往复几轮后，在双方共同打磨下，报告最终定稿。
这份最终定稿的报告，可能与你和上司一开始的构想并不完全相同，但通过双方不断地沟通和修改，形成了双方都满意的结果。这个常见的场景，与本文要介绍的敏捷方法有几分相似。
01
敏捷方法的出现
1. 瀑布模型
在谈敏捷开发之前，我们花一点时间了解一下“瀑布模型”。
瀑布模型是在软件开发中最早被采用、同时应用最广泛的开发模型。早期的软件开发过程存在着随意性和不规范性，软件质量及交付及时性都难以保证。为了解决这些问题，Winston Royce在1970年提出了著名的“瀑布”（Waterfall）开发模型。
这种模型的本质是一种结构化的线性模型，它将软件开发过程严格划分为需求分析、设计、实施、验证及维护五大阶段，就像“瀑布”一样逐级下落。
但在实际使用场景中，瀑布模型也存在以下问题：
客户在早期往往很难清楚定义需求，因此不能保证最终开发出的产品能够真正满足客户。
重大缺陷也许到流程后期评审时才会被发现，造成严重的不良结果。
线性工作顺序开展使开发效率变低，成本不易控制。
为了克服以上问题，应对需求的不确定性和变化性，一些并行、迭代的方法得以发展和应用，敏捷的概念就是在这种背景下出现的。
2. 敏捷宣言
2001年2月，Martin
Fowler，Jim Highsmith等17位著名的软件开发专家齐聚在美国犹他州雪鸟滑雪胜地，举行了一次敏捷方法发起者和实践者的聚会。在这次会议上，他们正式提出了敏捷（Agile）这个概念，并共同签署了敏捷宣言。
随着《敏捷宣言》的签署，“敏捷”一词正式进入了产品研发领域。但实际上，敏捷方法在此之前已经应用了很多年。
02
“敏捷”是什么
1. 敏捷的定义
《敏捷宣言》创始人之一的Jim
Highsmith曾经这样描述“敏捷”：
敏捷是制造并响应变化，从而在动荡的商业环境中创造利润的能力。
敏捷是平衡灵活性和稳定性的能力。
从Jim
Highsmith对敏捷的描述中可以看出，变化孕育着创新，而创新则需要一定的灵活性来保证。但敏捷绝不意味着要牺牲质量和秩序来换取速度，敏捷≠仓促，它是追求既快又好的一种思维和方法。
2. 敏捷的12项原则
基于《敏捷宣言》的4项价值观，还有12项更为细致的指导原则，一起构成了敏捷开发的指导思想：
3. 敏捷项目
2005年，敏捷专家们又发布了《相互依赖声明》，从领导力角度来诠释敏捷的价值观，也明确了敏捷项目的管理思想：
本文中，我们借助Jim
Highsmith的理论来快速了解一下敏捷项目的运作方式。
1）敏捷项目要实现的五个商业目标
作为一种具体的流程方法，敏捷所期望实现的商业目标如下：
持续创新：满足当前客户的需要；
产品适应性：满足未来客户的需要；
缩短交付进度：满足市场，提高投资回报率;
人员和流程适应性：对产品和企业变化做出迅速反应；
可靠的结果：支持业务增长和盈利能力。
敏捷开发紧紧围绕着市场，追求更高的业务目标，这与所有优秀的产品开发方法一样，将市场放在第一位。
2）敏捷的组织架构
下图是一种敏捷的组织架构方式，每一层运用不同的敏捷方法开展各自的工作，共同保证敏捷项目的实施及目标的实现：
3）
敏捷项目的阶段
与一般项目的阶段类似，敏捷项目可以通过五个阶段来组织实施：
构想：确定产品构想、项目目标和控制要素，以及项目团队如何共同工作。
推测：制定基于性能和/或功能的发布计划，确保交付构想的产品。
探索：制定短期计划、完成功能开发并进行测试，不断致力于减少项目风险和不确定性。
适应：审核提交的结果、当前情况以及团队的绩效，必要时做出调整。
结束：终止项目、交流主要的学习成果。
需要注意的是，敏捷项目的五个阶段并非产品的全生命周期，完整的产品生命周期管理还要增加敏捷项目之外的内容。
4）敏捷项目治理和绩效评价
敏捷三角形：
不同于传统项目的三重约束（质量、成本、进度），敏捷项目需要按照敏捷的原则构建一套新的目标体系，即下图中的敏捷三角形模型，包含三方面的目标：
价值目标：生产可交付的产品
质量目标：交付可靠的、适应性强的产品
约束目标：在可接受的约束范围内，实现价值和质量目标
敏捷项目没有把所有精力都放在约束目标上，而是在约束的范围内尽可能创造更大的价值和更好的质量，最终赢得顾客的满意。
经过一系列的治理，敏捷项目希望在下面五项核心的绩效指标上取得好结果：
功能的数量：即以用户故事、事例、需求或特征来表示的范围；
生产效率：以时间和工作量来表示产生的功能；
时间：项目历时月数；
工作量：以多少个人一个月为单位付出的工作量；
可靠性：以缺陷率表示。
在追求绩效结果的同时，不能忘记绩效和成功意味着什么，也就是敏捷项目的绩效管理系统的设计初衷，尤其是第一条：
建立基于信任、诚实、旨在提高组织价值的评估系统；
把大多数重点放在评估结果而不是输入上，即使在度量指标不容易获取、也不精确的情况下；
对于指标的偏差宽容对待，以鼓励适应；
创建产出信息度量指标以支持人类天生的内在动机需要，结合使用评估方式；
促进全面进步。
4. 敏捷方法的实施效果
5. 敏捷的操作方法
在《敏捷宣言》和原则的思维模式和价值观下，许多敏捷操作方法在不同行业和场景下得以创造和应用，下图是项目管理协会（PMI）《敏捷实践指南》中罗列的部分常见方法，我们平时最常用的是Scrum管理方法：
本文在此不对具体的方法展开介绍，但有一点需要说明：方法的选用要能适应特定环境或场景，只要符合《敏捷宣言》的思维模式、价值观和原则的都可以定义为敏捷方法。如果现有方法能够依据敏捷原则提供可持续价值，那你已经是敏捷方法的使用者了。
03
敏捷的特点和逻辑
1. 敏捷的特点
敏捷方法的整体性：
敏捷方法从诞生之日起，就已经通过《敏捷宣言》和原则等高度精炼的文字阐释了其精髓，在这里，我们尝试用过程模型将提炼后的12项原则组合为一个整体：
可以看出敏捷方法充分考虑了开发过程中的各种要素，但聚焦于通过迭代交付的方式解决需求变化的业务场景，并强调了顾客参与这一要点。
自组织团队和以人为本：
自组织团队和以人为本是敏捷方法的另一大特点，也是敏捷项目管理的核心。敏捷原则5和原则11描述的就是这两方面。
自组织的团队不是没有领导的团队，而是一种团队的领导方式。
自组织团队具有自主权，要自我选择如何最好地完成工作。自组织团队结合了自由与责任，面对不确定与各种矛盾，要始终坚持实现交付目标。
在自组织团队中，团队成员需要具有自律性，个人负责管理自己的工作量，对于如何“交付结果”，团队成员保有较大的灵活性，但他们要对结果负责，并在制定的灵活框架内工作。
适用场景：
新的产品、问题和之前未做过的工作都具有探索性，它要求不同领域的专家协作来解决问题。这类不确定的问题变化速度快，复杂性和风险也高，并不适合用传统的计划型方法来应对。在这种场景下，可以考虑应用敏捷的方法。
敏捷方法始于软件行业，但敏捷思想的应用并不需要局限于此。凡是需求不明确或频繁变化、需要客户更多参与的场景，都是敏捷方法的用武之地。
《敏捷实践指南》中提供了一种敏捷适用性筛选工具，可以帮助大家来评估自己的业务是否适合采用敏捷方法。
2. 敏捷背后的逻辑
在敏捷方法的认识过程中，我们可以体会到两种思维方式：
不同的思维方式会产生不同的行为，小到一个产品，大到世界观，思维方式对人类的影响是非常深刻的。
但我们在此只是在探讨产品开发的方法，搞清楚什么场景下采用哪种思维方式，进而创造或选用适合的方法，开发出顾客所期待的产品，才是我们所追求的目标。我们在产品攻略系列第一篇文章《产品攻略系列：门径管理》中曾经提到，罗伯特·G.库珀在2016年提出了敏捷门径混合（Agile-Stage-Gate Hybrid）模型，这种将两种产品开发思维方式结合的尝试，给我们很好的启示。
04
写在最后
确定性是我们努力营造和追求的美好期望，然而不确定性才是世界的常态。因此怎样与不确定性共存，与变化共舞，是我们必须面对的问题。敏捷方法为如何在不确定的情况下开发产品提供了一种有效的思维和方法，也为我们的生活提供了一些启发。
注：
本文在对敏捷项目的描述上，参考引用了以下书籍：《敏捷项目管理-创造创新产品》
华沣管理研究院
