敏捷開發管理--任務分解經驗之談

敏捷開發是快速迭代，快速交付的開發模式。這也就要求迭代週期內任務量不宜過大，以保證在預期內可以按時完成開發計劃。
敏捷開發中怎樣保證開發任務的適宜呢？答案是任務分解。 而任務分解的前提則是 需求確認。

敏捷開發中的需求確認

咱們都知道需求的來源渠道不少（如用戶調查問卷，用戶訪談，客戶服務人員/商務人員的反饋，產品的技術交流羣，用戶使用數據分析等，甚至還有一部分來源於產品經理對產品的定義，以及對技術的把握和對競品的分析），一般產品經理收集到的用戶故事須要通過分析篩選整理，造成最初的產品需求。此時的產品需求算是草稿狀態的產品需求。

產品經理經過發佈計劃會議對初步的產品需求進行講解傳達，由敏捷團隊討論細化，對其評估和排序以後造成需求條目，也就是能夠排到敏捷開發計劃裏面去實現的需求列表。至此爲需求確認的完成階段。

須要注意的是，在需求分解時須要面對的一個問題是 需求的優先級問題。先作哪一個後作哪一個？你能夠參考下面幾個標準。
一、 價值，包括對產品自身的價值和對用戶的價值，價值越高優先級越高。
二、 必要性，先作必需的功能特性，而後再作其餘高級特性。
三、 緊迫性，時間要求越高的優先級越高，特別是線上問題的解決。

除了優先級問題，在敏捷開發中咱們還須要面對 需求變動問題。需求變動之因此可怕，主要是由於變動影響的範圍沒法預估。在傳統項目管理中，因爲沒有有力工具的支撐，產品經理在變動需求的時候，沒法知曉該需求的影響範圍，也就很被動。

而現在的項目管理工具已經很好的解決了這個問題，像禪道就是將需求、任務、bug和用例都歸入爲一體管理，就能夠很清楚的知曉變動的影響範圍，從而給產品經理更好的指導。 雖然敏捷開發最大的優點是擁抱變化。但這並不意味着需求想變就變，產品經理仍是要儘可能控制變動狀況的發生。

需求確認後就進入爲需求分解任務階段。 如何爲需求分解任務呢？
敏捷開發的特性決定了迭代內任務量要適宜。任務量太大致使項目延期，任務量過小則工做量不飽和。因此需求的分解過程是一個對資源的評估再分配過程（這裏的資源通常是指團隊的開發能力，包括人員、任務量、工時等的合理統籌）。

需求分解在敏捷開發中通常經過迭代計劃會議實現。敏捷團隊對每個需求進行分解，分解的標準是完成該需求（stroy）的全部任務，最終實現每一個任務都有明確的負責人。敏捷開發中需求分解的目的在於將需求細化爲可執行可評估的開發任務。

咱們經常使用的管理軟件禪道中這個過程就表現爲「爲需求分解任務」。研發團隊對需求進行詳細的評估和細分，生成完成這個迭代內的全部任務（這裏的全部任務，包括但不限於設計，開發，測試等），團隊成員領取任務，並進行工時的估計。

在具體操做上表現爲經過建立任務，關聯相應的需求來實現。在禪道的項目需求列表頁面，能夠方便的對某一個需求進行任務分解，同時還能夠查看這個需求已經分解的任務數，指派的成員等（動態演示地址： http://www.zentao.net/book/zentaopmshelp/130.html）。

分解 任務 的注意事項
一、須要將全部的任務都分解出來。這裏麪包括設計，開發，測試，美工，甚至包括購買機器，部署測試環境等等。
二、任務分解的粒度越小越好，儘可能控制在幾個小時就能夠完成。
三、若是一個任務須要多我的負責，繼續考慮將其拆分。
四、任務應作到相對獨立完整，某個任務的延期不至於影響到其餘任務的進行。
五、多個子任務要進行排序，要區分輕重緩急。
六、任務的分配最好是自由領取，這樣能夠大程度上調動你們的積極性。

說到底，任務分解是敏捷開發管理中不可或缺的基本流程，任務分解的做用就在於將需求轉變爲可量化可執行的具體工做內容。同時敏捷團隊也能夠作到心中有數，項目經理更好的掌握研發進度，隨時調整，以保證按時交付。所以，任務分解的實現使得敏捷開發得以更好的實現。