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

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

1. 技术

   华为在开发一个自己的云平台技术。叫做华为应用引擎(HUAWEI Application Engine)。它是一个基于J2EE的云平台,有比较多的华为定制前端控件,前端控件比较齐全。REST服务可以不用写java代码就可以构建,配置一些sql语句就可以。功能也是比较强大的。缺点是这些前端控件有些死板,不能满足所有要求,应用团队必须借助于华为应用引擎团队才能修改这些控件。后台服务间调用关系复杂,难以维护。应用团队想了本地化的方法,可以更多的写java代码。但是后台服务间调用关系复杂的情况还是有待改善。单元测试覆盖率不高。代码质量难以保证。

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

   不方便做单元测试。不管是前台的javascript,还是后台的service都无法方便地做单元测试。HAE平台加上这个应用的可测试性比较差。因配置管理很差,无法正常地部署。基本每天结束的时候都难以获得一个具有可测试的版本。需要好几天甚至更长时间拼凑出一个勉强可以测试的版本,但是一移到另外一个环境。就歇菜了。又得花好几天时间。

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

 

2. 管理

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

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

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

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

 

文中所说的情况,部分反应了当时的情况。可能不准确。后来情况也有可能会发生变化。比如情况有所改变。

 

posted on 2016-10-22 11:33 mikelij 阅读(...) 评论(...) 编辑 收藏

导航