Scrum

最近把之前学习 Scrum 的资料整理为一篇文档，在接下来的团队和项目开发中，根据项目的情况引入 Scrum 的一些实践，提高团队成员之间的协作能力和项目的交付质量。 参考资料：

? ? ? ? ?

《轻松Scrum之旅—敏捷开发故事》、《敏捷无敌》 硝烟中的Scrum 和 XP 火星人敏捷开发手册 Scrum-Checklists 维基百科：http://zh.wikipedia.org/wiki/Scrum Scrum 工具

? ?

禅道 JIRA+GreenHopper

Scrum 中的角色

Scrum Master——项目负责人、项目经理

保护团队不受外界干扰，是团队的领导和推进者，负责提升 Scrum 团队的工作效率，控制 Scrum 中的“检视和适应”周期过程。与 Product Owner 一起将投资产出最大化，他确保所有的利益相关者都可以理解敏捷和尊重敏捷的理念。 Team——开发人员、测试人员、美工设计、DBA等全职能性团队

团队负责交付产品并对其质量负责，团队与所有提出产品需求的人一起工作，包括客户和最终用户，并共同创建 Product Backlog 。团队按照大家的共识来创建功能设计、测试 Backlog 条目交付产品。

Product Owner——产品负责人、产品经理、运营人员

从业务角度驱动项目，传播产品的明确愿景，并定义其主要特性。Product Owner 的主要职责是确保团队只开发对于组织最重要的 Backlog 条目，在 Sprint 中帮助团队完成自己的工作，不干扰团队成员，并迅速提供团队需要的所有信息。 User——最终用户、运营人员、系统使用人员

很多人都可能成为最终用户，比如市场部人员、真正的最终用户、最好的领域专家，也可能是因其专业知识而被雇佣的资讯顾问。最终用户会根据自己的业务知识定义产品，并告知团队自己的期望，提出请求。 Manager——管理层、投资人

管理层要为 Scrum 团队搭建良好的环境，以确保团队能够出色工作，必要的时候，他们也会与 Scrum Master 一起重新组织结构和指导原则。 Customer——客户、系统使用人员、运营人员

客户是为 Scrum 团队提出产品需求的人，她会与组织签订合同，以开发产品。一般来说，这些人是组织中的高级管理人员，负责从外部软件开发公司购买软件开发能力。在为内部产品的公司中，负责批准项目预算的人就是客户。 Scrum 中的产出物

Product Backlog——Backlog 待开发项，积压的任务。

产品 Backlog 包括了所有需要交付的内容，其内容根据业务需求的价值顺序排列，每个 Backlog 的优先级是可以调整的，需求是可以增减的，因此产品 Backlog 将根据不断增长来持续驱动维护。

Sprint Backlog——Sprint 本意为“冲刺”，指迭代周期，长度通常是一至六周。

在 Sprint 开始前，定义本次 Sprint 要讨论的“Sprint Backlog”，从中产生本次 Sprint 要完成的 “已定 Product Backlog”。

已定 Product Backlog

Sprint 计划会议的产物，它定义了团队所接受的工作量，在整个 Sprint 过程中它将保持不变。 User Story、Task——用户故事、任务

用 User Story 来描述 Sprint Backlog 里的项目，User Story 是从用户的角度对系统的某个功能模块所作的简短描述。一个 User Story 描述了项目中的一个小功能，以及这个功能完成之后将会产生什么效果，或者说能为客户创造什么价值。一个 User Story 的大小和复杂度应该以能在一个 Sprint 中完成为宜。如果 User Story 太大，可能会导致对它的开发横跨几个 Sprint，此时就应该将这个 User Story 分解。

为了能够及时，高效地完成每个 Story，Scrum 团队会把每个 Story 分解成若干个 Task。每个Task 的时间最好不要超过8小时，保证在1个工作日内完成，如果 Task 的时间超过了8个小时，就说明Task的划分有问题，需要特别注意。 障碍 Backlog——问题列表，积压的待处理事务。

列举了所有团队内部和团队相关的和阻碍项目的进度的问题，Scrum Master 需要确保所有的障碍 Backlog 中的问题都已分配并可以得到解决。 通用会议规则 基本要求

? ?

每次会议都要准时开始、准时结束。

