l

2012年7月25日 星期三

Scrum框架下的跨界開發(7):扯這麼多,最後不就是需求與開發嘛!

July 24 16:55~18:40

螢幕快照 2012-07-24 下午5.32.28

 

昨天討論到《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要怎麼寫會比較好(有助於開發)。

image

 

雖然傳統的需求分析都會強調「使用者介面是一種實作,不需要急著在需求分析階段就早早決定」,但是對於「依靠使用者介面或是使用者經驗決生死」的應用而言(例如手機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。

***

友藏內心獨白:搞不好過一陣子還真的要去教跨界開發流程的課耶。

沒有留言:

張貼留言