在华为做外包获得的一些感想

Posted Mike的技术博客

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了在华为做外包获得的一些感想相关的知识,希望对你有一定的参考价值。

本人曾在华为的一个项目里作为合作方的项目管理协助者,技术架构师角色。在这里谈谈技术和管理方面的感想。

1. 技术

   华为在开发一个自己的云平台技术。叫做华为应用引擎(HUAWEI Application Engine)。它是一个基于J2EE的云平台,有比较多的华为定制前端控件,前端控件比较齐全。REST服务可以不用写java代码就可以构建,配置一些sql语句就可以。只底层是基于Websphere的,平台将这些部署的复杂都透明化,使用者不需要知道具体的细节。几百人在开发这些平台。投入的力量还是蛮大的。缺点是这些前端控件有些死板,不能满足所有要求,应用团队必须借助于华为应用引擎团队才能修改这些控件。后台服务间调用关系复杂,首先调用者和被调用者都是REST服务,性能有问题,java类之间的调用就快的多了。在这里基本用不到java类之间的调用,极端的情况是,java代码甚至可以完全不写,只写javascript代码。因为后台代码完全可以用配置sql语句的方式实现。应用团队想了本地化的方法,可以更多的写java代码。但是后台服务间调用关系复杂的情况还是有待改善。华为应用引擎对单元测试有比较多限制,应用团队想了办法写单元测试,但是有些场景还是不能写单元测试的。所以单元测试覆盖率不高。代码质量难以保证。

   另外平台基于华为自己的安全登录系统w3。但是从过去获得的经验当中,发现了一些安全缺陷,向华为指出这些安全问题。华为的架构师也接受了。w3登录系统作为一个华为内部广泛应用的平台。还是要尽可能地减少安全问题和隐患。作为架构师,要考虑满足功能需求,可扩展性,可维护性,可伸缩性,安全性,健壮性,等等等等方面。所以要做的工作很多。

   华为应用引擎还有很长的路要走。

 

2. 管理

    团队很大,有100多人。团队试图采用敏捷的方法论,但是实际做的并不符合敏捷。华为方项目经理同供应方项目经理一起来管理这么大的团队。分成了几个小团队。把每个小团队作为一个敏捷团队。有时这些小团队人数在10人左右,有的时候有20人。其实这个人数并不适合敏捷。一般7到8人比较合适。没有真正符合敏捷定义的PO(Product Owner),其组织形式还是瀑布式的组织形式。BA(Business Analyst)在勉强充当PO。

     项目中蕴藏的风险是多种多样的,人员的风险,离职率比较高,需要安排工作交接。技术的风险,如某些功能华为应用引擎本身需要改造一下,就必须请华为应用引擎团队来修改,但是华为应用引擎团队服务于多个项目,需要协调资源。这块的工作就不少。需求理解的风险,开发和测试对BA给出的需求的理解可能出现偏差,需求没有很好地版本管理,所以有时出现BA改了需求文档,忘记通知开发和测试,或者只通知了开发,没有通知测试,或者只通知了测试,没有通知开发,各方对需求的理解不一致,导致项目后期各方扯皮。最后项目延期。彼时华为应用引擎不够健壮和稳定,经常出问题,耗费了团队很多时间。风险管理一度管理起来了。但是该团队没有坚持管理起来。

    华为应用引擎平台当时还未实现打标签,所以版本管理挺难的,配置管理是个很头痛的事情。做一次Build,再部署。时间都很长。不是缺这个就是缺那个,代码版本不对是常有事情。这个应该很好地识别出所有配置项,这个平台的要求,它的配置项本身就多,必须得都识别出来,很好地管理起来。这块的工作一直做得不够好,有一些配置项总是让某些开发团队的开发人员在管。甚至部署到生产环境也是这些开发人员在管。大量的部署步骤是人为操作,没有脚本。容易出错。即使有脚本,脚本的质量也堪忧。这和我们过去做的项目比。差远了。

   可以说该团队应用了少部分敏捷的形式,但是并没有敏捷的精髓。敏捷的精髓是敏捷团队对PO的主动的交付承诺。它是敏捷团队对需求理解后,分析后,对需求有拆解,了解其复杂度后,向PO做的主动的交付承诺。现实是该团队没有主动的承诺,都是华为项目经理和BA硬塞给团队的范围,需求和工期。然后没有办法,只能被动的承诺,但是这种承诺绝大部分都没有兑现。质量,工期,范围都达不到华为方的要求。这个要真正按敏捷的话,需要华为和供应方都转变成敏捷思维。

 

以上是关于在华为做外包获得的一些感想的主要内容,如果未能解决你的问题,请参考以下文章

项目过程中的一些感想

一些感想

项目感想 总纲-基于8051的数据采集系统

近期做项目上云迁移的一些状况与感想

读研以来的一些感想:名校好在哪里?

第一次做项目的感想