用戶故事與敏捷方法.png

第I部分 起步

第1章 概覽

1. 軟件需求是一個溝通問題荚虚。一旦任何一方再溝通中把持絕對地位洼滚，項目就會遭受損失。如果業(yè)務方把持絕對地位良蒸，他們就會關注軟件功能和交付日期，卻很少關注開發(fā)人員是否能夠同時滿足這兩個目標伍玖，或者開發(fā)人員是否確切地了解需求嫩痰。如果開發(fā)人員把持絕對地位，技術術語就會代替業(yè)務語言窍箍，從而導致開發(fā)人員無法傾聽業(yè)務方的實際需求串纺。P3
2. 用戶故事描述了對用戶、系統(tǒng)或軟件購買者有價值的功能椰棘。用戶故事由以下三方面組成纺棺。P4
   • 一份書面的故事描述，用來做計劃和作為提示邪狞，卡片（Card）祷蝌。
   • 有關故事的對話，用于具體化故事細節(jié)帆卓，對話（Conversation）巨朦。
   • 測試米丘，用于表達和編檔故事細節(jié)且可用于確定故事何時完成，確認（Confirmation）罪郊。
3. 卡片代表客戶用戶故事而不是記錄需求蠕蚜。用戶故事代表對用戶有價值的功能。P4
4. 如果一個故事很大悔橄，我們有時候就稱之為史詩故事（Epic）靶累。史詩故事可以分成兩個或更多的小故事。P5
5. 我們并不需要不斷地分解故事癣疟，直到有一個故事能夠覆蓋每一個細節(jié)挣柬。類似的，用戶故事不需要像典型的需求文檔樣式那樣擴充睛挚。與其寫下這些故事細節(jié)邪蛔，還不如讓開團隊和客戶討論這些細節(jié)，即在這些細節(jié)變得重要時才討論扎狱。P5
6. 故事并不是具有契約性質侧到，達成的協(xié)議將由測試來記錄，這些測試將演示故事是否被正確開發(fā)淤击。P5
7. 用戶的期望最好以驗收測試的形式被記錄下來匠抗。開發(fā)人員如果能了解客戶的期望，他們便能指導什么時候算是完成了客戶要求的功能污抬。P6
8. 客戶為什么要編寫故事汞贸？
   由客戶團隊而不是開發(fā)人員來編寫用戶故事基于兩個原因。首先印机，每個故事必須用商業(yè)語言來寫矢腻，不是用技術術語，這樣一來射赛，客戶團隊可以排列故事的優(yōu)先級多柑，放入迭代和發(fā)布。其次咒劲，作為主要產(chǎn)品構想著顷蟆，客戶團隊所處的位置最適合描述產(chǎn)品行為。P6
9. 一個項目的用戶故事初稿通常是在故事編寫工作坊（workshop）中寫就的腐魂，但用戶故事可以在項目生命周期的任何時候編寫。在故事編寫會上逐纬，大家集思廣益蛔屹，充分想象用戶故事。有了可以開始工作的故事集合后豁生，開發(fā)人員便可以估計每個故事的大小兔毒。P8
10. 客戶團隊和開發(fā)人員一起選擇迭代長度漫贞，可能一周到四周的時間。在項目進行期間將使用同樣的迭代長度育叁。在每輪迭代結束時迅脐，開發(fā)人員將負責發(fā)布完全可用的應用程序子集『浪裕客戶團隊在迭代期間高度參與谴蔑，與開發(fā)人員談論迭代期間正在開發(fā)的故事黔攒。在迭代期間渐北，客戶團隊也會詳細定義測試话肖，并且跟開發(fā)人員一起編寫運行自動化測試宙地。此外崖疤，客戶團隊要確保項目能夠達成交付所需產(chǎn)品的目標筷笨。P8
11. 一旦確定迭代長度拯钻，開發(fā)人員就會估計每輪迭代中可以做多少事情膀估。我們稱之為速率（velocity）躁倒。團隊的第一速率估計可能是錯誤的荞怒，因為無法事先知道團隊的速率。然后秧秉，我們可以用初步估算來勾勒出大致的藍圖或者發(fā)布計劃褐桌，用以說明在每輪迭代中會完成哪些工作，需要多少輪迭代周期福贞。P8
12. 為了做發(fā)布計劃撩嚼，我們把故事排列成許多堆，每一堆代表一輪迭代挖帘。每一堆包含一定數(shù)量的故事完丽，其中故事的估算中和不超過事先估算的速率。最高優(yōu)先級的故事放在第一堆拇舀。當那一個堆放滿以后逻族，次高優(yōu)先級的故事放入第二堆（代表第二輪迭代）。這樣持續(xù)進行骄崩，直到已經(jīng)有很多堆故事需要完成聘鳞，估計會占用完這個項目的時間為止，或者直到這些故事堆已經(jīng)可以代表產(chǎn)品的一個新發(fā)布計劃為止要拂。P8
13. 在每輪迭代開始前抠璃，客戶團隊可以在中途修正計劃。當?shù)Y束后脱惰，我們可以得知開發(fā)團隊的實際速率搏嗡，然后用它代替估算速率進行估算。這意味著每一堆故事可能需要通過增加或者移除來進行調(diào)整。有些故事可能比預期的簡單很多采盒，所以有時開發(fā)團隊想在迭代中完成另外的故事旧乞。但有些故事比預期的難，這時就要把有些工作移到下一輪迭代或者下一個發(fā)布計劃中去完成磅氨。P9
14. 一個發(fā)布由一個或多倫迭代組成尺栖。發(fā)布規(guī)劃指的是確定項目時間表和預期功能集合之間達到平衡。迭代規(guī)劃涉及選擇迭代包含的故事烦租⊙佣模客戶團隊和開發(fā)人員在發(fā)布和迭代規(guī)劃中都要參與。P9
15. 客戶團隊首先從排列故事優(yōu)先級開始左权。在排列優(yōu)先級時皮胡，他們要考慮下面幾點。P9
    • 大部分用戶和客戶對特定特性的渴望程度赏迟。
    • 小部分重要用戶和客戶對特定特性的渴望程度屡贺。
    • 故事之間的關系。例如锌杀，“縮兴φ弧（zoom out）”這個故事的優(yōu)先級可能不高，但是它可能被看作是高優(yōu)先級的糕再，因為它與高優(yōu)先級的另一個故事“放大（zoom in）”互補量没。
16. 在許多故事的優(yōu)先級上，開發(fā)人員可能與客戶團隊意見相左突想。他們可能基于技術風險方面的考慮殴蹄，或者由于某個故事是其他故事的互補故事，而建議改變故事的優(yōu)先級猾担∠疲客戶團隊應該傾聽他們的觀點，但是隨后排列故事優(yōu)先級時绑嘹，應該堅持客戶組織利益最大化的原則稽荧。P9
17. 為發(fā)布中的所有迭代分配故事后，發(fā)布計劃便“浮出水面”工腋。要確保每輪迭代中分配的故事點數(shù)不超過開發(fā)團隊預期的速率姨丈。P10
18. 為什么編寫用戶故事而不繼續(xù)編寫需求文檔或者用例（use case）?P12
    • 用戶故事強調(diào)對話交流而不是書面溝通。
    • 用戶故事可以同時被你和開發(fā)人員理解擅腰。
    • 用戶故事的大小適合于做計劃蟋恬。
    • 用戶故事適用于迭代開發(fā)。
    • 用戶故事鼓勵推遲考慮細節(jié)趁冈，直到你非常清楚地了解自己的真正需求筋现。