每次会议都采取开放形式，所有人都可以参加。

会前准备

? ?

提前邀请所有必须参会的人，让他们有时间准备。 发送带有会议目标和意图的会议纲要。

? ? ?

预订会议所需的全部资源：房间、投影仪、挂图、主持设备，以及此会议需要的其他东西。 会前24小时发送提醒。 准备带有会议规则的挂图。

会议推进

? ? ? ? ?

展开讨论时，会议的推进人必须在场。他不能参与到具体讨论中，但是他需要注意讨论进程，如果讨论参与者失去重点，他还要将讨论带回正规。 推进人展示会议的目标和意图。

有必要时，推进人可以商定由某个撰写会议记录。

推进人可以记录团队的意见，或是教授团队如何自己记录文档；而且推进人可能会在挂图上进行记录，将对话可视化。 推进人会对会议进行收尾，并进行非常简短的回顾。

会议输出

? ?

使用手写或挂图说明来记录文档，给白板和挂图上的内容拍照。 必须传达会议记录和大家对会议结果的明确共同认知。

让团队坐在一起！

? ? ? ?

大家都懒的动，尽量让“产品负责人”和“全功能团队”都坐在一起！ 互相听到：所有人都可以彼此交谈，不必大声喊，不必离开座位。

互相看到：所有人都可以看到彼此，都能看到任务板——不用非得近到可以看清楚内容，但至少可以看到个大概。 隔离：如果你们整个团队突然站起来，自发形成一个激烈的设计讨论，团队外的任何人都不会被打扰到，反之亦然。

团队建设

? ? ?

Scrum 团队最佳人数控制在“5～9”人。

全职能性团队：开发组（后台开发、前端开发、测试人员——3~8人）、Scrum Master（项目经理）、产品负责人 兼职团队成员：美工、DBA、运维

每日立会（Daily Standup Meeting）——建议下班前开始 会议目的

? ?

团队在会议中作计划，协调其每日活动，还可以报告和讨论遇到的障碍。 任务板能够帮助团队聚焦于每日活动之上，要在这个时候更新任务板和燃尽图。

构成部分

? ?

任务板、即时贴、马克笔

提示：ScrumMaster 不要站在团队前面或是任务板旁边，不要营造类似于师生教学的气氛。

基本要求

? ? ? ?

成员：团队、Scrum Master 无法出席的团队成员要由同伴代表。

持续时间/举办地点：每天15分钟，同样时间，同样地点。

提示：团队成员在聆听他人发言时，都应该想这个问题：“我该怎么帮他做得更快？”

会议输出

? ?

团队彼此明确知道各自的工作，最新的工作进度图。 得到最新的“障碍 Backlog”

? 得到最新的“Sprint Backlog”

会议过程

? ? ? ? ? ?

团队聚在故事板旁边，可以围成环形。

从左边第一个开始，向团队伙伴说明他到现在完成的工作。 然后该成员将任务板上的任务放到正确的列中。

如果可以的话，该成员可以选取新的任务，交将其放入“进行中工作”列。 如果该成员遇到问题或障碍，就要将其报告给 Scrum Master。 每个团队成员重复步骤2到步骤5。

每个人三个问题：

? ?

上次会议时的任务哪些已经完成？：把任务从“正在处理”状态转为“已完成”状态。——今天完成了什么？

下次会议之前，你计划完成什么任务？：如果任务状态为“待处理”，转为“正在处理”状态。如果任务不在 Sprint Backlog 上，则添加这个任务。

如果任务不能在一天成，把这任务细分成多个任务。如果任务可以在一天内完成，把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”，询问是否存在阻碍任务完成得问题。——明天做什么？

? 有什么问题阻碍了你的开发？：如果有阻碍你的开发进度的问题，把该障碍加入到障碍 Backlog中。——今天遇到了什么问题？

注意事项

? ? ? ?

不要迟到 不要超出限制时间 不要讨论技术问题 不要转变会议话题

? ? ? ?

不要在没有准备的情况下参加

Scrum Master 不要替团队成员移动任务卡片，不要替团队更新燃尽图。

Scrum Master 不要提出问题，团队成员不要向 Scrum Master 或管理层人员报告。 如果不能出席会议，需要通知团队，并找一名代表参加。

任务板

? ? ?

