在敏捷開發過程中是通過用戶故事來將需求具體化成可以進行迭代開發的一個個現實的可見的開發任務。因此在敏捷軟件的開發過程中，用戶故事的劃分對于迭代和開發起著舉足輕重的作用。
用戶故事從其名字來看是站在用戶的角度所描述的故事，同時也是用戶所能看懂的故事，開發人員最容易犯下的一個錯誤就是站在自己的角度去思考和劃分故事，這樣就背離了用戶故事的初衷。
?
那什么是用戶故事？首先來說用戶故事是對需求的細化和切分，既然是細化，就得有一個度，需求的顆粒度需要多少才能稱之為用戶故事？這就牽扯出和用戶故事一起出現的另外一個關鍵的單詞叫史詩故事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。
?
https://blog.csdn.net/rxr1st/article/details/7479472
?
)
