如果作为设计师的你已经下定决心，要加入一个真正的产品团队，那么懂一点技术相关的知识绝对是加分项！不如今天就从最基础的开发模式起步吧。

“敏捷开发”（agile）是一个行业专用术语，它常常出现在雇主和招聘人员口中。而对没有在软件工程领域工作过的设计师来说，恐怕很难理解这到底是什么意思。所以有意往软件工程领域发展的设计师，你可能需要了解什么是敏捷开发。作为一个网页设计师，下面分享下我眼中的“敏捷”设计方法。

这不是一篇全面的设计指南，也不是什么关于“scrum”或“agile”的不二真理，但如果你正在准备参加一个互联网产品或软件的面试，本文可以帮你建立一些基本的认知。

我会就“敏捷开发”是什么、如何运作来做介绍，当然也包括其他相关术语，如“产品需求池”、“迭代需求列表”、“每日Scrum Meeting”以及“潜在可交付产品增量”等概念。

当我们谈论“敏捷开发”时，我们在谈什么？

在2001年的一次软件开发者的团体讨论中，“敏捷开发（Agile）”一词首次出现。他们一致认同需要一种全新的工作流程，并为此设立了12条原则，将之整合为一份宣言。

这份关于敏捷开发的宣言描述了一种工作流程、一种方法论。

敏捷开发

敏捷开发的定义中包含了其他更细分的方法，其中大概最热门的就是“scrum”了。Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。迭代是指把一个复杂且开发周期很长的开发任务，分解为很多小周期可完成的任务，这样的一个周期就是一次迭代的过程；同时每一次迭代都可以生产或开发出一个可以交付的软件产品。

不管在什么案例中，敏捷开发的方法都意味着迭代式、周期性的开发工作。把它和“瀑布流”式方法对比着看，会更有助于理解。

瀑布流式开发

对产品开发来说，瀑布流是一种更传统的方式。它意味着整个开发过程必须是连续性的，也因此更严格、死板，甚至更低效。

与瀑布流相比，敏捷开发的好处就在于它的最终产品能更快地对接市场，需要更多团队协作和增量投资。另一方面，因为它的灵活可变，它常常使利益相关者感到紧张，也常常被误解。
它是如何工作的？

现在让我们看一下在实际设计场景下，敏捷开发流程(agile workflow)到底是怎样的吧。

产品需求池（Product Backlog）

迭代需求列表 （Sprint Backlog）

对于每一张功能卡片，设计师和开发者都需要预估各自完成时间，并给出相关排期——而这只是一个估计值。在第一个“迭代（sprint）”完成后，对下一个“迭代”所需花费的时间，你会更加心中有数。通常来讲，在一次”迭代“中，每一张功能卡片都会按优先级被给予一个“T恤尺寸”（XL, L, M, S)，而它们各式各样。

一般来讲，迭代需求列表，除了项目需求还有状态显示，例如“迭代前”、“评审中”、“项目受阻”等。这些卡片被张贴在Kanban墙上（Kanban在日语中写作“看板”），从而将所有功能开发进展“可视化”。当然你也可以用网上的工具来实现类似的目的，比如Tower、Teambition等。

每日Scrum Meeting

每日Scrum Meeting类似于每日总结会。根据我的经验，组内的每一个人都清楚知道自己在做的事情，Scrum Meeting使得大家在早上互相了解对方的相关情况，了解项目进度，为即将到来的一天设定工作方向。

潜在的可交付（Shippable）产品增量

在每一次需求迭代后，按理说你应该能够提交可交付的产品增量（shippable increments）。这个术语适用于很多领域，但理论上很难实现。它表示在功能上做出改进的产品部分。
作为设计师你应该知道的

与产品打交道

尽管敏捷开发来自软件工程领域，但该方法论对于网站和应用开发都非常有效。比如说，从你所创建的人物角色中，你可以勾勒出目标用户的需求，并基于此挖掘所需的功能点。

锻炼准确预估能力

你将需要与产品经理，或敏捷开发的高手合作（当然和谁合作取决于你在什么样的组织／公司）。通常他们负责确保事情按计划发展，因此会让你尽可能准确地进行预估完成时间。你将会发现你很容易做出过于乐观的预估，所以请现实一些吧 —— 没有人会记仇的。

高度协作

敏捷开发的一个最大好处，在于它是一种高度协作化的工作方式。例如，在传统的瀑布流式开发中，一般你把设计交给开发者后，你就再也见不到它们了。但在敏捷开发的迭代工作流程中，你会和程序员肩并肩坐在一起工作，完成每一次产品迭代。

结论

作为设计师，从自由工作者成为大公司的一员，与多个团队合作、参与敏捷迭代项目，这可以说是一个非常大的转变。根据我的经验，敏捷开发是一个很有效的工作模式，它的原则甚至可以应用到你的个人项目中。通过理解协作式的工作方式以及如何评估完成时间，你将会更加高效与设计团队协作。

本文来源于广州网站建设公司与广州网站设计制作公司-广帆互动广州公司！