如何在用户体验中应用敏捷方法是当今设计领域的一个热点话题，也是设计人员应该具备的一项新技能。在过去，用户体验团队在实践敏捷方法时有许多成功的经验，也有很多失败的教训。本书提供确定敏捷用户体验含义所需的工具，包含丰富的案例研究，以及航行于敏捷用户体验之海所需要考虑的现实因素。你将学习到团队成功的有利因素，以及确定成功路径需要考虑的因素。阅读本书之后，你将获得更快、更简单地用敏捷过程改进软件和开发产品的知识。

本书主要内容
深入探讨《敏捷宣言》中传达的价值观和原则。
分析在团队完全认可敏捷的精神和价值观的前提下如何将用户体验融入敏捷环境。
通过丰富的案例详细介绍如何采用敏捷开发流程和设计思维，并从不同角度呈现参与者对敏捷用户体验的看法。
分析团队成功进行敏捷用户体验工作的因素，如何才能打造高效团队。
围绕在启动敏捷用户体验过程中遇到的“视情况而定”问题，如何创建优雅的解决方案。
分析用户体验团队如何在实践中吸收和采纳敏捷概念。
包含了敏捷用户体验实施成功和常见错误的实例。


作者简介










资深用户体验设计专家、敏捷培训师、Nuance公司首席用户体验设计师，关注和推动企业软件产品开发转型、敏捷开发方法与实践、质量管理，拥有数十年交互设计和软件界面设计经验。善于为软件开发组织提供全方位的指导。她曾帮助许多公司在实际项目中成功实施敏捷方法，培训美国和其他国家的开发团队。她还是一位卓越的演讲家，经常在大型国际会议上发表演讲。

当发现自己将要为一个使用Scrum的项目提供支持时，我立刻就变得小心翼翼。我并非真的很了解Scrum和敏捷（Agile），但是我意识到，这些技术都在快速发展，而且没有真正地将UX考虑在内。然而，我无法选择我的团队采用的开发过程，所以只能放下自己的不安，做好支持团队的准备。
　　我很幸运，有一些内部专家是用户体验（UX）团队的倡导者，他们和开发团队并行或者提前投入工作。他们的模型看上去非常符合逻辑且顺畅，我很高兴应用这些技术。但是从一开始，我就注意到自己所处的情况下有许多因素和他们的经验不相符，我不完全确定如何修改这些技术来适应环境。我的团队在物理上不处于同一个位置（但是也不极端），规模大于推荐的标准，除了用户界面之外，该项目还有一个重要的基础结构组件。这些问题都不是毁灭性的，但是我需要调整自己的过程，对于自己是否足够“敏捷”，我总是不太确定。
　　结束这个项目之后，我在本地的可用性专家会议上分享了自己的经验，这令人大开眼界。人们渴望着这方面的深刻见解和指南，并且有着许多相同的问题。然而，情况千变万化，这些问题的答案对每个人而言也各不相同。我被不同的敏捷UX实现搞得筋疲力尽，觉得在围绕敏捷和UX的对话中，不足以反映出这种多样性。我感觉到，如果我知道有许多方法可以实现敏捷UX，并且通过了解这些方法，我能够对自己的方法更加自信。我想，“应该有人写本书”，几年之后，我做到了。
　　本书的目标是说明UX团队在敏捷上有许多成功和失败的方法，并阐明在不同的情况下，使用相同的策略可能造成不同的后果。书中的案例研究说明有许多方法实现敏捷方法，UX团队在敏捷环境里需要不止一两年的时间才能做得好。我研究了团队成功的原因，以及确定团队实现正面结果的最佳途径所需要考虑的因素。在阅读本书之后，你将拥有确定特定情况下使用的敏捷UX方法所需的工具。
鸣谢
　　感谢DeMarco Interactive的Doug DeMarco为本书创作了出色的插图。

计算机\软件工程

如何在用户体验中应用敏捷方法是当今设计领域的一个热点话题，也是设计人员应该具备的一项新技能。在过去，用户体验团队在实践敏捷方法时有许多成功的经验，也有很多失败的教训。本书为你提供了确定敏捷用户体验含义的工具，包含丰富的案例研究，以及航行于敏捷用户体验之海所需要考虑的现实因素。你将学习到团队成功的贡献因素，以及确定成功路径需要考虑的因素。阅读本书之后，你将获得更快、更简单地用敏捷过程改进软件和开发产品的知识。
本书主要内容：
·深入探讨《敏捷宣言》中传达的价值观和原则。
·分析在团队完全认可敏捷的精神和价值观的前提下如何将用户体验融入敏捷环境。
·通过丰富的案例详细介绍如何采用敏捷开发流程和设计思维，并从不同角度呈现参与者对敏捷用户体验的看法。
·分析团队成功进行敏捷用户体验工作的因素，如何才能打造高效团队。
·围绕在启动敏捷用户体验过程中遇到的“视情况而定”问题，如何创建一个优雅的解决方案。
·分析用户体验团队如何在实践中吸收和采纳敏捷概念。
·包含了敏捷用户体验成功和常见错误的实例。

