超越 Sprint 0：整合團隊的另一種選擇
已發表: 2022-03-10Scrum 是世界上最流行的項目管理方法，超過 72% 的團隊使用 Scrum 或混合 Scrum。 如果您從事 Web 開發工作，那麼很有可能您正在以某種形式使用 Scrum。
Scrum 的當前趨勢是“Sprint 0”或其更具藝術氣息的表親“Design Sprint”。 關於這些是否是真正的衝刺（它們不是）已經寫了很多，但關於它們為什麼存在，為什麼它們如此頑固地堅持，以及存在哪些替代方案的說法卻很少。
我個人喜歡 Scrum，我一直在尋找方法來逐步改進我的實施方式。 在這篇文章中，我想分享我已經融入我的工作流程的方法，並且在合併 UX/UI 和開發以及創建更強大的項目願景時，我發現這些方法很有幫助。
在我們開始之前的一些快速定義：
- 衝刺 0
團隊創建 Scrum 項目所需的指導文件的最初努力：願景、產品待辦事項和產品發布估算。 - 設計衝刺
團隊為發布的其餘部分創建指導設計的最初努力。
為什麼 Sprint 0 和設計 Sprint 存在
說“Sprint 0 不是真正的 sprint，不要這樣做”，這一切都很好。 但是這些衝刺式的改編存在是有原因的。 許多團隊採用它們是因為他們的項目有超出 Scrum 直接範圍的未滿足需求。 我的觀察是 Sprint 0 和設計衝刺最常用於解決以下情況：
- 缺乏強烈的指導性願景；
- 缺乏將設計集成到開發工作流程中。
Scrum 流程假設產品所有者已經制定並傳達了清晰的願景。 但是，如果您從事的項目的願景是弱的、錯誤的或不可見的，請舉手。 我也是！ Sprint 0 是開發團隊填補願景空白的嘗試。 這不是最糟糕的想法，那麼問題是什麼？ 從敏捷的角度來看，Sprint 0 不是迭代的，沒有利用整個團隊的才能，並且提供了模糊的結果。 在你指出“嘿，這裡真正的問題是 Scrum 團隊不應該做產品負責人的工作”之前，我實際上相信跨學科敏捷團隊是開發強大、現實的最佳環境之一願景和目標。
我提出了一種更靈活的構建願景的方法，我已在無切換項目中成功使用過該方法。 我將探討使用這些類似 sprint 的調整的兩種情況，並描述這種替代的第一個 sprint 如何更好地支持敏捷工作流程。
願景和原型沖刺
在第一種情況下，缺乏強烈的願景，指導文檔或想法太弱，無法真正開始 Scrum 項目。 對於任何流程（包括 Scrum），您在開始旅程之前都需要指導。 敏捷非常適合找出實現目標的最佳方式，但產生最初的願景不在其範圍之內。 事實上，Scrum 完全缺少對開發過程開始所需願景的描述。 無論是否真的是 Scrum，Sprint 0 只是一個在前線的網絡團隊，使用他們擁有的工具，試圖在開始做之前弄清楚他們需要做什麼。
Sprint 0 的真正缺點是，在您掌握的信息最少的時候為項目構建指導文檔對隨後的開發過程的價值很低。
不符合迭代出現的現實的指導項目願景要么需要經歷另一個 Sprint 0 的昂貴過程，要么更經常被忽略。
更好的選擇是原型沖刺：第一個衝刺讓整個團隊參與其中，同時實際構建初始原型本身。
原型 Sprint 視覺過程
頭腦風暴的想法被盡快轉化為低視覺保真度的工作原型。 原型是用功能性的前端 HTML 和 CSS 框架編寫的，即團隊的共享語言。 不是每個人都能理解規格表或願景聲明。 每個人都可以理解一個網站，並且交流更容易，並且包含更廣泛的學科。
在第一個 sprint 結束時，原型已準備好在多個方面進行初步測試，包括一般可用性、可訪問性和移動響應能力。 在我的團隊中，這是一個有效且重要的完成增量。 原型沖刺還產生了初始產品積壓。 隨著積壓項目在未來的衝刺中完成，原型獲得了保真度。 原型不是一次性代碼——它是基礎。
在某些項目中，在生產原型時會生成書面願景。 但在許多項目中，原型就是願景。 它以團隊的共同語言說話，當然，它永遠不會與產品脫節。
例子
下面的示例是一個電子商務應用程序的工作原型，它是根據初始 RFP 中的粗略輪廓完成的。 儘管它很粗糙，但它有助於將團隊的精力集中在生產性方向上，跨越許多潛在的干擾和陷阱，專注於功能標準。
初始原型通常會導致需求更改，這只是最好的猜測，直到根據用戶體驗進行。 例如，我們從上面顯示的原型沖刺中獲得的一個見解是，定價和“購買”按鈕最初在頁面上太低了。 最初的要求是將它們放在產品信息下方和推薦上方，但功能原型很快表明層次結構不是很實用。
曝光的另一個功能是畫廊圖像最初被要求很大並且可以拉伸頁面的整個寬度。 原型不是向利益相關者提出假設的原因為什麼這不起作用，而是能夠以整個團隊都理解的共享語言來展示問題。 在與利益相關者的一次權力會議中，我們迅速將這個頁面重新組織成一個普遍認可的層次結構。
由於原型天生易於訪問且響應迅速，我們可以立即開始在多種設備和技術上進行測試。 儘管設計（如果在這個早期階段甚至可以稱之為）故意保持低保真度，但很明顯桌面上的年份切換器消息在移動設備上太大並且干擾了可用性（左）。 我們迅速更新了原型，在標題中使用了一個較小的切換器（右）。
在這個原型沖刺期間，其他一些問題很快就暴露出來了：
- 客戶在點擊功能導航後，立即意識到他們錯過了規範中的一個主要功能組件：博客。 這影響了估算和時間安排，但我們能夠快速調整。
- UI 團隊很明顯，定價顯示過於復雜和混亂。 我們與客戶一起探索了其他可能性，並能夠在原型沖刺期間快速製作原型和用戶測試多個解決方案。
一旦開發開始，願景就不會成為障礙或過時，而是在原型沖刺中共同開發願景和功能標準並相互支持。 而且由於願景是由團隊產生的，因此無需向團隊移交，並且可以輕鬆避免開發過程中的那個風險時期。
設計和原型沖刺
在第二種情況下——缺乏設計與開發的整合——通常是你會看到使用“設計衝刺”的時候。 我發現這個方向比 Sprint 0 更適得其反。將設計集成到復雜的開發過程中的挑戰是真實的，但設計衝刺是一種弄巧成拙的方法。 設計衝刺是針對症狀的創可貼——建立集成團隊的挑戰——但沒有解決根本問題——理解和滿足用戶需求的挑戰。 將設計預先加載到一個 sprint 中避免了集成的挑戰，但是集成和增量設計過程的好處以及它為理解和接觸用戶打開的窗口完全消失了。
我在無移交項目中使用的原型沖刺是設計衝刺的高效且完全敏捷的替代方案。 它是協作的，從項目的最早階段就融合了 UI/UX 和開發。 即使是最有經驗的設計團隊也可以從其他學科的參與中受益，而且至關重要的是，它可以確保代碼和設計目標不會交叉。
通常，設計衝刺也有望充實願景。 這是一個絕望的舉動，基於一種模糊但有見地的理解，即設計過程比開發更能產生願景。 然而，設計產生的願景並不能替代真正的、協作的、團隊範圍內的努力。
可憐的設計師背負著生成最終產品來啟動開發的任務，而沒有必要的跨學科信息來使這項工作真正有價值。 儘管具有技術知識和更多經驗的設計師將有更好的機會做到這一點，但這仍然是非常冒險的。 由於在階段結束時沒有潛在的可交付產品來針對猜測進行測試，因此繼續開發。 如果設計沒有達到目標，或者如果規格發生變化，則可能會導致長時間的延遲，因為它會返回給設計團隊。 敏捷的核心是風險管理過程，我們可以做得比以固有風險設計衝刺開始我們的敏捷項目更好。
原型沖刺設計過程
與更傳統的設計衝刺相比，最重要的變化是，在原型沖刺期間，團隊直接從紙上到原型，並跳過了使用 Sketch、InVision、Photoshop 或其他數字佈局程序。 它們在這個階段充當了視覺拐杖，似乎很快就會引入價值（因為好的設計師做出好看的東西），但是這麼早的高保真模型的真正價值非常低，而它引入的潛在危險——婚禮利益相關者的錯誤解決方案——高。
這些工具最適合高保真平面模型，但最初的原型既不高保真也不平面。 白板、鉛筆和紙讓團隊可以快速通過想法，而不會被他們束縛住。 然後儘快將這種想法轉化為功能原型。
每個團隊成員，包括設計師，都應該熟悉並能夠在低保真階段直接處理原型。 但如果這是不可能的（或者這是一個長期目標，你現在需要向前推進），那麼設計師和開發人員並肩工作的配對方法是好的。 草圖可以由設計師描述並由開發人員共同解釋，擴大他們對每個觀點的共同理解。
例子
下面的示例顯示了我們將現有網站的深入分析直接提取為功能原型的過程。 它允許在本地網絡環境中評估報告的結果，這與在打印文檔中智能分析建議的體驗截然不同：
此外，與深入分析文檔不同（儘管它很有幫助），功能原型沒有行話，並使用每個人都能理解的共享語言和視覺語言。 它以視覺顯示向所有團隊成員和學科打開對話。
我們在構建此模板時的主要問題是要包含多少設計細節。 因為我們有一個充滿分析的豐富文檔可供借鑒，所以我們可以進一步開發原型。 但是，請記住，視覺效果可以迅速（並且無意地）從想法領域轉移到事實領域，我們保持佈局不明確，並將文檔提煉成其基本元素和意義。
內部測試使我們進入了一個更加以用戶為中心的解決方案的範圍內，跳過了許多潛在的問題，但我們有意識地避免在這個過程的早期做出任何精緻的設計決策。 重要的是不斷權衡所有想法和建議，包括客戶的，與已知數據，並記住我們的知識庫在這一點上比在項目的任何其他階段都要小。
保持初始原型低保真且不包含任何“設計”元素至關重要的另一個原因是，團隊支持可能會被不相關的視覺元素所破壞，這些視覺元素會引發意外的本能反應。 我們遠離顏色，甚至不包括客戶徽標（而是使用空白區域或淺灰色框作為佔位符）。 對話必須不斷地以功能標準為導向，如內容層次結構、可訪問性、可用性、語言和意義。 向團隊保證“有趣的東西”會到來，但不是在這個早期階段。
事實上，成功的原型沖刺的一個重要目標是盡可能少地做出前期設計決策。 成功的設計是由用戶體驗提供的，因此要留出時間讓新興的項目知識為 UI 提供信息。
原型沖刺何時完成
當原型和伴隨的工件得到整個團隊（包括客戶）的批准時，衝刺就完成了，並且認為原型已準備好進行初始可用性和可訪問性測試。
早期的功能原型通過規模（頁面數量、導航範圍和其他主要 UI 元素）、未來複雜性（具有有用描述符的佔位符內容，可能一些早期功能編碼）和識別需求（需要的特定技術）來實現項目願景，它們將在哪裡部署，任何依賴項）。 有關工具、工作環境和代碼堆棧的決策將在整個團隊的輸入下做出。
對於擁有響應客戶的經驗豐富的團隊來說，達到這一完成增量只需一天時間，但通常持續大約一周且不超過兩週。 原型沖刺應該快速推進，超過兩週的時間框架可能是一個危險信號。 這可能意味著還有其他問題在起作用。
在原型沖刺期間需要注意的一些常見問題
實施原型沖刺時需要注意的一些常見問題包括：
- 接受低保真度的價值，避免強調視覺效果。 對這一點保持警惕，因為不熟悉這種方法的團隊可能需要幫助和保證，因為他們超越了“徽標在哪裡”並專注於更深層次的功能和層次問題。
- 上述的不同方面，也要警惕不要依附於你自己的設計/佈局想法。 在原型沖刺期間記住沒有產生任何寶貴的東西並與最終結果保持分離是有幫助的。 此外，這是保持原型最小化的另一個原因，坦率地說，它相當醜陋。 它的目的是讓用戶保持分離。
- 領導層的早期流程支持至關重要。 因為整個團隊都參與其中，您的客戶、您的老闆和開發人員都需要用他們的參與、創造力和時間來支持和培養這個過程。 不要成為一個孤獨的啦啦隊長，你的整個團隊需要揮動他們的絨球！
- 溝通不暢是所有團隊合作的致命弱點。 原型沖刺不會解決持續存在的溝通問題，但隨著整個團隊幾乎立即投入協作工作流程，它將盡快將它們帶到前台。 當您努力達成共識和第一次完成增量時，任何已經存在的溝通問題都會在原型沖刺中儘早出現並且經常出現。 抓住改善溝通的機會，讓整個團隊參與尋找解決方案。
- 選擇正確的前端框架。 如果您還沒有，您可能需要嘗試各種前端框架，然後才能找到適合您團隊工作流程的框架。 我建議研究像 Fomantic 或 Bulma 這樣的最小框架，不要被花里胡哨的東西所困擾。 但是，正確的框架始終是適合您團隊的框架。
- UI/UX 團隊需要開發一個對前端框架的舒適度和訪問權限。 理想情況下，他們將直接在原型上工作，避免不必要的交接以及從一種媒體轉換到另一種媒體（即從 Sketch 到原型）的需要。 如果您的前端團隊不熟悉 CSS 和 HTML，那麼配對方法（一名設計師和一名程序員在框架上一起工作）也很有效。
- 最後但同樣重要的是，請記住，作為一個團隊，你們會變得更好更快！ 運行富有成效的原型沖刺是一項隨著實踐而增長的技能。
接下來發生什麼
第一個 sprint 的完成增量——功能性、低保真原型——為隨後的所有 sprint 奠定了基礎。 有了一個工作原型，用戶就可以立即開始對可用性、可訪問性和響應性進行測試，確保未來的 sprint 由 UX 提供信息。
原型沖刺是任何 Scrum 流程的良好開端，但在我的項目中，我們的下一步是轉向雙軌工作流程，其中 UI/UX 在開發之前工作半個或整個衝刺，進行發現並直觀地更新原型以反映新的見解。
在用戶體驗研究和現實功能需求的支持下，原型有機地發展並變得越來越精緻。 這些信息在原型沖刺期間不可用，只會隨著項目的進展逐漸出現。 UI/UX 和開發通過雙軌敏捷流程反饋到彼此的工作流程中。
沒有將設計移交給要構建的開發，也沒有將開發的應用程序設計到皮膚。 相反，原型沖刺從一開始就讓整個團隊參與進來，並為整個項目的協作敏捷工作流奠定了堅實的基礎。
原型沖刺產生的指導性願景並不完美，並且可能會隨著學習的更多而改變，但認識到我們在開始時比項目的任何其他階段了解的更少，這是敏捷工作流程的核心。 當我們通過原型沖刺將同樣的理念應用於項目願景和設計的出現時，結果是可操作的完成增量、真正有用的工件、共享的支持以及可以在整個項目中持續的團隊合作和協作模式.
關於代理設置的說明
如果您在代理機構工作，您可能會認為這種方法很難推銷。 不幸的是，你可能是對的。 許多機構天生不靈活，並積極爭取整體項目交接，通常有官方簽字和仔細記錄的影響，以在未來做出改變。 在非敏捷組織中提倡原型沖刺是不可能的：它只是不在他們的 DNA 中。 一旦組織接受了敏捷和跨學科團隊，他們就可以輕鬆考慮無移交原型沖刺是否會增強他們的流程。
結論
Sprint 0 和設計衝刺解決了許多 Scrum 團隊面臨的真正挑戰：缺乏遠見，缺乏集成設計，或兩者兼而有之。 它們是可以理解且合乎邏輯的響應，但它們不能提供高價值或為強大的敏捷團隊做出貢獻。
用原型沖刺代替它們是解決 Sprint 0 和設計衝刺的缺點的實用方法，同時為未來衝刺期間更強大的敏捷協作奠定基礎。
原型沖刺利用整個團隊的才能，產生必要的願景，導致團隊第一次完成的增量，並避免項目交接。 通過這個過程，團隊建立了項目願景的共享所有權，並為敏捷精神下的跨學科合作奠定了更堅實的基礎。
關於 SmashingMag 的進一步閱讀：
- 成為更好的促進者
- 為兼職團隊調整敏捷
- 項目回顧的重要性
- 為您的組織帶來更好的設計流程