19. 由于用戶故事沒有技術術語（記住，它們是由客戶團隊編寫的）箱歧，所以開發(fā)人員和客戶團隊雙方都能理解矾飞。P12
20. 總結。P13
    • 故事卡包含對用戶或者客戶有價值的功能的簡短描述呀邢。
    • 故事卡是故事的可見部分洒沦，但客戶團隊和開發(fā)人員關于故事的對話更重要。
    • 客戶團隊包括哪些確保軟件符合潛在用戶需求的人价淌，可以包括測試人員申眼、產(chǎn)品經(jīng)理、實際用戶和交互設計師蝉衣。
    • 故事卡由客戶團隊編寫括尸，因為他們最了解如何表達需要實現(xiàn)的需求，也因為他們會在后期與開發(fā)人員共同確定故事細節(jié)并安排故事的優(yōu)先級順序病毡。
    • 按照故事對客戶的價值來安排故事的優(yōu)先級順序濒翻。
    • 將各個故事放入迭代，進行發(fā)布與迭代規(guī)劃啦膜。
    • 速率是開發(fā)人員可以在一輪迭代中完成的工作量有送。
    • 放入一輪迭代的故事估計總和不能超過事先開發(fā)人員預計的速率。
    • 如果故事太大以至于無法在一輪迭代中完成僧家，可以考慮把它分成兩個或更多的小故事雀摘。
    • 驗收測試用于驗證實現(xiàn)的故事是否開發(fā)成符合客戶團隊的設想。
    • 用戶故事是很有意義的八拱，因為他們強調(diào)口頭交流阵赠，你和開發(fā)人員都可以理解，可以用于進行迭代計劃肌稻，在迭代開發(fā)過程中能很好地工作清蚀，而且因為他們鼓勵推遲細節(jié)。

第2章 編寫故事

1. 一個優(yōu)秀的故事應該具備以下特點（INVEST）：P15
   • 獨立的（Independent）
   • 可討論的（Negotiable）
   • 對用戶或客戶有價值的（Valuable to Purchasers or Users）
   • 可估計的（Estimable）
   • 小的（Small）
   • 可測試的（Testable）
2. 獨立的：我們要盡量避免故事間的相互依賴灯萍。出現(xiàn)這種依賴時轧铁，有兩種方法可以繞過這種依賴。P15
   • 將相互依賴的故事合并成一個大的旦棉、獨立的故事齿风。
   • 用一個不同的方式去分割故事。
3. 可討論的：故事是可以討論的绑洛。若我們把故事卡用于提醒開人員和客戶進行關于需求的討論救斑，那么故事卡包含下面的信息就變得有意義。P16
   • 一兩句短語真屯，用來提醒開發(fā)人員和客戶進行對話脸候。
   • 一些注釋，用以表明在對話中亟待解決的問題。
4. 對用戶或客戶有價值的：“每個故事必須對用戶有價值”运沦，這話說起來很誘人泵额，但那是不對的。應當避免那些只對開發(fā)人員有價值的故事携添。P18
5. 可估算的：對開發(fā)人員來說嫁盲，能估算故事的大小（至少猜一下）烈掠，或者是把故事變?yōu)榭捎么a的時間量是很重要的羞秤。一般有一下3個原因會導致故事不可估計。P18
   • 開發(fā)人員缺少領域知識左敌。
   • 開發(fā)人員缺少技術知識瘾蛋。
   • 故事太大了。
6. 當無法估算某個任務時矫限，可以讓一個或多個開發(fā)人員去實施極限編程（XP）中所謂的探針實驗（spike）哺哼。開發(fā)人員不需要做十分深入的研究，只要能夠答題了解足夠信息來估算這個任務即可奇唤。探針試驗本身總是會限定一個最大時間量（稱為時間箱幸斥，timebox），用這個時間量作為探針試驗的估算咬扇。如此甲葬，一個不可估算的故事就變成了兩個故事：一個快速探針故事（用來獲取足夠的信息）和一個故事（真正實現(xiàn)功能）。P19
7. 如果希望暫時不細化系統(tǒng)的一部分功能懈贺，可以考慮寫一兩個史詩故事（epic）经窖。也可以給史詩故事一個大的比較虛的估算值。P20
8. 小的：故事的大小很關鍵梭灿，故事太大或太小画侣，都無助于制訂計劃。使用史詩故事來開展工作會很困難堡妒，因為它們通常包含多個故事配乱。史詩故事需要分成更小的故事。合適的故事大小最終取決于團隊皮迟、它的容量及使用的技術搬泥。P20
9. 史詩故事通常分為以下兩種。P21
   • 復合故事（compound story）：復雜故事是由多個小的故事組成的史詩故事伏尼。
   • 復雜故事（complex story）：復雜故事是其本身就很大且不容易分解的故事忿檩，可以將它分成連個故事：一個做調(diào)研的故事和一個開發(fā)故事。
10. 考慮將探針試驗放在不同的跌代里爆阶。P22
    如果可能燥透，一種較好的做法是把做調(diào)研的故事放在一輪迭代中沙咏，另外的故事放在接下來的一輪或幾輪迭代中。
11. 合并故事班套。P23
    故事太小肢藐，在極限編程的團隊中，一個比較好的方法通常是將其合并到需要半天活幾天完成的故事中孽尽。
12. 可測試的：故事必須是可測試的窖壕。成功通過測試可以證明開發(fā)人員正確地實現(xiàn)了故事。P23
13. 小結杉女。P24
    • 理想情況下，故事之間是獨立的鸳吸。有時很難做到這一點熏挎，但我們要盡量實現(xiàn)這一目標。故事之間的交付順序應該是無關的晌砾，可以任意拿一個故事來實現(xiàn)坎拐。
    • 故事細節(jié)由用戶和開發(fā)人員討論得出。
    • 故事應該很清晰地體現(xiàn)對用戶和客戶的價值养匈。最好的做法是讓客戶編寫故事哼勇。
    • 故事可以注釋一些細節(jié)，但是過多的細節(jié)會使故事難以理解呕乎，也可能給人一種開發(fā)人員和客戶無需交談的錯覺积担。
    • 給故事加上注釋的最好方法是給它編寫測試用例。
    • 如果故事太大猬仁，復合故事和復雜故事可以分成幾個小的故事帝璧。
    • 如果故事太小，幾個小故事可以合并成一個較大的故事湿刽。
    • 故事應該是可以測試的的烁。

第3章 用戶角色建模

1. 在編寫故事前識別用戶角色、角色建模诈闺、角色映射和虛構人物有很多好處渴庆。P27
2. 把這些單獨的客戶進行分組，把每一類作為一種“用戶角色（User Role）”雅镊。用戶角色是一組屬性的集合襟雷，這些屬性刻畫了一群人的特征以及這群人與系統(tǒng)可能的交互。P28
3. 我們將使用一下步驟來識別漓穿、選擇有用的用戶角色集合嗤军。P28
   • 通過頭腦風暴，列出初始的用戶角色集合晃危。
   • 整理最初的角色集合叙赚。
   • 整合角色老客。
   • 提煉角色。
4. 別了識別用戶角色震叮，客戶和開發(fā)人員（多多益善）聚集在一個房間里胧砰，房間里要有一張大桌子或一堵墻，這樣他們就有地方粘貼或者固定卡片苇瓣。理想情況是在項目啟動時尉间，把團隊所有成員聚集在一起進行用戶角色建模。P29
5. 一個用戶角色是一個用戶：對項目的角色進行頭腦風暴時击罪，要堅持“已確認的角色代表的是單一用戶”的原則哲嘲。P29
6. 整理最初的角色集合。P30
   接下來需要整理這些角色媳禁。在桌子上或墻上移動卡片的位置眠副，以表明角色之間的關系。對于有重疊的角色竣稽，把它們相應的卡片也重疊在一起囱怕。如果角色只有一點點重疊，那么卡片也只重疊一點點毫别。如果角色完全重疊娃弓，那么卡片也完全重疊。P31
