關於逐步實踐敏捷開發的想法_敏捷開發

由於將會要組織一個全新的研發團隊，而且可能團隊中講會以年輕人為主，應屆畢業生尤其巨多。

 

我覺得這是一個嘗試全新的開發模式的好時機，但是當然需要平穩過渡。首先，我們都沒有敏捷開發的經驗，其次，敏捷開發所有的概念也未必完全適合團隊，需要動態來尋找結合點。

 

1. 簡單設計及重構

首先需要較為嚴格的確立工程的概念，我比較欣賞“簡單設計”這個原則，但是不完全贊同。

 

系統剛開始整個架構還是應該細緻設計，而之後每個模組的詳細設計應該是經常勇於重構，經常有新的想法。而重構的實現實踐也是要在不影響軟體交付的前提下進行。

 

歸根到底總結就是：有度的迭代。

 

2. 自動化測試

其次，自動化測試也是需要逐步普及的，特別是核心功能模組，但是關於如何構建可測試代碼，這是一門需要鑽的很深入的學問，我也將在之後的時間內親自先實踐這一點。我現在的疑惑主要是：

 

測試案例細到什麼層級，如果是功能性模組需要若干個模組整合或者資料庫特殊環境支援，是怎樣來編寫測試指令碼的。這樣指令碼編寫開銷是否特別大。

 

3. 持續整合

這個是基於自動化測試已經成熟的基礎上的，我想我現在對於這點暫時沒有發言權。當然，我也會要深入細心學習，不過我覺得在相當長的一個時間內，小的團隊、項目還是用不到做到持續整合的。

 

4. 代碼公有化

在敏捷開發中，這不是版本庫許可權這麼簡單，而是一個所有人都必須對整個工程每個模組熟悉，或者整個工程代碼風格和設計高度統一，我覺得在團隊成員都不是一等一的高手，並且項目代碼量較大的情況下，實施起來比較困難。

 

5. 結對程式設計

我一直認為，核心模組可以使用結對程式設計。前提是能夠很好的估計工作量，定時定性的指派任務。但是普通工作還是不要使用結對了。

 

6. 例會

重構經驗交流、敏捷開發體驗交流、自動化測試心得交流，需要在各個例會中脫離業務層，來深入商討我們的整個團隊研發模式。

 

7. QA團隊

那麼測試人員在研發期間的參與度就比較低了，QA人員只負責項目最後的功能驗收。一定要讓QA團隊和研發團隊和睦共處，不能有“敵對”的關係，這樣才不會出現BUG被踢皮球的現象。