初步对Scrum的了解

最近开始做敏捷开发方面的工作，只能说对scrum有了一定点的了解，比如3个角色即PO、SM和开发Team。3个工具即产品待办事项列表(product backlog)、迭代待办事项列表(sprint backlog)、可交付的产品增量(product increment)。5个活动即：发布计划会议、Sprint计划会议、Sprint、每日例会、Sprint评审会议和Sprint回顾会议。

1-团队组建，宣扬方法论

目的：组建好用的团队，灌输结果导向以及敏捷方法。
敏捷方法里对于个人和团队的技能要求有三点。
一是跨职能，即在懂研发的基础之上，可以跨到测试甚至设计甚至更多；
二是主观能动性要高，都是为了解决问题而不是卖骚秀工作量；
三是认同结果导向，即我们用此方法，可以更快更高质量的输出可用产品。

2-创建产品待办事项列表

目的：输出有排序的，有故事点估算的用户故事列表。
此环节里PO进行产品梳理，排序现有用户故事，同时帮开发Team理解需求。
开发Team根据理解的用户故事来进行故事点估算，产出可输入至迭代计划里的用户故事。SM来绘制燃尽图，表示产品进度，在每个迭代后进行更新。
备注：用户故事也分颗粒度大小，排序就是优先级越高的故事越具体。

 3-通过迭代计划会议产出【sprint+backlog】

目的：通过会议产出本轮迭代的任务。
迭代周期：根据交付要求进行评估后产出产品迭代周期，一般为2周~4周不等。周期太长不灵活。
PO与团队从产品待办事项列表中选取待完成的用户故事。开发Team负责将这些用户故事拆分成任务，给出任务估算，任务一般可在8小时内完成的，可量化。
SM绘制针对迭代的可视化图，表示迭代进度，在每个立会进行更新。最后将本轮迭代的任务放置在To do（准备做）一栏。

4-通过每日例会【沟通及领取、交付任务】

目的：保证整体团队每天高频的沟通，了解每个任务的进展及大家进度情况。
整体团队每天花15分钟快速的勾兑昨天做了什么、今天准备做什么，需要什么问题。
每个人主动在To do（准备做）一栏中的选取今日要完成的任务放入Doing一栏并且开工，第二天立会继续按此勾兑，同时将已完成的任务放入Done（完成）一栏
备注：只有PO、SM、开发Team能发言，其他人旁观，有事儿单独聊。

5-通过评审、回顾会议【评审本次迭代的成果和输出改进项】

Scrum方法论里是两个会。
评审会议是邀请客户等利益攸关者一起针对本次迭代的成果进行评审（可交付的产品增量）。团队进行演示，PO来讲解整体产品情况。
回顾会是团队内部针对本次迭代内发生的各类做的好的、可以改进的、存在问题的输出改进项， 改进项作为单独的任务为下一轮迭代做输出，也就是持续改进。

6-会后更新产品待办事项列表

整体过程中：
SM需要确保开发Team不受外界干扰，作为敏捷教练更多的是确保会议执行、确保大家理解方法、遵循时间盒规则。
PO把控整体方向及对接外部需求，只有PO可调整产品待办列表优先级，另有权中途取消迭代。
开发Team负责任务的同时还需要遵循敏捷的核心方法，同时按需运用如持续集成、自动化测试、结对编程等组件级方法。

总结：

前期贴合需求，浅显易懂的说明
价值观一致(褒义方向)
自组织跨职能团队(人&技能)
信息发射源(燃尽图)
高频短时沟通(每日例会)
高频迭代及优化机制(持续改进)
周期性评审及回顾(交付增量＋下一轮改进)

始终认为，敏捷只是达成目标所使用的方法，而Scrum等诸多实践只是提供了一种验证过的可行的参考，而是否适用于本团队，以及团队里每个人具备的技能和方法认知，还需要管理者自行斟酌和思考。

永远不是为了敏捷而敏捷，而是为了更高效的交付更高质量的可用产品。