敏捷開發實踐：使用者故事與持續發現

– 15 分鐘閱讀

敏捷開發的核心就在於快速迭代和持續回饋，而使用者故事和持續發現正是實作這一目標的關鍵。使用者故事能幫助團隊聚焦於使用者需求，並將複雜的功能拆解成可管理的小單元，而持續發現則確保團隊始終走在正確的道路上，避免開發出使用者不需要的功能。這兩種方法相輔相成，共同構成了敏捷開發的基本，讓團隊能夠更有效地應對變化，交付更有價值的產品。

啟動階段的成功標準

一個成功的啟動階段應該能夠達到以下幾個目標：

  1. 共同的願景和商業價值：所有團隊成員和利益相關者應該對於產品的願景、商業價值和範圍有相同的理解。
  2. 優先順序的使用者故事：根據客戶價值，優先順序的使用者故事應該被識別和優先排序。
  3. 產品路線圖：根據高階別的工作量估算和交付頻率，應該有一個清晰的產品路線圖。
  4. 績效指標：應該有明確的績效指標來衡量是否按計劃進行。
  5. 風險、假設、問題和依賴：應該有對主要風險、假設、問題和依賴的清晰理解。

使用者故事的重要性

使用者故事是敏捷開發中的一個基本概念，它代表著對於產品功能的最小單位的描述。一個好的使用者故事應該能夠獨立交付，並且具有明確的商業價值。使用者故事是將想法、意圖和背景轉化為清晰的接受標準的工具，從而引導團隊成員瞭解需要建造什麼以及何時完成。

使用者故事的定義

使用者故事是一個描述使用者需求的簡短文字，通常遵循以下格式：“作為一名[使用者角色], 我想要[完成某個任務]，以便[實作某個目標]。”使用者故事包含一個或多個接受標準，幫助團隊成員對於需要建造的內容有共同的理解。

接受標準的重要性

接受標準是使用者故事的一部分，幫助團隊成員瞭解需要建造的內容。接受標準應該是明確的、可衡量的、可實作的、相關的和時間敏感的（SMART）。透過接受標準，團隊可以確保他們正在建造正確的東西，並且能夠在開發過程中進行有效的驗證。

垂直切割的使用者故事：打造高效的產品開發流程

垂直切割的使用者故事是一種從使用者角度出發，橫跨應用程式所有層次的功能或產品功能，組織方式能夠從前端到後端的所有層面，包括資料管道和機器學習模型，為使用者提供完整的功能體驗。這種方法與傳統的水平切割故事不同，水平切割故事可能會將功能分解為多個故事，例如資料準備、模型訓練和模型整合等。

垂直切割故事的優點

垂直切割故事的優點在於它能夠提供一個完整的功能體驗，讓使用者能夠從頭到尾地使用產品，同時也能夠幫助開發團隊更好地瞭解使用者的需求和期望。這種方法還能夠減少資訊的丟失和誤解，提高開發效率和品質。

垂直切割故事的格式

一個垂直切割故事通常包括以下幾個部分：

  • 使用者角色：明確的使用者角色，例如「作為一名使用者」
  • 行動/意圖：使用者想要完成的行動或意圖，例如「我想要查詢產品資訊」
  • 期望結果：使用者期望的結果，例如「所以我可以快速找到我需要的產品」

垂直切割故事的範例

以下是一個垂直切割故事的範例： 「作為一名使用者，我想要查詢產品資訊，所以我可以快速找到我需要的產品」

定義完成的標準

定義完成的標準是指在一個專案或使用者故事中，必須完成的專案清單。這些專案可能包括：

  • 符合接受標準
  • 自動化測試透過
  • 佈署到生產環境

垂直切割故事的好處

垂直切割故事能夠提供以下幾個好處：

  • 提高開發效率和品質
  • 減少資訊的丟失和誤解
  • 提供完整的功能體驗
  • 幫助開發團隊更好地瞭解使用者的需求和期望

個人化商品推薦系統

背景

作為一名線上購物者，我們希望能夠看到相關的商品建議，以便我們能夠輕鬆地找到所需的商品。這個系統的目標是提供一個個人化的商品推薦功能，根據使用者的瀏覽和購買記錄，推薦最相關的商品。

需求

  1. 首頁應該顯示一個「為您推薦」的區塊，至少包含五個商品建議。
  2. 商品建議應根據使用者的最近瀏覽和購買活動更新。
  3. 如果使用者購買了一個推薦的商品，系統應該在未來推薦類似的商品。
  4. 使用者應該可以提供反饋意見，例如「不感興趣」，以便於未來的建議更加精確。
  5. 系統不應該重複推薦使用者已經購買或明確標記為不感興趣的商品。

