任務驅動的發展

隨著公司的發展，擴展敏捷產品開髮變得更加困難。 根據第 13 次敏捷狀態報告中 52% 的受訪者，組織文化和敏捷價值觀之間的差異是他們工作中的主要缺陷。

組織領導者能夠利用敏捷文化來改進產品開發。 穩健的敏捷文化涉及團隊在解決複雜問題方面的自主權、與客戶的密切合作以及長期願景和戰略。

這些抽象價值很難評估和參與。在一個組織中，實施有效的戰略來利用它們變得非常重要。 任務驅動開發 (MDD) 方法已從中期初創公司興起，作為發展這種文化的替代方案。

擴展挑戰

擴展時可能會出現幾種減速模式。 隨著項目的結束不明確，團隊積極性可能會降低。 產品經理可能會在運營會議中迷失方向，從而失去設計戰略產品路徑的時間。 隨著系統變得越來越複雜，新功能和產品的部署可能會放緩。

應該從文化和實踐的角度來處理這些障礙。 克服它們包括放棄控制權、提高團隊自主權、實施徹底的透明度以及建立有效的產品開發框架來推動成果。

擴展傳統敏捷框架的挑戰

在擴展敏捷時，管理和團隊級別需要同步。 管理層負責制定公司戰略、創建和傳達產品願景、執行人員配置決策以及促進團隊發展。 團隊級別執行必要的任務，以有效地將這一願景和戰略轉化為有價值的產品和功能。

傳統的敏捷框架（XP、Scrum 和看板）經過優化以在團隊級別運行，而管理關係主要未得到解決。 新一波規模化敏捷框架的發展填補了這一空白，即 SAFe、LeSS、Scrum of Scrums、Nexus、DAD 等。然而，這些方法需要大量的計劃來實施以及管理和維護。

任務驅動開發框架是一種輕量級的方法，它提供了足夠的指導來圍繞擴展開發和利用敏捷價值實現一個健壯的結構。

任務驅動發展的核心要素

任務

起點是任務發現。 業務任務需要時間和精力，並且應該識別潛在問題、解決方案空間和期望的業務成果。 準確定義後，任務可以激發動力、促進協作並促進對更廣泛設計空間的研究。

小隊

每個任務成功的負責人是小隊。 與產品經理合作，由 2-4 人組成的小團隊開展必要的活動，以提供符合任務目標和時間限制的解決方案。

6週週期

6 週的時間框允許所有小隊遵循相同的時間線進行基地規劃，同時也有足夠的時間來交付有意義的結果。

緩衝期

MDD 框架通常包括一到兩週的緩衝期，用於最終集成和部署、培訓和技能開發、創新活動和下一個週期規劃等。

6 週週期的重要性

雖然對於一些敏捷從業者來說，六週的時間似乎很長，但它包含幾個重要的好處。

工作週期短的團隊往往會失去對產品願景的參與，因為他們覺得他們正在檢查修復、錯誤和小功能的“洗衣清單”。 這威脅到團隊探索和選擇交付解決方案的最佳方式的自主權。

隨著周期變長，產品估計精度會降低。 因此，它需要產品團隊進行大量的規劃工作。

六週被稱為產品時間表的“金發姑娘”，通過創新思維、快速原型設計和持續交付提供了足夠的時間來交付最小可行產品。

6 週的周期通過利用自主權進一步提高了團隊願景的參與度。 只要任務明確且週期短到足以讓團隊專注於期望的結果，就不需要微觀管理。

最後，產品經理可以每六週參與一次計劃活動，為團隊保持足夠的可預測性，以跟踪任務。 因此，可以將更多時間集中在產品開發的戰略性和探索性方面。

任務驅動發展的實施

讓我們以一家中期創業公司為例，該公司的 B2B 產品提供網絡定價優化，通過使用人工智能應用程序增加客戶收入。 該公司最近簽署了新一輪融資，目標是鞏固自己作為相關行業參與者的地位，並將市場份額提高 300%。

在這種情況下，有幾個產品開發挑戰：

• 如何獲得當前和潛在客戶的反饋來驗證待定價值假設？
• 應該從平台構建或刪除哪些功能以獲得引人入勝的用戶體驗？
• 如何建立管理結構來處理規模擴大和利用文化價值觀來加速增長？

最後，為了避免複雜的框架，公司決定應用任務驅動開發框架。 在任務驅動開發中，每個組織都定義了“最後一英里”的細節。 需要定義的主要元素是：

• 任務發現
• 任務結構
• 小隊集結
• 檢查和適應
• 緩衝迭代
• 容量規劃

任務發現

起點是任務發現。 Tim Herbig 將發現描述為減少圍繞問題或想法的不確定性的迭代過程，以確保為正確的受眾構建正確的產品。 在迭代周期中提交任何任務之前，應盡可能全面地對其進行驗證。

任務發現過程由專門分配的團隊進行。 發現團隊由產品經理領導，由產品研究人員、業務分析師和設計師組成。 當存在多個產品經理時，他們向首席產品官 (CPO) 報告，首席產品官 (CPO) 確保產品的共同願景、產品和全球公司戰略的契合以及及時交付。

任務發現的建議起點是挑戰、問題或機遇。 例如，從挑戰開始，幫助團隊探索更多的設計空間，最終拓寬解決方案的可能性。

任務驗證涉及一些有助於公司更好地了解客戶需求的活動：

1. 進行市場研究和競爭對手分析
2. 了解定義任務的問題空間
3. 設計低保真草圖和原型
4. 為任務定義明確的範圍
5. 收集客戶反饋和驗證

這些活動有助於使命成為開發團隊的可靠指南，並保證為用戶創造價值。

結果，一些任務被驗證進入任務積壓，隨著發現活動和反饋收集而不斷發展。

在示例中，讓我們接受這個挑戰：應該從平台構建哪些功能來產生引人入勝的用戶體驗？ 只有一個由產品經理領導的發現團隊就足以應對這一挑戰。

假設目前，示例公司的平台獲取客戶的原始數據並返回已處理數據文件的優化定價網絡。 但是，平台 UX 並未針對迷人體驗進行優化。 此時的目標是確定客戶價值是否來自改進用戶體驗、開發新功能或增強平台服務。

經過初步市場調查後，決定開發新功能。 該平台的候選功能包括：

• 超快速重新定價
• 快速響應的界面
• 智能和先進的定價規則
• 重新定價和銷售歷史

出於發現的目的，該公司決定採用設計衝刺方法：一個為期五天的流程，通過設計、原型設計和與用戶一起測試想法來回答關鍵業務問題。 為每個候選功能運行發現過程，以查看哪些將為當前和潛在客戶創造更多價值。 選擇用於開發的首要功能是智能和高級的重新定價規則。

任務結構

實現可靠的任務定義並非易事。 它必須描述一個明確的業務挑戰並為其結果設定界限，同時也為小隊提供足夠的空間來達成創新和有效的解決方案。 明確、準確的使命：

• 明確指出業務挑戰，確定並描述了問題空間。
• 綜合之前階段發現的所有信息和見解。
• 鏈接到期望的業務成果。
• 以結果為導向，清楚地表明任務成功的畫面。
• 在 6 週的周期機會內是現實且可實現的。
• 足夠窄以保證焦點和足夠寬以遠離細節。

在示例中，經過一周的發現，信息和用戶反饋已被收集和綜合。

目標用戶：客戶定價分析師。

問題空間：用戶希望能夠設置和管理智能和高級的定價規則，以便在特定條件下自動調整定價。

規則最有價值的條件是競爭對手的價格、運輸緊迫性、訂單總額、可用庫存和高級客戶的折扣。

見解：規則應在自定義優先級中應用，並可根據需要進行修改。

分析師希望輕鬆查看特定產品在特定時間適用哪些規則。

期望的業務成果：將用戶平台參與度提高 25%，以在平台上花費的時間衡量。

