用户故事与敏捷方法 - 第七章 优秀用户故事准则

        最好的办法是是考虑每一个用户角色，了解用户使用我们软件的目地。

        切蛋糕 （整体突进，不要单独把某个细节做到极致。）

        当面临一个大的故事时，通常许多办法可以将它分解成小故事。许多开发者首先想到将故事按照技术路线分割。如果按技术的路线分割故事，那么很难保证在这个故事在被分解后在单个迭代中是对客户有价值的。

        千万不要用技术角度分割故事。

        一个更好的办事是换一种方式编写故事，每个故事都提供某种程度的完整的功能（end-to-end）。Bill Wake 称他为切蛋糕。

        在编写用户故事时，更倾向于编写一块完整蛋糕那样的完整故事。具体有两个原因。首先，在开发中，及早涉及软件应用程序架构的每一层能够降低最后时刻发现层次架构方面的问题风险。其次，  尽管不十分完美，即是只提供了部分功能，只要发布的功能可以跑，就可以放心的把应用程序发布给用户。

        

    编写封闭故事

    任务闭包性。

    卡片约束

    对系统的要求，比如该系统要满足50个并发用户请求。

    根据实现时间来确定故事规模

    故事拥有层次，史诗故事，正常故事，史诗故事被大家讨论分解成一个个正常故事。

    不要过早涉及用户界面

      

    有些需求并不是故事

    

    在故事中包括用户角色

    大多数故事都有拥有自己的角色，角色引出故事，故事引出角色。

    用户故事格式  （角色名称）可以（功能）。

    用户故事格式   我作为（角色），想要（功能），以此（商业价值）

    你可以尝试这个模板或者使用自己的模板。像这样的模板有助于区分重要的和无关紧要的故事。

     

    只为一个用户编写

    一定要从单个用户的角度就考虑故事，这样故事会更加清晰。比如求职者可以删除简历，这个故事并不清晰，他可以删除谁的简历？自己的？别人的？所以应该改成求职者可以删除自己的简历。

    

    以主动语态编写

    简历可以被求职者修改改成求职者可以修改简历。

    由客户编写

    在理想情况下，故事由客户编写。不能完全转嫁给开发者。客户需要理解每个故事，从而为每个故事安排合适的迭代。

    

    向故事卡编号说“不”

    初次使用故事卡片时，很多人情不自禁的给他们编号。这样做的理由是可以方便追踪到故事。但是这样做会增加无谓的流程，会让我们抽象画去讨论形象化的功能。所以如果必要给故事添加编号的话，那么试着给故事加上一个简单的标题，并在其余的故事描述文本中使用这个标题做缩写。

    不要忘记意图

    不要忘记故事卡的主要目的是用来提醒开发人员与客户团队讨论的。既然仅仅是一个提示，就要保持他的简洁性。加入需要的细节，以便于联想到继续对话的切入点，但不要在故事卡上加入太多的细节并取代对话。