User Stories Applied读书笔记（第二章）

 

story应该尽量相互独立，如果确实两个story需要互相依赖，那么1）合并两个story；2）采用其他方案划分story

story card上只需要一个简单的描述，具体涉及到的细节应该在同用户的讨论中得出，以注释的方式记录到story card上（也许是背面），这些细节讨论出来后应该形成测试用户。注意注释不要太多，假如一个story拥有太多的注释，那么1）将注释中的内容抽取出来形成新的story；2）将此story拆分。

注意区分产品的购买者和实际使用者（两者通常是不同的自然人），我们的story是写给最终用户，最终用户不关心的一切技术方面的story都应该除去。写出好的user story最好的办法是把写user story的权利交给用户。

开发人员在对story做评估时通常会遇到三个问题：1）缺少相关领域的知识；2）缺少相关技术的知识；3）story太大。针对于前两种情况，可以采用学习和用户讨论的方式解决，最后一种情况，就需要对story进行细分。

 可分解的story一般分为两种：compound  story和complex story。对于前者，可以采用对方法和对数据划分的方式来细分story，例如“用户可以向网站提交和维护资料”这个compound story，按照对数据操作的方法，可以分为“上传”，“编辑”，“删除”等story，按照对数据本身的不同，可以分为“上传和维护帖子”，“上传和维护图片”，“上传和维护pdf文档”等。对于后者，通常比较复杂和难以划分，可以采用以下的形式来获得较为准确的评估时间，例如，一个complex的story是“A company can pay for a job posting with a credit card”，现在的问题是没有任何一个人知道如何进行网上支付，于是把这个story细分为两个，1）Investigate credit card processing over the web；2）A user can pay with a credit card。对于第一个story，指定一个时间段，从而可以较为容易的确定需要的时间和工作量。

有时候我们还会碰到这种情况，有一些story实在太过与小了，小到维护这个story的时间比实际开发他的时间还要多很多，这个时候我们就需要合并，将需要tiny story合并成为一个较大的，可以在半天或者一个星期内完成的story。

 一个好的story必须是容易测试的，完全通过所有测试用例的story必然也是被完全开发的。

• Ideally, stories are independent from one another. This isn't always possible but to the extent it is, stories should be written so that they can be developed in any order.

• The details of a story are negotiated between the user and the developers.

• Stories should be written so that their value to users or the customer is clear. The best way to achieve this is to have the customer write the stories.

• Stories may be annotated with details, but too much detail obscures the meaning of the story and can give the impression that no conversation is necessary between the developers and the customer.

• One of the best ways to annotate a story is to write test cases for the story.

• If they are too big, compound and complex stories may be split into multiple smaller stories.

• If they are too small, multiple tiny stories may be combined into one bigger story.

• Stories need to be testable.