Scrum 是一套敏捷开发流程，用于快速响应客户需求，降低过程风险，确保项目质量，积累宝贵经验。
所谓敏捷，就是任务多，团队小，还要快速的完成任务的代名词，如果没有一套流程规范，是很容易乱套的，人人都很累，人人都在抱怨，产品质量一塌糊涂，企业发展受阻，团队士气低落，Scrum 就是用来保障敏捷的同时又兼顾人性化的一套规范流程。
背景
先来看一幅漫画
一天，一只鸡散步时遇见了猪。
- 鸡对猪说：“嗨，我们合伙开个餐厅吧？”
- 猪说：“好啊，那准备叫什么店名呢？”
- 鸡说：“要不，就叫火腿和鸡蛋吧？”
- 猪直接拒绝了：“那可不行。我要割肉，你只要下蛋。这样下去，我迟早要完蛋。”
这个故事实际上反映了软件开发过程中的2种不同角色，即需要完全投入的“猪”和只要部分投入的“鸡”。
真实项目过程中，往往会发生这样的现象，产品经理或领导，喜欢临时往项目中新增任务，打乱原先的开发节奏，导致程序员压力倍增，士气低落，项目延期。
而Scrum，就是为了保护“猪”这种角色，兼顾“鸡”的感受，从而确保整个项目正常交付。
Scrum 流程
Scrum，橄榄球术语——并列争球的全体前锋。
Scrum是一个包括了一系列的实践和预定义角色的过程骨架。
上图概述了 Scrum 敏捷开发的全流程，其中涉及到一些人员角色及过程产物：
产品负责人 Product Owner：即产品经理，大部分时间担任了“鸡”的角色，迫于领导的压力，喜欢往团队中不断增加任务或修改需求。
Scrum 主管 Scrum Master：类似于项目负责人，他需要做的是保护团队，兼顾产品经理的需求，确保项目的按时交付。
开发团队 Team：开发测试设计人员，Scrum Master 本身可能也是其中一员。
产品需求列表 Product Backlog：Product Owner 事先将所有的用户需求按优先级排好，放到一个列表内，这个列表就是Product Backlog.
冲刺（迭代）讨论会 Sprint Planning Meeting：迭代计划评审会，用于按优先级从 Product Backlog 中选出本次迭代要做得事情，进行拆分，分配，预估。
冲刺（迭代）任务列表 Sprint Backlog：迭代任务列表，小组通过 Sprint Planning Meeting 将用户需求按优先级移入到迭代计划内，并对需求进行评审，任务拆分并估点，得到迭代任务列表。
冲刺周期 Sprint Weeks：迭代计划会后，小组成员按个人喜好领取自己的任务，开始为期 1-4 周的迭代周期，最佳实践为 2 周。
每日立会 Daily Standup Meeting：迭代周期内，Scrum Master 组织每天的立会，每天的站立会议上讲一下自己昨天做了什么，今天准备做什么，大概什么时候完成，以及遇到了什么问题。当有人提出遇到难题时，Scrum Master 需要记录并在会后安排人帮忙解决，而不是在会议上直接解决。每个人大概1-3分钟，整个会议一般不超过30分钟。每一个工作日结束后，需要画燃尽图。
评审会 Review Meeting：一个迭代开发阶段结束后，进入内部演示会议，工作成果给整个小组演示（包括Project Owner）。
反思会/回顾会 Retrospective Meeting：内部演示结束后，整个小组（包括Project Owner）召开一个迭代复盘会，回顾本迭代中大家哪些做的好，哪些做的不好，每人各列举1-3个好的以及不好的，列的时候只讲现象，不分析原因，不找解决方案。然后整个小组投票选出3个不好的，分析原因，寻找解决方案，并指定执行者。
任务估点
任务估点，常见的有俩种方式：时间点和故事点。
时间点：每个任务大概花费的小时数，比如开发一个 getUser 接口预估 0.5h. 但是，哪怕是经验丰富的开发人员，也无法按小时数/天数进行精确预估，所以推荐采用故事点的方式。
故事点：可以理解为一个故事（任务）的复杂性及大小，比如故事点的范围为 1-5（可以适当调整，但不建议太大，不要超过12），不同的人给不同的任务预估故事点，如果一个任务耗费的故事点超过最大值，那需要考虑将任务进一步拆分。
燃尽图
燃尽图是查看工作进展的最快方式。
如果 Remaining Values 这条线（红色）一直水平伸展，而不是向下降，您就需要查找原因。
在成功的 Sprint 中，Remaining Values 这条线应该与 Guideline 这条线（参考线，正常线）同时，或比它更早触及底部。
如果 Remaining Values 这条线在 Guideline 这条线之前终止，则说明团队中要么存在一些工作绩效超常的成员，要么有一些本应认领更多工作（而实际上却没有认领那么多）的人！
下面的表格记录了一些任务的事件情况。
下面为大家介绍两种 Scrum 软件工具：jira 和 tapd
Jira Scrum
Jira 我就不介绍了，有空可以整理一下官方指南给大家分享出来，这里主要展示一下 Jira Scrum 长啥样。
创建 Jira 项目的时候，你可以选择 Scrum 类型的项目，创建好之后大概长这样：
Backlog 中用来记录待排期的任务，也就是上面所说的 Product Backlog, 迭代计划会议中从这里选出一部分作为一个迭代版本，创建 Sprint 并开启，开启后的 Sprint 可以在 活动的Sprint 中查看：
每天的站立会上，可以通过报告中的各种图表进行统计展示迭代的一些状态进展：
TAPD Scrum
TAPD 是腾讯开放出来的用于敏捷团队流程管理的一套很强大易用的工具，当然不是为了替腾讯宣传哈，仅仅是因为个人用过，并且还是免费的（可能以后会开放收费的功能吧）。
介绍：
https://www.tapd.cn/official/solution/tapdlite
下图是 TAPD 的敏捷流程：同 Scrum 标准流程规范。
TAPD 有如下概念：
使用TAPD管理整个研发生命周期，使用需求承载需求的设计规划，利用迭代进行迭代的规划跟踪，通过缺陷保证Bug流程可追溯。迭代发布后，及时收集用户反馈进入下一个迭代的研发，实现快速迭代，小步快跑。
需求规划
需求的来源不尽相同——用户反馈、已实现功能的优化、新功能模块的增加等，产品经理需将这些不同来源的信息抽丝剥茧，设计成为需求。
使用需求模块录入需求单，需求单中包含了需求实现的详细描述，往往需求原型图或是其他参考资料也会被作为附件添加到需求单中。
迭代规划
创建一个新的迭代，并设定迭代的目标、开始和结束时间，然后再往迭代里添加本迭代须实现的需求。
迭代需求规划完成后，项目经理组织开发工程师、测试工程师等参与迭代过程的团队成员进行本迭代的需求说明会议。
会议开始后，产品经理向团队成员讲解需求的设计思路，再由团队成员充分讨论需求方案可行性，预估风险。
讨论结束后，团队成员对需求进行工作量评估，由于每个需求都经过了充分的讨论，大家在工作量的评估时很容易就达成了共识。
最后，开发工程师根据自己的兴趣主动认领迭代工作任务，完成迭代工作分配。
迭代跟踪
迭代开发过程中的使用故事墙、迭代燃尽图、甘特图进行迭代进度跟踪，可以在每日立会中进行同步。
故事墙以卡片的形式，详细地展示了项目的进度。卡片里包含了任务内容、任务优先级、任务负责人、当前状态等信息。
燃尽图相比故事墙，为迭代进度提供了量化的数据展示。燃尽图的走向代表了迭代进度的健康度，当出现异常时，需要对团队开发节奏进行调整。
缺陷管理
研发过程中，测试工程师使用缺陷进行缺陷管理。开发工程师完成需求开发后，测试工程师跟进测试。
测试工程师首先根据需求罗列出测试重点，然后根据测试重点进行测试。测试过程中发现了Bug，便会填写缺陷单，并分配给需求开发人。
缺陷单包含了Bug的重现规则、关联需求、优先级和紧急程度等信息。
开发工程师修复Bug后，将缺陷单状态设置为已解决，此时缺陷单流转回测试工程师手中。测试工程师验证Bug已正确修复后，将缺陷单关闭，否则打回给开发工程师。整个过程可重复进行，直至Bug被正确修复。
统计分析
统计模块除了提供缺陷统计、需求分布统计、进度跟踪、工时花费统计、需求关联统计等丰富的内置报表外，同时也支持通过报表自定义，灵活定制团队专属统计报表。
项目经理可以将统计报表作为邮件内容，创建定时报告发送给团队成员，方便所有团队成员关注开发质量。
知识沉淀
团队在研发过程中产生的经验积累可以通过文档承载，无论是团队发展过程的记录，还是产品里程碑规划，或者是开发测试工程师的技术分享，都可以在文档中呈现。
每个团队成员都可以通过文档收集并整理知识条目，对知识库进行补充和反馈，实现团队经验的积累与传承。
TAPD轻量敏捷项目管理解决方案的设计紧密地融合了敏捷研发思想，覆盖了整个研发生命周期，能有效提升团队研发效率，快速迭代，持续产出，保证产品的持续可用。对中小型研发团队而言，它不仅是一套项目管理工具，更是敏捷研发的最佳实践。
总结
本文概述了 Scrum 敏捷开发流程规范，并给出了 Jira 和 TAPD 两个实践参考，其中 TAPD 重点进行了详细的介绍敏捷开发涉及到的核心知识点，大家可以结合自己团队实际情况进行取舍。
敏捷开发适用于需求多且多变，又需要快速交付的场景，并不一定所有场合都适用，大家重点理解一下其各流程设计的初衷意图即可，在合适的场景可以尝试，任何规范流程仅仅是参考意见而已，真正落地，生效还是要靠人，要从上到下认同此理念，这样才能持续高效的推进下去。
祝大家学有所思，思有所行，行有所果，喜欢记得点赞分享。
如果想链接我，公&号：新质程序猿，可以找到我。