（美）Diana DeMarco Brown 著：暂无简介

姚军　等译：暂无简介

信息技术的巨变为我们呈现了一个丰富多彩、别开生面的世界。软件行业的建立和发展归功于各相关门类技术和理论的发展，其中软件工程理论是核心和基础。通过前人数十年的不懈努力，整个软件开发生命期已经形成了一套理论体系，并诞生了许多不同的软件开发过程，其中被采用最多的是传统的瀑布开发模型和后起的敏捷开发模式。
　　瀑布开发模型起源于传统制造业，它提出了预先设计、精确定义需求、各阶段利用文档紧密衔接、反复迭代等思想，使软件制造真正成为一个严格的过程，并在许多大型项目上得到了普遍应用，在20世纪80年代成为软件开发的标准。尽管软件业经历了许多变化，但是这一经典模型迄今仍经久不衰，在许多项目上发挥着巨大的作用。
　　随着网络的兴起和软件复杂度的提高，以及软件在人类生活等各个领域中越来越明显的作用，以用户为中心的思想日益深入人心，人们的需求已经超出了传统的软件功能范畴，更多地强调使用的体验，交互设计、用户体验（UX）设计越来越成为蔚然成风的行当，这也给软件开发带来了深远的影响。由于用户的反馈越来越成为软件开发和更新的依据，传统的开发模型推进缓慢、在各阶段可交付工件（例如文档）上开销过大、不能迅速适应变化的矛盾越来越突出。在这种背景下，人们开始积极推行另一种更具备适应性、开发过程更迅速的开发模式—敏捷开发模式。这种模式摒弃了传统模式下对预先确定需求和设计细节以及制作大量文档的要求，将软件分解为更小、更灵活的单元，可快速开发、测试、迭代，使得软件更容易根据用户的反馈做出改变，而对团队沟通的强调，更是这一方法的精髓，它不仅是一个开发过程，更是组织和团队文化的构建过程。敏捷方法的价值观和准则不仅代表着新时代软件需求变化造成的影响，更代表着网络时代新经济实体高效协作的理念。
从用户体验设计和敏捷开发模式产生的背景来看，两者有许多融合之处，但是两者鲜明的特性，又使得真正的融合举步维艰。由于敏捷开发模式是以开发活动为中心的，设计人员往往游离其外，而在传统过程中的大量习惯也影响了设计人员对敏捷开发模式的看法。人们期待着敏捷UX方面的权威指导，期待着各个功能区真正地相互理解、协作和融合。
　　本书是用户体验设计专家Diana DeMarco Brown的力作，不仅为UX人员详细解说了敏捷开发过程的含义、核心价值观和准则，更宝贵的是提供了许多不同公司的案例，这些案例中有的团队已经在敏捷UX上达到了炉火纯青的地步，有些游离于传统方法和敏捷方法之间，还有些则面临着很大的挑战、苦苦挣扎，利用这些正面和反面的例子，读者可以看到不同情况下敏捷团队所需要面对和考虑的各种因素，从而深受启发。
　　在本书的翻译过程中，我们对敏捷开发模式和UX设计都有了新的认识，也期待着它能给更多的读者提供前进道路上的利器。由于译者的水平有限，错误在所难免，敬请广大读者见谅。
　　本书的翻译工作主要由姚军完成，徐锋、陈绍继、郑端、吴兰陟、施游、林起浪、陈志勇、刘建林、宁懿等人也为本书的翻译工作做出了贡献，在此特别感谢机械工业出版社华章分社的编辑对翻译工作提出的中肯意见。

