July 24 16:55~18:40
昨天討論到《UX設計師是屬於哪一國的？》，今天又花了點時間思考這個問題，最後得到一個結論：《Agile Experience Design》這本書基本上在討論的事情，可以簡化為不同角色的人，在敏捷方法中，如何遊走於「需求分析」與「系統開發」這兩個活動並且相互合作。最後Teddy畫出上面這張圖來代表這本書中所提到的跨界開發精神。
這張圖要怎麼解讀哩，如果沒有讀過《UX設計師是屬於哪一國的？》這一篇的鄉民們，請先跳過去看一下，接下來的說明才看得懂。在此先將軟體開發簡化為兩個主要的活動：
- 需求分析：所有的鄉民應該都要知道的一個概念，那就是需求是所有專案的「輸入端」。如果需求錯了，那後續的開發活動可能都會淪於做白工。在傳統的軟體工程領域中，其實有很多篇幅或是書籍都是在討論需求分析這一塊。但是，不知道為什麼，可能是因為敏捷方法倡導「將需求寫成story」，而且不需要寫出完整的產品需求就可以開工。此後大家對於敏捷方法注目的焦點，好像都落在流程或專案管理（例如Scrum），以及實務做法（例如Unit Test、TDD、BDD、Pair Programming、Continuous Integration、Continuous Delivery等等）這兩個領域，需求分析反倒是很少聽人在討論（迷之音：難道是沒有人來台灣開Certified Product Owner課程的緣故嗎XD）。但是，Teddy相信很多採用Scrum的團隊，應該對於需求分析感到很頭痛。在《Agile Experience Design》這本書裡面，主要流程還是以Scrum為主，所以PO還是需求（product backlog）的負責人。但是，PO並不是萬能的，因此上天派出兩位（兩種角色）小幫手來幫PO，分別是BA（Business Analyst，分析所謂企業流程的人）以及UX（使用者經驗設計師，或是廣義的說，使用者介面/經驗團隊）。
- 系統開發：有了需求（product backlog）之後，每個sprint就可以從product backlog挑出要施工的story出來實作。如果鄉民們有仔細看Teddy介紹Scrum的文章，應該會發現Scrum的活動大部分都著墨於開發這一端。Scrum的開發團隊是一個cross-functional team，所有的開發人員都放在這裡。傳統上開發人員指的是所謂的工程師，例如程式設計師、測試人員、持續整合工程師、建構管理工程師等等。
***
看到這邊應該沒什麼問題才對，接下來就是重點了。先考考鄉民們，請問Scrum那些活動是和需求分析有關的？有，Product Backlog Refinement Workshop（團隊每個sprint花費5%-10%的時間來整理product backlog）以及Sprint Review Meeting（因為透過demo可以產生需求的回饋路徑，請參考下圖）。Daily Scrum也可以算是有點相關。但是，如何獲得使用者真正需求的這件事情，其實在介紹Scrum的書籍探討的並不多，就算是《User Stories Applied》這類的書，主要還是在說明story要怎麼寫會比較好（有助於開發）。
雖然傳統的需求分析都會強調「使用者介面是一種實作，不需要急著在需求分析階段就早早決定」，但是對於「依靠使用者介面或是使用者經驗決生死」的應用而言（例如手機app），「使用者經驗」就變成「需求的一部分」。這個觀念很重要，請記下來。
***
接著解釋一下圖中黃色箭頭的意思。黃色箭頭的含意Teddy在《UX設計師是屬於哪一國的？》中已經說明過了，這邊在解釋一次：
在sprint 0的時候，PO與UX設計師（現在要再加上BA）專注撰寫與設計sprint 1所準備開發的story的內容與操作流程。而Developer則是準備日後的開發環境，例如設定版本控管系統、持續整合系統、安裝開發與測試環境等。當正式進入sprint 1之後，由於PO與UX設計師（加上BA）已經將這個sprint所準備實作的story的內容準備得很充分了，例如包含story的敘述、如何驗收每一個story、story的操作流程、甚至於畫面的prototype都畫好了。因此，在sprint planning meeting的時候，Developer便可比較容易的來估算story point以及每一個task所需的工時。在sprint進行時，PO與UX設計師（再加上BA）協助Developer完成該sprint的story。例如，如果Developer對於需求不清楚，或是對於原先UX設計師所設計的介面與操作流程有實作上的疑慮，隨時都可請求PO與UX設計師的協助。在此同時，當PO與UX設計時有空的時候，便一起規劃sprint 2的story。
***
最後說明圖中系統分析與系統開發的箭頭，以及卡在這兩個活動中間Front-End Developer的用途。系統分析與系統開發的箭頭意思很簡單，代表需求是開發的輸入，開發的結果會回饋到需求，基本上和第二張圖的意思很像。至於Front-End Developer是指前端工程師（英翻中，有講等於沒講），在《Agile Experience Design》這本書當中是指具備撰寫CSS、JavaScript以及畫畫圖等能力的網頁設計師。書中將Front-End Developer當作UX設計師與開發團隊的橋樑。作者建議系統的雛型或是畫面可以直接用網頁來表達，而且作者也知道UX設計師可能、應該、也許、大概不太會製作網頁。所以，假設UX設計師將使用者操作的設計用手繪草稿，之後可以請Front-End Developer用網頁做出來。等交給開發團隊實作時，搞不好這個網頁就可以直接變成產品（假設系統的介面真的是以網頁呈現）。
***
看到這邊跨界開發的日月精華鄉民們應該吸的差不多了XD，剩下的就是一些「實際運作的細節」。實際運作細節重不重要，當然重要啊。但是總是要先把觀念弄懂，之後才可收事半功倍之效。至於實作細節，就等Teddy有空再慢慢寫，或是花點小錢來上Teddy開的課學起來會比較快XD。
最後還有一點小小的心得要補充，在讀《Agile Experience Design》這本書的時候，Teddy感覺到書中「好膽 大膽假設」UX設計師是具備「Experience Knowledge」的人，這一點就好像很多Scrum的書都假設所有Product Owner都具備很強的「Domain Knowledge」一樣。當假設成立時這個世界就很完美--PO寫出很棒的需求，並且可以依據實際狀況（客戶真正需要與企業願景）來決定需求開發的優先順序。在sprint planning meeting的時候，PO一夫當關，萬夫莫敵，輕輕鬆鬆地就回答開發人員對於需求的所有疑惑。在sprint review meeting的時候，PO當機立斷，當場便可決定開發人員做出來的功能是否符合客戶的需要。此時此景只能用一首英文歌的歌名來形容：What a Wonderful World！
但是當假設不成立，就會很「賽（慘）」，至於有多慘，那…麼…慘。問題是，在現實生活中，假設經常都不成立...Orz。所以結論就是，扯那麼多有的沒的，什麼流程改善、什麼使用者經驗研究、什麼GGG、YYY的，還不如想辦法找幾個（或培養幾個）「真正有能力且可以合作的人」進來團隊中比較實在啦XD。這個道理很簡單，大家都知道，但是卻都做不到。為什麼？因為大家都沒來上Teddy的課…Orz。嗯嗯…其實是因為老闆或主管都想用「便宜的人力」去做出偉大的事業...Orz。
又扯遠了，下課XD。
***
友藏內心獨白：搞不好過一陣子還真的要去教跨界開發流程的課耶。
沒有留言:
張貼留言