敏捷软件开发（用户故事实战）

作者简介

\\\"作者简介 迈克？科恩（Mike Cohn） 敏捷联盟联合创始人&Scrum联盟联合创始人及理事会主席，CST（Scrum认证讲师），Mountain Goat Software创始人兼总裁。迈克从1984年开始编程，1988年开始管理软件项目，1995年开始做自己的第一个Scrum项目，从此一发不可收，成为Scrum的忠实拥趸和积极的倡导者。他熟悉很多硬件和软件环境，尤其擅长于指导组织采用和改进敏捷过程和技术的应用，帮助他们打造高绩效的软件开发企业。他服务过很多公司，从新创公司到财富40强都有，比如加拿大游戏制作公司Bioware、第一资本Capital One、艺电Electronic Arts、谷歌，高月工作室High Moon Studios、财捷Intuit、JDA软件，律商联讯Lexis Nexis、航空航天公司洛克希德马丁Lockheed Martin、微软、尼尔森媒体调研、培生教育、飞利浦电器、旅游公司Sabre、西门子、升阳微系统、德州仪器、特纳广播公司TBS、人力资源软件开发商Ultimate Software和雅虎。 译者简介 王凌宇 精益敏捷践行者，PMI-ACP，PMP。历任高级项目经理、研发经理、项目群经理、产品经理、敏捷教练等职位，现任上市公司PMO敏捷教练和研发管理专家。 教练指导过多个产品团队实现敏捷转型，成效显著。对于精益敏捷方法的推广应用，项目管理以及PMO的建设运营具有丰富的实践经验。参与译著有《SAFe 4.0精粹：运用规模化敏捷框架实现精益软件与系统工程》。 \\\"

内容简介