解決方案

為了實作這個系統，我們需要將大故事分解成小故事，以便於開發和交付。這些小故事包括：

  • 建立使用者瀏覽和購買記錄資料函式庫
  • 開發商品推薦演算法
  • 建立使用者反饋機制
  • 更新首頁以顯示推薦商品

分解故事

根據INVEST原則，我們可以將大故事分解成小故事。INVEST是獨立、可協商、有價值、可估計、小且可測試的簡稱。這些原則可以幫助我們確保每個小故事都是獨立的、有價值的、可估計的和可測試的。

獨立

每個小故事應該獨立於其他小故事，以便於開發、優先順序和實施。

可協商

小故事不應該被視為契約，而是作為對話的開始。細節可以根據交付團隊和產品負責人之間的合作進行討論和調整。

有價值

每個小故事都應該為終端使用者或業務帶來價值。如果它不帶來價值，可能不值得將其包含在產品待辦事項中。

可估計

小故事應該是可估計的，以便於計劃和跟蹤進度。

小

小故事應該足夠小，以便於開發和實施。

可測試

小故事應該是可測試的，以便於驗證其是否符合要求。

內容解密：

在這個系統中，我們使用INVEST原則來分解大故事成小故事。這些小故事包括建立使用者瀏覽和購買記錄資料函式庫、開發商品推薦演算法、建立使用者反饋機制和更新首頁以顯示推薦商品。每個小故事都獨立於其他小故事，並且有其自己的價值、可估計性和可測試性。

圖表翻譯：

  graph LR
    A[使用者瀏覽和購買記錄] --> B[商品推薦演算法]
    B --> C[使用者反饋機制]
    C --> D[首頁更新]
    D --> E[個人化商品推薦]

這個圖表顯示了系統的工作流程。使用者瀏覽和購買記錄被用來開發商品推薦演算法，然後使用者反饋機制被用來調整推薦結果。最終，首頁被更新以顯示個人化的商品推薦。

個人化商品推薦的故事分解

在進行敏捷開發時，使用者故事（User Story）是一種強大的工具，幫助團隊瞭解需求並將其分解為可管理的任務。然而，在機器學習（ML）領域，使用者故事的應用可能會更加複雜。讓我們以「個人化商品推薦在首頁」為例，探討如何將其分解為較小的使用者故事。

個人化商品推薦的挑戰

個人化商品推薦涉及多個因素，包括使用者行為、商品特徵和商業目標。要將其分解為小的使用者故事，我們需要考慮以下幾個方面：

  1. 使用者行為分析：瞭解使用者的購買習慣、瀏覽記錄和搜尋偏好。
  2. 商品特徵提取：從商品資料中提取有用的特徵，例如類別、品牌和描述。
  3. 推薦演算法：選擇合適的推薦演算法，例如協同過濾或根據內容的過濾。
  4. 商業目標：將推薦結果與商業目標對齊，例如增加銷量或提高使用者滿意度。

分解使用者故事

根據上述挑戰，我們可以將「個人化商品推薦在首頁」分解為以下小的使用者故事：

  • 使用者行為分析：
    • 使用者故事1：根據使用者的購買記錄，建立使用者購買習慣的模型。
    • 使用者故事2：根據使用者的瀏覽記錄，建立使用者瀏覽習慣的模型。
  • 商品特徵提取：
    • 使用者故事3：從商品資料中提取類別、品牌和描述等特徵。
    • 使用者故事4：根據商品特徵，建立商品之間的關聯模型。
  • 推薦演算法：
    • 使用者故事5：實作協同過濾演算法，根據使用者行為和商品特徵進行推薦。
    • 使用者故事6：實作根據內容的過濾演算法，根據商品特徵和使用者偏好進行推薦。
  • 商業目標：
    • 使用者故事7：根據推薦結果，計算銷量和使用者滿意度的指標。
    • 使用者故事8：根據商業目標，調整推薦演算法和模型的引數。

個人化推薦系統的垂直切割

個人化推薦系統是一個龐大且複雜的專案，需要將其分解成較小的使用者故事，以便於開發和實作。以下是如何將個人化推薦系統的使用者故事分解成較小的使用者故事的例子。

使用者故事 1：基本推薦功能