任务板集合了选择好的 Product Backlog 和 Sprint Backlog，并以可视化方式展示。

任务板只能由团队维护，使用不同颜色的“即时贴”来区分开发人员，或者在“即时贴”写上接受任务的姓名。 尽量使用大白板，也可以使用软件。

任务板有4列：

? ?

选择好的 Product Backlog：按照优先级，将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。

待完成的任务：要完成一个故事，你得完成一些任务。在 Sprint 规划会议中，或是在进行当前 Sprint 中，收集所有特定 Backlog 条目需要完

成的新任务，并将它们放入该列。

进行中的工作：当团队成员开始某个任务后，他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始，没有完成的任

务都会放在该列中，并在上面做标记（通常是个红点）。如果某个任务在“待完成任务”列中所处时间超过一天，就尽量将该任务分为更小 的部分，然后把新任务放到那一列，移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成，就会得到一个红点标记，Scrum Master 就会记下一个障碍。

?

? 完成：当一个任务卡完成后，完成此任务的成员将其放入“完成”列，并开始选取下一张任务卡。

燃尽图（Burn Down Chart）

?

跟踪进度要由团队来完成，燃尽图的横轴表示整个Sprint 的总时间，纵轴表示 Sprint 中所有的任务，其单位可以是小时，人天等。一般来说，

燃尽图有”Sprint燃尽图”和”Release燃尽图”之分。

团队每天更新燃尽图。

如果燃尽图一直是上升状态，或当 Sprint 进行一段时间之后，Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几，就说明这个 Sprint 中

的 Story 过多，要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果Sprint 燃尽图下降得很快，例如 Sprint 刚过半时Y值已经接近0了，则说明

? ?

这个 Sprint 分配的任务太少，还要多加一些任务进来。在 Sprint 计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。（锻炼团队人员的自我估算时间）

?

燃尽图要便于团队更新，没必要让它看起来很炫，也不要过于复杂，难以维护。

Release 燃尽图：记录整个Scurm项目的进度，它的横轴表示这个项目的所有Sprint， 纵轴表示各个Sprint开始前，尚未完成的工作，它的单位可以是个（Story 的数量），人天等。

Sprint 规划会议——第一部分（上午） 会议目的

?

该会议的工作以分析为主，目的是要详细理解最终用户到底要什么，产品开发团队可以从该会议中详细了解最终用户的真实需要。在会议的结束，

团队将会决定他们能够交付哪些东西。

产品负责人在会前准备：条目化的需求（用户故事），优先级排序，最近1~2个迭代最希望看到的功能。会前准备至关重要，可帮助产品负责人

理清头绪，不至于在迭代期内频繁提出变更、增加或删除故事。 基本要求

?

? ?

迭代计划会在每个迭代第一天召开，目的是选择和估算本次迭代的工作项。

只有团队成员才能决定团队在当前 Sprint 中能够领取多少个 Backlog 条目的工作。

构成部分：

? ? ? ?

经过估算和排序的 Product Backlog。

挂图、马克笔、剪刀、胶水、即时贴、白板、铅笔和蜡笔。 假期计划表、重要人员的详细联系信息。

参会成员：团队成员、Scrum Master、产品负责人

持续时间：在 Sprint 中，每周该会议占用时间为 60 分钟，在早上召开该会议，这样还有可能在同一天召开 Sprint 规划会议的第二部分。 会议输出

? ?

选择好的 Product Backlog 条目。 各个 Backlog 条目的需求。

? 各个 Backlog 条目的用户验收测试。

会议过程

? ? ? ? ? ? ? ? ?

从第一个 Product Backlog 条目（故事）开始。 讨论该 Product Backlog 条目，以深入理解。 分析、明确用户验收测试。

找到非功能性需求（性能、稳定性...） 找到验收条件。

弄清楚需要“完成”到何种水平。

获得 Backlog 条目各个方面的清晰了解。

绘制出所需交付物的相关图表，包括流程图、UML图、手绘草图、屏幕 UI 设计等。 回到步骤1，选取下一个 Backlog 条目。

流程检查：询问团队能否快速回答下列问题，只需要简要回答即可：“我们能 在这个 Sprint 中完成第一个 Backlog 条目吗？”如果能得到肯定的回答，那么继续询问下一个 Backlog 条目，一直到已经分析完的最后一个 Backlog 条目。——接下来，休息一下。在休息后，对下一个 Backlog 条目展开上述流程。 结束流程：

