User Stories Applied

第一部分 起步

第一章 概覽

什么是用戶故事

用戶故事描述了對用戶、系統(tǒng)或軟件購買者有價值的功能。

• 一份書面的故事描述，用來做計劃和作為提示。 （Card）
• 有關(guān)故事的對話，用于具體化故事細節(jié)。（Conversation）
• 測試，用戶表達和編檔故事細節(jié)且可用于確定故事何時完成。（Confirmation）

規(guī)劃發(fā)布和迭代

假設(shè)開發(fā)團隊每輪迭代的速率是13個故事點：

用戶故事的發(fā)布計劃：

分割故事，做更好的發(fā)布計劃：把故事I分成故事Y（3個點）和故事Z（2個點）

什么是驗收測試？

假設(shè)寫下故事“用戶可以用信用卡為購物車中的物品付款”。然后再故事卡背面寫下測試描述：

• 用Visa信用卡、萬事達信用卡測試（通過）。
• 用大來卡測試（失?。?/li>
• 用Visa借記卡測試（通過）
• 用有效、無效和反面丟失卡ID號的信用卡測試
• 用過期卡測試。
• 用不同購買金額測試（包括超出信用卡額度）

為什么要變？

Change is a law, and no amount of pretending will alter the reality.

• 用戶故事強調(diào)對話交流而不是書面溝通。
• 用戶故事可以同時被你和開發(fā)人員理解。
• 用戶故事的大小適合于做計劃。
• 用戶故事適用于迭代開發(fā)。
• 用戶故事鼓勵推遲考慮細節(jié)，直到你非常清楚地了解自己的真正需求。

小結(jié)

• 故事卡包含對用戶或者客戶有價值的功能的簡短描述。
• 故事卡是故事的可見部分，但客戶團隊和開發(fā)人員關(guān)于故事的對話更重要。
• 客戶團隊包括那些確保軟件符合潛在用戶需求的人，可以包括測試人員、產(chǎn)品經(jīng)理、實際用戶和交互設(shè)計師。
• 故事卡由客戶團隊編寫，因為他們最了解如何表達需要實現(xiàn)的需求，也因為他們會在后期于開發(fā)人員共同確定故事細節(jié)并安排故事的優(yōu)先級。
• 按照故事對客戶的價值來安排故事的優(yōu)先級。
• 將各個故事放入迭代，進行發(fā)布與迭代規(guī)劃。
• 速率是開發(fā)人員可以在一輪迭代中完成的工作量。
• 放入一輪迭代的故事估計總和不能超過事先開發(fā)人員預(yù)計的速率。
• 如果故事太大以至于無法在一輪迭代中完成，可以考慮把它分成兩個或更多的小故事。
• 驗收測試用于驗證實現(xiàn)的故事是否開發(fā)成符合客戶團隊的設(shè)想。
• 用戶故事是很有意義的，因為它們強調(diào)口頭交流，你和開發(fā)人員都可以理解，可以用于進行迭代計劃，在迭代開發(fā)中能很好地工作，而且因為它們鼓勵推遲細節(jié)。

第 2 章 編寫故事

優(yōu)秀的故事的特點：（INVEST）

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

小結(jié)

• 理想情況下，故事之間是獨立的。故事之間的交付順序應(yīng)該是無關(guān)的，可以任意拿一個故事來實現(xiàn)。
• 故事細節(jié)由用戶和開發(fā)人員討論得出。
• 故事應(yīng)該很清晰地體現(xiàn)對用戶或客戶的價值。最好的做法是讓客戶編寫故事。
• 故事可以注釋一些細節(jié)，但是過多的細節(jié)會使故事難以理解。
• 給故事加上注釋的最好方法是給它編寫測試用例。
• 如果故事太大，復(fù)合故事和復(fù)雜故事可以分成幾個小的故事。
• 如果故事太小，幾個小故事可以合并成一個較大的故事。
• 故事應(yīng)該是可以測試的。

開發(fā)人員職責

• 幫助客戶編寫故事，故事要能提醒你們同客戶交談，不是記錄詳細的需求定義，故事應(yīng)該對用戶或者客戶有價值，它們是獨立的、可測的、大小合適的。
• 使用對用戶或客戶有價值的術(shù)語來描述實現(xiàn)故事所用的技術(shù)或者基礎(chǔ)架構(gòu)信息。

客戶團隊職責

• 負責編寫故事。

第 3 章 用戶角色建模

