本人曾在华为的一个项目里作为合作方的项目管理协助者，技术架构师角色。在这里谈谈技术和管理方面的感想。
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硬塞给团队的范围，需求和工期。然后没有办法，只能被动的承诺，但是这种承诺绝大部分都没有兑现。质量，工期，范围都达不到华为方的要求。这个要真正按敏捷的话，需要华为和供应方都转变成敏捷思维。
文中所说的情况，部分反应了当时的情况。可能不准确。后来情况也有可能会发生变化。比如情况有所改变。