? ? ? ? ?

在 Sprint 规划会议第一部分结束前留出 20 分钟。

再次提问——这次要更加严肃、正式：“你们能否完成第一个 Backlog 条目，...第二个，...？” 如果团队认为他们不能再接受更多的 Backlog 条目，那就停下来。

现在是非常重要的一步：送走 Product Owner，除了团队和 Scrum Master 之外的所有人，都得离开。 当其他人都离开后，再询问团队：“说真的——你们相信自己可以完成这个列表？”

? ?

希望团队现在能短暂讨论一下，看看他们到底认为自己能完成多少工作。 将结果与 Product Owner 和最终用户沟通。

注意事项：不要改变 Backlog 条目大小，不要估算任务。 Sprint 规划会议——第二部分（下午） 会议目的

? 该会议的工作以设计为主，产品开发团队可以为他们要实现的解决方案完成设计工作，在会议结束后，团队知道如何构建他们在当前 Sprint 中

要开发的功能。 基本要求

? 只有产品开发团队才能制定解决方案，架构师或其他团队之外的人只是受邀帮助团队。

构成部分：

? ? ?

能够帮助团队在该 Sprint 中构建解决方案的人，比如厂商或是来自其他团队的人员。 选择好的 Product Backlog 条目。 挂图......

注意事项：不要估算任务，不要分配任务。 会议输出

? ?

应用设计、架构设计图、相关图表 确保团队知道应该如何完成任务！

会议过程

? ? ? o o o o o

从第一个 Backlog 条目开始。

查看挂图，确定对于客户的需求理解正确。

围绕该 Backlog 条目进行设计，并基于下列类似问题：

我们需要编写什么样的接口？ 我们需要创建什么样的架构？ 我们需要更新哪些表？

我们需要更新或是编写哪些组件？ ......

当团队明确知道自己应该如何开发该功能后，就可以转向下一个 Backlog 条目了。在会议的最后 10 分钟，团队成员使用即时贴写出初步的任务。这能帮助团队成员知道接下来的工作从哪里开展，将这些任务放在任务板上。

持续时间：在 Sprint 规划会议第一部分完成后，召开该会议。可以将午餐作为两次会议的一个更长久的休息。但是要在同一天完成 Sprint 规划第一部分，在 Sprint 中，每周该会议占用时间为 60 分钟。 估算会议——根据项目情况合并到 Sprint 第二部分会议 会议目的

? 要做好战略规划，你需要知道 Backlog 中各项的大小，这是版本规划的必要输入；如果想知道团队在一个 Sprint 中能够完成多少工作，这个数

据也是必须的。

团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。

基本要求

?

? 只有团队才能作估算，Product Owner（产品负责人）需要在场，以帮助判定某些用户故事能否拆分为更小的故事。

构成部分：

? ?

Product Owner 根据业务价值排定 Product Backlog 各项顺序。 需要参加的人员：Team、Product Owner、User、Scrum Master

注意事项：

? ?

不要估算工作量大小——只有团队能这么做。 Product Owner 不参与估算。

会议过程

? ? ?

Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。 团队使用规划扑克来估算 Backlog 条目。

如果某个 Backlog 条目过大，需要放到下一个或是后续的 Sprint 中，团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目，并对新

的 Backlog 条目使用规划扑克进行估算。

重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。

持续时间：该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周，那么每个 Sprint 举行两次估算会议比较合适。 会议输出

?

? ?

经过估算的 Product Backlog。 更小的 Backlog 条目。

扑克牌估算（Planning Poker）

具体步骤：

? ? ? ?

每个人各自估算后独立出暗牌，听口令一起开牌。 数值最大者与最小者PK，其他人旁听也可参考。 讨论结束后重新出牌和开牌。 重复上述过程，直到结果比较接近。

常见问题

1、为什么任务要分给组而不是个人？

答：因为怕出错了牌又说不出所以然，这样即使日后他不做这个功能，也对这个功能很了解。 2、为什么不让最后领任务的人自己估算？

答：因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。 3、为什么不让师傅估算大家采纳，他不是最厉害吗？

