說起來第一次聽到敏捷開發這個詞是2004年與之一起的是XP程式設計，當時剛剛加入挨踢大軍還沒多長時間，和很多程式設計師一樣對於專案管理、專案文件持極端反感的態度。曾經老闆嘗試使用IBM的靜室軟體工程來實施ERP軟體開發，帶來的結果是一個專案組在公司辦公室討論一個月了專案文件還沒有弄清楚，幾乎脫離了實際情況。最後還是憑藉個人能力完成這一曠日持久的ERP專案。

目前我所在的團隊是2012年組建的，一年多以來基本還是按照以前的工作模式進行工作，隨著業務量的增加逐漸發現專案越來越不可控，專案的進展完全看個人能力，而我一個人的力量畢竟是有限的，慢慢的開始認識到必須得好好管理管理專案了。

開始的時候只是想能有一個工具能夠把任務分解，讓每個成員清楚自己的任務，於是先用上了TFS。

TFS裡面建團隊專案的時候會給兩個預設模板：CMMI和敏捷，我們只是一個小團隊CMMI這樣的巨無霸讓我有點恐懼，於是選擇了適合小團隊的敏捷，當時對敏捷開發的認識只停留在敏捷這兩個字上，當TFS用上了之後我們團隊開始探索這個巨無霸（為什麼說TFS是巨無霸，安裝過的人一定知道）。

=======專案管理的力量======

我們的團隊分成了兩個組，分別開發兩個專案，我們先在小一點的組中試用TFS，之所以選中這個組，一是因為人員少只有兩個人，好管理，二是因為這個組的主力成員有過日企開發經驗，專案管理上的理解更好，工作積極主動。

我們的探索從開發任務的管理開始，開專案會先召整合員討論下一階段做什麼事情，然後把任務逐一分解，並增加到TFS中，這時對於TFS中的使用者情況還不理解，我們只是用了任務和BUG，任務或BUG完成後把任務關閉掉，這個時候可以說TFS只是起到了任務管理的作用。

在平常的工作中大家把客戶反饋過來的問題或自己發現的問題也記錄為BUG增加到TFS中，有了新的需求也會及時記錄到TFS中。

與此同時做為部門負責人一直在研究TFS的功能，看能給我們帶來什麼樣的管理方式，這時發現了燃燒圖，也大概明白了使用者情景可以理解為使用者需求/功能點，其中可以統計出來一些任務進展情況、開發人員的工作效率等資料。

經過近兩個星期的探索，這個小組的工作有了明顯的提升，該做哪些事情很清楚了，這期間給一個新客戶部署了一套系統，我們也開會總結出了一套系統部署的標準工作流程，並反推出部署一套系統所需要的時間/人力成本。合作伙伴、公司老闆、團隊成員對這個組的變化都看在眼裡喜在心上。

用一句話總結一下這個階段就是：管和不管有很大區別，這時我才意識到小團隊也是可以有高效管理的。

這一時期我們解決了以下幾個問題：

1、每個人對自己要做的工作不清晰，只知道有很多事要做，但是具體有哪些，需要多長時間，沒數。

2、把每個人的工作像玩遊戲一樣做為任務清單，讓有強迫症的程式設計師效率提升不少。

3、形成了一部分標準工作流程。

當然也發現了新的急需解決的問題：

1、任務每週都會有增加，有時候程式設計師只看到任務數量在增加，看不到減少，漸漸失去動力，沒有里程碑，看不到出頭之日。

2、遊戲裡完成了任務有任務獎勵，可是個這沒有任務獎勵，對無強迫症患者的程式設計師效果不明顯。

3、無法通過TFS準確的看到進度，原因不明。

方法總結：改變從小處開始。共黨一直都喜歡搞試點不是沒有道理的，這一階段的改變從一個小組開始，見到了效果，很容易大家都接受了，另外一個組幾乎沒有障礙的用上了TFS，也見到了點效果。

=========開始認識敏捷=========

到了這個時候可以說遇到了一個小瓶頸，幸運的是我們看到了專案管理給我們帶來的好處，值得繼續探索。

更加幸運的是老闆帶領我們團隊的兩個成員奔波千里到了大連參加軟交會，我帶著我的問題來到美麗的大連探索我們的專案管理之路，目標鎖定專案管理論壇！

其實上一年也參加了軟交會，專案管理論壇也參加了，但是並沒有什麼深刻的體會，這一次我們帶著問題來了：什麼是敏捷？為什麼被挨踢大軍如果推崇？

在此之前我們還搞不清楚迭代/使用者情景/任務之間的關係，通過一天的論壇學習對敏捷開發惡補了一下，這一天最深刻的收穫就是四個字：持續改進！

相比之下敏捷的四句話宣言對我的印象前不深刻，或者說在我看來敏捷真正的精髓並不是敏捷宣言，而是"持續改進”這個四字，從這時開始，持續改進成為了我們每一次部門會議上必須探討的話題。

