一年之前我們公司的項目一般都是一兩個人來完成的.完成的質量總是不太理想,很多時候完成後才現發有這樣那樣的問題.嚴重影響項目的進度和部門形象.新的方法實行了差不多一年了,效果非常理想.
大概說一說我們之前的開發流程,首先會有其他的部門負責人找到我或者我的上頭阿生,我們兩個會根據用戶的需求寫一份詳細的說明文檔,然後根據需求文檔設計數據庫.完成這兩件工作後會把需求文檔給我們的同事,然後兩三個人簡單討論一下就開始真正的編碼工作了.
其實很多時候編碼的同事的理解可能跟你的想法有出入,同一份文檔可能會有兩種不同的理解.最後出來的效果,那真是哭笑不得啊!
一年前我們發現這個問題越來越來嚴重了,於是我們引入了敏捷開發,項目團隊人員由一兩個人一組變成五六個人一組.
在項目的最初階段,跟用戶討論問題的時候就會把相關的同事一起叫過來聽(注意,這個階段主要以聽爲主),瞭解完需求後,我們內部組別再一起討論確定最終的需求文檔(這樣做的好處是在這個階段用戶的需求,參加開發的同事也已經非常清楚了,不需要項目負責人再講解一次.).
然後我們會進入系統分析階段,這時界面設計人員也會加入,這一個階段我們會把用戶需要的數據,採用的什麼技術,頁面的大概框架都會進行詳細的討論.團隊的人員在這一個階段會非常活躍,這一階段要花費大量的時間討論,有時候一次不夠,需要第二次,第三次,第N次再開會討論,直到團隊的所有同事都非常清楚爲止.(關鍵部分)
討論完成後,會將項目分成很多個非常小的階段,每個小階段有一些功能組合列表,我們團隊使用的是自己認領的方式,讓團隊的成員自由選擇自己有興趣的功能組合並寫上大概的完成日期.最後定下一次的會議的時間,一般是每一個小階段結束的時間(當然並不是每個小階段都必須開會).每次會議的間隔時間不定,一般爲1-3天.
訪方法實行半年多以來,效果非常理想!由於參與人數增多,每個人員開發的代碼都要互相調用,代碼的規範,可複用性,效率都得到了很大的提升.由於採用認領的方式,積極性和責任心都大大提高(因爲你的功能沒有完成會影響到整個項目的進度,你的功能做得不好也會影響整個項目,程序員都是這樣,壓力越大,做出來的東西也越好).
各位大蝦對此有什麼看法,或者還可以改進的地方,歡迎留言我!