2025年程序员必会的【敏捷】思维能力

一、何为“敏捷”

敏捷是指能够让团队更加有效、工作更为高效，并且作出更好决策的一组方法和相关理念。它不仅仅是一种流程或方法，更是一种思维方式、一种态度，强调快速响应变化、持续交付价值以及团队协作的重要性。

敏捷开发的核心价值层主要包括敏捷宣言和12个原则，这些原则和宣言共同构成了敏捷开发的核心思想。其中，敏捷宣言强调了个体与交互优于流程与工具、可工作的软件优于面面俱到的文档等四个方面的优先级。而敏捷的12个原则则进一步细化了这些核心价值观在实践中的应用，如尽早并持续交付有价值的软件、欢迎需求变更、经常交付可用的软件等。

敏捷开发的方法论包括多种具体的实践方法，如Scrum、极限编程(XP)、精益开发和OpenUP等。这些方法各有特色，但共同遵循敏捷的核心价值观和原则。例如，Scrum强调迭代和增量式开发，通过固定的迭代周期（Sprint）来交付可工作的软件；极限编程则注重编程实践的持续改进和团队协作的重要性。

二、《敏捷宣言》四大价值观

2001年，软件界思想领秀共同发表了《敏捷宣言》，宣言包含的四大价值观是敏捷开发方法论的核心，它们强调了软件开发中人的重要性、快速反馈、紧密合作以及灵活应对变化。

（一）个体和互动高于过程和工具

在项目开发和团队协作中，个体的技能和相互之间的互动比固定的开发过程和工具更为重要。项目团队应该更加关注如何提升团队成员的技能，促进团队之间的有效沟通和协作，而不是仅仅依赖于特定的流程和工具。
当团队成员能够充分发挥自己的专长并有效互动时，团队的整体效能会得到显著提升。另外，良好的互动环境也有利于激发团队成员的创新思维，促进新想法和新解决方案的产生。

（二）可用的软件胜过详尽的文档

能够运行和测试的软件比详尽的文档更具价值。团队应该更专注于实际的软件开发工作，因为详尽的文档可能会占用大量的开发时间，而最终用户更关心的是软件的实际功能和性能。
敏捷开发鼓励团队通过快速迭代来交付可用的软件原型，可以让团队快速获得用户反馈，从而及时调整开发方向，避免资源浪费。此外，通过不断交付有价值的软件，团队可以更好地满足客户需求，从而提升客户满意度。

（三）客户合作优于合同谈判

与客户紧密合作以了解他们的需求并共同制定解决方案比仅仅依赖于合同谈判更为重要。团队应该积极与客户沟通，理解他们的业务目标和痛点，以便开发出真正符合客户需求的产品。如此以来，团队可以更好地理解并满足客户需求，从而减少需求变更的可能性。
此外，通过积极的沟通和合作，团队与客户之间可以建立起更加稳固的信任关系。紧密的客户合作也有助于确保项目成果与客户的期望一致，从而提升项目的成功率。

（四）应对变更而不是遵循计划

在软件开发过程中，需求变更几乎是不可避免的。因此，团队应该灵活应对这些变更而不是僵化地遵循原定计划。这要求团队具备快速响应变化的能力，以便在需求变更时能够迅速调整开发策略和资源分配。
通过早期发现和处理潜在的问题和需求变更，团队可以降低项目失败的风险。灵活应对变更使团队能够迅速调整以适应外部环境的变化，从而保持项目的竞争力。及时响应客户需求变更并交付满足新需求的产品有助于提升客户满意度和忠诚度。

三、敏捷的十二大原则

（一）我们的最高目标是，通过尽早持续交付有价值的软件来满足客户的需求。
（二）欢迎对需求提出变更，即使在项目开发后期也不例外。敏捷过程要善于利用需 求变更，帮助客户获得竞争优势。
（三）要经常交付可用的软件，周期从几周到几个月不等，且越短越好。
（四）项目实施过程中，业务人员与开发人员必须始终通力协作。
（五）要善于激励项目人员，给予他们所需的环境和支持，并相信他们能够完成任务。
（六）无论是对开发团队还是团队内部，信息传达最有效的方法都是面对面的交谈。
（七）可用的软件是衡量进度的首要衡量标准。
（八）敏捷过程提倡可持续的开发。项目发起人、开发人员和用户应该都能够始终保 持步调稳定。
（九）对技术的精益求精以及对设计的不断完善将提高敏捷性。
（十）简洁，即尽最大可能减少不必要的工作，这是一门艺术。
（十一）最佳的架构、需求和设计将出自于自组织团队。
（十二）团队要定期反省怎样做才能更有效，并相应地调整团队的行为。

四、Scrum的名词解释

