金融業作法
等於過三關
基本的程式都在板控上
假設USER新需求，就先在開發機(VM)
我們是三台DB擺一台，AP一台，一台兩個都有。
改完或是寫完，TESTOK，提出申請(ISO)
跑文件，去換版室，連上正式機，換版。
對，相當麻煩。
大多數時間其實都在寫文件，USER需求有時候可能只是。
一個按鍵再重組SQL就好了。
老實說對開發來講，這種情況滿不好的，軟體業應該不適應人月才對。
想不出來就是想不出來，再多人也沒有用。
版控的好處大概就是有屍體可以死者復甦這樣。
如果你們用VS他是有TF可以用，不然就是GIT SVN之類的。
小公司的話我覺得還是有機一點，大公司就可以掛這些。
不然我是覺得一組RD寫一寫，去發布就好了。
然後PG做做教育訓練，在自己電腦分區。
感覺比較好也比較自由一點， 有主管或是RDTEAM做CODEREVIEW
這樣會不會比較好?

但是我們的開發人員其實不到十個人兩個是做網站oa的，五個是做現場自動化的主要是要管控做網站的這兩個人後續會新增人員也不一定主管其實不懂Java 或現場程式的.net ,他也不想看程式碼我猜主要就是想把這群人框在一個平台上開發程式最好他們做了什麼操作主管可以知道

你們主管並不是真的想看什麼 只是想要有一切都在他監控之下的錯覺

推樓上另外你如果不是主管就不用煩惱開發環境統一個問題煩惱如何用好版本控制如何讓大家都懂正確操作A與B上傳後某功能消失 有版控跟本不應該發生

原po出發點就不是想搞好軟體品質，搞什麼版控到最後都是會失敗的。

推二樓

推二樓，主管只是想要有掌控感，那就裝模作樣隨便弄個東西不過你要跟主管解釋會有開發變慢的問題，讓他背責任

人要請、機器要多買、專案時程要拉長，列給他，看他反應跟你討價還價就是想把數字壓到他舒服的範圍內的，別跟了

主管外行 要是沒能力做好資源跟需求管理 別跟了