《实例化需求》三

• 这是人的问题，而不是技术问题。
• 正确地构建一个产品和构建一个正确的产品是两件完全不同的事情，我们要确保他们都成功。
• 活文档，从根本上来讲，如同程序源代码一样，是关于系统功能的另一个可靠的信息源，只是更容易被获取，更容易被理解。
• 让产品待办事项更容易地管理。
• 只有当团队已经准备好实现某事项时才开始着手实例化需求，比如迭代开始的时候。
• 从目标获取范围，交流商业意图，然后团队提出解决方案。
• 冗长的描述会过度地约束系统，与其描述什么是必须要做的，不如描述为什么需要去做什么。
• 传统的验证方式有这样的问题：如果我们在业务需求和技术自动化之间转化时丢失了某些信息，那么我们就冒着引入问题的危险。
• 自动化的实例化需求，如果仍然用可被人们读懂的方式去描述，而且整个团队的成员都很容易获取到，那么它实际上就变成了并可执行的需求。
• 测试就是需求，需求就是测试。
• 将活文档视为服务不同客户和利益相关者的独立产品。
• 使用实例化需求后，可能会发现不再需要用户验收测试了。
• 改变过程时，将实例化需求作为文化变革的一部分推出，关注质量的提高，从自动化功能测试开始，引进新的工具，使用TDD作为阶梯。
• 改变文化，要避免敏捷术语，得到管理层的支持，实例化需求是一种更好地执行用户验收测试的方法，不要将自动化作为最终目标；不要关注于特定工具；留一个人迁移历史遗留脚本（称之为“蝙蝠侠”）；跟踪谁在和谁不在运行自动化测试；聘用有经验的人；引进顾问；推行培训。
• 实行签收制和可追溯制，将需求说明放入版本控制系统中，获取活文档的签收，获取项目范围的签收而不是具体需求的签收，获取精简用例的签收，引入用例实现。
• 警告信号有：频繁改动的测试、退回返工、测试延误、以防万一的代码以及霰弹式修改（即到处修改）。
• F16战机，原先的需求是高速，但真正的问题是要能在战斗中逃避敌人的战机，30多年后它还是非常成功。
• 范围隐含着解决方案，制定出目标，并进行协作，确定出与目标一致的项目范围。
• 人们告诉你他们认为他们想要的，但是通过询问他们为什么想要，可以确定出新的真正的需求。
• 要了解为什么有的东西是需求的、什么人需要，是提出解决方案的关键点。
• 讨论，划分优先级和评估目标等级，可以更好地理解需求，减少所需的精力。
• 从外到内的设计模式，先从系统的输出结果开始，调查为什么需要它们，以及软件如何提供这些功能（来自BDD）。
• 另外一个方法就是让程序员去编写故事卡的“我需要……”的部分。
• 如果你对范围没有控制权，就去询问为什么某些东西是有用的，询问另外一种解决方案，不要只关注最低那一层的需求，交付完整的功能。
• 团队协作是非常有价值的，可以尝试进行整个大团队的工作坊，也可以尝试更小的工作坊（三个人），开发人员和业务分析师结对进行测试，开发人员审核测试，使用非正式的对话进行协作。
• 业务分析人员是交付团队的一部分，而不是客户代表。
• 当你拿起一张用户故事卡，说到“我不是很确定”时，就说明详细程度十分恰当，而这会促使你与业务人员进行一次交流。
• 团队协作，进行具有引导性的会议，让利益相关者参与进来，提前准备，程序员和测试人员一起审查用户故事，只准备基本的例子，广泛地进行障碍性讨论。
• 检查需求是否完整的一个最好的办法就是设计一个与之相对应的黑盒测试用例。如果我们没有足够的信息去设计一个好的测试用例，那么我们绝对没有足够的信息去开发一个系统。
• 功能模块的例子必须具有精确性（不是简单的是或否的答案，使用具体的例子）、真实性（使用真实数据，从客户那儿获取真实的例子）、完整性（使用不同的数据组合去试验，利用其他方式去检验和测试），并易于理解（不用试验所有组合，寻找隐含的概念你）。
• 无论什么时候如果发现需求中有太多实例或实例太复杂，就要努力将其复杂度降低，描述简单化。
• 应该阐明非功能性需求，获取精确的性能需求，在用户界面设计上使用简单原型，使用QUPER模型（译者注：一种确定非功能性需求的方法），讨论时使用检查清单，对于那些难以量化的事项（比如要有趣味性），可以创建参考的例子用来说明。
• 好的需求说明，应该是精确的、可测试的，不应该用脚本去编写，也不应该写成流程描述的样子。
• 对系统应该如何工作的描述应予以避免，要关注于思考系统应该做什么。
• 需求说明应该与软件设计无关，不应与代码联系太紧，应避开技术难题，不要深陷在用户界面细节里。
• 需求说明应该具有自我解释性，具有描述性标题，对目标的描述要简短，能被他人理解，不要过度定义，从基本开始然后扩展。
• 需求说明要集中，使用“given—when—then”模式，不要特意细节化所有的依赖，可在技术层使用默认值，但不要依赖它们。
• 定义和使用一门统一语言。
• 从自动化开始，使用小的试验项目，事先计划好，不要推迟或者委派，避免自动化现有的手动脚本，从UI测试中获取信任。
• 管理自动化测试，不要将其定位成用以描述验证的二等代码。不要复制业务逻辑，根据系统边界进行自动化，不要用UI层去验证业务逻辑。
• 自动化用户界面，定义更高层次的交互（例如“登录功能”，而不要定义成“填写登录页面”），与UI需求一同验证UI功能，避免录制和回放，在数据库中创建上下文。
• 测试数据的管理，应避免使用预先生成的数据，使用预先制定的参考数据，从数据库获取原型。
• Bott’s Dott’s（译者注：凸起的，会反光的路面标记）是一种车道标志，在人们越线时给以警示。持续集成在软件开发中有同样的作用，在持续集成中运行实例化需求，我们就会拥有持续的验证。
• 降低不可靠性，找到最困扰的问题并将其修复，确认不稳定的测试，建立专门的验证环境，完成自动部署，对于外部系统使用测试替身（test double），实现多级验证，在事务中执行测试，对参考数据进行快速验证，等待事件而非消耗时间，将异步执行设定为可选项，不要把需求说明当成是端到端的验证。
• 为了更快地获取回馈，可以引入业务时间，将长时间测试拆分成小的模块，避免使用内存数据库做测试，区分快测试和慢测试，保持过夜测试的稳定，创建一个当前迭代包，平行地执行测试。
• 管理失败的测试，有的时候你无法修正所有的测试，这时可以创建一个回归的失败包，自动检查屏蔽的测试。
• 要让文档容易理解，应避免过长的需求说明，避免使用多个较小的需求说明去描述单一功能，寻求更高层的概念，避免技术上的自动化概念。
• 文档要一致，演进出一门统一语言，使用虚构人物，在制定语言时进行协作，记录构建单元。
• 改善文档的组织方式，便于访问，可以使用用户故事、功能区域、UI交互路径、业务流程，使用标签而不要使用URLs。