一、寫在前面

敏捷項目管理實施前，一直在倡導做項目、需求要敏捷，在保證質量的同時盡可能的快速完成開發任務，但很少有真正實踐的機會。之前的需求開發流程基本如圖1所示。

（圖1 基本開發流程圖）

該流程最大優點是需求能快速上線。需求方提出的需求，基本都希望能盡快上線。各開發針對自己開發的需求，在需求方要求的時間內完成對需求的開發，發布上線。

缺點：

1）不利于產品發展。開發人員滿足于開發眼前需求，缺少對產品的整體認識，對產品發展的貢獻不足；

2）不利于開發人員的成長。需求一個接一個的開發，純粹為開發需求，缺少沉淀和總結，開發人員很累；

3）缺少團隊合作。每個開發人員各自為戰，欠缺開發人員之間的溝通。

二、體驗Scrum

基于以上需求開發流程，我們嘗試改變原有的方式，擬采用兩周一迭代的敏捷開發模式。

1） 第一輪迭代

由于先前對于敏捷開發的認識并不是很足，于是乎第一次的迭代基本可用“摸著石頭過河”來形容。整體周期如圖2所示：

（圖2 第一輪迭代周期圖）

該迭代以2周為一個周期，整體開發周期為6天，2天為集成測試時間，PM資源權重為0.5。回顧這一次迭代，整個過程還是比較順利，主要遇到以下幾個問題：

1）緊急需求的插入（新增3個需求，約4人/日的工作量）；

2）對于一句話的需求，工作量評估不足（如，“XXX頁面增加XX功能”需求。評估1.5人/日，實際需要3人/日。）

處理辦法：

1） PM壓縮部分時間投入于緊急需求的開發；分配部分任務給項目成員（其他任務完成較快的開發）；

2） 開發晚上加班處理對于工作量評估不足的需求；項目組成員共同協調處理。

總得來看，采用敏捷開發與之前的變化：1）每天晨會，開發間的溝通多了；2）開發對于整體需求認識度提升；3）項目成員開始相互協作，共同解決問題；4）緊急需求能快速響應，項目組內部消化。

2） 第二輪迭代

    針對第一輪遇到的不足點（需求評估不足）以及項目開發周期的試用總結，對于第二輪迭代做了相應調整。如圖3所示：

（圖3 第二輪迭代周期圖）

紅色部分為變化的點。其中在迭代任務分配完，進行了整體需求的評審；開發周期從6天調整為7天；集成測試2天調整為1天；PM資源權重從0.5調整為0.7；項目完成后，增加了項目總結環節。

回顧該迭代，主要遇到的問題有以下幾點：

1）緊急需求的插入；2）需求評審較晚，影響開發人員的開發時間；3）前端開發工作量評估不足；

針對以上問題的解決辦法：

1） 周末PM加班處理緊急需求；2）相應開發加班趕進度；3）項目總結。

3）第三輪迭代

針對第二輪迭代遇到的主要問題（需求評審太遲，影響工作量評估，影響開發時間），將需求評審的時間再往前移。如圖4所示：

（圖4 第三輪迭代周期圖）

第三輪迭代目前正在進行，已經感知到的問題有以下兩個：1）需求評審還是太遲，影響工作量評估及部分開發工作；2）整個周期缺少設計環節，缺少對于技術的沉淀。

    針對以上兩個問題，擬對迭代再次調整。如圖5所示：

（圖5 擬第四輪迭代周期圖）

    將需求評審再次提前。需求評審完后，指定相應開發跟進需求，進行相關的設計工作，擬減輕迭代中的開發任務。

三、總結

    以上迭代流程并不是最優，還在不斷地實踐中優化。總體感覺，敏捷開發是不斷自我進化的一個過程。通過不斷地實踐，在實踐過程中進行不斷地總結，不斷完善和優化，使項目朝著健康、有序、向上的方向發展。

原文鏈接：http://www.cnblogs.com/xjk15082/archive/2012/09/25/2702165.html

【編輯推薦】