• Scrum： 橄榄球比赛中的“争球”，在IT中指快速迭代式增量软件开发过程。
• ST： Scrum Team开发人员、测试人员、UI设计师等。
• PO： Product Owner产品负责人。
• SM： Scrum Master敏捷教练。
• User Story：
  • User Story 是从用户的角度来描述用户希望得到的功能的一种简短描述。它通常遵循“角色-功能-益处”的模式，即 “作为一名<某种类型的用户>，我希望<达成某些目的>，这样可以<开发的价值>”。
  • User Story用于捕捉软件系统的功能需求，帮助开发团队更好地理解用户需求，并促进开发团队和非技术相关方之间的沟通。
  • 每个User Story都代表了一个独立的需求或功能点，且可以独立交付。其大小和复杂度应该以能在一个 Sprint 中完成为宜，通常，一个好的User Story应该能够在几天到一周内被开发、测试和验证。
• Product Backlog：
  • Product Backlog由产品负责人（Product Owner）负责维护，它是一个有序的、动态的需求列表，用于记录产品的所有需求。
  • 需求描述遵循SMART原则：Specific（具体的）、Measurable（可衡量的）、Achievable（可实现的）、Relevant（相关的）和Time-bound（有时限的）。
  • Product Backlog中的工作项通常以User Story的形式描述，并按照优先级进行排序。
• Sprint Backlog：
  • Sprint 本意为“冲刺”，指迭代周期，长度通常是一至四周。
  • Sprint Backlog中的工作项通常是从Product Backlog中选取的，用于实现Product Backlog中的一部分需求。它是团队在每个迭代中要完成的具体任务清单。

五、Scrum的三个角色

Scrum是一种敏捷软件开发方法论，它强调团队合作、自组织、迭代和增量开发。在 Scrum 敏捷方法中，主要有三个角色，分别是产品负责人（Product Owner）、Scrum 主管（Scrum Master）和开发团队（Scrum Team）。Scrum敏捷方法中的三个核心角色各自承担着不同的职责。以下是各个角色的主要职责：

（一）产品负责人（Product Owner）

1.负责定义和优先级排序产品需求，确保产品愿景与市场需求保持一致。
2.维护与更新产品待办事项列表（Product Backlog），确保清晰、完整且有序。
3.与开发团队和Scrum主管紧密合作，确保团队理解并聚焦于实现产品目标。

（二）Scrum主管（Scrum Master）

1.负责确保Scrum流程得到正确实施和遵循，解决团队在开发过程中遇到的障碍。
2.促进团队内部的沟通和协作，包括组织Scrum会议（如每日站会、评审会议和回顾会议）。
3.保护团队免受外部干扰，确保团队能够专注于开发工作，同时引导团队持续改进。

（三）开发团队（Scrum Team）

1.主要包括：开发人员、测试人员、UI设计师等，团队控制在5-10人左右。负责实现产品待办事项列表中的功能，通过自组织的方式完成迭代开发任务。
2.在每个迭代周期（Sprint）内，参与计划、执行、评审和回顾工作，确保按时交付高质量的产品增量。
3.积极参与团队决策，共同解决开发中遇到的技术问题，持续提升团队的开发效率和产品质量。

六、Scrum的四个会议

（一） Sprint计划会议（Sprint Planning Meeting）

1.目的：

• 确定当前Sprint要完成的工作。
• 团队共同理解并承诺完成Product Backlog中的一部分工作。
• 产出Sprint Backlog，作为团队在当前Sprint中的工作计划。

2.参会人员：

• 产品负责人（Product Owner）
• Scrum主管（Scrum Master）
• 开发团队（Scrum Team）

3.会议内容：

• 产品负责人介绍并解释Product Backlog中的条目。
• 开发团队评估工作量，并与产品负责人讨论优先级。
• 共同确定Sprint Backlog，包括要完成的故事（User Stories）、缺陷和任务。

（二）每日站会（Daily Scrum Meeting）

1.目的：

• 同步团队工作进度。
• 快速识别和解决遇到的问题和障碍。
• 计划当天的工作。

2.参会人员：

• 产品负责人（Product Owner）
• Scrum主管（Scrum Master）
• 开发团队（Scrum Team）

3.会议内容：

• 每个团队成员简短介绍自己昨天完成的工作、今天计划做的工作以及遇到的问题。
• 会议时间通常控制在15分钟以内，保持高效和聚焦。

（三）Sprint评审会议（Sprint Review Meeting）

1.目的：

• 展示Sprint期间完成的工作成果。
• 收集利益相关者的反馈。
• 根据反馈调整Product Backlog的优先级和内容。

2.参会人员：

• 产品负责人（Product Owner）
• Scrum主管（Scrum Master）
• 开发团队（Scrum Team）
• 其他利益相关者（如客户、业务代表等）

3.会议内容：

• 开发团队展示完成的Product Increment。
• 利益相关者提供反馈，产品负责人记录并更新Product Backlog。

（四）Sprint回顾会议（Sprint Retrospective Meeting）

1.目的：

