伺服器
伺服器至少要3個環境，開發環境、測試環境、準生產環境，個人建議的是要4個環境，除了這3個，還要加個效能測試環境。
應用伺服器要分開到不同的主機，也可以是虛擬機器，資料庫伺服器可以在同一臺主機。
平時我們先在開發環境寫**，等自己在開發環境上測試完成，再上傳到測試環境，等測試人員測試完成，上傳到效能測試環境，如果效能也達標並且沒有問題，上傳到準生產環境進行回歸測試。**的流向 開發環境（開發人員測試）---->測試環境（測試人員測試）---->效能環境（開發人員測試）---->準生產環境（測試人員回歸測試）。
各個環境的**
所有的**，從功能上面或者**層面，開發環境 > 測試環境 = 效能環境 > 準生產環境。
2.1 開發環境 ：由於有臨時**，或者其他未上測試環境的**，開發環境的**要多於測試環境，並且完全包含測試環境。從開發環境到測試環境，要根據開發環境實際修改的**，和測試環境的**合併。
2.2 測試環境 ：就是給測試人員測試的，如果沒有專門負責這塊的，測試環境可以忽略。
2.3 效能測試環境：由於是做效能測試的，根據實際，可能測整個流程，這就和測試環境的**一樣了。如果只測試部分，可以閹割其他**測試。
2.4 準生產環境 ：這個要和實際環境一樣，也就是和吉林總部的硬體裝置一樣，最終投產的檔案就是放到準生產環境的。
**管理
重點對準生產環境管理，每次投產後，都把**全量備份。其他環境的**，只需要定時備份就可以了。
文件從需求到投產，整個過程，應該有的文件如下：
4.1 需求文件 ：需求提出方要做什麼、實現什麼功能、投產上線時間。
4.2 需求分析文件：開發人員對需求文件的理解，分析要做什麼，是否能理解需求方的想法，做出開發計畫，啥時候能開發完成、開發測試、測試環境測試等等。
4.3 概要設計文件：開發人員大致說明要怎麼做、需要哪些硬體環境、哪些軟體環境、涉及到的相關其他系統。
4.4 詳細設計文件：開發人員要詳細告訴其他人準備怎麼做，每個步驟的流程怎樣，介面定義，資料庫建表等等。
4.5 開發測試案例：開發人員自己測試了什麼，案例是否滿足需求方的要求。
4.6 測試人員案例：測試人員做的測試案例，可能是對整個過程的所有開發人員的測試案例的整理。比如乙個系統，涉及到2個交易，2個開發人員參與，開發人員只測試自己負責的部分，整理的案例也是侷限的，而測試人員需要負責測試整個過程。
4.7 測試人員記錄的問題彙總：記錄測試過程中程式出現的問題，越詳細越好，內容包括，時間、測試內容、測試環境等等
4.8 維護文件 ：有些非系統缺陷的，比如前端填寫的資料出錯，應該怎麼處理。
4.9 投產文件 ：每次將**放到下乙個環境，都需要投產文件，包括檔案列表以及對應的修改內容、需求編號、投產檔案、投產操作（投產前的備份、投產、投產異常回滾）。
測試案例的要素
總體來說，必須包括2個部分，正常交易、異常交易。每個部分又包括5個內容，測試內容、預先條件、預期結果、執行過程、實際結果，每個部分包含1個或多個步驟。
投產投產的檔案，包括但不限定，源**、源**編譯後的可執行檔案或者動態庫、配置檔案、shell檔案（流程控制、新建目錄、修改許可權等等）、資料庫指令碼
關於軟體評審的一些想法
軟體評審 軟體評審並不是在軟體開發完畢後進行評審，而是在軟體開發的各個階段都要進行評審。因為在軟體開發的各個階段都可能產生錯誤，如果這些錯誤不及時發現並糾正，會不斷地擴大，最後可能導致我們開發結果不可控。軟體評審是相當重要的工作，也是目前國內開發最不重視的工作。1 評審目標 發現任何形式表現的軟體功...
關於IT企業組織架構的一些思考
今天早上看到一篇文章 渡過生死線 一段恩怨，一段商戰 裡面講的是金山網路的一些事情，雖然有軟文的嫌疑，但是裡面說的有幾點我覺得非常認同。先談談一般公司的組織架構把，傳統的軟體企業的組織架構是水平的，涉及和跨越多個部門，例如下面的乙個企業的組織架構 虛擬出來的，說明而已 首先層級非常多，從ceo到最終...
關於組建自組織團隊的一些想法
自組織團隊，自適應團隊 敏捷宣言中有一句 quote 最好的架構 需求和設計來自於自組織的團隊 quote 怎樣的團隊才叫自組織的團隊呢 csdn上有一篇myan的文章 url 也有對自組織團隊 自適應團隊 的介紹。摘錄一部分內容如下 mishkin 這個很難說，因為在不同的組織，情況會稍微不同。不...