進入公司差不多有3年的樣子了，大大小小的項目參與了不少，一路走來有不少的感想，總的感覺很累。無論是大的項目還是小的項目，總覺得效率很低，耗時很長，我不停的思考，究竟一個團隊的產品開發和維護應該具備什麼樣子才能高效而快速的向前推進。
這段時間，“敏捷開發”變的很時髦，似乎不“敏捷開發”就落伍了，那麼到底什麼是“敏捷開發”呢？簡而言之，敏捷是一種新的軟件開發的思想，通過迭代、結對編程、測試驅動等實踐逐步完善對軟件的開發，最終形成穩定的系統。與傳統的軟件開發相比，敏捷強調人與人之間的溝通，而不是通過文檔。
我覺得一般的網絡公司的項目一般不是很大，項目開發有幾個要數：
- 項目成員的主動性
- 項目成員的溝通
- 完善的設計文檔
- 規範的流程
- 系統的自動測試
一、項目成員的主動性
大部分的項目都是比較小的（一些稍微大點的項目經過功能分割，實際上也比較小），考驗的項目成員的能力。所以在項目安排上要有所區分，讓合適的成員擔任合適的崗位。在每個項目成員的所屬的職責範圍內，需要項目成員本身主動積極的去處理和探索所碰到的問題，要積極的承擔項目中的相關責任。在實際的項目開發中，項目成員或許由於技能變的熟練或者其他等原因可能會比較消極的對待或者推諉責任。個人覺得需要採用各種方式來激勵項目成員。
二、項目成員的溝通
毋庸置疑，項目溝通在項目開發中佔着非常重要的地位。對於一個產品的迭代開發，一個項目組由開發工程師、產品設計師、測試工程師等相關人員的參與，如果不及時溝通，會導致需求和交付的產品不一致，會導致開發、PD、測試相互理解的不一致。在開發過程中，需要項目成員及時彙報自己的進度和下一步的工作，以便PM及時調整計劃或者資源。一般溝通爲一天一次比較好，比如我們現在是每天早上有個晨會，大家彙報自己的進度和碰到的問題，彙報明天的計劃，如果測試有接入的話，測試會總結一下測試的情況和進度，這樣如果有問題，大家在會議上立刻進行處理。一般晨會不易太長，5分鐘左右。
三、完善的設計文檔
很多項目有個很明顯的後遺症：就是資料不全。後續接手的和維護產品的都不知道如何下手，這樣也給人員的輪崗帶來麻煩，故項目開發完畢以後需要有一份完善的文檔，這個文檔從產品設計到開發結束都需要不斷的調整，需要整理到相應的文檔庫中。
四、規範的流程
一個產品從需求、設計、開發、測試、上線需要遵循一定的流程，比如要有DB表結構變更規範、代碼開發規範、代碼提交Review規範、測試規範、上線的流程等等。有了這些規範還需要嚴格的執行，否則是一張白紙，很容易出問題。目前流程是系統化和人工化各有一半，但個人覺得適當的偏向系統化一點更能保證系統的質量，畢竟單純的靠人來監督還是有疏漏的。
五、測試驅動
系統開發過程中，很多人都很相信自己的代碼，以爲寫完了就好了，就提交到測試環境讓測試去測試。其實這個是非常不負責任的行爲，一份提交給測試工程師是需要經過自己嚴格測試以後，否則到測試工程師發現問題以後，然後再反饋調整，無疑代價擴大，同時犧牲了開發和測試的寶貴時間。所以一份提交的代碼需要經過幾個環節：1.開發個人的單元測試。2、系統的自動化測試。3、經過前面兩個環節的過濾以後，才提交到測試環境。
當然在實際的項目過程中，還有其他因素（比如環境，E網打進產品和5-6其他產品有關聯關係），那麼就需要確保這些因素穩定在一個允許的範圍內。另外，我覺得需要有一些獎罰機制，比如BUG數量、規範的執行情況等，當然獎罰並不是目的，目的是警戒一下沒有遵守規範和規定的結果。
好了，羅哩羅嗦這麼多，上面只是我這段時間來參與項目和帶項目的一些感想。還需要以後不停的總結和改進。
