步步莲花--SCRUM团队敏捷需求实战案例

凌宇哥在之前的多篇文章中多次提及到用户故事方法在精益敏捷实施推广中的重要性，包括单纯在研发过程实施敏捷的不足（请见之前文章《两条腿走出“伪敏捷”的怪圈--Scrum团队敏捷转型成功案例》）。大家可能会有若干疑问，今天，就和大家讨论一下。

首先，大家可能会有疑问。我的团队想要推敏捷，我不实践用户故事就一定会失败吗？答案是不一定。凌宇哥在好多年前第一次给团队推行SCRUM的时候也没有实践用户故事，推行了一段时间，团队改进效果也不错。甚至，我今年在TiD大会上听有的老师分享敏捷转型经验，他们也没有实践用户故事。但是，你会发现这些团队即使没有用用户故事，但是他们的需求工作也基本实现了条目化、可测试化。你若细细分析，这不就是用户故事的INVEST特征吗？他们没有用户故事之形，但是实质上已经运用了用户故事的一些本质。那与其这样，为什么一开始就不推行用户故事呢？

我觉得原因有几点：对于经验丰富的教练，采用持续渐进的方式对团队进行各项实践导入，那么可能会先从研发过程着手，所以一开始没有引入用户故事。对于经验较浅的敏捷转型推动人，第一种可能是没有一开始就认识到需求与研发同步实现敏捷化的重要性。所以我们会看到绝大多数团队一直在推行SCRUM，结果推行一段时间后发现SCRUM框架貌似运转的不错，可是效果没有达到预期。为什么？很可能是研发过程敏捷了，需求没有敏捷，导致研发无法有效承载需求，就如上图所示。第二种可能是推行用户故事方法有一定难度。SCRUM框架里面的活动绝大多数属于管理实践，但是用户故事是需要改变产品需求的工作方法和思路的，对于产品需求人员的改变很大，对教练的要求会也更高一些。

但是，作为团队敏捷转型的推动人，我们要认识到，产品需求的敏捷化是必须要做的一件事情。今天，凌宇哥就用一个实例给大家介绍一下团队产品需求敏捷化的过程。

事先需要说明一下，下面的实例内容在产品研发中的适用范围具有边界。前置边界，我们认为某产品的产品定义已经被验证是通过组织评审的。我们的实践重点只付诸于需求分析、团队规划部分。后置边界不包括研发阶段。

本实例产品需求敏捷化践行的精益敏捷实践主要包括：用户故事、用户故事地图、需求实例化、发布计划、产品待办列表梳理。本次实例只是针对某一Feature进行举例。

首先使用用户故事地图对该Feature进行可视化。同时，根据团队迭代速度，根据用户故事的优先级初步将故事划分到3个迭代里。

其次，对史诗故事进行拆分，向下拆分出若干用户故事，并对用户故事进行故事点估算。

再次，对用户故事进行细节补充。用户故事只有描述和验收标准是完全不够的，这个时候需要增加诸如原型、文档等对用户故事进行细节描述。

那么，在产品层面，团队取得了哪些成效呢，经过4个多月的实践，基本实现了迭代的增量交付，团队第一次实现了计划内提前一天发版（没在半夜发版。该团队一年计划发两个大版本）。

最后和大家交代一点，该名PO于一年前入职，入职之前，非计算机专业，非软件公司任职，从没和软件研发团队打过交道。通过4个多月产品敏捷需求化的培训指导，获得事业部季度之星称号，下面是对她的评价之一。