读《用户故事与敏捷方法》有感（二）
上一次阅读笔记阅读此书结合个人看法着重阐述个人的一些观点，今天回归正题。再次阅读了几个章节，我们怎么编写构造好的故事呢？故事的特征是什么？
首先，在理想情况下，故事之间是独立的。优势很难做到这一点，但我们要尽量实现这一目标。故事之间的交付顺序应该是无关的，可以任意拿一个故事来实现。故事独立了，那么故事细节应该由用户和开发人员讨论得出。而且故事应该很清晰地体现对用户或客户的价值。最好的做法是让客户编写自己故事。那么我们一定要善于和客户做交流，用自己编写的故事原型和客户做需求讨论，然后让用户描述自己的工作场景继续完善故事。用户故事还可以注释一些细节，但是过多的细节会使故事难以理解，也可能给人一种开发人员和客户无需交谈的错觉。所以，写用户故事不是随意编写故事那么简单，我们必须把握一个度。注释太多适得其反，那么有什么好的方法增加注释呢？答案是肯定的，作为开发人员，那么我们最好的方法是给它编写测试用例。故事应该是明确可测试的。最后但同样重要的度的标准是，故事不要太大，复合故事和复杂故事可以分成几个小的故事；故事也不要太小，这样会造成开发人员不想写下这么难以估计的小情节，所以可以吧几个小故事合并成一个较大的故事。作为开发人员，我们负责帮助客户编写故事，这些故事要能提醒你们同客户交谈，而不是记录详细的需求定义，故事应该对用户或者客户有价值，它们是独立的、可测的、大小合适的。如果被问及实现故事所用的技术或者基础架构信息，应该使用对用户或者客户有价值的术语来描述。
故事定义好后，我么要对用户角色建模。在很多项目中，需求分析人员只是从一个角度写用户故事，这样往往容易忽略一些需求，因为有些故事针对的并不是系统的一般用户。以用户为中设计和交互设计的规则使我们懂得，在编写故事前识别用户角色和虚构人物有很多好处。本章我们将学习用户角色、角色建模、角色映射和虚拟人物，并学习利用这些初步步骤来编写更好的故事，开发更好的软件。
作为开发人员，我们必须负责参与确认用户角色和虚构人物的过程。并负责理解每个用户或虚构人物，以及它们之间的异同。开发软件时，负责考虑不同的用户角色对于软件如何运行的不同偏好。负责确保在识别和你描述用户角色时，它们只是这个过程中的工具，不应超越作为工具之外的任何用途。