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

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

一直是很多公司團隊比較困擾的問題，那么最近筆者為了解決這些問題，上了一些課程，

現將核心內容，總結如下，希望對大家有幫助，一起探討~~

 

在項目開發過程中，由於歷史或者出於方便和規范的原因項目經理一般還是喜歡使用word文檔來描述需求。

舉個電商的例子，一般文檔結構會如下所示

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

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

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

 

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

上面這種格式文檔對於敏捷開發團隊來說可能是比較生疏的，因為開發團隊一般常見的都是敏捷中的常用術語，如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 -->方法

 

一、如何防止需求遺漏

 找到了所有的名字之后我們可以拿出每一個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