这 10 个技术知识，让设计师更方便地与产品团队合作

2016-10-17 09:40:00

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

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

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

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

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

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

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

敏捷开发

下图演示了一个敏捷开发的典型过程，在一系列的“sprints”中完成。

（图1 敏捷开发迭代过程）

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

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

瀑布流式开发

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

（图2 瀑布流式产品开发过程）

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

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

产品需求池（Product Backlog）

（图3 产品需求池）

上图是一个产品需求池，它包含最终产品需要的所有功能。基于用户的需求，提炼产品功能点，并转化为一些相应收益。将每个功能列在一个单独的卡片上；为了保证功能描述的一致和清晰，通常从人物角色的角度出发，以一定语义结构描述某个功能点；举个例子：“作为Bob，我可以……以致于我可以……”

迭代需求列表（Sprint Backlog）

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

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