转载：
Scrum敏捷开发，是一种敏捷开发框架，是一个增量的、迭代的开发过程，具备可视、可集成和可运行使用的特征。与传统的瀑布式开发模式不同，它更倾向于对一个复杂系统的局部模块做短平快的版本迭代，快速响应预期的市场需求验证。
从图中可以看到，主要流程如下：
- 产品分析用户需求，按照商业价值依次排序估算，输出计划产品功能列表。
- 经过计划会议讨论，按照计划面板梳理功能列表，输出产品版本迭代任务。
- 进入开发迭代周期，按照任务面板增量迭代开发，输出可交付的迭代版本。
- 进入评审验收环节，按照发布面板汇总问题原因，输出迭代周期报表数据。
从上述流程中可以看到有4个输入/输出，3个关键物，3个会议，下面的我们依次了解一下这些内容。
4个输入/输出
1.用户需求，分析转化，产品BACKLOG
这个部分的内容由PM具体负责，主要的工作内容如下：
- 用户调研、需求分析，确定产品迭代功能，出具产品BACKLOG。
- 决定产品的发布日期与发布内容，给迭代计划预设目标。
- 根据RIO（商业价值/工作量）排序优先级，考虑必要风险。
-
2.产品BACKLOG，Sprint计划会议，Sprint BACKLOG
这个部分的内容主要由开发经理负责，主要工作内容如下：
将产品BACKLOG拆分为在本次Sprint中可细化的Sprint BACKLOG。
- Sprint BACKLOG中的开发任务以小时估算，预计1-16小时的工作量化。
- 根据开发优先级管理Sprint BACKLOG，随时更新Sprint BACKLOG状态。
每个团队成员都可以自主挑选任务，修改Sprint BACKLOG。
3.Sprint BACKLOG，迭代开发周期，可交付的迭代版本
这部分内容主要由开发团队共同推进，主要工作内容如下：
依照Sprint BACKLOG，开始开发工作，更新工作任务面板。
- 参加每日例会，明确各团队的整体开发进度与开发难点。
- 保证整体开发进度不大幅度的偏离预设的Sprint燃尽图。
高度的自我组织管理，保持良好的跨职能团队沟通，确保实现Sprint目标。
4.验收发布版本，评审回顾会议，周期数据报表
这部分内容主要由Sprint团队成员共同参与，主要工作内容如下：
产品开发团队通过操作演示的方式展示Sprint中完成的功能与架构。
- PM根据产品BACKLOG，验收开发交付的迭代版本，发布产品迭代版本。
收集Sprint问题反馈，寻找根本原因，讨论解决方法，改善Sprint过程。
3个关键物
1.产品BACKLOG
由产品负责人维护管理的一个已排序，已估算，可渐进的需求清单列表，可参考PRD文档中的功能模块记录列表或者产品需求池的记录列表。在一般的情况下，会根据功能模块对应的用户故事流程来表示BACKLOG条目内容。在每个Sprint结束或者临时需求变更时，都需要更新优先级的排列顺序。
如图：
2.Sprint BACKLOG
由开发负责人维护管理的一个Sprint任务清单，根据产品BACKLOG细化而来，细化为开发过程中可用的产品功能任务，每个任务用小时估算时间，团队成员可自行管理任务，每天的任务进度会更新到对应的任务面板上。
如图：
3.燃尽图
燃尽图是指在1个Sprint周期内，工时/工作量的二维图表，主要是为了让团队成员明白在Sprint截止时间点前剩余开发工作量的整体情况，通过实际燃尽图与理想燃尽图的线性对比，可快速调整开发节奏，降低Sprint版本交付存在的风险。
如图：
3个会议
1.Sprint计划会议（明确目标，细化任务）
在Sprint计划会议上，需要明确Sprint目标与Sprint BACKLOG，讨论时要考虑团队的接受力，开发的速度、技术水平和商业条件等，提前确定好Sprint交付日期，增量迭代开发任务，产品版本迭代内容等。
2.Sprint每日例会（定点，定时，人齐，会短，高效）
每日进行的Scrum会议是团队交流的形式，固定地点，固定时间点，团队成员都参与，会议维持在15分钟左右，发言内容围绕昨日进度、今日安排、所遇困难三个方面快速的梳理一遍任务面板上的工作内容，所遇困难在会后点对点进行讨论解决。每例会是在Sprint周期内（2-4周）的开发进度反馈，在这个周期内，会经常更新任务面板。
任务面板是“任务状态/工作进程”的二维工作面板，便签颜色可代表团队成员，便签内容代表团队成员所负责的开发任务。任务状态一般可划分为：ToDo，Doing，Tested，Reviewed，Finished五个状态，在一块方形划分区域中贴满了颜色便签，随时更新任务面板状态，保证团队所有成员随时随地都可以了解Sprint周期内的整体开发进度
如图：
3.Sprint评审回顾会议
Sprint评审回顾会议主要有两个部分的内容，一是做Sprint交付版本与计划版本的验收，二是总结和完善后续Sprint的开发建设。
我眼中的敏捷开发
在笔者的眼中，敏捷开发作为一种团队协作方法论，高效与清晰是两个特别明显的特点，保持敏捷开发的理念开始Sprint工作的团队，一定有正向的开发BUFF加成，我们需要面对的是如何将敏捷开发的流程执行到位，最大化的获取加成收益。我很认同敏捷开发对于精英团队的加成是最大化的，因为大家目标清晰，技术能力完善，执行力强，这是最理想的工作模型。但对于现实中的非理想工作模型，我们可以从以下几个方面去加强这种团队加成效果：
产品BACKLOG的来源一定要尽可能的准确，最好是有明确的数据分析结果作为支持依据，Sprint BACKALOG的任务细化尽可能细致，保证在后续的Sprint迭代过程中，团队的工作目标清晰明确。因为没有人会希望自己的工作量最后转化为无用功，而不是KPI，这对于团队士气是一种相当沉重的打击。如果还是出现了这种情况，Sprint负责人也要积极转移大家的情绪，劝慰大家尽快投入下一个更加正确的Sprint周期中去。
- 团队成员之间要形成积极沟通的氛围，保证各职能团队之间的信息沟通准确对称。为了保证开发过程中灵活性，敏捷开发往往为了高效而不会过多的对成员做工作流程上的束缚，需求在迭代过程随时可发生变动，开发任务清单可由团队成员自主选择，任务面板由成员自主更新，是一种以沟通为主的工作模式。
- 对于中国特色社会主义建设的国内而言，非理想工作模型下，团队成员往往更愿意被动的选择工作分配。开发经理应该合理的根据团队成员的能力维度安排工作任务清单，尽可能避免团队成员因为能力失控导致进度延期、工作效率低、工作情绪泛滥等不利于团队建设的情况出现。
- 团队成员的组成结构在Sprint周期内尽量保证不变动，尤其是核心主导成员更不能做人事变动。在一个Sprint周期内，团队整体的开发关注力是需要高度集中的，如果这时团队的头部成员发生更换，一定会存在沟通成本损耗，影响整体迭代效率。
- Sprint开发过程，会议的频次与时长需要做适当的把控。笔者参加过蛮多工作会议，个人觉得有些会议的RIO并不成正比，耗时且没有正向的工作计划输出，这往往是蛮多人都吐槽且不喜欢参加会议的原因。每次最好由负责人主导会议，做好会议相关数据报表的输入输出，阶段性的展示成果，给予团队积极的正向会议反馈。
其他资源：
若有收获，就点个赞吧
0 人点赞