小隊大會

團隊組建過程是針對每個開發週期臨時完成的。 團隊自治和自組織原則仍然是核心。 團隊組建受多種因素的指導，包括任務複雜性、開發人員和設計師技能、興趣和小隊化學。

敏捷教練促進了小隊形成的過程。 在做出任何決定之前，會詢問每個人在接下來的六週內他們想做什麼類型的工作。 然後，根據經驗、知識和技能，組建小隊，確保他們擁有成功完成任務所需的知識和技能。

敏捷教練在開發週期中與多個小組一起工作，幫助他們提高障礙和依賴性。 當存在多個敏捷教練時，他們會向敏捷負責人匯報，後者負責團隊組建、持續改進和敏捷產品交付。

建議的小隊規模為 2-4 人：通常是一名設計師和一兩名開發人員，具體取決於任務的複雜性。 QA 工程師被認為可以幫助一個或多個小隊達到所需的質量標準。

每個週期後，小隊往往是混合的，所以每個人都可以與不同的人合作，傳播知識，在不同的產品維度上工作，儘管一個高績效的小隊可能會一起工作幾個週期。

示例中的特定小隊應考慮具有 UI 設計、數據處理和數據可視化能力的人員。

在周期內檢查和調整

敏捷教練應通過標準敏捷實踐不斷鼓勵透明度、檢查和適應。

每週舉行一次簡短的會議來組織工作並促進提高障礙和依賴性。 如有必要，會進行梳理，以確保小隊完全了解任務和用戶故事。 每週結束時都會進行簡短的回顧，以識別和實施變更和改進。

應在整個週期中保持持續交付實踐。 任務目標可以更早地實現，因為 6 週的周期時間框是一種基於節奏的方法來設定基本規則，同時幫助實現班組的可預測性。

根據小隊和產品經理之間商定的里程碑，提高透明度的一個好做法是在第四周結束時進行演示。 這些演示的目標是根據需要調整、縮小或增加範圍。

對於示例任務，小隊和產品經理已就四個不同版本的發布計劃達成一致：

1. 發布 1：
   • 新規則功能 UI
   • 競爭對手價格規則
2. 發布 2：
   • 出貨緊急規則
   • 訂單總計規則
   • 規則優先級
3. 第 3 版：
   • 可用庫存規則
   • 可視化應用規則
4. 第 4 版：
   • 高級客戶折扣

第 3 版被同意作為第四周的演示。 由於在整個開發週期中都進行了發布，因此應從開發週期開始的那一刻起跟踪期望的業務成果（在這種情況下，用戶參與度）。 從圖形上看，預計進展如下：

緩衝期

將一到兩周作為緩衝期是一種通過任務驅動開發實施以及其他擴展方法（如 SAFe）複製的做法。

在 SAFe 中，每個開發週期都會進行一次創新和規劃迭代。 它充當上下文切換器，支持通常被其他以交付為重點的框架遺漏的探索和創新過程和活動。 在這個緩衝週實施的活動示例：

• 最終集成解決方案。 在 6 週週期快結束時進行部署時，集成、驗證、文檔和驗證可能仍處於未決狀態。 投入時間有助於確保將新解決方案有效和順利地集成到現有產品中。
• 任務規劃和優先次序。 任務被細化，分成小批量或大批量，並為下一個開發週期確定優先級。 在確定任務的優先級時，一些公司會實施推介日，在此期間向公司介紹最重要的任務，然後以協作的方式承諾下一個開發週期。
• 黑客馬拉松。 黑客馬拉鬆在初創公司和公司中越來越受歡迎，這要歸功於他們以有趣的方式促進創新、創建社區和建立新知識和技能的能力。 結果將呈現給其他人，並成為任務積壓的候選人。
• 實驗原型開發或副項目。 通常的做法是讓工程師和設計師有時間去做他們決定的任何事情，只要他們展示在緩衝時間結束時完成的工作。
• 工程工作。 通常會執行純工程工作，例如基礎設施開發、測試自動化、技術債務減少和系統遷移。
• 開發新的技能和知識。 知識進化的快速步伐迫使開發人員隨時了解全球趨勢。 緩衝時間適合舉辦現場培訓、實踐社區和技術研討會等。

緩衝期應依賴於確定的知識差距、創新目標和下一個週期的需求。 例如，一周的緩衝期可能如下所示：

容量規劃

根據 Basecamp 聯合創始人 Jason Fried 的說法，在決定下一個開發週期的任務承諾時，一種常見的做法是首先確定小批量或大批量。 大批量是指大的產品特性或功能，而小批量是指較小的迭代或任務。 在給定的示例中，為新功能選擇的任務可以被視為大批量。

這裡的建議很簡單：總是混合使用小批量和大批量。 小批量是估計需要 3-4 週的任務，大批量可能需要 6 週或更長時間。

如果小批量團隊在第 3 週或第 4 週之前完成了任務，商定的演示是評估小隊是否應該繼續努力改進實施的解決方案、幫助另一個小隊、執行新的小批量任務還是開始計劃外的工作。

大批量和小批量的良好混合可以防止人們以 100% 的能力工作，從而使他們能夠在計劃外工作的情況下進行機動和適應。 大批量團隊在周期中盡可能多地關注，而小批量團隊可以處理因意外工作而產生的臨時任務。

結合小批量和大批量也可以降低風險。 只有大批量會增加對用戶體驗產生負面影響的可能性。 如果幾個新功能的發布彼此接近，它們應該伴隨著良好的變更管理。 此外，在計劃外工作的情況下，可用容量將減少。 最後，如果幾個大批量的團隊失敗了，迭代可能會被認為是徒勞的，從而使團隊士氣低落。

任務驅動開發的風險

實施任務驅動開發有很多好處，但作為任何規定性框架，它有幾個需要考慮的固有風險。

任務範圍

任務應該是現實的，旨在很好地適應挑戰的複雜性和小隊技能； 否則，對發展成果的影響可能很大。

過於雄心勃勃的任務可能會讓人感到沮喪和焦慮，從而對小隊的表現產生負面影響。 另一方面，不熱情的任務可能會導緻小隊士氣低落和無聊。 因此，最小可行產品的心態應該在框架內保持不變。

使命的原因

強大的業務任務應該對問題空間及其與公司願景的關係有一個全面的定義。 如果這種關係不明確，由於缺乏對問題解決如何影響公司目標的了解，可能會丟失有價值的見解。

瀑布陷阱

在六週內陷入瀑布模型是小隊的自然趨勢。 這有兩個主要因素。 首先，部署壓力在周期快結束時更大。 其次，小隊希望在任務中盡可能多地壓縮範圍，從而導致在開發週期結束時進行部署的緊迫性。 因此，應鼓勵持續交付實踐以在整個週期中實現敏捷發布並避免與瀑布相關的風險。

產品運營

管理基礎設施、服務或監控組件等產品運營任務應保持在小隊範圍之外，因為它們可能會影響速度。 依賴於原子設計等開發標準和實踐可以減少開發工作，從而加速擴展。 該框架下的另一種常見做法是，除了管理產品運營和監控之外，還有一個中央運營團隊負責處理基礎設施。

6 週週期作為短視框架

有些場景對於框架來說是不夠的。 在處理可能對客戶體驗產生巨大影響的大型複雜系統時尤其如此，例如研發項目或關鍵系統的遷移。

擴展敏捷的輕量級選項

擴展敏捷以跟上產品開發和公司發展的步伐是敏捷從業者的潛在挑戰。 作為最近開發的敏捷方法，任務驅動開發框架因其易於使用和實施而在公司中廣受歡迎。 MDD 框架啟動了一個端到端的橫向產品創新過程，從發現到交付，填補了傳統敏捷結構中存在的空白。 任務驅動開發有可能成為成長型公司的新 Scrum。