當然也明白瞭如何做迭代、如何做使用者情景、任務。帶著我收穫我回到了團隊，並分享給了大家，同時開始了我們的持續改進之路！

首先要做的就是洗腦。

個體和互動 高於 流程和工具
工作的軟體 高於 詳盡的文件
客戶合作 高於 合同談判
響應變化 高於 遵循計劃

對於這四句話中的前三句話基本每一個程式設計師都可以認同。

但是第四句話就有點難了，一直以來為了避免使用者需求變化，我們總是儘可以的把需求調查清楚，功能儘可能設計的完美，考慮周全。但事實情況是設計的再完美，到實際使用的時候各種問題都會出來，甚至會完全推翻。

其實對於團隊來說需要洗腦的並不是團隊成員，而是團隊的領導和客戶。程式設計師們大多數會跟著領導走，領導怎麼說我們就怎麼做，除非在團隊中有可以挑戰領導的人存在，幸運的是我的團隊暫時沒有這樣的人。對於程式設計師們其實只要大家看到了變化，看到了好處，自然會接受這一思想，所以洗腦工作並沒有下多大的力氣，只是和客戶深談了一次，客戶基本接受了我的想法，到目前為止還比較配合。

其次，把敏捷開發的方法嘗試應用在我們的團隊中。

我們做了下面的工作：

1、向大家講解迭代/使用者情景/任務/BUG之間的關係，以及在TFS中如何使用，以及分解使用者需求和任務的原則。

2、把當時剩餘的工作梳理了一便，按著緊急/重要分類，挑出一部分任務放在以後再解決，確定了2周左右的迭代。

3、把任務分解到6個小時之內。之所以選擇6個小時，是希望每一個成員每天至少能夠完成一個任務，之所以不是8個小時，是留2個小時讓程式設計師們處理其它的雜事，並且要求大家每天至少完成6個小時的任務。

4、佈置站立會議，每天向團隊成員通報當天任務情況，站立會議原則：

　　總時間不超過15分鐘

　　每個人只講三件事：昨天做了什麼/今天要完成什麼/是否需要幫助

5、這些依然還是在小團隊中試點。

6、貫徹持續改進的思想。

7、佈置了看板，把大家的任務貼在看板上，每日更新。

經過一段時間的嘗試，這個小組的迭代提前完成，讓我們看到了希望，同時TFS中的報表清晰了，能夠相對準確的看到任務進展。

於是另外兩個組（又增加了一個兩個小組，開始另外一個專案的開發）也開始了敏捷之路，其中一個組效果明顯，提前1天完成，另一個人最多的組晚了三天完成迭代。

同時又發現了很多新的問題，其中有一些是我在下一階段想要重點解決的：

1、很多程式設計師並沒有及時在TFS中更新任務完成情況，一直到了迭代最後才一起更新，甚至很多程式設計師平常都不看TFS。

2、任務評估不準確，導致部分任務嚴重超時。

3、責任不明確，一個功能模組的程式碼好幾個人改過，出了問題找BUG非常困難。

4、TFS的很多功能還是搞不清楚，使用起來也有點麻煩，進度不直觀。

不管怎麼樣這個月三個組的迭代都完成了，我們團隊還是取得了不小的勝利，大家心情都挺不錯。於是在人事的提醒下，向老闆申請了一筆活動經費，帶著大家去腐敗。

腐敗之後繼續改進。

========開始持續改進==========

 此時正好到了月底，我們又有些的改進措施：

1、考慮到程式設計師們對任務的敏感度降低，在下一個月的月度考核中加入了任務考核：

任務目標分為及格目標和卓越目標，並把目標達成作為月度考核中重要的佔比（60%），並且完成卓越目標還有加分，鼓勵大家向卓越前進。

2、鑑於TFS使用的效果不理想，我們安裝了SCRUMWORKS，在使用TFS效果不好的小組中推行，經過兩個星期的使用，效果比用TFS有好轉，在使用SCRUMWORKS之後這個小組的下一個迭代按時完成，雖然還有一些問題，比上一次迭代已經好了很多，最值得欣慰的是團隊成員在我沒有出面的一次站立會議中自行討論如何按時完成迭代，這個小組具有了一點自我修復能力。

3、在這個月的月度例會中開始嘗試明確職責，明確了SCRUM框架中的幾種角色：Product Owner/Scrum Master/Scrum Team

隨著一點點措施的開展，對於敏捷我也有了一點自己的認識：

1、敏捷開發的核心是持續改進，這一思想應該不僅僅適用於軟體專案管理，對於任何管理同樣適用。

2、任何工具、管理方法包括SCRUM、XP、宣言、敏捷十二條原則都是工具，適用就用，不適用就改。

3、敏捷開發與考核必須掛鉤，沒有誘惑任何好的方法慢慢都會褪色。

4、考核、管理方法也要持續改進。

最後想說一句話：持續改進只有開始，沒有結束。