導(dǎo)語(yǔ)：經(jīng)常聽(tīng)到程序猿大大們說(shuō)敏捷開(kāi)發(fā)，也看到越來(lái)越多的國(guó)外設(shè)計(jì)師和開(kāi)發(fā)人員的blog里頻頻提到agile workflow，相比于傳統(tǒng)的waterfall workflow，短平快的Agile團(tuán)隊(duì)協(xié)作方法可能更加高效。
原文地址：http://webdesign.tutsplus.com/articles/a-designers-introduction-to-agile-methodology--cms-23349
編譯：飛呀(hh就是我自己）
轉(zhuǎn)載請(qǐng)注明原文出處和譯者鏈接。
"Agile"（敏捷）對(duì)于沒(méi)有參與過(guò)軟件開(kāi)發(fā)的設(shè)計(jì)師們來(lái)說(shuō)是個(gè)有點(diǎn)詭異的專(zhuān)有名詞。雇主和招聘者們頻頻用到這個(gè)詞，那么Agile到底是什么？以我作為業(yè)內(nèi)人士的視角，以下是我覺(jué)得設(shè)計(jì)師們?cè)诖祟I(lǐng)域應(yīng)該了解的知識(shí)。
這并不是一份關(guān)于“敏捷開(kāi)發(fā)”（agile）或稱(chēng)“并行開(kāi)發(fā)”（scrum)的完全指南，但如果你正打算去一家以產(chǎn)品或者軟件開(kāi)發(fā)為主的公司應(yīng)聘，這篇文章或許可以給你提個(gè)醒。
我會(huì)聊聊它是什么，它是如何運(yùn)作的，包括其它一些術(shù)語(yǔ)，比如“產(chǎn)品需求待辦列表”（product backlog)、"一次迭代待辦列表“（sprint backlog）、每日例會(huì)，以及潛在的可輸出產(chǎn)品增額的概念(potential shippable product increments)。
What-我們到底在聊什么？
“Agile"起源于2001年，當(dāng)時(shí)一小群軟件開(kāi)發(fā)者認(rèn)為他們需要一種新的工作流程。他們構(gòu)想出12條準(zhǔn)則，并總結(jié)成一份宣言。它描述了一種流程，一套方法論。
敏捷開(kāi)發(fā)
以下圖表展示了一個(gè)典型的敏捷開(kāi)發(fā)流程，包含了一系列小的迭代周期。
在“敏捷開(kāi)發(fā)”的定義范疇中有一些更精確的分支，其中一種（也許是最受歡迎的一種）就是“scrum"(譯者注：本義為英式橄欖球中的并列爭(zhēng)球行為）。想要了解更多關(guān)于Scrum的詳情，可以訪問(wèn)scrummethodology.com.
不論哪種，“敏捷開(kāi)發(fā)”必然包含了迭代的、不斷增進(jìn)的周期型工作。理解它的最好方法就是先看看與之反向?qū)?yīng)的"瀑布流式"（Waterfall)協(xié)作方法。
瀑布流
“瀑布流”是產(chǎn)品開(kāi)發(fā)領(lǐng)域里一種相對(duì)傳統(tǒng)的協(xié)作模式。它是按照次序逐一執(zhí)行的，無(wú)疑也相對(duì)僵化和低效一些。
敏捷開(kāi)發(fā)有許多優(yōu)點(diǎn)（相較于瀑布流式開(kāi)發(fā)方式），比如它的最終成品可以更早地投向市場(chǎng)，更適于團(tuán)隊(duì)協(xié)作，需要不斷增加投資。從另一方面來(lái)說(shuō)，它靈活的特點(diǎn)也讓利益相關(guān)者們更加緊張。這也是常被誤解的一點(diǎn)。
How-“敏捷開(kāi)發(fā)”是怎么運(yùn)作的？
Let’s see how an agile workflow looks in a practical design situation.
讓我們來(lái)看看在實(shí)際的設(shè)計(jì)工作中敏捷開(kāi)發(fā)工作流是什么樣子的。
產(chǎn)品需求待辦列表
上圖就是一個(gè)產(chǎn)品需求待辦列表，它列舉了所有可能會(huì)出現(xiàn)在最終產(chǎn)品里的功能特性。這些特性是基于用戶(hù)需求的，并轉(zhuǎn)化成一些盈利點(diǎn)。每個(gè)特性/功能被單獨(dú)寫(xiě)在一張索引卡片上，并且是依據(jù)語(yǔ)義構(gòu)造的，通常是從設(shè)定好的人物角色（persona）的視角，以特定的方式保持一致性和清晰度。例如“作為Bob，我能……于是可以……”
沖刺期（一個(gè)迭代周期）待辦列表
作為設(shè)計(jì)師，你需要估算每張卡片上的特性需要多長(zhǎng)時(shí)間來(lái)完成。開(kāi)發(fā)人員也需要做個(gè)估算。那只是個(gè)估計(jì)——第一次迭代期過(guò)去之后，你將會(huì)更好地估計(jì)完成某個(gè)任務(wù)需要花多久?？偟膩?lái)說(shuō)，每個(gè)特性會(huì)被標(biāo)上一個(gè)標(biāo)記，類(lèi)似于T恤衫尺碼（XL,L,M,S),許多不同的尺碼會(huì)被放進(jìn)這一個(gè)周期內(nèi)。
和“產(chǎn)品需求待辦列表”一樣，這里也會(huì)有許多其它的小版塊，例如當(dāng)前迭代周期（current sprint)、在評(píng)判中的（in review）、被屏蔽的（blocked）等等。它會(huì)被張貼在一個(gè)叫做“Kanban墻”的東西上（Kanban在日語(yǔ)中表示布告板的意思）：把所有的索引卡片貼出來(lái)，從視覺(jué)上便于看見(jiàn)全局，涵蓋所有的需求。當(dāng)然，你也可以使用在線工具（比如Trello，見(jiàn)下圖）來(lái)達(dá)到同樣的效果。
每日scrum例會(huì)
每日scrum例會(huì)實(shí)際上很像“起立/預(yù)備”。在我的經(jīng)歷中，團(tuán)隊(duì)里的每個(gè)人已經(jīng)了解了你和他們自己在做什么。晨會(huì)是個(gè)很好的機(jī)會(huì)，互相簡(jiǎn)單地聊一下，并為將要開(kāi)始的一天設(shè)定方向。
潛在的可輸出產(chǎn)品增額
理論上，每個(gè)迭代周期之后，你應(yīng)該可以輸出“可實(shí)現(xiàn)的增額”。這個(gè)名詞可廣泛應(yīng)用于很多產(chǎn)業(yè)，然而實(shí)際上很難實(shí)現(xiàn)。它實(shí)際上是作為“產(chǎn)品的一部分”，可以提高或增加產(chǎn)品的功能性。
作為設(shè)計(jì)師你應(yīng)該知道什么？
與用戶(hù)界面產(chǎn)品協(xié)同
盡管敏捷開(kāi)發(fā)方法論是植根于軟件工程的，但它對(duì)于網(wǎng)站和APP也同樣有效。舉例來(lái)說(shuō)，你可能會(huì)從之前創(chuàng)建的一個(gè)用戶(hù)角色設(shè)定（user persona)開(kāi)始，梳理出你的目標(biāo)用戶(hù)的需求，然后再依次細(xì)化并確定出需要的功能特性。
培養(yǎng)精確估算的能力
你需要和產(chǎn)品經(jīng)理或者負(fù)責(zé)項(xiàng)目進(jìn)度的scrum專(zhuān)家合作(取決于你所在的公司）。他們會(huì)要求你盡可能準(zhǔn)確地預(yù)估需要花費(fèi)的時(shí)間。你會(huì)想要樂(lè)觀估計(jì)，但最終還是要現(xiàn)實(shí)——并沒(méi)有人會(huì)以此反對(duì)你。
高度協(xié)作
敏捷開(kāi)發(fā)流程最大的優(yōu)點(diǎn)就是它是一個(gè)高度協(xié)作的工作方式。如果按照傳統(tǒng)的瀑布流式工作方法，你可能把設(shè)計(jì)稿交給開(kāi)發(fā)人員，然后就再也見(jiàn)不到它了。但是在這種不斷迭代的工作流程里，你會(huì)坐在開(kāi)發(fā)人員身邊，協(xié)同完成每一次迭代。
結(jié)論
作為一個(gè)設(shè)計(jì)師，如何從自由設(shè)計(jì)師的狀態(tài)過(guò)渡到在一個(gè)大公司里與多個(gè)團(tuán)隊(duì)合作，尤其是在敏捷開(kāi)發(fā)項(xiàng)目中，這會(huì)是一次巨大的飛躍。以我的經(jīng)驗(yàn)來(lái)說(shuō)，這是一個(gè)很實(shí)用的工作框架，它的一些原則甚至可以被用于你自己的項(xiàng)目。理解團(tuán)隊(duì)合作的方式，并學(xué)會(huì)估算會(huì)使你在設(shè)計(jì)團(tuán)隊(duì)中更有效地工作。
還有一篇文章也很不錯(cuò)Doing UX in an Agile World: Case Study Findings
第一篇關(guān)于UX的翻譯，爭(zhēng)取每周一篇不拖延，對(duì)自己是個(gè)梳理，也希望有人能覺(jué)得它有用，詞不達(dá)意之處歡迎指正。