答：师傅的想法常常是徒弟们理解不了的，比如为什么不留在女儿国而偏偏去西天取经之类的，共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。

Sprint 评审会议（Review Meeting）——根据项目需要举行 会议目的

? Scrum 团队在会议中向最终用户展示工作成果，团队成员希望得到反馈，并以之创建或变更 Backlog 条目。

基本要求

? Sprint 复审会议允许所有的参与者尝试由团队展示的新功能。

构成部分

? 有可能发布的产品增量，由团队展示。

会议输出

? ? ? ?

来自最终用户的反馈。 障碍 Backlog 的输入。 团队 Backlog 的输入。

来自团队的反馈为 Product Backlog 产生输入。

持续时间：90分钟，在 Sprint 结束时进行。 会议过程

? ? ? ? ?

Product Owner 欢迎大家来参加 Sprint 复审会议。

Product Owner 提醒大家关于本次 Sprint 的目的：Sprint 目标、Scrum 团队在本次 Sprint 中选定要开发的故事。 产品开发团队展示新功能，并让最终用户尝试新功能。 Scrum Master 推进会议进程。

最终用户的反馈将会由 Product Owner 和/或 Scrum Master 记录在案。

注意事项：

? ?

不要展示不可能发布的产品增量。 Scrum Master 不要负责展示结果。

? ?

团队不要针对 Product Owner 展示。

Sprint 反思会议（Retrospective Meetin）——根据项目需要举行

会议目的

? 该会议的对应隐喻：医疗诊断！其目的不是为了找到治愈方案，而是要发现哪些方面需要改进。

构成部分

? 参与人员：团队成员、Scrum Master

基本要求

? ?

从过去中学习，指导将来。 改进团队的生产力。

注意事项

? ?

不要让管理层人员参与会议。 不要在团队之外讨论找到的东西。

会议输出

? ?

障碍 Backlog 的输入。 团队 Backlog 的输入。

持续时间：90分钟，在 Sprint 评审会议结束后几分钟开始。 会议过程

? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

准备一个写着“过去哪些做的不错？”的挂图。 准备一个写着“哪些应该改进？”的挂图。 绘制一条带有开始和结束日期的时间线。 给每个团队成员发放一叠即时贴。 开始回顾。 做一个安全练习。

收集事实：发放即时贴，用之构成一条时间线。每个团队成员（包括 Scrum Master）在每张即时贴上写上一个重要的事件。 “过去哪些做的不错？”：采取收集事实同样的过程，不过这次要把即时贴放在准备好的挂图上。 做一个分隔，以区分“过去哪些做的不错”和接下来要产出的东西。 “哪些应该改进？”：像“过去哪些做的不错”那样进行。 现在将即时贴分组：

我们能做什么》团队 Backlog 的输入。

哪些不在我们掌控之内？》障碍 Backlog 的输入。 根据团队成员的意见对两个列表排序。

将这两个列表作为下个 Sprint 的 Sprint 规划会议第一部分和 Sprint 规划会议第二部分的输入，并决定到时候要如何处理这些发现的信息。

附两张流程图（资料截图）

Sprint Review Meeting（Sprint评审会）

在Sprint结束的时候召开Sprint评审会. 这个会议最多不超过4个小时.会议的前一半时间用来演示在这个Sprint中开发的产品功能给 Product Owner. Produc Owner会组织这阶段的会议并且邀请相关的利益相关者参加。 业务，市场，技术都要做相关的评审。由Product Owner来决定Product Backlog中的哪些功能已经开发完成 。会议的下半部分，是由Scrum Master和Scrum Team一起回顾当前的Sprint。团队评估大家在一起的工作方式，找出好的方式以后继续发扬，找出需要做的更好的地方，想办法提升。Sprint评审会结束后，新一轮的迭代又继续开始（中间最好修整半天或者隔个周末），迭代会一直继续，直到开发了足够多的功能去交付一个产品。

敏捷开发模型之SCRUM方法简介

敏捷开发模型之SCRUM方法简介

由Ken Schwaber和 Jeff Sutherland 提出，旨在寻求充分发挥面向对象和构件技术的开发方法，是对迭代式面向对象方法的改进，名称来自英式橄榄球(在比赛中每个队员都应时刻保持对场上全局的判断，然后通过集体行动，奋力实现同一目标──胜利)。

