《敏捷软件开发：用户故事实战》—小结

小结

l   理想情况下，故事是彼此相互独立的。这在一定程度上较难做到，但写出来的故事只有彼此相互独立，才能便于以任意的顺序进行开发实现。

l   故事的细节在用户和开发人员之间是可协商的。

l   故事对用户或者客户的价值应该清楚地写出来。实现这一目标的最佳方式是让客户写故事。

l   故事可以用细节来标注，但是细节太多的话会使故事含混不清，会给人产生错觉：开发人员和客户之间不需要对话了。

l   注释一个故事的最好方法之一就是为故事写测试用例。

l   太大的复合故事和复杂故事应该拆分成更多较小的故事。

l   多个太小的故事可以合并成一个更大的故事。

l   故事必须是可测试的。

开发人员的责任

l   开发人员有责任帮助客户编写故事，这些故事是用来承诺对话而不是需求的细节规格，故事必须是对用户或客户有价值的，具有独立性，可测试的，并且具有适当的大小。

l   如果被问及故事所用的关于技术或基础结构的信息，开发人员负责使用对用户或客户有价值的术语来描述。

客户的责任

l   客户负责写的故事是用来承诺对话，而不是需求的细节规格，同时故事必须是对用户或客户自己有价值的，具有独立性，可测试的，并且具有适当的大小。