背景
人员组织结构
XXX
周边集成系统
SSOProxy 1个接口
Classroom 2个接口
DocMan 2个接口
CodeHub 1个接口
ProjectMan 3个接口
APIGateway 所有开发云服务接口
判题系统 2个接口
系统部署架构
XXX
系统技术栈
C#语言 HTML/CSS/JS RAZOR模板引擎
Windows Server 2012 IIS容器部署
交付工作时间线
2017.11 决策接受系统开发任务
2018.1.8启动大赛平台的开发工作
2018.2.15~2018.2.21春节放假
2018.3.1大赛平台上线运行
开发工作是1月8日开始,3月1日截止,2月15月-2月21日春节假期,共计35天。
开发:易思智外包,2后台+1前台+1个实习生
测试:华为方1人+外包1人(1月15投入)
CIE:华为方1人(2月7日投入)
交付过程风险
TOP1 需求风险 (无人管控、随意变更、需求反复、重视不足)
(1)缺少需求列表
完全没有需求文档,需求细节完全靠问,时间都浪费在各种沟通中。
(2)领导改需求
开发到1月26日改了一版需求,首页页面完全基本换掉、其他页面调整、报名流程调整(增加25人天开发工作量)
(3)后期改实现方案
1、判题串行执行改并行执行,配合联调(增加5人力)
2、为了架构稳定性,同步接口改异步接口(增加10人力)
3、增加可测试行,增加灰度功能(增加5人力)
(4)需求反复
1、赛事直播页面先是移除,后又要上线
(5)PD投入不足
1月29日一周 杭州授课,事项委托姚传存
(6)需求基本处于无管控状态
HR那边的需求负责人换成一个完全不懂业务的人,基本什么需求细节都不了解,还得由开发给他讲业务细节。
(7)交付时间提前
原定交付上线时间是3月8日,提前为3月1日
(8)与开发云深度集成
与17年相比,最大特性是利用开发云进行开发活动,且集成开发云的4个服务。工作量比17年大大增加,预估工作量严重不足,预估工作量为14人天,实际工作量为3倍不止。
最开始需求为储存学生答案(DocMan),后经领导要求深入使用开发云功能
TOP2 周边系统风险 (集成系统越多,风险越大)
个人感受:真正的开发工作量其实只占了1/5,其余时间全是在等待、联调、验证、定位问题
个人体会:你能对自己系统了解,但你永远无法了解其他系统的风险。(添加成员无法加入仓库,后经定位为不支持跨租户成员添加,但是文档里也没有写)
TOP3 技术/架构风险 (前期考虑方案不全面,导致后期风险大)
我1月5日接受此任务时,各环境服务器资源没有申请、部署架构没有梳理。
(1)与开发云服务集成需经过APIGateway交付,这是我没有识别到的,导致内部开发时按照内网的对接,后又全部改为APIGateway对接。
(2)与CodeHub集成内部开发完成,后经了解网络不通,又改为新加服务来支撑此功能。
(3)与IAM直接集成后改为SSOProxy集成
TOP4 人力风险 (前期不紧张,后期时间紧任务重,再紧张已经晚了)
1、由于PO问题,外包进场比预计晚了1月。导致开发周期被大大压缩,17年大赛12月外包就进场了。
2、1月8日后陆续人力才到齐。
3、前年前后外包请假比较多,前年前后全员各3天,后经多方交涉派了两个人,还是阶段支撑,且新员工工作效率低。
4、从1月8日开始全部处于加班状态,基本都加班到10点,外包抱怨较多,周末至少加班1天,中间一名外包扛不住离职了。
5、易思智没有提供测试人力,后从Cloud BU协调了两名人力。
6、人越多管理成本就会越高。
7、一个项目全部围绕一个人转就会出现瓶颈,解决瓶颈就是要多培养对业务负责的骨干。
环境风险
研发环境(Alpha/Beta/Gamma/性能环境)
现网环境
性能环境搭建耗费大量时间,codehub、classroom出现大量功能问题,组织升级,定位耗时长(工作量14人天)
新服务交付面临巨大挑战(基础工作量大)
1、流水线搭建:组内没有人懂流水线,多方求助,慢慢搭建起流水线,编译构建、自动部署。
2、新服务上线要做大量的工作来满足性能、安全、可靠性要求。
个人总结
1、要合理管控PD提出的需求,往往PD对需求实现不了解,工作难度也不了解,所以要给PD合理的反馈,不要一味承接需求。
2、需求还是要有文档有邮件,可追查,不然就需求变更带来是全尽的痛苦。
3、项目交付全部依赖于人,多掌握几个能力强负责人的人是关键。
4、多培养几个对业务熟悉对架构熟悉的人,如果只有SL懂,那将成为整个项目进度的瓶颈。而且还会特别累。
5、项目交付是个工程事件,需首先从全局着手,切忌一头扎入实施细节,从而忽略了很多前期应该开展的工作。
6、系统的架构设计是不能出错的,后期改动架构是一件很痛苦的事情,这就要求我们一定要多方面论证方案的可行性。
7、如果集成的系统过多,那你就要小心了,这表明你花费的沟通成本将大大增加,不可控因素也大大增加。
8、遇到风险千万该求助就求助,该上升就上升。
反思
1、让自己成为项目团队的瓶颈
2、架构应该提前识别到网络风险,但是没有及时识别到。
改进思路
需求把控,PD要管控需求,不能在有限的时间承接无限的需求,SL针对不合理的需求要给出意见
可以并行搞的事情不要串行搞(环境搭建可以在开发活动开始时就开始,开发完成再进行就影响进度)
DevCloud工具要怎么帮助用户成功(真正提高研发活动效率,整个流水线搭建熟手都要一周)
周边系统要了解需求的背景,不然开发完才发现不对造成反复。(对端到端的业务没有明确的说明。 )
人很关键,交付过程中最重要的是人的能力,培养几个业务骨干,技术骨干
出现风险的时候,要调整,比如人力、功能特性( 12月份讨论方案只接入DOCMan,1月确定深入集成DevCloud )
架构设计要具有扩展性(需求变动不可避免,尽量做到可扩展,SSO方案)
交付流程精简,提高交付效率(从出包到上线要一天时间)
人员管理,调动人员积极性,让大家团结起来把力用在一点上
多投入华为人力(熟悉交付流程,投入SE对架构进行把控)
流水线搭建过程中,对C#编译构建,Windows部署支撑起来有点吃力。
新服务上线面临诸多挑战,要如何帮助服务成功,快速上线
原文地址:https://www.cnblogs.com/yaochc/p/8678713.html