需求如何進行敏捷設計

　　敏捷開發其實不光光要求開發層面和測試層面的敏捷，其實對需求設計層面也是要敏捷的，這樣才能配合後續的開發和測試，使之真正的敏捷起來。

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

　　大多數情況下需求的處理過程都可以分為需求分析和需求設計兩部分，前者要將業務需求轉化成產品需求，後者要將產品需求轉化為產品設計，也即成品的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表就是一個對產品需求進行拆分的過程，拆分完成後再根據迭代計劃來設計具體的實現，前面所講的專案敏捷則是將所有需求都設計完成之後才進行拆分，這時主要就是為了把開發任務和測試任務拆分出來了。

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