第2章 编写故事 在这一章里，我们将介绍如何编写故事。为了创建好的故事，我们需要关注六个特征。一个好的故事应该具备以下特征（INVEST）： 独立的（Independent） 可协商的（Negotiable） 对用户或客户有价值的（Valuable to users or customers） 可估算的（Estimatable） 小的（Small） 可测试的（Testable） 《极限编程》（Extreme Programming Explored）和《重构实践手册》（Refactoring Workbook）的作者比尔？威克（Bill Wake）建议用单词首写字母缩写INVEST指代这六个特征（Wake 2003a）。 独立的 我们应该尽量避免故事之间相互依赖。故事间的相互依赖会导致优先级排序和计划出现问题。例如，假设客户选定了一个高优先级的故事，而这个故事却依赖于一个低优先级的故事，这样就会产生问题。 故事间的相互依赖也会使估算变得更加困难。例如，假设我们在BigMoneyJobs网站上工作，需要编写故事：公司如何为在网站上发布职位进行付费。我们可以写出如下这些： 1.公司可以用Visa信用卡对发布职位进行付费。 2.公司可以用万事达信用卡对发布职位进行付费。 3.公司可以用美国运通卡对发布职位进行付费。 假设开发人员估算需要3天的时间来支持第一种信用卡（不管它是哪种），然后给第二种和第三种各分别需要1天。对于像这些有相互高依赖关系的故事，你不知道如何对每个故事进行估算—哪个故事应该给3天的估算？ 当故事间出现这种依赖时，有两种应对方法可以避免。 将相互依赖的故事合并成一个更大但独立的故事。 寻找一种不同的方式来拆分故事。 将不同种类的信用卡合并成一个独立的大故事（“公司可以使用信用卡对发布职位进行付费”）是不错的，因为合并后的故事只需要5天时间。如果合并后的故事花费的时间要比这长得多，通常一个更好的方法是找一个不同的维度来拆分故事。如果对这些拆分后故事的估算时间更长，那么另一种拆分方法如下： 1.客户可以用一种信用卡支付。 2.客户可以用另外两种信用卡支付。 如果你不想将这些故事合并在一起，并且无法找到一个很好的方法来拆分它们，那么你还可以采用简单的方法，即在故事卡上放两个估算值：较高的估算值给二者之间必须在前面完成的故事，较低的估算值给后面接着要完成的故事。 可协商的 故事是可协商的，它们不是签署好的书面合同或者是软件必须实现的需求。故事卡是对功能的简短描述，其细节是在客户和开发团队之间的对话中协商产生的。因为故事卡本身并不是详细的需求，而是用来提示客户和开发团队进行对话的，所以它们不需要包括所有相关的细节。然而，在编写故事的时候，如果一些重要的细节是已知的，那么就应该把它们包括在故事卡的注释中，如故事卡2.1所示。挑战在于如何掌握包含“足够”的细节。 公司可以用信用卡支付发布职位的费用。 注释：接受Visa信用卡、万事达信用卡和美国运通卡。考虑美国发现卡。 故事卡2.1 一个注释了额外细节的故事卡 故事卡 2.1是一个不错的故事卡，因为它提供了适量的信息供开发人员和客户讨论。当一个开发人员开始编码实现这个故事时，故事卡会提示她必须支持三种主卡（Visa信用卡、万事达信用卡和美国运通卡），同时她也可以询问客户是否已经决定接受美国发现卡。卡片上的注释可以帮助开发人员和客户恢复之前中断的对话。理想的情况下，不管是原来对话的开发人员和客户，还是其他的开发人员和客户，对话都应该能够恢复。把细节加入故事时，应该以此为指导原则。 另一方面，让我们思考一个带有太多注释的故事，如故事卡2.2所示。这个故事有太多的细节（“收集卡片的过期月份和日期”），还结合了一个单独的故事（“系统可以存储一个卡号供将来备用”）。 公司可以用信用卡支付发布职位的费用。 注释：接受Visa信用卡、万事达信用卡和美国运通卡。考虑美国发现卡。当支付金额超过100美元时，需要提供卡背面的ID号。系统可以根据卡号的前两位数字识别客户使用的是何种类型的信用卡。系统可以存储卡号以备将来使用。收集信用卡的过期月份和日期。 故事卡2.2 细节过多的故事卡 处理故事卡2.2这样的故事是非常困难的。大多数读者在阅读这种故事时，会错误地关注本不应该关注的细节。然而，在许多情况下，过早指定细节只会产生更多的工作。例如，如果两个开发人员讨论和估算一个简单的故事“公司可以用信用卡支付发布职位的费用”，开发人员知道他们的讨论有点抽象，他们不会误以为他们的讨论是明确的，或者他们的估算是准确的，因为缺少太多的细节。然而，如果向故事卡中添加更多类似故事卡2.2中的细节，关于这个故事的讨论就有可能变得更加具体和真实。但这可能会导致错误的判断：故事卡反映了所有的细节，没有必要再与客户进一步讨论这个故事了。 如果我们把故事卡看作是开发人员和客户进行对话的一种提示，那么故事卡中包含如下信息就是很有价值的。 用来提示保持开发人员和客户对话的一两句话。 在整个对话期间待解决问题的注释。 已经通过对话确定的细节将变成测试。如果使用纸质故事卡，我们可以在故事卡背面注明测试内容，如果使用电子系统，可以标注在合适的地方。故事卡2.3和故事卡2.4展示了故事卡2.2中的过多细节如何变成测试，用于提示对话的注释可以留存在故事卡正面。这样，故事卡的正面包含故事本身和关于相关问题的注释，而卡片的背面则包含用于验证故事是否像预期的那样，以测试形式体现的故事细节。 公司可以用信用卡支付发布职位的费用。 注释：我们需要接受美国发现卡吗？ UI注释：不需要专门的字段来输入信用卡类型（可以从信用卡号的前两位来获得该信息） 故事卡2.3 修正后的故事卡正面（只有故事和需要讨论的问题） \\\"《敏捷软件开发：用户故事实战》的特色如下： 专注于“用户故事”这一灵活、敏捷和实用的需求方法 强调如何用更短的时间开发更符合用户需求的软件应用 揭示如何在不能直接与用户交流的情况下搜集用户故事 精辟阐述如何围绕着用户故事进行全面的规划、进度、估算和测试 诠释用户故事的优势，用户故事与用例、使用场景和传统需求方法的不同 极限编程（Extreme Programming）、Scrum或其他任何敏捷方法的理想搭档 《敏捷软件开发：用户故事实战》的精彩内容： 用户角色建模：理解不同用户角色之间的共性与差异 搜集故事：用户访谈、问卷调查、观察和工作坊 与管理者、培训师、销售人员和其他代理人合作 为验收测试写用户故事 运用故事来排优先级、设进度和估算发布成本 各章末尾包含思考练习题 \\\"