7. 系統(tǒng)角色岛宦。P31
   盡量堅持一個原則：用戶角色定義的是人台丛，而不是其他外部系統(tǒng)。如果覺得有幫助恋博，可以偶爾確認一個非人物的系統(tǒng)角色（non-human user role）齐佳。然而，確認用戶角色的目的是確保我們很周到地為用戶考慮债沮，我們要絕對地炼吴、積極地讓用戶對新系統(tǒng)感到滿意。我們不需要為每一個可以想象得到的系統(tǒng)用戶建立角色疫衩，但需要那些能影響項目成敗的角色硅蹦。由于其他外部系統(tǒng)很少會是我們系統(tǒng)的購買者，它們很少能決定我們系統(tǒng)的成敗闷煤。自然童芹，事情總有例外，若覺得加入一個非人物的系統(tǒng)角色有助于思考系統(tǒng)鲤拿，將它加入也未嘗不可假褪。
8. 整合角色。P32
   在角色分組完成后近顷，試著整合及濃縮角色生音∧瘢可以從完成重疊的卡片入手。首先缀遍，這些卡片的作者描述一下他們的角色究竟代表什么慕匠，在簡短的小組討論之后，再判斷這些角色是否等同域醇。如果等同台谊，那么這些角色要么合并成一個單一的角色（也許可以根據(jù)這兩個初級的角色名取一個新的名字），要么丟掉其中一張角色卡譬挚。
9. 提煉角色锅铅。P32
   給每個角色定義一些特征來建立角色的模型。角色特征是關于同屬于這一類的用戶的事實或有用的信息殴瘦。任何可以區(qū)分這個角色的信息都可以用來做該角色的特征狠角。這里有一些適用于任何角色建模的角色特征。
   • 用戶使用軟件的頻率蚪腋。
   • 用戶在相關領域的知識水平。
   • 用戶使用計算機和軟件的總體水平姨蟋。
   • 用戶對當前正在開發(fā)的軟件的熟悉程度屉凯。
   • 用戶使用該軟件的總體目標。有些用戶注重使用的便攜性眼溶，有些關注豐富的用戶體驗悠砚，等等。
10. 虛構人物堂飞。P33
    識別用戶角色是一個偉大的飛躍灌旧，但對于有些更為重要的用戶角色，再進一步為角色創(chuàng)建一個虛構人物是很值得的绰筛。虛構人物是假想的用戶角色代表枢泰。要注意，應該事先做好充分的市場和目標用戶群調(diào)查铝噩，要確保虛構人物能夠真正代表產(chǎn)品的目標用戶衡蚂。
11. 極端人物。P34
    考慮極端人物很可能會讓你編寫出原本可能遺漏的故事骏庸。
12. 小結毛甲。P35
    • 大部分項目小組只考慮單一的用戶類型。這會導致軟件忽略原本需要的一些用戶類型具被。
    • 為了避免從單一用戶的角度編寫所有故事玻募，要識別與軟件交互的不同用戶角色。
    • 通過對每個用戶角色定義相關特征一姿，可以更清楚地看到不同角色的不同點七咧。
    • 對于有些用戶角色而言跃惫，用代表人物來描述會很有幫助。虛構人物是假想出來的用戶角色代表坑雅。他們有名字辈挂，有照片，還有足夠的相關細節(jié)裹粤，因為對項目成員來說终蒂，很真實。
    • 對于有些應用程序遥诉，極端人物可能有助于搜集原本被遺漏的故事拇泣。
13. 開發(fā)人員職責。P35
    • 負責參與確認用戶角色和虛構人物的過程矮锈。
    • 負責理解每個用戶角色或虛構人物霉翔，以及它們之間的異同。
    • 開發(fā)軟件時苞笨，負責考慮不同的用戶角色對于軟件如何運行的不同偏好债朵。
    • 負責確保在識別和描述用戶角色時，它們只是這個過程中的工具瀑凝，不應超越作為工具之外的任何用途序芦。
14. 客戶職責。P35
    • 負責尋找用戶（多多益善）粤咪，并識別恰當?shù)挠脩艚巧?/li>
    • 負責參與識別用戶角色和虛構人物的過程谚中。
    • 負責確保軟件沒有關注不恰當?shù)挠脩簟?/li>
    • 在編寫故事時，負責確保每個故事都能和至少一個用戶角色或虛構人物聯(lián)系起來寥枝。
    • 開發(fā)軟件時宪塔，負責考慮不同的用戶角色對于軟件如何運行的不同偏好。
    • 負責確保在識別和描述用戶角色時囊拜，它們只是這個過程中的工具某筐，不應超越作為工具之外的任何用途。

第4章 搜集故事

1. 需求本來已經(jīng)存在了艾疟，我們只要讓客戶給我們解釋需求来吩，然后把它們鎖入一個籠子里就可以了。很多需求并不容易想到蔽莱。同樣弟疆，用戶并不知道所有需求，所以不能單純依靠引出盗冷。P37
2. 收集需求就像拖網(wǎng)捕魚一樣怠苔。首先，不同大小的網(wǎng)用來捕獲不同大小的需求仪糖。第一遍我們可以用大網(wǎng)眼的漁網(wǎng)撈一遍需求池柑司，以此得到所有的大需求迫肖。通過這些大需求，形成對軟件的整體感覺攒驰，接下來蟆湖，用網(wǎng)眼稍微小一些的漁網(wǎng)得到中等大小的需求，暫時還不用顧及那些小需求玻粪。P37
3. 冥界項目則承認沒有一種理想的方法可以在一個單一階段獲取到所有的用戶故事隅津。敏捷過程也承認用戶故事有一個時間維度：隨著時間推移以及先前迭代中加入產(chǎn)品的故事，一個故事的相關性（relevance）會有所變化劲室。P38
4. 因為故事會隨著項目的進展二演進伦仍，所以我們需要一些可以反復使用的方法來搜集故事。我們使用的技巧必須是足夠輕量的很洋，并且不咄咄逼人充蓝，可以持續(xù)地、或多或少地應用于故事搜索喉磁。一下是創(chuàng)建故事最有用的一些方法：P39
   • 用戶訪談
   • 問卷調(diào)查
   • 觀察
   • 故事編寫工作坊
5. 用戶訪談谓苟。P39
   只詢問用戶“你們需要什么”是不夠的，大部分用戶不太善于理解协怒，更難以表達他們的真實需求娜谊。詢問開放式的問題好得多，這可以讓調(diào)查對象表達更深入的意見斤讥。如果問封閉式的問題，調(diào)查對象只能回答簡單的是或否湾趾。同樣重要的是要提背景無關的問題芭商。從背景無關的問題開始提問，這樣就有可能從用戶那里獲得更多樣化的回答搀缠。如果從非常具體的問題開始铛楣，則很可能漏掉很多故事。P40
6. 問卷調(diào)查艺普。P41
   問卷調(diào)查會是一種有效的方法簸州，有助于收集已有故事的相關信息。若有一個龐大的用戶群歧譬，那么問卷就是收集有關故事優(yōu)先級信息的好方法岸浑。在需要得到大量用戶關于耨寫具體問題的回答時，問卷是非常有用的瑰步。
7. 鑒于單向溝通的既有特點和時間滯后矢洲，我不建議在捕撈故事時使用問卷調(diào)查。P41
8. 觀察罚随。P41
   觀察用戶實際使用軟件的情況蝌借。這種機會可以讓你快速直接地從用戶那里獲得反饋，從而可以更早星虹、更頻繁地發(fā)布軟件盖桥。
