# 敏捷开发简述

# 瀑布流开发 vs 敏捷开发

# 瀑布流开发过程

瀑布流开发流程源于制造业。是一种逐步的，分阶段的产品开发过程。

工作原理是这样的：

• 有人会提出一个他们想要开发的软件。需求者/产品经理们会写出他们想要构建的内容，以及一系列冗长而详细的计划。
• 然后项目会流向下游，从一个阶段到下一个阶段，从一个团队到另一个团队，直到完成。
• 最后，整个新软件都经过了测试，反馈给了客户，然后就交付出去了。

使用瀑布流开发软件，会遇到一个很可怕的问题：

• 如果你在最后一个阶段发现了一个 bug，那么尝试回去修复它可能会很混乱，甚至是致命的。一些软件项目会陷入困境，根本不可能去交付了。

当你确切地知道你想要构建什么东西时，瀑布流的线性开发过程可能会奏效：

• 但是软件开发不同于传统制造业，没有统一的实现标准，一个项目与另一个项目之间的差异可能非常大。
• 在开发过程中，变化是会经常发生的 ( 需求变化、技术变化、资源变化 )
• 所以，"瀑布流" 不适合软件开发。

# 敏捷开发宣言*

为了能够更高效的开发软件，人们提出了 "敏捷" 的概念，并且发表了一份『 敏捷宣言 』

于此同时还提出了十二条『 敏捷原则 』：

# 敏捷开发过程

上面只是 "敏捷" 的思想，下面具体介绍什么是 "敏捷"？什么是 "敏捷开发"？

# 什么是敏捷

• 是一种响应变化的能力。
• 当处于一种不确定或经常发生变化的环境中时，能够理解环境所发生的一切，并且识别你所面对的不确定性，边前进边找出应对措施。

# 什么是敏捷开发

• 指的是建立在 "敏捷" 思想之上的一系列方法论和具体实践。
• 追求对需求变化、技术变化、资源变化的响应能力。
• 通过不断调整项目计划，提高软件项目的成功率。

# 迭代开发

传统瀑布流开发方式是采用一整个大周期（ 比如一年 ）进行开发。

敏捷开发，采用『 迭代开发 iterative 』的方式。将一个大的开发周期拆分成多个连续小周期，且每个小周期也都是一个完整的开发周期，并且有相似的流程。看上去好像就在一遍遍的重复，因此成为 "迭代"。

# 增量开发

那么应该怎么在一个大周期中划分迭代呢？敏捷开发中采用『 增量开发 incremental 』的方式去划分迭代。指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，在敏捷开发中，按照 "新增功能" 来划分迭代。

• 开发者先快速发布一个有效但不完美的最简版本；
• 然后不断迭代，不断添加新功能。并且根据上一次迭代的反馈，改进产品；
• 最终使软件接近于完善状态；

# 敏捷开发的好处

早期交付：

• 快速的实现一个可以交付给用户的可运行的早期版本。
• 让用户可以对产品的核心设计进行验证，及时给出意见反馈。

降低风险：

• 根据用户给出的反馈，开发团队可以及时修改产品需求和设计方案，以让产品真正符合用户需求。
• 通过不断的迭代和试错，可以让项目成功的可能性不断增加。

# 敏捷开发方式论

上面介绍了敏捷开发的基本思想。敏捷开发在实际应用中有很多个『 敏捷开发方法论 』用来指导实际的开发过程。

# RUP 统一过程*

In 1990s, a company called Rational Software developed the Rational Unified Process as a software process product.

In February 2003, IBM acquired Rational Software. A few years later in 2006, IBM created a subset of RUP, which is more agile centric and is called OpenUP.

RUP has four phases: Inception, elaboration, construction, and transition.

• view these phases as container for small waterfall-like iterations.
• each phase has one or more iterations.

Each RUP phase ends with a milestone.

• At the end of the inception phase, you will have achieved what is known as the Lifecycle Objectives Milestone. So you will have all stakeholders agree to what you are going to build.
• The elaboration phase ends with base lining the architecture of your software system, and this landmark is called Lifecycle Architecture Milestone.
• Construction ends with achieving Initial Operational Capability Milestone, which is where your software product is ready to be used by end users.
• Transition is the phase where you fine tune your application to make it fully usable at production scale, and this is where you achieve Production Release Milestone.

每一个阶段的每一次迭代中，可以分为如下的具体 Activities。

下图 👇 中用紫色填充的大小，来表达每个 Activity 在迭代中的工作量大小和重要程度。

RUP 因为太重量级了，现代软件开发中使用的人不多。但是它还是提供了很多有借鉴意义的理念：

# Scrum

Scrum 是用于开发、交付和持续支持复杂产品的一个框架。由 Scrum 团队 以及与之相关的 角色，物件，事件，规则 组成。

# 3 个角色

