敏捷項目需求拆解&發現用戶故事

需求文檔和敏捷中的Epic，User Story， Task之間是什麼關係以及如何將需求文檔轉換成敏捷方式的描述，指導開發人員。

一直是不少公司團隊比較困擾的問題，那麼最近筆者爲了解決這些問題，上了一些課程，

現將核心內容，總結以下，但願對你們有幫助，一塊兒探討~~

 

在項目開發過程當中，因爲歷史或者出於方便和規範的緣由項目經理通常仍是喜歡使用word文檔來描述需求。

舉個電商的例子，通常文檔結構會以下所示

-------------------------------------------------------------------------

• 前言
• 功能性需求
  • 　　商鋪管理場景
    • 　　建店申請
      • 提交申請
      • 查詢全部申請
      • 查看單個申請
      • 。。。。。。
    • 店鋪
      • 。。。。。。

------------------------------------------------------------------------

 

 1、如何將需求文檔的內容轉化成敏捷中的術語

上面這種格式文檔對於敏捷開發團隊來講多是比較生疏的，由於開發團隊通常常見的都是敏捷中的經常使用術語，如User Story， Task...

那麼需求改如何變成敏捷術語中的Business Epic，Feature，User Story和Task呢？

下面舉個栗子，需求如何對應到 SAFe（Scaled Agile Framework）框架 --常規的敏捷框架適用於中小型項目團隊，並且不具備擴展性。基於常規的敏捷框架，SAFe 定義了一個可擴展的敏捷框架模型，它適用於大型團隊的合做開發，能夠幫助提升團隊之間的協做性，下降團隊管理的複雜性。

對於SAFe想作更多瞭解請看官網 https://www.scaledagileframework.com/

或者 https://www.ibm.com/developerworks/cn/rational/1606_wanghy_saf/index.html

 

 

 

從上圖可知，拿到需求文檔，

第一步，咱們須要找到需求描述中的名詞，名詞通常是用來表述某項業務，全部將會對應到Business Epic或者是大的Feature。（描述偏業務性）

第二步，咱們須要找到名詞所對應的動詞，動詞主語是用戶或者是外部系統的通常能夠轉化成User Story，也就是用戶故事。（描述偏業務性）

第三步，仍是要找動詞，動詞主語是開發者的，通常會轉化爲Task，也就是具體工做。（描述偏技術性）

 

敏捷術語和代碼的對應關係

• Business Epic -->庫/包
• Feature -->類
• User Story -->方法

 

1、如何防止需求遺漏

 找到了全部的名字以後咱們能夠拿出每個Feature創建如下表來捕捉用戶故事。

第一行，參考上面第二步，列出全部的主語是用戶或外部系統的名詞

第一列，老是寫上CIDED（增查查改刪），第一個查爲查詢全部信息，理解爲列表，第二個查爲查詢單個詳細信息

而後在對應的格子中填寫是否有相應的動詞對個某個實體的某個特定的操做。

 

上面的列表可產生自粗略的需求說明，用來捕捉遺漏的需求，也可用來將需求用這個表來過渡，而後用As...I want...so that...格式描述成用戶故事。

 

用戶故事變成Task這個通常技術人員都會，這裏就再也不贅述。 

 

一些參考數據：

• 自動化測試用例/功能點 = 1.2
• 一天大概能編寫15~18個測試用例
• 名字平均6.5個動詞 （3~9個動詞）
• 一個名詞35個功能點
• 一個功能點約等於1人天
• 一個功能點價格約等於1k
• 調整因子1.3根號人天數

 

 

個人博客即將搬運同步至騰訊雲+社區，邀請你們一同入駐：https://cloud.tencent.com/developer/support-plan?invite_code=16mfkucn8havj