• 通過頭腦風暴，列出初始的用戶角色集合
• 整理最初的角色集合
• 整合角色
• 提煉角色

小結(jié)

• 大部分項目小組只考慮單一的用戶類型。導致軟件忽略原本需要的一些用戶類型。
• 為了避免從單一用戶的角度編寫所有故事，要識別與軟件交互的不同用戶角色。
• 通過對每個用戶角色定義相關(guān)特征，可以更清楚地看到不同角色間的不同點。
• 對于有些用戶角色而已，用代表人物來描述會很有幫助。虛構(gòu)人物是假想出來的用戶角色代表。他們有名字，有照片，還有足夠的相關(guān)細節(jié)，因為對項目成員來說，很真實。
• 對于有些應(yīng)用程序，極端人物可能有助于搜集原本被遺漏的故事。

開發(fā)人員職責

• 負責參與確認用戶角色和虛擬人物的過程。
• 負責理解每個用戶角色或虛擬人物，以及它們之間的異同。
• 開發(fā)軟件時，負責考慮不同的用戶角色對于軟件如何運行的不同偏好。
• 負責確保在識別和描述用戶角色時，它們只是這個過程中的工具，不應(yīng)超越作為工具之外的任何用途。

客戶職責

• 負責尋找用戶（多多益善），并識別恰當?shù)挠脩艚巧?/li>
• 確保軟件沒有關(guān)注不恰當?shù)挠脩簟?/li>
• 確保每個故事都能和至少一個用戶角色或虛構(gòu)人物聯(lián)系起來。
• 開發(fā)軟件時，負責考慮不同的用戶角色對于軟件如何運行的不同偏好。
• 負責確保在識別和描述用戶角色時，它們只是這個過程中的工具，不應(yīng)超越作為工具之外的任何用途。

第 4 章 搜集故事

創(chuàng)建故事最有用的一些方法：

• 用戶訪談
• 問卷調(diào)查
• 觀察
• 故事編寫工作坊

簡單原型.png

通過畫上面這個原型，得到以下故事：

• 求職者可以發(fā)布他的簡歷。
• 雇主可以發(fā)布工作。
• 雇主可以查看提交的簡歷。
• 求職者可以搜索工作
• 求職者可以看到符合搜索條件的工作。
• 求職者可以看到指定工作的詳細信息。

畫原型的過程中，問一些有助于找到遺漏故事的問題：

• 用戶接下來最有可能做什么？
• 用戶會在這里犯什么錯誤？
• 用戶會有什么困惑？
• 用戶需要什么額外的信息？

小結(jié)

• 能夠引出及捕捉需求這一想法是錯誤的。
• 拖網(wǎng)捕魚的比喻非常有用。
• 即使敏捷流程支持需求的后期涌現(xiàn)，依然需要對預(yù)期的發(fā)布進行展望并開始寫下容易發(fā)現(xiàn)的故事。
• 可以通過用戶訪談、觀察用戶、問卷調(diào)查和舉辦故事編寫工作坊來發(fā)現(xiàn)用戶故事。
• 使用多種方法比過度使用一種方法更能獲得好的效果。
• 通過開放式、與背景無關(guān)的提問更容易獲得有用的答案。

開發(fā)人員職責

• 負責理解并使用多種技巧來捕撈用戶故事。
• 負責知道怎么使用開放式和背景無關(guān)的提問。

客戶職責

• 負責理解并使用多種技巧來捕撈用戶故事。
• 負責盡早寫更多的用戶故事。
• 作為軟件用戶的主要代表，負責和他們多溝通。
• 了解怎么使用開放式和背景無關(guān)的提問。
• 如果需要關(guān)于編寫故事的幫助，負責安排并舉辦一次或多次故事編寫工作坊。
• 負責確保在捕撈故事過程中考慮所有用戶角色。

第 5 章 與用戶代理合作

小結(jié)

• 除非用戶的經(jīng)理也是用戶，否則他就不是合適的用戶代理。
• 開發(fā)經(jīng)理會試圖擔任用戶代理，因為他們已經(jīng)參與到項目每天的細節(jié)中。然而，開發(fā)經(jīng)理大多不是正在開發(fā)的軟件的用戶，所以他們不是理想的用戶代理。
• 在產(chǎn)品公司里，客戶經(jīng)常來自市場團隊。
• 與很多不同的客戶聯(lián)系的銷售人員可以是很好的開發(fā)項目客戶。
• 領(lǐng)域?qū)＜铱梢猿蔀閮?yōu)秀的用戶代理。
• 客戶，那些做出購買決定的人，如果他們能與用戶密切地交流，那么他們能成為非常好的用戶代理。
• 為了成為好的用戶代理，培訓師和技術(shù)支持人員必須避免僅僅關(guān)注產(chǎn)品中那些他們每天關(guān)心的方面。

