目录[-]
Scrum是跨职能团队以迭代、增量的方式开发产品或项目的一种开发框架。
它把开发组织成被称为Sprint的工作周期。这些迭代每个都不超过4周（最常见的是两周），并且无间歇地相继进行。Sprint是受时间箱限制的，无论工作完成与否它们都会在特定日期结束，并且从不延长。通常由Scrum团队来选定一个Sprint的时长，并且对于他们所有的Sprint都使用这一时长，直到这个团队能力提高，可以使用较短周期。
在每个Sprint的初始，跨职能团队（大约7名成员）从排好优先级的列表中选择事项（客户需求）。团队对于在Sprint结尾他们相信自己可以交付哪些目标集合达成一致意见，这些交付应该是有形的并且能被真正“完成”的。
在Sprint过程中不可以增加新事项，Scrum在下一Sprint时才接受变化，当前这么短的一个Sprint周期里只注重于短小、清晰、相对固定的目标。团队每天都进行简短会面来检验工作进程，并调整后续步骤以确保完成剩余工作。
在Sprint结尾，团队与利益关系人一起回顾这个Sprint，并演示所构建的产品。团队成员从中获取可以结合到下一Sprint中的反馈。Scrum强调在Sprint结尾产生真正“完成”了的可工作产品。在软件领域是指已经集成的、完全测试过的、已经为最终用户生成文档的、潜在可交付的系统。
产品负责人是一个人，而不是一个委员会。可能会有一些委员会向产品负责人提出建议或影响他的决策，但要想改变某条目的优先级必须先说服产品负责人。
实施Scrum的企业可能发现这样会影响他们制定优先级和需求的方法。
为保证产品负责人的工作取得成功，企业中的所有人员都必须尊重他的决定。任何人都不得要求团队按照另一套优先级开展工作，团队也不允许听从任何人带有威胁恐吓性的指令。产品负责人所作的决定需要通过产品Backlog内容和优先级使其可视化。这种可视化要求产品负责人全力以赴，同时也使其成为一个费心费力但又值得去做的角色。
Scrum Master 需要知道什么任务已经完成，哪些任务已经开始，哪些新的任务已发现，和哪些估算可能已经发生变化。
Scrum Master 需要根据以上的情况更新反映每天完成的工作量以及还有多少没有完成的燃尽图（Burndown Chart）。
Scrum Master 还必须仔细考虑同时在进行开发的任务数，同时进行的工作需要做到最小化，以实现精益生产率的收益。
Scrum Master需要找出阻碍团队的障碍和依赖。他们需要的优先次序和跟踪。根据优先级指定计划解决这些障碍。其中有些问题可以在团队内部解决，有些则要团队之间的协调，还有的要管理层的介入来解决，甚至有些是公司的问题阻碍了团队达到他们的生产力。比如：一个电信公司最近实施了Scrum，但后来发现只有两个问题和Scrum Team有关，其他的全是公司的问题需要管理层关注。
最后但并非最不重要， Scrum Master 可能会注意到，个人问题或冲突在Scrum里是需要解决的。这些都需要被澄清，或通过内部的沟通解决，或向管理层和HR寻求帮助解决。Scrum Master 必须注意去确保团队资源完全可被利用并且全部是高产出的。
Scrum团队的规模控制在5-9个人
Scrum团队是跨职能的团队
Scrum团队是自组织的
产品待办事项列表包括不同种类的事项：
一个好的产品待办事项列表要做到：
优先级列表顶端的事项比低级别的事项更为精确和详细，因为前者要比后者先被开发。比如，待办事项列表顶端的百分之十可能包含非常小且分析得很详细的事项，而其他的百分之九十则不是那么具体。
当前发布版本的事项需要有估算，而且随着大家了解得更多和新信息的融入应当在每个Sprint中重新考虑这些估算。 团队提供给产品负责人产品待办事项列表中每个事项的工作量估算和技术风险估算。 产品负责人和其他商业利益相关人提供产品需求的价值信息，其中可能会包括获得的收益、减少的成本、商业风险、对不同利益相关人的重要性等等。
为了响应学习和变化，要定期梳理产品待办事项列表。 每个Sprint，可能要加入、删除、修改、分解或者调整事项的优先级别。因此，产品负责人会不断地更新产品待办事项列表，以反映客户需求的变化、新想法或见解、竞争而导致的变化、出现的技术障碍等等。
在产品待办事项列表顶端的事项具有最高优先级，或者是从1开始顺序排列。 一般来说，最高优先级别的事项应当最物超所值：高收益（商业价值）低花销（成本）。 提高某事项优先级的另一诱因是在高风险来袭之前及早解决掉它。
团队为每个Product Backlog事项建立一个工作列表，有时由产品待办事项列表中的事项分解出的任务组成。或者当产品待办事项列表中的事项很小，只要几个小时就能实现时，就简单的由产品待办事项列表事项组成。
通常分成两部分：
关于做什么
关于怎么做
概述 ： 为了将来的Sprint拆分大事项、分析事项、重新估计并重排优先级。
参与者 ： 团队；如果产品负责人是能够帮助梳理细节的专家，那么他会全程参与整个活动，否则他可以只参与其中一部分来设定方向或者重排优先级；其他理解需求并能给予团队帮助的人；Scrum Master将在会议的开始部分来指导团队如何有效地开这个会，否则的话他不必参加。
时长 ： 通常来讲不多于团队一个Sprint工作容量的10％，但有时对于“有大量分析工作”的事项来讲要更长一些。例如，对于两周的Sprint，可能要有一天的时间花在梳理上。
概述 ： 演示产品增量，并且在会议上对于功能性的产品增量进行审视并调整。它让产品负责人了解产品和团队的当前状况（也就是对于这个Sprint的评审），也让团队了解产品负责人和市场的当前状况。
参与者 ： 团队、产品负责人、ScrumMaster。产品负责人可以邀请其他恰当的利益相关人参加。
时长 ： 时间箱为Sprint中的每一周对应一个小时。
概述 ： 针对流程和环境进行审视并调整。
参与者 ： 团队、ScrumMaster、产品负责人（非必须）。团队可能会邀请其他利益相关人，否则这些人不准参加。
时长 ： 时间箱为对应Sprint中的每一周为45分钟。
Sprint评审之后，产品负责人可以根据任何新的见解来更新产品待办事项列表，如添加新事项、删除过时事项或修改现有事项。产品负责人负责保证这些变化反映在产品待办事项列表中。
//todo
是所有代码被check-in就算故事做完了，或者是放到测试环境并且被整合测试团队验证过，才算是做完？
这一点是非常重要的，产品负责人和团队必須同意，要對“做完”有一致的定义。
概述 ： 在团队成员间更新信息和进行协调。
参与者 ： 团队必须参加；产品负责人不是必须的；ScrumMaster通常会在场，但要保证团队自己主持会议。
时长 ： 最长15分钟。
这是一个自组织团队互相分享目前工作情况的时刻，每个团队成员一个接一个地向团队的其他成员报告三件事：
Scrum中的团队是自管理的，想要做到这一点，团队必须要知道自己做得怎么样。每天，团队成员都会在Sprint Backlog上更新他们对还需要多少工作量来完成他们当前工作的估计。一个也很常见的做法是有人把这些剩余工作量加起来，然后在Sprint燃尽图上画点。这个图显示每天新的对团队完成工作所剩余工作量的估计。理想中，这应该是一条向下的斜线图，其轨迹指向Sprint最后一天没有剩余工作量的那一点。所以它被称为燃尽图。
