本文作者@朱軍華Ronzhu 敏捷開發其實不光光要求開發層面和測試層面的敏捷，其實對需求設計層面也是要敏捷的，這樣才能配合后續的開發和測試，使之真正的敏捷起來。

我們可以通過在實際操作過程當中在需求層面進行敏捷設計的分析來了解需求的敏捷設計。

大多數情況下需求的處理過程都可以分為需求分析和需求設計兩部分，前者要將業務需求轉化成產品需求，后者要將產品需求轉化為產品設計，也即成品的PRD。

在做需求分析的時候，我們也是接到一部分需求之后，按鈕業務優先級來做分析，每次分析肯定是將相互關聯的需求放在一起分析，或者是先分析優先級較高的，后分析優先級較低，這個過程將分析的任務進行了劃分。

因此其也較為接近于敏捷的模式，這里撇開不談，主要講需求設計部分如何與后面的開發、測試結合起來。

在真正開始談敏捷設計之前，我覺得有必要思考一下是否所有的需求都適合用敏捷設計？ 為什么有這樣的疑問，在于敏捷開發其實是較為靈活的，并不是一味的為了敏捷而敏捷，其也可以分成產品敏捷和項目敏捷兩種方式。

在我的理解里面，產品敏捷是真正的將敏捷設計、敏捷開發、敏捷測試結合在一起的，從產品的層面講所有的任務都用敏捷的方式進行管理；而項目敏捷則采用的是需求設計走的是瀑布的模式，開發和測試才是敏捷的，因此兩者之間還是有點差異。

有的需求不適合用敏捷的方式的來設計

 

敏捷的模式總的來講就是將整體拆為多個個體，然后再單獨的完成各個個體以達到這些個體合成之后就是整體的效果，所以這里就有一個問題存在，產品的整體需求是否適合拆分？個人在操作經驗中總結如下：

• 各功能之間較為獨立的適合敏捷。一個產品有十個功能點，各個功能點之間相互依賴關系不強的，松耦合，就可以每個功能點單獨抽取出來做設計。
• 功能本身的邏輯遵循某種操作流程的適合敏捷。功能的實現是按照一個較為固定的流程一步一步往下走的，這樣可以將每一個步驟單獨拆分開。
• 產品上線之后的版本維護適合敏捷。上線之后，對一些BUG、問題、小需求的縫縫補補，都適合用敏捷的方式來設計。
• 上線后的新增需求適合敏捷。上線的的新增需求一般都針對某個功能模塊來進行設計，相對來說較為獨立，因此也適合敏捷設計。

反之，如果不能滿足以上幾個條件的，特別是耦合度較高的需求，個人建議還是走瀑布的模式，把整體的需求都梳理清楚之后做整體的需求設計，這樣可以避免后面的設計過程要改動前面的設計結果的問題，減少一部分的需求變更.

敏捷雖然說很大的一個優勢就在于可以較好的適應需求變化，但這個需求變化是指來自于業務層面的，而不是來自于產品設計人員或者產品經理自身的工作方式所導致產生的。

當然肯定也有人是全部都走敏捷的，這樣的話對其產品規劃能力要求較高，整體思維邏輯要很清晰，才能避免出錯，這里只是個人建議，僅供參考。

敏捷設計的產出如何維護

 

平常我們稱一個功能點為一個CASE或者是一個Story，而在敏捷里面稱之為backlog產品條目，其實只是換了個名稱而已，實質沒有變。

之前我也說過在學習他人長處的時候，重要的是理解和變通，而不是照抄。 產品backlog是敏捷的核心，也是整個產品敏捷過程的起源。從根本上說，它就是一個需求、或故事、或特性等組成的列表，按照重要性的級別進行了排序。

它里面包含的是用戶或者業務方想要的東西，并用用戶或者業務方可以理解的術語加以描述。通常有如下幾個部分：

序號ID

統一標識符，就是個自增長的數字而已，用以唯一標示每個backlog，主要用來做標示用，以及在PRD當中標注每個backlog所對應的需求設計描述；

名稱Name

簡短的、描述性的backlog標題，比如“查看你自己的交易明細”。它必須要含義明確，這樣開發人員、測試人員才能大致明白我們說的是什么東西，其實也方便產品經理自身做checklist檢查，可以跟其他backlog區分開。 它一般由2到10個字組成；拆分backlog是有要求的，一般要求每條backlog都能在規定的單個迭代周期里面完成；

重要性Importance

產品經理評出一個數值，指示這個backlog有多重要，一般為1到10之間的整數值，分數越高越重要。 其實就是優先級，只不過有的人所理解的優先級是1最優先，所以這里用重要性來表述。優先級的評定主要參考兩個維度，一是業務價值，二是緊迫性，其他的都可以暫不考慮；

工作量估算Initial estimate

團隊的初步工作量估算，表示完成該backlog所需的工作量，最小的單位是0.5人/天。為盡量提高估算的準確性，目前個人采用的是整個團隊每人都寫一個估算工作量，去掉一個最高的，去掉一個最低的，剩下做平均，呵呵。 然后再安排各自講解一下為什么，最終要在團隊內部達成一致；

演示How to demo

大略描述了這個backlog應該如何進行示范，本質就是一個簡單的測試規范。一般為“先這樣做，然后那樣做，就應該得到……的結果”，敏捷對每個backlog的要求就是可演示可單獨上線的；

備注Notes

相關信息、解釋說明和對其它資料的引用等等，一般都非常簡短； 通常都把backlog存放在共享的Excel文檔里面，以便團隊成員都可以隨時查看編輯。一般來說這個文檔歸產品經理維護，但也并不把其他團隊成員排斥在外。開發人員和測試人員常常要打開這個文檔，弄清一些事情，或者修改估算值。

這里又會產生一個問題，那就是如何讓產品backlog停留在業務層面上？

舉例來說，如果產品經理有技術相關的背景，那他就可能添加這樣一個backlog：“給Events表添加索引”。真正目的也許是“要提高在后臺系統中搜索事件表單的響應速度”。到后面可能會發現索引并不是帶來表單速度變慢的瓶頸，也許原因與索引完全不相干。

所以指出如何解決問題的應該是開發團隊，產品經理只需要關注業務目標即可。這種面向技術的backlog，可以一直問下去“為什么”，直到發現內在的目的為止.

然后再用真正的目的來改寫這個backlog（“提高在后臺系統中搜索并生成表單的響應速度”）。最開始的技術描述只會作為一個注解存在（“為事件表添加索引可能會解決這個問題”）。

維護backlog表就是一個對產品需求進行拆分的過程，拆分完成后再根據迭代計劃來設計具體的實現，前面所講的項目敏捷則是將所有需求都設計完成之后才進行拆分，這時主要就是為了把開發任務和測試任務拆分出來了。

相對來說，敏捷還是一種較為新穎的模式，目前在互聯網行業用的較多，每個公司在用的時候實際情況可能都不大一樣，其實沒有關系的，適合自己的就是最好的，只要能提高產品迭代發布的效率，就可以了，先用起來，然后在用的過程當中慢慢優化，發揮敏捷的最大的效用。

作者博客：IT民工