本文是 映萱 參與 HPX98 – 敏捷開發與使用者體驗的結合，於會後整理當日分享內容的筆記。
James在此次分享了Agile的一些核心價值與流程要點，並分享了他在擔任國際公益總幹事期間，協助鄉村兒童教育開發圖書館系統的一些觀察於執行想法，而Lynn在微軟團隊中實際使用Agile development incorporating UX 的實作流程與經驗。
James 一開始就引用了agile manifesto敏捷宣言（2001）裡頭的精神：「敏捷本身不是方法，他代表的是一種價值觀與理論，個體互動高於流程與工具，文件只是一個幫助的工具，但真正的價值是個體與軟體互動的需求」，來引出今天的主題「敏捷開發與使用者體驗的結合」，James提供了幾點來讓大家了解敏捷的核心精神：
敏捷即是快的迷思
相較於瀑布流式的傳統開發流程（Waterfall ），敏捷是響應是充滿變化與彈性的，使用敏捷這樣的方法不保證一定成功，方法不可以保證項目一定會成功，但是在微軟團隊的開發中，將敏捷與UX結合在一起，稱為user centered agile scrum，以用戶為中心的敏捷開發，讓軟體可以更「早出現產品」與使用者互動，而不是「更快的出現產品」使用，透過過程中彈性敏捷的調整設計，而不是加快產出。
不要糾結為何計畫還未達到
Burndown Chart是指敏捷式開發過程中，會記錄的剩餘多少工作尚未完成，目的在於不要糾結於計畫為何還沒達到，而是專注於產品身上，還剩餘多少小時可以把工作做完及解決問題，這過程中重視的是產出（outcome），透過sprint計畫、每日與會、sprint審查與回顧，讓工程師自己規劃剩餘的項目還需要花多少時間，從這可以看得出來，敏捷式開發非常尊重開發團隊自我管理。
敏捷溝通是一個彼此優化自我與互相解決問題的過程
James分享了在微軟團隊中使用Agile時的站立會議開會場景描述，James：「在開發團隊是自我管理自我衝刺計畫，當大家早起會開會，我們圍繞著一個圈，回答三個問題，分別為上次討論後完成了什麼？接下來要做什麼？有沒有什麼障礙？有障礙的話，團隊團員會互相幫助解決，scrum講究團隊成功而不是個人的產出表現，scrum master會替團隊解決外部問題，例如產品的發展限制， 透過這樣的站立會議，大家彼此review回顧什麼東西好，什麼東西不好，不好的事情要馬上停止，要如何將產品變更好，這過程中經常會出現失敗的情境與挑戰，因此可以看出Scrum是一個彼此自我優化與彼此學習的過程。」
UX與Agile的比較
這次James講者分享到Agile與UX之間其實有著許多相似之處，透過三個不同的角度來看待Agile+UX，其中增值式開發與迭代式開發的想法，所謂增值式開發，是指透過每次建構一點點想法，來完成最後的成果 ; 而迭代式開發，是指從一個模糊的想法添加細節直到完成 ; 在微軟裡是增值且迭代式開發，UX是以用戶為中心。確保在開發過程中有效地讓用戶充分參加，用用戶的視角來定義solution功能範圍，以及配合ux與商業策略、系統功能需求和技術規範互補。
最後James特別強調：「每個人都是UX的一份子，UX Designer會教導整個團隊設計，重視換位思考，彼此參與大家在團隊中擔任的角色體驗，每個人都要對於產品負責，技術與用戶體驗是不分界線。」
接下來為Lynn的分享，他分享了在UX用戶故事的執行細節及如何執行：
任務的分配
在收集完使用者旅程後，會將用戶需求整理成使用者故事，接著再將使用者故事中整理成product backlog ，每次在sprint之前會去評估這些做多少user story ，再將user story分配給團隊人員，最後確保團隊在sprint結束後，團隊人員可以透過這些user story來完成產品以便來達成客戶需求。
優先順序的評比
確認客戶優先來確保開發順序，因此會將需要先開發的使用者故事優先列入 ，敏捷開發響應改變，如果需求改變則會增加新的使用者故事，再根據product owner針對客戶需求來加入sprint任務。這過程會根據給予使用者故事評分，並在眾多的使用者故事中團隊會根據使用者故事中來挑選一個開發上不困難但也不過度簡單當做任務基準。
高精度與低精度
雛形的製作，可以分為低精細與高精度，再做高精度前可以做低精度，可以先跟用戶討論，一方面可以節省一些ux團隊再做精細畫面時節省時間浪費的成本。畫完紙本雛形，會做紙本雛形的測試，有幾個角色，使用者、旁白與記錄，故事牆會根據用戶使用情景，例如醫囑的場景設計來說，對醫生來說，是利用這個系統完成每天幫病人看診的工作，將每個頁面的標題做成便利貼，彼此做關聯，可以幫助開發團隊去了解頁面的互動關係。
故事牆
其實使用者在使用場景的變換並不多，但會利用系統來幫助使用者解決工作上的問題，因此對於系統的內容互動的體驗反而較多，因此故事牆主要是製作這種互動關係的互動，幫助開發團隊了解使用者的使用狀況。
UX團隊就像蓋鐵道，要跑在前面鋪路
UX在執行sprint時，scrum之前至少要先執行一個sprint，這樣scrum team才有辦法由story map來規劃任務，也就是所謂的Sprint0，這樣的目的在於釐清UX的spec，可以依照任務大小來決定是否需要在scrum前多做幾次sprint衝刺，但要注意也不要做太多輪，以免spec太過龐大且可成會造成UX需要做調整，而浪費時間。
後記：講者提供了一款管理工具來管理任務，微軟團隊使用了Visutal Studio Team Services 來管理Story Map，將user story對應到實作任務 。