在“敏捷开发”的定义范畴中有一些更精确的分支，其中一种（也许是最受欢迎的一种）就是“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专家合作(取决于你所在的公司）。他们会要求你尽可能准确地预估需要花费的时间。你会想要乐观估计，但最终还是要现实——并没有人会以此反对你。

高度协作

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

结论

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

译文来自：http://www.jianshu.com/p/16bf4ed5558a#

编译： 飞呀

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