用户故事与敏捷开发 notes

1、如果故事太大以致无法在一轮迭代中完成，可以考虑把它分成两个或更多的小故事；

2、用户故事是很有意思的，因为他们强调口头沟通，客户和开发人员都可以理解，可以用于进行迭代计划，在迭代开发过程中能很好地工作，因为使用用户故事事实上鼓励推迟细节；

3、优秀的故事应该具备以下特点：独立的，可讨论的，对用户或客户有价值的，可估计的，小的，可测试的；

4、理想情况下，故事之间是独立的。有时很难做到这一点，但我们要尽量实现这一目标；

5、故事应该很清晰地体现对用户或客户的价值。最好的做法是让客户编写故事；

6、给故事加上注释的最好的方法是给它编写测试用例；

7、能够引出及捕获需求这一想法是错误的。它有两个有问题的假设：用户知道所有的需求；需求一旦被捕捉，就锁定，不再改变；

8、使用开放式、与背景无关的提问更容易获得有用的答案，例如，“告诉我你想怎么搜索工作？”就胜于“你要通过职位名称来搜索工作吗？”

9、让开发经理担任用户代理，是最坏的选择之一，除非你们开发的软件就是给开发经理用的；让领域专家来担任用户代理的另一个潜在问题是，最终开发出的软件可能仅仅针对那些与领域专家有类似水平的用户；

10、让客户，而不是开发人员，编写故事；

11、故事与用例之间最明显的区别是它们的范围。两者的大小都以交付商业价值为目标，但故事的范围更小，因为我们对它们的大小有限制，以便用于安排工作；

12、相信我们能够写下一个系统的所有需求，然后从上往下想出解决方案，这向来就是一个美丽的陷阱。约20年前，Parnas及Clements（1986）已经告诉我们根本不可能有这样的好事儿。