如何編寫敏捷開發中的user story
阿新 • • 發佈：2018-12-24
對於敏捷開發來說，User Story是開發的基礎，它不同於傳統的瀑布式開發方式，而是把原本需求拆成最小粒度的Story，以方便拆分Task，估計開發時間，領取開發任務。
優點和好處
- Being very short. They represent small chunks of business value that can be implemented in a period of days to weeks.
- Allowing developer and client to discuss requirements throughout the project lifetime
- Needing very little maintenance
- Only being considered at the time of use
- Maintaining a close customer contact
- Allow projects to be broken into small increments
- Suited to projects where the requirements are volatile or poorly understood. Iterations of discovery drive the refinement process.
- May be easier to estimate development effort
User Story模板
User Story可以遵循以下模板：As a <User Type> I want to <achieve goal> So that I can <get some value>
翻譯成中文就是：作為一個<某種型別的使用者>，我要<達成某些目的>，我這麼做的原因是<開發的價值>。
User Story應遵循INVEST規則
- Independent 獨立性，避免與其他Story的依賴性。
- Negotiable 可談判性，Scrum中的story不是瀑布開始某事中的Contract, Stories不必太過詳細，開發人員可以給出適當的建議。
- Valueable 有價值性， Story需要體現出對於使用者的價值
- Estimable 可估計性，Story應可以估計出Task的開發時間。
- Sized Right 合理的尺寸， Stories應該儘量小，並且使得團隊儘量在1個sprint(2 weeks)中完成。
- Testable 可測試性， User Story應該是可以測試的，最好有介面可以測試和自動化測試。每個任務都應有Junit Test.
一些經驗：
- 永遠不要在User Story中使用And和Or，因為這是些分支詞就表示分支任務，把它們拆成兩個Story.
- 資料整理：通常情況下1個sprint(2週一次迭代)可以做4～5個Story，極端大的Story不可大於1個sprint。
- 資料整理：通常情況下1個sprint(2週一次迭代)可以做50個左右的Task。
- User Story用於描述使用者故事，不要包括任何的技術，框架等內容。Task可以包括框架，技術等內容。