敏捷开发适合你的项目吗？

敏捷开发（agile development）是非常流行的开发方法。市场上，大多数公司都会声称自己使用了敏捷开发的方式来进行项目开发，但实际上，大多数人对敏捷开发的理解并不一致，这导致很多匪夷所思的事情发生。

比如：

1. 每天早上开站立会，晚上开回顾会，每周/每月都开一次迭代计划会议。这就是敏捷开发。
2. 只要把最小可行性产品（MVP）按最快速度做出来，它就是敏捷开发。
3. 不论硬件还是软件，所有项目都可使用敏捷开发。如果不行，那是团队有问题。
4. 敏捷开发只关注用户最终需求，不关注过程中产生的技术需求。技术方案优化，管理技术债，这些都不会在敏捷开发体现。研发团队需要额外安排时间来做这些事情。

所以，敏捷开发到底是什么？

要敏捷地开发，而不是敏捷开发。

敏捷开发的本质就是，将一个复杂的问题，分解成多个小问题，然后逐步优化和解决。它最核心的做法就是迭代和增量改进。

开发者先快速发布一个有用的但不完美的版本，然后不断迭代。每一次迭代都包含规划、设计、开发、测试、评估五个步骤，不断改进产品，添加新功能。通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态。

关键功能要达到 90 分，其他功能 60 分万岁，不要追求完美。

管理一个复杂的工程，最重要的就是抓住关键功能点，并尽快让关键功能点达到超出用户预期的完美，而其他功能点，则可以适当降低标准，甚至可以不做。

通常来说，即使我们有足够多的资源（往往并不是），我们的注意力和时间也是有限的。如果我们把所有精力都投入到所有功能点上，最终可能的结果是，所有功能点都只能达到 60 分，甚至更低。这往往会导致产品无法满足用户需求，甚至无法满足市场竞争。

举例子来说：

• 微信最初要解决的痛点就是用户存在强烈的即时通讯需求，张小龙非常聪明，先发布一个简单有用的版本，然后根据用户反馈，不断迭代，添加新功能。* 2011年1月21日，微信发布的第一个版本也仅仅有文字消息，图片消息等功能，这个版本其实并不足以让它变得流行，因为当时同类竞品也有类似功能，并且像运营商推出的飞信支持免费的短信通讯（文字消息）
• 2011年5月，张小龙推动继续优化之后，增加了实时语音消息功能，让用户可以像使用对讲机一样通讯，而中国恰恰有大量的人并不善于打字输入，他们就是语音通讯的忠实用户，当时并没有其他一样好用的产品，大大地引爆了微信流行
• 2011年7月，微信增加了基于位置的服务"附近的人"、“漂流瓶"和"摇一摇”，允许用户与附近的陌生人联系。每日用户增长跳升到了100,000。
• 2012年5月，微信推出了朋友圈功能，允许用户分享自己的生活。这使得微信从一个即时通信软件，向社交网络发展。
• 2013年8月，微信添加了公众号、微信支付、表情商店和游戏中心等大量功能。公众号使得微信变成内容平台，游戏中心使得微信具备娱乐功能，游戏中心的第一个游戏是"飞机大战"。微信支付最早只限于游戏内的支付，后来才演变成通用的支付工具。
• 2014年1月，腾讯联合创始人张志东希望改变传统的向腾讯员工发红包的形式，就委托微信团队的一个工程师开发了微信的红包功能。这个功能在春节前夕向公众开放，结果一炮而红，那年春节超过800万中国人收到超过4000万个红包。为了发红包，用户开始将他们的银行账户，绑定到微信手机钱包，这使得微信有能力与支付宝竞争。阿里巴巴创始人马云称这件事是"袭击珍珠港"。
• 2017年1月，小程序的开发指南和 API 正式发布。
• 2017年12月，微信正式推出小游戏，它属于小程序的一个类别。同时发布了一个小游戏"跳一跳"作为演示，这个游戏的日活跃用户达到1亿。

