导语：经常听到程序猿大大们说敏捷开发，也看到越来越多的国外设计师和开发人员的blog里频频提到agile workflow，相比于传统的waterfall workflow，短平快的Agile团队协作方法可能更加高效。

原文地址：http://webdesign.tutsplus.com/articles/a-designers-introduction-to-agile-methodology--cms-23349

编译：飞呀(hh就是我自己）

转载请注明原文出处和译者链接。

"Agile"（敏捷）对于没有参与过软件开发的设计师们来说是个有点诡异的专有名词。雇主和招聘者们频频用到这个词，那么Agile到底是什么？以我作为业内人士的视角，以下是我觉得设计师们在此领域应该了解的知识。

这并不是一份关于“敏捷开发”（agile）或称“并行开发”（scrum)的完全指南，但如果你正打算去一家以产品或者软件开发为主的公司应聘，这篇文章或许可以给你提个醒。

我会聊聊它是什么，它是如何运作的，包括其它一些术语，比如“产品需求待办列表”（product backlog)、"一次迭代待办列表“（sprint backlog）、每日例会，以及潜在的可输出产品增额的概念(potential shippable product increments)。

What-我们到底在聊什么？

“Agile"起源于2001年，当时一小群软件开发者认为他们需要一种新的工作流程。他们构想出12条准则，并总结成一份宣言。它描述了一种流程，一套方法论。

敏捷开发

以下图表展示了一个典型的敏捷开发流程，包含了一系列小的迭代周期。

在“敏捷开发”的定义范畴中有一些更精确的分支，其中一种（也许是最受欢迎的一种）就是“scrum"(译者注：本义为英式橄榄球中的并列争球行为）。想要了解更多关于Scrum的详情，可以访问scrummethodology.com.

不论哪种，“敏捷开发”必然包含了迭代的、不断增进的周期型工作。理解它的最好方法就是先看看与之反向对应的"瀑布流式"（Waterfall)协作方法。

瀑布流

“瀑布流”是产品开发领域里一种相对传统的协作模式。它是按照次序逐一执行的，无疑也相对僵化和低效一些。

敏捷开发有许多优点（相较于瀑布流式开发方式），比如它的最终成品可以更早地投向市场，更适于团队协作，需要不断增加投资。从另一方面来说，它灵活的特点也让利益相关者们更加紧张。这也是常被误解的一点。

How-“敏捷开发”是怎么运作的？

Let’s see how an agile workflow looks in a practical design situation.

让我们来看看在实际的设计工作中敏捷开发工作流是什么样子的。

产品需求待办列表

上图就是一个产品需求待办列表，它列举了所有可能会出现在最终产品里的功能特性。这些特性是基于用户需求的，并转化成一些盈利点。每个特性/功能被单独写在一张索引卡片上，并且是依据语义构造的，通常是从设定好的人物角色（persona）的视角，以特定的方式保持一致性和清晰度。例如“作为Bob，我能……于是可以……”

冲刺期（一个迭代周期）待办列表

作为设计师，你需要估算每张卡片上的特性需要多长时间来完成?？⑷嗽币残枰龈龉浪?。那只是个估计——第一次迭代期过去之后，你将会更好地估计完成某个任务需要花多久。总的来说，每个特性会被标上一个标记，类似于T恤衫尺码（XL,L,M,S),许多不同的尺码会被放进这一个周期内。

和“产品需求待办列表”一样，这里也会有许多其它的小版块，例如当前迭代周期（current sprint)、在评判中的（in review）、被屏蔽的（blocked）等等。它会被张贴在一个叫做“Kanban墙”的东西上（Kanban在日语中表示布告板的意思）：把所有的索引卡片贴出来，从视觉上便于看见全局，涵盖所有的需求。当然，你也可以使用在线工具（比如Trello，见下图）来达到同样的效果。

每日scrum例会

每日scrum例会实际上很像“起立/预备”。在我的经历中，团队里的每个人已经了解了你和他们自己在做什么。晨会是个很好的机会，互相简单地聊一下，并为将要开始的一天设定方向。

潜在的可输出产品增额

理论上，每个迭代周期之后，你应该可以输出“可实现的增额”。这个名词可广泛应用于很多产业，然而实际上很难实现。它实际上是作为“产品的一部分”，可以提高或增加产品的功能性。

作为设计师你应该知道什么？

与用户界面产品协同

尽管敏捷开发方法论是植根于软件工程的，但它对于网站和APP也同样有效。举例来说，你可能会从之前创建的一个用户角色设定（user persona)开始，梳理出你的目标用户的需求，然后再依次细化并确定出需要的功能特性。

培养精确估算的能力

你需要和产品经理或者负责项目进度的scrum专家合作(取决于你所在的公司）。他们会要求你尽可能准确地预估需要花费的时间。你会想要乐观估计，但最终还是要现实——并没有人会以此反对你。

高度协作

敏捷开发流程最大的优点就是它是一个高度协作的工作方式。如果按照传统的瀑布流式工作方法，你可能把设计稿交给开发人员，然后就再也见不到它了。但是在这种不断迭代的工作流程里，你会坐在开发人员身边，协同完成每一次迭代。

结论

作为一个设计师，如何从自由设计师的状态过渡到在一个大公司里与多个团队合作，尤其是在敏捷开发项目中，这会是一次巨大的飞跃。以我的经验来说，这是一个很实用的工作框架，它的一些原则甚至可以被用于你自己的项目。理解团队合作的方式，并学会估算会使你在设计团队中更有效地工作。

还有一篇文章也很不错Doing UX in an Agile World: Case Study Findings

第一篇关于UX的翻译，争取每周一篇不拖延，对自己是个梳理，也希望有人能觉得它有用，词不达意之处欢迎指正。