敏捷開發是快速反覆運算，快速交付的開發模式。這也就要求反覆運算週期內任務量不宜過大，以保證在預期內能够按時完成開發計畫。敏捷開發中怎樣保證開發任務的適宜呢？答案是任務分解。而任務分解的前提則是需求確認。
敏捷開發中的需求確認
我們都知道需求的來源通路很多（如用戶調查問卷，用戶訪談，客戶服務人員/商務人員的迴響，產品的技術交流群，用戶使用資料分析等，甚至還有一部分來源於產品經理對產品的定義，以及對科技的把握和對競品的分析），通常產品經理收集到的用戶故事需要經過分析篩選整理，形成最初的產品需求。此時的產品需求算是草稿狀態的產品需求。
產品經理通過發佈計畫會議對初步的產品需求進行講解傳達，由敏捷團隊討論細化，對其評估和排序之後形成需求條目，也就是可以排到敏捷開發計畫裡面去實現的需求清單。至此為需求確認的完成階段。
需要注意的是，在需求分解時需要面對的一個問題是需求的優先順序問題。先做哪個後做哪個？你可以參考下麵幾個標準。
1、價值，包括對產品自身的價值和對用戶的價值，價值越高優先順序越高。
2、必要性，先做必需的功能特性，然後再做其他高級特性。
3、緊迫性，時間要求越高的優先順序越高，特別是線上問題的解决。
除了優先順序問題，在敏捷開發中我們還需要面對需求變更問題。需求變更之所以可怕，主要是因為變更影響的範圍無法預估。在傳統專案管理中，由於沒有有力工具的支撐，產品經理在變更需求的時候，無法知曉該需求的影響範圍，也就很被動。
而如今的專案管理工具已經很好的解决了這個問題，像老資料網就是將需求、任務、bug和用例都納入為一體管理，就可以很清楚的知曉變更的影響範圍，從而給產品經理更好的指導。雖然敏捷開發最大的優勢是擁抱變化。但這並不意味著需求想變就變，產品經理還是要儘量控制變更情况的發生。
需求確認後就進入為需求分解任務階段。如何為需求分解任務呢？
敏捷開發的特性决定了反覆運算內任務量要適宜。任務量太大導致項目延期，任務量太小則工作量不飽和。所以需求的分解過程是一個對資源的評估再分配過程（這裡的資源一般是指團隊的開發能力，包括人員、任務量、工時等的合理統籌）。
需求分解在敏捷開發中一般通過反覆運算計畫會議實現。敏捷團隊對每一個需求進行分解，分解的標準是完成該需求（stroy）的所有任務，最終實現每個任務都有明確的負責人。敏捷開發中需求分解的目的在於將需求細化為可執行可評估的開發任務。
我們常用的管理軟體老資料網中這個過程就表現為“為需求分解任務”。研發團隊對需求進行詳細的評估和細分，生成完成這個反覆運算內的所有任務（這裡的所有任務，包括但不限於設計，開發，測試等），團隊成員領取任務，並進行工時的估計。
在具體操作上表現為通過創建任務，關聯相應的需求來實現。在老資料網的項目需求清單頁面，可以方便的對某一個需求進行任務分解，同時還可以查看這個需求已經分解的任務數，指派的成員等（動態演示位址：http://laoziliao.net/book/zentaopmshelp/130.html）。
分解任務的注意事項
1、需要將所有的任務都分解出來。這裡面包括設計，開發，測試，美工，甚至包括購買機器，部署測試環境等等。
2、任務分解的細微性越小越好，儘量控制在幾個小時就可以完成。
3、如果一個任務需要多個人負責，繼續考慮將其折開。
4、任務應做到相對獨立完整，某個任務的延期不至於影響到其他任務的進行。
5、多個子任務要進行排序，要區分輕重緩急。
6、任務的分配最好是自由領取，這樣可以大程度上調動大家的積極性。
說到底，任務分解是敏捷開發管理中不可或缺的基本流程，任務分解的作用就在於將需求轉變為可量化可執行的具體工作內容。同時敏捷團隊也可以做到心中有數，專案經理更好的掌握研發進度，隨時調整，以保證按時交付。囙此，任務分解的實現使得敏捷開發得以更好的實現。