产品经理在敏捷开发环境中，应关注于创建团队能理解的用户故事，而非详尽的文档。合格的用户故事需确保团队能给出故事点数，并能在一次“冲刺”中完成。需求梳理会上，通过故事点数评估工作量，无法给出点数的需求需重新考虑。用户故事应简洁明了，避免超过13点的故事点，以确保每个“冲刺”的可交付内容。通过这样的方式，敏捷实践提高了需求处理效率并促进了团队沟通。
要是问开发团队需求文档应该写成什么样，一千个团队可能有一千个答案。而产品经理在各种各样的模板的需求文档中疲于奔命，还不一定能让团队满意。那么对于实践敏捷开发模式的团队，产品经理该怎么写开发文档让团队满意呢？
答案很简单，只要符合下面两条就可以了：
- 在需求梳理会上，对于该需求，团队能给出故事点数
- 并且这个故事点数的大小表示在一个“冲刺”中能够做完该需求
需求不在详细，而在于团队能明白
敏捷实践使用用户故事描述需求。虽然敏捷实践中对用户故事的格式提出了下面的要求，但是没有明确用户故事到底该写得多详细。合格的用户故事只有一个标准，团队能够明白这个用户故事的意思，知道该怎么做。敏捷更看重的的是沟通和交流，而不是文档。
- 用户故事的描述语言
As a user, I want to do something, so that I can achieve some goal. - 检验标准
Given some precondition
When I do some action
Then I expect some result
最终说明团队能不能明白用户故事的含义，有前文所述的两条决定。
给不出故事点数就不能纳入开发计划
在用户故事梳理会上，最佳实践之一是采用故事点数来评估需求的工作量大小。有关如何评估故事点数可以查看我的这篇文章：
在团队阅读了需求说明，产品经理也解释了需求中问题后，如果团队还是给不出点数，这说明团队没有明白需求或者不知道该如何实现需求。这样的需求只能被暂时搁置，产品经理需要重新修改需求描述，或者和相关的开发者讨论清楚以后在下次梳理会上再让团队评估，直到团队能给出点数为止。
在上面的过程中，团队通过故事点数实现了“需求准入”的目的，和一般的需求评审会相比，用户故事梳理会有明确的输出结果。一般来说，产品经理经过几次这样的会议就能和团队达成默契，明白什么样的需求描述和标准能被团队接受。
用户故事的点数应该能在一个“冲刺”中完成
在敏捷实践中，团队通常会设定一个点数表示某个用户故事能在一个“冲刺”中刚好能被做完。一般来说 13 点被设置为了这样一个点数。
如果某个用户故事的点数超过了 13 点，这个用户故事就应该被拆分成较小的用户故事。能在一个“冲刺”中能完成的用户故事才能作为“冲刺”计划的候选用户故事，因为每个“冲刺”都需要完成一定数量的用户故事作为“增量”交付内容。在一个“冲刺”中做不完就可能导致这个“冲刺”没有可交付的内容。
结论
敏捷开发通过让团队对产品经理书写的用户故事“打分”，实现了需求准入的目的。产品经理不用拘泥于文档的格式，只要能在需求梳理会上让团队为自己拟定的用户故事打出合格的用户故事点数，需求文档就算过关。相比传统的需求文档和评审会议，敏捷实践通过团队交流和合作提高了需求产出的效率。
扫一扫
1024
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
