擬在公司內實行的開發規定（修改版），敬請大家指正和補充

軟體開發流程（架構性草稿，細節還需要完善，修改中）
 
團隊組成
專案經理、組態管理員、業務顧問、項目組員。
其中專案經理是必須的，組態管理員和業務顧問可按情況單獨配置或與其它項目共用。

進展控制
在開發前先根據項目要求設定一個總體的完成期限，並且根據經驗設定若干個項目裡程碑，裡程碑規定了項目進展所達到的要求，在整個開發流程中採用迭代迴圈的方式進行漸進式開發，每個項目的迭代周期應由專案經理根據迭代目標和實際情況進行確定。每次迭代前確定迭代目標和迭代周期，一般是把需求優先順序最高和技術風險最大的用例首先實現，每次迭代都要以得到一個達到迭代目標並明確可啟動並執行版本為結束標誌。
需求分析
原則上不限制需求分析過程，但是建議採用UP流程進行需求分析，必須編寫詳細的文本方式的用例說明（UML圖形為可選件）。進行需求分析時採用頭腦風暴會議方式，要求項目組所有人都必須參加和討論。所有的用例和設計都必須儲存到組態管理庫中。
軟體開發
採用敏捷開發過程和持續整合。
測試先行，開發時，先編寫對應的TESTCASE後經專案經理審核，並編列入開發文檔後，方可進行功能代碼編寫，功能代碼和單元測試代碼都由必須同一個人完成。單元測試行覆蓋率要達到90%以上。
每天下班以前必須簽入當天的工作代碼，並通過單元測試。如有特殊情況不能完成，需要向專案經理說明。
每次簽入必須說明簽入結果，比如增加成了什麼功能，修複了什麼BUG等等。
一般情況下組員都應該採用結對方式工作，兩人同時使用一台電腦。碰到特殊情況由專案經理安排。
除非迫不得以，盡量不要採用IDE的DEBUG方式來進行單步跟蹤，而是採用記錄日誌和設定斷言的方式來進行DEBUG。
每次發現BUG，必須修改單元測試以至讓單元測試可以檢測到該BUG的存在。如有特殊情況不能完成，需要向專案經理說明。
會議要求
每次會議必須記錄下需要解決的問題和會議結果，並且用攝象機錄製整個會議過程，並存檔。

註：
許多朋友在看過這個規定之後，提出了許多好建議和善意的批評，這裡非常感謝大家，特別是肯.索夫特朋友（以上蘭色部分為他的修改意見）。
說實話，我的職業大部分是一個程式員，也沒什麼太多的管理經驗，我想每個程式員在工作的時候都會有這種感覺：提高生產力除了提高技術，優秀的管理手段也是非常重要的一個因素。
其實在國內很多企業，把程式員當工人一樣管理，但是軟體和傳統工業相比還是有許多特殊的地方，但是管理員並不知道，比如在我以前的一家公司，還在採用瀑布模型，需求人員做好了需求給設計人員，設計人員做好了設計給程式員，程式員基本上沒有資格參與需求分析和設計，但是一程式員拿到最終設計時卻發現無法下手，只好憑著自己的想象去做，最終是什麼結果可以想象。但是管理員還認為他的管理手段非常先進，實現了“流水線作業”。這種巨無“可操作性”的制度，最後竟然也被“操作”下來了，並且還做了幾個項目。。。
雖然我們並不是管理員，但是在面對不合理的制度的時候，我們除了抱怨制度的合理性，能不能主動一點提出一些自己的理想中的建議呢？
我承認我的經驗不足，太理想化，在這個規範中，確實有許多地方不完善，也有許多部分還沒有考慮到，比如軟體測試等等。所以希望大家在批評之後，最好能提出一些修改意見或補充，或者把自己心目中設計的或實際運行中優秀制度提出來給大家分享和參考，再次感謝大家。