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。這個是太理想的情況，所以，我們建立一個客戶團隊，這個團隊裡包括那些可以保證軟體達到終端使用者需求的那些人。這就意味著這個客戶團隊包括測試人員、管理人員、使用者和互動設計人員。