SCRUM方法最初实践于Easel公司(1993年)，现已被数十家公司数百个项目开发中应用，适用于需求难以预测的复杂商务应用产品的开发[11]。SCRUM提出的SCRUM Meeting、Sprint、Backlog、SCRUM Master、SCRUM Team、Demo等模式已被PLOP作为组织和过程模式(Organizational and Process Pattern)的标准[12]。

SCRUM将工业过程控制中的概念应用到软件开发中来，认为软件开发过程更多是经验性过程(Empirical Process)，而不是确定性过程(Defined Process)。确定性过程是可明确描述的、可预测的过程，因而可重复(Repeatable)执行并能产生预期的结果，并能通过科学理论对其最优化。经验性过程与之相反，应作为一个黑箱(Black box)来处理，通过对黑箱的输入输出不断进行度量，在此基础上，结合经验判断对黑箱进行调控，使其不越出设定的边界，从而产生满意的输出。

SCRUM方法将传统开发中的分析、设计、实施视为一个黑箱，认为应加强黑箱内部的混沌性，使项目组工作在混沌的边沿，充分发挥人的创造力。如将经验性过程按确定性过程来处理(如瀑布模型)，必将使过程缺乏适应力。 SCRUM方法的开发过程包括三个过程：

(1) 计划和体系结构设计(确定性过程)

将Backlog(急待完成的一系列任务，包括：未细化的产品功能要求、Bugs、缺陷、用户提出的改进、具竞争力的功能及技术升级等)按优先级排序形成Backlog 列表，根据该表和风险评估制订产品交付基线。

建立系统体系结构(如为已有系统改进，则只作有限分析、调整)，将Backlog项按高内聚低耦合的原则分解为一系列问题包(Packets,每个Packet是一组对象或构件的集合) ，依据同样原则相应划分若干个开发小组(SCRUM Team),分配各小组合适的Backlog项或问题包。建立开发运行环境。

(2) Sprint(经验性过程)

该过程由若干个迭代的疾跑(Sprint) 活动组成，直至风险评估认为产品可交付为止。一个Sprint是在限定时间段内(Sprint周期，通常为1~6周，可在前一个Sprint结束时调整)的一系列开发活动(包括分析、设计、编码、测试等)，每个SCRUM Team并行开发且必须步调一致(在一个Sprint结束后，均须完成所分配的Backlog项并有可执行的产出)。 每个Sprint包含以下活动：

A: 开发。对分配的Backlog工作进行分析，将所需改动(changes)映射到各packets，打开packets,进行领域分析，然后设计、开发、实施、测试、文档化这些改动。

