說起來第一次聽到敏捷開發這個詞是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、考核、管理方法也要持續改進。
最后想說一句話：持續改進只有開始，沒有結束。
文章列表
留言列表
