2022年度系列工作总结「国内软件质量调查问卷」针对于本年度软件质量分析总结报告

Posted 2022-12-19 洛神灬殇

前提背景

针对于目前的软件行业而言，软件的质量目前越来越被大家所在关注，慢慢的QA以及SQA的角色也变得愈加重要。接下来我就针对于我司（XXX）的相关的实际开发情况对应的【2022年国内软件质量调查问卷】，为大家梳理和归纳一下目前存在的问题，想看看您或您所在的团队（公司）是否也存在着此类问题呢？好我们废话不多说，直接进入主题。

团队信息介绍

调研总结跨度

我从事于目前的这家公司，时间的跨度是【2021-08-04】~ 【至今（2022-12-18】，已经工作了慢慢接近一年半左右了。

技术行业领域

公司从事相关的【呼叫中心】以及【智能语音机器人】的相关领域的开发行业，目前做的市场份额还是不错的，属于一家跨国的创业型公司。感兴趣的小伙伴欢迎与我私信交流哈。

团队大致规模

目前我所属的团队的规模是Java应用后端开发组，分布在三个城市地区，国内外都有，大概20~30人之间的规模，针对于我一个人去管理整体的进度还是比较的游刃有余的。但是经历了快速迭代的节奏之后暴漏出了很多的问题。

版本迭代与质量的关系

从事于软件开发行业，相信版本的快速迭代是难免的，无论是领导要求还是客户要求、甚至是老板要求的都需要快速的落地，但是落地是好落地但是质量如何良好把控就成了一个难题。

团队目前主要采用什么开发模式

由于团队数量人数并不是很多，所以目前采用的是【敏捷中的Scrum框架】 + 【瀑布模式】共存的混合模式，进行驱动我们的业务开发节奏和计划。对应的角色我承担的是Team Leader及部分的Master的角色。不了解的小伙伴们可以直接去定位到【Scrum的模式的额外科普】这一小节。

• 每个团队都有负责人 作为JM作为对应的需求迭代管理者
• 每个团队都有负责的领域、并且每个人都有对应的负责功能项
• 每个JM都可以对应N个产品所属人。

产品交付的周期多长

就我们目前的开发进度和迭代周期而言如下所示

主要版本的迭代周期	小版本周期	紧急补丁包（hotfix/patch）	备注
一个月	一周或两周	<=天	目前的版本迭代速度偏快了

总体我们经历了从入职到现在大版本从现在的版本的范围是1.35 ~ 1.43版本（进行中），这milestone大概是到2023年1月中旬左右。到年底估计会达到1.43.1的这个版本。

• 目前大致版本经历了8个大版本（存在延迟以及进度问题以及一些其他可控因素（疫情）），
• 小版本不计其数，据我所知大致100个左右。
• hotfix以及patch更多了，估计150个以上。

如何保证软件需求质量？

对于CSDN给出的选项我大致排了一个优先级顺序，优先级越高我们需要重视的力度就会高！小伙伴们看看你们的顺序是否和我的保持一致？

• 有明确的需求规范
• 在会议上集中评审
• 有SQA这样角色的专人检查
• 严格的需求评审流程
• 需求管理系统对基线、变更等审核、管理
• 完善的需求工程体系其他

我们的排序就是一下的流程顺序

1. 其中我最重视的两项便是【有SQA这样角色的专人检查】，因为这项算是最后兜底以及质量把控的最重要一项，算是万无一失的双保险吧。

2. 【严格的需求评审流程】需求评审的重要程度，很多人觉得比较奇怪，其实非常好的需求评审，让我们对需求的理解有很大帮助，有一句话叫做好的"良好的开局，就是成功的一半！"，对吧！随意只有需求明确了才能造就好的开端以及正确的需求方向。事实上我们很多的时候都是需求不明确导致研发的开发方向出现了偏差，以及需求总是频繁修改，导致代码的不一致和健壮性不好。

3. 【需求管理系统对基线、变更等审核、管理】，当出现多个版本的需求的迭代开发的时候，经常会出现混乱，导致出现了版本合并的问题，引起后面上线所出现的线上紧急问题和bug。

需求质量是重中之重

CSDN基于的选项

• 没有规范的需求文档模板
• 需求文档描述模糊、细化不够需求文档
• 缺少典型的应用场景、用例(USE CASE)
• 需求文档缺少验收标准(未实施AT DD)
• 需求评审走过场(流于形式)
• 需求变更频繁
• 需求变更缺乏有效的控制
• 需求文档不能及时更新
• 需求文档缺少系统来跟踪、管理其他

从我的经验之谈和目前的状况我们公司目前存在最大的问题就是我上面几个问题：

我把上面这几个称之为造成需求开发版本出现失误的四大“罪状”。

