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