劃分使用者故事（user-story）的原則

在靈活開發過程中是通過使用者故事來将需求具體化成可以進行疊代開發的一個個現實的可見的開發任務。是以在靈活軟體的開發過程中，使用者故事的劃分對于疊代和開發起着舉足輕重的作用。

使用者故事從其名字來看是站在使用者的角度所描述的故事，同時也是使用者所能看懂的故事，開發人員最容易犯下的一個錯誤就是站在自己的角度去思考和劃分故事，這樣就背離了使用者故事的初衷。

那什麼是使用者故事？首先來說使用者故事是對需求的細化和切分，既然是細化，就得有一個度，需求的顆粒度需要多少才能稱之為使用者故事？這就牽扯出和使用者故事一起出現的另外一個關鍵的單詞叫史詩故事epic，通俗來說就是大型的故事。Epic有一些自身的特點：如是由許許多多的較大的不确定的需求（large fuzzy  requirements）組成；另外epics本身具有更低的優先級，因為你不能直接通過其完成疊代和開發，而是首先需要劃分成較小的真正的user-story；除了這兩點，epics因為包含了太多的模糊性需求，是以常常混雜了很多不同的特性，而一個特性就是一組可以歸為一類的需求，同時對某一特定的使用者存在着互動的價值。

在使用者故事的劃分中有三要素3C，分别為card，conversation和confirmation。

card 故事描述：通過将故事寫在note card上面，除了故事本身的描述之外，還應該包括故事的時間點估計及對應的測試行為等等。

conversation 通過交談豐富内容：使用者故事的具體細節不是某一個開發人員或者PO自己拍着腦袋定義出來的，而需要項目組中的成員與PO或者客戶之間溝通得出的。

confirmation 驗收測試能夠确認故事已經完成：使用者故事劃分以後是由開發人員通過編碼實作，但是不能僅靠開發人員自測确認故事完成，需要的是一系列的驗收測試用以保證故事功能的完成及軟體按照我們的預期運作。

關于使用者的編寫原則，有一個通用的模闆用以站在使用者的角度描述使用者所期望得到的功能：

As a role, I want to do something or a piece of functionality, so that achieve some business value or statement of intent. 

作為一個角色，通過某項操作，以便能夠完成特定的目标。

在這個模闆中有三個不同的點，分别為使用者角色--who，某項操作--what，完成的目标--why（reason）。

如：作為一個國米的球迷，通過點選官網的最新新聞欄，以便能夠實時了解最新的國米動态。

一個良好的User-story的編寫應該遵循INVEST原則：

Independent：獨立性

使用者故事之間應該具有獨立性（有點類似于UT中的test case），不應該依賴于其他的使用者故事。如果使用者故事存在依賴性那麼就會導緻使用者故事之間存在着不同的優先級，隻有被依賴的使用者故事完成才能繼續開發依賴的使用者故事。一般可以通過組合使用者故事或者分割使用者故事來減少使用者故事間的互相依賴性。

Negotiable：可協商

使用者故事不是簽訂的商業合同contracts，它是由客戶或者PO同開發小組的成員共同協商制定的，如果最開始像商業合同一樣設定了太多的條條框框和限制就無法更好的溝通及協商，也就不可能劃分出既讓客戶滿意，也能讓開發認同的好的使用者故事。

Valuable：有價值

使用者故事必須對于最終的使用者是有價值的，是以應該站在使用者的角度去編寫，描述的是一個一個的feature，而非一個一個的task。

Estimable：可評估

對于一個使用者故事的劃分需要足夠的領域知識，使得在劃分i故事之時就能大緻了解故事開發的周期，為了減少估算的不确定性，故事本身不能太大。

Small：短小

故事應該盡量的短小，當然也不是說越小越好。短小的故事可以減少劃分過程中估算的誤差，最好的故事是能夠在一個疊代周期之内完成的。如果太大就應該考慮将其拆分為多個粒度更小的使用者故事。

Testable：可測試

個人認為這一點在所有的特性中對于使用者故事的重要程度最高。首先，如果一個使用者故事無法進行測試，那麼也就無法判斷該故事是否完成。除此之外，對應的驗收測試也最好是自動運作的，這樣在任何時候都能觸發該使用者故事的檢驗。最後，必須在定義了驗收測試通過的标準後才能認為故事劃分完畢。

關于Testable，有一個較為經典的例子：

As  a user, I want to be able to cancel a reservation so that I can get a refund for the trip not taken.

關于此使用者故事前面所提到的幾個要素who，what，why都滿足，那麼驗收測試應該如何去做？模拟的應該是實際的真正場景，如：退款是全退還是部分退還；提前多久cancel才是有效的；退還款項如何與使用者之間進行确認等等。

按照剛才的假設，做一個真實場景的驗收測試用例，通過Given-When-Then的方式來設定：

Given：“我”付款1000RMB預定了一個3周後從成都飛往三亞的航班。

When：在航班起飛前一周“我”取消了該行程。

Then：“我”應該得到預定機票半價的退款（500RMB）

在對使用者故事設定驗收測試的條件時候，分别對應：starting state---》event---》final state

任何的user story，在驗收測試的時候都必須至少設定一個defaule scenario。

使用者故事應滿足的标準INVEST
Ø  Independent-獨立的 ：故事互相之間可以并行開發，有相對獨立的價值。
Ø  Negotiable-可協商的：在能夠實作使用者價值的前提下，實作方式的細節可協商。
Ø  Valuable-有價值的：給最終使用者提供的價值且可度量。
Ø  Estimable-可估算的：團隊在估算故事大小時能達成一緻，不存在不可估算的内容。
Ø  Small-小的：兩周以内可以完成的。
Ø  Testable-可測試的：具備驗收規格和測試條件，且可被自動化測試。