1. 概述
Scrum是一个用于组织和管理工作的框架。Scrum框架建立在一套价值观、原则和实践之上，在这个框架的基础上，各个组织可以添加相关工程实践特有的实现方式以及在实现Scrum实践时所采取的特定方法。
Scrum是一个令人耳目一新的框架，简单，以人为中心，以诚实、开放、勇气、尊重、专注、信任、授权和合作八大价值观为基础。
Scrum的实践体现在具体角色、活动、工件及相关规则中。
2. Scrum角色
Scrum开发工作包含一个或多个Scrum团队，每个团队由三个Scrum角色组成：产品负责人、Scrum Master和开发团队。
产品负责人负责敲定要开发什么、以什么顺序开发。Scrum Master负责指导团队在通用的Scrum框架上建立并遵循自己的过程。开发团队负责确定如何交付产品负责人要求的产品。
2.1 产品负责人
产品负责人是有授权的产品领导力中心。TA是唯一有权决定要构建哪些特性并以何种顺序构建这些特性的人。对于Scrum团队要实现的目标，产品负责人要保持一个清晰的构想并把它传达给每一位参与者。产品负责人的身份决定着TA要对正在开发或维护的解决方案全面负责。
这里所说的产品可以是外部产品，也可以是内部应用程序。产品负责人还有责任确保总能完成价值最高的工作，这些工作也可能包括偏技术的工作。为了确保开发团队快速构建产品负责人需要的产品，产品负责人要与Scrum Master和开发团队积极合作，及时解答Scrum Master和开发团队提出的问题。
2.2 Scrum Master
Scrum Master帮助每个参与者理解并乐于接受Scrum的价值观、原则和实践。TA充当教练，在过程方面发挥教导作用，帮助Scrum团队以及组织中的其他人制定合适的高绩效、有组织特色的Scrum方式。同时，在采用Scrum时，可能有一个充满挑战的变革管理过程，Scrum Master要帮助组织顺利适应这个过程。
作为辅助者，Scrum Master要帮助团队解决问题和改进Scrum的使用状况。TA还有负责保护团队不受外界干扰，发挥领导作用，清除阻碍团队生产率的障碍。Scrum Master没有权力控制团队，这个角色不同于项目经理或开发经理等传统角色。Scrum Master担任的是领导者，不是管理者。
2.3 开发团队
传统软件开发方法论述的是各种类型的职位，例如架构师、程序员、测试人员、数据库管理员和界面设计师等。Scrum定义的是开发团队角色，这是一个由几种职位的人组成的多样化跨职能团队，负责产品的设计、构建和测试。
开发团队进行自我组织，确定采用哪种最佳方式来实现产品负责人设定的目标。开发团队一般是5到9人，团队成员作为一个整体，必须具备多种技能以构建高质量、可工作的软件。
3. Scrum活动与工件
Scrum框架如下图所示，从图的左边开始，沿着最大的环形箭头一圈，称为一个冲刺。
产品负责人建立产品愿景(图中的大立方体)，产品愿景通过梳理活动分解为一组特性并收集到产品列表，列表中的条目按照优先级排序。
冲刺由图中央最大的那个环形箭头表示。产品列表中的条目开发团队可能无法在一个短冲刺中开发完。因此，在每个冲刺开始的时候，开发团队必须把自己认为能够完成的PBI子集(Product Backlog Item)确定下来, 这个活动称为冲刺规划。
为了有信心确保开发团队的承诺是合理、恰当的，团队成员在冲刺规划会期间会建立第二个列表，称为冲刺列表。冲刺列表通过一组详细任务，描述团队在这个特定的冲刺中计划如何设计、构建、集成并测试从产品列表中挑选出来的特性子集。
接下来是冲刺执行，开发团队执行一些必要的任务，以便实现选定的特性。在冲刺过程中的每一天，团队成员都要进行同步、检查与调整计划，通过每日例会这种活动来帮助管理工作流。在冲刺执行结束时，团队产出一个潜在可发布产品增量，体现产品负责人所构想的一部分产品，但不是全部产品。
Scrum团队在冲刺结束时要执行两个“检视调整”活动。第一个活动称为“冲刺评审”，利益干系人和Scrum团队检视正在构建的产品。第二个活动称为“冲刺回顾”，Scrum团队在这个活动中检视构建产品时所采用的Scrum过程。这些活动带来的结果可能是对产品列表或团队开发部分过程进行适应性调整。
此时再次重复进行Scrum冲刺的循环过程，在重新开始时开发团队要确定能够完成的下一批最重要的PBI(产品列表条目)。在完成适当数量的冲刺之后，就可以实现产品负责人的构想并发布解决方案了。
3.1 产品列表
在使用Scrum时，我们总是先做最有价值的工作。产品负责人结合Scrum团队其他成员与利益干系人的意见，最终负责确定和管理工作顺序，并采取产品列表(按优先级排序的列表)的形式传达给别人。在开发新产品时，PBI在刚开始时是为满足产品负责人的设想而需要开发的特性。对于正在开发的产品，产品列表也可能包含新特性、对现有特性的变更、需要修复的缺陷以及技术改进点等。
产品负责人与内外部利益干系人合作收集并定义PBI。接下来确保PBI是以正确的顺序(使用类似于价值、成本、知识和风险之类的因子)放置的，使高价值条目出现在产品列表的顶部，低价值条目出现在底部。产品列表是一个不断演进的工件。在业务环境发生变化或Scrum团队(通过每个冲刺获得的对软件的反馈)深入了解产品后，可以添加、删除或修改其中的条目。
3.2 冲刺
在Scrum中，工作在不超过一个月的迭代或循环中进行，这个迭代或循环称为冲刺。每个冲刺完成的工作应当创建一些对客户或用户来说具有明确价值的东西。
冲刺是有一定时间范围的，总是有固定的开始和结束日期，而且一般来说冲刺的持续期应当都是相等的。前一个冲刺结束后马上就会开始一个新冲刺。在一个冲刺中通常不允许改变范围内的目标或是更换人员，不过，有时业务需求使我们无法遵守这个规则。
3.3 制定冲刺计划
产品列表体现的可能是多周或多个月的工作，是一个短期的冲刺根本无法完成的。为了确定下一个冲刺要构建的PBI最终的子集，产品负责人、开发团队和Scrum Master需要做冲刺规划。
在做冲刺规划期间，产品负责人和开发团队要对当前冲刺准备实现的冲刺目标达成一致意见。针对这个目标，开发团队要对产品列表进行评审，确定在以可持续的节奏工作时根据实际情况在当前冲刺中能够完成的高优先级条目，可持续节奏指的是开发团队能够轻松、长时间保持的工作节奏。
为了获得完成工作的信心，很多开发团队都会把每个需要完成的特性分解为一组任务。这组任务及其相关的PBI组成了第二个列表，称为冲刺列表。开发团队给出完成每项任务所需工作量的估算值(通常以小时计)。把PBI分解为任务是一种设计形式，是适时(just-in-time)制定特性完成计划。
3.4 冲刺执行
在Scrum团队完成冲刺计划并就下一个冲刺内容达成一致意见后，开发团队就要在Scrum Master的指导下，执行为了完成特性而所需的所有任务级的工作。此处所说的“完成”指的是非常有信心地认为对于产出高质量特性所需的所有工作都已完成了。
没有人告诉开发团队在完成一个冲刺列表的这段时间中以什么顺序、什么方式执行任务级的工作。相反，团队成员要定义自己的任务级工作，然后按照自认为最好的方式进行自组织并实现冲刺目标。
3.5 每日例会
在冲刺期间的每一天，理想的做法是在每天的同一时间，开发团队举行一定时间范围内(不超过15分钟)的每日例会。这个检视调整活动也被称为每日站会，因为大家站着开会可以使会议简明扼要。
举行每日例会的一个常见做法是Scrum Master负责确保会议顺畅，每个团队成员都要轮流回答三个问题，让其他团队成员了解情况。
- 在上次每日例会之后我完成了什么？
- 在下次每日例会之前我计划做什么工作？
- 有什么障碍让我无法取得进展？
通过回答这些问题，每个人都能了解全局，知道发生了什么事情，实现冲刺目标的进展如何，对当天的工作，是否需要修改计划，有什么需要处理的问题。每日例会是必不可少的，能够帮助团队管理一个冲刺内快速、灵活的工作流。
每日例会不是用来解决问题的。相反，很多团队会选择把问题的讨论放到每日例会之后和一小部分感兴趣的人讨论。每日例会也不是传统意义上的状态会议，尤其不是以前那种由项目经理召集、为了解项目最新状态而举行的会议。不过每日例会对于开发团队成员交流冲刺列表条目的状态也是可能有帮助的。每日例会主要是一个检视、同步、适应性制定每日计划的活动，以帮助自组织团队更好地完成工作。
3.6 完成
在Scrum中，我们把冲刺的成果称为潜在可交付产品增量，意思是按照大家一致同意的“完成”的定义来看，Scrum团队承诺做的所有东西都做完了。这个定义明确说明了要有信心确保完成的工作是高质量的、潜在可发布的。例如，在开发软件时，“完成”的最低限度的定义是应当产出一个完整的产品功能，经过设计、构建、集成、测试并且编写了文档。
“完成”最激进的一个定义是当业务部门想要交付(或部署、发布)时，能够确定每个冲刺中要为内外部客户构建什么。
需要明确一点，潜在可交付并不是说构建的东西必须实际交付。交付是一个业务上的决策，经常受其他因素的影响。潜在可交付最好理解为对冲刺中实际构建的产品的一种信心，意味着如果业务部门想要交付的话，我们在交付这个冲刺结果之前，不需要再做其他重要工作，比如重要的测试和集成等。
3.7 冲刺评审
冲刺评审活动是检查和调整正在构建的产品。这个活动很重要的一点是在参与者之间进行交谈，包括Scrum团队、利益干系人、发起人、客户和其他团队中感兴趣的成员。交谈的重点是把刚刚做完的特性放到整体开发工作的背景下进行讨论。每个参与者都能清楚了解现状，都有机会指导下一步开发工作，以确保产出最合适的解决方案。
成功的冲刺评审会议可以促成双方充分交流信息。非Scrum团队的人员能够跟上开发工作并帮助指导开发方向。同时，在与业务部门一起交付满足客户或用户需要的产品时，经常收到反馈可以促使Scrum团队进一步理解产品的业务和市场。因此，冲刺评审是一个预先安排的检查与调整活动。在实践中，非Scrum团队的人员可以在冲刺之间进行特性评审并提供反馈，帮助Scrum团队更好地实现冲刺目标。
3.8 冲刺回顾
冲刺回顾出现在冲刺评审之后、下一个冲刺规划之前。冲刺评审是检视和调整产品的时间，而冲刺回顾是检视并调整过程的时机。在进行冲刺回顾时，开发团队、Scrum Master和产品负责人聚到一起讨论Scrum及其相关技术实践中哪些是可行的、哪些是不可行的。重点关注的是必要的持续过程改进，帮助优秀的Scrum团队成长为卓越的团队。在冲刺回顾活动结束时，Scrum团队应当找出数量适中的过程改进项并承诺在下一个冲刺中采用。
在完成冲刺回顾之后，再次重复整个冲刺过程，开始时是下一个冲刺规划会议，举行这个会议的目的是确定当前团队必须关注的价值最高的工作。
4. 结束语
春节期间事情相对较多，人也比较懒惰，没有坚持周更博客，罪过。另外，这次的博客内容主要来自《Scrum精髓》一书，有这么多大师作品存在，偶尔会觉得写博客似乎没有意义，再努力也难以望其项背。
接下里的三个月会更忙，新项目开发的日常管理沟通、Scrum Master和PMP的学习培训以及不可预知的其他杂事，都会接踵而至，让人应接不暇。突然觉得很有必要进一步提高自己的时间管理观念和水平，才能从容应对，笑迎未来。
重读一下《高效能人士的七个习惯》吧，迷茫时就尝试从书中获取灵感和启示，学海无涯，永无止境，古人诚不我欺。
