Page 41 - 《软件学报》2021年第5期

崔海涛 等:面向微服务架构的开发组织适应性评估框架 1265

Table 4 Details of the questionnaire
表 4 问卷的详细信息
参与者基本信息
Q1. 您从事微服务架构开发多久了? Q2. 您在公司中担任的主要角色是什么?
项目的基本信息
Q3. 您的公司是如何使用微服务架构的? Q4. 您目前开发的微服务项目所属领域是?
Q5. 项目完成需要多长时间?(如果项目仍在进行,请勾选计划完成时间)?
阶段 1:评估框架中的 7 个概念在实际开发中进行设计的必要性
自治团队: 通信:
Q6. 高度自治的团队(团队是松散耦合的, Q7. 良好的沟通结构(团队内部和
每个微服务团队可以独立开发和交付) 不同团队之间有效的沟通)
组织结构:
Q8. 与微服务相匹配的组织结构(合适的 组织文化:
Q9. 优秀的组织文化
团队数量和规模,完善的人员配置等)
DevOps: 开发人员:
Q10. 与 DevOps 紧密结合(实现持续监控,持续交付等) Q11. 由经验丰富和技能娴熟的开发人员构建团队
技术/工具:
Q12. 合理选择开发工具和技术
阶段 2:评估框架中建议的有效性
(基于 Q6,Q7) (基于 Q7)
Q13. 建议 1:在开发中加入相关的会议(技术协调会议, Q14. 建议 2:在不同团队间加入团队协调员,
依赖协调会议等),以保证项目整体的同步性 保证不同团队间信息传递的正确性
(基于 Q8,Q10)
(基于 Q8,Q10) Q16. 建议 4:每个微服务团队都应该包括
Q15. 建议 3:每个微服务的团队规模建议在 6~7 人左右
开发人员,运维人员和质量保证人员
(基于 Q9) (基于 Q11)
Q17. 建议 5:公司需要考虑团队成员对微服务的接受 Q18. 建议 6:开发前,对开发人员进行
程度,这种接受体现在团队成员是否愿意放弃
原有的工作团队,而有意愿进入新的微服务团队 技能和微服务基础知识的培训
(基于 Q12)
Q20. 建议 8:微服务团队需要有对技术和工具选择的
(基于 Q11) 自主权,但公司必须给出一个可供选择的技术和
Q19. 建议 7:确保每个微服务团队中都包含 工具的清单. (目的在于团队可以选择最适合
有微服务开发经验的人
他们的技术和工具,同时又避免技术和工具
过量使用导致的可维护性等问题)
开放式问题
Q21. 在实际工作中,公司会从哪些方面评估开发组织是否适应微服务?
以及有哪些具体的措施来调整开发组织?请留下您的宝贵意见,十分感谢!

2.3.2 行业访谈
A) 访谈设计
为了进一步验证本文所提出的适应性评估框架,同时为了结合工业界的开发经验来细化框架中的建议以
帮助公司更直接的采用,本文设计了一次微服务行业内的访谈.访谈的问题提纲围绕框架进行设计,同时由一位
在访谈方面有丰富经验的作者进行审阅.通过对问题提纲的 3 次修改之后,最终设计出的访谈主要包括以下 3
个部分.
1) 热身问题:专家的基本信息和所负责项目的基本信息;
2) 探讨框架的内容:我们将适应性评估框架和围绕框架所设计的问题提前发送给参与者,让他们有足够
的时间熟悉框架内容并思考问题回复;
3) 实际开发中遇见的组织问题:收集参与者在实际开发中遇见的组织方面的问题以及具体的解决方案.
B) 识别访谈参与者
为了识别有微服务开发经验的参与者保证数据来源的可靠性,本文直接面向国内正在使用微服务架构进
行开发的知名公司,并成功邀请到了来自 3 家公司的 4 位微服务领域的专家.
C) 访谈结果