PO 产品负责人：

• 产品负责人的职责是将开发团队开发的产品价值最大化。
• 是负责管理 "产品待办列表" 的唯一负责人。( 后面讲什么是产品待办列表 ) 可以亲自完成上述工作，或者也可以让开发团队来完成。
• 为保证产品负责人的工作取得成功，组织中的所有人员都必须尊重他/她的决定。

开发团队成员：

• 团队包含各种专业人员。负责在每个 Sprint 结束时交付完成的产品增量。只有开发团队成员才能创建增量。
• 每个人都做好本职工作，彼此之间良好配合；每个人都理解团队的产品目标和迭代目标；每个人都了解团队的工作方式和节拍。
• 跨职能：个人不一定是全能的，但团队要是全能的，具备把产品列表变成产品增量的全部技能。团队成员之间，不受角色和头衔的制约，只要具备能力，每个人都可以认领所有任务。
• 自组织：团队自行决定自己的工作方式，只要团队有共识。

开发团队的规模：

• 开发团队最佳规模是足够小以保持敏捷性，同时足够大可以在 Sprint 内完成重要的工作。一般约束为 3 - 9 人。
• 过小的团队在 Sprint 中可能会遭遇到技能上的约束，进而导致开发团队无法交付潜在可发布的产品增量。超过 9 人的团队则需要过多的协调沟通工作。

SM ( Scrum Master )

• SM 对 Scrum 团队而言是一位服务型领导。它促进和指导团队使用 Scrum 进行开发。
• SM 会帮助每个人理解 Scrum 理论、并应用于实践。

# 3 个物件

产品待办列表 Product Backlog：

• 列出了所有的特性、功能、需求、增强、修复等对未来要发布的产品所要进行的改变。
• 表中单个项称为 "产品列表项" Product Backlog Item, PBI
• 产品待办列表永远是不完整的。最早开发的产品待办列表列举最初所知的以及理解最透彻的需求。产品待办列表会随着产品及其应用环境的改变而动态演进。
• 随着产品的使用、价值的获取和获得市场的反馈，产品待办列表会成长为更大和更详尽的列表。

好的产品列表要满足 DEEP 原则：

• Detailed Appropriately 细节得当。越是马上要做的 PBI，越是要有足够的细节。很久以后才做的，可以粗略一点。
• Emergent 涌现式的。PBI 可以根据实际情况随时插入。
• Estimated 有估算的。近期要做的 PBI，估算要较精细。对于远期要做的 PBI，估算可以粗略。
• Prioritized 排好优先级的。近期要发布版本中的 PBI 的优先级要明确排列，中期的可粗略排列，远期的可不必排列。

迭代待办列表 Sprint Backlog：

• 从产品列表中选出当前迭代要完成的 PBI，及由 PBI 分解产生的任务构成。
• 对于任务的估算，可以采用天或小时估算，也可以不估算。采用哪种方式，以团队能够做履行迭代承诺，以及方便监测迭代工作为标准。

产品增量 Increment：

• 是一个 Sprint 完成的所有产品待办列表项的总和，以及之前所有 Sprint 所产生的增量的价值总和。
• 每个增量都添加至之前的所有增量上，并且经过彻底地测试，以此确保整合在一起的所有增量都能工作。
• 在 Sprint 的最后，新的增量必须是 “完成” 的，这意味着它必须可用并且达到了 Scrum 团队 “完成” 的定义的标准。

# 5 个事件

Scrum 使用固定的事件来产生控制节奏。所有事件都是有 "时间盒" 限定的事件，也就是说每一个事件限制在最长的时间范围内。

产品列表精化会 Product Backlog Grooming：

• 产品人员对 "产品待办列表" 进行精化，使得列表中的 PBI 达到可估算可计划和可执行的状态。开发人员可以对之进行开发工作了。

---

Sprint 迭代：

• Sprint 是 Scrum 的核心。每个 Sprint 都可以被视为一个项目，其长度为一个月以内，这段时间内构建一个 “完成” 的产品增量。
• 当 Sprint 的长度太长的话，对要构建什么的定义就有可能会改变，复杂性也有可能会增加，同时风险也有可能会增加。
• 在整个开发过程期间，Sprint 的长度保持一致。前一个 Sprint 结束后，新的下一个 Sprint 紧接着立即开始。

一个完整的 Sprint 由 Sprint 计划会议、每日站会、开发工作、Sprint 评审会议和 Sprint 回顾会议构成。

迭代计划会 Sprint Planning：

确定此次 Sprint 实现产品待办列表要达到的目的，以及要完成的产品待办列表项。并且给出如何完成交付增量所需的工作计划。

Sprint 计划会议回答以下问题：

