——由于種種原因，最近有了換工的想法，聯系了以前混的不錯的同事，哥們說啥也不需要準備，總結一下這幾年的管理、技術經驗，跟老板聊聊就行。在此背景驅動之下，決定總結一下四年多外包的工作經歷，也跟大伙分享一下，估計有90%以上的java程序員會對下面系統感興趣。

我是2010年4月份進入華為外包公司，然后在5月份跳槽到現在的公司，一直待到現在，目前是公司持證PM，華為技能定級五級。

技術篇：

這些年主要一直在做同一個項目，某個業務發放網關管理系統（這里簡稱SPXX），主要是用于管理所有的BOSS系統和組網內所有網元，組網之間采用的是Webservice技術進行數據通信，大概結構如下。

營業廳BOSS（多個）<—>SPXX（一個）<—>網元（多個）

一、組網說明：一個SPXX系統北向支持320個營業廳BOSS同時在線發放，南向支持64個網元版本和實例。

二、系統結構：該分布式系統有6↑個進程，支持添加擴展板負荷分擔，進程之間是通過Mina和Jms進行數據通信，標配主備雙活兩塊板，支持倒換，支持擴展，主要涉及Java、C++、Shell、Python、VB、Xslt等語言，大概結構如下。

1）業務發放進程（進程間都是使用Mian進行數據通信）

營業廳BOSS（多個）

↓↑Webservice調用（ACL/用戶名密碼鑒權）

——SPXX——————————————————————————–

DPU4N（北端業務分發進程，監聽SOAP、TL1、MML等消息端口，支持并發320連接）

↓↑Mina

SPU（消息處理進程，有多個，支持隨時擴展，DPU4N輪選）

↓↑Mina

DPU4S（南向匯聚）

—–SPXX———————————————————————————-

↓↑Webservice調用

網元（多個）

2）配置管理進程（進程間都是使用JMS進行數據通信）

PMU（Tomcat進程）、CMU（數據持久化進程）、OMA（配置管理進程）、JMX（進程監控進程）、Common（非進程，公共代碼工程）

三、工作原理：采用MyEclipse作為開發工具，總共有8個工程，該系統是在SUSE版本的Linux系統上部署，標配主備雙活兩塊板、支持倒換、支持擴展、升級等操作。

1）該系統有Web管理界面，主要是用于業務和配置管理，包含系統用戶、BOSS用戶、角色權限、日志、網元版本、網元實例、業務流管理、用戶策略管理、分權分域管理、Batch/Bulk批處理等等功能。

a、系統北端是采用Webservice調用，配置管理主要是給北向BOSS配置ACL和用戶名密碼鑒權信息，只有通過鑒權的消息才允許發放到網元；

b、系統可以為每個BOSS用戶指定業務發放權限和分權分域權限，也就是限制某些用戶只能開戶或者換號、某些用戶只能設置139號段等等；

d、SPXX系統本身沒有任何業務，只做網關管理，主要是由網元提供wsdl接口。SPXX系統南向有十幾個網元，每個網元都是用SPXX系統提供的模板工具，生成接口包（該包包含wsdl接口文件），然后把該包加載到SPXX系統上，再添加一個實例對象（該對象包含網元IP/端口/服務名），SPXX系統會根據網元加載的接口包自動生成業務發放界面（wsdl接口文件里面本身包含命令和參數類型、參數范圍等信息），該自動生成的界面只用于維護，BOSS需要拿接口包中的wsdl接口進行二次開發，這樣就起到屏蔽BOSS直接對接十幾個網元，只要對接一個SPXX系統，由SPXX系統來管理所有網元，避免接口混亂的局面；

c、該系統支持業務定制功能，內部有一個業務流解析引擎，支持封裝多個網元命令，主要原理是通過XML編寫一套業務流程文件和wsdl接口，然后將該業務流加載到SPXX系統中，再把該wsdl接口發布給BOSS系統，當BOSS系統下發該命令到SPXX系統，系統通過機制判斷該消息是個業務流，再通過命名空間路徑+命令找到該XML腳本，解析里面定義的原子命令，把原子命令分解發送到各個網元，再把各個網元的返回結果根據XML腳本定義規則組裝返回給BOSS系統，這樣就解決一個開戶十幾條命令對BOSS呈現只需要一條命令搞定。另外該業務流腳本支持定義變量、循環、條件分支判斷、失敗回滾等操作，說白了就是SPXX系統提供了一套自己的編程語言和語言解析器。

d、該系統還提供了批量發放功能，類似市面上那種充值卡、直接開好的手機卡都是通過批量開戶完成的，支持步長累加批處理和多個命令放到文件內的批處理。

