扫码获取 VIP 码
添加管理员微信获取 VIP 码
很多人听到敏捷开发，第一反应是"开发速度快"或"少写文档多写代码"。这两个理解都偏了。敏捷开发是一套以人为中心、以迭代增量为基础节奏、以持续交付有价值软件为目标的方法论体系，可追溯至九十年代多种轻量级方法，最终在二零零一年由十七位软件工程专家联署的敏捷宣言完成系统化表达。
要理解敏捷，必须先厘清它与传统开发模式的核心差异。瀑布模型将软件开发切分为需求分析、设计、编码、测试、部署等严格顺序阶段，隐含需求在项目初期可以被完整捕获且不发生重大变化的假设。现实恰恰相反——用户看到可运行软件之前往往无法清晰表达需求，市场和技术条件也在持续变化，等到开发周期结束，交付的软件可能早已偏离用户期望。
敏捷开发放弃了"先全部想清楚再动手"的思路，转而采用"先做出最小可用版本，再根据反馈持续改进"的策略。开发工作被拆分为多个短小迭代，每个迭代通常一到四周，结束时产出经过测试的、可交付的软件增量。产品负责人和利益相关者在每个迭代末尾评审成果并提出调整意见，团队将反馈纳入下个迭代计划。这种短周期反馈机制从根本上降低了不确定性风险——方向正确就继续前进，偏离了就快速纠偏，损失被严格控制在一个迭代范围内。
在软考系统架构设计师考纲中，敏捷被置于软件工程核心知识模块，要求掌握敏捷宣言、Scrum框架运作机制、极限编程工程实践以及敏捷与传统方法的适用场景辨析。敏捷是包含Scrum、极限编程、看板方法、特性驱动开发等多种实现的方法族，其中Scrum凭清晰角色定义成为应用最广的框架，极限编程以技术实践见长，看板脱胎于精益思想，三者构成软考敏捷考点主体。
理解敏捷还要认识到，它并非排斥文档和计划。宣言说的是"可以工作的软件高于详尽的文档"而非"不需要文档"。文档从厚重的需求规格说明书转变为用户故事、验收标准和架构决策记录等轻量级形式。计划同样重要，只是从"制定详细长周期计划并严格执行"转变为"持续制定短周期计划并根据反馈调整"。背后逻辑是：软件开发是知识发现和创造过程，不是机械重复的制造过程。
二零零一年二月，十七位来自极限编程、Scrum、水晶方法等不同流派的软件工程领军人齐聚美国犹他州雪鸟滑雪场，产出软件工程史上最具影响力的文件之一——敏捷软件开发宣言，从根本上重塑了人们对软件开发的认知。
敏捷宣言首先宣告四条核心价值，每条采用"X高于Y"的表述形式。这种表述容易被误读为"X重要而Y不重要"，但宣言的本意是在两个都有价值的维度之间做出优先级选择。
个体和互动高于流程和工具。软件开发本质上是人的智力协作，再完善的流程和先进的工具都无法替代团队成员间高效的信息交流和协同决策。沟通顺畅、互相信任的团队即使使用简陋工具也能产出高质量软件；成员信息壁垒重重时，再昂贵的平台也无济于事。但这不意味流程和工具不重要——持续集成、自动化测试框架和版本控制等工程基础设施，正是支撑高效互动的关键使能因素。
可以工作的软件高于详尽的文档。这直面"文档驱动"模式的内在矛盾。需求规格说明书再详尽，也不如可运行的软件原型更能让用户确认需求。架构设计文档再精美，也不如通过持续集成验证过的代码更能证明可行性。敏捷团队交付文档的方式是"恰到好处"——只编写确有读者、能被持续维护、能带来实际价值的文档，用户故事卡片和验收测试用例等轻量级文档取代了传统巨量文书。
客户合作高于合同谈判。传统外包中，甲乙双方签订合同后，关系往往变成围绕条款的博弈。敏捷主张客户或产品负责人应成为开发团队的紧密协作者而非对立面，持续参与需求优先级排序、迭代评审和反馈，确保开发方向与业务目标始终一致。
响应变化高于遵循计划。这是敏捷与传统方法的核心分水岭。传统方法将变更视为敌人，需要严格的变更控制流程压制。敏捷则认为变更是常态，通过短迭代、持续反馈和自动化测试建立起快速拥抱变化的能力，产品负责人可基于最新信息随时调整下个迭代的优先级。
在四大价值基础上，敏捷宣言进一步提出十二项原则，构成从理念到操作指南的完整链路，可从四个维度加以把握。
面向客户价值的原则占据最大篇幅。最高优先级是通过尽早和持续交付有价值的软件来使客户满意；即使在开发后期也欢迎需求变化，利用变化为客户创造竞争优势；业务人员和开发人员必须每天一起工作；要经常交付可工作的软件，间隔越短越好。这四条共同指向一个理念：软件开发一切活动都应以尽早持续为客户创造价值为最终目标。
面向团队协作的原则强调激发个体和自组织的价值。项目围绕有动力的个体构建，信任他们能完成工作；团队内部传达信息最有效的方法是面对面交谈；最好的架构、需求和设计出自自组织团队。这三条与传统层级式管理形成鲜明对照：最了解技术细节的人是执行者自己，团队应被授权自行决定如何完成任务，管理者从指挥者转变为服务者和障碍清除者。
面向持续改进的原则是敏捷工程实践的哲学基础。团队定期反思如何变得更有效，然后调整行为。这条原则在Scrum框架中体现为每个Sprint结束时的回顾会议：检查上迭代哪些做法值得保留、需要改进或放弃，并制定行动方案在下迭代执行。
面向技术卓越的原则是敏捷可持续性的保障。持续关注技术卓越和良好设计能提高敏捷性；简单——最大化未完成工作的艺术——至关重要；可工作的软件是进度的首要度量标准；敏捷过程促进可持续开发。这四条共同说明：敏捷绝不是降低技术标准的借口，敏捷团队对代码质量、设计简洁性和测试覆盖率的追求比传统团队更加严格——没有技术保障的快速迭代只会沦为混乱。
十二条原则的底层逻辑可归纳为一个核心命题：软件开发的不确定性是内在的且不可消除的，正确策略不是消除不确定性，而是建立能快速感知并适应变化的组织和技术能力。瀑布模型试图通过详尽前期分析消除不确定性，在实际中几乎不可能。敏捷方法接受了不确定性，通过短周期迭代管理它：每个迭代都是低成本探索，方向正确就前进，偏离了就快速纠偏。
从认知科学视角看，敏捷原则与人类认知规律高度吻合。人学习复杂事物的方式不是一次性、线性的，而是螺旋式、反复、渐进深入的。每个迭代都是一轮"尝试、反馈、学习、调整"的认知循环，经过若干轮循环后，对需求的理解可达到传统模式无法企及的深度。
Scrum是当前全球使用率最高的敏捷实施框架，超八成敏捷组织采用Scrum或其变体。Scrum得名于橄榄球运动中的争球术语，寓意团队成员紧密协作。框架本身极其简洁，规则文档仅十几页，精妙之处在于通过几个清晰角色、几个标准仪式和几个核心工件的有机组合形成自洽的管理闭环。
Scrum定义三个角色，各司其职、互相制衡。产品负责人是产品价值最大化的责任人，管理产品待办列表——产品所有待开发功能的优先级清单，必须深刻理解用户需求，在相互竞争的功能间做出取舍，用业务语言向团队解释每个用户故事的价值。产品负责人不能同时充当Scrum Master，也不应干涉团队内部技术决策。
Scrum Master是Scrum框架的守护者和服务型领导者，最容易被误解为"项目管理员"或"技术主管"，但既不管理团队也不对产品和技术方案负责。其核心职责包括三个方面：促进Scrum实践规范执行，帮助团队内化敏捷原则；消除阻碍团队前进的障碍，无论是技术依赖、流程审批拖延还是团队内部协作摩擦；引导团队自我反思和持续改进，营造心理安全环境让成员敢于暴露问题。
开发团队是实际交付软件增量的跨职能群体。Scrum对开发团队有三条刚性约束：规模控制在三到九人之间，人太少缺乏技能广度，人太多沟通成本急剧上升；成员必须跨职能，团队整体具备将产品待办项从概念转化为可交付增量所需的全部技能；团队必须自组织，自行决定工作方式和技术方案。
Sprint是Scrum的心跳，是时间盒固定的迭代周期，通常两到四周。长度一旦确定，在项目期间尽量保持不变，建立稳定的节奏感。Sprint期间不允许做出危及Sprint目标的变更——已纳入Sprint待办列表的需求不能被随意增减或重新定义目标，这保护了团队在一个迭代内的专注度。
Sprint计划会议在每个Sprint开始时召开，时间盒为Sprint长度乘以两小时。会议回答两个核心问题：本次Sprint能交付什么增量，如何完成工作。团队从产品待办列表顶部选取高优先级条目，评估容量后拉入Sprint待办
本篇完！