敏捷開發(agile)中story
阿新 • • 發佈:2018-12-23
Story概念:
- User Story是敏捷開發的基礎,它不同於傳統的瀑布式開發方式,而是把原本需求拆成最小粒度的Story,以方便拆分Task,估計開發時間,領取開發任務。
- User Story是從使用者的角度對系統的某個功能模組所作的簡短描述
- 一個 User Story 描述了專案中的一個小功能,以及這個功能完成之後將會產生什麼效果,或者說能為客戶創造什麼價值
- User Story是敏捷開發和管理的核心,要確保Story的輸出質量。
Story優點和好處:
- 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劃分原則(INVEST規則):
- 獨立性(Independent):一定要保證Story在功能上的獨立,儘量不要有Story之間的依賴,否則會大大影響將來的開發和測試。
- 可談判性(Negotiable):Scrum中的story不是瀑布開始某事中的Contract, Stories不必太過詳細,開發人員可以給出適當的建議。
- 有價值性(Valuable): Story需要體現出對於使用者的價值。
- 可估計性(Estimable):Story應可以估計出Task的開發時間。
- 大小合適(Sized Right):關於Story的粒度,建議的開發工作量是3-5天(包含針對Story所做的開發者自測工作量),如果Story不能拆分到3-5天的開發粒度,則一定要確保該Story在一個迭代週期內可開發測試完成。
- 可測試性(Testable):要從可測試性考慮需求,同時要考慮能夠獨立測試,每個任務都應有Junit Test。另外注意,伴隨Story要同時輸出可接受性測試用例(Acceptance Test Case,以下簡稱AT),用於驗證Story是否開發完成,可以給測試人員做Story測試。AT用例在Story協作階段只是對測試要點、場景的描述,在迭代開發階段可以繼續補充和完善。
Task:
- 為了能夠及時,高效地完成每個 Story,Scrum 團隊會把每個 Story 分解成若干個 Task。
- 每個Task 的時間最好不要超過8小時,保證在1個工作日內完成,如果 Task 的時間超過了8個小時,就說明Task的劃分有問題,需要特別注意。
User Story模板:
- User Story可以遵循以下模板:As a <User Type> I want to <achieve goal> So that I can <get some value>
- 翻譯成中文就是:作為一個<某種型別的使用者>,我要<達成某些目的>,我這麼做的原因是<開發的價值>。
一些經驗:
- 永遠不要在User Story中使用And和Or,因為這是些分支詞就表示分支任務,把它們拆成兩個Story.
- 資料整理:通常情況下1個sprint(2週一次迭代)可以做4~5個Story,極端大的Story不可大於1個sprint。
- 資料整理:通常情況下1個sprint(2週一次迭代)可以做50個左右的Task。
- User Story用於描述使用者故事,不要包括任何的技術,框架等內容。Task可以包括框架,技術等內容。