9. 故事編寫工作坊灾螃。P42
   故事編寫工作坊是開發(fā)人員、用戶揩徊、產(chǎn)品客戶和其他對編寫故事有版主的人共同參加的會議腰鬼。在工作坊期間，參與人員編寫盡可能的故事靴拱。此時不對故事排優(yōu)先級垃喊，以后客戶有機會排優(yōu)先級。我認為袜炕，故事編寫工作坊是快速捕撈故事最有效的方法本谜。至少，我建議再開始每個計劃發(fā)布前舉辦故事編寫工作坊偎窘。在通往軟件發(fā)布的路上乌助，總是可以舉辦更多的故事編寫工作坊，但這通常是沒有必要陌知。
10. 在畫用戶故事原型中他托，問一些有助于找到遺漏故事的問題，示例如下仆葡。P44
    • 用戶接下來最有可能做什么赏参？
    • 用戶會在這里犯什么錯誤？
    • 在這里沿盅，用戶會有什么困惑把篓？
    • 用戶需要什么額外的信息？
11. 在故事編寫工作坊期間腰涧，我們應該把重點放在數(shù)量上而不是質量上韧掩。即使最后會用電子方式保存故事，但在工作坊里最好還是用卡片窖铡。只要把想法記下來就行疗锐。最初大家覺得不好的故事經(jīng)過幾個小時候可能就會變得很棒，或者這會激發(fā)我們相出其他故事费彼。另外滑臊，不要為每個故事都陷入長時間的討論中。如果一個故事是多余的或者能夠更好的故事替換敌买，就扔掉這個故事简珠。同樣，當客戶為發(fā)布而確定故事優(yōu)先級時，他可以給不好的故事安排低優(yōu)先級聋庵。P44
12. 有時膘融，一些參與者在工作坊中很難開頭，或者卡在某個點上過不去祭玉。這時不妨看看競爭對手的產(chǎn)品或類似的產(chǎn)品氧映。P44
13. 不要在整個過程中評價某個故事好或壞。一旦參與者覺得大家只是在記錄而不是評價故事脱货，會更樂意參與岛都。P45
14. 小結。P45
    • 能夠引出或捕捉需求這一想法是錯誤的振峻。它有兩個問題的假設：用戶知道所有的需求臼疫；需求一旦被捕捉，就鎖定扣孟，不再改變烫堤。
    • 拖網(wǎng)捕魚的比喻是非常有用的：它說明了需求有不同的大小，需求會隨著時間的推移變化凤价，需要一些技巧來發(fā)現(xiàn)需求鸽斟。
    • 即使敏捷流程支持需求的后期涌現(xiàn)，依然需要對預期的發(fā)布進行展望并開始寫下容易發(fā)現(xiàn)的故事利诺。
    • 我們可以通過用戶訪談富蓄、觀察用戶、問卷調(diào)查和舉辦故事編寫工作坊來發(fā)現(xiàn)用戶故事慢逾。
    • 使用多種方法比過度使用一種方法更能獲得好的效果立倍。
    • 通過開放式、與背景無關的提問更容易獲得有用的答案侣滩，例如帐萎，“告訴我你想怎么搜索工作？”就勝于“你要通過職位名稱來搜索工作嗎胜卤？”
15. 開發(fā)人員職責。P45
    • 負責理解并使用多種技巧來捕撈用戶故事赁项。
    • 負責知道怎么使用開放式和背景無關的提問葛躏。
16. 客戶職責。P45
    • 負責理解并使用多種技巧來捕撈用戶故事悠菜。
    • 負責盡早寫更多的用戶故事舰攒。
    • 作為軟件用戶的主要代表，負責和他們多溝通悔醋。
    • 了解怎么使用開放式和背景無關的提問摩窃。
    • 如果需要關于編寫故事的幫助，負責安排并舉辦一次或多次故事編寫工作坊。
    • 負責確保在捕撈故事過程中考慮所有用戶角色猾愿。

第5章 與用戶代理合作

1. 對于一個項目來說鹦聪，客戶團隊里包括一個或多個真實用戶是極其重要的。雖然其他人可以猜想用戶如何使用軟件蒂秘，但事實上泽本，關鍵往往還在于實際用戶。遺憾的是姻僧，我們很難有機會與實際用戶一起工作规丽。P47
2. 在開發(fā)一個供內(nèi)容使用的項目時，組織可能不愿理讓你完全不受限制地接觸一個或多個用戶撇贺，缺可能讓你接觸用戶的經(jīng)理赌莺。如果用戶的經(jīng)理不是軟件的實際用戶，這其實就是偷梁換柱松嘶。P47
3. 有時候艘狭，用戶的經(jīng)理會從中干預，并且出于自負喘蟆，想在項目中充當用戶的角色缓升。她可能承認自己不是典型的用戶，但她固執(zhí)己見蕴轨，認為自己比她的用戶更知道他們需要什么港谊。當然，在這種情況下橙弱，務必小心歧寺，不要得罪用戶的經(jīng)理。但是為了項目的成功棘脐，在部分圍繞她的同時斜筐，也要想辦法接觸終端用戶。P57
4. 讓開發(fā)經(jīng)理擔任用戶代理蛀缝，是最壞的選擇之一顷链，除非你們開發(fā)的軟件就是給開發(fā)經(jīng)理用的。大部分開發(fā)經(jīng)理對正在開發(fā)的軟件沒有像用戶那樣的親身經(jīng)驗屈梁，而且他們也不是領域專家嗤练。P48
5. 讓銷售人員充當用戶代理是危險的，這會讓大家對正在開發(fā)的產(chǎn)品沒有一個全面的藍圖在讶。對銷售人員來說煞抬，最重要的故事是哪些如果沒有實現(xiàn)就會導致她“丟單”的故事。如果希望軟件是可用的构哺，就要通未來的用戶交流革答。P49
6. 領域專家，有時也稱為主題專家，是非常重要的資源残拐，他們對軟件應用領域的了解程度對軟件的成敗有直接影響途茫。讓領域專家來擔任用戶代理的另一個潛在問題是，最終開發(fā)出的軟件可能僅僅針對那些與領域專家有類似水平的用戶蹦骑。領域專家會傾向于將項目指向合適他們自己的解決方案上進行慈省，但這往往過于負責，對目標用戶群體而言明顯是錯誤的眠菇。P50
7. 了解市場的是營銷團隊边败，而不是用戶。這會導致營銷團隊或者有營銷背景的人更關注產(chǎn)品特性的數(shù)量捎废，而輕視特性的質量笑窜。在很多情況下，營銷團隊可以為相關故事的優(yōu)先級提高層次的知道意見登疗，但他們往往不具備很好的洞察力排截，無法提供故事的具體細節(jié)。P50
8. 如果以前的用戶在不就前還使用過你們的軟件辐益，那么由她來擔任用戶代理是非常耗的断傲。但和其他用戶代理一樣，應該謹慎考慮她的目標和動機是否與實際用戶的完全一致智政。P50
9. 客戶是那些做出購買決定的人认罩，他們不一定是軟件的用戶。P50
10. 如果用培訓師充當用戶代理续捂，你的系統(tǒng)最終只能成為一個容易培訓的系統(tǒng)垦垂。類似的，如果你讓技術支持來充當用戶代理牙瓢，那么你的系統(tǒng)最終只是使得支持工作變得較為容易劫拗。P52
11. 許多業(yè)務和系統(tǒng)分析師是很好的用戶代理，因為他們即懂技術矾克，有熟悉軟件相關的領域知識页慷。能平衡好這些背景且努力跟實際用戶溝通的分析師，通常會是非常出色的用戶代理胁附。有些分析師暴露出來的問題是差购，他們遇到問題喜歡空想，而不是去做調(diào)查汉嗽。P52
12. 訪問實際用戶受阻團隊被告知要和用戶代理一起工作，最好的方法之一是請求準許啟動一個用戶顧問團隊（user tabsk force）找蜜。P52
13. 實在不能接觸到用戶時饼暑，必須求助于用戶代理，一種有價值的方法是使用多個用戶代理。P53
14. 建立客戶團隊有三步弓叛。P54
    • 邀請真實用戶加入彰居。
    • 在客戶團隊中確定一位“項目負責人”或“一把手”。
    • 確定項目成功必須的關鍵因素撰筷。
