《敏捷軟件開發：用戶故事實戰》—為什么要改變？

為什么要改變？

你可能會問到這幾個問題：“為什么要改變？為什么要寫故事卡，并保持所有這些對話？為什么不繼續編寫需求文檔或者用例呢？”因為用戶故事展現了許多優于其他方法的優點。在第13章中提供了更多的細節，一些使用用戶故事的原因如下。

l?? 用戶故事強調的是口頭溝通而不是書面溝通。

l?? 用戶和開發人員都可以理解用戶故事。

l?? 用戶故事的大小適合做計劃。

l?? 用戶故事適用于迭代開發。

l?? 用戶故事鼓勵推遲細節，直到你對自己真正需要的東西有了最好的了解。

因為用戶故事的重點在于對話和遠離書面，所以重要的決定不會被記錄在不太可能被閱讀的文檔中。相反，關于故事的重要方面會記錄在自動化驗收測試中頻繁運行。此外，我們避免使用含混不清的書面文檔，比如：

系統必須存儲地址和業務電話號碼或者移動電話號碼。

這是什么意思？這可能意味著系統必須存儲其中一個：

（地址和商務電話）或者移動電話；

地址和（商務電話或者移動電話）；

因為用戶故事沒有技術術語（請記住，是客戶團隊編寫了這些業務術語），所以無論是開發人員還是客戶團隊都可以理解它們。

每個用戶故事都代表一個獨立的功能塊，換言之，就像用戶在一個單一環境下可能做的事情。這使得用戶故事適合成為一種做計劃的工具。你可以評估在不同的發布版本之間調整故事順序的價值，這遠勝于估計去掉一個或者多個“系統應該……”類似陳述所產生的影響。

迭代過程是一個逐步求精的過程。開發團隊對系統進行第一次切割實現，知道它在某些（可能是許多）區域是不完整的或者薄弱的。然后，他們不斷細化這些領域，直到產品令人滿意為止。每一次迭代都通過增加更多細節來改進軟件。對于迭代開發來說，故事可以很好地適用，因為它也可以迭代這些故事。對于一個你最終想要的但現在并不重要的特性，你可以先寫一個大的故事（一個史詩）。當你準備把這個故事添加到系統中，你可以丟棄史詩，用更小的故事來代替、并且完善它。

允許故事鼓勵細節延遲，使故事集能夠迭代這一能力得以體現。假如今天你為系統的一部分編寫了一個占位符史詩，就沒有必要寫出這部分的故事，除非馬上就要開發實現這部分。推遲確定細節是很重要的，因為它允許我們在不確定新特性是否真的被需要之前就不需要花費時間去考慮。故事勸阻我們不要假裝知道并事先寫下所有東西，相反，故事鼓勵這樣一個過程：在客戶團隊和開發人員之間的討論中，軟件被迭代細化。

敏捷開發 軟件開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。