译者序
前言
第1章　敏捷方法简介 1
1.1　导言 1
1.2　敏捷价值观+UX 3
1.2.1　个体和交互重于过程和工具 4
1.2.2　可用的软件重于完备的文档 5
1.2.3　客户协作重于合同谈判 6
1.2.4　对变化的响应重于遵循计划 7
1.3　敏捷原则+UX 8
1.3.1　原则1：我们最重要的任务是通过尽早和持续交付有价值的软件来满足客户 8
1.3.2　原则2：即使在开发的后期也欢迎需求的更改。敏捷过程利用更改来为客户获得竞争优势 9
1.3.3　原则3：频繁交付可用软件，从几周到几个月，优先考虑较短的时间段 10
1.3.4　原则4：业务人员和开发人员在整个项目创作期间每天都必须一起工作 10
1.3.5　原则5：围绕积极的个体构建项目。为他们提供环境并支持他们的需求，相信他们能够完成工作 11
1.3.6　原则6：在开发团队中传达信息的最有效方法是面对面的交谈 12
1.3.7　原则7：可用软件是进展的主要度量 13
1.3.8　原则8：敏捷过程提倡可持续开发。项目方、开发人员和用户应该长期保持步调一致 14
1.3.9　原则9：对卓越技术和优秀设计的持续追求能够改进敏捷性 14
1.3.10　原则10：简洁性不可或缺，它是减少工作量的艺术 15
1.3.11　原则11：最好的架构、需求和设计源自于自我组织的团队 16
1.3.12　原则12：团队定期总结更为高效的手段，然后相应地调整自身的行为 17
1.4　常见方法 18
1.4.1　Crystal 18
1.4.2　极限编程 18
1.4.3　Scrum 19
1.4.4　混合敏捷 21
1.4.5　看板 22
1.4.6　Scrumban 23
1.4.7　Lean UX 24
1.5　常见术语 25
1.5.1　鸡和猪 25
1.5.2　产品负责人 25
1.5.3　Scrum主管 26
1.5.4　冲刺 27
1.5.5　产品待办事项列表 27
1.5.6　用户故事 28
1.5.7　史诗 29
1.5.8　计划扑克 29
1.5.9　故事点估算 30
1.5.10　验收标准 31
1.5.11　燃尽图 31
1.5.12　穿刺 32
1.5.13　AgileFall 32
1.5.14　Jeff Patton 33
1.6　案例研究—Jeff Gothelf，TheLadders.com 33
关键点 36
1.7　小结 36
参考书目 36
第2章　敏捷方法+UX=敏捷UX 39
2.1　导言 39
2.2　将UX融入到敏捷环境中 41
2.3　UX工作 47
2.3.1　资源和人员 48
2.3.2　规格说明 51
2.3.3　用户调查 54
2.3.4　可用性测试报告 59
2.3.5　设计活动 62
2.4　案例研究—Catherine Robson，Seachange International 64
关键点 68
2.5　小结 68
参考书目 69
第3章　案例研究 71
3.1　导言 71
3.2　Suzanne O扠elly，AppNexus 72
关键点 75
3.3　Thyra Rauch，IBM 76
关键点 78
3.4　Archie Miller，Snagajob.com 78
关键点 82
3.5　Carol Smith，Perficient 82
关键点 86
3.6　Kayla Block，PAR Springer Miller 86
关键点 90
3.7　无名氏1，一家企业级软件公司 91
关键点 93
3.8　Christina York，ITHAKA 94
关键点 98
3.9　无名氏2，一家大型桌面软件公司 98
关键点 103
3.10　Austin Govella，Avanande 103
关键点 107
3.11　Josh O扖onnor，爱尔兰国家盲人理事会 108
关键点 109
3.12　Adrian Howard，Quietstars 109
关键点 111
3.13　Elisa Miller，GE Healthcare的高级用户体验工程师 111
关键点 116
3.14　小结 117
参考书目 117
第4章　共同的成功因素 119
4.1　导言 119
4.2　项目重于过程 121
4.3　团队的活力 125
4.4　沟通 127
4.5　定义整体思路 130
4.6　培训 131
敏捷方法的学习资源 132
4.7　适应和进化 136
4.8　案例研究—Sarah Kahn，Adzerk 137
关键点 142
4.9　案例研究—无名氏3，一家专门从事产品直接营销的公司 142
关键点 146
4.10　小结 146
参考书目 147
第5章　常见问题 149
5.1　导言 149
5.2　我们应该采用敏捷方法吗 149
5.3　应该采用多长的冲刺周期 152
5.4　UX应该制作什么可交付物 153
5.5　UX团队如何融入开发团队的冲刺中 155
5.6　如何在开发人员忙于实现设计时谈论另一个设计 156
5.7　如果UX团队成员必须支持多于一个项目怎么办 157
5.8　如何将用户调查融入冲刺周期 157
5.9　如果团队声称是敏捷的，但是没有看到敏捷价值观的体现，该怎么办 158
5.10　如果团队不在一起办公该怎么办 159
5.11　当有人以“这不是敏捷方法”为由不做某些工作时，我该怎么办 160
5.12　UX团队如何为下一次发行开展计划和调查 160
5.13　如何管理内部利益相关方 161
5.14　小结 162
参考书目 162
第6章　将敏捷概念用于UX团队 163
6.1　导言 163
6.2　创建用户体验待办事项列表 163
6.3　重复进行用户测试 164
6.4　将工作分解为较小的部分 165
6.5　不断的反馈和迭代 166
6.6　反复进行的活动和仪式 166
6.7　没有设计明星或者英雄 166
6.8　与文档相比更注重沟通 168
6.9　构思和传达用户故事 168
6.10　定义验收标准 169
6.11　减少预先设计 170
6.12　小结 170