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

　　Scrum 工具

 

　　•禅道
    •JIRA+GreenHoppe

 

　　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 的数量），人天等。