敏捷式開發(Agile)、瀑布式開發(Waterfall) 、敏捷式UX、Lean UX。兜幾？
大家可能看掉標題都會覺得：到底是在工殺毀。
今天小編Wei要帶大家破解這些名詞，分享其中差別。
若大家有看過之前文章『產品原型製作工具(Prototyping Tools)使用分享』小編有稍微提到Agile Methodology和Waterfall Methodology的差異，今天要更深入探討一點。
敏捷式開發（Agile Methodology）
Agile是現在軟體產品開發的趨勢（當然根據產品性質會有許不同），顧名思義，就是敏捷、敏捷、敏捷！
根據定義，Agile的原則是減少浪費、產出迅速、不斷循環、快速學習。
實際使用上為例，Scrum是Agile Methodology相當著名的骨架，一般來說一個Scrum Team構成有產品經理、Scrum Master（主導Scrum的人，可能是project manager）、工程師和開發者。有可能以產品功能來做成主要任務，譬如說交友軟體的「這個軟體要讓我可以輕易看到所有配到的對象並做整理」(我朋友跟我說他想要的我不熟)，以這為例一般來說以兩週為單位（每個單位稱為Sprint）來做衝刺，每天早上團隊可能有每日會議（Stand up meeting）來更新隊友的狀況，衝刺完跟所有跟產品有關的人做報告。不斷迭代姓的循環、學習和調整。
並不是說敏捷式開發就是好的，有時候會因為衝刺到後面跟一開始的目標偏離，讓產品缺乏一致性，硬體產品也較不適用於此方法，畢竟硬體做出來就不能一直更改。
瀑布式開發(Waterfall)
瀑布式就比較不迭代式(Iteratvie)，像瀑布般從上往下：
產品需求 → 設計 → 開發 → 驗證 → 保養更新
開發時一般不會回去上一步驟，若有需要更改或是修正時較為困難，所以每一步驟都會非常小心仔細的產出。
這篇文章非常清楚指出何時較適合使用Agile或Waterfall
敏捷式UX(Agile UX)
使用者體驗設計師將UX設計流程置入Agile Methodology稱之為Agile UX。換言之，就是“嘗試”將User Experience Design的各種調研、方法置入軟體開發時的Sprint，根據產品開發的現狀調整調研和進行產品的優化和更改，所以每次的release都會漸行更新。好處就是不用像Waterfall那樣破壞性的一次做完所有設計，然後嚇死設計師。而不像傳統做UX可以長時間好好做研究，Agile UX常常會因為時間上的限制、缺乏高層的支持和資源而沒辦法做完整的調研，做折扣的調研(Discount Usability)可以解決部分的問題，因為所花時間和金錢較少。
使用者體驗設計師在Agile Methodology的環境下必須保持積極主動，在每個sprint開始前就要規劃好每個sprint要做什麼調研，避免被動式的發現產品缺乏什麼實在東補西補的將設計做出，另外同伴保持一致(就是每個Sprint都是一樣的人)、讓組上同伴都知道你在做什麼，有個固定的Srum Master等都是讓UX可以在Agile環境下運行順暢的撇步之一。
Nielsen Norman Group這篇文章詳細坦討案例和怎麼讓UX好好運行的方法。
而這篇文章也提供了如何在Agile哪個階段時行哪種使用者調研。
Lean UX
Inspired by Lean and Agile development theories, Lean UX is the practice of bringing the true nature of our work to light faster, with less emphasis on deliverables and greater focus on the actual experience being designed.
根據定義，Lean UX也是著重在不斷迭代式的設計，與Agile UX不同的地方是Lean UX著重在統整性的設計上面而不是產出，不管你的團隊是使用Agile還是Waterfall，Lean UX都可以應用在兩者的設計過程當中。
MVP(Minimum Viable Product)是Lean UX的精神，意思是在概念階段做出愈簡單的設計愈好，然後驗證出概念有沒有價值，有的話就可以在開發時以最節省成本時間的方法加入概念。MVP可以讓產品在早期時就驗證概念，減少投資者的風險。
以下是大致上的Lean UX的循環：
概念設計 → 設計產品原型 → 內部驗證 → 外部調研 → 學習調研所得 → 重複循環
Lean UX 著重在設計維持產品的統整性、商業模式和使用者的回饋，使用者體驗設計師要接觸各個和團隊的回饋，看清產品大方向的版圖，成為捍衛產品價值的守門員。
以下圖表指出Agile UX和Lean UX的差異
結論
使用者體驗設計師需要根據團隊的開發方式尋找最適合產品的使用者調研和設計方向，主動規劃和思考產品的假說、如何去驗證，更需要當維持團隊的橋樑，讓產品的使用者、工程師和有關的人都可以提供回饋，讓團隊的大家都為產品提供想法和心力。產品開發不只是需要設計師去設計產品的使用者介面和體驗，更需要所有人的熱情都灌注在產品上面！
-Wei