15. 小結陈惰。P55
    • 除非用戶的經(jīng)理也是用戶，否則她就不是合適的用戶代理毕籽。
    • 開發(fā)經(jīng)理會試圖擔任用戶代理抬闯，因為他們已經(jīng)參與到項目每天的細節(jié)中。然而关筒，開發(fā)經(jīng)理大多不是正在開發(fā)的軟件的用戶溶握，所以他們不是理想的用戶代理。
    • 在產(chǎn)品公司里蒸播，客戶經(jīng)常來自市場團隊睡榆。來自市場團隊的人經(jīng)常是不錯的用戶代理，但他們通常關注于軟件的功能數(shù)目袍榆，而不是其質量胀屿，這點必須要克服。
    • 與很多不同的客戶（而這些客戶同時也是用戶）聯(lián)系的銷售人員可以是很好的開發(fā)項目客戶包雀。銷售人員必須避免把重點放在那些可以重新贏得已失去訂單的故事上宿崭。在所有情況下，銷售人員是與用戶溝通的有效渠道馏艾。
    • 領域專家可以成為優(yōu)秀的用戶代理劳曹，但必須避免一點：在為產(chǎn)品編寫故事時，將產(chǎn)品開發(fā)成只適合那些與他們有相同水平的人使用琅摩。
    • 客戶铁孵，那些做出購買決定的讓你，如果他們能與用戶密切地交流房资，那么他們能成為非常好的用戶代理蜕劝。顯然，如何客戶自己也是用戶轰异，那就是完美的組合岖沛。
    • 為了成為好的用戶代理，培訓師和技術支持人員必須避免僅僅關注產(chǎn)品中那些他們每天關心的方面搭独。
    • 本章也簡短地給出了一些與用戶代理一起工作的方法婴削，包括用戶顧問團隊的使用，使用多個用戶代理牙肝，分析競爭產(chǎn)品唉俗，盡早發(fā)布軟件來獲取用戶反饋嗤朴。
16. 開發(fā)人員職責。P55
    • 負責幫助組織機構為項目物色合適的客戶虫溜。
    • 負責了解不同類型的用戶代理怎么考慮你們正在開發(fā)的系統(tǒng)雹姊，他們的背景如何影響交互。
17. 客戶團隊職責衡楞。P55
    • 如果你不是軟件的用戶吱雏，則要負責了解自己屬于哪種用戶代理。
    • 負責理解自己會將哪些偏見帶入到項目中瘾境，如何克服這個問題歧杏，無論是依靠別人還是其他方法。

第6章 用戶故事驗收測試

1. 既然軟件是用來實現(xiàn)用戶的愿景寄雀，驗收測試當然就應當由客戶來定義得滤。P59
2. 多少測試才算多。P59
   只要這些測試還在繼續(xù)為故事增加價值和使它更加清晰盒犹，客戶就應該繼續(xù)寫測試懂更。
3. 測試的是缺陷，而不是覆蓋率急膀。P61
   在一個敏捷的由故事驅動的項目中沮协，測試并不像很多團隊那樣是一個對抗性的活動。發(fā)現(xiàn)缺陷時卓嫂，不該有“被我逮到了吧”這樣的心態(tài)慷暂。在敏捷開發(fā)中，若有缺陷知道系統(tǒng)投產(chǎn)的時候才被發(fā)現(xiàn)晨雳，團隊成員是不應該項目推卸責任的行瑞。高度協(xié)作的團隊以及“我們共同負責”的心態(tài)防范這種事情的發(fā)生。
4. 在敏捷項目中餐禁，測試的目的發(fā)現(xiàn)并消除缺陷血久，所以沒有必要追求100%的代碼覆蓋率或測試所有邊界條件。我們運用我們的直覺帮非、知識和過去的經(jīng)驗來指導測試氧吐。P61
5. 小結。P62
   • 驗收測試可以用來記錄客戶和開發(fā)人員討論的很多細節(jié)末盔。
   • 驗收測試記錄了有關故事的一些假設筑舅，這些假設可能還沒有和開發(fā)人員討論過。
   • 驗收測試提供了檢查故事是否被完整實現(xiàn)的基本標準陨舱。
   • 驗收測試由客戶來編寫而不是開發(fā)人員翠拣。
   • 驗收測試應在程序員寫代碼之前就寫好。
   • 如果新的測試對闡明故事的細節(jié)或意圖沒有任何幫助游盲，就不用再寫误墓。
   • FIT和FitNesse是寫驗收測試的優(yōu)秀工具邦尊，它們用的是我們熟悉的表格或電子表格格式。
6. 開發(fā)人員職責优烧。P62
   • 若團隊覺得有需要，則負責實現(xiàn)自動化驗收測試链峭。
   • 開始開發(fā)一個新的故事時畦娄，負責考慮更多的驗收測試。
   • 負責為代碼作單元測試弊仪，使驗收測試就不必顧及故事的每個細節(jié)熙卡。
7. 客戶職責。P62
   • 負責編寫驗收測試励饵。
   • 負責執(zhí)行驗收測試驳癌。

第7章 優(yōu)秀用戶故事準則

1. 在一個大型項目中，尤其是有許多用戶角色的項目役听，確定用戶故事有時讓人無從下手颓鲜。我發(fā)現(xiàn)最好的辦法是考慮每一個用戶角色，了解用戶使用我們軟件的目的典予。P63
2. 切蛋糕甜滨。P63
   當面臨一個大的故事時，通常有許多方法可以將它分解成較小的故事瘤袖。許多開發(fā)人員首先想到的是將故事按照技術路線分割衣摩。這樣做的缺陷是，沒有一個故事是單獨對用戶很有用的捂敌。一個更好的辦法是換一種方式編寫故事艾扮，每個故事都提供某種程度的完整的功能。稱之為“切蛋糕”占婉。
3. 一個封閉的故事是指那種隨著一個有益意思的目標的實現(xiàn)而結束的故事泡嘴，能讓用戶使用后覺得她完成了某個任務。編寫封閉故事其實是在相互沖突的各種需求之間權衡的結果锐涯。因為磕诊，故事也要小到能做評估，小到可以方便地安排到一輪迭代中纹腌。但故事也要足夠大（這里的大指的是粒度的霎终、高層次的和抽象的），從而避免過早捕獲當下還不需要的細節(jié)升薯。P64
4. 你應專注于最需要你關注的領域莱褒。通常，這意味著要把注意力放在那些即將發(fā)生的事情上涎劈，而不是放在更遠的將來才發(fā)生的事情上广凸。對股市而言阅茶，要基于故事實現(xiàn)的時間跨度，以不同的層次來編寫故事谅海。P66
5. 一直困擾著軟件需求方法的問題之一試講需求和解決方案混在一起脸哀。也就是說，在陳述需求的時候扭吁，也顯示說明或暗示了解決方案撞蜂。最常見的情況是用戶界面。你應盡量讓故事不包含用戶界面侥袜。P66
6. 在故事里包括用戶角色蝌诡。這樣編寫故事，能讓用戶在開發(fā)人員腦子里保持最重要的位置枫吧。開發(fā)人員不會去想乏味的浦旱、不形象的、可切換的用戶九杂，他們會聯(lián)想實際的颁湖、真切的用戶，開發(fā)出滿足用戶需求的軟件尼酿。P67
7. 每個故事使用下面的格式編寫：P67
   我作為（角色）爷狈，想要（功能），以此（商業(yè)價值）
