故事是敏捷中用來定義系統行為的主要工件。它們是功能的簡短描述，通常從用戶的角度用用戶的語言編寫。每個故事的目的是實現壹個小的、垂直的系統行為片段，以支持增量開發。
這個故事為商業人士和技術人員理解其意圖提供了足夠的信息。故事的細節將被推遲，直到故事準備實施。通過驗收標準和驗收測試，故事變得更加具體，並有助於確保系統的質量。
用戶故事直接向最終用戶交付功能。啟用者故事帶來了支持探索、架構、基礎設施和法規遵從性所需的工作項目的可見性。
SAFe的需求模型描述了工件的四層結構，它概述了功能系統的行為:史詩、能力、特征和故事。它們描述了創建解決方案預期行為的所有工作。但是詳細的實現工作是用故事來描述的，這些故事構成了團隊Backlog。大多數故事來自於“計劃積壓”中的業務和使能特性，壹些故事來自於團隊識別的工作。
每個故事都是壹個小的、獨立的行為，可以逐漸實現，為用戶或解決方案提供壹定的價值。它是壹個垂直切片的功能，確保每次叠代都能帶來新的價值。要將故事分割得相對較小，必須在壹次叠代中完成(參見關於分割故事的部分)。
通常，故事會先寫在索引卡或便條上。索引卡的物理性質在團隊、故事和用戶之間建立了壹種有形的關系:它有助於整個團隊參與故事的寫作。便利貼還提供了其他好處:它們有助於作品的可視化，可以很容易地放在墻上或桌子上，按順序重新排列，甚至在必要時傳閱。故事可以讓人更好地理解工作的範圍和進度:
雖然任何人都可以編寫故事，但是產品負責人有責任批準它們進入團隊待辦事項列表，並接受它們進入系統基線。當然，便利貼無法在整個企業中很好地擴展，所以故事通常會很快轉移到ALM(敏捷生命周期管理)工具中。
在SAFe中，有兩種類型的故事，即用戶故事和授權故事，如下所述。
如圖1所示，故事通常由業務和使能特性的分離所驅動。
用戶故事是表達所需功能的主要方式。它們在很大程度上取代了傳統的需求規範。(然而，在某些情況下，它們可用於解釋和開發系統行為，然後記錄這些行為以支持合規性、可追溯性或其他要求。)
因為他們關註的是用戶感興趣的話題，而不是系統，所以用戶故事是以價值為中心的。為了支持這壹點，建議采用“用戶聲音”的形式，如下所示:
通過使用該表格，引導團隊了解誰在使用該系統，他們正在使用該系統做什麽，以及他們為什麽這樣做。經常使用“用戶聲音”的形式，往往會提高團隊的領域能力；他們會更好地理解用戶真正的業務需求。圖2提供了壹個例子。
“人物角色”描述了代表性用戶的具體特征，可以幫助團隊更好地理解他們的最終用戶。圖2中騎手角色的例子可以是壹個令人興奮的“簡”和壹個膽小的騎手“鮑勃”。然後，故事描述會引用這些人物(如簡，我希望……)。
雖然用戶故事語音很常見，但並不是每個系統都會和終端用戶交互。有時“用戶”是壹個設備(如打印機)或壹個系統(如交易服務器)。在這些情況下，故事可以采用圖3所示的形式。
團隊可能需要開發系統架構或基礎設施來實現壹些用戶故事或系統的支持組件。在這種情況下，故事可能不會直接接觸任何最終用戶。這些是支持探索、架構或基礎設施的成功案例。使能故事可以用技術而不是以用戶為中心的語言來表達，如圖4所示。
還有許多其他類型的賦能故事，包括:
與用戶故事壹樣，使能故事通常通過顯示獲得的知識、制造的工件或用戶界面、堆積或模擬來顯示。
壹個好的故事需要多個視角。在敏捷中，整個團隊(產品所有者、開發人員和測試人員)對要構建的內容有壹個共同的理解，以減少返工並提高吞吐量。團隊使用行為驅動開發(BDD)來協作，定義詳細的驗收測試，並清楚地描述每個故事。好的故事需要多角度思考:
共同編寫壹個故事，可以保證所有觀點都被考慮，每個人對故事的行為都有* * *的理解，結果體現在故事的描述、驗收標準和驗收測試中。驗收測試是使用系統的領域語言和行為驅動開發(BDD)編寫的。然後，BDD測試將自動執行並持續運行，以保持內置質量。BDD測試是根據系統需求(故事)編寫的，因此它可以作為系統行為的確定性陳述，而不是基於文檔的規範。
XP的發明者之壹Ron Jeffries被認為是第壹個提出3C方法來描述故事的人:
敏捷團隊通常用業務可讀的領域特定語言自動執行驗收測試。自動化創建壹個可執行的規範來驗證和確認解決方案。自動化還提供了系統快速回歸測試的能力，從而增強了持續集成、重新配置和維護的能力。
Bill Wake [1]開發的投資模型描述了優秀用戶故事的特征:
敏捷團隊使用故事點和“評估撲克”來評估他們的工作[1，2]。壹個故事點是壹個單壹的數字，它代表了以下特征的組合:
故事點是相對的，與任何具體的計量單位無關。每個故事的大小(工作量)是相對於最小的故事來估算的，最小的故事被賦予“1”的大小。應用修正的斐波那契數列(1，2，3，5，8，13，20，40，100)來反映估計中固有的不確定性，特別是大的數字(如20，40，100) [
敏捷團隊經常使用“評估撲克”，它結合了專家意見、類比和分解來創建快速但可靠的評估。分解是指將壹個故事或特征分成更小的部分，以便於評估。
(請註意，還有壹些其他方法在使用。)估計撲克的規則是:
進行壹些初步的設計討論是合適的。然而，花太多時間在設計討論上往往是浪費精力。評估撲克的真正價值在於同意壹個故事的範圍。這也是壹種樂趣！
團隊在叠代中的速度等於所有滿足完成定義(DoD)的已完成故事的故事點的總和。隨著團隊的不斷合作，他們的平均速率(每次叠代中完成的故事點)將變得可靠和可預測。可預測的速度有助於計劃和限制WIP，因為團隊承擔的故事數量不會超過其歷史速度所允許的範圍。這種方法也用於估計交付史詩、特性、能力和推動者所需的時間，這也可以通過使用故事點來預測。
能力指的是團隊比率中可以實際用於任何特定叠代的部分。假期、培訓和其他事件將阻止團隊成員在某些部分為叠代的目標做出貢獻。這降低了團隊在該叠代中的最大潛在速率。例如，壹個平均每次叠代交付40分的團隊，如果團隊成員休假壹周，他們的最高比率將被調整為36分。提前知道這壹點，團隊在叠代規劃中只承諾了最多36個故事點。這也有助於預測PI計劃期間PI中每個叠代的實際可用容量，以便團隊在構建PI目標時不會過度承諾。
在標準的Scrum中，每個團隊的故事點估計和由此產生的比率是團隊內部的獨立事務。從規模敏捷性的角度來看，當團隊之間的速度基準差異很大時，將很難預測更大的史詩和特征的故事點大小。為了克服這個問題，SAFe團隊將首先校準壹個起始故事點基準，在這個基準上，所有團隊都有大致相同的故事點定義。沒有必要重新校準團隊評估或比率。當新的agile發行系列啟動時，將會執行校準。
標準化故事點為故事和費率提供了壹種達到商定的起始基準的方法，如下所示:
例:假設壹個6人團隊由3個開發人員、2個測試人員和1個PO組成，沒有請假和假期，那麽估計初始率=5×8分=40分/叠代。(註:如果開發人員和測試人員中有壹人兼職，可能需要降低)。
這樣各隊的故事點就有了壹定的可比性。管理層可以更好地了解故事點的成本，並更準確地確定即將推出的功能或史詩的成本。
雖然隨著時間的推移，團隊傾向於提高速度是壹件好事，但事實上，這個數字傾向於保持穩定。團隊的速度受團隊規模和技術環境變化的影響遠遠大於生產力變化的影響。
較小的故事將導致更快和更可靠的實現，因為小項目在任何系統中都更快、更少變化和更少風險。所以，把壹個較大的故事拆分成較小的故事，是每個敏捷團隊必備的技能。這不僅是增量開發的藝術，也是壹門科學。Leffingwell的敏捷軟件需求[1]介紹了十種拆分故事的方法。以下是這些技術的總結:
圖6顯示了壹個用例場景分割的例子:
正如文章《安全需求模型》中所描述的，這個框架應用了壹系列的工件和連接，以壹種精益和敏捷的方式來管理復雜系統的定義和測試。圖7說明了故事在外管局全局中的作用。
在伸縮敏捷性中，故事通常(但不總是)由新特性創建。而且每個故事都有驗收測試，可能還有單元測試。單元測試主要是保證故事的技術實現是正確的。同時，它也是測試自動化的壹個關鍵起點，因為單元測試可以很容易地自動化，這在論文測試驅動開發(TDD)中有所描述。
註意:圖7使用統壹建模語言(UML)符號來表示對象之間的關系:零到多(0...*)，壹對多(1...*)、壹對壹(1)等等。
最後更新:17 12月2019