今天，微信已经拥有 10 亿全球用户，是全球日活数量最高的 APP。它已经不仅仅是一个即时通信软件，而是一个超级应用，它已经成为了中国移动互联网的代名词。

敏捷开发的核心优势

最大好处就是加速了接收用户反馈的过程并降低了成本。对于一个研发公司最大的成本就是人力成本，因为产品提前发布上线了，就意味着节省了时间和人力成本。另外，因为产品相对提前上线了，便可以快速感知真实的用户需求，从而快速调整产品方向，降低风险。

对于硬件产品怎么做？

硬件项目有较长的生产验证周期，在硬件项目发布的同时，通常意味着已经进行量产验证。这个时候，如果发现产品存在问题，往往已经错过了最佳的改进时机。

在硬件迭代的周期内，每次验证周期，往往需要比软件更长的周期验证，如 PCB 设计，打样，组装，测试，需要数周甚至数月。每一次验证都涉及成本。在变更关建零部件的情况下，还涉及供应链管理，涉及商务谈判等更多的动作。

所以怎么做，有些思考，可以参考：

1. 硬件-软件分离设计

• 将可变的功能尽可能放在软件/固件层，使用可编程器件（FPGA、MCU）提高灵活性
• 硬件设计预留扩展接口和冗余设计

2. 模块化与平台化

• 采用模块化设计，降低单个模块的迭代成本
• 建立硬件平台，在平台基础上进行功能迭代

3. 仿真先行

• 大量使用仿真工具，在虚拟环境中快速验证设计想法
• 进行热仿真、信号完整性分析，降低物理打样次数

4. 快速原型验证

• 使用开发板、评估板快速验证概念
• 采用3D打印制作结构件原型
• 小批量试产，快速验证关键功能

5. 版本规划策略

• Alpha版：内部验证，可以有飞线、手工焊接
• Beta版：小批量试产，验证核心功能
• Release版：大规模量产前的最终验证
• 每个版本有明确的验证目标

6. 并行工程

• 硬件、软件、结构、测试并行开发
• 使用接口定义文档（ICD）协同工作
• 在硬件完成前，软件或者特性基于仿真环境开发

7. 风险驱动的迭代

• 采用风险燃尽图，着重关注项目关键风险的处理进度。而不是采用瀑布模型，来管理项目进度。
• 优先验证高风险、高不确定性的设计
• 关键器件提前采购小样进行评估
• 对核心功能进行充分的前期验证

敏捷开发真的没有缺点吗？

敏捷开发的最大的缺点，实际上恰恰与它最大的好处相关。那就是它的灵活性带来的模糊性。

1. 工期评估模糊：因为每个迭代都在做新的需求，人们对于未做过的事情难以做出准确评估，而工期评估往往被管理人员视为承诺，这往往容易产生矛盾和冲突。
2. 文档灾难：因为每一次迭代之后，产品形态都会发生变化，而敏捷思想是优先开发，并不是优先文档，随着人员流动，时间一长，很多需求往往没有任何一个人能够讲清楚当时为什么这么做，甚至不敢随便改动。
3. 技术债管理：快速迭代，意味着需要快速响应变化，这往往需要团队有很强的学习能力，以及对新技术的快速掌握能力，这通常来说，是一个巨大的挑战，敏捷开发往往会留下大量的技术债需要进行管理。
4. 信任危机：如果产品方向本身就存在问题，一直进行敏捷开发，一直得不到用户的正反馈，这往往容易会导致团队士气低落，甚至出现信任危机。

所以，敏捷开发真的适合你的项目吗？

敏捷开发不是银弹，它并不适合所有项目。判断敏捷开发是否适合你的项目，需要从多个维度进行评估。

适合敏捷开发的项目

如果你的项目具备以下特征，那么敏捷开发可能是一个很好的选择：

1. 需求不确定性高的项目

当你在做从零到一的创新产品，或者进行产品原型验证时，往往很难在一开始就明确所有需求。这种情况下，敏捷开发可以帮助你快速试错，找到真正的用户痛点。比如：

