1 從這里開始

第一部分我們將快速瀏覽什么是user stories以及如何使用，然后將闡述如何編寫User Stories；如何通過系統用戶模型來定義Stories；當客戶自己本身無法前來的時候，如何同那些能夠充當客戶角色的人一起工作；如何來編寫測試用 例，來證明你的Stories已經被成功編寫的細節，最后將闡述幾條編寫好的Story的指導建議。

當你學完這部分之后，你就可以定義、編寫、測試你的Stories，同時你應該準備去看如何通過User Stories去進行評估和計劃，也就是第二部分的內容。

1.1 概述

軟件需求是一個溝通的問題，想得到（或者使用，或者出售）新軟件的人，必須和軟件的生產者進行溝通。項目的成功與否，依賴于從不同的人那里得到的信息：一方面是客戶、用戶、分析人員、領域專家以及其他從業務或者組織角度來看待軟件的人；另一方面則是技術團隊。

如果任何一方控制了溝通，那么項目注定會失敗。如果業務一方控制，則會要求功能和日期，而不太擔心開發人員是否能全部完成或者開發人員是否明白他們的真正要求；如果開發人員控制了溝通，技術術語會代替業務語言，開發人員也失去了通過傾聽來了解客戶真正需求的機會。

我 們需要一種方法讓大家一起合作，以至于溝通不會被單方控制，并且資源分配中的感情因素和原則問題就變成了雙方共同的問題。.當資源分配完全傾向一方的時 候，項目就會失敗。如果開發人員全權負責（無論怎樣都必須在7月份之前全部做完），他們可能會因為一些附加的功能而犧牲質量，或者只實現部分功能，或者獨 自制定本該客戶或用戶參與制定的大量的決定。當客戶和用戶方全權負責，項目前期就會出現一個漫長的討論過程，在這個過程中越來越多的功能被從項目中刪除， 當軟件被交付的時候，甚至實現的功能比刪掉的功能少。

我們已經知道了我們不能夠完美 的預言一個軟件開發項目。當用戶看到軟件的初版時，他們會產生一些新的想法，改變一些他們原有的想法，由于軟件的不可把握性，開發人員進行時間估算變得非 常困難。由于種種原因，我們無法羅列一個完整的PERT圖表來顯示我們在項目里所必須完成的全部工作。

那么，怎么辦？

我們經常通過手頭已經掌握的資料來做決定，會好過在項目初期就做出所有的決定。我們把做決定分散到整個項目過程中。為了做到這一點，我們要確認已經有一個盡早盡多獲得相關的資料的程序。User Stories 由此而生。

1.1.1 User Story 是什么？

User story是對軟件的用戶或買主有價值的功能點的描述。User stories 由以下三點組成：

• 用來制定計劃和作為提醒的一段書面描述
• 用來充實story的細節的談話
• 測試用例，用來表達和記錄細節并且能夠在story實現的時候對進行驗證

因 為User Story的描述是通過傳統的手寫記錄在卡片上，所以Ron Jeffies給這三個方面起了很好的名字，Card（卡片），Conversation（會話），和Confirmation（確認）。卡片是 story最可見的表現形式，但是他不是最重要的。Rachel Davies 已經說過，卡片“重現客戶需求場景好于記錄它們”。思考User Stories的完美方法是：card 包含story的正文，通過會話得出細節，并記錄在測試用例中。

User story 的例子，請參見Story Card 1.1

Story Card 1.1 是一個寫在卡片上的初期的User Story

（用戶可以在網站上發布簡歷）

為了保持一致，貫穿剩下的這本書的例子大多都是為BigMoneyJobs 網站而設計的。其他的例子故事可能包括：

• A user can search for jobs（用戶可以查找職位）
• A company can post new job openings（公司可以發布新的職位）
• A user can limit who can see her resume（用戶可以限制那些人可以查看他的簡歷）

因為user stories 描述了對客戶來說有價值的功能點，所以對這個系統來說下邊的例子就不是好的user stories。

• The software will be written in C++.（軟件應該用C++來編寫）
• The program will connect to the database through a connection pool（軟件應該通過連接池來連接到數據庫）.

第一個例子對BigMoneyJobs來說不是個好的user story是因為用戶根本就不關心使用哪種編程語言。但是，如果這是一個應用程序接口，用戶（他本身就是個程序員）寫下“The software will be written in C++（軟件應該用C++來編寫）”就會很好。

第二個story在這種情況下也不是個好的user story ，因為系統的使用者并不關心應用程序如何連接到數據庫的技術細節。

也許，你已經讀了這些stories 并且很驚訝地說，“等等，使用一個連接池是我這個系統的一個需求” 如果這樣的話，請一定要清楚，編寫stories的關鍵點在于讓客戶認可他們的價值，我們將在第二部分“編寫story”里看到一些關于編寫Story方面的例子。

1.1.2 細節在哪呢？

