敏捷需求之分層管理

傳統軟件開發（或者說瀑布式軟件開發）方法，對于需求的看法是 – 盡可能詳細的了解需求、分析需求以形成詳盡的需求文檔，然后就把文檔交付給開發部門。敏捷軟件開發中則是完全不一樣的做法。首先敏捷需求是ODDE的，其中有一個點很重要就是Detailed Rightly (Appropriated) – 詳略得當。

什么是詳略得當

介紹詳略得當之前，我們先看一張圖

在上圖的產品列表（Product Backlog）中，最左邊分為幾個部分：已完成，細粒度，粗粒度，下一版本。已完成無需介紹，下面分別介紹一下細粒度，粗粒度，下一版本。

細粒度

細粒度的意思是這些產品列表條目是相對比較明確的，詳細的。團隊對于這些條目的認知是達成一致的。經常有學員問我，那這些條目到底多大合適？這里有一個經驗值供參考（根據行業不同會有很大不同） – 一般來說，一個團隊在一個迭代內完成6-12個條目為宜。細粒度一般也意味著馬上要做的條目。

粗粒度

粗粒度指的是這些條目的細節還不清楚，團隊有可能沒有達成共識。粗粒度一般是接下來2-3個迭代要做的條目，并且會在產品列表梳理會上，對粗粒度的條目進行拆分、澄清，從而有可能變成細粒度的條目。

下一版本

有一些條目是近期不會考慮的，但從產品規劃上需要有考慮的。比如正在做一個安卓APP，從長遠來看是需要做iOS版本的，不過可能要3個月后才會考慮。這樣的條目就是下一版本的。

為什么詳略得當很重要

敏捷需求是有分層的，正如上一節討論的，分為：已完成，細粒度，粗粒度，下一版本。

如本文的題圖（感謝Alistair Cockburn博士），產品列表中的條目也是可以分為魚蝦級別（故事）、大海級別（Epic）和風箏級別（Theme）。

那么為什么詳略得當如此重要呢？

這是因為產品列表條目，我們（作為人類）不可能一次獲得所有信息。在產品開發的早期，獲得的信息尤其少，那這個時候做出的需求分析（或決策）怎么可能包含所有的條目呢？因此條目就不可避免的有大海和風箏，只有少量的魚蝦可以完成。隨著完成的魚蝦越來越多，我們獲得的信息也越來越多，對產品的認知也越來越清楚，從而能夠做出更加可信的決策。

寫在最后

本篇文章起源于“敏捷之旅北京眾籌群”中，和火星人陳勇之間的一次討論。我的觀點和陳勇老師略有不同。用戶故事，顧名思義，是從用戶的角度來講故事。那么它的核心是產品負責人和開發團隊之間都了解這個用戶故事是解決什么問題的。而不是一定要從Theme拆分成多少個Epic，從而再拆分成多少個Story這樣的一個過程。

敏捷開發

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。