整合精益用户体验与敏捷方式
棒~好期待完整的翻译出炉^ ^
敏捷方式是现在的主流。同样还有用户体验设计，这要感谢Kindle、iPhone等注重用户体验的产品带来的巨大成功。但一直以来，如何将敏捷方式和用户体验结合才是我们工作中的难点。在本章中，我将带你们回顾精益用户体验是怎样搭配最受欢迎的敏捷风格的——Scrum过程——并讨论怎样融合精益用户体验和敏捷方式，来创造一个更有朝气的团队以及更高效的协作过程。包括：
名词解释
只是明确一下我们对“周期”和“用户故事”的理解角度是否一致。
交叉周期
敏捷/精益的融合，一度曾遥不可及，现在正成为真实的团队凝聚基石。
倾听Scrum节奏
Scrum会议清晰地整合了精益用户体验，就像是音乐的旋律与节奏。
共同参与
真正跨职能过程，要求每个人都参与其中。
设计是一场团队游戏
确保过去封闭的设计过程，现在正面向所有的成员敞开，这是成功的关键。
管理收放有度
通过主动沟通并积极准备来扫除团队前进的障碍。
敏捷的过程，包括Scrum，有很多专业术语。随着时间的推移，其中很多术语又有了自己的释义。为了保证表意清晰，我将花点时间在这里定义其中的一些（如果你熟悉Scrum，可以跳过这段。）
Scrum
Scrum是一种敏捷方式的流程，可以促进工作循环优化、团队高效构建，并使参与者有高度责任感。Scrum是最流行的敏捷形式。
用户故事（User stories）
用户故事是指用最浓缩的方式概括产品给目标用户带去的好处。典型的用户故事撰写原则：
作为 [用户类型]
我希望[达成的事情]
所以[达成的目的]
故事列表（Backlog）
故事列表是指一个有优先级的用户需求表。故事列表是敏捷方式过程中最有用的管理工具。通过对需求的动态维护，团队可以对每天的工作量以及部署新的工作进行有效管理。这就是团队保持敏捷的缘由。
周期（Sprint）
每个周期都像一次冲刺，它是一个独立的工作循环。每个周期的交付物都应该是完整可执行的。大部分Scrum团队一个周期不超过2周。
站立开会（Stand-up）
每天的短会，每个成员汇报今天遇到的问题——这是Scrum团队自建的一种工具。每个成员必须向其他成员阐述每天做了什么，以及发生了什么。
回顾（Retrospective）
每个周期结束时，真诚的回顾什么做的好，什么做的不好，以及团队在下一个周期中应如何提高。流程迭代就像产品迭代一样。回顾，为你带来任何优化的可能。
迭代准备会议（Iteration planningmeeting）
关于计划接下来这一期需要做什么的会议，每当周期创建时召开。有时，会包括用户故事的收集和评估。迭代准备会议决定了故事列表的初始优先级。
2007年5月，Desiree Sy 和Lynn Miller在可用性研究期刊上，刊登了“关于适用敏捷方式的用户体验设计的可用性调查”
(https://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.pdf)
Sy和Miller是第一批尝试结合敏捷方式与用户体验的人，他们得到的方案进一步激发了我们中的许多人。对于敏捷方式和以用户为中心的设计是如何高效集成的，在文中Sy和Miller详细描述了自己的想法。他们使用的方式叫做“周期0”（即“迭代0”或“交叉周期”）。
简而言之，Sy和Miller描述了一个流程：设计活动发生在前置的周期中（图7-1）设计工作在“设计周期”中被完成，然后结束并交付到“开发周期”中，等待开发实施。
图7-1 Sy和Miller的交叉周期模型
很多团队曾对这个模型产生误解。Sy和Miller经常倡导不管是在“设计周期”还是“开发周期”，设计师和开发工程师都应该高效合作，但很多团队都遗忘了这个关键点，反而建立了类似小型瀑布式的工作方式，设计师和工程师之间的交流仅仅是交接工作。
交叉周期让部分团队运转良好。但如果你的研发环境不允许频繁发布（比如，你在研发套装软件、嵌入式软件，或者需要交付软件到一个难以或无法持续优化的环境），获得设计权需要花费的成本较高，那么，精益用户体验设计与你的团队可能不适合，因为你需要花大功夫去获取市场反馈，为此你应该在该方面寻求各种方式和技巧。
如果团队能提供一个仍然保持着高效合作的环境，那么在交叉周期后，设计就能更多地得到验证。另外，还有正从瀑布型转变为敏捷型的团队，也能从交叉周期中获益，因为它教会你把工作拆解成有秩序的列表，然后用更短的周期去工作。
但是，这个模型只是一种最佳的过渡型态。你的团队不应该就此止步。原因是：它非常容易出现这种状况，整个团队从来没有同时一起做事。这样，你永远无法理解跨职能合作的好处，因为大家的学科不同关注点不同。没有那样的合作，就没有基于分享的理解，所以你只能重度依赖文档和交接工作时的沟通。
另外一个原因说明这个流程不够理想：它造成不必要的损失。设计师花费时间撰写文档，解释设计周期发生了什么。如果开发工程师不曾参与设计周期，那他们根本没机会去评估可行性和设计的范围。直到交接工作时，开发工程师才跟设计师有交流，他们能够在接下来的2周真正完整地认识设计方案吗？如果不能，那么设计中的那些基础工作就被浪费了。
正如我在本章开始所说的，我们在TheLadders公司尝试实践交叉周期模式。当遇到问题继续优化，最终我们获得了一个更深度合作的程式，像是Scrum的旋律打着节拍。让我们看下，如何通过Scrum会议来运用和精益用户体验，进而构建更高效的流程。
主题
Scrum需要召开大量会议。很多人不喜欢开会，但如果你把它们当作你冲刺周期的里程碑，那你就创造了一个流程，它整合了精益用户体验和敏捷方式，因为在这里，整个团队正在同一时间为同一件事而工作。
让我们拿一个2周-周期的模型打比方，并且假设可以把项目的一系列周期全部聚集在一起，我们称之为主题。（图7-2）
图7-2 一个主题下的不同周期
项目启动系列工作，概述和构思
每个主题都需要启动，启动工作包括一些列头脑风暴和类似第2章所举例的验证练习。这些活动最短可能是一个下午，最长可能有一周。你可以和你的直接团队成员或者更大组织的成员一起完成这件事。主题的范围由参与度和可允许的时间决定。启动工作的目的是让整个团队一起来构思、创造丰富的方案，这些方案是试验和精益的来源。
一旦开始周期，这些方案会被试验、验证、拓展为新的知识，并且你需要决定针对他们可以做些什么。你做出这些决定是在接下来的每次新周期前的一系列更短的头脑风暴中。这些决定，让团队保证永远用当前最佳的方案来创建下期的故事列表。（图7-3）
图7-3 主题，概述范围、构思过程以及头脑风暴
迭代准备会议
项目启动工作的产出物：杂乱的便利贴、草图、线框、纸面原型以及其他产物，会被带到迭代准备会议中（IPM）。对旁观者来说可能无用，但对你的团队来说是极具意义的。你把这些创作收集起来，因为他们非常重要，你可以从分享的见解中提取出故事。在迭代准备会议（IPM）中使用他们(图7-4)，用来撰写用户故事，然后对故事评估和排出优先级。
图7-4头脑风暴系列后立即召开迭代准备会议
用户反馈验证计划
最后，为确保能持续听到用户的声音和反馈建议，制定计划的人需要每周召开会议（图7-5）让你的团队永远贴近用户，至少5个工作日内必有一天是跟用户反馈验证有关的。同时，要保持想法在周期结束前能有足够的响应时间。规划构想时的产出物是用户测试的基本素材。记住，如果产出物是未经加工的，验证标准就是自己。（即，大家真的喜欢我的产品吗？）一旦你开始衡量用户对产品的需求，就可以输出更高保真的产出物了，不管你当时的标准是对的还是错的。
图7-5 与用户的对话每周都会发生。
第3章一开始展示的图表，告诉我们一个巨大的教训：设计师需要时间来变得更有创意。2周的开发和设计周期为创意时间提供了可能。一些敏捷方式，采取比Scrum更灵活的时间把控方法。（比如，在为期2周的繁杂工作中废除了看板方式，以及强调单线程工作）但是使用Scrum，你也可以在一个周期中腾出时间进行创意活动。
我在TheLadders公司的用户体验团队没有找出这部分时间，因为当时大家没有完全参与Scrum过程。这并不完全是我们的错：Scrum过程的内容对用户体验设计师大多没什么价值。但没有我们的参与，我们的需求和关注点又不能被考虑到项目计划中。结果是，我们使用额外时间去创意，而团队其他成员并不理解这对用户体验来说是必须的。
对于敏捷方式的精益用户体验工作，整个团队必须参加所有活动，回顾、站立开会、迭代会议，头脑风暴，他们都需要所有人用心投入。除了可以讨论某些复杂的特性，跨职能的参与还帮助设计师和开发人员有效地建议优先级列表。
例如，假设在一个周期开始时，有一个第一优先级的需求，需要设计的成分很高，但是设计师不在，他不能表达自己的想法和关注点。那这个团队的问题在第2天站立开会时就会被发现。设计师声明那个需求没有经过设计。然后他会说需要在需要2-3天来完成设计，才能提交开发。试想，如果在这之前，设计师已经参与了优先级的排序，他可以给建议把这个定为第一优先级的需求往后排。团队可以选择一个故事卡，这样可以减少设计师的事先准备工作，这样也不会占用设计师太多时间。
参与者对分享的理解，也饱受伤害。在会议上会作出决定，这些决定都基于讨论。即使一个会议90%的内容都与你不直接相关，但你可以利用。这90%为你提供了时间来理解为什么作出这些决定，以及另外10%与你相关的部分，要怎样向你的下游去解释和传达。
参与，帮助你为工作争取时间。对用户体验设计师来说真的有用，对团队中的其他人也一样。
设计是一场团队游戏：Knowsy案例研究
在这个案例研究中，设计师和教练Lane Halley详细阐述了他们怎样与所以的玩家：开发、设计、市场、还有其他相关人员一起创建一个平板电脑游戏。
作为一个产品设计师，我在各种项目里实践精益用户体验。目前我的工作主要是针对娱乐、商务和社交媒体设计不同平台的产品，包括ipad、iphone和web。团队一直很小，从3个人到7个人。大多数项目有以下特点：
项目在一个敏捷方式的框架内运行（以客户为中心，持续性的交付，成员们坐在一起，轻量级的文档，成员有决策权，分享仪式如站立会议、回顾，等等）
成员掌握多种复合技能（前端&后端开发，用户体验&信息架构，产品管理&营销，平面设计，文案）
成员通常在擅长领域工作，但也参与其他领域并且有兴趣学习新的技能。
大部分成员和我一起工作，我们创造全新的产品或服务。他们不工作在一个现有的产品框架或结构中。在“green filds”这样的项目里，我们试图了解这种全新的产品或服务将怎样被使用，他应该如何被展现，我们应该如何去设计。这个是一个不断变化的世界，没有很多耐心等待我们去计划或预设。
创新游戏公司
创新游戏公司（简称TIGC）生产一系列线上或线下游戏，为市场研究带来帮助。TIGC帮助研究机构获得了可行的灵感来探索用户需求及喜好，来提高游戏配合中的表现。2010年，我被邀请帮助TIGC，为消费市场开发一款新游戏。
我是Knowsy ipad版本的团队成员，一个单机互动（pass-and-play）游戏，主要玩法是互相测试跟你的朋友、家人、同事彼此的了解程度。对其他人了解最多的玩家可以获胜。这是一个快速、有趣、真实的6人“社交”游戏。
这是我们第一次做ipad应用程序。我们定了一个雄心勃勃的期限：用一个月来完成这个游戏，并在苹果应用商店上架。我们的小团队综合了产品专业知识、前后端开发技能，还有视觉和交互设计。过程中的每个阶段我们还邀请别人来帮助我们试玩，测试游戏。
一个新产品很难让所有人都能在相同的愿景下辛勤工作，直到编辑代码阶段，。哪些功能是重要的？或者什么应该第一个做？当争论发生，你就会认识到团队缺乏共同的愿景。这样，团队成员会普遍认为：团队没有“高效运转”或者团队总是一次次地讨论同一个问题。
在Knowsy工作期间,我寻找到一个方式，让用户体验实践更具协作性，可视化，轻量级还有不断迭代。我找机会跟团队其他成员一起工作（如开发人员和产品经理），希望设计草稿能够尽快产出又不用承担过多的责任。
因为对产品有共同的愿景，使我们有信心，找到了合适的解决方案。共同的团队认识，设计理念，能够设计出更加丰富的产出物。（图7-6）
图7-6 Knowsy团队以及贴着产出物的工作墙
打破设计瓶颈
在项目早期，我坐在那儿与前端开发人员讨论游戏设计。我们一起发明了一个高级的游戏般的工作方式，在纸上标记和来回传递我们的想法，就好像我们在对话。这是一个让我倾听和学习他想法的机会。当我们传递纸片时，我尝试指出两人的分歧点，比如“这种情况发生的时候我们该怎么做？”这个方法比起直接说你是错的我是对的更能解决问题。
图7-7 纸上原型开始成型
达成基本共识后，我能够基于这个游戏创立一个纸上原型，然后跟团队其他成员进行测试（图7-7）这立即影响了整个团队。顿时，所有人“明白了”并为之兴奋。人们贡献的点子逐渐能够很好地结合在一起，并且我们能够分解出可以各自完成的部分，并最终支持整个工作。
一旦所有人有了共识，我就能更容易地整理出一个可点击的原型了，因为花在文档上的时间和跟团队待在一起的时间减少了。
图7-8 Lane正在实时更新原型和工作墙
成果
Knowsy的案例证明了精益用户体验的成功。我们的应用在苹果应用商店如期上线。后续，我又被邀请去做一些它的其他版本产品。那一轮，我用了一个类似的流程。因为我工作地点比较远，开发团队不能很好配合，所以我不得不制作一些相对更重的产出物。虽然如此，我们不断以更高的保真度来迭代的基本原理仍然被延续。
保持团队动力是管理的最大障碍之一。设计师已经习惯了设计评审。但不幸的是，每天的计划安排还是有。产品的所有者，股东，CEO以及客户都想知道事情的进展如何。他们都想保佑项目按着计划继续前进。对专注结果的团队来说这是一种挑战，因为只能依赖已知的知识来制定计划。为了确保有足够时间来应变，往往典型的一次计划只是安排整批工作的一小部分。团队计划最多只是超前一或两个迭代版本。这种感知“短视”，往往不能满足大多数高级管理者。那你如何完成每天既定工作，同时又继续保持精益用户体验和Scrum的步伐？
两个词：积极主动，沟通交流
我曾管理过一个团队，从根本上改变了一个现有产品的工作流，那个产品有数以千计的支付用户。我们为这种改变兴奋不已，所以继续向前推进，但没有提醒组织中的其他任何人。当新产品上线1小时后，客服副总裁来到我的桌前，向我发烟并询问为什么这个变化没有告诉她。原来是因为：一旦客户对产品有疑问，他们会打电话给客服寻求帮助。呼叫中心在产品中写脚本来帮助寻找客户遇到的问题并提供解决方案。但是，新上线的产品里没有这个脚本，因为他们根本不知道，我们所做的改变是什么，还将有怎样的改变。
我们诚挚地赔礼道歉。作为一个宝贵的教训，它告诉我们，如果你想让你的利益相关者，管理你但又不碍着你，请确保他们知道你的计划。这里有一些小贴士：
主动向你的产品所有者和经营者展示你的产品。
让他们知道：
——项目进展如何
——目前你做过哪些尝试并做了哪些优化
——你接下来要尝试什么
对产出物保持探讨（你怎样向着目标探索）而不是现有特性。
确保支持部分（客服、市场营销、运维等）都了解到即将到来的变化，以便他们在工作中做出相应调整。
如果又比要，请给他们提供充裕的时间来调整工作。
本章详细探讨了如何在Scrum过程中融入精益用户体验。此外，还谈到了跨职能合作让团队保持敏捷轻快地前进，以及如何应对那些烦人的总想知道进度、计划的股东和管理者。我讨论了，为何参与是如此的至关重要，为什么交叉周期模型只是真正敏捷方式的过渡型态。
在下一章，也就是最后一章，我们将一起来看一看，推动精益用户体验，应该做哪些组织上的转变。这一章，可以引发管理者对一个成功团队如何配置方面的思考。
本文翻译自 "LEAN UX" Chapter 7“Integrating Lean UX and Agile”感谢作者。
评论