敏捷之道 | 敏捷开发真的过时了么？

写在前面
「敏捷之道」是 LigaAI 的全新栏目。在这里，Liga 希望能与更多朋友一起深入探讨「敏捷」知识，挖掘和发现更多工作和生活中的“敏捷可能”。新篇第一章，我们聊聊“什么是敏捷”。

敏捷开发虽然被视为“开发者的福音”，但却频繁被国内团队诟病成“世纪大谎言”。难道敏捷开发在国内真的行不通吗？

事实上，许多团队宣称的“敏捷”不是最初解放开发者的敏捷，而是片面理解需求、极端追求快速交付、忽略软件质量的“田园敏捷”。敏捷开发在国内实践的“跑偏”，源于对“敏捷”深度理解的缺乏，浮于表面的应用将“敏捷”错当成“快速”。因此，本篇希望与诸位就以下问题共同探讨“敏捷”的本质：

• 敏捷开发是什么？
• 敏捷开发的「敏捷」指什么？
• 敏捷开发比瀑布开发更好么？
• 打造敏捷开发团队的第一步是什么？

敏捷开发是什么？

敏捷开发自1990年代起逐渐被广泛关注，作为一种新型软件开发方法，它描述的是一种快速应对变化的能力。

敏捷联盟（agilealliance.org）对敏捷开发的定义如下：敏捷软件开发是一组基于敏捷软件开发宣言及其背后的12个原则中表达的价值观和原则的框架和实践的总称。下面，我们来重温一下「敏捷宣言」，以及其背后的价值观和原则。

敏捷宣言 Agile Manifesto

「敏捷宣言」诞生在美国犹他州的雪鸟城，一个跟软件革命或者科技创新没啥关系的滑雪基地。2001年，苦于软件开发中不合理的繁冗流程和文件，来自多个不同软件开发领域的17位代表聚集在一起（度假），讨论软件开发的未来。最终，他们达成了价值观和原则上的共识，共同签署并发布了「敏捷软件开发宣言 Manifesto for Agile Software Development 」，即「敏捷宣言」。

「敏捷宣言」在极限编程 (XP)、Scrum、动态系统开发 (DSDM)、水晶开发(Crystal Clear)、特征驱动开发(FDD) 等框架中找到了共同点，并定义了敏捷开发的四项核心价值观和十二条基本原则。

敏捷价值观 Agile Values

「敏捷宣言」传递了不同于传统软件开发的四项价值观，即敏捷开发更重视

• 个体和互动 Individuals and interactions
• 工作的软件 Working software
• 客户合作 Customer collaboration
• 响应变化 Responding to change

「敏捷宣言」在价值观的最后说到：“尽管右项有其价值，我们更重视左项的价值”，而左项的四项价值，即流程和工具、详尽的文档、合同谈判和遵循计划正是传统软件开发模式——瀑布式软件开发的核心。

敏捷开发原则 Agile Principles

「敏捷宣言」进一步拓展四项价值观，补充提出了敏捷开发应该遵守的十二条原则。

敏捷开发 Agile Development

敏捷价值观和敏捷开发原则共同说明，敏捷开发以客户满意为目标，重视成员个体的能力与价值，强调团队内外需要紧密协作和高效沟通，认为个体内驱、团队信任、追求卓越和优化进步能推动项目进行。

敏捷开发的初衷是为了让软件开发回归到客户想要的软件本身，用价值产出取代规范文档推动项目完成。与非敏捷的传统软件开发模式相比，敏捷开发摒弃非必要的流程和文件，通过作业简化和团队内外的高效合作等，持续实现软件价值的短周期交付，让客户满意。

敏捷开发的「敏捷」指什么？

要回答“什么是敏捷”，首先要清楚敏捷开发的核心是什么：为什么敏捷开发要求短周期开发、持续交付、拥抱变化和少写文档？

• 短周期开发和持续交付是为了获取客户反馈确认研发方向，避免最终产品与客户期望不符；
• 拥抱变化是因为需求多变，要让最终的软件成果符合实际的使用场景，成为有价值的软件；
• 少写文档是为了高效传递信息，专注研发，同时可以避免需求变更导致无效文档浪费时间。

可以看出，敏捷开发本质上是一个需求逐渐明确和丰富的过程，而敏捷开发的核心就是响应需求的变化。换句话说，敏捷开发通过降低试错成本（比如缩短研发周期、摒弃非必要文档等），减小需求变更对项目推进的影响。

