■User Story 是什麼？
User story是對軟體的使用者或買主有價值的功能點的描述。
1.他是用來制定計劃和作為提醒的一段書面描述
2.用來充實story的細節的談話
3.測試用例，用來表達和記錄細節並且能夠在story實現的時候對進行驗證
每個Story都有每個Story存在的價值，編寫stories的關鍵點在於讓客戶讓你們的主管和經理們認可Story的價值。

■如何去編寫Story
1.使用5W1H的方式去編寫Story
5W1H:what, when, where, why, who, How
在編寫Story的時候，用盡可能短的語言去表述清楚what，where，why就可以了
至於How，when, who則可以在planningMTG中通過和客戶，領導等溝通去決定。

Story例：某某功能的內部処理を設計、実裝和測試
問題點：某某功能是what？這個Story的完成基準又是什麼？在這個例子中，都沒有明確的說明。那麼該如何去判斷做什麼，又如何去判斷完了呢。
在優秀的軟體中，每一行程式碼都為了完成一個或者多個功能而存在的。在Story中把真正what, where, why用最簡單的方式去說明清楚吧。
設計、実裝、測試、DR等等是How，是為了完成這個Story的手段。
因為Story做成提倡儘可能短，所以不要將How放入Story中。將How作為Story的一個補充說明才是上上之策。

2.一個Story必須要有一個明確的Goal
簡單來說一個Story在作成完了後，必須能夠判斷他的Goal條件。如果Story中無法明確傳達Goal條件的話，也就失去了用Story來管理進度的意義了。
至於你使用機能點還是測試點或者是成果物單位來對Story進行分解，這個是次要的，關鍵是每個Story要有一個明確的完成基準。

3.根據是否有明確的最終Goal分開考慮作成Story
明確最終Goal的專案中，用TopDown的方式，分解Story，每一個Story就是一個Goal,所有的小Story達成後，最終Goal也就達成，如果你的Story中有和最終Goal沒有關係的小Goal，那麼就把這個Story果斷的去掉吧。
當沒有明確最終Goal的專案中，用BottomUp的方式，把眼前能夠要做的該做的先做好後，再去和客戶檢討式樣把。檢討以後再作成Story。如果能做到的話，就可以"擁抱變化"了。

4.不明確事項，檢討專案也需要管理
專案開發過程中，有太多的TBD專案，有太多的曖昧的地方，這就是軟體開發。
這些地方也請你用Story或者其他方式將他管理起來，在早會時定期聯絡。不要在你的Story中出現這些不確定的內容。
如果你的Story因為某些不確定原因而無法著手的話，請果斷將這個Story掛起，並及時通知ScrumMaster吧。

■如何去使用Story
1.Story需要定期維護嗎
在剛開始軟體開發的階段，並不需要也沒有必要把所有的Story都分好詳細列出，因為軟體開發中存在太多的不確定的因素。客戶的需求也不是一成不變的。
剛開始只要列出一個完成開發的大致的指令碼就可以了，當真正開始做之前，再把故事指令碼細化為可以量化的Story。什麼時候明確了需求，再去考慮為了完成需求的具體的Story。理論上在PlanningMTG的時候把近1~2周的計劃列出來，進行相對的工作量估算後，就開始衝刺。如果能夠這樣的話，團隊的效率是最高的。
所以敏捷開發中提倡的就是一邊開發一邊去作Story。

2.StoryPoint如何確定
根據書上所說，先選出一個大小適中的Story作為模板，將Point分為1,3,5,8,13等相對數值來標示一個作業的工作量。每個Story最好能夠在3天之內完成。
我覺得相對於花時間去想去決定Point，還不如把時間花在專案本身上，Point只是一個工作量的標示罷了。每個專案都有每個專案的特殊性，Point也好，對一個Story使用百分比也好，只要能夠將進度實現視覺化就可以了。

3.進度的自我管理
用Story管理也好，用白板管理進度也好，用其他的進度管理方式也好。都只是進度管理的方法而已。真正清楚進度的人並不是專案主管，專案經理，也不是客戶，應該是擔當該要件的人。當你發現進度提前或者落後的時候，就主動想好原因對策以後，找ScrumMaster溝通吧。世界上沒有完美的專案進度計劃，專案中每個人的進度情況構成了一個專案的進度情況。使用好Story去管理進度，而不要依賴於Story去管理進度。

4.Story僅僅只是為了進度管理嗎？不是。
進度管理只是他一部分的作用，利用Story不僅僅是進度管理，Story也是要件擔當者和專案關係者(主管,專案經理,測試員,客戶)之間的一個溝通模板。
利用好這個溝通模板，才能更好的挖掘出客戶的潛在需求，才能更好的將自己的成果頻繁主動的展示給你的專案經理。拿著你做好的Story主動和他們去溝通吧。
敏捷開發提倡頻繁的溝通，如果沒有良好而頻繁的溝通，Story的作用效果也就大打折扣了。

結束語:如果一個要件是一部電影的話，擔當要件的人就是總導演，Story就是為了完成電影的一個個鏡頭。在設計軟體之前，請先設計好你的Story把。一個個短短的鏡頭就構成了一部電影。做一個優秀的導演，從先設計好一個個短短的鏡頭(Story)開始。