第 2 章 編寫故事
優(yōu)秀的故事的特點：（INVEST）
- 獨立性（Independent）
- 可討論的（Negotiable）
- 對用戶或客戶有價值的（Valuable to Purchasers or Users）
- 可估計的（Estimatable）
- 小的（Small）
- 可測試的（Testable）
一衷快、獨立的
我們要盡量避免故事間的相互依賴。
假如客戶團隊已經(jīng)選擇了一個高優(yōu)先級的故事姨俩，但它對一個低優(yōu)先級的故事有依賴蘸拔，這就會出現(xiàn)問題。
出現(xiàn)這種依賴時环葵，有兩種方法可以繞過這種依賴调窍。
- 將相互依賴的故事合并成一個大的、獨立的故事张遭。
- 用一個不同的方式去分隔故事邓萨。
二、可討論的
故事是可討論的菊卷。
故事卡是功能的簡短描述缔恳，不需要包含所有的相關(guān)細節(jié)，細節(jié)將在客戶團隊和開發(fā)團隊的討論中產(chǎn)生洁闰。
若我們把故事卡用于提醒開發(fā)人員和客戶進行關(guān)于需求的討論歉甚，那么故事卡包含下面的信息就變得有意義。
- 一兩句短語扑眉，用來提醒開發(fā)人員和客戶進行對話纸泄。
- 一些注釋赖钞，用以表明在對話中亟待解決的問題。
三刃滓、對用戶或客戶有價值的
應(yīng)當(dāng)避免那些只對開發(fā)人員有價值的故事仁烹。
應(yīng)該避免在故事中出現(xiàn)用戶界面和技術(shù)方面的定義。
保證每個故事對客戶或用戶有價值的最好方法是讓客戶來編寫故事咧虎。
四卓缰、可估計的
故事不可估算的3個原因：
開發(fā)人員缺少領(lǐng)域知識。
開發(fā)人員缺少技術(shù)知識砰诵。
故事太大了征唬。
如何解決：如果開發(fā)人員不理解故事，他們應(yīng)該和寫故事的客戶一起討論茁彭。
如果開發(fā)人員缺乏所涉及的技術(shù)总寒，可以讓一個或多個開發(fā)人員去實施極限編程（XP）中所謂的探針實驗（spike）。這是一個簡短的試驗理肺，用于研究應(yīng)用程序的某一方面摄闸。一個不可估計的故事就變成了兩個故事：一個快速的探針故事（用來獲得足夠的信息）和一個故事（真正實現(xiàn)功能）。
如果故事太大了妹萨，那么可以將大故事拆分為多個小故事年枕。
五、小的
故事的大小很關(guān)鍵乎完，故事太大或太小熏兄，都無助于制定計劃。
分割故事
大的故事通常分為以下兩種树姨。
- 復(fù)合故事（compound story）
- 復(fù)雜故事（complex story）
復(fù)合故事是由多個小的故事組成的史詩故事摩桶。
復(fù)雜故事是其本身就很大且不容易分解的故事。如果一個故事因為不確定性而復(fù)雜帽揪，可以將它分為兩個故事：一個做調(diào)研的故事和一個開發(fā)故事硝清。
合并故事
有時候，故事太小了转晰，顯得微不足道耍缴。
在極限編程的團隊中，一個比較好的方法通常是將其合并到需要半天或幾天完成的故事中挽霉。
可測試的
故事必須是可測試的防嗡。成功通過測試可以證明開發(fā)人員正確地實現(xiàn)了故事。
當(dāng)產(chǎn)品是增量開發(fā)的侠坎，很多東西變化得很快蚁趁，昨天能工作的代碼，今天就會出現(xiàn)問題实胸。這時需要自動化測試來幫助你盡早發(fā)現(xiàn)這些問題他嫡。
小結(jié)
- 理想情況下番官，故事之間是獨立的。故事之間的交付順序應(yīng)該是無關(guān)的钢属，可以任意拿一個故事來實現(xiàn)徘熔。
- 故事細節(jié)由用戶和開發(fā)人員討論得出。
- 故事應(yīng)該很清晰地體現(xiàn)對用戶或客戶的價值淆党。最好的做法是讓客戶編寫故事酷师。
- 故事可以注釋一些細節(jié)，但是過多的細節(jié)會使故事難以理解染乌。
- 給故事加上注釋的最好方法是給它編寫測試用例山孔。
- 如果故事太大，復(fù)合故事和復(fù)雜故事可以分成幾個小的故事荷憋。
- 如果故事太小台颠，幾個小故事可以合并成一個較大的故事。
- 故事應(yīng)該是可以測試的勒庄。
開發(fā)人員職責(zé)
- 幫助客戶編寫故事串前，這些故事要能提醒你們同客戶交談，不是記錄詳細的需求定義实蔽，故事應(yīng)該對用戶或者客戶有價值酪呻，它們是獨立的、可測的盐须、大小合適的。
- 使用對用戶或客戶有價值的術(shù)語來描述實現(xiàn)故事所用的技術(shù)或者基礎(chǔ)架構(gòu)信息漆腌。
客戶團隊職責(zé)
負責(zé)編寫故事贼邓，這些故事要能提醒你們同開發(fā)人員交談，而不是記錄詳細的需求定義闷尿，他們對用戶或你們自己是有價值的塑径，他們是獨立的、可測的填具、大小合適的统舀。