開發(fā)人員職責

• 負責幫助組織機構(gòu)為項目物色合適的客戶。
• 負責了解不同類型的用戶代理怎么考慮你們正在開發(fā)的系統(tǒng)，他們的背景如何影響交付。

客戶團隊職責

• 如果你不是軟件的用戶，則要負責了解自己屬于哪類用戶代理。
• 負責理解自己會將哪些偏見帶到項目中，如何克服這個問題，無論是依靠別人還是其他方法。

第 6 章 用戶故事驗收測試

測試是一個兩步流程：

• 將測試要點記錄在故事卡的背面，任何時候發(fā)現(xiàn)新的測試，都可以記錄到故事卡的背面；
• 將測試要點變成全面的測試，這些測試可以用來演示故事已正確、完整地實現(xiàn)。

一般在這些時候?qū)憸y試：

• 開發(fā)人員和客戶討論故事且需要記錄明確的細節(jié)時。
• 在迭代開始時，在寫代碼前作為一項專門的任務(wù)。
• 在開發(fā)中或之后的任何時候發(fā)現(xiàn)新的測試時。

客戶和開發(fā)人員討論故事的時候，比較好的做法是問一些類似的問題：

• 關(guān)于這個故事，程序員還需要知道什么？
• 對怎么實現(xiàn)這個故事，我的想法是什么？
• 有沒有一些特殊情況會使這個故事有不一樣的行為？
• 這個故事在什么情況會出錯？

測試類型

• 用戶交互測試，確保所有用戶交互組件如期工作。
• 可用性測試，確保程序好用。
• 性能測試，測量應(yīng)用程序在各種負荷下的工作狀況。
• 壓力測試，使應(yīng)用程序在用戶和事務(wù)的極限情況或其他任何讓應(yīng)用程序處在壓力下的情況運行。

小結(jié)

• 驗收測試可以用來記錄客戶和開發(fā)人員討論的很多細節(jié)。
• 驗收測試記錄了有關(guān)故事的一些假設(shè)，這些假設(shè)可能還沒有和開發(fā)人員討論過。
• 驗收測試提供了檢查故事是否被完整實現(xiàn)的基本標準。
• 驗收測試應(yīng)由客戶來寫而不是開發(fā)人員。
• 驗收測試應(yīng)在程序員寫代碼之前寫好。
• 如果新的測試對闡明故事的細節(jié)或意圖沒有任何幫助，就不用再寫。
• FIT 和 FitNesse 是寫驗收測試的優(yōu)秀工具，它們用的是我們熟悉的表格或電子表格格式。

開發(fā)人員職責

• 若團隊覺得有需要，則負責實現(xiàn)自動化驗收測試。
• 開始開發(fā)一個新的故事時，負責考慮更多的驗收測試。
• 負責為代碼作單元測試，使驗收測試就不必顧及故事的每個細節(jié)。

客戶職責

• 負責編寫驗收測試
• 負責執(zhí)行驗收測試

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

• 從目標故事開始

• 切蛋糕

• 編寫封閉的故事

• 卡片約束

• 根據(jù)實現(xiàn)時間來確定故事規(guī)模

• 不要過早涉及用戶界面

• 有些需求并不是故事

• 在故事里包括用戶角色

• 只為一個用戶編寫

• 以主動語態(tài)編寫

• 由客戶編寫

• 向故事卡編號說“不”

• 不要忘記意圖

小結(jié)

• 為了確定故事，從每個用戶角色使用系統(tǒng)的目標開始考慮。
• 分割故事時，試著將它分割成貫穿應(yīng)用程序所有層面的故事。
• 試著讓故事的大小能夠在使用后讓用戶有成就感。
• 如果有項目領(lǐng)域和環(huán)境的需要，可以用其他需求搜集或文檔技術(shù)來補充故事。
• 創(chuàng)建約束卡，將它們貼在公共的墻上，或者編寫測試來確保系統(tǒng)沒有違反約束。
• 為團隊即將實現(xiàn)的功能編寫小的故事，針對未來實現(xiàn)的功能編寫寬泛的、高層次的故事。
• 不要讓故事過早涉及用戶界面。
• 實際編寫故事時，要包括用戶角色。
• 用主動語態(tài)編寫故事。
• 為單個用戶編寫故事。
• 讓客戶，而不是開發(fā)人員，編寫故事。
• 用戶故事要簡短。
• 不要給故事卡編號。

