Scrum敏捷开发

scu程序设计实践-2

瀑布模式

敏捷开发

什么是敏捷开发

敏捷开发（Agile）是一种以人为核心、迭代、循序渐进的开发方法。

在敏捷开发中，软件项目的构建被切分成多个阶段，各个阶段的成果都经过测试，具备集成和可运行的特征。

简单地来说，敏捷开发并不追求前期完美的设计、完美编码，而是力求在很短的周期内开发出产品的核心功能，尽早发布出可用的版本。然后在后续的生产周期内，按照新需求不断迭代升级，完善产品。

敏捷宣言

敏捷开发分类

Scrum

Scrum是敏捷众多方法中最流行的一种。是一种开发创新产品和服务的敏捷（Agile）方法。

Scrum基本术语

Sprint：

冲刺周期，通俗的讲就是实现一个“小目标”的周期。一般需要2-6周时间。

User Story：

用户的外在业务需求。拿银行系统来举例的话，一个Story可以是用户的存款行为，或者是查询余额等等。也就是所谓的小目标本身。

Task：

由User Story 拆分成的具体开发任务。

Backlog：

需求列表，可以看成是小目标的清单。分为Sprint Backlog和Product Backlog。

Daily meeting：

每天的例会，用于监控项目进度。有些公司直接称其为Scrum。

Sprint Review meeting:

冲刺评审会议，让团队成员们演示成果。

Sprint burn down：

冲刺燃尽图，说白了就是记录当前周期的需求完成情况。

Rlease：

开发周期完成，项目发布新的可用版本。

Scrum团队架构

Scrum开发工作由一个或多个Scrum团队组成，每个团队由三个Scrum角色组成：产品负责人（Product Owner），Scrum Master 和 开发团队。 在使用Scrum时可能还有其他角色，但Scrum框架只需要这里列出的三个。

产品负责人负责敲定要开发什么、以什么顺序开发。 Scrum Master负责指导团队在通用的Scrum框架上建立并遵循自己的流程。 开发团队负责确定如何交付产品负责人要求的内容。

如果您是经理，请不要担心“经理”在下图中不会出现; 管理人员在使用Scrum的组织中仍然发挥着重要作用。 Scrum框架仅定义了特定于Scrum的角色，而不是在使用Scrum的组织中可以存在的所有角色。

产品负责人（Product Owner）

产品所有者是有授权的产品领导力的中心点。 他是唯一有权决定要构建哪些特性并以何种顺序构建这些特性的人。对于Scrum团队要实现的目标，产品负责人要保持一个清晰的构想并把他传达给每一位参与者。产品负责人的身份决定着他要面对正在开发或维护的解决方案全面负责。

这里所说的产品可以是外部产品，也可以是内部应用程序。产品负责人还有责任确保总能完成价值最高的工作，这些工作也可能包含偏技术的工作。为了确保开发团队快速构建产品负责人需要的产品，产品负责人要与Scrum Master和开发团队积极合作，及时解答Scrum Master和开发团队提出的问题。

Scrum Master

ScrumMaster帮助每个参与者理解并乐于接受价值观、原则和实践。 她充当教练，在过程中方面发挥教导作用，帮助Scrum团队及组织的其他人制定合适的高绩效、有组织特色的Scrum方式。 同时，在采用Scrum时，可能有一个充满挑战的变革管理过程，Scrum Master要帮助组织顺利适应这个过程。

作为辅助者，Scrum Master要帮助团队解决问题和改进Scrum的使用状况。他还有责任保护团队不受外界干扰，（在个人无法有效解决遇到的障碍时）发挥领导作用，清除阻碍团队生产率的障碍。ScrumMaster没有权限控制团队，这个角色不同于项目经理或开发经理等传统角色。Scrum Master担任的是领导者，不是管理者。

开发团队（Development Team）

传统的软件开发方法论述的是各种类型的职位，例如架构师，程序员，测试人员，数据库管理员，UI设计者等。 Scrum定义的是开发团队的角色，这是一个由几种职位的人组成的多样化跨职能团队，负责产品的设计、构建和测试。

开发团队自行组织，确定采用哪种最佳方式来实现产品负责人设定的目标。开发团队一般是5-9个人，团队成员作为一个整体，必须具有多种技能以构建高质量、可工作的软件。当然，如果开发工作需要一个大型的团队，也可以使用Scrum。比如一个大型Scrum团队，比如有35人，不太可能让一个Scrum团队拥有35人，而是分为4个或4个以上的Scrum团队，每个团队不超过9个人。

