敏捷開發是快速迭代，快速交付的開發模式。這也就要求迭代週期內任務量不宜過大，以保證在預期內能夠按時完成開發計畫。
敏捷開發中怎樣保證開發任務的適宜呢？答案是任務分解。而任務分解的前提則是需求確認。
敏捷開發中的需求確認
我們都知道需求的**渠道很多（如使用者調查問卷，使用者訪談，客戶服務人員/商務人員的反饋，產品的技術***，使用者使用資料分析等，甚至還有一部分**於產品經理對產品的定義，以及對技術的把握和對競品的分析），通常產品經理收集到的使用者故事需要經過分析篩選整理，形成最初的產品需求。此時的產品需求算是草稿狀態的產品需求。
產品經理通過發布計畫會議對初步的產品需求進行講解傳達，由敏捷團隊討論細化，對其評估和排序之後形成需求條目，也就是可以排到敏捷開發計畫裡面去實現的需求列表。至此為需求確認的完成階段。
需要注意的是，在需求分解時需要面對的乙個問題是需求的優先順序問題。先做哪個後做哪個？你可以參考下面幾個標準。
1、價值，包括對產品自身的價值和對使用者的價值，價值越高優先順序越高。
2、必要性，先做必需的功能特性，然後再做其他高階特性。
3、緊迫性，時間要求越高的優先順序越高，特別是線上問題的解決。
除了優先順序問題，在敏捷開發中我們還需要面對需求變更問題。需求變更之所以可怕，主要是因為變更影響的範圍無法預估。在傳統專案管理中，由於沒有有力工具的支撐，產品經理在變更需求的時候，無法知曉該需求的影響範圍，也就很被動。
而如今的專案管理工具已經很好的解決了這個問題，像禪道就是將需求、任務、bug和用例都納入為一體管理，就可以很清楚的知曉變更的影響範圍，從而給產品經理更好的指導。
雖然敏捷開發最大的優勢是擁抱變化。但這並不意味著需求想變就變，產品經理還是要盡量控制變更情況的發生。
需求確認後就進入為需求分解任務階段。
如何為需求分解任務呢？
分解任務的注意事項
1、需要將所有的任務都分解出來。這裡面包括設計，開發，測試，美工，甚至包括購買機器，部署測試環境等等。
2、任務分解的粒度越小越好，盡量控制在幾個小時就可以完成。
3、如果乙個任務需要多個人負責，繼續考慮將其拆分。
4、任務應做到相對獨立完整，某個任務的延期不至於影響到其他任務的進行。
5、多個子任務要進行排序，要區分輕重緩急。
6、任務的分配最好是自由領取，這樣可以大程度上調動大家的積極性。
說到底，任務分解是敏捷開發管理中不可或缺的基本流程，任務分解的作用就在於將需求轉變為可量化可執行的具體工作內容。同時敏捷團隊也可以做到心中有數，專案經理更好的掌握研發進度，隨時調整，以保證按時交付。因此，任務分解的實現使得敏捷開發得以更好的實現。
LINUX下的開發經驗之談
我就是做linux下的c開發的。準確的說，linux下c才是主要的開發語言，但是寫應用程式還是要用物件導向的，尤其是圖形介面的，不如qt和x和gtk等等。下面說的必須要求你c語言學的很好而且會使用linux的情況下。linux常用命令要熟悉。要學linux下的c程式設計，先看一兩本linux下c的書...
我的O R Mapping實際開發經驗之談
一 概述 就是物件關係對映。把對錶直接進行的操作，變成對持久化類的屬性和方法的直接操作。很多的專案是基於資料庫的開發，程式中要大量進行表的增 刪 改 查詢的工作。例如下面一段c 從資料庫customerdemo取表customer資料 string connectionstring data sou...
學歷教務系統專案管理經驗之談
從事遠端學歷教育的教學教務管理平台的開發 管理多年，一直想把遇到的挫折和感悟和同行分享，於是集中幾天時間整理出這篇文章，希望能對在這一行業奮鬥的兄弟姐妹有所啟發。文章中的一些觀點也許有所偏激，但卻是我的心聲，歡迎批評指正。由於整個教學教務平台內容十分龐雜，本文涉及到的內容主要是教務管理方面。在國內學...