8. 當故事只為單一用戶編寫時裳擎，故事的可讀性通常是最強的涎永。P68
9. 用戶故事用主動語態(tài)編寫時，更易于閱讀和理解鹿响。P68
10. 給故事卡片編號會增加無謂的流程羡微，并導致我們?nèi)コ橄蟮赜懻撔枰蜗蠡墓δ堋69
11. 小結惶我。P69
    • 為了確定故事妈倔，從每個用戶角色使用系統(tǒng)的目標開始考慮。
    • 分割故事時绸贡，試著將它分割成貫穿應用程序所有層面的故事盯蝴。
    • 試著 讓故事的大小能夠在使用后讓用戶感到可以去喝杯咖啡休息一下。
    • 如果有項目領域和環(huán)境的需要听怕，可以用其他需求搜集或文檔技術來補充故事捧挺。
    • 創(chuàng)建約束卡，將它們貼在公共的墻上尿瞭，或者編寫測試來確保系統(tǒng)沒有違反約束闽烙。
    • 為團隊即將實現(xiàn)的功能編寫小的故事，針對未來實現(xiàn)的功能編寫寬泛的声搁、高層次的故事黑竞。
    • 不要讓故事過早涉及用戶界面捕发。
    • 實際編寫故事時，要包括用戶角色很魂。
    • 用主動語態(tài)編寫故事扎酷。
    • 為單個用戶編寫故事。
    • 讓客戶遏匆，而不是開發(fā)人員霞玄，編寫故事。
    • 用戶故事要簡短拉岁，別忘了，它們的目的是提醒開發(fā)人員和客戶進行對話惰爬。
    • 不要給故事卡編號喊暖。

第II部分 估算和計劃

第8章 估算用戶故事

1. 故事估算的最好方法具有如下特點。P73
   • 無論什么時候獲得有關故事的新信息撕瞧，都允許我們改變之前的想法陵叽。
   • 適用于史詩故事和小故事。
   • 不需要花很多時間丛版。
   • 提供進度和剩余工作的有用信息巩掺。
   • 不太精確的估算也不會有太大問題。
   • 可以用來制定發(fā)布計劃页畦。
2. 我個人比較偏好將一個故事點的工作量看作是一個理想日的工作胖替。第一，相較于用連續(xù)時間估算豫缨，它更簡單独令。用持續(xù)時間估算迫使我們考慮對時間的各種可能的影響。第二好芭，相較于用完全模糊單位燃箭，用理想日估算故事點可使我們的估算擁有更好的依據(jù)。估算的主要目的之一是知道整個項目的工作量舍败，所以最后我們總是要將估算換算成時間招狸。顯然，相較于用完全模糊單位邻薯，用理想時間更簡單裙戏。P73
3. 故事估算應該由整個團隊集體完成。第一弛说，還不確定團隊中誰負責完成這個故事挽懦，所以應該把故事分配給整個團隊而不是某個人。第二木人，團隊決定的估算可能比個人估算更有用信柿。P74
4. 估算冀偶。P74
   估算方法把所有參與估算的客戶和開發(fā)人員聚集在一起。帶上故事卡和一些額外的空筆記卡渔嚷。發(fā)給每個參與者一些空卡片进鸠。客戶隨機抽取一個故事形病，讀給開發(fā)人員聽客年。開發(fā)人員根據(jù)需要盡可能多發(fā)問，客戶要盡其所能解答漠吻。如果客戶不知道答案量瓜，可以先猜猜看，或者要團隊推遲估算這個故事途乃。
5. 程序員估算一個故事時绍傲，他們應考慮完成這個故事需要做的所有事。他們要全盤考慮測試代碼耍共，和客戶討論烫饼，可能幫助客戶計劃或自動化驗收測試等諸多因素。P74
6. 估算试读。P75
   每個開發(fā)人員在卡上寫下一個估算值杠纵，先不要給其他人看。大家都寫好估算值后钩骇，所有人翻開他們的卡片或者拿起展示給所有人看比藻。這時，估算值很有可能相差很大倘屹。這其實是件好事韩容。如果估算值不同，估算值高的和低的再解釋一下估算依據(jù)唐瀑。值得注意的是群凶，這時不要互相攻擊對方，而是耐心聽取他們的想法哄辣。
7. 三角測試请梢。P76
   在做了幾個估算后，我們可以（而且必要）對估算做三角測量力穗。具體做法就是在估算一個故事時毅弧，根據(jù)這個故事與其他一個或多個故事的關系來估算。假定一個故事估算為4個故事點当窗，第二個故事估算為2個故事點够坐。把這兩個故事放在一起考慮時，程序員應該都同意4個點的故事大概是2個點的故事的兩倍。
8. 使用故事點元咙。P76
   在一輪迭代結束時梯影，團隊計算已完成的故事點數(shù)。因為即將到來的迭代也是同樣的長度庶香，這個點數(shù)可以作為下輪迭代將完成的故事點數(shù)的預報甲棍。
9. 小結。P79
   • 用故事點估算故事赶掖，故事點是故事復雜度感猛、工作量或工期的相對估算。
   • 應由團隊估算故事奢赂，估算屬于團隊而不是個人陪白。
   • 通過和其他估算進行比較來進行三角測量蹬碧。
   • 團隊是否使用結對編程對故事點估算沒有影響佳吞。結對編程影響的是團隊的速率卓研，不是他們的估算秧骑。

第9章 發(fā)布計劃

1. 我們想在什么時候發(fā)布。P81
   理想情況下这嚣，開發(fā)人員和客戶可以談一個日期范圍，而不是一個具體日期。如果一個團隊做發(fā)布計劃時能以一個可接受的日期范圍為起點聋迎，那么他們的發(fā)布時間將更靈活。例如在6或7輪迭代之后枣耀，應該有最基本的功能霉晕。
2. 希望再發(fā)布中包含哪些功能。P82
   為了計劃一個發(fā)布捞奕，客戶必須排列故事的優(yōu)先級牺堰。我們可以借用來自DSDM的方法，它是另一種敏捷過程颅围。DSDM包括一個排列優(yōu)先級的方法伟葫，稱之為莫斯科（MoSCoW）規(guī)則。
   • 必須有（Must have）：指系統(tǒng)的基本功能院促。
   • 應該有（Should have）：指很重要但短期內(nèi)有替代解決方法的功能筏养。如果項目沒有時間約束，通常認為應該有的功能是強制性的常拓。
   • 可以有（Could have）：指如果沒有時間就可以在發(fā)布中不予考慮的功能渐溶。
   • 這次不會有（Won't have this time）：客戶期望擁有但同時承認需要在后續(xù)發(fā)布中實現(xiàn)的功能。
3. 排列故事優(yōu)先級弄抬。P82
   我們可以通過多個維度來為故事排優(yōu)先級茎辐。可以利用的技術要素如下。
   • 故事不能如期完成的風險拖陆。
   • 推遲實現(xiàn)一個故事時對其他故事的影響弛槐。
   • 故事對于廣泛用戶或客戶的重要性。
   • 故事對于少部分重要用戶或客戶的重要性慕蔚。
   • 故事與其他故事的內(nèi)聚性丐黄。
     當客戶和開發(fā)人員對這個順序有不同意見時，最后每次都應該是客戶說了算孔飒。
