最近把之前学习 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小时发送提醒。 准备带有会议规则的挂图。

会议推进

? ? ? ? ?

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

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

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

会议输出

? ?

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

让团队坐在一起！

? ? ? ?

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

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

团队建设