實踐和理論需要同步，本文作者記錄了自己的敏捷開發流程，與大家分享。
需求的收集
首先對於不同的公司，大家對於需求的管理和搜集都是不一樣的，是什麼原因造成了這種百花齊放的原因，主要因為在需求收集和整理時會需要花費大量的時間和精力,來甄別。而對於處於不同規模、階段、行業的公司，它們所能耗費的成本（人力、時間、資源）都是不同的。自然大家對於如何搜集需求，如何整理需求，如何輸出需求都不相同。但最後都想達到需求明確的結果。
收集需求的方式有但是大致可分為幾類：
問卷調查——通過制定詳細周密的問卷，要求被調查者據此進行回答以收集資料的方法。用戶訪談——通過線上，線下的方式進行一對一單獨對話訪談。競品分析——通過觀察直接或間接競爭對手，得出自己或競品的優劣。內部搜集——通過個人（用戶模擬）或他人獲取「直接」需求。數據需求——通過當前數據的反饋來感知需求。第三方——通過第三方資訊/報告/白皮書/數據分析等手段了解當前需求。等等
需求整理
然而收集需求的方法處理這列舉出來的之外，還有更多的我們並不知道的方法。但是他們終究是為了達到「搜集需求」而已。在我們搜集了足夠的需求之後，就到了需要我們記錄下來的時候了，至於如何記錄，這裡和前面一樣。
對於需求記錄，每個人都有著自己常用的記錄方式，比如有喜歡用看板類teambition、trello、leangoo，等軟體的。而我這裡的話，我十分推崇使用Excel來記錄我的需求。
推崇使用Excle主要是原因有幾個原因有很多：
首先就是普及率高。在這個網際網路時代，只要不是太過於困難的偏遠地區，我們在讀書時都或多或少接觸過Office三件套。就算沒有接觸過，大家也可以在短時間能上手使用。其次就是裝配率高，除純淨版的系統，基本所有的系統都會攜帶office三件套，就算沒有攜帶，我們也可以輕而易舉的從網上下載來使用。其他的如功能強大之類話題我就不在過多闡述，因為在日常使用中我們也只用那固定的幾個小功能而已，並不需要過多的了解太多的「高級」技巧。創建功能需求表之前，我會先瀏覽用戶Story，做到場景還原化，之後再根據記錄的用戶Story來進行功能拆解。
首先說明，這種拆解不是盲目的拆解，是需要根據一定規則進行拆解的。不同的人或許有不同的拆解方式，而我遵循的是從上到下的拆解規則。
我將他們分為 系統，模塊，功能，內容，備註：
系統：明確story拆分出來的功能是屬於那個需求或者是那個端的。模塊：這裡期有兩種劃分思維：將有共通性的功能劃分到一起、將在同一頁面的功能劃分到一起。內容：輔助功能明確這個功能的邊界。備註：對於一些有歧義或需要特別說明功能進行補充說明。這樣拆分有助於我梳理整體架構。
在分解的過程中，我們還需要注意功能的準確性，因為這個功能始終是圍繞著用戶Story來的，是為了解決用戶故事中用戶的需求而存在的，不能讓功能偏離了用戶Story的出發點，偏離後會出現幾種情況，一個是偏離後做出來的功能牛頭不對馬嘴，無法滿足用戶。
另外一種是功能給用戶造成損失，最終都會造成用戶流失。所有在拆分完後，我們需要多次的複查這些功能，以保證這個功能點基本滿足用戶需求。
複查後就是我們的下一步操作分優先級（優先級我將放入原型後，禪道驅動中來講解），隨後就是原型繪製。
最後根據上面來進行操作，我們得到了功能需求表。但是得到了功能需求表，並不能代表我們的這個階段的工作完成了 ，我們可以直接推進到下個工作環節當中。
反而這個時候我們還需要反覆的拿著用戶Story與功能需求表進行對比，除了反覆對比之後，我們還需要拿著功能需求表和用戶Story，與需求者進行需求校對，校隊是否真正的滿足了用戶需求，在校對過程中我並不推薦將功能需求表直接交予對方進行直接進行校對，因為這種方式會適得其反，會直接出現對方看不懂，或者是看之後，他突然說我還有個IDEA。
所有我們需要使用交談的方式進行試探用戶。最後基本確定後，我們這個階段的工作就可以暫時告一段落，進入下個環節單中。
備註：當遇見一些功能複雜的業務或需求時（常見於0到1）我們可以適當的將模塊進行再次拆分，拆分成模塊，子模塊以便更好的進行維護功能需求表
Tips：在創建過程中明確了《範圍層》
本文由 @Wcof 原創發布於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。