作為一個線上購物者，我希望看到一個根據我購買歷史的產品推薦列表，以便我可以找到可能感興趣的商品。 接受標準：

  • 首頁顯示一個「為您推薦」的區塊，包含五個商品。
  • 產品推薦根據最近的購買記錄。
  • 我們有一個機制來評估生產環境中推薦的品質。

使用者故事 2：實驗和調查

使用者故事 2是一個時間盒實驗或調查，旨在幫助團隊減少不確定性，測試假設，並快速學習。 實驗的結果將告訴我們是否可以實作使用者故事 3中描述的功能，並且如何實作它。 後續在討論雙軌交付時，您可以看到如何使用實驗和調查來促進機器學習專案的持續發現。

使用者故事 3：根據強化學習的推薦

作為一個線上購物者，我希望看到一個根據我購買歷史和互動記錄的產品推薦列表，以便我可以找到可能感興趣的商品。 接受標準：

  • 首頁顯示一個「為您推薦」的區塊，包含五個商品。
  • 產品推薦根據最近的購買記錄和互動記錄。
  • 我們有一個機制來評估生產環境中推薦的品質。

實驗和調查的結果

從實驗和調查中，我們可以學習到以下內容：

  • 提取或生成一些代表性的資料：使用者與商品的互動記錄和結果。
  • 確定一個或多個可行的強化學習技術。

結果

個人化推薦系統的垂直切割可以幫助我們更好地理解專案的複雜性和需求，並且可以讓我們更好地實作使用者的需求和期望。

  flowchart TD
    A[使用者故事 1：基本推薦功能] --> B[使用者故事 2：實驗和調查]
    B --> C[使用者故事 3：根據強化學習的推薦]
    C --> D[實驗和調查的結果]
    D --> E[結果]

圖表翻譯：

上述圖表顯示了個人化推薦系統的垂直切割過程。首先，我們有使用者故事 1：基本推薦功能，然後是使用者故事 2：實驗和調查，最後是使用者故事 3：根據強化學習的推薦。實驗和調查的結果將告訴我們是否可以實作使用者故事 3中描述的功能，並且如何實作它。最終的結果將是個人化推薦系統的實作。

個人化實時推薦系統

系統概述

實時推薦系統是一種能夠根據使用者的即時行為和偏好提供個人化推薦的系統。這種系統可以應用於各種領域，例如電子商務、內容推薦等。

使用者故事

使用者故事1：實時推薦

作為一名線上購物者，我希望能夠看到根據我當前瀏覽的內容推薦的產品列表，以便我能夠發現對我有趣的專案。

使用者故事2：避免重複推薦

作為一名線上購物者，我不希望看到我已經購買或標記為不感興趣的產品，以便我能夠看到多樣化的新推薦。

使用者故事3：反饋機制

作為一名線上購物者，我希望能夠對推薦的產品提供反饋，以便未來的建議能夠更好地符合我的口味。

系統設計

實時資料處理

系統需要能夠處理使用者的實時資料，例如瀏覽記錄、購買記錄等。這些資料需要被儲存和分析，以便提供個人化的推薦。

推薦演算法

系統需要使用適合的推薦演算法，例如協同過濾、內容基礎過濾等。這些演算法需要被訓練和最佳化，以便提供最好的推薦。

反饋機制

系統需要提供反饋機制，讓使用者能夠對推薦的產品提供反饋。這些反饋需要被收集和分析，以便改進系統的效能。

效能評估

系統的效能需要被評估，以便確保它能夠提供高品質的推薦。這些評估需要包括使用者滿意度、推薦的準確性等指標。

時間估計

實作這個系統需要大約5天的時間，包括設計、開發和測試。

技術選型

系統需要使用適合的技術，例如Python、Rust、Mojo等。這些技術需要被選擇和最佳化，以便提供最好的效能。

實時推薦系統架構

系統的架構需要包括以下幾個部分：

  • 資料收集：收集使用者的實時資料，例如瀏覽記錄、購買記錄等。
  • 資料分析：分析收集的資料，例如使用者的偏好、購買習慣等。
  • 推薦演算法：使用適合的推薦演算法，例如協同過濾、內容基礎過濾等。
  • 反饋機制：提供反饋機制，讓使用者能夠對推薦的產品提供反饋。
  • 效能評估：評估系統的效能，以便確保它能夠提供高品質的推薦。

瞭解使用者故事的細節量

在評估使用者故事的細節量時，團隊成員之間的溝通和共識是非常重要的。透過團隊成員的提問和討論，可以確定是否具備足夠的細節以進行開發工作。