整体流程

在项目启动之前，会由团队的产品负责人（Product owner）按照需求优先级来明确出一份Product Backlog，为项目做出整体排期。

随后在每一个小的迭代周期里，团队会根据计划（Sprint Plan Meeting）确定本周期的Sprint Backlog，再细化成一个个Task，分配给团队成员，进行具体开发工作。每一天，团队成员都会进行Daily meeting，根据情况更新自己的Task状态，整个团队更新Sprint burn down chart。

当这一周期的Sprint backlog全部完成，团队会进行Spring review meeting，也就是评审会议。一切顺利的话，会发布出这一版本的Release，并且进行Sprint回顾会议（Sprint Retrospective Meeting）。

迭代

在敏捷方法中，首先要开发产品列表（Product backlog） - 一个按优先级排列的、成功开发产品所需的特性及其他功能的列表。 在产品列表的指导下，我们总是先做最重要或优先级最高的条目。 当资源耗尽（例如时间）时，所有未完成的工作的优先级将低于已完成的工作。

工作本身是在一些短期的、时长固定的迭代中完成的，每次迭代时间通常为1周到一个月。 在每次迭代中，自组织，跨职能的团队完成所有必需的工作 - 例如设计，构建和测试 - 产生完整的、可工作的、可以放入产品的特性。

通常，产品列表中的工作量远远不是团队在一次短期迭代中能够完成的。所以，在每次迭代开始时，团队需要制定计划，说明在下一个迭代中要创建产品列表中哪一个高优先级子集。 例如，在上图中，团队已经同意它可以创建功能A，B和C。

在迭代结束时，团队与利益干系人一起评审已完成的功能，获取他们的反馈。 根据反馈，**产品负责人（Product Owner）和团队（Team）**即可对下一步工作内容进行修改，也可以修改以前的工作方式。 例如，如果利益干系人在看到一个完成的特性时，意识到自己没有考虑到另一个必须包含在产品中的特性，此时，产品负责人只需建立一个代表该特性的新条目并把它以适当的优先顺序插入产品列表，留到后面的迭代中迭代完成。

在每次迭代结束时，团队应该有一个潜在可交付的产品（或产品的增量），如果业务上合适，就可以发布。 如果不适宜在每次迭代后发布，可以把多个迭代的一组特性合并在一起发布。

在每次迭代结束后，从规划下一个迭代开始，重新开始整个过程。

Scrum优势

Scrum活动与工件详细

从图的左边开始，沿着最大的环形箭头（Sprint）顺时针介绍。

产品负责人建立产品愿景（图中大立方体）。因为这个立方体可能很大，所以要通过梳理活动分解为一组特性并收集到列表按优先级排序的列表中。

Sprint （冲刺）首先是Sprint 计划（也称冲刺计划），在Sprint过程（也称Sprint执行）包含开发工作，最后是评审和回顾。Sprint由图最大的环形箭头表示。产品列表中的条目可能超过开发团队一个Sprint中可以完成的工作量。因此，在每个Sprint开始时，开发团队必须把自己认为能够完成的PBI的子集确定下来–这个活动成为Sprint规划会（sprint planning）。

接下来是Sprint执行（Sprint execution），开发团队执行一些必要的任务，以实现所选功能。 在sprint执行中的每一天，团队成员都要进行同步、检查与调整计划，通过**每日例会（standup meeting）**这种活动来帮助管理工作流。 在Sprint执行结束时，团队产出一个潜在的可发布产品增量，体现产品负责人所构想的部分产品，并不是全部。

Scrum团队在Sprint结束后要执行两个“检视与调整”活动。第一个，称为sprint评审（sprint review），利益干系人和Scrum团队检视正在构建的产品。 第二个活动称为sprint回顾（sprint retrospective），Scrum团队在这个活动中检视构建产品时所用的Scrum过程。 这些活动带来的结果可能对产品列表或团队开发部分过程进行适应性调整。

此时再次重复进行scrum sprint的循环过程，在重新开始时开发团队要确定能够完成的下一批最重要的PBI（产品列表条目）。在完成适当的Sprint之后，就可以实现产品负责人的构想并发布解决方案。

产品列表（Product Backlog Item/PBI）

在使用scrum时，我们总是先做最有价值的工作。产品负责人结合Scrum团队其他成员与利益干系人的意见，最终负责确定和管理工作顺序，并采取产品列表（按优先级排列/排序的列表）的形式传达给别人。在开发新产品时，PBI在刚开始时是为满足产品负责人的设想而需要开发的特性。对于正在开发的产品，产品列表也可能包含新特性、对现有特性的变更、需要修复的缺陷以及技术改进点等。

