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

在敏捷開發過程中是通過使用者故事來將需求具體化成可以進行反覆式開發法的一個個現實的可見的開發工作單位。因此在敏捷軟體的開發過程中，使用者故事的劃分對於迭代和開發起著舉足輕重的作用。

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

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

在使用者故事的劃分中有三要素，分別為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。

 

胡亂寫了一通，也沒有什麼思路和頭緒，暫且先這樣，等以後有時間了再改改，mark！