2）分布式進程主備是雙活的，這里雙活的概念是部署到兩套單板，都是活動狀態，一塊單板掛了不會影響業務發放，如果進程掛掉JMX會對故障進程進行自動修復，多次修復不成功會就行倒換操作，支持升級、補丁。

3）其他進程功能和工具工作原理這里不細講，后續博文再輸出。

管理篇：

這里必須植入一個背景，早期我們團隊由于管理計劃不明確，人員技能過于單一，再加上系統過于復雜，由簡單的WEB系統改造成多進程的分布式系統，涉及技術非常多技能要求也比較搞。導致版本轉測試延遲和Bug改不對、修改不全的問題非常嚴重，經常被客戶投訴。我進項目半年內，項目經理、區域經理迫于壓力相繼離職，每天加班加點老員工也陸續離開，項目已經瀕臨要黃掉的地步。歷時半年勉強交付一個版本，客戶要求我帶一批人駐場交付。

合作模式：每個版本需求包分成兩份，客戶+合作方共同開發，合入同一個SVN庫，雙方投入比例3：7。

獨立運作：我們開發模式是敏捷開發，一般2周左右一個迭代，整個開發階段有4到5個迭代，一個版本大概有4.5萬行代碼量。

1、任務分配：客戶PM跟我劃分交付特性，然后我跟骨干員工一起把每個需求劃分責任人，這里主要是每個人認領制，也會根據重要程度進行劃分;

2、計劃制定：我們內部制定了完備的開發流程，所有成員可以根據該流程特性屬性2天左右就可以給出交付計劃；

3、任務跟蹤：采用早會站立會議，每個成員講述自己的計劃完成情況和下一步計劃，反饋風險和求助。我主要解決風險和求助，糾正計劃偏差；

4、流程保障：我們有專門的SVN目錄用于歸檔開發和日常規范的流程規范文檔，有迭代開發流程規范、特性串講&答辯流程規范、檢視格式規范、編碼規范（這個包含客戶要求的規范）、轉測試CheckList規范等等。統一項目人員的操作規范和輸出規范，保障交付結果。我也因為有這一系列流程保障，每天投入管理的工作時間可以縮短到2個小時左右，其余時間跟組內成員一起寫代碼，處處以身作則，遷移組內成員保障流程；

5、技能提升：項目各個模塊采用代碼責任田制，總共19個模塊都有田主和副田主，每人至少有2塊以上的田，我們定期進行代碼互檢挖掘歷史版本問題、知識點文檔寫作，根據知識點文檔每周兩次下午茶培訓，人員技能增長效果非常明顯。多個模塊都有專家，面對一線緊急問題定位，田主基本都輕松應對；

6、團隊活動：我們采取兩兩一組，每個月組織一次活動，目前已經爬遍深圳各大名山、穿越、燒烤、騎車等等，至今三年以上的老員工占8成；

工作成果：

1、工作1年以上的員工都具備獨立開發能力。我們的迭代開發流程：從特性熟悉、概要設計、串講、模塊設計、模塊答辯、BBIT用例寫作、編碼、用例測試、VT、轉測試都是有一個開發人員單獨完成。涉及到安裝、升級、前端等都由特性交付責任人全流程完成開發，而且效率和質量都符合客戶要求；

2、項目再次離岸交付。通過一年多駐場改造，我們的交付能力已經跟客戶員工基本對等，實現再次離岸交付；

心得：一個團隊制定合理的流程規則非常重要，通常一個管理者耗費太多時間和精力在人員管理和任務跟蹤上，而團隊成員則把時間浪費在瑣事上。

1、我們項目管理者在項目前期制定好交付計劃，跟客戶約定任務下發和反饋機制，維護好跟客戶的需求列表，不能讓團隊成員干了活沒地方體現。

2、每天早會把握好計劃是否正常進行，解決每個成員當前的困難和求助，讓成員都能專心寫代碼，周邊溝通和求助是每個程序員的通病，尤其是外包公司，不要讓他們把時間浪費在這個上面。

3、尊重每個成員的想法，培養他們自己計劃自己的工作任務能力，我們管理者只需要評估計劃的合理性，是否在效率允許和可承受風險范圍內，這樣才能讓團隊成員迅速成長，一兩年后你的團隊不缺乏骨干成員。

———————-由于時間關系，后續再做補充，初次寫博文，本身寫作水平能力有限，還望各位多提意見糾正，非常感謝—————————-

本文來自：http://www.cnblogs.com/huige-you/p/3802542.html