新闻与资讯
敏捷方法的内容（2）
发表日期：2016-05-12被浏览： 2099次返回
协作用户故事的创建
大部分项目失败的主要原因在于规格说明的缺乏。规格说明的问题可能来自于用户缺乏对他们真实需要的了解，或者是缺乏对系统的全局观，以及在沟通过程中传达了不需要的或不一致的、甚至是错误的特性。
在敏捷开发中，用户故事用于从开发人员、测试人员和业务代表的视角来捕获需求。在顺序开发中，这种特性的共同价值观是在需求编写完成后，通过正式评审来实现；在敏捷开发中，这种特性的共同价值观是在需求编写过程中通过频繁的非正式评审来完成。
用户故事必须处理功能和非功能性特性。每一个用户故事都包含这些特性的验收准则。这些准则通常是在业务代表、开发人员以及测试人员的共同协作下定义出来的。它们提供给开发人员和测试人员对业务代表将要确认的这些特性额外的了解。当一系列的准则满足时，敏捷团队就可以宣称一个任务完成。
通常，测试人员具有独特的视角，通过识别遗漏的细节或非功能性需求帮助改进用户故事。测试人员通过向业务代表提出开放式问题，提出测试用户故事的方法并确认验收准则来帮助改进用户故事。
以作者的身份提供用户故事协作，可以通过采用头脑风暴或思维导图等技术进行。测试人员可以采用INVEST技术：
根据[Jeffries00]提出的3C概念，一个用户故事是以下3个元素的有机联合体：
-
卡片（Card）：卡片是用来描述用户故事的物理介质。卡片描述了需求，紧急性，期望的开发和测试周期，以及故事的验收准则。由于将要用于产品待办列表中，用户故事描述应尽可能地精确。
-
对话（Conversation）：对话解释了软件将会如何使用。对话可以是书面的或口头的。测试人员拥有与开发人员和业务代表不同的观点[ISTQB_FL_SYL]，可以为交换想法、观点和经验带来有价值的输入。对话始于发布计划阶段，并一直持续到用户故事被排入开发进程中。
-
确认（Confirmation）：在对话中讨论的验收准则被用于确认用户故事的完成。这些验收准则 可能跨越多个用户故事。正正向和逆向的测试应该被用于覆盖验收准则。在确认过程中，各类参与者扮演测试人员的角色。这可能包括开发人员，也包括关注性能、安全性、互操作性以及其它质量特性的专家。为了确认一个用户故事的完成，已定义的验收准则应该被测试，并显示是被满足的。
敏捷团队有不同的方法来文档化他们的用户故事。不论采用哪种方法来文档化用户故事，文档内容应该是简洁的，充分的以及必要的。
回顾
在敏捷开发中，回顾是指在一个迭代结束后举行的会议，该会议讨论哪些是成功的、哪些需要改进以及如何在未来的迭代里整合这些改进并继续保持成功。回顾会议的主题通常包括：过程、人员、组织、关系和工具。当有适当的后续活动发生，定期举行回顾会议对开发和测试的自组织和持续改进是重要的。
回顾可能会产生关注于测试有效性、测试效率、测试用例的质量和团队满意度等测试相关的改进决定。他们也可能会处理应用程序、用户故事、特性或系统接口的可测试性。缺陷（defect）的根本原因分析可以驱动测试和开发的改进。通常，在每个迭代中团队应只实施少量的改进。这允许以一个持续的步伐来连续的改进。
回顾的时间和组织形式依赖于团队所采用的敏捷方法。业务代表和团队作为参与者参加每一个回顾，而会议组织者则组织并确保会议的开展。在某些情况下，团队可能邀请其他参与人员到会。
在回顾中，测试人员应该发挥重要的角色。测试人员作为团队的一员，在回顾中可以带来独特的观点。测试活动在每一个冲刺（Sprint）中进行，对于成功功不可没。所有的团队成员，包括测试和非测试人员，都可以提供测试和非测试活动的输入。
回顾必须在相互信任的专门环境下进行。成功回顾的标志与在基础级大纲讨论的其他任何评审一样。