導語：經常聽到程序猿大大們說敏捷開發，也看到越來越多的國外設計師和開發人員的blog里頻頻提到agile workflow，相比于傳統的waterfall workflow，短平快的Agile團隊協作方法可能更加高效。

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

編譯：飛呀(hh就是我自己）

轉載請注明原文出處和譯者鏈接。

"Agile"（敏捷）對于沒有參與過軟件開發的設計師們來說是個有點詭異的專有名詞。雇主和招聘者們頻頻用到這個詞，那么Agile到底是什么？以我作為業內人士的視角，以下是我覺得設計師們在此領域應該了解的知識。

這并不是一份關于“敏捷開發”（agile）或稱“并行開發”（scrum)的完全指南，但如果你正打算去一家以產品或者軟件開發為主的公司應聘，這篇文章或許可以給你提個醒。

我會聊聊它是什么，它是如何運作的，包括其它一些術語，比如“產品需求待辦列表”（product backlog)、"一次迭代待辦列表“（sprint backlog）、每日例會，以及潛在的可輸出產品增額的概念(potential shippable product increments)。

What-我們到底在聊什么？

“Agile"起源于2001年，當時一小群軟件開發者認為他們需要一種新的工作流程。他們構想出12條準則，并總結成一份宣言。它描述了一種流程，一套方法論。

敏捷開發

以下圖表展示了一個典型的敏捷開發流程，包含了一系列小的迭代周期。

在“敏捷開發”的定義范疇中有一些更精確的分支，其中一種（也許是最受歡迎的一種）就是“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專家合作(取決于你所在的公司）。他們會要求你盡可能準確地預估需要花費的時間。你會想要樂觀估計，但最終還是要現實——并沒有人會以此反對你。

高度協作

敏捷開發流程最大的優點就是它是一個高度協作的工作方式。如果按照傳統的瀑布流式工作方法，你可能把設計稿交給開發人員，然后就再也見不到它了。但是在這種不斷迭代的工作流程里，你會坐在開發人員身邊，協同完成每一次迭代。

結論

作為一個設計師，如何從自由設計師的狀態過渡到在一個大公司里與多個團隊合作，尤其是在敏捷開發項目中，這會是一次巨大的飛躍。以我的經驗來說，這是一個很實用的工作框架，它的一些原則甚至可以被用于你自己的項目。理解團隊合作的方式，并學會估算會使你在設計團隊中更有效地工作。

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

第一篇關于UX的翻譯，爭取每周一篇不拖延，對自己是個梳理，也希望有人能覺得它有用，詞不達意之處歡迎指正。