敏捷基本概念——三大角色五大会议
Scrum是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。迭代是贯穿敏捷管理的一个特有概念，Sprint是冲刺跑的意思，在敏捷里指的是一次迭代，而一次迭代的周期一般是2~4周，也就是要把一次迭代的开发内容以最快的速度完成它，这个过程我们称为迭代。Scrum团队试图在每一个迭代中都构建出一个潜在可交付、并且充分测试过的产品增量。
图1. 敏捷流程人员构成
Scrum团队，又叫Scrum Team，是Scrum的基本单位，一般都是小团队，这个团队虽小，但是麻雀虽小，五脏俱全，这是一个跨职能的团队，这个团队具有完成每个迭代所创造的价值的全部技能。 他们是自管理的，这意味着他们在团队内部决定谁做什么、何时做以及如何做。
一般Scrum团队都是10个人左右，这已经是最小单元，没有子团队或结构层次了，规模足够小可以保持灵活，同时也足以完成一个迭代中重要的工作。小的团队沟通更好，效率更高，如果有问题，站起来直接喊、然后开始讨论把事情解决了。
Scrum团队是具有凝聚力的专业团体，作为一个整体，每个成员都非常重要，大家互相配合一次专注于一个目标，即产品目标。在团队中，三种角色有不同的分工，由一名流程管理员（Scrum Master），产品负责人（Product Owner），开发团队（Dev Team）组成来完成每一次迭代，产出每一次增量，完成每一次目标。
图2. 敏捷团队角色
- 产品负责人：定义所有产品功能，决定产品发布的内容以及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理地调整产品功能和迭代顺序，认同或者拒绝迭代的交付。
- ScrumMaster ：指导项目组的成员按照Scrum的原则、方法做事情，领导团队完成Scrum的实践以及体现其价值，排除团队遇到的困难，确保团队胜任其工作，并保持高效的生产率，使得团队紧密合作，使得团队个人具有多方面职能的工作能力，保护团队不受到外来无端影响。
- 开发团队：一般有 5-9 人，团队成员包含程序员、测试员、用户体验设计等等，由一批跨职能的人组成，他们拥有完成每个产品增量所需的全部技能。开发团队成员需要以自组织的方式实现Sprint目标，根据Sprint的计划完成产品增量。产品负责人准备一个有序的代办事项列表。开发团队成员共同预测在一个Sprint里能完成的工作量，并决定如何实现。
在Scrum团队中，有三种角色，Scrum Master作为主导者，驱动着团队前进，而Product Owner作为业务方代表，提供需求，最终让开发团队把需求实现，作为一个Scrum团队，大家一起配合完成任务，交付成果。
不同于瀑布模型将开发过程划分为需求、设计、编码、测试等阶段，Scrum将整个开发过程分为多次迭代（称为Sprint，冲刺），一般为期2～4周，最常见的为2周。Scrum并非以一段时间集中完成一个过程，而是将所有过程中必须的每一部分集中在这段时间内完成。需求、设计、编码、测试、上线都必须在一个迭代中完成，每个迭代必须产生一个可以工作的软件。
Scrum的整个过程主要分成五大会议，如下图所示。这些会议均由在这些会议上不具备决策权的ScrumMaster来负责引导。
图1. Scrum流程相关会议
- 待办事项整理会议（Backlog Refinement Meeting）
大多数产品在规划时都是切分为大且模糊的主题，也称史诗级故事（epic）。经验中发现，可以在每个迭代的执行过程中都拿出点时间召开待办事项整理会议，用于为下一个迭代计划会议做准备。在待办事项修整会议上，围绕着产品列表上的主题，产品负责人、Scrum Master和少部分关键开发者，先把功能清单理一理、拆一拆，需要把主题功能拆分为可代表产品特性的多个用户故事。
由产品负责人将一批希望团队在下次迭代时实现的用户故事，按照实现顺序描述给团队成员，开发团队分析用户故事需要包含哪些技术任务，由Scrum Master建立子任务，方便迭代计划会议的时候团队可以更准确的预估任务故事点。
在会议结束时，产品负责人需要确认会议中提出的需要完善的问题在迭代计划会议开始之前都能被解决，而不浪费迭代计划会议的时间去做这件事情。
图2. 需要大块的史诗故事进行拆分
- 迭代计划会议（Sprint Planning Meeting）
产品负责人建立产品功能清单（Product Backlog），是一组条目化的需求，它必须从客户价值角度描述，并按优先级排序。每个迭代在刚开始的时候，Scrum Master召集相关人员和开发团队一起召开迭代计划会议，讨论在这个迭代中想要把产品的哪些功能清单列为待办事项，并估算本次迭代的工作量。
产品负责人需要讲清楚对于业务来说哪些需求是最重要的，开发团队则负责选定在不积累技术债务的情况下可完成的工作，估算Backlog所需工作量，将工作从“产品清单”中拉入Sprint列表，直到本迭代工作量达到饱和。
产品负责人参与讨论并回答和需求相关的问题，但不干扰估算结果。由组长协商分发，或队员自行认领任务，独立或与其他成员一起完成任务。
会议时长尽量控制在1-2个小时之内。
图3. Sprint计划会议的交付物是产品功能清单和迭代任务清单
- 每日站会（Daily Scrum）
每天在相同时间相同地点让团队成员们花费15分钟相互沟通进度，每位成员都要总结他昨天做了什么、今天将要做什么、以及是否遇到了阻碍。站着开日会，有利于保持会议简短，如果有额外讨论的话题可以等所有人报告完之后感兴趣的人再继续讨论。Scrum开发团队利用燃尽图来展示整体进度，每天进行简短会面来检验工作进程，并调整后续步骤以确保能如期完成剩余工作。
- 迭代评审会议（Sprint Review）
在Sprint的结尾，产品负责人、Scrum Master、开发团队，可能还有客户一起评审这个迭代的结果。小组向产品负责人展示迭代工作结果，产品负责人给出评价和反馈，以用户故事是否能成功交付来评价任务完成情况。未完成的任务会被打回PBI，然后再根据产品负责人的最新优先级顺序判断是否放入后续迭代。任何参与者都可以问问题和提意见，时间控制在1-2个小时之内。
- 迭代回顾会议（Sprint Retrospective）
敏捷开发的一个原则是“可持续的步伐”，迭代之间没有间歇期，团队通常在迭代结束的某个下午召开回顾会议，第二天早上就直接进入下一个迭代计划会议。这是一个简短的反思会，总结哪些事情做得好，哪些事情做的不好。做得好的保留，不好的摒弃。团队中的每个人将在会上反思自己的工作，并决定开始做什么、继续做什么、停止做什么，采取措施以在下一个迭代中做得更好。时间一般控制在15-30分钟。
Scrum是一套开发流程，强调的是自组织、自驱动的，团队只有在实施中不断地仔细体会，采取应对措施来适应自身团队的流程。