July 22 23:25 ~ July 23 00:47
前幾天在讀《Agile Experience Design: A Digital Designer's Guide to Agile, Lean, and Continuous》這本書，研究一下書中所建議UX設計師在敏捷團隊中扮演的角色，Teddy慢慢有點搞懂這些所謂Agile UX Designer（敏捷使用者經驗設計師）在想些什麼。簡單的說，最原始的Scrum團隊只包含三種角色：
- Product Owner：了解需求並且負責寫出需求、排定需求優先順序的人。
- Scrum Master：負責Scrum的精神有被團隊所遵循，並且協助團隊排除困難。
- Team (Developer)：由「跨職能成員」所組成的cross-functional team。
在大部分Scrum的書裡面，並沒有特別提到「使用者介面設計」或是「使用者經驗設計」這類的事情。概括地來講，如果鄉民們的團隊沒有所謂的「UX設計師」，那麼設計與實作出軟體系統的畫面、操作流程等等的工作，通常就直接落在開發人員（程式設計師或網頁設計師）身上。假設開發人員缺乏「如何設計出好用的軟體操作流程」的能力，那麼就會設計出「功能看起來OK，但是操作起來很難用」的系統。Teddy相信這種情況還是目前大多數軟體開發的模式---由開發人員來決定軟體操作流程。但是，近幾年因為Apple的崛起，尤其是App的市場所畫出的大餅，讓很多新興的團隊，或是出錢的老闆，慢慢有著「使用者經驗至上」的想法。也就是說，老闆或是主管們，動不動就把「使用者經驗」這幾個字放在口邊，好像只要「使用者經驗」搞好，就一定可以大撈一筆。
無論最後結果如何，「使用者經驗」被看重的確是一個事實，對軟體開發團隊來講，也是一件好事。慢慢地，有些團隊便配備有專屬或是與其他團隊共用的「使用者經驗設計師」。現在問題來了，要把「使用者經驗設計師」把在哪裡？
鄉民甲：這問題不是白問的嗎？既然Scrum說要組織cross-functional team，使用者經驗設計師當然是開發團隊的一員啊！
***
沒錯，一開始Teddy也是這樣想。但是，接下來更頭大的問題就接踵而來：
- UX設計師需要參加sprint planning meeting嗎？
- 如果要參加，UX設計師如何跟開發人員（程式設計師）一起出牌估算task的時數呢？畢竟這兩者的專長相差那麼多啊。
- 通常一個story開始施工的時候，UX設計師需要先設計操作流程。如果他們把和使用者介面設計相關的工作都做完，此時都沒有屬於他們可做的事那該怎麼辦？總不能要求他們去認領coding的工作吧。
- 相反地，如果其他人的工作都必須等UX設計師做完才可以開工，那其他人不也是沒事可做？
以上問題當然可以搬出Scrum的標準說法：
- 出牌有助溝通，就算將職能相差很多的人擺在相同的團隊中一起出牌形成大混戰的局面，估算活動還是有助於團隊溝通。
- 施工的問題可以透過各種不同形式的「配對」來慢慢克服，例如pair programming、pair design。
- 當UX設計師沒事做的時候，可以請他們去設計、寫或是執行自動化驗收測試。
以上答案看起來也很有道理，但是總覺得還少了些什麼。鄉民們你們說說看，還少了些什麼？
***
要回答上面這個問題，以及這一系列原本要討論的「跨界開發問題」，讓我們回頭思考一下軟體開發生命週期的每項活動。在所有的軟體開發活動中，「需求開發」是最早發生的一項活動。由於Scrum只是一個框架，要求只要product backlog裡面有足夠的story就可以開工了。至於這些story是怎麼被生出來的，Scrum很 不負責任 簡單的就一句話：「此為Product Owner的責任，請找他」。
假設鄉民們要開發一個「管理體重app」，其中有一個story長成這樣：
身為使用者，我每天都可以輸入當日的體重，以便後續可以追蹤與管理我的瘦身成果。
以上是一個很典型的story，要在手機上輸入體重這也不是什麼難事。但是，如果這個app的「使用者經驗」設計得很爛，那麼這樣的app就幾乎不可能成功。
現在問題來了，在sprint planning meeting中，Product Owner在跟開發人員說明了這個story之後：
開發人員：請問使用者要如何輸入體重？操作介面要如何設計？
Product Owner：嗯，這我也不確定耶。你們有沒有什麼想法？
***
開發人員：需求是你PO的責任啊，啊你需求都沒有講清楚，我們是要怎麼估算story大小與切割task啊？
Product Owner內心獨白：我只負責提需求，怎麼做你們工程師要告訴我solution啊。
***
那到底「軟體操作流程」或是用有學問一點的講法「使用者經驗設計」是屬於「需求」還是「solution」的範圍呢？這個問題的答案將決定UX設計師被擺在哪個腳色，以及如何透過Scrum的框架達成跨界合作的目的。
回答這個問題之前，Teddy想到10幾年前，當時Teddy剛開始學著用use case來撰寫需求。那時候OOAD的書都一再強調：需求應該要和使用者介面分開，也就是說不要在需求中描述使用者介面的設計或是細節。至於為什麼書上要如此建議在此Teddy就不多做解釋，但是在Teddy實際將寫好的use case解釋給客戶聽的時候，Teddy總是會搭配用VB畫出的「假畫面」。而且Teddy發現一邊念著use case，一邊看著畫面，對使用者來講是非常有效果的一種溝通方式（本篇文章最前面的那張圖就是Teddy在1998年用VB所畫出的洗衣店進銷存系統假畫面，當年客戶還問Teddy這種方法是去那裡學來的XD）。在這樣的互動過程中，基本上Teddy就扮演著「使用者經驗設計」的工作。
好，所以UX設計是需求開發的一部份。但是，到了實作階段難道就沒UX設計師的事了嗎？當然不是，UX設計師可以搭配PO一起耕耘product backlog裡面的story，但是在實作階段也必須要與開發人員緊密的互動，以便快速修正UX設計（有些UX設計可能有實作上的困難或是因為時間與資源的因素需要加以調整）。
上述所說的責任，便是《Agile Experience Design: A Digital Designer's Guide to Agile, Lean, and Continuous》這本書中所建議的：
PO與UX設計師在sprint N-1的時候，一起合作將sprint N所需要的story與操作流程先設計出來，然後在sprint N時，UX設計師一方面協助開發人員把story實做出來，另一方面繼續與PO開發sprint N+1的story內容。
***
總之，《Agile Experience Design: A Digital Designer's Guide to Agile, Lean, and Continuous》所提到的跨界合作，大致上的想法可以簡化成Teddy上述所說的那一句話。這樣的模式和Jonathan上次在ezScrum系列講座中所分享的跨界合作模式也很像（這一點是Teddy個人的解讀啦XD）。
***
友藏內心獨白：流程是死的，人是活的，要活用流程不要被流程搞死。
沒有留言:
張貼留言