為什麼UI/UX設計師也要學Agile？

Dec. 07 11:11~12:23

圖片來源在此。

 

Teddy的同事Erica在今年11月份去了上海參加「User Friendly 2013」會議（感謝HPX揪團團報），報名前Teddy提醒Erica：「參加這種會議，如果只去聽聽名人演講，就跟去拜拜一樣，大概只有心安的效果。要真的學到東西，就要多參加幾場workshop。過程一定會很累，但這樣才值得搭飛機跑這一趟。」

昨天下午簡短和Erica聊了她參加「Agile UX中的設計決策」這場workshop的經驗，講者是「熊子川」，ThoughtWorks首席設計師。講起ThoughtWorks這家公司，做軟體的人就會想到有名的Martin Fowler，他也是ThoughtWorks員工。

根據Erica轉述，這個workshop以往是三天的課程，但是當天他們只有三個小時的時間，所以整個過程非常的趕（迷之音：練了就九死一生，不練就十死不生）。快速聽完Erica對於「Agile UX中的設計決策」的說明，歸納幾個重點：

• 這個方法是一個end-to-end的過程：從「一句話的需求」開始，經過一連串發散、收斂的過程，建立起product backlog（產品功能列表）、規劃release plan、得到產出。用白話一點的說法，這是一個考慮到UX設計的敏捷開發流程。
• Requirement Workshop + Scrum：整個流程可以抽象化為兩大部分，用來尋找、釐清、確認需求的requirement workshop，以及用來執行實作的敏捷流程（看就來就是Scrum）。
• Requirement Workshop階段：採用 People-Context-Task (PCT，什麼人，在什麼情境之下，要完成什麼任務) 的方式來引導出「問題（Problem，為了完成任務，會遭遇什麼困難或是問題）」。然後將問題寫成問句，稱為「設計挑戰」，以此來引導出Epic Story。接著從Epic Story細分成Story （中間省略若干步驟 XD）。到這個階段，requirement workshop結束，產出product backlog以及「設計牆」（ 還有一個XX地圖的東西，名稱忘了…Orz），就可以做release plan。
• Scrum：有了product backlog，規劃好release plan，接下來的過程就和Scrum談的東西差不多，但該方法有加上UX設計師在Agile團隊中要如何和開發人員一起工作，看起來是參考了《Agile Experience Design》這本書的做法，Teddy在〈Scrum框架下的跨界開發(6):UX設計師是屬於哪一國的？〉曾經介紹過。

***

整個方法的框架類似Teddy之前談的〈Scrum框架下的跨界開發(7):扯這麼多，最後不就是需求與開發嘛!〉，但是針對requirement workshop階段要如何產出需求，Teddy之前熟悉的是物件導向分析與設計（OOAD）、Alexander的pattern方法、腦力激盪、快速原型驗證，以及後來學了一點design thinking與problem frame的皮毛。

ThoughtWorks的方法，整合了一些 design thinking、OOAD 、HCI/UX 的技巧，從流程的角度來看，這些步驟算是十分具體清楚，也滿足了許多「設計師」很喜歡畫圖、貼便利貼的要求。

整個requirement workshop階段的作法。Teddy覺得ThoughtWorks的方法還蠻不錯的，值得學習。

和Erica討論完畢之後突然想到前陣子Teddy幫忙審校的一本書：「精益度量」（簡體轉正體中文），作者也是在中國的ThoughtWorks服務。書中談到度量的方法其實都引用自其他現成的作法，但是ThoughtWorks有辦法把這一狗票方法放到Agile/Lean框架之下，整合與應用的很好，這一點真的是很不簡單（寫到這裡突然想到Alexander的Context、Form、Fitness的觀念）。

***

最後的心得就是，自己知道的東西要夠多、夠深入，就比較不會被一些看起來很酷炫的方法給嚇到「ㄔㄨㄚ、屎」，也比較能夠平心靜氣的吸收與欣賞別人方法的優點和限制。江湖上傳言：「有九陽神功護體，學什麼武功都特別快」，大概就是這個意思。

鄉民甲：我沒有九陽神功護體怎麼辦？

Teddy：很簡單，請報名參加「第八梯次Scrum敏捷方法實作班」。

***

友藏內心獨白：不需妄自菲薄也不可過於自大啊。