• 创业公司开发新产品
• 探索新市场的试水项目
• 技术概念验证（POC）项目

2. 用户反馈对产品方向影响大的项目

面向消费者（To C）的互联网产品，如社交应用、电商平台、内容平台等，用户的真实反馈往往会极大地影响产品的发展方向。通过敏捷开发，可以快速收集用户反馈，及时调整产品策略。

3. 软件主导或软硬件分离的项目

纯软件项目，或者采用软硬件分离设计的项目，迭代成本相对较低，更适合采用敏捷方式。比如：

• Web 应用、移动应用
• SaaS 产品
• 采用可编程器件（FPGA、MCU）的智能硬件

4. 团队具备快速学习和适应能力

敏捷开发需要团队成员能够快速学习新技术，适应需求变化，并且有很强的自驱力和协作精神。理想的敏捷团队应该：

• 成员技能互补
• 具备良好的沟通能力，可以并且有意愿跨职能协作
• 愿意拥抱变化，持续改进

不适合敏捷开发的项目

相反，以下类型的项目可能不太适合完全采用敏捷开发：

1. 需求明确且固定的项目

政府项目（To G）或大型企业项目（To B）通常有非常明确的需求文档和验收标准，合同条款也相对固定。这类项目采用传统的瀑布模型或混合模型可能更合适。

2. 法规和标准严格的项目

医疗设备、航空航天、金融系统等领域，受到严格的法规和标准约束，每一次变更都需要完整的文档和合规性验证，快速迭代的成本极高。

3. 硬件占主导且迭代成本极高的项目

如果硬件设计是项目的核心，且每次迭代需要重新开模、打样、测试，周期长、成本高，完全采用敏捷开发可能不现实。

4. 团队缺乏敏捷实施经验

如果团队从未接触过敏捷开发，组织文化也不支持快速迭代和试错，贸然采用敏捷可能会造成混乱。

5. 预算和时间极度受限

当项目的时间和预算已经非常紧张，连一次完整的迭代都无法支撑时，敏捷开发反而会增加管理成本。

如何评估你的项目

你可以从以下维度来评估你的项目是否适合敏捷开发：

实施建议

即使你的项目不完全符合敏捷开发的理想条件，也可以借鉴敏捷的思想：

1. 采用混合模式

不必全盘采用敏捷，可以在项目的某些阶段或某些模块采用敏捷方式。比如：

• 前期探索阶段采用敏捷，需求明确后采用瀑布
• 软件部分敏捷，硬件部分传统，硬件模块化，模块化的部分可以敏捷
• 核心功能先敏捷验证，扩展功能按计划开发

2. 从小范围试点开始

如果组织从未尝试过敏捷，建议先选择一个风险可控的小项目进行试点，积累经验后再推广。

3. 重视团队培训和文化建设

敏捷开发的成功，70% 取决于团队文化和协作方式，30% 取决于具体的实践方法。要投入足够的时间和资源来：

• 培训团队成员理解敏捷的本质
• 建立开放、信任的团队文化
• 赋予团队足够的自主权

4. 平衡敏捷与文档

敏捷不是没有文档，而是优先可工作的软件，而不是详尽的文档。但对于关键决策、架构设计、接口定义等，还是需要维护必要的文档。可以考虑：

• 使用轻量级的文档形式（如 Markdown、Wiki）
• 在每次迭代结束时更新文档（可以结合 AI 辅助生成）
• 让文档成为团队知识沉淀的工具

结语

记住：要敏捷地开发，而不是教条地敏捷开发。

敏捷开发的本质是快速响应变化，持续交付价值。不要被各种敏捷方法论的形式所束缚，而是要理解其背后的原则和价值观。

每个项目都有其独特性，没有一种方法论可以适用于所有场景。重要的是：

• 深入理解你的项目特点和团队能力
• 根据实际情况选择或调整开发方法
• 持续反思和改进你的工作方式

最终，无论采用什么方法，目标都是一致的：高效地交付满足用户需求的高质量产品。