軟件開(kāi)發(fā)流程（框架性草稿，細節還需要完善，修改中）
團隊組成
項目經(jīng)理、配置管理員、業(yè)務(wù)顧問(wèn)、項目組員。
其中項目經(jīng)理是必須的，配置管理員和業(yè)務(wù)顧問(wèn)可按情況單獨配置或與其它項目共用。
進(jìn)展控制
在開(kāi)發(fā)前先根據項目要求設定一個(gè)總體的完成期限，并且根據經(jīng)驗設置若干個(gè)項目里程碑，里程碑規定了項目進(jìn)展所達到的要求，在整個(gè)開(kāi)發(fā)流程中采用迭代循環(huán)的方式進(jìn)行漸進(jìn)式開(kāi)發(fā)，每個(gè)項目的迭代周期應由項目經(jīng)理根據迭代目標和實(shí)際情況進(jìn)行確定。每次迭代前確定迭代目標和迭代周期，一般是把需求優(yōu)先級最高和技術(shù)風(fēng)險最大的用例首先實(shí)現，每次迭代都要以得到一個(gè)達到迭代目標并明確可運行的版本為結束標志。
需求分析
原則上不限制需求分析過(guò)程，但是建議采用UP流程進(jìn)行需求分析，必須編寫(xiě)詳細的文本方式的用例說(shuō)明（UML圖形為可選件）。進(jìn)行需求分析時(shí)采用頭腦風(fēng)暴會(huì )議方式，要求項目組所有人都必須參加和討論。所有的用例和設計都必須保存到配置管理庫中。
軟件開(kāi)發(fā)
采用敏捷開(kāi)發(fā)過(guò)程和持續集成。
測試先行，開(kāi)發(fā)時(shí)，先編寫(xiě)對應的TESTCASE后經(jīng)項目經(jīng)理審核，并編列入開(kāi)發(fā)文檔后，方可進(jìn)行功能代碼編寫(xiě)，功能代碼和單元測試代碼都由必須同一個(gè)人完成。單元測試行覆蓋率要達到90%以上。
每天下班以前必須簽入當天的工作代碼，并通過(guò)單元測試。如有特殊情況不能完成，需要向項目經(jīng)理說(shuō)明。
每次簽入必須說(shuō)明簽入結果，比如增加成了什么功能，修復了什么BUG等等。
一般情況下組員都應該采用結對方式工作，兩人同時(shí)使用一臺電腦。碰到特殊情況由項目經(jīng)理安排。
除非迫不得以，盡量不要采用IDE的DEBUG方式來(lái)進(jìn)行單步跟蹤，而是采用記錄日志和設置斷言的方式來(lái)進(jìn)行DEBUG。
每次發(fā)現BUG，必須修改單元測試以至讓單元測試可以檢測到該BUG的存在。如有特殊情況不能完成，需要向項目經(jīng)理說(shuō)明。
會(huì )議要求
每次會(huì )議必須記錄下需要解決的問(wèn)題和會(huì )議結果，并且用攝象機錄制整個(gè)會(huì )議過(guò)程，并存檔。
注：
許多朋友在看過(guò)這個(gè)規定之后，提出了許多好建議和善意的批評，這里非常感謝大家，特別是肯.索夫特朋友（以上蘭色部分為他的修改意見(jiàn)）。
說(shuō)實(shí)話(huà)，我的職業(yè)大部分是一個(gè)程序員，也沒(méi)什么太多的管理經(jīng)驗，我想每個(gè)程序員在工作的時(shí)候都會(huì )有這種感覺(jué)：提高生產(chǎn)力除了提高技術(shù)，優(yōu)秀的管理手段也是非常重要的一個(gè)因素。
其實(shí)在國內很多企業(yè)，把程序員當工人一樣管理，但是軟件和傳統工業(yè)相比還是有許多特殊的地方，但是管理人員并不知道，比如在我以前的一家公司，還在采用瀑布模型，需求人員做好了需求給設計人員，設計人員做好了設計給程序員，程序員基本上沒(méi)有資格參與需求分析和設計，但是一程序員拿到最終設計時(shí)卻發(fā)現無(wú)法下手，只好憑著(zhù)自己的想象去做，最終是什么結果可以想象。但是管理人員還認為他的管理手段非常先進(jìn)，實(shí)現了“流水線(xiàn)作業(yè)”。這種巨無(wú)“可操作性”的制度，最后竟然也被“操作”下來(lái)了，并且還做了幾個(gè)項目。。。
雖然我們并不是管理人員，但是在面對不合理的制度的時(shí)候，我們除了抱怨制度的合理性，能不能主動(dòng)一點(diǎn)提出一些自己的理想中的建議呢？
我承認我的經(jīng)驗不足，太理想化，在這個(gè)規范中，確實(shí)有許多地方不完善，也有許多部分還沒(méi)有考慮到，比如軟件測試等等。所以希望大家在批評之后，最好能提出一些修改意見(jiàn)或補充，或者把自己心目中設計的或實(shí)際運行中優(yōu)秀制度提出來(lái)給大家分享和參考，再次感謝大家。
聯(lián)系客服