• 接下来的 Sprint 交付的增量中要包含什么内容？
  • 产品负责人讲解 Sprint 的目标以及达成该目标所需完成的产品待办列表项。
  • Sprint 会议的输入是产品待办列表、最新的产品增量、开发团队在这个 Sprint 中能力的预测以及开发团队的以往表现。开发团队自己决定选择产品待办列表项的数量。只有开发团队可以评估接下来的 Sprint 可以完成什么工作。
• 要如何完成交付增量所需的工作？
  • 开发团队预估每个选出的产品待办列表项转换成产品增量所需要的工作，以及工作量。需要确保能在即将到来的 Sprint 中能够完成。
  • 这个 Sprint 中所选出的产品待办列表项加上交付它们的计划称之为 "Sprint 待办列表"。
  • 在 Sprint 计划会议的最后，开发团队规划出在 Sprint 最初几天内所要做的工作，通常以一天或更少为一个单位。开发团队自组织地领取 "Sprint 待办列表" 中的工作。
  • 在 Sprint 计划会议结束时，开发团队应该能够向产品负责人和 Scrum Master 解释他们将如何以自组织团队的形式完成 Sprint 目标并开发出预期的产品增量。

每日站会 Daily Stand：

• 每日 Scrum 站会在 Sprint 的每一天都举行，时间控制在十五分钟左右。
• 在每日 Scrum 站会上，开发团队为接下来的 24 小时的工作制定计划。
• 通过检视上次每日站会以来的工作情况，和即将到来的工作计划，来优化团队协作。
• 每日 Scrum 站会在同一时间同一地点举行，以便降低复杂性。
• 开发团队成员通常会在每日 Scrum 站会后立即聚到一起进行更详细的讨论，或者为 Sprint 中剩余的工作进行调整或重新计划。

"问题为导向" 是一种常见的站会进行方式。每个团队成员回答如下问题：

• 昨天，我为帮助开发团队达成 Sprint 目标做了什么？
• 今天，我为帮助开发团队达成 Sprint 目标准备做什么？
• 是否有任何障碍在阻碍我或开发团队达成 Sprint 目标？

迭代评审会 Sprint Review：

• Sprint 评审会议在 Sprint 快结束时举行，用以检视所交付的产品增量并按需调整产品待办列表。
• Scrum 团队和相关人员协同讨论在这次 Sprint 中所完成的工作。
• 根据完成情况和 Sprint 期间产品待办列表的变化，所有参会人员协同讨论接下来可能要做的事情。
• Sprint 评审会议的结果是一份修订后的产品待办列表，阐明很可能进入下个 Sprint 的产品待办列表项。
• 这是一个非正式会议，并不是一个进度汇报会议，演示增量的目的是为了获取反馈并促进合作。

迭代回顾会 Sprint Retrospective：

• 回顾会议发生在 Sprint 评审会议结束之后，下个 Sprint 计划会议之前。
• Sprint 回顾会议中，需要检视此次 Sprint 中出现的一些团队协作，开发过程，工具使用上出现的问题。找出潜在需要改进的地方。
• 在 Sprint 回顾会议结束时，Scrum 团队应该明确接下来的 Sprint 中需要实施的改进。
• Scrum Master 鼓励 Scrum 团队在 Scrum 的过程框架内改进开发过程和实践，使得他们能在下个 Sprint 中更高效更愉快。
• 虽然改进可以在任何时间执行，Sprint 回顾会议提供了一个专注于检视和适应的正式机会。

---

Sprint 取消：

• 只有产品负责人才有取消 Sprint 的权力。
• 如果某个 Sprint 对其所在环境来说失去了价值和意义，那么它就应该被取消。比如公司的发展方向或者市场上或技术上的状况发生改变。
• 然而，由于 Sprint 的时间都很短，所以取消 Sprint 的意义不大。
• 当取消某个 Sprint 时，产品待办列表项需要评审。
• 取消 Sprint 会消耗资源，每个人都需要重新集合去开始另一个 Sprint。

# XP Extreme Programming 极限编程

# Lean 精益

# Kanban

# DevOps

# 敏捷工具

# 时间盒 Timebox

Timeboxing，是敏捷开发中的重要概念，它是一种任务及时间管理的方法。

思想是，设置一个固定的时间长度，称为『 时间盒 』，具体在这个时间段内要完成的任务量是可以变化的，根据每个任务的具体工作量来决定。

可以想象为，有一个盒子。这个盒子内可以随意地放入任何工作，只不过因为每项工作都有其占的空间大小，并且铁盒子的容量固定无法扩大，所以仅能放入有限数量的工作。

在 Scrum 中每个 Sprint 都是一个时间盒。

# 参考

• Scrum 官方权威指南
• 图解 Scrum 精要，一看就会! - GitChat - GlenWang
• 为什么我讨厌 Scrum？- InfoQ - Gerhard Beck
• 精益思想与敏捷思想 - MBA 智库