說 “A user can search for jobs（用戶可以查找職位）”是一件事情，而能否只靠這個作為指導就開始編碼和測試卻是另外一件事情。因為，細節在哪里呢？類似于下邊的這些問題怎么辦呢？

• What values can users search on? State? City? Job title? Keywords?（用戶查詢的條件是什么？州？城市？職位？關鍵字？）
• Does the user have to be a member of the site?（用戶必須是網站的注冊用戶嗎？）
• Can search parameters be saved?（可以保存查詢條件么？）
• What information is displayed for matching jobs?（查詢頁面上應該顯示哪些信息呢？）
• 許多類似的細節可以當作另外的stories來描述。實際上，多做幾個stories 比做一個很大的stories要好。例如整個的BigMoneyJobs 網站可以用這兩個stories來描述：
• A user can search for a job（用戶可以找工作）
• A company can post job openings（公司可以發布職位空缺（好機會））

很明顯，這兩個stories太大了，大到沒有太大用處.，在第二章“編寫故事”中，完整的闡述了故事大小的問題。從一、兩個開發人員花費半天或者兩個星期來編寫和測試一個story開始，是一個不錯的起點。 公平一些來講（Liberally interpreted），上邊的兩個stories簡單的概括了BigMoneyJobs網站的大部分功能，，每一個大概要花費程序員多于一周的時間。

當一個故事太大的時候，他通常會被作為一個Epic（譯者注：此詞本意為史詩級的，我沒有找到合適的漢語詞匯表達，就是大的故事集的意思）提出.Epics可以被分割成兩個或更多個小故事。例如，這個Epic“A user can search for a job（用戶可以找工作）”就可以被分割成這些Stories。

• A user can search for jobs by attributes like location, salary range, job title, company name, and the date the job was posted.（用戶可以通過地區, 薪水, 職位, 單位名稱, 和職位發布日期 來搜索）
• A user can view information about each job that is matched by a search.（用戶可以查看搜索出來的每個職位的詳細信息）
• A user can view detailed information about a company that has posted a job.（用戶可以查看發布職位空缺信息公司的詳細信息）
• 但是，當我們的story能夠涵蓋所有的細節時，我們就不再去分割story了。例如，故事“A user can view information about each job that is matched by a search”是非常適度和實用的。我們不需要再去把它進一步的像這樣去拆分：
• A user can view a job descrīption.（用戶可以查看職位描述）
• A user can view a job's salary range.（用戶可以查看職位薪水）
• A user can view the location of a job.（用戶可以查看工作地點）

總的來說，user story 不需要用專業的需求文檔格式夸張的描述成下面這個樣子。

4.6)

A user can view information about each job that is matched by a search.

4.6.1)

A user can view the job descrīption.

4.6.2)

A user can view a job's salary range.

4.6.3)

A user can view the location of a job.

比 坐在這里把這些細節寫成stories更好的方法就是開發團隊和客戶來一起討論這些細節。就是說，當這些細節比較重要的時候，就把他拿出來討論。討論后， 在卡片上添加一些注釋是沒有錯的，就像Story Card 1.2.一樣。可是，重點是會話，而不是story card上的筆跡。不管是開發人員還是客戶都能夠在3個月后還指著卡片說“看，我那時候是這么說的”。Stories并不承擔法律責任。我們將看到，協議 通過可以證明某個story被正確實現的測試用例來記錄。

Story Card 1.2. A story card with a note.

1.1.3 故事應該有多長呢？

當我上中學文化課時候，每當我們被指定去寫一篇論文，我總是問“論文必須寫多長呢？”老師是不喜歡這個問題的，但是我仍然認為這個問題是必要的，因為它告訴我老師期望的是什么。這個問題同樣也是了解項目用戶需求很重要的一點。這些要求最好以可測試的形勢被捕獲。

如果你使用的是紙質的筆記卡片，你可以把卡片翻過來，把需求寫到背面。這些記錄下來的要求提醒怎樣測試這個story，就像Story Card 1.3所顯示的那樣。如果你使用的是電子系統，它應該有一個地方可以讓你加進一些可測試性的提醒。

Story Card 1.3. The back of a story card holds reminders about how to test the story.

測試描述是簡短和不完備的，測試用例可以隨時添加或者刪除。目的是涵蓋Story的附加信息，以便開發人員知道Story什么時候就算完成了。就像老師的要求對我來說很有用，我可以知道什么時候我寫的關于Moby Dick的東西算完成了。它對于開發人員來了解什么時候完成了客戶需求一樣有用。

1.1.4 客戶團隊

對于一個理想的項目來說，我們會有一個專門的系統最終用戶，他為開發人員區分工作的優先級，并回答他們的問題，編寫所有的Stories。這個是太理想的 情況，所以，我們創建一個客戶團隊，這個團隊里包括那些可以保證軟件達到最終用戶需求的那些人。這就意味著這個客戶團隊包括測試人員、管理人員、用戶和交 互設計人員。

User Story 在敏捷開發過程中的應用