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


原文地址:

编译:飞呀(hh就是我自己)

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


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

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

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

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

What-我们到底在聊什么?

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

敏捷开发

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

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

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

瀑布流

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

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

永利电玩城 1

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

潜在的可输出产品增额

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

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

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

与用户界面产品协同

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

培养精确估算的能力

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

高度协作

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

结论

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


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

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

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

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

当我们谈论敏捷开发时,我们在谈什么?

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

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

敏捷开发

下图演示了一个敏捷开发的典型过程,在一系列的sprints中完成(不知道sprints是什么?点击查看《谷歌内部方法!快速做创新设计并验证的DESIGN
SPRINT》。

永利电玩城 2

(图1 敏捷开发迭代过程)

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

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

瀑布流式开发

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

永利电玩城 3

(图2 瀑布流式产品开发过程)

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

它是如何工作的?

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

产品需求池(Product Backlog)

发表评论

电子邮件地址不会被公开。 必填项已用*标注

相关文章