用户故事实战

用户故事实战 pdf epub mobi txt 电子书 下载 2026

出版者:清华大学出版社
作者:Mike Cohn
出品人:
页数:244
译者:王凌宇
出版时间:2019-1
价格:69.80
装帧:平装
isbn号码:9787302511083
丛书系列:
图书标签:
  • 敏捷
  • 产品经理
  • UserStory
  • 翻译好
  • 产品
  • 非虚构
  • 职场
  • 用户故事
  • 用户故事
  • 敏捷开发
  • 需求分析
  • 软件工程
  • 产品管理
  • Scrum
  • XP
  • 迭代开发
  • 软件需求
  • 用户体验
想要找书就要到 小美书屋
立刻按 ctrl+D收藏本页
你会得到大惊喜!!

具体描述

作为敏捷社区的经典名作,《敏捷软件开发:用户故事实战》不负众望,为软件行业提供了一种高效的需求过程,通过用户故事来节省时间、消除重复工作和开发更优秀的软件。要想构建可以满足用户需求的软件,好的方法是从“用户故事”开始,用简明扼要的语言清楚明确地描述对实际用户有价值的功能。在本书中,敏捷实干家提供了一个详尽的蓝图来指导读者如何编写用户故事,如何在软件开发生命周期中实际运用用户故事。

《敏捷软件开发:用户故事实战》共5部分21章,介绍了如何写出理想的用户故事,造成用户故事不理想的因素有哪些,如何在无法直接接触到用户的情况下有效搜集用户故事,如何对写好的用户故事进行整理、排优先级并在此基础上进行计划、管理和测试。

《敏捷软件开发:用户故事实战》适合采用XP、Scrum甚至其他自主敏捷方法的所有开发、测试、分析师和项目负责人阅读和参考,可以帮助他们以更少的人手在更短的时间内开发出更符合用户需求的产品或服务。

作者简介

作者简介

