1 從這里開始

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

當(dāng)你學(xué)完這部分之后，你就可以定義、編寫、測試你的Stories，同時(shí)你應(yīng)該準(zhǔn)備去看如何通過User Stories去進(jìn)行評估和計(jì)劃，也就是第二部分的內(nèi)容。

1.1 概述

軟件需求是一個(gè)溝通的問題，想得到（或者使用，或者出售）新軟件的人，必須和軟件的生產(chǎn)者進(jìn)行溝通。項(xiàng)目的成功與否，依賴于從不同的人那里得到的信息：一方面是客戶、用戶、分析人員、領(lǐng)域?qū)＜乙约捌渌麖臉I(yè)務(wù)或者組織角度來看待軟件的人；另一方面則是技術(shù)團(tuán)隊(duì)。

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

我 們需要一種方法讓大家一起合作，以至于溝通不會被單方控制，并且資源分配中的感情因素和原則問題就變成了雙方共同的問題。.當(dāng)資源分配完全傾向一方的時(shí) 候，項(xiàng)目就會失敗。如果開發(fā)人員全權(quán)負(fù)責(zé)（無論怎樣都必須在7月份之前全部做完），他們可能會因?yàn)橐恍└郊拥墓δ芏鵂奚|(zhì)量，或者只實(shí)現(xiàn)部分功能，或者獨(dú) 自制定本該客戶或用戶參與制定的大量的決定。當(dāng)客戶和用戶方全權(quán)負(fù)責(zé)，項(xiàng)目前期就會出現(xiàn)一個(gè)漫長的討論過程，在這個(gè)過程中越來越多的功能被從項(xiàng)目中刪除， 當(dāng)軟件被交付的時(shí)候，甚至實(shí)現(xiàn)的功能比刪掉的功能少。

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

那么，怎么辦？

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

1.1.1 User Story 是什么？

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

• 用來制定計(jì)劃和作為提醒的一段書面描述
• 用來充實(shí)story的細(xì)節(jié)的談話
• 測試用例，用來表達(dá)和記錄細(xì)節(jié)并且能夠在story實(shí)現(xiàn)的時(shí)候?qū)M(jìn)行驗(yàn)證

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

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

Story Card 1.1 是一個(gè)寫在卡片上的初期的User Story

（用戶可以在網(wǎng)站上發(fā)布簡歷）

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

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

因?yàn)閡ser stories 描述了對客戶來說有價(jià)值的功能點(diǎn)，所以對這個(gè)系統(tǒng)來說下邊的例子就不是好的user stories。

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

第一個(gè)例子對BigMoneyJobs來說不是個(gè)好的user story是因?yàn)橛脩舾揪筒魂P(guān)心使用哪種編程語言。但是，如果這是一個(gè)應(yīng)用程序接口，用戶（他本身就是個(gè)程序員）寫下“The software will be written in C++（軟件應(yīng)該用C++來編寫）”就會很好。

第二個(gè)story在這種情況下也不是個(gè)好的user story ，因?yàn)橄到y(tǒng)的使用者并不關(guān)心應(yīng)用程序如何連接到數(shù)據(jù)庫的技術(shù)細(xì)節(jié)。

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

1.1.2 細(xì)節(jié)在哪呢？

說 “A user can search for jobs（用戶可以查找職位）”是一件事情，而能否只靠這個(gè)作為指導(dǎo)就開始編碼和測試卻是另外一件事情。因?yàn)椋?xì)節(jié)在哪里呢？類似于下邊的這些問題怎么辦呢？

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

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

當(dāng)一個(gè)故事太大的時(shí)候，他通常會被作為一個(gè)Epic（譯者注：此詞本意為史詩級的，我沒有找到合適的漢語詞匯表達(dá)，就是大的故事集的意思）提出.Epics可以被分割成兩個(gè)或更多個(gè)小故事。例如，這個(gè)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.（用戶可以通過地區(qū), 薪水, 職位, 單位名稱, 和職位發(fā)布日期 來搜索）
• A user can view information about each job that is matched by a search.（用戶可以查看搜索出來的每個(gè)職位的詳細(xì)信息）
• A user can view detailed information about a company that has posted a job.（用戶可以查看發(fā)布職位空缺信息公司的詳細(xì)信息）
• 但是，當(dāng)我們的story能夠涵蓋所有的細(xì)節(jié)時(shí)，我們就不再去分割story了。例如，故事“A user can view information about each job that is matched by a search”是非常適度和實(shí)用的。我們不需要再去把它進(jìn)一步的像這樣去拆分：
• 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.（用戶可以查看工作地點(diǎn)）

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

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.

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

Story Card 1.2. A story card with a note.

1.1.3 故事應(yīng)該有多長呢？

當(dāng)我上中學(xué)文化課時(shí)候，每當(dāng)我們被指定去寫一篇論文，我總是問“論文必須寫多長呢？”老師是不喜歡這個(gè)問題的，但是我仍然認(rèn)為這個(gè)問題是必要的，因?yàn)樗嬖V我老師期望的是什么。這個(gè)問題同樣也是了解項(xiàng)目用戶需求很重要的一點(diǎn)。這些要求最好以可測試的形勢被捕獲。

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

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

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

1.1.4 客戶團(tuán)隊(duì)

對于一個(gè)理想的項(xiàng)目來說，我們會有一個(gè)專門的系統(tǒng)最終用戶，他為開發(fā)人員區(qū)分工作的優(yōu)先級，并回答他們的問題，編寫所有的Stories。這個(gè)是太理想的 情況，所以，我們創(chuàng)建一個(gè)客戶團(tuán)隊(duì)，這個(gè)團(tuán)隊(duì)里包括那些可以保證軟件達(dá)到最終用戶需求的那些人。這就意味著這個(gè)客戶團(tuán)隊(duì)包括測試人員、管理人員、用戶和交 互設(shè)計(jì)人員。

User Story 在敏捷開發(fā)過程中的應(yīng)用