由於將會要組織乙個全新的研發團隊，而且可能團隊中講會以年輕人為主，應屆畢業生尤其巨多。
我覺得這是乙個嘗試全新的開發模式的好時機，但是當然需要平穩過渡。首先，我們都沒有敏捷開發的經驗，其次，敏捷開發所有的概念也未必完全適合團隊，需要動態的來尋找結合點。
1. 簡單設計及重構
首先需要較為嚴格的確立工程的概念，我比較欣賞「簡單設計」這個原則，但是不完全贊同。
系統剛開始整個架構還是應該細緻設計，而之後每個模組的詳細設計應該是經常勇於重構，經常有新的想法。而重構的實現實踐也是要在不影響軟體交付的前提下進行。
歸根到底總結就是：有度的迭代。
2. 自動化測試
其次，自動化測試也是需要逐步普及的，特別是核心功能模組，但是關於如何構建可測試**，這是一門需要鑽的很深入的學問，我也將在之後的時間內親自先實踐這一點。我現在的疑惑主要是：
測試用例細到什麼級別，如果是功能性模組需要若干個模組整合或者資料庫特殊環境支援，是怎樣來編寫測試指令碼的？這樣指令碼編寫開銷是否特別大？
3. 持續整合
這個是基於自動化測試已經成熟的基礎上的，我想我現在對於這點暫時沒有發言權。當然，我也會要深入細心學習，不過我覺得在相當長的乙個時間內，小的團隊、專案還是用不到做到持續整合的。
4. **公有化
在敏捷開發中，這不是版本庫許可權這麼簡單，而是乙個所有人都必須對整個工程每個模組熟悉，或者整個工程**風格和設計高度統一，我覺得在團隊成員都不是一等一的高手，並且專案**量較大的情況下，實施起來比較困難。
5. 結對程式設計
我一直認為，核心模組可以使用結對程式設計。前提是能夠很好的估計工作量，定時定性的分派任務。但是普通工作還是不要使用結對了。
6. 例會
重構經驗交流、敏捷開發體驗交流、自動化測試心得交流，需要在各個例會中脫離業務層，來深入商討我們的整個團隊研發模式。
7. qa團隊
那麼測試人員在研發期間的參與度就比較低了，qa人員只負責專案最後的功能驗收。一定要讓qa團隊和研發團隊和睦共處，不能有「敵對」的關係，這樣才不會出現bug被踢皮球的現象。
關於敏捷開發的一點小想法
針對最近又比較火熱的敏捷開發，我有一些個人的想法和認識，粗淺之處，還請大家指教了。個人不太感冒，或者說持觀望態度吧，原因如下 1 首先概念是國外提出來的，是英文的，翻譯成中文往往就會有質的區別，中國人喜歡歪曲外國人的概念，也可能是翻譯的問題吧 2 敏捷開發對個人素質的要求是很高的，國外的軟體人員要比...
敏捷開發實踐 pair programming
上週一是洋老闆d正式上班的第一天，我們三人小組開了乙個很短的會，會議的主題很簡單，依然是那不變的scrum 每日站立會議三段論 前一陣做了什麼？將要做什麼？有什麼問題？下午，我正在皺著眉頭解決乙個dojo的問題 剛接觸dojo,很具挑戰性啊 d問我是否準備好了pair programming.對於p...
關於敏捷的一些想法
敏捷軟體開發宣言 個體和互動 勝過 過程和工具 可以工作的軟體 勝過 面面俱到的文件 客戶合作 勝過 合同談判 響應變化 勝過遵循計畫 今天看了robert martin的ppp一書的第一部分，敏捷開發 回顧了自己曾經加盟過的幾個公司，經歷過的大大小小的專案，感慨良多。這些公司中不乏奉過程開發為寶典...