第 2 部分 估算和計劃

第 8 章 估算用戶故事

估算故事的最好方法具有如下特點：

• 無論什么時候獲得有關(guān)故事的新信息，都允許我們改變之前的想法。
• 適用于史詩故事和小故事
• 不需要花很多時間
• 提供進度和剩余工作的有用信息
• 不太精確的估算也不會有太大問題
• 可以用來制定發(fā)布計劃

故事點

理想工作日：一天中沒有任何干擾，沒有會議，沒有電子郵件，沒有電話等等

以團隊估算

• 還不確定團隊中誰負責完成這個故事；
• 團隊決定的估算可能比個人估算更有用。

所有事情都要花4小時

Mad About You中， 主角是住在紐約的一對新婚夫婦。有一集中，妻子纏著丈夫去買沙發(fā)。她堅持認為只需要花一個小時。丈夫告訴她“這個世界上所有的事情都要花4個小時。你會去那，做各種事情，吃東西，談?wù)撃闫鋵崙?yīng)該在哪里進餐更好，然后回家。這至少是4個小時。”
程序員估算一個故事時，應(yīng)該考慮完成這個故事需做的所有事。他們要全盤考慮測試代碼，和客戶討論，可能幫助客戶計劃或自動化驗收測試等諸多因素。如果不將這些考慮在內(nèi)，無異于期望只花一個小時買個沙發(fā)。

可以用紙牌的方式，讓大家估算時間。估算值很可能相差很大。這其實是一件好事。如果估值不同，估算值高的和低的再解釋一下估算依據(jù)。值得注意的是，這時不要互相攻擊對方，而是耐心聽取他們的想法。

討論完之后，開發(fā)人員再次將估算值寫在卡片上。當大家都寫好修改的估算值，將卡再次展示給所有人看。如果估算值還是相差很大，重復(fù)讓估高和估低的人解釋他們的想法。

三角測量

image.png

使用故事點

如果用結(jié)對編程呢？

如，有個兩個開發(fā)人員的團隊按理想日來估算故事點。他們沒有用結(jié)對編程。他們計劃一個一星期的迭代，一共兩個故事，每個估算3個故事點，完成這輪迭代，他們完成了這兩個故事并算出其團隊速率為6。如果他們用結(jié)對編程并且以理想結(jié)對日來估算。他們研究故事后決定每個故事需要兩個理想結(jié)對日。這個迭代結(jié)束后，他們完成了這兩個故事，并算出其團隊速率為4。數(shù)字不一樣，但這兩種情況速率是一樣的。一個迭代都是完成這兩個故事。

一些提醒

• 你的團隊的故事點和我的團隊的故事點是不一樣的。你的團隊估算的故事有3個故事點，可能我的團隊估算有5個故事點。
• 一個故事（可能是一個史詩故事）分解成一些小故事后，這些小故事估算的總和不需要與開始那個故事或史詩故事估算相等。
• 類似地，一個故事分解成一些任務(wù)。這些任務(wù)估算的總和不需要與故事的估算相等。

小結(jié)

• 用故事點估算故事，故事點是故事復(fù)雜度、工作量或工期的相對估算。
• 應(yīng)由團隊估算故事，估算屬于團隊而不是個人。
• 通過和其他估算進行比較來進行三角測量。
• 團隊是否使用結(jié)對編程對故事點估算沒有影響。結(jié)對編程影響的是團隊的速率，不是他們的估算。

開發(fā)人員職責

• 負責用一個方式定義故事點，并且對團隊可用和相關(guān)的。努力保證這個定義的一致性。
• 負責給出誠實的估算，不屈服于誘惑或壓力而給出低的估算。
• 負責以團隊估算
• 負責估算應(yīng)與其他估算一致。即所有2點的故事都應(yīng)差不多。

客戶職責

• 負責參加估算會議，但是你的任務(wù)是回答問題并澄清故事細節(jié)。你不必參與故事估算。

第 9 章 發(fā)布計劃

DSDM(Business Focused Development) 包括一個排列優(yōu)先級的方法，稱為莫斯科（MoSCow）規(guī)則：

• 必須有（Must have）
• 應(yīng)該有（Should have）
• 可以有（Could have）
• 這次不會有（Won't have this time）

