【公眾號 “專案管理研究所” 將會第一時間更新文章並[分享行業分析報告]】
歸檔於軟體專案管理初級學習路線
第五章 軟體專案任務分解
《初級學習路線合集 》
前言
大家好，這節我們學習軟體專案管理---敏捷任務分解方法。
一、敏捷專案的任務分解
敏捷開發過程是通過使用者故事，將需求具體化成可以進行迭代開發的任務。
Epics是由許許多多小大的，不確定的需求組成，不能直接通過迭代開發，需要劃分為較小的，真正的user stories。
另外Epics有時包含著太多且模糊的需求，所以常常包含著不同的特性，而一個特性就是一組可以歸為一類的需求。
因此敏捷專案的分解級別如下，Epic是比較大的story，那麼Epic可以分解為一類，一類就是一個Feature，那麼Feature下可以分解出一些user story。
例如：某Epic是硬碟備份功能，我們可以分解出兩個story。第一個story是作為power user 為了更好管理檔案，登記檔案規模，建立或者修改日期，對檔案或者資料夾備份。
第二個story是作為user,為了使備份的驅動器不會被不需要的內容裝滿，需要標識出不需要的資料夾。
這也是一個Epics分解的例子：Epic分解了四個story。
story編寫完成之後，應該寫出接收標準，那麼他（如下圖）可以作為使用者測試story的依據。
翻譯：驗收標準只是一個高階別的驗收測試，在敏捷使用者故事完成後，它將是真實的。通常情況下，它會寫在故事的背面。這是一個很好的方法，可以確保故事被理解，並邀請團隊就我們試圖建立的業務規則進行談判。
例如這個story是建立賬戶功能，設立驗收標準如下：
- 確保這個使用者在系統中存在。
- 確保使用者的信用狀況是滿意的。
- 確保賬戶型別是正確的。
- 確保賬戶是唯一的。
- 賬戶密碼是6位數字。
那麼這就是5條接收標準。
二、任務分解輸出-列表
敏捷專案的任務分解輸出可以是對backlog列表進行細化的過程，將編寫完成的story彙總到backlog列表中，那麼他也是後續規劃的基礎。
總結
總之 敏捷專案任務分解就是將Epic分解成多個story的過程。
到這裡，第五章 軟體專案任務分解就講解完畢了！下一章介紹軟體專案成本計劃~
如果您覺得這篇文章有幫助到您的的話不妨點贊支援一下喲~~?
後續將持續更新【軟體專案管理初級學習路線】的全知識點，大家感興趣的多多關注博主喲~
————————————————