如果说敏捷开发是一个具有实验性质的，不断实施“计划-实践-反馈-优化”循环的软件开发模式，那么敏捷则是一种主张化繁为简和良性反馈，强调定期优化和持续进步的价值观。

为什么「敏捷开发」在国内实践会脱离原有的轨迹，最后演变成「中华田园敏捷开发」？因为大家把「敏捷」搞错了。

敏捷强调要及时根据变化进行调整和优化，以减小负面影响，它反映的是一种快速响应变化的能力，而不是快速研发的能力。哪怕跳出软件开发领域，敏捷也仍然是一种能够贯彻“生活-工作-学习”的问题解决思维方式。就像百度词条所定义的：敏捷是一种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力。

敏捷开发比瀑布开发更好吗？

如果细心留意「敏捷宣言」的表述会发现，初代敏捷联盟者不曾否认瀑布开发的价值，也未曾表示“敏捷价值观比传统软件开发价值观更有价值”。实际上，敏捷开发和瀑布开发，作为两种不同的软件开发模式，本来就没有绝对的优劣之分，毕竟任何方法或者工具都要放在具体场景使用中讨论才有意义，团队构成、项目性质、时间/成本等支持等都会影响方法有效性的最终判定。

可能有朋友要反驳：“端水大师吧你，瀑布已经过时了，现在大家都喜欢搞敏捷。” 对啊，为什么越来越多的团队和组织放弃了瀑布开发，转而选择采用各式各样的敏捷开发方式？

因为市场是快速变化的，用户的需求也是多变的。相比瀑布开发的标准流程，敏捷开发更能适应需求变化，做到随时响应。毕竟只有快速响应需求变化，才能保证在当下的商业环境中绝对竞争力。

「敏捷开发 V.S. 瀑布开发」是一个老生常谈的命题，两种方法各有特点，也分别适用于不同的场景：

• 瀑布开发更适用于项目需求明确且鲜有变化的，或对项目计划要求高的开发项目；
• 敏捷开发适用于需求多变的、功能耦合度低或可用性可持续叠加的，以及迫切需要市场反馈的项目。

戳👇图片了解更多【敏捷开发 V.S. 瀑布开发】对比

关注 LigaAI公众号 并回复关键词「对比图」获取纯享版对比

打造敏捷开发团队的第一步是什么

《新的新产品开发游戏》的作者发现，世界优秀公司最卓越团队具备以下三个特征：超越寻常、自主性和多功能。如果想要打造卓越的敏捷开发团队，应该从哪里开始？

首先明确卓越的敏捷开发团队是什么样的。「敏捷宣言」描述的“理想团队”有以下特征：

• 业务人员和开发人员相互合作
• 高效沟通（最好是面对面沟通）
• 个体斗志，成员是项目核心
• 坚持不懈地追求技术卓越和良好设计
• 团队要定期反思，优化调整
• 责任人、开发人员和用户共同维持稳定步调

如果理想的敏捷开发团队是高效合作、良好沟通、斗志昂扬、节奏一致的，那么打造敏捷开发团队的第一步，就是拥有一个「小而精且结构扁平」的软件研发团队。

• 布鲁克斯法则指出，由于组内沟通成本增加等，投入更多的人来开发一个紧急的项目只会让进度更慢。因此，敏捷开发中，团队越小越有优势，而最佳的敏捷团队规模应该维持在 4-9 人之间，宜少不宜多。
• 开发团队必须熟练掌握完成一个项目所需的全部技能，才能顺利推进项目完成。敏捷开发团队需要专业精湛且多功能的成员，换句话说，兼具深度专业和跨职能的「T型人才 T-shaped Person」是敏捷开发的最优选。
• 扁平化组织结构所隐含的人性假设是，人除了社会需求外，还有一种想充分表现自己能力、发挥自己潜力的欲望。因此，在扁平组织中，成员都能够通过自主探索和持续精进来完成目标，推动项目进度。

除了小而精之外，敏捷开发原则中也有一条内容刻画了具体的团队画像：

最好的架构、需求和设计出自自组织团队。
The best architectures, requirements, and designs emerge from self-organizing teams.

什么是“自组织团队”？管理者应该如何构建一个合格的自组织团队？普通的开发团队能否成长为自组织团队？

下篇文章我们将和大家继续探讨敏捷中的「自组织」。想要第一时间获取更多敏捷开发资讯，请持续关注我们的sf账号-LigaAI

点击LigaAI-新一代智能研发协作平台，在线申请体验我们的产品。