敏捷開發管理--需求分解經驗之談
敏捷開發是快速叠代，快速交付的開發模式。這也就要求叠代周期內任務量不宜過大，以保證在預期內能夠按時完成開發計劃。
敏捷開發中怎樣保證開發任務的適宜呢？答案是任務分解。
而任務分解的前提則是
需求確認。
敏捷开发中的需求確認
我们都知道需求的来源渠道很多（如用户调查问卷，用户访谈，客户服务人员/商务人员的反馈，産品的技术交流群，用户使用数据分析等，甚至还有一部分来源于産品经理对産品的定义，以及对技术的把握和对竞品的分析），通常産品经理收集到的用户故事需要经过分析筛选整理，形成最初的産品需求。此时的産品需求算是草稿状态的産品需求。
産品经理通过发布计划会议对初步的産品需求进行讲解传达，由敏捷团队讨论细化，对其评估和排序之后形成需求条目，也就是可以排到敏捷开发计划里面去实现的需求列表。至此为需求確認的完成阶段。
需要注意的是，在需求分解時需要面對的一個問題是
需求的優先級問題。先做哪個後做哪個？你可以參考下面幾個標准。
1、
價值，包括对産品自身的價值和对用户的價值，價值越高优先级越高。
2、
必要性，先做必需的功能特性，然後再做其他高級特性。
3、
緊迫性，時間要求越高的優先級越高，特別是線上問題的解決。
除了優先級問題，在敏捷開發中我們還需要面對
需求變更問題。需求变更之所以可怕，主要是因为变更影响的范围无法预估。在传统項目管理中，由于没有有力工具的支撑，産品经理在变更需求的时候，无法知晓该需求的影响范围，也就很被动。
而如今的項目管理工具已经很好的解决了这个问题，像禅道就是将需求、任務、bug和用例都纳入为一体管理，就可以很清楚的知晓变更的影响范围，从而给産品经理更好的指导。
虽然敏捷开发最大的优势是拥抱变化。但这并不意味着需求想变就变，産品经理还是要尽量控制变更情况的发生。
需求確認后就进入为需求分解任務阶段。
如何爲需求分解任務呢？
敏捷開發的特性決定了叠代內任務量要適宜。任務量太大導致項目延期，任務量太小則工作量不飽和。所以需求的分解過程是一個對資源的評估再分配過程（這裏的資源一般是指團隊的開發能力，包括人員、任務量、工時等的合理統籌）。
需求分解在敏捷開發中一般通過叠代計劃會議實現。敏捷團隊對每一個需求進行分解，分解的標准是完成該需求（stroy）的所有任務，最終實現每個任務都有明確的負責人。敏捷開發中需求分解的目的在于將需求細化爲可執行可評估的開發任務。
我們常用的管理軟件禅道中這個過程就表現爲“爲需求分解任務”。研發團隊對需求進行詳細的評估和細分，生成完成這個叠代內的所有任務（這裏的所有任務，包括但不限于設計，開發，測試等），團隊成員領取任務，並進行工時的估計。
在具体操作上表现为通过创建任務，关联相应的需求来实现。在禅道的项目需求列表页面，可以方便的对某一个需求进行任務分解，同时还可以查看这个需求已经分解的任務数，指派的成员等（動態演示地址：
http://www.zentao.net/book/zentaopmshelp/130.html）。
分解
任務
的注意事項
1、需要将所有的任務都分解出来。这里面包括设计，开发，测试，美工，甚至包括购买机器，部署测试环境等等。
2、任務分解的粒度越小越好，尽量控制在几个小时就可以完成。
3、如果一个任務需要多个人负责，继续考虑将其拆分。
4、任務应做到相对独立完整，某个任務的延期不至于影响到其他任務的进行。
5、多个子任務要进行排序，要区分轻重缓急。
6、任務的分配最好是自由领取，这样可以大程度上调动大家的积极性。
说到底，任務分解是敏捷开发管理中不可或缺的基本流程，任務分解的作用就在于将需求转变为可量化可执行的具体工作内容。同时敏捷团队也可以做到心中有数，项目经理更好的掌握研发进度，随时调整，以保证按时交付。因此，任務分解的实现使得敏捷开发得以更好的实现。
