《使用者故事與靈活方法》讀書筆記——第二章

第 2 章 編寫故事

優秀的故事的特點：（INVEST）

• 獨立性（Independent）
• 可讨論的（Negotiable）
• 對使用者或客戶有價值的（Valuable to Purchasers or Users）
• 可估計的（Estimatable）
• 小的（Small）
• 可測試的（Testable）

一、獨立的

我們要盡量避免故事間的互相依賴。

假如客戶團隊已經選擇了一個高優先級的故事，但它對一個低優先級的故事有依賴，這就會出現問題。

出現這種依賴時，有兩種方法可以繞過這種依賴。

• 将互相依賴的故事合并成一個大的、獨立的故事。
• 用一個不同的方式去分隔故事。

二、可讨論的

故事是可讨論的。

故事卡是功能的簡短描述，不需要包含所有的相關細節，細節将在客戶團隊和開發團隊的讨論中産生。

若我們把故事卡用于提醒開發人員和客戶進行關于需求的讨論，那麼故事卡包含下面的資訊就變得有意義。

• 一兩句短語，用來提醒開發人員和客戶進行對話。
• 一些注釋，用以表明在對話中亟待解決的問題。

三、對使用者或客戶有價值的

應當避免那些隻對開發人員有價值的故事。

應該避免在故事中出現使用者界面和技術方面的定義。

保證每個故事對客戶或使用者有價值的最好方法是讓客戶來編寫故事。

四、可估計的

故事不可估算的3個原因：

• 開發人員缺少領域知識。
• 開發人員缺少技術知識。

• 故事太大了。

  如何解決：

• 如果開發人員不了解故事，他們應該和寫故事的客戶一起讨論。
• 如果開發人員缺乏所涉及的技術，可以讓一個或多個開發人員去實施極限程式設計（XP）中所謂的探針實驗（spike）。這是一個簡短的試驗，用于研究應用程式的某一方面。一個不可估計的故事就變成了兩個故事：一個快速的探針故事（用來獲得足夠的資訊）和一個故事（真正實作功能）。
• 如果故事太大了，那麼可以将大故事拆分為多個小故事。

五、小的

故事的大小很關鍵，故事太大或太小，都無助于制定計劃。

分割故事

大的故事通常分為以下兩種。

• 複合故事（compound story）

• 複雜故事（complex story）

  複合故事是由多個小的故事組成的史詩故事。

  複雜故事是其本身就很大且不容易分解的故事。如果一個故事因為不确定性而複雜，可以将它分為兩個故事：一個做調研的故事和一個開發故事。

合并故事

有時候，故事太小了，顯得微不足道。

在極限程式設計的團隊中，一個比較好的方法通常是将其合并到需要半天或幾天完成的故事中。

可測試的

故事必須是可測試的。成功通過測試可以證明開發人員正确地實作了故事。

當産品是增量開發的，很多東西變化得很快，昨天能工作的代碼，今天就會出現問題。這時需要自動化測試來幫助你盡早發現這些問題。

小結

• 理想情況下，故事之間是獨立的。故事之間的傳遞順序應該是無關的，可以任意拿一個故事來實作。
• 故事細節由使用者和開發人員讨論得出。
• 故事應該很清晰地展現對使用者或客戶的價值。最好的做法是讓客戶編寫故事。
• 故事可以注釋一些細節，但是過多的細節會使故事難以了解。
• 給故事加上注釋的最好方法是給它編寫測試用例。
• 如果故事太大，複合故事和複雜故事可以分成幾個小的故事。
• 如果故事太小，幾個小故事可以合并成一個較大的故事。
• 故事應該是可以測試的。

開發人員職責

• 幫助客戶編寫故事，這些故事要能提醒你們同客戶交談，不是記錄詳細的需求定義，故事應該對使用者或者客戶有價值，它們是獨立的、可測的、大小合适的。
• 使用對使用者或客戶有價值的術語來描述實作故事所用的技術或者基礎架構資訊。

客戶團隊職責

負責編寫故事，這些故事要能提醒你們同開發人員交談，而不是記錄詳細的需求定義，他們對使用者或你們自己是有價值的，他們是獨立的、可測的、大小合适的。