提供敏捷框架的过程——Scrum

Scrum是个什么意思？它其实代表了几大核心价值观：

S-openess-开放，团队每个成员都乐于交流、乐于分享、能访问到相同的信息；

C-courage-勇气，有勇气、用尊重的态度迎接质疑，并且有勇气进行突破；

R-respect-尊重，彼此尊重、共同遵守工作规范、有融洽协作的氛围；

U-focus-专注，确认有价值的事项、集中去做；

M-commitment-做出承诺，团队要务实，保证每次迭代有实实在在的价值产出。

敏捷本身就是一种思想，并不是指某个特定的方法，而Scrum，在核心价值观基础之上，提供了可供参考的敏捷过程框架。

这个框架有个“3324”的模式：

• 3-个角色：产品负责人、团队负责人、开发团队
• 3-种图表：产品功能列表、冲刺列表、燃尽图
• 2-个计划：Sprint Plan（冲刺计划）和Release Plan（发布计划）
• 4-种会议：迭代计划会议、每日站会、迭代评审会议、迭代回顾会议

3个角色

• 产品负责人（PO-Product Owner）懂业务擅沟通，敢于决策承担产品责任；
• 团队负责人（SM-Scrum Master）激励团队促进合作，引导敏捷实践，沟通决策解决冲突、帮助团队清除外界障碍；
• 敏捷团队（Scrum Team）自组织、沟通很透明、跨职能、成员稳定、有T型人才、集体承诺承担责任；自组织团队自己决定团队内如何开展工作，自主设计、计划和执行任务；组建自组织团队之初，需要制定“团队工作协议”（并持续优化）

3种图表

① 产品功能列表（Product Backlog）

敏捷团队的产品功能列表是条目化、量化、分配优先级的需求列表，需求通过用户故事的方式来描述（注：优先级越高的需求，用户故事的粒度越细，不一定要Backlog非常完整才开始工作）。

优先级排序方法（各种排序方法可以按具体情况综合使用）：

• MoSCoW：必须有，应该有，可以有，这次不会有；
• 100点投票：每个人有100点，可以把他们投给各个功能需求，统计各功能需求点数之和，点数多的优先级高；
• KANO分析（由Kano教授发明）-客户满意度

根据KANO分析，有如下几类需求：

1-【Must-have】必须有的基本需求（这是用户的痛点，解决了，客户满意度不会明显提升，但是不解决，满意度就会非常差）

2-【Linear】线性期望型需求（如果满足了，客户满意度相应有线性升高）

3-【Exciter】让客户兴奋的需求（客户满意度暴涨）

4-【Reverse】客户不喜欢的反向功能（如果做成这样，客户满意度反而会下降）

5-【Indifferent】客户不怎么关心的功能（做不做都不太影响满意度）

6-【Questionable】团队现在不确定该需求功能会产生什么效果

团队怎么分析需求属于哪一类呢？可以按这样的维度来分析：

如果有这个功能/如果没有这个功能-->

我希望这样；

我预期这样；

中立；

我可以忍受这样；

我不希望这样；

下面，就可以理性征求团队成员意见，看看某个需求属于哪一类满意度需求，示例：

② 冲刺列表（Sprint Backlog）

③ 燃尽图（Burn-Down Chart）

2个计划

估算故事点数

• 团队所有人参与估算
• 团队把比较小的故事设定为1，作为参考基准（故事点是个相对值）；
• 决定难以估算的故事，可以尝试分解成小故事（由产品负责人协助）；
• 完成DoD(Definition of Done)；

4种会议

迭代计划会议（Sprint Planning Meeting）

时长：1小时左右；每个迭代冲刺开一次；

成员：产品负责人、团队负责人、开发团队；

会前准备：

• 经过估算的产品功能列表；
• 假期表&重要人员联系信息；

会议输出：

• 团队认领一个冲刺周期的产品功能清单；
• 分解本冲刺周期产品功能清单，产生初步的 冲刺任务清单 ，以及相应的用户验收测试清单（UAT）；

每日站会（Daily Scrum Meeting）

时长：15分钟左右；每天；

成员：团队负责人、开发团队（如有成员无法出席、找同事代表）；

会前准备：

成员清楚3个问题：

• 我昨天做/完成了什么
• 我今天打算做/完成什么
• 存在的困难或阻碍

会议输出：

• 团队成员彼此明确知道各自的工作；
• 为有障碍的任务项产生输入；
• 更新任务项；

迭代评审会议（Sprint Review Meeting）

时长：1小时左右/周；

成员：产品负责人、团队负责人、开发团队、用户/客户、部门经理；

会前准备：

团队准备增加的可以演示的功能；

会议输出：

• 用户/客户试用后的反馈；
• 来自开发团队的反馈-->可以为产品功能列表增加输入；
• 其他输入，比如障碍任务项

迭代回顾会议（Sprint Retrospective Meeting）

时长：1小时左右/周，在迭代评审会议结束后开始；目的：发现哪些方面需要改进；

成员：团队负责人、开发团队、产品负责人

输出：做的好的-继续、做的不好的-停止、需要改善的-开始改善；

一些技巧：

• 从优点开始、开放式提问；
• 感谢环节，感谢他人对自己的帮助、感谢某某对团队的贡献；
• 回顾维度：
  • 团队合作、前后端分工、任务分配是否均衡；
  • 有没有需求不明确导致rework；
  • 任务进展曲线是否顺利，有没有被严重block的因素。