使用者故事的精煉和估算

在交付過程中，使用者故事的精煉和估算是評估細節量的重要步驟。團隊成員可以透過討論和提問來確定是否具備足夠的細節，以進行開發工作。這個過程可以幫助團隊成員達成共識，避免誤解和爭議。

高效交付團隊的特點

高效交付團隊通常具有以下特點：

  • 團隊成員之間具有豐富的溝通和討論
  • 團隊成員具有強烈的共識和合作意識
  • 團隊成員不怕問問題和提出意見
  • 團隊成員具有強烈的學習和改進意識

交付過程的重要性

交付過程是整個專案中最重要的部分，因為它涉及到最多的成本、時間和努力。同時，交付過程也容易出現一些常見的陷阱，例如：

  • 未計劃或隱藏的工作
  • 範圍蔓延
  • 優先順序別的變化
  • 未識別的依賴關係

交付活動和持續發現

交付活動和持續發現是交付過程中非常重要的兩個方面。交付活動可以幫助團隊成員建立一個穩定的交付節奏，而持續發現可以幫助團隊成員不斷學習和改進。

測量進度和品質

測量進度和品質是交付過程中非常重要的兩個方面。透過測量進度和品質，團隊成員可以瞭解是否正在朝著正確的方向前進，是否需要進行調整和改進。

# 測量進度和品質的例子
class ProgressTracker:
    def __init__(self):
        self.progress = 0
        self.quality = 0

    def update_progress(self, progress):
        self.progress = progress

    def update_quality(self, quality):
        self.quality = quality

    def get_progress(self):
        return self.progress

    def get_quality(self):
        return self.quality

# 建立一個進度追蹤器
tracker = ProgressTracker()

# 更新進度和品質
tracker.update_progress(50)
tracker.update_quality(80)

# 取得進度和品質
print(tracker.get_progress())  # 輸出: 50
print(tracker.get_quality())  # 輸出: 80

交付過程的最佳實踐

交付過程中有一些最佳實踐可以幫助團隊成員避免常見的陷阱和提高交付效率。這些最佳實踐包括：

  • 建立一個穩定的交付節奏
  • 不斷學習和改進
  • 測量進度和品質
  • 團隊成員之間具有強烈的溝通和合作意識
  graph LR
    A[交付過程] --> B[交付活動]
    B --> C[持續發現]
    C --> D[測量進度和品質]
    D --> E[最佳實踐]
    E --> F[提高交付效率]

圖表翻譯：

此圖表描述了交付過程中不同階段的關係。交付過程（A）包括交付活動（B）、持續發現（C）和測量進度和品質（D）。這些階段最終導致最佳實踐（E），從而提高交付效率（F）。

敏捷開發流程中的迭代規劃和團隊協作

在敏捷開發中，迭代規劃是一個至關重要的步驟，幫助團隊明確目標和範圍，確保每個成員都在同一頁上。這個過程涉及到團隊成員、產品經理和其他利益相關者共同參與，共同定義下一個迭代的目標和工作內容。

迭代規劃的重要性

迭代規劃不僅僅是選擇哪些工作專案加入下一個迭代，而是要確保這些工作專案與團隊的整體目標和優先順序相符。透過這個過程，團隊可以避免在不重要的工作上浪費時間和資源，同時也能夠更好地管理自己的工作量和速度。

每日站立會議

每日站立會議是一種簡單而有效的團隊協作方式，讓團隊成員可以快速同步工作進度和分享遇到的問題。這種會議通常在每天的早晨進行，時間短暫，內容集中，能夠有效地提高團隊的協作效率和工作品質。

故事交付和工作流程

在敏捷開發中，故事交付是指團隊完成特定工作專案的過程。這個過程通常涉及到分析、開發和測試等多個階段，團隊成員可以根據自己的專長和工作安排，選擇負責哪個階段的工作。透過每日站立會議和其他協作機制，團隊可以確保工作的順暢進行和品質的控制。

定期展示和回顧

定期展示是團隊展示工作成果和分享經驗的機會，也是收集反饋和改進工作的重要途徑。通常在迭代結束時進行，展示可以幫助團隊成員和利益相關者更好地理解工作進度和成果，同時也能夠收集到寶貴的反饋，幫助團隊在未來的工作中改進和最佳化。

玄貓的敏捷開發實踐

玄貓是一位具有豐富實務經驗的技術專家，對於敏捷開發有深刻的理解和實踐。透過他的分享和經驗，團隊可以學習到如何更好地應用敏捷開發的原則和方法，提高工作效率和品質，實作更好的協作和溝通。