4. 大家一直再爭論一個問題灌闺，即對一個項目來說，應該先做最有風險的部分坏瞄，還是先做最有價值的部分桂对。風險驅動開發(fā)的主要領導者也許是巴·里鮑依姆（Barry Boehm），他的螺旋模型（spiral model）著重在早期消除風險鸠匀。而另一個方向的領導者是湯姆·吉爾伯（Tom Gilb）蕉斜，他提倡先做“油水最多”（“juicy bits”）的部分。P84
5. 敏捷方法旗幟鮮明地支持先做最有價值的部分缀棍。這讓敏捷項目能夠避免過早地解決風險宅此，同時也推遲了可能并不需要的一些基礎性代碼的開發(fā)。贊同先做最有價值的部分爬范，還能使項目可能盡早發(fā)布父腕，那時只提供最有價值的功能。P84
6. 即使以價值優(yōu)先為導向青瀑，我們在排列故事優(yōu)先級時任然需要考慮風險璧亮。許多開發(fā)人員傾向于先做風險最高的故事。有時這是恰當?shù)某饽眩@任然必須由客戶決定枝嘶。然而，在排列故事優(yōu)先級時哑诊，客戶應該考慮技術團隊的意見群扶。P84
7. 選擇迭代長度。P86
   開發(fā)人員和客戶共同選擇合適他們的迭代長度镀裤。迭代長度通常為1至4周穷当。短迭代允許項目更加頻繁地做出調(diào)整，項目進度也會更加透明淹禾；但是每輪迭代會有少許額外開銷馁菜。假如不確定迭代長度，請選擇段迭代而不是長迭代铃岔，使用長迭代更容易犯錯汪疮。
8. 初始速率峭火。P87
   • 使用歷史值。
   • 執(zhí)行一輪初始迭代智嚷，使用那輪迭代的速率卖丸。
   • 猜測。
9. 小結盏道。P88
   • 在計劃發(fā)布時稍浆，有必要知道客戶預期的大致發(fā)布日期和故事的相對優(yōu)先級。
   • 故事應該以明確的順序排列（第一個猜嘱、第二個衅枫、第三個，等等）朗伶，而不是利用諸如“非常高弦撩、高、中等”模糊順序的分組论皆。
   • 故事的優(yōu)先級由客戶確定益楼，但也要考慮開發(fā)人員的想法。
   • 使用速率將以理想日為單位的估算轉換成日歷日点晴。
   • 估算團隊的初始速率是很有必要的感凤。

第10章 迭代計劃

1. 整個團隊通過舉行迭代計劃會議來為下一輪迭代做計劃。迭代計劃會議的一般內(nèi)容如下粒督。P91
   • 討論故事陪竿。
   • 從貴中分解出任務。
   • 開發(fā)人員承擔每個任務的職責坠陈。
   • 討論過所有故事，并且接受所有任務后捐康，開發(fā)人員單獨估計他們承擔的任務仇矾，以確保他們不會做出過于樂觀的承諾。
2. 討論故事解总。P91
   團隊獲得一個已經(jīng)排好優(yōu)先級的故事集合贮匕，以此作為迭代計劃會議的輸入。正如程序員可能改變他們對實現(xiàn)一個故事難度的看法花枫，客戶一樣可能改變她對故事優(yōu)先級的想法刻盐。迭代計劃會議是客戶為團隊調(diào)整故事優(yōu)先級的最佳時機。
3. 分解任務劳翰。P92
   盡管故事的確可以小到作為工作單位敦锌，但將它們分解出更小的任務，一般更符合項目的需要佳簸。首先乙墙，對很多團隊來說，實現(xiàn)故事的開發(fā)人員不止一個。其次听想，故事是對用戶或客戶有價值的功能描述腥刹，它們并不是開發(fā)人員的待辦事項（to-do list）。把故事分解成任務常常是有用的汉买，因為這有助于發(fā)現(xiàn)那些可能會被遺忘的任務衔峰。
4. 敏捷過程為人詬病的地方之一，是它沒有像瀑布過程那樣的前期設計步驟蛙粘。這是事實垫卤，敏捷沒有前期設計階段，敏捷過程的特點是做頻繁的短期設計组题。P93
5. 從故事分解任務時葫男，使用一下準則。P93
   • 如果故事的某個任務特別難于估算崔列，就把那個任務從故事的其余任務中分離出來梢褐。
   • 倘若有些任務可以很容易安排給多名開發(fā)人員共同完成，就分割它們赵讯。
   • 若有必要讓客戶了解故事某一部分的完成情況盈咳，可以把那部分拿出來作為一個任務。
6. 承擔職責边翼。P94
   團隊要有一種“同舟共濟”的心態(tài)鱼响。而且，在迭代快要結束時组底，如果有開發(fā)人員不能完成他接手的所有任務丈积，團隊中的其他成員應該盡量用于承擔。

第11章 測量并監(jiān)控速率

1. 不能將部分完成的故事也計算在速率中债鸡。首先江滨，一個顯然的問題就是沒法計算故事已完成的百分比。其次厌均，不想使用帶小數(shù)的值為速率引入錯誤的精度唬滑。第三，沒完成的故事通常并不能給用戶或客戶帶來任何價值棺弊。第四晶密，既然一個故事大到包含一個影響速錄的子故事，那只能說明這個故事確實太大了模她。最后稻艰，我們盡量避免許多故事90%完成，沒有多少故事100%完成的情形侈净。P98
2. 計劃速率和實際速率连锯。P98
   監(jiān)測實際速率與計劃速率的偏差归苍，或者說，是否需要采取什么措施保證合理的速率运怖，這是很重要的拼弃。一個比較好的方法是為每輪迭代畫出計劃速率和實際速率。
3. 迭代燃盡圖摇展。P100
   另外一個監(jiān)控進展的好方法就是迭代燃盡圖（Burndown Chart）吻氧。迭代燃盡圖展示了以故事點表示的在每輪迭代末剩余的工作量。

第III部分 經(jīng)常討論的話題

第12章 故事不是什么

1. 小結咏连。P117
   • 用戶故事有別于IEEE 830軟件需求規(guī)格盯孙、用例和交互設計場景。
   • 不管預想得那么全面祟滴，我們都無法事先完全定義一個完整的具有相當規(guī)模的系統(tǒng)振惰。
   • 在定義需求和用戶早期頻繁接觸軟件之間，有一個有價值的反饋循環(huán)垄懂。
   • 考慮用戶的目標比列出方案的特性更重要骑晶。
   • 用戶故事與用例場景類似。但用例往往任然比單個故事要大草慧，更容易包含關于用戶界面的嵌入式假設桶蛔。
   • 此外，用戶故事與用例的完整度和壽命不同漫谷。用例比用戶故事完整得多仔雷。用例存在于整個開發(fā)過程中。用戶故事往往只是暫時的舔示，它們的生命周期僅僅限于開發(fā)它們的迭代中碟婆。
   • 用戶故事和用例以不同的目的編寫。用例被編寫成方便開發(fā)人員和客戶討論并達成共識惕稻。用戶故事編寫成方便計劃發(fā)布竖共，并用于提醒需求細節(jié)的討論。
   • 不像IEEE 830規(guī)格和用例缩宜，用戶故事不是分析活動的產(chǎn)物肘迎。相反甥温，用戶故事是進行分析的支持工具锻煌。
   • 交互式設計場景比用戶故事具體得多，它們提供的細節(jié)類型也不同姻蚓。
   • 典型的交互式設計場景比用戶故事大得多宋梧。一個場景可以由多個用例組成，相應地狰挡，它可以組成許多用戶故事捂龄。

第13章 用戶故事的優(yōu)勢

1. 使用用戶故事到底帶來哪些好處释涛。P119
   • 用戶故事強調(diào)口頭溝通。
   • 人人都可以理解用戶故事倦沧。
   • 用戶故事的大小適合做計劃唇撬。
   • 用戶故事適合于迭代開發(fā)。
   • 用戶故事鼓勵延遲細節(jié)展融。
   • 用戶故事支持隨機應變的開發(fā)窖认。
   • 用戶故事鼓勵參與性設計。
   • 用戶故事傳播隱性知識告希。