产品负责人与内外部利益干系人合作收集并定义PBIO接下来确保PBI是以正确的顺序（使用类似于价值、成本、知识和风险之类的因子）放置的，使高价值条目出现在产品列表的顶部，低价值条目出现在底部。产品列表是一个不断演进的工件。在业务环境发生变化或Scrum团队（通过Sprint获取对软件的反馈）深入了解产品后，可以添加、删除或修改其中的条目。

总体来说，建立和优化PBI、估算并确定他们的优先顺序，这样的活动成为**“梳理”**。

在确定好优先顺序、排好序或者说是安排好产品列表之前，还需要知道产品列表中每个条目的大小

条目大小等同于成本，为了合理确定条目的优先级，产品负责人需要知道条目的成本。Scrum没有规定PBI的大小要用哪种方法来测量。在实践中，很多团队使用相对大小测量，例如故事点（story point)或理想天数。在使用相对大小测量表达项目的整体大小时，不考虑绝对值，而是考虑一个条目与其他条目的相对值。例如，在上图中，特性C的大小是2，特性E的大小是8。由此可以得出结论，特性E的大小大约是特性C的4倍。

Sprint（冲刺）

在Scrum中，工作在不超过一个月的迭代或循环中进行，这个迭代被成为Sprint（冲刺）。每个Sprint完成的工作应当创建一些对客户或用户来说具有明确价值的东西。

冲刺是有一定时间范围的，总是有固定的开始和结束日期，而且一般来说冲刺的持续期应当都是相等的。前一个冲刺结束后马上就会开始一个新冲刺。在一个冲刺中通常不允许改变范围内的目标或是更换人员，不过，有时业务需求使我们无法遵守这个规则。

Sprint 计划（Sprint Planning）

产品列表体现的可能是多周或多个月的工作，是一个短期的冲刺根本无法完成的。为了确定下一个冲刺要构建的PBI最重要的子集，产品负责人、开发团队和ScrumMaster需要做冲刺规划。

在做冲刺规划期间，产品负责人和开发团队要对当前冲刺准备实现的冲刺目标达成一致意见。针对这个目标，开发团队要对产品列表进行评审，确定在以可持续的节奏工作时根据实际情况在当前冲刺中能够完成的高优先级条目一一一可持续的节奏指的是开发团队能够轻松、长时间保持的工作节奏。

为了获得完成工作的信心，很多开发团队都会把每个需要完成的特性分解为一组任务。这组任务及其相关的PBI组成了第二个列表，称为“冲刺列表”。

