引言：

我會以系列文章的形式跟蹤記錄我現在正在做的一個完整運用Scrum管理專案的筆記，裡面會有一些經驗教訓總結心得，以便讀者與我互相學習勉勵。有寫的不對的或者寫的不好的地方還請海涵，當然我更希望大家多多提寶貴意見，讀者的支持是我最大的動力。（之一，之二，之三，之四，之五，之六）

============================================================================================

專案在跌跌撞撞中終於塵埃落定，這個專案不大，計劃總人力34.2人月，實際人力投入大概28左右。由於是內部專案，並且也可以算是實施敏捷方法的試驗田，所以估算比較充足，不過不管是CPI還是SPI，從各方面的資料上來看這個專案還算是比較成功的。缺陷率比較低；專案執行順利人力節省；客戶滿意；基本上沒有加班；總之我對此專案還是非常滿意的，當然還要多謝專案中的每一位成員的努力，特別是TM（Technical Manager）的合作與支援。

最後跟大家一起再回顧一下我的整個專案：

整個專案過程有點像網上常說的Fall-Scrum-Fall的過程，先瀑布->然後敏捷->最後瀑布

1. 專案初期，出資人或者專案提出人預指派（還未授權）PM跟進客戶提出的一些想法，與客戶溝通，結合公司的現有能力或者技術，提出產品的一個願景，然後產生Feature List，以及系統的大致業務模型和構架。

2. 立案（PM真正授權），與客戶達成意願，把上面所說文件提交公司申請立案，這個時候需要做人力預估和時程的預估。當然這個是很粗的一個預估只是用來立案之用。

3. 市場分析與進一步計劃，此時TM會參與進來，與客戶一起討論更細一點的Feature，具體到模組與功能，PM和TM一起做出細部的人力預估，產生人力與時程的基線。

4. 預研、架構與實作，對於關鍵技術點我們首先需要去做風險評估，並且為了降低風險而做一些預研性的工作。設計系統骨架，並實作一兩個例子。因為我們運用的是敏捷，所以這裡不會做很細的設計，我們儘量先做出來後面不斷重構完善，但切記一定要不斷重構，不要積累設計問題，不然必成大禍。

5. 開始真正的敏捷，這個時候已經進入真正的實質性的開發工作，整個開發階段我們運用的是敏捷Scrum框架。

5.1. 我們的Product Backlog也就是我們上面講到的細化過後的Feature List。首先我們會做Release Plan，定義迭代週期。

5.2. 然後選取PB中的一些Feature到Sprint Backlog中，然後開計劃會議Sprint Planning Meeting。Scrum的幾個會議我在前面的文章中已經有講，這裡不再細說。

5.3. 然後產生任務牆看板。在迭代的執行期，會通過每日晨會，任務牆以及燃盡圖去跟蹤專案進度，控制偏差和風險。

5.4. Sprint結束後會有一個Demo Meeting，大家一起看一下這個迭代我們的成果如何，是否我們是Story可以交付。然後收集反饋問題記錄下來，作為下一個Sprint可能將要完成的任務。

5.5. 緊接著我們會開反思會，回顧一下上一個Sprint我們哪些做得好的，哪些做的不好，哪些本可以做的更好的？選取其中大家認為最重要的2-3條，拿出措施Action Plan，再下一個Sprint中去改進。（我覺得這一點我們做的非常好，個人認為這個會議也非常的重要，可以使我們一直都在持續改進）

然後周而復始一個接著一個的Sprint，直到開發結束。

6. 進入系統測試階段，專門的測試人員會對整個產品做測試與驗收工作。開發和測試一起合作完成。

7. 測試驗收完畢後，提交最終版本給使用者，使用者做UAT驗收工作。

8. 驗收通過，最後做結項工作。總結專案，收集整理文件等。

整個專案完結。

我簡單的把整個專案的過程按順序列舉了一番，沒有細說，如果有任何疑問都可以直接跟我留言，或者通過微博聯絡我，我一定會盡我所知，知無不言。呵呵

我的微博是：http://weibo.com/lackinpm