首当其冲

【需求文档描述模糊、细化不够需求文档】，知道什么意思吗？“以己昏昏，使人昭昭”，很多产品自己都是蒙圈的状态，然后很多细节都不写，我们知道开发程序最重视的就是细节，而产品自己都不清晰，还玩什么呢！所以未来需求文档的质量一定要提出来把控好，把质量抓起来！

不够重视

【需求评审走过场(流于形式)】往往就是对于日程的开发工作中，最不受大家重视的了，有问题只希望自己去猜测需求，不在真正有意义的场景去处理和解决，就是程序员的很大的通病哦，至少非常在我们这边还是很严重的，需求评审大家只依赖于产品的思想去发挥，不过需求隐藏在表面之下的问题，依然无法被我们发觉，后果就是导致bug特别多，而且需求澄清也出现了少许问题，最后导致质量不断地下滑，这一切的一切很可能就是当初我们没有做好前提工作所引发的。所以在软件开发的每一个环节都应该努力重视哦！

因小失大

• 需求变更频繁
• 需求变更缺乏有效的控制

如果你是一个程序员，我相信如果要问到你最讨厌的行为一定是上面说的这两个点，总是在不断的变更需求，但是我觉得对需求变更是正常的，但是过于频繁就是有问题的了，任何事情都要有一个度，所以对于需求变更，要考虑三个问题：

1. 时间问题

如果出现在封边以及马上上线的时候，那么就要慎重考虑了，是否修改的范围会影响很多地方，还有就是，是否需要重新评审方案等等，时间是否来得及，会不会影响上线时间等等。

2. 紧急和重要问题

是否属于必须要上或者要改的点，如果不是特别紧急和重要的问题，最好还是保持不变，稳健起见，是否通过hotfix进行上线补丁。

3. 影响范围

上面第一点【时间问题】，就是影响范围了，担心会导致其他问题的崩盘（改了这边，导致其他地方全面崩盘！因小失大）

希望大家有效的把控【 需求变更缺乏有效的控制】，可以根据我一上的这三点顺序来进行确认和评估是否一定要做出需求变更！

如何保证设计质量

• 培养、设置能力很强的架构师设计规范
• 选用成熟的设计模式
• 加强设计评审(开发人员)
• 邀请测试人员参加设计评审
• 邀请运维人员参加设计
• 评审原型(仿真)验证

---

面向于如何保证质量设计，我主要面向于【培养、设置能力很强的架构师设计规范】、【加强设计评审(开发人员)】和【邀请测试人员参加设计评审】这几个方面。

• 主要面向于对于开发角度

加强设计评审(开发人员)，提高对应的开发人员对需求的理解和吃透细节。

• 主要面向于对于测试角度

邀请测试人员参加设计评审，提高测试的测试质量和能量水平。

• 主要面向于对于规划角度

培养、设置能力很强的架构师设计规范

明年(2023年)软件质量改进，会侧重哪几个方面

• 团队人员能力建设(培训)上流程改进上
• 重新设计或优化架构代码重构
• 研发基础设施建设质量文化建设

1. 接下来就是我2023年的未来计划，大力加强重新设计以及优化架构，因为未来我们的最大的困难和目标就是性能和代码的鲁棒性，所以这个是我们的首要目标。

2. 团队管理的规划管理技术，对于团队人员能力建设(培训)上流程改进上，进行规划新的目标和KPI计划。

3. 研发基础设施建设质量文化建设，建立中台化服务机制，使得开发人员重点精力体现在【需求的开发迭代之中】，针对于功能化的功能，都交由中台化服务区支持就好了。并且叫单独划分团队去建立中台化服务。

---

Scrum的模式的额外科普

Scrum中的人员分为3个角色：产品所有者（Product Owner）, Scrum Master，开发团队(Team)。

• 产品所有者：定义所有产品功能，决定产品发布的内容以及日期，对产品的投入产出负责，根据市场变化对需要开发的功能排列优先顺序，合理地调整产品功能和迭代顺序，认同或者拒绝迭代的交付。
• ScrumMaster ：ScrumMaster不是项目经理，他没有分配任务的权力，没有考核的权力，没有下命令的权力，他指导项目组的成员按照Scrum的原则、方法做事情，领导团队完成Scrum的实践以及体现其价值，排除团队遇到的困难，确保团队胜任其工作，并保持高效的生产率，使得团队紧密合作，使得团队个人具有多方面职能的工作能力，保护团队不受到外来无端影响。
• 开发团队：经典团队拥有 5-9 人，团队成员包含程序员、测试员、用户体验设计等等，团队关系在一个迭代中应该是固定的，个人的职能可以在新迭代开始时发生调整，团队自我组织和管理（自组织，自驱动），团队成员都全职工作。