88%

敏捷开发对于过程控制更加精通，但紧迫的时间会迫使某些团队放弃用户研究，因此降低用户体验。

写在前面

产品的快速发展是程序员们喜闻乐见的，我们花费了很多年的时间用来研究怎样才能够最有效的系统化产品的敏捷方法和用户体验的研究方法，并通过这些方法来创造那些兼具可用性与时代性的产品。早期的调研支持开阔视野，所以现在我们主要投入少量研究深入收集信息，更好的提高用户体验，并快速发展。

我最近采访了八个敏捷团队的专业工作人员，采访他们的工作过程，采访他们的成功和失败。我交谈的对象包括用户体验设计师，开发人员，还有产品负责人。他们都在这样的环境中工作了至少两年时间。

一、敏捷是未来趋势

过去不可改变。与我交谈过的每个人都承认，敏捷开发的发展并不是一路顺畅，但是现在已经比刚开始的时候取得了很大的进步。在两年纪念的时候有人坦白，这个过程虽然不尽完美，但已经比过去好太多了——没有人想要再回到那个传统的阶段。

通常来说，敏捷团队的工作人员认为，这种小巧而灵敏的架构能够有效的促进过程的透明度。问题被快速确定，特点被快速总结。开发者和设计者花费好几个月的时间起动、工作，最后仅仅确定了问题的日子一去不复返了。这样的设置能够有效掌握各个阶段的发展，将最终惊喜最小化，开发人员能够更准确地预测时间。

“现在，我们用更聪明的方法工作，再也没有一天工作14个小时连续工作1个月的时候了。我们是一个团队，我们比过去有了更多的时间放松……自从我们以细小的组块而不是耗时9个月的巨大整体为工作对象后，预测进程变得更加容易了，每个人都能够清楚地看到接下来的发展。”Victor，软件工程师

“在使用这种敏捷团队的工作方式之前，产品的发展过程难以保持正轨。现在我们有更多的责任，事情也更加透明。”Anca，软件工程师

1、熟而后生巧

经过几年的尝试，敏捷团队已经掌握了的运作的要领。首先，成员们学会了设定和控制任务的时间，也学会了按照日程表来精准地执行工作；大家对于“规则”的理解和认同进入了一个新的阶段。比如每日的站立会议从过去的30分钟已经成功缩减到了15分钟。其次，现如今团队对于时间的估计更加准确。早期团队会设定查出冲刺时间范围的工作，但这在今天已经不是个大问题了，因为他们已经学会了如何合理地安排冲刺任务。

“问题已经逐渐消失了，人们正在逐渐适应这种有趣的新称呼和新活动。” Michelle，用户界面设计师

2、沟通是关键

某些团队成员认为，敏捷团队的最大优势在于能够有效地促进沟通。这种混搭的工作方式提供了跨职能的同伴，他们可以碰撞思想，分担责任，共同完善工作过程。

“小团队的最大优势是提供了一个公开的平台，它允许成员自由发表意见，进步，尝试不同事情。最初，我非常注意遵循规则，但是在我在不同的敏捷团队工作过之后，我了解到我必须为这些团队做出我自己的贡献——现在我们共享知识，分享理解。” Jeff，产品经理

“混搭的团队的价值在于沟通。不要让自己被规则打败，只要我们能做，我们都会去尝试。” Cathy，产品负责人

二、敏捷团队的挑战

对于很多人来说，敏捷团队的发展仍然是有风险的。得到公司层面的支持仍然是一场攻坚战争。团队成员必须努力工作，向怀疑论者显示出这样的团队的价值，来鼓励他们打破舒适的工作方式。

1、缺乏行政支持和资源

敏捷团队面临的第一个挑战是如何得到来自组织管理层的支持。我访谈过的许多人都讲述过他们受到的来自上层的挫折：没有上层支持，团队会被迫抄近路，损失工作效率，对于敏捷团队的误解，也会导致交流障碍和无逻辑的计划。缺乏管理层支持最终会体现在缺乏资源上。这些实践者同意敏捷和精益方法的优点，比如scrum开发过程。Scrum过程的每个部分都是完成产品开发必须的，一些成功的项目都是出现在各个成员统一了研究方法之后。然而，我采访的几乎所有人都没有按照标准流程走，或者被迫直接走捷径。主要的原因都是：缺乏资源。

“来自团队外股东的要求与团队迭代计划的冲突。” Julia，用户体验设计师

“我们不得不处理工作计划之外的事务。” Cathy，产品经理

“我们的小组正在积极迎接这种敏捷小团队，但是我们的组织却没有。我们有一些团队教练，但是这些教练却没有足够的能力说服高层管理人，他们还没有形成足够大的影响以此来拉拢管理层上船。” Mandy，高级管理层分析师

2、缺乏用户研究和可用性测试

敏捷团队的成员都同意用户研究的重要性。不幸的是，就算做，大多数小组也并没有将用户研究作为一项固定的基础工作，人们会把紧迫的截止日期和人手不足作为不能开展这些活动的原因。但是，忽略用户研究是一项极其冒险的行为。即使是最好的设计也只是设想，即使最优秀的设计师也有他的局限，用户研究可以帮助我们检验设想，减少认知偏见，防止被带入歧途。

“我们在强加的截止日期下工作，常常被迫放弃测试，而这对于用户体验研究来说并不是最优的选择。” Julia，用户体验设计师

“落实可用性测试真的不是一件简单的事情。我们的小组缺少人手，而且没有一个主要的领导者；我们曾经从市场部借调过相关人员，但是他对于我们的产品并不了解，或者根本不同意我们部门‘一切以用户为中心’的信条。” Julia，用户体验设计师

“我们没有时间来开展用户测试。” Victor，软件工程师

一个好的消息是一些用户体验研究方法比如说草图法、线框图法以及原型图法，已经得到了支持，设计师们被鼓励将创造低保真原型作为演示想法并且减少大量文档的方法。同时仍然存在的局限是许多组织并没有使用目标用户作为测试对象。

“我们尽量做到精益。我的老板鼓励我们不要使用线框图，而是使用手绘草图。这是一个转变。手绘草图能帮助我更好的理解我们的想法。” Julia，用户体验设计师

“我们比过去更加多的绘制直观的草图和模型，也更加多的关注未来的发展。” Mandy，高级程序分析师

注：88%原创编译文章，如需转载，请注明来源

英文原文：https://www.nngroup.com/articles/doing-ux-agile-world/