接下来，开发团队给出完成每项任务所需工作量的估算值（通常以小时计）。把PBI分解为任务是一种设计形式，是适时(just-in-time）制定特性完成计划。
大多数Scrum团队在执行一个两周到一个月的冲刺时，都尽量在大约4到8小时内完成冲刺规划。一个一周的冲刺中，用于计划的时间应当不超过几个小时（或许还应当更短）。此时有几种方法可以使用。

最常用的方法是遵照一个简单的循环：选择一个PBI（尽可能选择由产品负责人定义的下一个最重要的条目），把条目分解成任务，确定把所选择的项目放到冲刺中是否合适（要和同一个冲
刺中的其他条目结合起来考虑）。如果合适并且还有更多的能力完成工作，可以重复这个循环过程，直到团队没有能力再做更多的工作为止。另外一个方法是由产品负责人和团队一次选择所有目标PBIO由开发团队自己独立分解任务，确认团队是否确实可以交付所有选定的PBI。

Sprint 执行（Sprint Execution）

在Scrum团队完成冲刺计划并就下一个冲刺的内容达成一致意见后，开发团队就要在ScrumMaster的指导下，执行为了完成特性而所需的所有任务级的工作，此处所说的“完成”指
的是非常有信心地认为对于产出高质量特性所需的所有工作都己完成了。

当然，团队要执行哪些类型的任务，取决于工作特点。例如，我们是在构建软件吗，构建的是什么类型的软件？或者我们是在制造硬
件吗？或者这是一个市场推广工作吗？没有人告诉开发团队在完成一个冲刺列表的这段时间中以什么顺序、什么方式执行任务级的工作。相反，团队成员要定义自己的任务级工作，然后按照自认为最好的方式进行自组织并实现冲刺目标。

每日例会（Daily Scrum）

在冲刺期间的每一天，理想的做法是在每天同一时间，开发团队举行一定时间范围内的每日例会。这个检视与调整活动有时也称为“每日站会”，因为大家站着开会可以使会议简明扼要。

举行每日例会的一个常见做法是ScrumMaster负责确保会议更顺畅，每个团队成员都要轮流回答三个问题，让其他团队成员了解情况。

在上次每日例会之后我完成了什么？
在下次每日例会之前我计划做什么工作？
有什么障碍让我无法取得进展？

通过回答这些问题，每个人都能了解全局，知道发生了什么事情，实现冲刺目标的进展如何，对当天的工作，是否需要修改计划，有什么需要处理的问题。每日例会是必不可少的，能够帮助团队管理一个冲刺内快速、灵活的工作流。

每日例会不是用来解决问题的。相反，很多团队会选择把问题的讨论放到每日例会之后和一小部分感兴趣的人讨论。每日例会也不是传统意义上的状态会议，尤其不是以前那种由项目经理召集、为了解项目最新状态而举行的会议。不过每日例会对于开发团队成员交流冲刺列表条目的状态也是可能有帮助的。每日例会主要是一个检视、同步、适应性制定每日计划的活动，以帮助组织团队更好地完成工作。

完成

在scrum中，我们把冲刺的成果称为“潜在可发布产品增量”，意思是按照大家一致同意的“完成"的定义来看，scrum团队同意做的所有东西都做完了。这个定义明确说明了要有信心确保完成的工作是高质量的、潜在可发布的。例如，在开发软件时，“完成”的最低限度的定义是应当产出一个完整的产品功能，经过设计、构建、集成、测试并且编写了文档。

“完成”最激进的一个定义是当业务部门想要交付（或部署、发布）时，能够确定每个冲刺中要为内外部客户构建什么。

需要明确一点，“潜在可发布”并不是说构建的东西必须实际交付。交付是一个业务上的决策，经常受其他因素的影响，比如“我们是否开发了足够的特性或足够的客户工作流来满足客户的部署要求？”或者“我们两星期前才给过客户一个版本，他们能够消化另外一次修改吗？”

“潜在可发布”最好理解为对冲刺中实际构建的产品的一种信心，意味着如果业务部门想要交付的话，那么我们在交付这个冲刺的结果之前，不需要再做其他重要工作（比如重要的测试和集成等）。

在实际应用时，随着时间的推移，有些团队可能会修改完成的定义。例如，在游戏开发早期，提交一些潜在可发布物在经济上不可行或是不可取（因为游戏开发的早期是探索性质的）。在这些情况中，“完成”的一个适当的定义可以是完成一部分产品功能，提供的功能和可以使用的程度足以用来反馈，让团队确定下一个Sprint需要做什么、如何完成。

Sprint评审（Sprint Review）

在Sprint技术时还有两个**sprint评审（sprint review）**和 **sprint回顾（sprint retrospective）**活动，这个活动的目的是检查与调整正在构建的产品。这个活动很重要的一点是在参与者之间进行的交谈，包括scrum团队、利益干系人、发起人、客户和其他团队中感兴趣的成员。交谈的重点是在把刚刚做完的特性放到整体开发工作的背景下进行讨论。每个参与者都能清楚了解现状，都有机会指导下一步开发工作，以确保产出最合适的解决方案。

成功的冲刺评审会议可以促成双方充分交流信息。非Scrum团队的人员能够跟上开发工作并帮助指导开发方向。同时，在与业务部门一起交付满足客户或用户需要的产品时，经常收到反馈可以使scrum团队进一步理解产品的业务和市场。因此，冲刺评审是一个预先安排的检查与调整活动。在实践中，非scrum团队的人员可以在冲刺之间进行特性评审并提供反馈，帮助Scrum团队更好地实现冲刺目标。

Sprint回顾（Sprint Retrospective）

冲刺评审是检视和调整产品的时间，而冲刺回顾则是检视并调整过程的时机。在进行冲刺回顾时，开发团队、ScrumMaster和产品负责人聚到一起讨论scrum及相关技术实践中哪些是可行的、哪些是不可行的。重点关注的是必要的持续过程改进，帮助优秀的Scrum团队成长为卓越的团队。在冲刺回顾活动结束时，Scrum团队应当找出数量适中的过程改进项并承诺在下一个冲刺中采用。在完成冲刺回顾之后，再次重复整个过程一一开始时是下一个冲刺规划会议，举行这个会议的目的是确定当前团队必须关注的价值最高的工作。