125個從業者分享了他們在Agile（敏捷）項目中提升用戶體驗的經驗和成功故事。
今年早些時候，我們讓UX Conference上的敏捷從業者分享了他們在敏捷項目中運用到的的成功秘訣和技巧。
我們收到了美國和新加坡125位專業人員的回應。這些人在各類規模的公司工作，並且擔任不同的工作職責，從UX設計師，開發者，項目負責人到項目經理。顯然，這裡存在著一些潛在的受訪人偏差，因為他們不包含很多完全不關注用戶體驗的公司。不過我們可以說這些答覆確實反應了那些對UX足夠關注並願意送員工來參加用戶體驗培訓的機構的情況。
成功敏捷項目的10大關鍵技巧1、留時間用以release規劃和故事導圖(story mapping)受訪者匯報說在項目開始花時間好好做release規劃是一項值得的投資：
「在規劃，設計和細化階段投入更多的精力。」
「在最開始就參加進去。」
「在規劃階段花更多的時間，然後專注於改進和調整。在項目開始前獲得認可。」
「儘早計劃好營業時間，籤好所有東西。」
「在sprint開始做好適當且廣泛的規劃。留出足夠的時間來處理不可避免的阻礙。」
在開始階段就跟利益相關者展開合作，能夠讓團隊產生對項目共同的理解和願景。這個共同的願景會在整個項目過程中指導團隊，為他們給用戶故事（user stories）做優先級排序和正確取捨上提供幫助。
有些團隊在release規劃階段採用了故事導圖（story mapping）來幫助利益相關者與其他團隊成員一同創建產品儲備(product backlog)。這項活動經常揭示新的機遇，並幫助團隊給用戶故事分組和排序。
UX在release規劃階段的參與可以使得團隊專注於更廣闊的背景，找到需要進一步鑽研的知識缺口，並且在項目開始之前收集團隊決策所需的信息（例如通過一些適當的用戶研究）。如果團隊分配時間來做項目起步階段的發掘和研究工作，他們可以減少將來的無用功。
「在敏捷開始之前加入探索過程，用以項目策劃，人物角色構建和故事導圖。」
2、在sprint開始之前開展UX活動很多人匯報說在單個sprint期間嘗試同時開展設計和開發工作很難。兩周的時間往往不夠完成研究、線框圖和設計，並且同時完成所選用戶故事的開發工作。
克服這項挑戰最常見的建議就是交錯UX/UI和開發的工作流，這樣在sprint開始之前就可以完成研究和設計。例如，UX在sprint1製作界面，接著開發在sprint2中為完成好的設計編寫代碼。
「作為UX/UI負責人，我提前一個sprint完成我的工作。我會和scrum master及產品負責人一起對backlog中的項目進行優先級排序，並且在提前一個sprint完成UX/UI的需求。我在sprint中的工作時間計算方式有些不同，要從團隊速率中扣除，但是這種做法很高效。」
「研究和設計工作應該保持一個sprint的提前量。給自己留時間來進行深入的用戶研究和設計測試。」
「確保儘早完成設計，這樣你可以在開發開始之前製作原型並且測試你的概念。」
「在sprint期間花時間調查，來滿足下個sprint的預期需求。」
「在sprint規劃會議前準備好原型。」
在進入開發之前完成工作，可以留時間給設計師進行充分的思考，並且與真實用戶驗證假設。保持提前量可以讓整個團隊在功能設計進入sprint之前對審查原型並發現潛在的問題。
項目的規模和複雜度會影響UX設計師需要在開發之前多久開始工作。大多數從業者建議提前1到2個sprint進行設計工作。
這是一個協調性的工作，對團隊溝通有一定要求。僅僅因為設計在開發sprint之前完成了（或者完成了大部分）並不意味著UX設計師只需把設計交給開發者就可以繼續後面的工作了。儘管UX設計師應該保持未雨綢繆，他們仍然必須支持當下的sprint，給團隊提供建議，並且在必要的時候做出調整。
此外，所有的團隊成員包括項目經理，產品負責人和工程師，應該在過程中和UX設計師緊密合作，這樣當設計「就位」的時候，所有人是保持同步的。後端和前端開發者需要理解並支持設計，交互和用戶流（user flows）的工作。
3、培養協作文化軟技能是敏捷項目成功的關鍵。受訪者們認為健康的合作關係是成功的主要因素。這一發現並不令人驚訝；畢竟，在敏捷宣言裡，個體和交互的價值高於流程和工具。良好的溝通在任何軟體開發組織中都是必不可少的，無論其流程方法如何。但是在敏捷環境中，合作尤為重要，因為它的交付時間短，並且有固定的時間限制。
一些機構選擇採用設計思維的技巧，例如用構思和頭腦風暴來鼓勵團隊討論，並且打破那些阻礙有效溝通和團隊合作的隔閡。
「合作是至關重要的。」
「與團隊其他角色的緊密合作幫助我們在過程中更早地達成一致。」
「與所有團隊成員持續合作。我們用速寫和白板會議，以及體驗地圖來獲得全方位的體驗。」
「在跨職能團隊中分享信息。更多地和開發者及設計師進行溝通。」
「在初始階段不貶低或放棄想法。」
「讓團隊裡的每一個人都加入進來，並歡迎任何人的建議和想法。」
「保持業務分析師，設計師和工程師之間的密切關係。」
「每周定期碰頭來更新和了解進度。專注於互相幫助以完成工作。」
「每日立會，迭代演示，兩周一次脈衝會議（pulse meeting），與管理層互動。」
在現代開發環境中，UX已經積極地參與到制定線上產品服務的開發方式中。因此，UX的職責已經擴大到溝通層次。UX可以通過參與團隊成員活動，例如可用性測試，實地調研，設計構思和頭腦風暴，成為良好溝通的催化劑。
4、別光想著完美，多想想迭代。在我們的研究中，很多人贊成迭代的設計流程。從低保真原型（手繪，線框）開始，根據用戶和客戶的反饋進行迭代。換句話說，快速失敗，經常失敗。
「儘可能長久地進行低保真工作，先不考慮美觀的部分。」
「選擇快速粗糙的線框圖方式。」
「快速失敗，在迭代中嘗試多種選項。」
「不要試圖做到完美。」
「迭代地進行工作。」
「頻繁地迭代和測試。」
線框圖對于敏捷流程是天作之合，因為它能讓團隊成員在投入更多精力和時間之前，快速地測試設計想法。早期發現的設計缺陷比功能編碼完成之後要容易修復的多。
5、參與到scrum會議中來在四項scrum儀式之外，訪問者主動點讚最多的就是每日立會(scrum會)了。scrum會通常在每天相同的時間段，在15分鐘內召開。scrum會的主要目的是讓每個人了解團隊最新的進展，並且認識到需要解決的障礙。
「每天有短暫的scrum會議。」
「我們的每日立會更好地讓開發者們保持在軌道上(on track)。」
「每日scrum會議是關鍵。」
「限制每人發言時間在2分鐘以內，得有計時員。否則他們永遠也講不完。」
「每天的快速狀態更新可以保證每個人都在完成任務。」
「參加短立會。」
有時候人們會反對每日scrum會議，因為加上其他所有會議，梳理會、規劃會、演示會還有回顧會，他們已經耗光了寶貴的工作時間。然而，我們的調查顯示這樣的儀式對於保持團隊的狀態更新和同步有很大用處，這樣大家才可以在必要的時候響應變化。
基於這次研究的結果，假如你已經放棄了每日立會，也許值得考慮再給它一次機會。仔細觀察其他可能影響人們參會意願的因素：這些會以是否能順利進行，這些討論是否加入了UX相關的活動。
６、將用研轉化為團隊驅動的事件人們反映說可用性測試是團隊建設和影響決策的一個積極因素。即便在時間緊張的情況下，敏捷團隊也可以將用戶研究加入到他們的流程中來。這一結論打破了用戶測試過於耗時和昂貴的謠言。團隊將它用起來：一周一次（例如周二）進行用戶測試是一個可行的方式。
受訪者提議將可用性測試轉為整個團隊的活動，讓成員們（包括利益相關者們）觀察測試過程並且加入後期討論。
「確保所有的利益相關者都出席了研究會議。」
「提供明確的硬數據對決策產生了影響。」
「讓開發者和產品負責人參與或觀察可用性測試。」
「在sprint裡給研究和測試充足的時間。儘可能提早規劃。」
「測試完成之後，儘可能多碰頭，以確保大家的一致認識。」
「每周安排會議來展示上周的研究結果。」
大家一起根據用戶數據做設計決策，而非根據意見或者未經檢驗的假設，可以讓團隊更快地前進。
7、確保重要利益相關者的參與我們的受訪者強調了利益相關者在關鍵點參與的重要性。這個概念和敏捷原則相一致：比起合同談判，更重視客戶協作。合同是重要和有益的，但是當它們對有效合作有影響的時候，會阻礙前行。
一些機構採用的不同的策略與利益相關者協作。這些方法包括早期組建核心領導團隊，讓關鍵UX成員與客戶合作，邀請客戶參與用戶測試，以及頻繁地進行高層級的演講。
「與利益相關者和工程師不斷對話。」
「通過大場景演講（5-10分鐘），讓領導者參與項目的每個主要步驟。」
「先組建一個領導團隊。」
「讓利益相關者們看得見障礙。」
「在業務利益相關者中嵌入UX。」
８、設定明確的角色和責任很多受訪者強調需要讓團隊成員了解各自和同伴的角色。為了讓敏捷工作能夠有效開展，成員們需要知道預期是什麼，以及什麼在影響範圍之內。
「絕對的職位分隔是必不可少的。」
「與產品負責人，客戶及用戶舉辦分享會，告訴他們什敏捷流程是什麼，對他們的期望是什麼。」
「有一個單獨的scrum master和一個單獨的產品負責人。」
「你需要一個強大的scrum master」
「要知道你的開發團隊是如何工作的。」
在傳統敏捷方法中，團隊的定義和角色分工是相對明確的，用戶體驗從業者除外。事實上，傳統的scrum團隊不包含UX。由於UX的角色和流程對於其他團隊成員可比較新，他們不熟悉這一領域，因此讓大家設置正確的期望，並且幫助人們在敏捷背景下考慮用戶體驗尤為重要。
明確指示每個人的角色和責任，並說明在不同情況下各自的職權，可以加強協作，減少誤解和在地盤爭奪中浪費精力。
９、組織培訓和入職會議。敏捷團隊成員強調了對客戶、新成員和外部團隊進行敏捷UX流程教育的重要性。
「舉辦』午餐學習』來幫助他人了解流程。」
「努力把方法用到最好，並且持續地進行解釋。」
「開展培訓和灌輸。」
「擁有跨職能培訓。」
「跨團隊培訓。」
「遵從儀式並且教育客戶。」
「在他們所做的項目之外，提供開放式的培訓。提供小份的準則和最佳實踐，並且對它們進行解釋。」
在敏捷環境中，團隊成員的換組現象很常見。雖然這種做法並不理想，但是對於人手有限的機構而言是常見現象。
培訓提供了良好的機會來教育員工正確的UX和敏捷實踐方式。敏捷提供了交付產品所用的框架，但是不同的組織和團隊在這個框架裡融入UX的方式各不相同。
為了教育你目前的團隊，你需要去接觸其他的團隊和業務部門。設置適當的預期可以讓溝通和交接工作更加流暢。
10、改進你的方法直到它發揮作用。隨著敏捷團隊的日漸成熟，他們會嘗試不同的敏捷及UX技巧，為匹配他們的環境做特別定製。不光用戶界面，也需將迭代設計用於項目方法。
「我們不斷檢討敏捷的各個方面，如果效果不好就做出改進。回顧會和反思會很有幫助。」
「告訴團隊大部分的敏捷方法，讓他們決定用哪些。由於團隊是自組織的，他們應該可以決定什麼方法對他們的流程最有效，這些決定屬於他們自己。」
「我們更傾向於長期採用不固定迭代的流程。」
敏捷為你提供了工作框架，但是不會幫你決定該如何執行項目。它鼓勵自組織團隊，仔細思考更高效工作的方法，並且只有必要的時候採用，以減少不必要的複雜性。
先進的軟體開發團隊比以往更加跨學科，流動性更強。成功的團隊往往採用混合的方式。敏捷和UX方法都是針對傳統方法的缺陷被發明出來的。它們有各自的優點，如果我們能更專注成果而非強調規則，敏捷和UX可以被很好地組合運用。
譯者：Zoe Yin
來源：微交互
作者：HOA LORANGER
原文：https://www.nngroup.com/articles/ux-success-agile/