B:打包(Wrap)。封装packets,产生一个满足Backlog需求的可执行版本。ITPUB个人空间7J{9k*M3J.i

C:评审(Review)。所有的SCRUM小组一起开会，提交各自的工作并演示(Demo)，然后提出和解决问题(Issue)及难点(problem),增加新的Backlog项;发布、审查或调整产品的标准规范;进行风险评估并提出合适的对策;确定下一个Sprint的工作内容和结束时间。 D:调整(Adjust)。根据评审会汇集的信息，对受影响的Packets进行适当调整和巩固。 (3) 交付和巩固(确定性过程)

一旦根据风险评估结果认为可交付产品时，即进入该阶段。该阶段的活动包括：组装，系统测试和回归测试(Regression)，准备培训材料，完成最终文档。

过程认为一个产品的开发将一直持续下去，除非经风险评估后认为应停止。产品交付后的巩固活动类似于传统方法中的维护和改善，目的在于整理Sprint期压力下忽略的工作，为下一阶段的开发做准备，以便轻装上阵。

SCRUM对过程的管理： (1) SCRUM的控制手段。

SCRUM提出了八个控制项(Controls)用于开发过程的调控，其中风险控制是首要的手段。 A:Backlog。 B:对象/构件。 C:Packets。

D:变动(Changes)。实施一个Backlog项时，对相应Packet的改动。 E:难点(Problems)。实施一个变动时所必须解决的技术难点。

F:问题(Issues)。涉及到整个项目或在Backlog项分解到Packet之前须解决的问题。 G:措施(Solutions)。对问题或难点的解决，通常会导致变动。

H:风险(Risks)。影响项目成功的风险，应持续跟踪评估并相应做出调整。风险评估的结果将影响其他所有控制项。SCRUM定义了六个概念性变量来用于风险评估：用户需求，时间压力，竞争，质量，远见(vision)和可用资源。

在SCRUM的各个阶段都使用这些控制项来评估和权衡，管理人员侧重于以此管理Backlog，开发组用以处理变动和难点。所有人员一起来管理问题、风险和措施。

根据对控制项特别是风险的不断度量评估和权衡，一方面，计划和进度(在每个Sprint结束时)不断相应调整，保证实现产品的商务目标;另一方面，对开发中的工作任务Backlog动态地进行优先级排序，开发组总是先开发优先级最高的Backlog项，这样就保证了资源的最合理使用。另外，SCRUM强调度量(采用标准功能点度量方法)的重要性，通过对每个Sprint中生产率等的度量，计划和进度将越来越趋于准确。 (2) 项目组织。

项目组由全职开发人员及与该交付产品有关的市场人员、销售人员、用户等组成。设以下小组：ITPUB

A:项目管理组。由产品经理领衔，包括总设计师，各SCRUM小组组长，市场、销售的高级职员及典型用户等。

B: 若干个SCRUM小组。各小组由组长(SCRUM Master)领衔。每个小组都是跨专业的(通常包括开发人员，文档人员，质量控制人员或用户代表等)，通常为3~7人，以使小组内有充分的交流。小组的划分最好是功能导向的(按所分配的问题包或Backlog)，也可是系统层次导向(按体系结构中的分层)。.

在项目组人数增大时，可在管理组之上再设管理组(SCRUM of SCRUM),从而使SCRUM方法的应用到大项目中。 (3) Sprint期间的调控。

在Sprint期间，应使各SCRUM小组尽量避免外界的干扰(不可将新的Backlog任务加进来，组内产生的Backlog可放到整个项目的Backlog列表中，也可在本次Sprint中解决

在Sprint期间，应使各SCRUM小组尽量避免外界的干扰(不可将新的Backlog任务加进来，组内产生的Backlog可放到整个项目的Backlog列表中，也可在本次Sprint中解决)，使小组成员专心于目前的工作，使他们工作在混沌的边沿。 为避免项目组在Sprint期间不陷入混乱，SCRUM采取两个措施:

A:SCRUM会议(SCRUM Meeting)。对小组行为进行监控和刺激。会议在Sprint期间每天在同一地点举行，由SCRUM Master主持。会议上，SCRUM Master对每个小组成员提三个问题：

1) 昨天的工作进展如何。 2) 有否遇到困难和障碍。 3) 今天的工作打算。

会后SCRUM Master集中精力排除障碍，小组成员则进行当天的开发。 B:Sprint评审会议。评审后根据对每人的工作成绩，进行相应的激励。 SCRUM方法的实践效果和发展方向

SCRUM在实践中大大提高了生产率(据软件生产率组织的Capers Jones称可提高6倍)，在实施中有一个\间断平衡\

equilibrium)现象(类似于自然界中物种的进化，在经过一段相对平衡的各自独立、并行的发展期后，在交汇处发生变异)，即在经过紧张、并行的Sprint开发后，在Sprint评审时，软件产品产生较剧烈的变化。SCRUM方法的最近动向是设法借鉴XP方法。

如何在项目中实施敏捷开发scrum

.

scrum简介：Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小

的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。

在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。

在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。 Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。 我们的Sprint backlog是大概4周的时间，其中包括2天的sprint 计划会议,2.5周的开发，每日例会穿插在开发时间里，1周的测试改bug，1天的sprint评审会议和sprint回顾会议。 sprint 计划会议:

在开sprint 计划会议前，产品经理必须所要实现的产品需求（产品Backlog）以用户故事的形式确定下来，并画好原型图，UI应该要出设计稿（在sprint 计划会议前出设计稿很重要，因为设计对估算时间影响非常大）。产品经理同时确定各个产品需求的优先级。

开sprint 计划会议期间（一般是2天），开发团队的成员不应该做任何的开发工作，把全部精力都放在把产品需求变为一个个开发任务，并对开发任务估算时间。 估算时间有几点注意：

