2001年，許多公司的軟件團隊陷入不斷增長的流程困境，為了解決這個問題，這個領域中最優秀的experts一起概括出了一些全新的價值觀和原則，從而可以讓軟件開發團隊具有快速工作、響應變化能力，他們自稱為敏捷聯盟。敏捷開發過程的方法很多，包括Scrum, eXtreme Programming, Feature Driven Development, Adaptive Software Development等等。目前，我所在的公司內部也有很多團隊開始啟用Scrum的開發流程，力圖改變瀑布式開發模型的諸多弊端。作為Run了3年該流程的team，我們團隊在不斷學習和總結中得到了進步，我也希望可以從設計的角度來分享一些敏捷開發流程中快速迭代設計的心得。
Process 流程
這是一個高速變化的時代，無論是產品的更新還是技術的進化，同時變幻莫測的需求對傳統軟件開發模式造成了極大的衝擊。當用戶需求不斷變化造成軟件開發目標的不斷更換，傳統的設計方式會舉步維艱，從而造成了軟件的滯後，總是無法貼近用戶的實時需求。快速迭代設計的特點是：先設計出稿，再不斷改進。白鴉在2011中國交互設計體驗日上分享到：“怎麼做都是錯的。唯有迭代的速度，才能取勝。” 可見，快速迭代的要求，無論是對研發還是設計，都已迫在眉睫。
整個快速迭代設計流程分為5個階段：
* Iteration-1
前期準備階段，團隊很容易就各類需求該放哪些進入Sprint backlog發生討論，設計師主要參與PO(Product Owner)/PM組織的用戶需求討論，對需求優先級排序，解讀一些用戶潛在需求並轉化成為產品功能需求，畢竟相比他們，設計師更加懂得產品細節。同時，設計師可以同步展開用戶研究的工作，了解Persona的主要工作流和Goal。
* Iteration 0
與每個項目開始之前設定Sprint 0相同，Sprint裡也有一個叫Iteration 0的階段，包括設計開工之前的驗證與出具設計方案。通過與開發團隊的溝通來驗證設計方向與設計方案的可行性，可以創建一些信息流圖與內容結構，做好堅實的設計架構。同時，在用戶需求被解讀成為功能列表後，利用紙片、PPT、Balsamiq等工具創建快速原型，最好在這個階段讓研發團隊介入，對設計原型進行評估。然後設計師根據快速原型，負責設計其實現方式，通常會有幾個解決方案。在Scrum團隊內部與開發測試人員反复討論權衡後，選出最優方案。這個階段設計師的交付物為交互線框圖、低保真模型等簡單設計文檔。
* Iterations
設計不斷迭代的階段，因為我們假設改階段用戶需求已經確定，所以主要是基於設計方案的迭代，協同開發實現的進度，將設計不斷修正至最優。正是這種快速的模式讓設計師能在一個可以體驗的原型上驗證設計，從而改進設計。與流行的測試驅動開發（TDD）類似，我們也可以採用測試驅動設計（Test Driven Design,詳見http://www.agiledata.org/essays/tdd.html）的方式。 QA要對用戶的背景和工作模式比較熟悉，協同設計師一起敲定User Story，撰寫Real User Test Scenarios，並根據測試結果優化設計。設計師與開發團隊成員一併進行Usability Testing，以便在早期消除可用性缺陷，減輕後期維護成本。
* Release
作為design release的階段，前面的工作主要內容是確定功能的主要邏輯與工作流，這個時期，我們可以在優使性（Usability）上有所提升，做好Final Usability Testing，確認沒太大疏漏，再將其發佈出去。不同於QA的最終驗收測試，這裡的可用性測試需要從用戶的角度去“使用”產品，不是去找功能的缺陷，而是從優使性方面看是否順手，是否符合用戶心智模型，是否高效完成用戶目標。
* Production
設計發布過後，為了適應不斷更新和快速迭代的需要，設計師在這個時期的工作重心從偏用研設計轉移到偏運營維護的方面來，一方面收集一些用戶反饋和wishlist ，改進之前的不足；另外一方面為了產品的下一個迭代更新做好規劃，方便產品的發展和擴充。
整個流程有兩個迭代循環：
1.Requirements Iteration
這個迭代循環貫穿於整個敏捷設計流程。用戶需求隨著時間推移不斷更新，整個設計流程的迭代。根據以用戶為中心的設計思想，當用戶的需求發生變化時，在設計流程中要及時響應，做出調整變化。
2.Solution Iteration
這個迭代循環主要指Iterations階段，用戶需求相對確定，設計方案的不斷優化更新。當需求基本確定後，設計師需要配合開發團隊不斷優化設計思路，提供更優的設計解決方案。
特別需要注意的是，前面兩個階段（Iteration -1, Iteration 0），應該早於當前研發的Sprint N一個週期（Sprint N-1）進行。進入當前的Sprint工作週期，完成第一個迭代設計後，研發團隊可以開始該部分內容的開發測試，與設計師不斷互動推動迭代。在Sprint N的末期，設計師完成當前Sprint的基本設計工作後，開始收集前面Sprints release內容的反饋。團隊不需要提前太多進行設計，要保持需求的最新update，主要依賴測試結果作為支撐，不斷持續改進優化設計，以便每次迭代結束後產出物都最適合當前迭代的需求。
Rules 原則
快速迭代設計的一些原則：
* 驗證可行性的必要
完美的敏捷思想是團隊中的每個人都是全才，大家都可以design，coding，testing。不過這樣的團隊不多，全才的混合有時候更容易造成管理混亂，相反，專才的合理搭配能產生更好的效果。所以，如果你不會寫代碼，一定要在設計早期拉上開發人員，坐在一起慢慢探討設計可行性，用代碼驗證原型之後，再確定方案。
* 測試用例驗證設計的重要性
根據測試驅動設計的理念，設計師與QA協同合作，利用早期測試結果驅動設計更新，比設計師長期獨自醞釀出的詳細設計文檔更有用。行不行，利用草圖或者低保真原型讓QA去測測看就知道。 Scrum鼓勵充分溝通與互動，這個時候QA的測試用例能發現很多設計缺陷和遺漏。 TDD如下圖所示：
* 注重團隊設計
與瀑布模型的單打獨鬥不同，快速迭代設計更推崇團隊設計，由設計師主導，把握設計框架，整個團隊給出解決方案。一些design scenario和workflow的歸納，即使經驗豐富的設計師，也不如團隊智慧來的全面，當然，除非你是喬幫主，使用導演中心論的設計流程。另外，團隊設計的好處還可以減輕設計師的負擔與壓力，一起承擔產品興亡的重任比一個人承擔要安全可靠的多。
* 設計不多不少，恰好就行
兵貴神速，指的就是以快為王。特別是在快速迭代設計中，你不必在你的原型或草圖中事無鉅細的列出所有可能，完美的概念在這裡是不適用的，甚至你不需要完成設計的整個部分，只要把關鍵模塊講清楚了，開發與測試理解了，就足夠。想想那些精美的設計文檔中無數看上去perfect的圖片和排版，最後真的有人在乎嗎？只要你在迭代開發流程中能於腦海中攫取所有細節並傳遞給團隊，不要文檔都可以。無需太具體，思考那些真正有價值的地方。
* 寫好User Story
User Story是在Agile開發流程中從用戶角度對系統的某個功能模塊進行的簡短描述，它包含了目標用戶(不同角色)、功能需要（可以做什麼）以及其創造的價值（實現目的）。它可以是：
1.一個用戶需求
2.產品功能的描述
3.用來計劃和追踪任務的工具
4.團隊溝通的橋樑
通常我們把一個User Story按照以下格式寫在即時貼上：
以第一個句型為例：
As a _ I would like _ so that _
作為（某個角色)，我希望可以（做什麼），以達到（什麼目的）
User Story照理應該是由PO寫，不過有些團隊（比如我們:D）是由設計師來完成，同時在即時貼上標註預估完成時間（我們團隊採用了Story Point這樣一種估算方法，這裡不贅述）和優先級別，以便開發團隊根據它們來形成Sprint Backlog。
* 任務量
不同的功能模塊其工作量也不盡相同，我們可以按以下三種類型劃分:
1. Large
一般來說每個User Story都需要在一個Sprint內完成，避免太大而跨越幾個Sprint。如果出現太大的User Story導致一個Sprint塞不下，則需要將User Story分解，這個Sprint完成一部分，但是不release，只是demo給PO/PM， 餘下的在接下來的Sprint裡完成。
2. Normal
按正常流程進行快速迭代設計。
3. Mini
JDI (Just Do It), 一些小功能的實現無需文檔，任何溝通方式都可以用來傳達你的設計思路，然後交由開發去實現。
* 關於文檔
原本瀑布開發模式下設計師的唯一交付物Specification，在快速迭代設計中已經不是那麼重要，因為快速變化的用戶需求讓設計節奏加速，不斷更新維護Specification成本太高。用戶是為你設計出的產品或者功能付款，而不是你的設計文檔，所以傳遞設計思想才是主要目的，PPT、Visio等Wireframe或者email、meeting notes等記錄都可以作為設計參照。
對於文檔，我們一般遵循如下原則：
-盡可能在文檔中簡單的描述需求、分析結果、信息架構和設計細節，只要它們恰好滿足PO的要求即可。
-如果該Scenario的邏輯足夠複雜，那麼請毫不猶豫的用文檔詳細的描述，以開發團隊恰好能充分理解為宜。
-文檔的簡繁程度需要經過幾個Sprint的迭代，才能找到最合適的level。
* 保持一直設計
設計對產品來說如此重要，特別是在敏捷開發流程中，沒有一個專門的設計階段(There is no design phase)，整個流程都伴隨的設計。從前期紙片概念，白板框架，用戶場景測試，到具體細節代碼實現，終極用戶測試，都離不開設計的跟隨。這不再是那個只需要在早期完成設計就棄之不管的模式，他要求你每天都不停的參加討論參入迭代參與設計。
Epilogue 後記
我們團隊面對的是一款由公司早期元老打造的工程領域軟件，它的用戶基數龐大，它的地位曾經顯赫。然而它的功能逐漸老化，模塊架構也相對固化，開發團隊很難對整個系統進行改動，因為整個軟件架構已經固定，任何大的改動都是牽一發而動全身，不但會造成許多與改動處無關的環節出現問題，莫名其妙的regression defect也讓QA措手不及。一些設計改進都必須得在之前設計的基礎上進行調整，力求一致性，很難加入全新的交互模式和UI風格。同時，正是由於產品功能沒有大幅度的更新，瀑布模式比較擅長的低風險複雜功能開發已經無法滿足用戶需求的小快靈。因此，我們目前所使用的敏捷設計流程儘管無法跟全新開發的產品一樣自由，只是在大框架的製約下進行功能的迭代更新，但也取得了不錯的效果，3年做下來完成了許多小功能的快速成功發布，提升了大家對於Scrum流程繼續使用的信心，致力於建立一個持續的可改進的快速響應團隊。本文所提及的流程並不適用所有情況，希望大家各取所需，保留對自己有價值的部分，摒棄不適合的。
參考：
http://www.agilemodeling.com/
來源：http://dedicky.wordpress.com
特別注意：本站所有轉載文章言論不代表本站觀點，本站所提供的攝影照片，插畫，設計作品，如需使用，請與原作者聯繫，文章轉自alibuybuy