近期研究前 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 条目。
• 挂图......

　　注意事项：不要估算任务，不要分配任务。

　　会议输出

• 应用设计、架构设计图、相关图表
• 确保团队知道应该怎样完毕任务！

　　会议过程

• 从第一个 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 规划会议第二部分的输入，并决定到时候要怎样处理这些发现的信息。

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