|
项目管理者联盟
1、 什么是用户故事?项目管理者联盟
用户故事是描述用户、系统等的有价值的需求。用户故事包含三部分内容：pmp.mypm.net
1) 简述：故事简单的题要，作为计划和提示的标题。项目管理者联盟
2) 对话：有关故事的详细描述，用于故事的细节。项目管理者联盟
3) 测试：对故事细节的再细化，以及确认故事完成的判定依据。PgMp.mypm.net
一般用故事卡片来展现故事，正面有简述和对话，而背面去设计测试的内容。用户故事是对业务人员和开发人员的一个平衡。无论业务还是开发人员单方面把持了绝对地位，项目可能就会遭殃。用好用户故事可以保持这个平衡。项目管理者联盟
2、 用户故事是否可以作用对客户的约束?项目管理者联盟
很遗憾，用户故事不建议做为合同或是正式的约定来约束客户。因为与客户的及时沟通比你用故事来约束客户更有用，而且敏捷开发也是欢迎客户的需求变化的。所以故事是可以讨论的，它不是合同或是必须如此实现的需求，在不同的环节会多次与客户进行沟通、完善、修改。talent.mypm.net
3、 我们以什么样的形式去编写用户故事?项目管理者联盟
我建议最好是团队和客户代表一起进行头脑风暴去写所有能想到的故事(包括：测试内容)。这样开发人员也能在开发前就意识到自己开发所应注意的问题(测试驱动开发)。当大家把所有故事写出了，可以进行讨论，对各自已有的故事进行合并、分拆和删除等。training.mypm.net
4、 编写一个什么样故事合适?项目管理者联盟
编写一个故事至少要遵循如下原则：talent.mypm.net
1)
每个用户故事代表一个单独的功能，而且这个功能是对客户有价值的。(即不能是一个“太监”的故事，如：将用户信息存入数据库。这个结果客户不易见，而且后续还会有另一个故事：对存入的数据进行检验并显示结果。最好写成：管理员将用户信息存入数据库并验证显示结果)这样即明确了这个故事对客户的价值，也可以摆脱前后故事的依赖。项目管理者联盟
2) 每个用户故事的粒度应适合在一个迭代中完成。对于超出一个迭代的故事要进行拆分。项目管理论坛
3)
用户故事细节不应太多。尤其在前期故事过多的细节会让人认为这些细节是真实的客户需求，而往往这些内容实在头脑风暴时开发人员自己想到的，这就直接影响了后续讨论的深度。即使是客户的真实需求，有些细节也应该在测试内容中进行体现。club.mypm.net
4)
用户故事是可测试的。这点在反应设计约束或是非功能性需求时尤其重要。比如一个故事描述为：系统反应迅速、易操作。这条故事是不可测试的，反应迅速要明确时间的限制，而易操作则需要客户代表不断地去验证。当然，这些非功能的客户需求(如：易操作)可能会在后期逐渐明确成功能性的客户需求并被翻译成故事或UI/UE。项目经理博客
5)
故事阶段就要从业务上考虑后期的复用。在编写用户故事时，就要考虑一些用户故事可能会在不同的业务流程中复用，如果这样就要考虑把可复用的故事分拆出来。复用越在前面考虑越省成本。service.mypm.net
5、 故事在什么情况下会变更?bbs.mypm.net
1) 随着客户对需求不断明确、不断细化。项目管理培训
2) 市场需求发生了变化。项目管理者联盟
3) 客户和团队理解出现误差。talent.mypm.net
4) 发现故事粒度太大，无法在一个迭代完成。club.mypm.net
5) 对某个故事无法估算(如：技术不了解，无法估算)。这时可能会再在这个故事前再加几个技术研究类故事。有的则干脆搞出个Sprint0来。pmp.mypm.net
等项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