2. 小結扑浸。P127
   • 用戶故事促使我們重視口頭交流。與其他完全依賴書面文檔的需求方法不同燕偶，用戶故事認為開發(fā)人員與用戶之間的交談有重大的意義喝噪。
   • 重視口頭交流這一轉變提供了迅速的反饋周期，往往能促成對需求的充分理解指么。
   • 開發(fā)者與用戶都能理解用戶故事酝惧。IEEE 830軟件需求規(guī)格往往容易充斥著太多的技術或商業(yè)術語。
   • 用戶故事的典型范圍規(guī)模比用例及場景小涧尿，但比IEEE 830文檔大系奉，這個大小適合做計劃。計劃姑廉、編碼及測試缺亮，都可以不再需要合并或分解故事就能完成。
   • 用戶故事適合于迭代開發(fā)桥言，我們很容易從一個史詩故事入手萌踱，并在后來需要時把它分成多個小故事。
   • 用戶故事鼓勵延遲細節(jié)号阿〔⑼遥可以很快地寫出獨立的用戶故事，而且寫出不同大小的故事也很容易扔涧。對于不太重要的或者一開始不會被開發(fā)的需求园担，我們可以選擇先用史詩故事來代表，而其他故事包含有更多的細節(jié)枯夜。
   • 故事鼓勵隨機應變的開發(fā)弯汰。在此方式中，隨著不斷地發(fā)現(xiàn)機會湖雹，團隊視線能迅速地在高層及低層細節(jié)思考間來回切換咏闪。
   • 故事提升團隊內(nèi)隱性知識的水平。
   • 用戶故事鼓勵參與性設計摔吏。與經(jīng)驗性設計不同鸽嫂，用戶成為軟件行為設計的活躍的參與者纵装，做出有價值的貢獻。
   • 雖然使用故事有不少的好處据某，不可否認也有一些缺點：大型項目中難以組織好成千上萬的用戶故事橡娄；有時候需要額外的文檔以實現(xiàn)可追溯性；盡管面對面的溝通大大促進隱性知識的共享癣籽，但在大型項目中瀑踢，單單依賴這種交談難于實現(xiàn)有效的擴展來完全替代書面文檔。

第14章 用戶故事不良癥兆一覽

1. 小結才避。P134
   • 故事太谐髫病：小故事的規(guī)模估算十分依賴于故事實現(xiàn)的順序。實現(xiàn)順序不同桑逝，規(guī)模估算值可能也有很大的差異棘劣，從而導致故事估算和計劃出現(xiàn)問題。
   • 故事互相依賴：兩個甚至多個故事之間相互依賴楞遏，以至于很難把單獨的故事放入迭代中茬暇。
   • 鍍金：指的是開發(fā)人員實現(xiàn)了不需要的功能」押龋可能有幾個原因糙俗，首先，很多開發(fā)人員總是希望給客戶帶來驚喜预鬓。其次巧骚，在敏捷軟件開發(fā)項目總是采用基于故事驅動的短迭代模式，開發(fā)人員總能感受到需要不斷生產(chǎn)的壓力格二。鍍金功能使得開發(fā)人員得到一定程度的解脫劈彪。最后，開發(fā)人員總是愿意在項目中留下自己的印記顶猜，添加一些“寵物功能”就是一個種留下自己印記的方式沧奴。如果項目組中的卡法人員花太多的精力去開發(fā)鍍金功能，一個有效的解決方法是提高項目組中每個人的任務可見性长窄。
   • 故事中包含太多的細節(jié)：把故事寫到小卡片上的一個好處是在小卡片上只能記錄下很有限的東西滔吠。避免花太多的時間去寫故事而不去討論故事。
   • 過早包含用戶界面細節(jié)挠日。
   • 想得太遠疮绷。
   • 故事劃分太過頻繁。
   • 很難為故事安排優(yōu)先級肆资。
   • 客戶不愿意寫用戶故事矗愧，為故事安排優(yōu)先級灶芝。

第15章 Scrum與用戶故事

1. ScrumMaster更多的是為Scrum團隊服務郑原，而不是指手畫腳唉韭。ScrumMaster主要負責為團隊排除障礙，保證開發(fā)的順利進行犯犁，確保整個團隊按照Scrum的簡單規(guī)則進行開發(fā)属愤。P137
2. Scrum的主要規(guī)則。P139
   • 在Sprint開始的時候召開Sprint計劃會議酸役。
   • 每個Sprint必須發(fā)布可以工作的住诸、經(jīng)過測試的代碼，這些代碼能夠完成對最終客戶有價值的一些功能涣澡。
   • 產(chǎn)品負責人為產(chǎn)品Backlog排列優(yōu)先級贱呐。
   • 團隊一起決定一輪迭代完成多少故事。
   • 在任何時候都可以向產(chǎn)品Backlog中添加故事入桂，或者重新排列優(yōu)先級奄薇。
   • 每天有一個Scrum短會。每個項目成員回答三個問題：我昨天做了什么抗愁？我今天打算要做什么馁蒂？我有什么困難？
   • 只有團隊成員能在每日Scrum簡會中發(fā)言蜘腌，其他人包括對項目感興趣的觀察者或利益相關者都不能發(fā)言沫屡。
   • 在Sprint結束時的Sprint評審會議中，團隊會演示完成的成果撮珠。
   • 團隊演示的是可以工作的軟件沮脖，而不是幻燈片。
   • 準備Sprint評審會議的時間不得超過兩小時芯急。
3. 小結倘潜。P144
   • Scrum是一種迭代和遞增的過程。
   • Scrum每30天一輪迭代志于，成為Sprint涮因。
   • ScrumMaster相當于傳統(tǒng)的項目經(jīng)理，但更像是領導者和組織者伺绽，而不是經(jīng)理养泡。
   • 一般的Scrum團隊包括4~7個開發(fā)人員。
   • 產(chǎn)品Backlog是一個待開發(fā)的工鞥呢需求列表奈应，里面的條目要么還沒有實現(xiàn)到產(chǎn)品中澜掩，要么還沒有計劃再當前Sprint中開發(fā)。
   • Sprint Backlog是一個團隊承諾在當前Sprint完成的任務列表杖挣。
   • 在極限編程里面的客戶角色肩榕，在Scrum中稱為產(chǎn)品負責人。
   • 產(chǎn)品負責人負責給產(chǎn)品Backlog排列優(yōu)先級惩妇。
   • 在Sprint的開始株汉，團隊從產(chǎn)品Backlog中選擇下一個Sprint要完成的任務筐乳。
   • 在每日Scrum簡會中，每個團隊成員需要回答三個問題：我昨天完成了什么乔妈？今天我要做什么蝙云？我碰到了哪些問題？
   • 每個Sprint都要完成一部分可以潛在交付的產(chǎn)品功能增量路召。
   • 在Sprint結束時勃刨，團隊再Sprint評審會議上演示所完成的功能。

第16章 其他話題

1. 小結股淡。P154
   • 非功能性需求都可以通過創(chuàng)建約束卡的方式來處理身隐。假如系統(tǒng)的需求比這些更復雜，但無論其他格式還是方法唯灵，只要它能充分表示那些需求抡医，就可以用作用戶故事的補充。
   • 筆記卡和軟件系統(tǒng)都不是 適用于所有情況下編寫故事的最佳方式早敬。使用適合項目和團隊的工具忌傻。
   • 迭代過程會導致用戶界面的反復變動。習慣于特定界面的用戶搞监，不會喜歡用戶界面變動水孩，因為這會影響他們已經(jīng)學會的操作軟件的方法∷雎浚可以考慮加入一些敏捷版以使用為中心的設計實踐俘种，以避免用戶界面的發(fā)福變化。
   • 一旦故事完成绝淡，撕毀故事卡會有一定的樂趣宙刘。但同樣也有保留卡片的理由。寧可謹慎一些牢酵，保留故事悬包。
   • 把小的缺陷報告用一個封面故事卡裝訂在一起，并把它們當成一個單一故事馍乙。

第IV部分 一個完整的實例

建議必讀