對于Scrum開發(fā)來說，User Story是開發(fā)的基礎(chǔ)，它不同于傳統(tǒng)的UDD開發(fā)方式，而是把原本需求拆成最小粒度的Story，以方便Scrum小組拆分Task，估計開發(fā)
User Story不需要太過于詳細(xì)，只有在正式開發(fā)時，做詳細(xì)設(shè)計時在進(jìn)入Detail階段，如果初期時間估算不準(zhǔn)確，實際工作量增多時，Sprint Chart需要適當(dāng)?shù)?/div>
Burn-up。
User Story可以遵循以下模板：
As a <User Type>
I want to <achieve goal>
So that I can <get some value>
例如：作為一個病人，我可以預(yù)約一個醫(yī)生，讓他給我看病。
User Story應(yīng)遵循INVEST規(guī)則：
Independent 獨立性，避免與其他Story的依賴性。
Negotiable 可談判性，Scrum中的story不是瀑布開始某事中的Contract, Stories不必太過詳細(xì)，開發(fā)人員可以給出適當(dāng)?shù)慕ㄗh。
Valueable 有價值性， Story需要體現(xiàn)出對于用戶的價值
Estimable 可估計性，Story應(yīng)可以估計出Task的開發(fā)時間。
Sized Right 合理的尺寸， Stories應(yīng)該盡量小，并且使得團(tuán)隊盡量在1個sprint(2 weeks)中完成。
Testable 可測試性， User Story應(yīng)該是可以測試的，最好有界面可以測試和自動化測試。每個任務(wù)都應(yīng)有Junit Test.
經(jīng)驗：
1. 永遠(yuǎn)不要在User Story中使用And和Or，因為這是些分支詞就表示分支任務(wù)，把它們拆成兩個Story.
2. 數(shù)據(jù)整理：通常情況下1個sprint(2周一次迭代)可以做4～5個Story，極端大的Story不可大于1個sprint。
3. 數(shù)據(jù)整理：通常情況下1個sprint(2周一次迭代)可以做50個左右的Task。
4. User Story用于描述用戶故事，不要包括任何的技術(shù)，框架等內(nèi)容。Task可以包括框架，技術(shù)等內(nèi)容。
我們通常用User Story來描述Backlog里的各個Backlog項，User Story是從用戶的角度對系統(tǒng)的某個功能模塊所作的簡短描述。一個User Story描述了項目中的一個小功能，以及>這個功能完成之后將會產(chǎn)生什么效果，或者說能為客戶創(chuàng)造什么價值。
User Story要由Stakeholder（利益相關(guān)者）來編寫。User Story的形式很簡單，人們可以很容易地掌握編寫User Story的方法。這樣就可以保證是由與項目相關(guān)領(lǐng)域?qū)＜覀儊?/div>
編寫User Story，而不是開發(fā)人員。
我們通常把User Story寫在一張小卡片上，同時在卡片上標(biāo)明它的優(yōu)先級和預(yù)計完成時間，以便開發(fā)人員根據(jù)任務(wù)的優(yōu)先級來制定Sprint Backlog。而且，Stakeholder可以隨時更改一個Story的優(yōu)先級，那么此時開發(fā)人員就應(yīng)該相應(yīng)地調(diào)整Story的開發(fā)次序。
一個User Story的大小和復(fù)雜度應(yīng)該在一個Sprint中開發(fā)完畢為宜。如果User Story太大，可能會導(dǎo)致對它的開發(fā)橫跨幾個Sprint。這種情況是需要避免的。此時就應(yīng)該將這個User Story分解。
為了能及時、高效地完成每個Story，Scrum團(tuán)隊會把每個Story分解成若干個Task。每個Task都是可以在明確的時間內(nèi)完成的，而且時間是以小時為計量單位的。特別提示：每個Task的時間最好不要超過8小時，就是要保證1個工作日內(nèi)完成，如果做計劃時發(fā)現(xiàn)有些Task的時間超過了8小時，就說明Task的劃分有問題，需要特別注意。
-----------------------------------------------------
Silence, the way to avoid many problems;
Smile, the way to solve many problems;
