在外包的這幾年，技術和管理經驗總結

我是2010年4月份進入華爲外包公司，而後在5月份跳槽到如今的公司，一直待到如今，目前是公司持證PM，華爲技能定級五級。

　　技術篇：

　　　　這些年主要一直在作同一個項目，某個業務發放網關管理系統（這裏簡稱SPXX），主要是用於管理全部的BOSS系統和組網內全部網元，組網之間採用的是Webservice技術進行數據通訊，大概結構以下。

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

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

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

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

　　　　　　　營業廳BOSS（多個）

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

　　　　　　------SPXX--------------------------------------------------------------------------------

　　　　　　　DPU4N（北端業務分發進程，監聽SOAP、TL一、MML等消息端口，支持併發320鏈接）

　　　　　　　　　↓↑Mina

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

　　　　　　　　   ↓↑Mina

　　　　　　　　DPU4S（南向匯聚）

　　　　　　-----SPXX----------------------------------------------------------------------------------

　　　　　　　　　↓↑Webservice調用

　　　　　　　　 網元（多個）

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

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

　　　　3、工做原理：採用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萬行代碼量。

　　　　　　一、任務分配：客戶PM跟我劃分交付特性，而後我跟骨幹員工一塊兒把每一個需求劃分責任人，這裏主要是每一個人認領制，也會根據重要程度進行劃分;

　　　　　　二、計劃制定：咱們內部制定了完備的開發流程，全部成員能夠根據該流程特性屬性2天左右就能夠給出交付計劃；

　　　　　　三、任務跟蹤：採用早會站立會議，每一個成員講述本身的計劃完成狀況和下一步計劃，反饋風險和求助。我主要解決風險和求助，糾正計劃誤差；

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

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

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

　　　　工做成果：

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

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

 

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

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

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

　　　　　　三、尊重每一個成員的想法，培養他們本身計劃本身的工做任務能力，咱們管理者只須要評估計劃的合理性，是否在效率容許和可承受風險範圍內，這樣才能讓團隊成員迅速成長，一兩年後你的團隊不缺少骨幹成員。

 

----------------------因爲時間關係，後續再作補充，初次寫博文，自己寫做水平能力有限，還望各位多提意見糾正，很是感謝--------------------------------