做了很長時間的開發，也帶過一些項目，有過很多成功和失敗的經歷。
一些失敗的項目不斷促使自己思考如何才能把項目做成功，也看了一些關於項目管理和敏捷開發方面的書籍。
自己總結下來，發現項目失敗的原因大概是兩方面：
1. 缺少方法， 不知道如何應當使用那些方法來保障項目的成功。
這個方面可以通過請教、多看書、不斷實踐來提高。
2. 還有一個重要原因是人性的弱點，"超越規則"的僥幸心理。
近期報道的中國式的過馬路，凸顯了國人不遵守規則的心理。因為人總會認為自己是個特例，明知道規則的情況下，總是認為自己能夠超越規則而能夠成功或者避免懲罰。
這也是軟件項目中同樣的失敗案例不斷重現的原因，即使我們有前人總結過的經驗教訓。
比如:
你明知道這個項目不可能在3個月內完成，但是迫於老板的壓力，你會覺得自己能夠超越當前開發效率滿足這個不切實際的幻想。
下面是我總結的一些團隊開發的規范，只是初稿，非常歡迎園友有其它的建議或者補充。
"你我是朋友，各拿一個蘋果彼此交換，交換后仍然是各有一個蘋果；倘若你有一個思想，我也有一種思想，而朋友間交流思想，那我們每個人就有兩種思想了。"
項目經理
1. 項目開始前組織培訓
使用的工具和技術， 如git, log4net, Resharper, Redmine, NAnt等
項目編碼規范
項目使用的框架和設計培訓
2. 每日構建
每日構建要能夠自動化執行。
覆蓋以下內容來保證項目質量:
單元測試的代碼覆蓋率達到90%，每日構建能夠成功通過
所有代碼運行過程, log4net可跟蹤
通過自動化的驗收測試
每天使用NAnt做每日構建，運行單元測試，代碼質量檢查，代碼重復檢查，安裝包制作和發布
3. 關於測試數據
在項目開始時，着手准備建立和維護一套數據庫結構和測試數據，測試數據要達到以下要求：
測試數據應當全員用一套，可以方便的導入和恢復到初始狀態
測試的數據庫結構和數據要有版本管理
測試數據應當用相對有意義的數據，比如User Name 不能用asdfasdfas這種， 而用Peter, Jim等。
當bug發生時，如果可以通過補充特例的測試數據達到覆蓋bug的效果，應當補全這部分測試數據
4. 每日的站會和分享
組織項目成員站會，關注項目block issue
成為站會的組織者而不是領導者，發揮集體成員的主動性來解決問題和分享經驗。
分享的內容與重要，大小無關。可能只是發現了一個更好的Api的使用，一個變量命名不好的錯誤等。
讓團隊成為一個自主的，自我提高和修正錯誤的團隊。
5. 關於知識分享工具
團隊中不斷建立的規范、知識、用戶需求等，需要有種方式記錄和傳播。以避免進入新的成員時，只能依靠經驗和記憶等不可靠手段來傳遞的方式。
推薦使用Wiki
6. 關於項目中使用的第三方API或控件
使用第三方API或控件時, 任何對商業使用收費，或者免費但不開源的，都需要得到客戶的認可和同意付費
團隊需要考慮第三方API或控件的穩定性，和可維護性，避免開源項目暫停或者停止維護等問題
如果是和客戶的技術團隊合作，即使使用開源和免費的，也需要得到對方的同意。
開發人員規范:
添加注釋
1. 類注釋
類的注釋，需要描述類的功能、依賴和如何使用
2. 代碼注釋
復雜的邏輯應當添加注釋
3.使用Region
使用關鍵字region注釋使代碼更加整潔
4.全局變量注釋
每個全局變量需要寫注釋
5. 程序流程變化注釋
switch, if, while 等條件判斷地方必須寫注釋
6. public方法注釋
public的方法體中的代碼，需要寫好詳盡的注釋
編碼規范
1. 單行代碼寬度不能超過150, 單個.cs文件長度不能超過600行. if, while, for, switch等的嵌套必須<=3
2. 少定義委托，多使用Event, Func, Action 和 Predicate
3. 對於public的函數， 不要太長，可以分拆成多個private方法減少代碼長度.
4. 變量命名
4.1 控件的名稱，不允許是button1, textbox1這種無意義的名字
4.2.使用能讀懂的命名(盡量使用全名)
4.3 Event等delegate的命名
Event的命名要體現出事件, 如...Changed, 體現發生了什么，而不是告訴要做什么
bad: publicEventHandler ExtendOrderDetails;這里直接告訴別人做什么
good: public Action<bool> OrderTrackTypeChangedToOther; 這里只是告訴別人發生了什么
5. 關於注釋的代碼
如果注釋的代碼具有通用性，就提取到公共類中
如果一些代碼確定沒有用處，注釋的代碼最好刪除掉(如果不確定, 暫時保留，也不要超過2天)
不要擔心, 可能由於需求改動，又會改回原來的代碼，因為：
* 可以通過SVN獲取
* 我認為敏捷的一個重要思想是，小步快(穩)走, 關注當前。 所以不要為未來不確定的東西支付成本
保留注釋代碼一般用於:
1. 為了調試作用，暫時注釋代碼
2. 一些關鍵的配置代碼, 比如IsLive變量用來判斷當前系統是否上線, 可能會有
IsLive = True;
//IsLive = False;
單元測試
1.盡量在項目中覆蓋單元測試，依據項目不同，團隊可以制定自己的標准(如代碼覆蓋率等)
2.修復bug前，先寫單元測試覆蓋bug, 然后再fix bug
類
1.單一職責
業務邏輯類中不要包含界面相關代碼
切實保證這個類中的代碼，和類的名字(定義)一致。
只告知外界本類內部發生的事情，不要直接發指令讓外界做什么。例子: 類中的delegate, event, 是用來告訴類內部發生了什么，不要指導外界做什么。
盡量隱藏類內部的實現細節。比如MS的File類，包含操作文件的方法實現，但是外界不需要知道具體如何實現的。
2.類應當盡量依賴其它小的類，依賴的其它的類應該盡量放到構造函數中
假如有一個擰螺絲的功能類，只需要一個扳手就能解決問題，那么不要讓這個類依賴於一個工具箱
3.減少依賴於類, 應當更多的依賴於接口
把上面的扳手類抽象成一個接口，讓擰螺絲的功能類依賴於接口
4.盡量少的使用全局變量
全局變量需要寫好注釋，解釋全局變量的作用
全局變量不要在類中的私有方法中使用
測試人員
參考下面的文章
如何有效地報告 Bug
其它相關文章: