HPX98 (2017/10/19)Agile+UX參加後感想
(update in 2017/10/31): 當天的slide參考：https://www.slideshare.net/Happy.Prototyper/agile-development-incorporating-ux-hpx98-81363724?from_m_app=android
今天來CLBC參加 HPX 的活動，題目是「敏捷開發與使用者體驗的結合」，分享的講者是微軟的James (James之前也有在Agile社群分享過相同的題目https://www.slideshare.net/ssusere62027/agile-ux-is-good-but-can-be-better) 與Lynn；小弟前公司CTKPro實施Agile+UX 也行之有年，雖然在實作上還蠻多心得的，但是由微軟來分享他們的實作經驗也別具意義，聽完之後，更為他們把這整個流程執行的成熟感到驚豔，以下整理一下我這次的心得，James的分享由Agile切入，再簡單帶過UX(畢竟這是UX社群的聚會)，最後分享他們執行Agile+UX的心得。
Agile
Agile是一種精神，相關的文章太多了，我就不班門弄斧，四個宣言大家應該都知道：
不過今天講者也提到了幾個常見的迷思：
- 這四個宣言不代表右邊不重要，而是左邊更重要 (重於不代表不要)：以「可用的軟體重於詳盡的文件」為例，不代表團隊實施Agile之後就不需要寫任何的文件，如果有需要的文件來輔助軟體的開發，也可以留有適度的文件。
- Agile開發產品是更「早」而不是更快：很多人覺得Agile是一個更「快」開發產品的流程，其實Agile並不是這麼的神奇，它可以更「早」的讓產品與用戶先見面（MVP），但是它並不是讓團隊有更快的產出，它的精神是因應變化而非加速生產。
- Burndown chart不是去檢討為何過去估不準，更重要的是看未來我們還有多少小時可以使用：很多人把Burndown chart拿來當作檢討過去的時數估不準，但是它更重要的應該是讓團隊知道離專案結束還有多少小時可以用？因應情況來調配。
UX
這天是HPX的場，所以講者對UX並沒有著墨太多不過有一些東西聽完講者分享完也另我有些收獲：
- UX不是前端UI，UX不是前端UI，UX不是前端UI：好，這一點講者今天沒有講，不過最近發現大部份的人還是會把UX/UI畫上等號，所以我還是藉機抒發一下XD，UX不是只有看到的部份，也包含「感受」的部份，詳情可參考「UI、UX 差很多！比起動手設計，UX 設計師更擅長規劃好體驗」。
- UX不是只有設計該做的事，人人都可以是UX：今天James分享在Microsoft裡更是有這樣子的精神，一個scrum team中，輪流每個人會抽一天中的2個小時來做UX的工作，人人都需要對UX負責。
- UX的U是user，user是「用戶」，不是老闆：很多客戶會把user當成自己，這時要有guts跟客戶說「我只做你user要的東西」；這一點說實在並不是那麼容易，有朝一日能做到跟微軟一樣大的時候我也要來跟客戶說說看 XDDD。
Agile+UX
這一段就是本次最精采的部份，之前其實我還沒有這樣子的體會，經由這次講者分享之後，發現Agile與UX的精神其實有異曲同工之妙。
從兩者的精神來看：
從工作的角度來看
從儀式的角度來看
以前從來沒有從這些角度來觀察這兩個東西，經由講者這樣一剖析，發現還真有這樣的相似性。
講者今天有把他們執行的細節講的很清楚，以下我簡單分享我個人得到的小心得：
- UX的sprint在scrum之前至少一個sprint，這樣scrum team才有辦法由story map來規劃任務：從上面的圖可以看到UX有一個所謂的Sprint 0，也就是在Scrum第一個sprint前需要透過UX來釐清spec，如果有需要的話也可以讓UX在Scrum前幾個sprint，但是差距不要太多輪，以免定出來的spec執行完之後才發現UX需要做修改，造成後面UX的sprint白做。
- 使用Visutal Studio Team Services來管理Story Map 以及實作任務：之前在使用Agile+UX開發時，一直沒有找到一個好的User story 對應到詳細實作任務的管理工具，聽完分享才知道原來微軟的Visutal Studio Team Services (https://azure.microsoft.com/zh-tw/services/visual-studio-team-services/)已經具備這樣的功能，不過我稍稍試用了一下感覺似乎是需要學習一下才比較好上手 XD
總結
使用Agile+UX的幾個好處如下：
- 客戶與團隊會對產品的樣貌有相同的認知：
有一張很有名的鞦韆圖形容專案在開發時團隊成員彼此對產品認知的差距有多大
我們透過Agile+UX的過程，發現這樣子的方法能夠減少很多溝通問題，傳統的方法常常會遇到做出來客戶質疑怎麼跟他想的不一樣，而現在客戶會對團隊所以執行出來的產品樣貌較明確，團隊間彼此也有較高的共識。
- 每個人都對UX責無旁貸：除了UX Designer之外，團隊中每個人都也會輪流負擔UX的角色，每個人都會對要呈現出來的東西負責；以前大家總是會把PM或是前端設計師當成是產品不好用的眾失之的，當團隊每個人都對UX有責任的時候，整個產品的可用性的責任就是屬於團隊的，不再對可用性區分你我。
- 縮小工程師與設計的gap：很多團隊中工程師與設計常常勢不兩立，團隊該適度把工程師丟到第一線去看用戶的反應，客戶覺得不好用，工程師可以立即感受到屈辱XD，回去進行修改；客戶如果覺得好用，工程師也能夠更加有成就感，能與設計團隊更加共創，而不是敵對。
想要瞭解更多Agile+UX的朋友，也可以去參考 Lean UX這本書，台灣也早早有人在推動 (https://www.slideshare.net/hhldavid/1408-uxsmallthingdavid-liuuigathering-38286140)，有興趣還沒有開始導入的團隊，也可以開始思考該如何導入喔！
