在 2020 年 12 月初，我们发起了 GSP 研发体验的年度调查问卷，有 191 位同学参加问卷，大约占 GSP 人数的 47%，在此我们感谢所有参加问卷反馈的所有同学，你们的积极参与可以让 GSP 的明天变得更好！
没有来得及参与调查问卷的同学不要感到遗憾，明年此刻我们可以再相遇。
第一部分：参与人员概况
在这一部分，我们统计了参加问卷人员的分布情况，大家在团队中的角色如下：
工作年限分布如下：
以上数据基本反应了上海团队的大致结构，各岗位人数比例还是比较符合软件研发公司的主流配比。工作年限比例中 1~3 年的工程师占比最高，希望年轻一代人可以团队带来更多的创新和活力。
第二部分：研发流程的完整体验
在这一部分，我们收集了项目计划，功能开发，QA 测试，产品发布以及监控运维共五个维度的研发体验评分，包含了研发流程的完整生命周期。
维度一，项目计划和需求管理的体验
你们项目需求管理体验如何？
需求主要由谁来分析呢？
维度二，功能开发的体验
你们项目的持续编译 CI 的做得怎么样？
维度三，QA 测试的体验
维度四，产品发布的体验
产品发布一般发生在工作日还是周末？
产品发布是不是需要开发人员参与？
维度五，运维监控的体验
作为开发人员每周花在人肉运维上的时间？
关于这一部分的结果，我们可以发现一些比较有意思的数据：
项目管理和计划：
- 接近 80%的人认为自己所在的项目组都是在完成计划内任务，有序的计划是成功的一半。
- 32%的人认为他们的需求能在 Sprint 开始前确定 80%，这些团队的开发人员一定很幸福。
- 35%的需求是完全由 BA 分析的，Lead/PM 会分析 30%，剩下的只能靠程序员自己了。
功能开发：
- 有 52.3%的开发团队能在功能完成后 15 分钟内完成本地验证，这样的体验还是很不错的。
- 有 52.4%的开发团队 CICD 能在 30 分钟内完成，其中 16.8%的团队甚至做到了 15 分钟的 CICD，加油！
QA 测试：
- 有 10%的项目能够做到自动化测试覆盖大部分用户场景，而且测试频率很高，真乃吾辈楷模。
- 大部分 QA 团队都还是以手动测试为主，希望我们 QA 团队能尽快转型，拥抱自动化！
产品发布：
- 你还没听说过 ROD 和 0 Touch Deploy? GSP 里 10 个人里就有 1 个掌握了这项技能。
- 整体而言，在 GSP 自动化一键发布已经是标准，70%以上团队已经遵循这项实践，不过部分团队还需努力优化成功率和运行时间。
- 周末发布（>45%）貌似是一种不正常的常态，希望明年我们有更多的团队可以选择在工作日发布自己的产品。
- 我们的大多数研发人员（72.8%）都会参与产品发布流程，知道大概不会出问题但还是想看看会不会出问题。
监控运维：
- 大部分的项目组（52.8%）认为自己都部署了还不错的监控运维系统，能第一时间收到线上告警问题，很棒！
- 除了监控系统，还是有 20%以上的研发人员每周需要花 1 天以上来处理线上问题，他们的头一定很大。
第三部分：改进意见和最佳实践
这一部分主要主观问题，大家可以畅所欲言去吐槽我们需要改变的地方，也可以分享自己团队里比较推荐和成熟的工程实践。
问题一，你希望项目组有哪些改进措施？
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
感觉很固定，没有变化。
对于新的大项目，lead应该准确规划好时间，以防拖到最后赶着完成。
sprint开始前能确定需求
环境稳定些，早些确定环境供求
Everyone need follow the timeline，invordrr that QA can carry out the shift left.
ecs资源申请能够尽快结束
需求能尽早确定 demo能相对早一点做
TeamCity Build 非常慢
跟其他team合作的项目，需要更全面的计划
希望从需求分析到整个sprint流程更智能规范化
使用可靠的ui组件
提升工作设备的性能
support回复太慢
希望能有一个给新入行的网页
出问题的环境，明确写明找谁，不然一个传一个比较很麻烦
提高ECS和Flink平台的稳定性。同样的deploy过程，有时第一次失败，需要deploy两次。
安装环境更快点
希望GSP DevOPS 能响应更及时
编译部署速度太慢，严重影响研发效率
batch的监测和诊断加强
BA更多介入需求提供，缩短发布时间
持续改进
改进发布流程，减少人工干预，缩短发布时间
需求，release items
产品更全面的监控; 历史项目上Ecs;
多增加前期plan 需求分析。使得开发效率更高
希望Support team能多做些Support工作，希望BA能够把需求分析做好
部署自动化 进一步加强流程监控
测试前环境非常不稳定
完善deploy流程，减少DEV的人为介入
提高稳定性，实现zero touch deployment
项目安排留好足够时间给中途加入的紧急事件
DDL configurations
由专门的support来support现在的项目，减少开发的support工作
改善测试环境
部署前自测环境
针对老的系统，搭建自动测试效率低，但是需求更新频繁，手动测试覆盖不全，如何解决？
尽快应用上先进的自动化部署CI CD，还有Kb等日志查看工具
增设qa和ba
申请更多的ecs资源，让部署能一次成功，不需要介入手工部分。提前plan好需求，让需求源源不断地到达开发手中。更准确地评估任务effort
落地一些中央化平台，减少一些应用程序的调研工作。
更好的计划，并且严格执行，有流程上的痛点及时安排人员解决，而不是只忙项目需求本身
希望每个sprint前能早点确定需求
加强operation,而不是全部dev解决.
希望环境更加稳定，自己CI CD工具有更好的体验
测试环境非常不稳定，项目上uat时间总是拖延压榨qa测试时间，需求和范围确定总是比较晚而且有反复，jira管理混乱类型字段和流程希望可以规范起来
除了开发，考虑工程整体性，测试，发布，部署，持续跟踪。
希望ba可以更专业
问题二，你们项目组有什么比较好的工程实践可以推广到其他人？
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
micro frontend
Monitor可以监管环境和service up down JIRA管理进度面板
airflow平台
部分dev 对qa的support很好
混沌
还不太了解。目前觉得checkout有工具还是不错
flink
Automation release
更好业务理解可以很大程度上减少不必要的开发， 从项目的启动开始去积极参与。
需求设计和开发过程中，我们有一些template，比如JIRA的template.要求BA将一些DEV设计开发过程中需要的一些信息罗列出来，避免一些信息不对称，从而提高效率
自动化测试
zero touch CHG
Project status progress tracking tool
data service组的沟通做的十分到位，support也很好
新项目模板，当前已经有了CI/CD，是不是可以加入更多的东西，其实好多项目用的东西都差不多
服务器down检测
多数据中心部署，需要一键部署。
最近在搞CAB Opt-out，希望对release流程有帮助
每天做自动的SOD环境健康检查，开发尽早介入调查
问题不是测出来，靠整个team合作，每一步严格把关。
Release checklist
提前做计划能保证整体交付质量，比如开发在sprint1，但是PM/BA已经把sprint 2/3的 70%需求和范围确定。
问题三，你所在项目组有哪些问题亟待改进？
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
跟美国用户沟通成本太高，老项目的部署没有全自动化，步骤繁琐
flink job部署过程中会产生莫名其妙的ecs问题而部署失败，需要重新部署
MF需要teamcity打包
ecs部署可以更加自动化
Blackduck 流程 和扫描都很慢
手动测试太多 开发、测试环境不稳定 需求不明确，没有local BA
能做到周内release
模块化不够导致重复代码很多，代码质量逐渐降低
自动部署的配置，希望多点注释
发布过程复杂，需要手动操作
DevOps自动化不够高
有些重复的工作，比如部署
如何按需全自动发布，实现真正的ROD
autosys失败到support发邮件中间有不小的间隔
Zero touch deploy缩短与support的交互时间
提change
bitbucket repo 太多，难以管理。发布流程手动干预过多
0 touch
多个环境的一键部署；模板代码框架，快速开发；
release前autosys 脚本的verify release中一些job的启停
可以自动化的步骤以后有待改进
需求变更有时会在release前几天发生
自动化部署
Legacy WPF 自动化 CICD auto regression
DDL configurations
需要加regression的测试，避免重复的劳动
没有时间完善回归测试用例，需求在最后两天都会有新增或更新，陷入恶性循环
切换server用户，非常繁琐，要填多张表单，费时费力
ecs资源不够导致部署失败的问题
dev整个流程经常失败，通常在部署，是否流程开始前做一些预判，节约时间.还有很多莫名其妙的问题，比如部署成功，但是页面上却是失败
部署自动化和更多的监控信息
编译部署半自动，需要自动化
简化release流程
持续自动化测试做的还不够好，需要能与cicd结合自动测试每个部署版本的质量，目前都是定时执行，失败率也较高，需要人工介入调查
好好使用Jira
Servicenow
自动化测试 ROD 代码质量管控
release 太痛苦，目前使用snapshot，没有使用ROD或者0 touch。每次部署的包很多，导致release coordinater 在收集包名和版本的时候非常痛苦，release当天耗时很长。
问题四，你希望 GSP 明年能应用哪些工程实践？
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
发布能不能尽量不需要研发参与。
service mesh
全自动化，稳定
Testing in devops，aim to "ROD"
release on demand
简单点 高效点不要太复杂
希望变成ECS的主人而不是客人ʘᴗʘ
希望简化部署流程
开设新技术的交流培训！
更加开放的开发工具使用
flink
ROD
优化编译部署环境和资源
LS pipeline执行速度需要更快
zero touch release
DDD？
CICD auto regression Cloud easy to access
Scrum tool Mockup tool
云存储（存储图片之类）
原先老项目，可不可以拆分为微服务。现有的数据查询验证客户端，非常卡顿
是否可以做到jira,ci/cd在一个页面上完成，打通所有链路
技术人员主导，而不是管理人员单方面制定
简化release流程
更简单的持续集成
建立代码评审委员会，提高GSP整体代码质量和设计水平 引入灰度发布
多一些BA帮助需求分析， ROD全面部署，包括部署以后的post check做成自动化。
从开放问题的词云我们大概能得到大家的核心关注点有几个方面：
- 构建高效敏捷的研发体系，利用好 JIRA 等管理工具
- 开发测试环境更稳定，希望更多项目能上 ECS
- 自动化测试和数据模拟更高效
- 缩短发布时间，简化 Release 流程
- ROD 和 0 touch Deploy 非常值得推广
- 开发人员尽量不用参与产品发布，期待更强的 DevOps 产品
- 拥抱变化，拥抱新技术，比如 ServiceMesh 和 MicroFrontend
在我看来，很多答案虽然就几个字，但是背后的声音在我脑海却久久回荡，这也许就是不善于表达的程序员们的共鸣吧。
感觉很固定，没有变化。
我们真的没有变化吗？也许对于疲于交付的部分项目组来说是吧，太忙碌会让我们失去创新和改进的动力。
总结
在敏捷软件研发理念中，我们都想要唾弃漫长的瀑布式研发流程，尽可能做到小步快步，持续迭代和改进。在年底留一点时间去回顾过去忙碌的 12 个月，是一个很好的反思机会。
总体而言，今年的调研报告可以让大家对我们 GSP 目前的整体软件工程水平有一个客观的认识，相信你可以在报告里找到自己团队的影子和改进的方向。
最后，祝大家新年快乐。明年，GSP 的工程文化和实践一定更优秀，因为那时的你，更优秀！