公司的規模不大，做的項目不多，每個項目組的成員也少，最多的也就是四、五個人，目前的幾個項目問題多多，各方面的問題都有，但是開發流程上的問題應該是最嚴重的。
這幾天在考慮公司的開發流程可以做哪些改進，考慮的結果如下，自己的一點看法，如果有不合理的地方希望大家能給我指出來，幫助我改進，謝謝！
公司現有開發流程改進可以做的地方：
一、開發
1、開發時的模塊劃分不是簡單的按照功能模塊劃分；必須按照面向對象的方法進行設計并拆分；
現在的劃分方法是：按照程序的功能劃分模塊，基本信息給A做，庫存管理給B做，業務模塊給C做，報表模塊給D做……
這種劃分方法造成的結果是大家的開發是各自為戰的，并且開發通常是面向過程的，程序很難進行自動化的測試；另一個就是代碼的重用只能做到函數級的，對于一些業務邏輯的全面封裝很困難；當然這些問題也跟開發工具有關，PB做OO開發要比做過程化的開發要困難。
模塊的劃分必須按照OO的概念進行，即必須把業務邏輯部分獨立出來，這一部分必須是僅僅包含邏輯，而不考慮展現的問題；在其他的功能部分全部都是使用邏輯部分的功能進行數據處理；
這樣做的好處是顯而易見的：
1）代碼的重用可以提高一級；
2）對于業務邏輯的修改可以封閉在業務邏輯部分，而對于展現部分的改動不會太大；
3）是在封裝后的業務邏輯模塊可以通過自動化測試工具（NUnit、DUnit等）進行單元測試，可以保證單元級的代碼質量；
2、在開發過程中對業務邏輯部分使用測試驅動開發，要求對業務邏輯類必須先寫出測試類，在開發過程中始終以測試對開發進行檢驗，以保證業務邏輯的正確性。
二、開發過程
1、開發過程必須使用配置管理系統，并且最好使用支持并行開發的SCM系統，比如CVS、SVN等；
2、對配置管理系統不能再作為單純的源代碼控制系統來使用，對于標簽、分支等等功能都應該使用起來，這對于開發的管理是很有好處的；
3、推行每日構建，在每日構建后對業務邏輯部分進行自動化的單元測試，對于構建或測試失敗的要立即解決，以免將錯誤拖延的太久，造成解決問題的代價過高；
4、Bug管理系統必須使用起來，目前使用Excel文件進行Bug管理的方法有諸多的缺陷，不是一個很好的辦法；使用Bugzilla、Mantis等等Bug管理系統有助于對系統存在的問題進行跟蹤管理，也有助于對開發過程的跟蹤；
5、開發人員必須每天記錄工作日志，工作日志不應該是單純的是“今天做了什么模塊，解決了什么問題”的垃圾信息，也不應該是給領導的工作匯報；工作日志更多的應該是大家在開發過程中遇到的問題、解決過程、心得等等的交流；我想通過建立一個內部的多人 Blog 用來記錄工作日志比較好；
三、流程改進中存在的問題
1、客戶的需求總是在不停的變動，甚至在核心業務的流程上有有可能更改；對于這種需求變更無論怎樣設計，其更改都不可能會少，需要想辦法盡量減少這中需 求變更對系統的影響；另一個就是在前期的需求調研中對用戶的需求了解應該能夠達到一定的深度，否則象目前項目在開發第二版的時候不得不推翻第一版的情況很 有可能會再次重演；
2、系統必須有OO的設計，這方面大家的經驗都很欠缺，而且欠缺的不僅僅是經驗，更重要的還有OO的思想；
3、開發工具的問題，雖然公司在逐漸向VS.Net轉移，但是目前大家比較熟的開發工具是PB，而且目前的一些業務項目仍然是CS結構，無法使用 VS.Net開發；繼續沿用 PB 則上面所說的全部都是一句空話；而如果改用Delphi，其轉移難度仍然很大，轉移的代價是否合算也是個問題；