可以通過多個維度為故事排列優(yōu)先級：

• 故事不能如期完成的風險（如需要有預(yù)期的性能特點或全新算法時）
• 推遲實現(xiàn)一個故事時對其他故事的影響。
• 故事對于廣泛用戶或客戶的重要性
• 故事對于少部分重要用戶或客戶的重要性
• 故事與其他故事的內(nèi)聚性

獲得初始速率的三種方式：

• 使用歷史值
• 執(zhí)行一輪初始迭代，使用那輪迭代的速率
• 猜測

一個由6人組成的團隊，使用為期2周的迭代長度（10個工作日），每輪迭代會有60個開發(fā)日。取決于他們預(yù)計的工作日與理想日之間的差異，他們可能想把速率估算為每輪迭代只能完成20~30個故事點。

小結(jié)

• 在計劃發(fā)布時，有必要知道客戶預(yù)期的大致發(fā)布日期和故事的相對優(yōu)先級
• 故事應(yīng)該以明確的順序排列。
• 故事的優(yōu)先級有客戶確定，但也要考慮開發(fā)人員的想法
• 使用速率將以理想日為單位的估算轉(zhuǎn)換成日歷日
• 估算團隊的初始速率是很有必要的

開發(fā)人員職責

• 負責提供信息給客戶，以幫助她排列故事優(yōu)先級
• 負責在基礎(chǔ)性需求或者架構(gòu)性需求與其他客戶需求之間取得權(quán)衡，避免不切實際地提高基礎(chǔ)性需求或架構(gòu)性需求的優(yōu)先級
• 建立發(fā)布計劃時，負責在實際估算的基礎(chǔ)上，適當包括一定長短的時間用以項目緩沖。

客戶職責

• 負責以自己對故事價值的估計來確切排列用戶故事的優(yōu)先級。
• 負責誠實地表達發(fā)布期限。
• 負責理解理想日和日歷日的不同
• 在想對故事的不同組件排列不同的優(yōu)先級時，負責分割故事。
• 負責了解為何不應(yīng)該譴責或批評一位個人速率為0.6的程序員，只因為她的速率小于1.0

第 10 章 迭代計劃

迭代計劃會議內(nèi)容：

• 討論故事
• 從故事中分解出任務(wù)
• 開發(fā)人員承擔每個任務(wù)的職責
• 討論過所有故事，并且接受所有任務(wù)后，開發(fā)人員單獨估計他們承擔的任務(wù)，以確保他們不會做出過于樂觀的承諾。

小結(jié)

• 迭代計劃是發(fā)布計劃的進一步計劃，但只在迭代即將開始時才開始做迭代計劃。
• 迭代計劃中，團隊討論每個故事，然后從故事中分解出任務(wù)。
• 任務(wù)的大小沒有強制的范圍。相反，從故事中分解出任務(wù)用來幫助估算或鼓勵多個開發(fā)人員合作完成一個故事。
• 每個任務(wù)都有開發(fā)人員承擔。
• 開發(fā)人員通過估算他們承擔的任務(wù)，評估他們是否承諾過度。

開發(fā)人員職責

• 負責參加迭代計劃會議
• 負責幫助把所有故事劃分為任務(wù)，而不只是自己想做的故事
• 負責為認領(lǐng)的任務(wù)承擔責任。
• 負責確保承擔適當工作量的任務(wù)
• 在整輪迭代中，負責監(jiān)控自己剩余的工作，同時也要監(jiān)控隊友剩余的工作。如果很快就能完成自己的工作，就有責任幫助隊友承擔部分工作。

客戶職責

• 負責對迭代中包含的故事排列優(yōu)先級
• 負責指導開發(fā)人員交付他們能提供的最大商業(yè)價值，意味著，從發(fā)布計劃設(shè)定后，諾有更高價值的故事，要負責調(diào)整優(yōu)先級以交付最大的商業(yè)價值。
• 負責參加迭代計劃會議。

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

尚未全部完成的故事不能包括在計算中，因為：

• 沒法計算故事已完成的百分比；
• 不能使用帶小數(shù)的值為速率引入錯誤的精度；
• 沒完成的故事通常不能給用戶或客戶帶來任何價值。

用集中全部力量完成一個故事的方法會提高團隊的意識：大家一起先完成一些故事比所有故事都只完成一部分更有價值。

為每輪迭代畫出計劃速率和實際速率：

image.png

image.png

Burndown Chart