軟件開發(fā)流程（框架性草稿，細節(jié)還需要完善，修改中）
 
團隊組成
項目經(jīng)理、配置管理員、業(yè)務(wù)顧問、項目組員。
其中項目經(jīng)理是必須的，配置管理員和業(yè)務(wù)顧問可按情況單獨配置或與其它項目共用。

進展控制
在開發(fā)前先根據(jù)項目要求設(shè)定一個總體的完成期限，并且根據(jù)經(jīng)驗設(shè)置若干個項目里程碑，里程碑規(guī)定了項目進展所達到的要求，在整個開發(fā)流程中采用迭代循環(huán)的方式進行漸進式開發(fā)，每個項目的迭代周期應(yīng)由項目經(jīng)理根據(jù)迭代目標(biāo)和實際情況進行確定。每次迭代前確定迭代目標(biāo)和迭代周期，一般是把需求優(yōu)先級最高和技術(shù)風(fēng)險最大的用例首先實現(xiàn)，每次迭代都要以得到一個達到迭代目標(biāo)并明確可運行的版本為結(jié)束標(biāo)志。
需求分析
原則上不限制需求分析過程，但是建議采用UP流程進行需求分析，必須編寫詳細的文本方式的用例說明（UML圖形為可選件）。進行需求分析時采用頭腦風(fēng)暴會議方式，要求項目組所有人都必須參加和討論。所有的用例和設(shè)計都必須保存到配置管理庫中。
軟件開發(fā)
采用敏捷開發(fā)過程和持續(xù)集成。
測試先行，開發(fā)時，先編寫對應(yīng)的TESTCASE后經(jīng)項目經(jīng)理審核，并編列入開發(fā)文檔后，方可進行功能代碼編寫，功能代碼和單元測試代碼都由必須同一個人完成。單元測試行覆蓋率要達到90%以上。
每天下班以前必須簽入當(dāng)天的工作代碼，并通過單元測試。如有特殊情況不能完成，需要向項目經(jīng)理說明。
每次簽入必須說明簽入結(jié)果，比如增加成了什么功能，修復(fù)了什么BUG等等。
一般情況下組員都應(yīng)該采用結(jié)對方式工作，兩人同時使用一臺電腦。碰到特殊情況由項目經(jīng)理安排。
除非迫不得以，盡量不要采用IDE的DEBUG方式來進行單步跟蹤，而是采用記錄日志和設(shè)置斷言的方式來進行DEBUG。
每次發(fā)現(xiàn)BUG，必須修改單元測試以至讓單元測試可以檢測到該BUG的存在。如有特殊情況不能完成，需要向項目經(jīng)理說明。
會議要求
每次會議必須記錄下需要解決的問題和會議結(jié)果，并且用攝象機錄制整個會議過程，并存檔。

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