內容解密：

以上內容簡要介紹了敏捷開發中的迭代規劃、每日站立會議、故事交付和定期展示等重要概念和實踐。透過這些機制和方法，團隊可以更好地協作和管理工作，提高工作品質和效率，實作更好的成果和滿意度。

  flowchart TD
    A[迭代規劃] --> B[每日站立會議]
    B --> C[故事交付]
    C --> D[定期展示]
    D --> E[收集反饋和改進]

圖表翻譯：

這個流程圖展示了敏捷開發中的工作流程，從迭代規劃開始，到每日站立會議、故事交付和定期展示，最終到收集反饋和改進。這個流程強調了團隊協作和溝通的重要性，同時也展示了敏捷開發中各個階段的連貫性和邏輯性。

敏捷開發中的持續改進

在敏捷開發中，持續改進是團隊成功的關鍵。透過定期的展示、回顧、風險管理和架構決策，團隊可以確保自己的工作始終符合組織的目標和需求。

展示

展示是團隊成果的展示，通常在迭代結束時進行。這不僅可以讓團隊成員展示自己的成就，也可以讓利益相關者提供寶貴的反饋和建議。展示可以幫助團隊：

  • 確保自己的工作符合組織的目標和需求
  • 獲得反饋和建議，從而改進自己的工作
  • 展示自己的成就和價值

回顧

回顧是團隊成員反思自己的工作，討論哪些做得好，哪些需要改進。這可以幫助團隊：

  • 學習和改進自己的工作流程
  • 解決問題和挑戰
  • 加強團隊合作和溝通

風險管理

風險管理是指識別和評估風險，然後採取措施來降低或消除風險。這可以幫助團隊：

  • 識別和評估風險
  • 採取措施來降低或消除風險
  • 確保自己的工作符合組織的目標和需求

架構決策

架構決策是指團隊在開發過程中需要做出的決策，例如選擇技術和架構。這可以幫助團隊：

  • 做出明智的決策
  • 確保自己的工作符合組織的目標和需求
  • 加強團隊合作和溝通

持續發現

持續發現是指團隊在開發過程中不斷地學習和改進自己的工作。這可以幫助團隊：

  • 學習和改進自己的工作流程
  • 解決問題和挑戰
  • 加強團隊合作和溝通
  flowchart TD
    A[展示] --> B[回顧]
    B --> C[風險管理]
    C --> D[架構決策]
    D --> E[持續發現]
    E --> A

圖表翻譯：

此圖表展示了敏捷開發中的持續改進流程。從展示開始，團隊成員展示自己的成果，然後進行回顧，討論哪些做得好，哪些需要改進。接下來，團隊進行風險管理，識別和評估風險，然後採取措施來降低或消除風險。然後，團隊做出架構決策，選擇技術和架構。最後，團隊進行持續發現，不斷地學習和改進自己的工作。

內容解密：

敏捷開發中的持續改進是指團隊在開發過程中不斷地學習和改進自己的工作。這包括展示、回顧、風險管理、架構決策和持續發現。透過這些過程，團隊可以確保自己的工作符合組織的目標和需求，同時加強團隊合作和溝通。

持續發現習慣

在產品開發過程中，持續發現習慣是一種重要的方法論。這種方法論強調了持續地與客戶互動，收集反饋，快速原型設計和測試，以便快速驗證或駁斥假設，從而做出資料驅動的決策。

持續發現習慣的實踐

持續發現習慣的實踐包括每週與客戶互動，建立一個持續的反饋流，以便快速原型設計和測試。這種方法使得團隊可以快速驗證或駁斥假設，從而做出資料驅動的決策。

從商業價值視角來看，精確的使用者故事拆解和垂直切割是敏捷開發，特別是機器學習專案成功的基本。分析使用者故事的INVEST原則及應用範例，可以發現，它能有效地將複雜的產品需求，例如個人化推薦系統，拆解成可管理、可驗證的小單元，從而提高開發效率和產品價值。技術限制深析顯示，故事拆解的粒度掌控和與機器學習模型訓練的整合仍是挑戰。團隊需要持續學習如何平衡商業目標、使用者需求和技術可行性，才能有效地將機器學習模型整合到產品中。玄貓認為，對於匯入機器學習的產品團隊，培養持續發現習慣，並將其融入使用者故事的精煉和驗證流程，將是未來提升產品開發效率和市場競爭力的關鍵。

玄貓

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。