• 回顾Sprint过程中团队的表现和协作方式。
• 识别哪些做得好，哪些可以改进。
• 制定改进措施，为下一个Sprint做准备。

2.参会人员：

• Scrum主管（Scrum Master）
• 产品负责人（Product Owner）
• 开发团队（Scrum Team）

3.会议内容：

• 团队成员分享Sprint过程中的经验和教训。
• 识别改进点，并制定具体的改进措施和责任人。
• Scrum主管引导会议，确保讨论高效和聚焦。

七、Scrum涉及的3个过程产出

（一）Product Backlog（产品待办事项列表）

1.定义：

它是一个有序的列表，包含了所有需要在产品中实现的功能、需求、改进和缺陷等。Product Backlog 通常由产品负责人（Product Owner）进行管理和维护。

2.内容：

对每个待办事项进行详细的描述，说明其要解决的问题或提供的价值。根据业务价值、用户需求紧迫性等因素确定每个待办事项的优先级。可以使用故事点（Story Points）等方式对每个待办事项进行相对规模的估算。

3.作用：

为整个产品的开发提供了一个清晰的方向和目标，开发团队可以根据 Product Backlog 的优先级依次选择任务进行开发。

（二）Sprint Backlog（冲刺列表）

1.定义：

在每个冲刺（Sprint）开始时，从 Product Backlog 中挑选出高优先级的任务组成 Sprint Backlog。它是开发团队在一个冲刺周期内需要完成的具体工作列表。

2.内容：

将选定的 Product Backlog 项进一步分解为具体的开发任务，明确每个任务的负责人，然后对每个任务进行时间估算，以便规划冲刺进度。

3.作用：

为开发团队在冲刺期间提供了明确的工作目标和计划，帮助团队成员了解自己的具体任务和责任，确保冲刺能够顺利进行。

（三）增量（Increment）

1.定义：

在每个冲刺结束时，开发团队应该交付一个可工作的产品增量。这个增量是对产品功能的逐步增加和完善。

2.内容：

实现了部分或全部从 Sprint Backlog 中挑选出的任务，为产品增加了新的功能，可能包括对现有功能中发现的缺陷进行修复，或者对产品的性能、用户体验等方面进行优化和改进。

3.作用：

通过不断交付增量，产品能够逐步满足用户需求，同时也为利益相关者提供了及时的反馈和价值展示。

八、Scrum 开发流程

（一）收集需求（Product Backlog）

• 负责人： 产品经理
• 主要任务： 负责收集Backlog，制定优先级
• 说明： 产品经理负责与需求方沟通需求，根据业务需求的价值顺序排列优先级。制定Product Backlog，包括了所有需要交付的内容。

（二）规划冲刺（Sprint Backlog）

• 负责人： 产品经理
• 参与者： 产品经理、敏捷教练、开发团队
• 主要任务： 产品经理召开 Sprint 计划会议，通过讲解 User Story 帮助团队理解 Product Backlog，开发团队根据人力资源情况，按照优先级从高到低的顺序挑选 Backlog到下一次的 Sprint Backlog中。

（三）开发任务分解（Sprint Plan）

• 负责人： 开发团队
• 参与者： 产品经理、敏捷教练、开发团队
• 任务： 开发团队组织 Sprint 任务分解会议，产品经理、敏捷教练参加。对Sprint Backlog 的每条进行开发任务分解，制定详细的开发计划：每项任务的工作量大小拆分标准为2-4工时，为每项任务指派负责人、预估任务的开始和结束日期（日期标准定为2天内）。

（四）执行冲刺（Sprint）

• 负责人： 开发团队
• 参与者： 产品经理、开发团队 任务：完成本次冲刺的所有待办事项
• 说明： 一个 Sprint 冲刺即是一次迭代，每次迭代包含的任务：每日不超出 15 分钟的站立会、数据库设计、接口设计、前后端开发、UI设计、Code Review、功能及性能测试等。建议开发人员采用测试驱动开发模式。

（五）交付与验收Sprint

• 负责人： 开发团队
• 参与者： 产品经理、敏捷教练、开发团队、以及利益相关方 任务：交付最终产品给利益相关方验收
• 说明： 在每个冲刺（Sprint）结束时，ST组织 Sprint验收评审会议，展示完成的 Product Increment。利益相关方提供反馈，PO记录并更新Product Backlog。

（六）回顾 Sprint

• 负责人： 开发团队
• 参与者： 产品经理、敏捷教练、开发团队
• 任务： ST总结本次 sprint 什么做得好、什么做的不好、后续应该怎么做。
• 说明： 回顾Sprint过程中团队的表现和协作方式。识别哪些做得好，哪些可以改进。制定改进措施，为下一个Sprint做准备。

遇见即是缘分，关注🌟、点赞👍、收藏📚，让这份美好延续下去！

🌟 基于禅道的Scrum敏捷项目管理最佳实践 请关注下方 ⬇ 【 技术管理修行】