一起长大敏捷实践 - 流程篇

全面转型敏捷之前，我们的 Scrum 流程在 Scrum 框架基础上改造了非常多，现在看起来很多都是没必要的，Scrum 框架已经非常简单和成熟，可操作性也非常强，只需要根据团队实际情况做微调即可。

Product Backlog Refinement

我们在每个 Sprint 中增加了 PBR，通过一个小时左右的会议，让团队对未评估过故事点的故事和后续的一些史实故事，使用 Planning Poker 工具进行故事点的评估，以便 PO 得到故事点后，结合故事的价值，对故事进行优先级综合排序，来重新调整 Backlog。这个环节的好处在于，所有故事都在 Planning 前有故事点，且故事点是团队一起评估出来的，PO 根据过往团队速率，可以对未来 Sprint 大致可以放入多少故事有一个准备，避免 Planning 准备不足或者故事过多。同时也可以让 PO 对未来要做的史诗故事大小有大致的了解。

Sprint Planning

我们的 Sprint Planning 没有太多特别，PO 详细讲解本次 Sprint 相关故事，团队一起提问和讨论，最后定下 Sprint 目标，大家会后一起将任务拆分到 JIRA，如下图： 

在 JIRA 中我们以故事+子任务的方式来管理，子任务包括各端的任务和测试任务，所有子任务都完成后，整个故事算完成。 新的 Sprint Planning 结束后，我们会在公司的一块大白板上，公示 Product Backlog 近期完成（上个 Sprint 已交付）、正在进行（当前 Sprint 计划交付）、即将进行（后续 Sprint 计划）的故事，让整个公司都知道开发团队的进展和规划，也是 Scrum 里面提倡「透明」的一个体现。

Daily Scrum

我们选择在每天下班前进行 Daily Scrum，这样有几个好处：

• 工作了一天大家都比较累了，Daily Scrum 让大家放松和站起来活动一下；
• 大家在同步信息和进度时，如果某人发现因为自己的原因，导致燃尽图偏离，会主动选择下班后加班去弥补和赶上进度，不至于让整个团队目标受到影响；
• 早上一到公司就可以开始工作，不用等待开会，早上的效率会更高。

另外，我们配备了一个超大的显示器，在 Daily Scrum 时所有人都可以注视着显示器，发言的同时去移动 JIRA 卡片，这让大家焦点一致。

Sprint Review

RC 环境走完以后，我们开启 Review 会议，当然，这个会议时间在 Planning 结束后就已经定下来并创建了日程。这个环节很重要，事实上，Review 应该是给客户展示我们即将交付的新特性，在我们公司，业务部门（销售、客户成功、运营、客服等）就代表着客户（和客户走得最近），所以，每次的 Review 会议，团队都会邀请业务部门来参与。会上团队指定一个演示人，按照故事列表，对本次 Sprint 完成的所有故事进行演示，这个环节也有很多好处：

• 让业务部门了解哪些功能是我们即将交付上线的，可以给用户/客户去传达；
• 业务部门会站在用户/客户的角度，给团队提出很多好的建议，PO 搜集以后可以作为下一次优化的参考；
• 增进开发团队和业务团队的交流机会，让业务团队不断地看到他们期望的新特性上线，通过业务团队的反馈和认可，也给开发团队更多的信心和成就感。

每次 Sprint Review 结束时，业务部门参与者都会给团队的产出以掌声，这个仪式感对团队来说是超棒的。

下面是一个典型的 Sprint Review 场景

Sprint Retro

回顾会议一般在正式上线生产后进行，回顾会议是我认为最重要的会议，自组织团队的自我认知、更新、迭代、流程优化等，全在这里。 我们的回顾会议有几个特点：

• 封闭的会议室，让大家畅所欲言，更有安全感；
• 提前准备好水果，让回顾会议的氛围变得轻松；

我们的回顾会议大概是这样的流程：

1. 所有人写出本次 Sprint 做得好和不好的，大家用工具投出优先级；
2. 投票最多的 3 个不好的，大家在会上一起思考和讨论改进意见；
3. 针对每个做得不好的点，分配一个成员，在下个 Sprint 中重点跟进；
4. 回顾之前 Sprint 的不好项的跟进进展，是否有改善；
5. 评选 Sprint 之星和看是否能获得团队之星（这两个在后续激励篇会专门介绍）

每个 Sprint 结束后，团队一般会组织一次聚餐，然后进入下一个 Sprint 迭代。

下面是一个典型的 Sprint Retro 场景

参考资料

Scrum要素 https://book.douban.com/subject/20507350/