1. 对于需要使用的新技术，要估算学习和调研的时间。

2. 根据统计，每个程序员每天的有效工作时间是5个小时左右，其他时间都被沟通，喝水，休息，上洗手间等占据，所以如果某个任务估算超过5个小时，那就代表了这个任务完成需要超过一天的时间。

3. 对于开发任务，估算尽可能的细，一般来说，每个任务的估算不应该超过5个小时，如果超过5个小时，就应该再把这个任务细分。只有尽可能细的估算任务，总的时间是大概精确地，因为估算时间是一个正态分布，有的任务估算的时间偏大了，有的时间任务估算的时间偏小了，估算越细，总体下来估算还是准确了。

最后，根据产品经理的优先级和开发人员的估算时间，确定最终的开发任务和优先级，即完成Sprint backlog。

日常开发:

在每个Sprint backlog，后台和app的交互都是通过api，所以由后台先写好相关的api并编写假数据，先让app端可以顺利开展工作。 先编写api和假数据，有两个好处： 1. 能对整个开发计划有个总体的规范。 2. 相当于是TDD（测试驱动开发）。

遇到问题的时候，必须要及时找相关的人员沟通。但这样有个问题，如果开发人员正在开发，被打扰可能会被决定很不爽，为了保证沟通的效果，可以：

1. 如果真的不是非常紧急，可以等相关的人员休息的时候再沟通。

2. 解决一个问题，先梳理情绪，再梳理人际关系，最后才是问题本身。多微笑，别苦着脸，平时待人以善，说好话，存好事，做好事，沟通的时候只针对问题，不针对别人的不良情绪。

3. 可以试一下番茄工作法。但根据我们自身的实践经验，效果不理想。

在创业开发团队中，scrum master 一般是由技术总监担任的。团队外部的沟通，必须统一通过scrum master。即如果市场部，运营部对开发团队有任何要求，必须要经scrum master同意后由scrum master传递进开发团队内部。团队内部的沟通，由团队成员自己解决，如果有重大的决策，必须经scrum master同意。通过scrum master遮蔽外部对开发团队的影响。 在团队建设中，定期的团体活动是个很好的主意，我们一般是周四下午集体去打羽毛球。

通过团体活动，不但能加强团队的凝聚力，而且运动后，整个人沉闷的感觉都消失了，变得神清气爽，活力十足。 在一个Sprint backlog中，需求不能变更，UI确定后原则上只能做小修改。 每日的例会:

在每天的例会前，每个团队成员应该更新自己的任务列表，包括：

1. 昨天完成了哪些任务，每个任务使用了多少时间，没完成的任务估算还需要多少时间 2. 更新总的剩余开发时间

例会一般是产品经理和开发团队的成员都要参加，如果可以的话，让运营人员和市场人员也参加，这样可以使每个成员都公司的产品有个整体的了解。

每个人在例会上说下面3方面的事情： 1. 昨天做了哪些工作。 2. 今天准备做哪些工作。 3. 有什么工作需要其他同事配合。

注意，避免在会议上讨论问题，如果真的需要讨论，请在会议后和同事讨论，不要浪费整个团队的时间。 测试和修bug:

开发完成，就进入测试和修bug的阶段。如果人手不足，可以使用交叉测试的方式，即android开发人员测试iphone的app，iphone开发人员测试android的app，后台，运营，UI等人员看情况分配测试任务。 针对每个bug，应该有3部分：

1. 问题描述和重现步骤 2. 测试人员

3. 负责解决这个bug的人员（这个人员一般由技术总监指定） sprint 评审会议:

一般是全体人员都参加，在测试和修bug后。

iphone的演示有个收费的工具，可以把iphone的屏幕通过电脑放到投影仪，android上没有哪个好用的工具！当时我们的方法是android演示的时候，用iphone的摄像头对着android机，通过iphone的收费工具在投影仪上看。 sprint回顾会议:

每个成员都要参加，每个成员都要提两点： 1. 在这轮sprint中值得表扬的点 在这轮sprint中做得不好的地方

这个过程走两轮，即每个成员都要说2次。

注意，当一个成员提出自己的意见时，其它成员不作任何的批评。

. .

.

本文来源：https://www.bwwdw.com/article/7a2r.html