外包这几年的技术和管理经验总结

——-由于种种原因,最近有了换工的想法,联系了以前混的不错的同事,哥们说啥也不需要准备,总结一下这几年的管理、技术经验,跟老板聊聊就行。在此背景驱动之下,决定总结一下四年多外包的工作经历,也跟大伙分享一下,估计有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、尊重每个成员的想法,培养他们自己计划自己的工作任务能力,我们管理者只需要评估计划的合理性,是否在效率允许和可承受风险范围内,这样才能让团队成员迅速成长,一两年后你的团队不缺乏骨干成员。

 

———————-由于时间关系,后续再做补充,初次写博文,本身写作水平能力有限,还望各位多提意见纠正,非常感谢—————————-

1 收藏 评论

相关文章

可能感兴趣的话题



直接登录
跳到底部
返回顶部