一、寫在前面

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

（圖1 基本開發(fā)流程圖）

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

缺點：

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

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

3）缺少團隊合作。每個開發(fā)人員各自為戰(zhàn)，欠缺開發(fā)人員之間的溝通。

二、體驗Scrum

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

1） 第一輪迭代

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

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

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

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

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

處理辦法：

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

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

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

2） 第二輪迭代

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

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

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

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

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

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

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

3）第三輪迭代

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

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

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

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

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

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

三、總結

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

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

【編輯推薦】