敏捷软件开发(用户故事实战)
①全新正版，现货速发，7天无理由退换货②天津、成都、无锡、广东等多仓就近发货，订单最迟48小时内发出③无法指定快递④可开电子发票，不清楚的请咨询客服。
￥ 29.2 4.2折 ￥ 69.8 全新
库存2件
浙江嘉兴
认证卖家担保交易快速发货售后保障
作者迈克·科恩
出版社清华大学出版社
ISBN9787302511083
出版时间2019-01
装帧平装
开本16开
定价69.8元
货号30415237
上书时间2024-10-13
- 在售商品 暂无
- 平均发货时间 17小时
- 好评率 暂无
商品详情
- 品相描述：全新
- 商品描述
-
前言
前 言
在20世纪90年代中期的大部分时间里，我都感到愧疚。我当时正在为一家公司工作，这家公司每年都会收购一家新公司。每次收购一家新公司，我都会被分派去负责打理他们的软件开发团队。收购的每个开发团队都带来了辉煌、美观、冗长的需求文档。我不可避免地感到愧疚，因为我自己的团队从来没有写出过如此优美的需求规格说明。但是，我的团队在生产软件方面一直比我们收购的团队成功得多。
我清楚我们成功的方法。然而，我总有一种难以名状的感觉，如果我们能写出大而冗长的需求文档，我们可能会更加成功。毕竟，那正是我当时正在阅读的书籍和文章中所描述的做法。如果成功的软件开发团队都在编写华丽的需求文档，那么看起来我们也应该这样做。但是，我们从来没有时间做。我们的项目总是太重要，需要我们尽快启动，以至于我们从一开始就没有时间来写文档。
因为我们从来没有时间写美观而冗长的需求文档，所以我们决定采用一种工作方式来与用户沟通。我们不是把需求写下来，让它们来回传递，并在时间不够用的时候还在谈判，而是和客户交谈。我们会在纸上绘制界面样例，有时候会创建原型，通常我们会写一些代码，然后向预期用户展示我们编写的内容。至少每月一次，我们会邀请一组具有代表性的用户，并向他们演示我们开发的功能。通过贴近用户并向他们演示小的增量进展，我们找到了一种方法来帮助我们在没有美观需求文档的情况下取得成功。
尽管如此，肯特•贝克（Kent Beck）仍然感到愧疚，认为我们没有按照我们应该的方式去做事。
1999年，肯特•贝克的革命性小册子《解析极限编程》出版发行。一夜之间，我所有的愧疚荡然无存。终于有人提出了开发人员和客户之间用讨论取代“写文档-商谈-再写文档”的模式。肯特阐明了很多事情，并带给我很多新的工作方法。但是，*重要的是，他证明了我从自己的实践中领悟到的是正确的。
大量的前期需求收集和文档可能在多方面导致项目失败。*常见的一种情况是需求文档本身成为软件开发的目标。需求文档只有在能够帮助实现交付某些软件的真正目标时才应该编写。
大量的前期需求收集和文档可能在多方面导致项目失败的第二种情况是书面语言的不准确性。我记得很多年前听到过一个小孩洗澡的故事。小孩的父亲已经在浴缸中放满了水，正准备帮助他的小孩进入水中。这个小孩大概两三岁，先把脚趾头伸入水中蘸了一下，然后迅速将脚趾移开，并告诉她的父亲“让它暖和一些”（make it warmer.）。父亲把手伸入水中，惊讶地发现水不是太冷，已经比他女儿习惯的温度更热了。
父亲思索了一下孩子的请求，意识到他们的沟通出现了问题，用相同的词语来表示不同的意思。孩子“让它暖和一些”的请求被任何成年人都解释为“调高水温”（increase the temperature）。然而，对于孩子来说，“让它变暖”意味着“让它接近我认为暖和的程度”。
文字，尤其是白纸黑字那样的，通过它来表达软件这样复杂东西的需求，是比较简单有限的载体。由于它们可能被误解，所以我们需要用开发人员、客户和用户之间频繁的对话来取代书面文字。用户故事为我们提供了这种方法，让我们写下来足够多我们不会遗忘的内容，并且我们可以估算和计划，同时还鼓励及时沟通。
读完本书的第I部分时，你将准备开始改变总是严格写下每一个需求*后细节的工作方式。读完本书的时候，你会知道在具体环境中实施故事驱动过程所有的必要信息。本书分为四个部分和两个附录。
第I部分“开始”，描述开始编写故事需要了解的一切。用户故事的目标之一是让人们说话而不是写作。第I部分的目标是尽快让你交谈。第1章概述了什么是用户故事以及如何使用故事。接下来的章节提供了编写用户故事，通过用户角色建模收集故事，在无法访问实际*终用户时编写故事以及测试用户故事的更多细节。第I部分的结尾部分提供了一些指导方针，可以用来改进用户故事。
第II部分“估算和计划”，有了一系列用户故事后，我们经常需要回答的*件事是“需要花费多长时间来开发？”。第II部分介绍了如何使用故事点来估算故事，如何在3~6个月的时间范围内计划发布，如何更详细地计划随后的迭代，*后如何度量进度并评估项目是否按照既定的意愿进行。
第III部分“经常讨论的话题”，首先描述故事与用例，软件需求说明和交互设计场景等需求方案的不同之处。随后探讨用户故事的独特优点，如何判断出现问题的时间，如何调整敏捷过程Scrum以使用故事。*后一章着眼于各种小问题，例如是否在纸质卡片或者软件系统中编写故事以及如何处理非功能性需求。
第IV部分“一个完整的项目案例”，一个扩展的例子，旨在帮助归纳用户故事的所有内容。如果说开发人员可以通过故事更好地理解用户的需求，那么本部分的完整示例是非常重要的，这个示例将展示用户故事的各个方面及其结合方式。
第V部分“附录”，用户故事源于极限编程。阅读本书之前不需要熟悉极限编程。附录A提供了极限编程的简要介绍。附录B包含对各章结尾思考练习题的解答。
【免费在线读】
商品简介
作为敏捷社区的经典名作，《敏捷软件开发：用户故事实战》不负众望，为软件行业提供了一种高效的需求过程，通过用户故事来节省时间、消除重复工作和开发更优秀的软件。要想构建可以满足用户需求的软件，*好的方法是从“用户故事”开始，用简明扼要的语言清楚明确地描述对实际用户有价值的功能。在本书中，敏捷实干家提供了一个详尽的蓝图来指导读者如何编写用户故事，如何在软件开发生命周期中实际运用用户故事。 《敏捷软件开发：用户故事实战》共5部分21章，介绍了如何写出理想的用户故事，造成用户故事不理想的因素有哪些，如何在无法直接接触到用户的情况下有效搜集用户故事，如何对写好的用户故事进行整理、排优先级并在此基础上进行计划、管理和测试。 《敏捷软件开发：用户故事实战》适合采用XP、Scrum甚至其他自主敏捷方法的所有开发、测试、分析师和项目负责人阅读和参考，可以帮助他们以更少的人手在更短的时间内开发出更符合用户需求的产品或服务。
作者简介
\\\\\\\"作者简介迈克？科恩（MikeCohn）敏捷联盟联合创始人&Scrum联盟联合创始人及理事会主席，CST（Scrum认证讲师），MountainGoatSoftware创始人兼总裁。迈克从1984年开始编程，1988年开始管理软件项目，1995年开始做自己的第一个Scrum项目，从此一发不可收，成为Scrum的忠实拥趸和积极的倡导者。他熟悉很多硬件和软件环境，尤其擅长于指导组织采用和改进敏捷过程和技术的应用，帮助他们打造高绩效的软件开发企业。他服务过很多公司，从新创公司到财富40强都有，比如加拿大游戏制作公司Bioware、第一资本CapitalOne、艺电ElectronicArts、谷歌，高月工作室HighMoonStudios、财捷Intuit、JDA软件，律商联讯LexisNexis、航空航天公司洛克希德马丁LockheedMartin、微软、尼尔森媒体调研、培生教育、飞利浦电器、旅游公司Sabre、西门子、升阳微系统、德州仪器、特纳广播公司TBS、人力资源软件开发商UltimateSoftware和雅虎。
译者简介王凌宇精益敏捷践行者，PMI-ACP，PMP。历任高级项目经理、研发经理、项目群经理、产品经理、敏捷教练等职位，现任上市公司PMO敏捷教练和研发管理专家。
教练指导过多个产品团队实现敏捷转型，成效显著。对于精益敏捷方法的推广应用，项目管理以及PMO的建设运营具有丰富的实践经验。参与译著有《SAFe4.0精粹：运用规模化敏捷框架实现精益软件与系统工程》。
\\\\\\\"
目录
目 录
第I部分 开 始
第1章 概述3
什么是用户故事？4
细节在哪里？5
“需要在多长时间内完成？”7
客户团队7
使用故事的过程是什么样的？8
计划发布和迭代9
什么是验收测试？11
为什么要改变？12
小结13
思考练习题13
第2章 编写故事15
独立的15
可协商的16
对用户或客户有价值的18
可估算的19
小的20
拆分故事20
合并故事22
可测试的23
小结24
开发人员的责任24
客户的责任24
思考练习题24
第3章 用户角色建模27
用户角色27
角色建模步骤29
通过头脑风暴，创建初始的用户角色集合29
整理初始的角色集合30
聚合角色31
细化角色32
两个额外的技术33
用户画像33
极端人物34
如果有现场用户呢？34
小结35
开发人员的责任35
客户的责任35
思考练习题36
第4章 收集故事37
引出和捕捉需求是不适用的37
一点儿就够用了，不是吗？38
方法39
用户访谈39
问卷调查41
观察41
故事编写工作坊42
小结44
开发人员的责任45
客户的责任45
思考练习题45
第5章 与用户代理合作47
用户的经理47
开发经理48
销售人员49
领域专家50
营销团队50
前用户50
客户51
培训师和技术支持52
业务分析师或系统分析师52
如何与用户代理合作？52
当用户存在但访问受限时52
当真的找不到用户时53
你能自己做吗？54
建立客户团队54
小结54
开发人员的责任55
客户的责任55
思考练习题55
第6章 用户故事验收测试57
在编码之前编写测试58
客户定义测试59
测试是过程的一部分59
多少测试才算多？59
集成测试框架60
测试的类型61
小结62
开发人员的责任62
客户的责任62
思考练习题62
第7章 好故事编写指南63
从目标故事开始63
纵切蛋糕64
编写封闭的故事64
约束卡片65
根据实现时间来确定故事规模66
不要过早涉及用户界面66
需求不止故事67
故事中包括用户角色67
为一个用户编写故事68
用主动语态68
客户编写68
不要给故事卡编号68
不要忘记目的69
小结69
思考练习题69
第II部分 估算和计划
第8章 估算用户故事73
故事点73
团队估算74
估算74
三角测量76
使用故事点77
如果用结对编程呢？78
“敲黑板”79
小结79
开发人员的责任79
客户的责任79
思考练习题80
第9章 发布计划81
我们希望什么时候发布？82
希望在发布中包含哪些特性？82
故事优先级排序83
混合优先级排序84
风险故事84
优先考虑基础设施需求85
选择迭代长度86
从故事点到预期工期86
初始速率86
猜测速率87
创建发布计划87
小结88
开发人员的责任88
客户的责任89
思考练习题89
第10章 迭代计划91
迭代计划概述91
讨论故事92
分解任务92
认领责任94
估算及确认94
小结95
开发人员的责任96
客户的责任96
思考练习题96
第11章 度量和监测速率97
度量速率97
计划速率和实际速率99
发布燃尽图100
迭代燃尽图102
小结104
开发人员的责任104
客户的责任105
思考练习题105
第III部分 经常讨论的话题
第12章 用户故事不是什么109
用户故事不是IEEE 830109
用户故事不是用例112
用户故事不是场景115
小结117
思考练习题117
第13章 用户故事的优点119
口头沟通119
用户故事容易理解121
用户故事的大小适合于计划122
用户故事适合迭代开发123
故事鼓励推迟细节124
故事支持随机应变的开发124
用户故事鼓励参与式设计125
故事增强隐性知识125
用户故事的不足126
小结126
开发人员的责任127
客户的责任127
思考练习题127
第14章 用户故事的不良“气味”129
故事太小129
故事相互依赖130
镀金130
细节过多131
过早包含用户界面细节131
想得太远132
故事拆分太频繁132
客户很难对故事排列优先级132
客户不愿意写故事并对故事进行优先级排序133
小结134
开发人员的责任134
客户的责任134
思考练习题134
第15章 在Scrum项目中使用用户故事135
Scrum是迭代式和增量式的135
Scrum基础136
Scrum团队137
产品待办列表137
Sprint计划会议138
Sprint评审会议140
每日Scrum站会140
在Scrum项目中加入用户故事142
用户故事和产品待办列表142
Sprint计划会议中使用用户故事142
Sprint评审会议中使用用户故事143
用户故事和每日Scrum站会143
案例学习143
小结144
思考练习题145
第16章 其他主题147
处理非功能性需求147
纸质还是软件？148
用户故事和用户界面150
保留故事152
用户故事描述bug153
小结154
开发人员的责任154
客户的责任154
思考练习题155
第IV部分 一个完整的项目案例
第17章 用户角色159
项目159
识别客户159
识别一些初始角色160
聚类与细化161
角色建模163
增加用户画像164
第18章 故事165
Teresa的故事165
Ron船长的故事168
初级海员的故事168
非海员礼品购买者的故事169
报表查看者的故事169
一些管理员的故事170
结束171
第19章 估算故事173
第一个故事174
高级搜索176
评分和评价177
账号177
完成估算178
所有的估算179
第20章 计划发布181
估算速率181
对故事进行优先级排序182
完成的发布计划183
第21章 验收测试185
搜索的测试185
购物车的测试186
购买书籍187
用户账号188
管理188
测试约束189
最后一个故事190
第V部分 附 录
附录A 极限编程概述193
附录B 各章思考练习题参考答案203
参考文献217
内容摘要
\\\\\\\"作为敏捷社区的经典名作，《敏捷软件开发：用户故事实战》不负众望，为软件行业提供了一种高效的需求过程，通过用户故事来节省时间、消除重复工作和开发更优秀的软件。要想构建可以满足用户需求的软件，最好的方法是从“用户故事”开始，用简明扼要的语言清楚明确地描述对实际用户有价值的功能。在本书中，敏捷实干家提供了一个详尽的蓝图来指导读者如何编写用户故事，如何在软件开发生命周期中实际运用用户故事。
《敏捷软件开发：用户故事实战》共5部分21章，介绍了如何写出理想的用户故事，造成用户故事不理想的因素有哪些，如何在无法直接接触到用户的情况下有效搜集用户故事，如何对写好的用户故事进行整理、排优先级并在此基础上进行计划、管理和测试。
《敏捷软件开发：用户故事实战》适合采用XP、Scrum甚至其他自主敏捷方法的所有开发、测试、分析师和项目负责人阅读和参考，可以帮助他们以更少的人手在更短的时间内开发出更符合用户需求的产品或服务。
\\\\\\\"
主编推荐
《敏捷软件开发：用户故事实战》的特色如下：
专注于“用户故事”这一灵活、敏捷和实用的需求方法
强调如何用更短的时间开发更符合用户需求的软件应用
揭示如何在不能直接与用户交流的情况下搜集用户故事
精辟阐述如何围绕着用户故事进行全面的规划、进度、估算和测试
诠释用户故事的优势，用户故事与用例、使用场景和传统需求方法的不同
极限编程（Extreme Programming）、Scrum或其他任何敏捷方法的理想搭档
《敏捷软件开发：用户故事实战》的精彩内容：
用户角色建模：理解不同用户角色之间的共性与差异
搜集故事：用户访谈、问卷调查、观察和工作坊
与管理者、培训师、销售人员和其他代理人合作
为验收测试写用户故事
运用故事来排优先级、设进度和估算发布成本
各章末尾包含思考练习题
【内容简介】
精彩内容
第2章编写故事在这一章里，我们将介绍如何编写故事。为了创建好的故事，我们需要关注六个特征。一个好的故事应该具备以下特征（INVEST）：独立的（Independent）可协商的（Negotiable）对用户或客户有价值的（Valuabletousersorcustomers）可估算的（Estimatable）小的（Small）可测试的（Testable）《极限编程》（ExtremeProgrammingExplored）和《重构实践手册》（RefactoringWorkbook）的作者比尔？威克（BillWake）建议用单词首写字母缩写INVEST指代这六个特征（Wake2003a）。
独立的我们应该尽量避免故事之间相互依赖。故事间的相互依赖会导致优先级排序和计划出现问题。例如，假设客户选定了一个高优先级的故事，而这个故事却依赖于一个低优先级的故事，这样就会产生问题。
故事间的相互依赖也会使估算变得更加困难。例如，假设我们在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中的细节，关于这个故事的讨论就有可能变得更加具体和真实。但这可能会导致错误的判断：故事卡反映了所有的细节，没有必要再与客户进一步讨论这个故事了。
如果我们把故事卡看作是开发人员和客户进行对话的一种提示，那么故事卡中包含如下信
— 没有更多了 —
以下为对购买帮助不大的评价