迈克科恩(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精粹:运用规模化敏捷框架实现精益软件与系统工程》。

目录信息

目 录
第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 830 109
用户故事不是用例 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
用户故事描述bug 153
小结 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
· · · · · · (收起)

读后感

评分

非常好的书,解释了很多东西。作为刚接触敏捷的pm或者ba,这绝对是一本入门的经典之作。<br><br>非常好的书,解释了很多东西。作为刚接触敏捷的pm或者ba,这绝对是一本入门的经典之作。<br><br>非常好的书,解释了很多东西。作为刚接触敏捷的pm或者ba,这绝对是一本入门的经典...  

评分

用户故事是敏捷开发流程中的一个工具,使用用户故事来收集、整理、分析、跟踪需求。 本书比较详细地解说用户故事的用法。以下是书中的一些观点信息的摘抄: 1:如果故事太大以致无法在一轮迭代中完成,可以考虑把它分成两个或更多的小故事; 2:用户故事是很有意思的,因为...  

评分

评分

评分

第一次看本书,但是没有项目管理经验,对里面讲述的内容似懂非懂。 第二次看本书,有了一些项目管理经验,开始明白有些内容确实是有用的。 在具有几年项目管理经验之后再回头看这本书,才发现其中的奥妙所在。 如果你是有经验的PM,相信这本书非常适合你。如果你是PM却经验尚浅...  

用户评价

评分

这部作品,在我读完第一章后,便有种强烈的预感,它将彻底颠覆我对“理论与实践”之间鸿沟的刻板印象。作者在开篇就毫不留情地撕开了那些教科书上光鲜亮丽却空洞无物的概念外衣,直接将我们拽入到真实的项目困境之中。那种娓娓道来,却又字字珠玑的叙事方式,让人仿佛置身于一个高强度的项目评审会上,空气中弥漫着咖啡和焦躁的气息。他没有停留在描述“应该如何做”,而是深入剖析了“在现实中,当所有人都意见相左、时间紧迫时,我们究竟是靠什么来推进工作的”。特别是关于需求澄清的那一节,简直是醍醐灌顶,那种将模糊的愿景转化为可执行步骤的系统性思维,是我在其他任何关于敏捷或产品开发的著作中都未曾如此详尽地见识到的。我尤其欣赏作者在描述技术债务累积的后果时所采用的近乎病理学的分析,清晰地揭示了为何许多项目最终会陷入泥潭,这比单纯的指责更具建设性。

评分

读完这本书,我感觉自己像刚参加完一场高强度的“极限生存训练营”。它的节奏感极其紧凑,几乎没有一页是用来做冗余的铺垫或华丽的辞藻堆砌。每一个案例、每一个工具的引入,都带着一股“解决问题”的实战蛮力。我特别关注了其中关于“反向规划法”的那部分论述,那是一种近乎反直觉的策略,要求团队先设想最坏的结果,再倒推回当前的每一步决策。这种严谨到近乎偏执的风险前置处理,极大地提升了我对未来项目不确定性的容忍度和应对能力。更值得称道的是,作者对于沟通障碍的处理,并非停留于“多说话”这种浅显建议,而是构建了一套精细化的利益相关者地图绘制与沟通频率控制模型。这套模型在我的近期工作中进行了小范围测试,效果立竿见影,那些原本需要耗费数小时的跨部门协调会议,现在只需十分钟就能达成共识,效率的提升是指数级的。

评分

坦白讲,起初我对市面上充斥着大量“速成指南”的书籍抱有深深的怀疑。然而,这部作品提供了一种截然不同的阅读体验,它更像是一本被高度浓缩的“失败案例档案汇编”,但重点不是去嘲笑失败者,而是从失败的骨架中提取出最坚固的教训。作者对“范围蔓延”的剖析达到了教科书级别的深度,他不仅解释了它如何发生,更重要的是,展示了它在不同组织层级上的表现差异——从最高管理层的战略模糊,到一线开发人员的技术性偏离。书中提到的“范围契约锚点”的概念,我个人认为价值千金,它提供了一个在面对压力时,可以立即回溯的、不可动摇的基准线。这使得原本主观性很强的需求控制,变成了一件可以被量化、被审计的工程任务,极大地增强了项目经理在面对“再加一点点”的诱惑时的心理韧性。

评分

翻到最后一章时,一种复杂的情绪油然而生:既有终于掌握了精髓的释然,又有一种对未来工作挑战性认识加深的敬畏。这本书的叙事脉络是如此的清晰和连贯,它没有给我们提供一个一劳永逸的万灵丹,反而教会了我们如何在一个永远充满不确定性的环境中,建立起一套能够自我修正的“心智模型”。作者对“迭代终结标准”的界定,尤其精妙,它超越了简单的“功能完成”,而更多地指向了“价值交付的最小可信单元”。这种视角的转换,促使我彻底反思了我们过去“做完”和“交付”之间的巨大鸿沟。读完此书,我不再仅仅是一个任务的执行者,而更像是一个系统性的问题解决架构师,对于复杂系统的反馈回路有了更深刻的敬畏和更精准的操控感。

评分

这本书的独特之处在于它超越了工具和流程的层面,直抵人性的复杂性。作者像一位社会人类学家,敏锐地捕捉到了在协作过程中权力动态、认知偏差以及信息不对称是如何扼杀优秀想法的。我印象最深的是关于“沉默的合谋”的章节,它揭示了在看似和谐的团队氛围下,个体为了避免冲突而选择性失声的倾向,以及这种倾向最终如何导致产品方向的彻底跑偏。作者提供的解药并非是推行激烈的辩论,而是一套基于结构化提问和匿名反馈的机制,巧妙地绕过了人际敏感区,让真正的痛点浮出水面。这种对“软技能”的“硬性”量化和结构化,极大地提升了其可操作性。读罢此部分,我开始重新审视过去团队中那些“无疾而终”的讨论,发现背后的机制,往往与作者描述的如出一辙。

评分

总体而言可以一读,有一些地方翻译的还是不容易理解。

评分

总体而言可以一读,有一些地方翻译的还是不容易理解。

评分

总体而言可以一读,有一些地方翻译的还是不容易理解。

评分

总体而言可以一读,有一些地方翻译的还是不容易理解。

评分

写的好好,翻译也好!写用户故事的方法指南,建议产品负责人必备。

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2026 book.quotespace.org All Rights Reserved. 小美书屋 版权所有