魏波

在流程的定义上，我们可以先简单后精细，简单才便于操作，精细才易于管理。流程是帮助我们更规范地做事情，目的是避免犯错误。

高效的研发过程应该具备“多线程”的特性，仿佛多条并行流淌的河流，上游是业务，中游的是产品，下游是技术，流量取决于业务，流速取决于产品和技术。将需求转化为项目，是一个复杂的过程。我们可定义了以下 10 个操作步骤，将需求转化为产品，将产品转换为项目，将项目顺利上线。

如果缺乏这些方面的建设，研发管理工作将变得痛苦且低效。我们应该做的是，从管理中追求效率，从效率中提升价值。

横向的“职能团队”比喻为“虚线团队”，将纵向的“项目团队”比喻为“实线团队”。以实线项目团队为主，以虚线职能团队为辅。横纵交错，形成一个优雅的矩阵，横向可扩展，纵向可延伸。如果研发团队规模大于 10 人，并且希望团队以最高效的方式实现项目交付，不妨采用以下“矩阵式”组织架构。该架构能让团队更加专注，而且整个架构的扩展性也非常强。根据团队成员专业技能的不同，可划分为多个职能团队，也称为“小分队”，例如：前端小分队、后端小分队、测试小分队、运维小分队等。横向关注人员成长，纵向关注项目落地。

员工说，方向总是变来变去。除了对步调和节奏的影响，对于多任务优先级的判断，也便没有了最核心的依据，此时要想在沟通中达成一致意见，沟通成本非常高，所以才有人反馈高效执行的第一反应就是“多做少说、决定干了就干，别讨论了”、“理解沟通”，换句话说，低效率的沟通也是执行的一大障碍，而目标不清晰必然会导致低效率沟通。而意愿的激发，却可以是立即起效的，所以我们看到大部分的管理者都在意愿的激发上做文章，比如发奖金、扣工资等，这就是我们经常说的员工激励。清晰的目标，本身就是激励，目标缺失的团队和员工，是很难有效激励的。

MT是 Mean Time 的缩写，意为平均时间。平均故障检测时间（MTTD）是系统出现故障到问题首次被发现的平均时间，用来衡量问题在被发现前存在的平均时长，可以用计算得出。

招商银行要提高研发质量和效能，可以从优化研发流程、加强人才管理、利用技术工具等多个方面入手，以下是具体措施：

对员工进行持续且系统的培训，包括新员工入职培训和现有员工的技能更新培训，内容涵盖研发技术知识、质量意识、工具使用等。：在项目开始之初，制定全面的质量管理计划，包括质量目标、质量标准、质量控制方法、质量改进策略以及质量沟通计划。：如浙商银行设计的质量分模型，包括开发质量、测试质量、合规质量、风险项等模块，通过多维度统计发现潜在问题。：南京银行通过功能点方法建立效能基线，关注功能点完成的数量、速度、质量和成本，以此提升工作效能。：实施持续改进计划，如PDCA循环，通过收集和分析数据，识别问题并制定改进措施。

银行科技部质量控制团队应以提升研发质量和效能为目标，通过完善体系、加强过程控制、引入自动化工具、团队建设和持续改进，确保系统稳定可靠，为银行业务发展提供有力支持。根据银行实际情况，制定涵盖需求、设计、开发、测试、部署等各环节的质量标准，明确各阶段的质量要求和验收标准。制定全面的测试计划，进行单元测试、集成测试、系统测试和验收测试，确保系统功能、性能和安全性达标。梳理现有流程，找出瓶颈，优化流程以提高效率和质量，如引入敏捷开发、持续集成和持续交付等方法。推行代码规范，进行代码审查，确保代码质量。

质量目标设定是质量管理的关键环节之一。质量目标分为长期和短期。长期目标是组织对产品质量的承诺，也是组织持续改进产品质量，传播质量文化，提高客户满意度的指南针；短期目标是组织在年内需求要达成的具体质量目标。如何设定软件研发质量目标？

1、人员2、流程3、制度4、工具5、模板

有原则性，当观点与团队不一致时，要在遵守基本原则的基础上争取对方的妥协，不能项目说怎样就跟着怎样。也不能死守成规，可在取得相同效果的情况下，简化流程，这就需要掌握好“度”。不需要精通各项知识，但要有基本的了解，比如不懂编码，但可以了解代码静态检查、代码走查等方面的知识。流程没有规定的不能强制要求执行，当然也不能放之不管，可在遵守质量管理基本原则的基础上提出建议，或者事后再给出答复。提出问题要有理有据，自己要先理解我们的流程为什么要这么要求，要想别人接受我们提出的问题，先要说服我们自己。

每日构建的保证：实际可执行、下关系的产品集成计划。每日构建的前提：对每日构建理论的理解和培训。每日构建的基础：开展单元测试和集成测试。每日构建的升华：自动化的回归测试。每日构建的精神：贵在坚持。

PMP项目管理以及软件测试技术的理论就是填充房子的砖石；CMMI软件能力成熟度模型好比房子的框架架构；盖好的房子就是软件质量管理系统；

因开发和维护的原因,要求实现开发人员同时在同一个软件模块上工作,同时对同一个代码部分做不同的修改,即使是跨地域分布的开发团队也能互不干扰,协同工作，而又不失去控制。基于软件存储库的版本控制功能,实现建立(build)过程的自动化。(7)变更请求管理。跟踪、管理开发过程中出现的缺陷(defect)、功能增强请求(RFE)或任务(task),加强沟通和协作,能够随时了解变更的状态。管理、计划软件的变更、软件的发布计划、使预先定制好的生命周期与相关的质量过程保持-致,项目经理能够随时清晰地了解项目的状态。

在软件开发过程中会有许多变更，如代码、配置、SQL、基线、构建版本、发布版本等变更。对于变更都要有一个控制机制，以保证所以变更都是可控的、可跟踪的、可重现的。对变更进行控制的机构称为变更控制委员会（change control board，CCB）。

基线标志软件开发过程的各个里程碑，任何配置项，一旦形成文档并审核通过，即形成一个基线，他标志开发过程的一个阶段的结束。对于已经成为基线的配置项，虽然可以修复，但必须按照一个特殊的、正式的过程进行评估以确认每一处修改。他提供了一个正式标志，随后的工作基于这个标志进行，并且只有授权后才能变更这个标志。建议一个初始基线后，以后每次对他进行的变更都将记录为一个差值，直到建成下一个基线。已经正式通过审核的某产品，他可以作为进一步开发的基础，并只能通过正式的变化控制过程改变。

设定了开发人员对软件基准库的存取权限，保证开发过程的安全可控。如开发库，开发者对自己的文件库有读写权限，无删除权限；如基线受控库，配置管理员有读写权限，开发人员只有读权限；如产品受控库，只有项目负责人和配置管理员有读写权限。：是配置管理的基本要求，使得组织在任何时候可以获得配置项的任何一个版本。配置控制是配置管理的核心工作。：保证了提交给客户的软件产品是完整的、正确的。：为软件产品变更提供了一个明确的流程。

软件配置管理（SCM）就是管理软件的变化。

质量成本是什么？质量成本包括：保证成本、损失成本。

质量改进

软件质量指标1、功能性质量指标2、可用性质量指标3、可靠性质量指标4、性能的质量指标5、可维护性的质量指标6、可移植性的质量指标

大项目或复杂问题的实施和解决，需要按照系统工程学理论进行，以系统的方法完整、全面的分析，而不是零星的处理问题，沿着逻辑推理的路径，去解决哪些原本靠直觉判断处理的问题。

1、对用户重要的属性有：2、对开发者重要的属性

软件缺陷由许多原因造成，如果把这些缺陷按照整个软件研发周期归纳起来，统计发现，软件研发周期：需求文档->需求规格说明书->设计文档->编码->测试->投产。软件产品在哪个阶段容易产生缺陷。是软件存在缺陷最多的地方。

软件缺陷是计算机系统或程序中存在的任何一种破坏正常运行能力的问题或错误，或隐藏的功能缺陷或瑕疵。缺陷会导致软件产品在某种程度上不能满足用户的需求。从产品内部看，软件缺陷是软件产品开发或维护过程中存在的错误等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。软件缺陷是软件产品中存在的问题，最终表现为用户需求功能没有完全实现，不能满足用户需求。

迭代模型描述软件产品的不同阶段是按产品深度或细化的程度来划分。先将产品的整个框架建立起来，在系统初期，已经具有用户需要的全部功能，然后不断细化和完善已有功能。增量模型和迭代模型两者最终的目标一致，都是为了实现一个功能完善、高质量、稳定的产品。

（1）需求分析和功能设计对应验收测试。在需求分析、产品功能设计的同时，测试人员就可以阅读、审查需求分析的结果，从而了解产品的设计特点、用户真正需求，确定测试目标，准备测试用例并策划测试活动。（3）当系统人员在做详细设计时，测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时设计功能、新特征等方面的测试用例，完善测试计划，并基于这些测试用例开发测试脚本。（2）当系统设计人员在做系统设计时，测试人员可以了解系统是如何实现的，基于什么平台，这样可以设计系统的测试方案和测试计划，并事先准备测试环境。

质量发展过程

产品质量是经过一个过程而形成，这个过程是产品的生命周期。

能够满足国家或行业标准、产品规范的要求体现了符合性质量概念。他以“符合”现行标准的程度作为衡量依据，但是“规格”和“标准”有先进和落后之分，过去认为是先进，现在可能落后了。同时，“规格”和“标准”不可能将客户的各种需求和期望都体现出来，特别是隐含的需求和期望。他以适用客户需求的程度作为衡量的依据。该概念要求人们从使用要求和满足程度两个方面理解质量的实质。这一概念既反映了要符合的标准要求，也反映了要满足客户的需求。随着经济的发展和社会的进步，人们的质量的需求不断提高，质量的概念也不断发展。

2、NASA（美国国家宇航局）：生命攸关，飞行中必须接近零缺陷，可靠性>99.999%；4、Motorola（摩托罗拉）：需要达到六西格玛管理标准，走在竞争对手前面；1、微软：软件质量只要好到能使大量的产品卖给顾客；3、合同承包商：满足合同的要求和规格；

提倡以终为始的思维，即当目标确定下来，再将目标拆解为小目标，转化为切实可行的动作，就不容易迷失在日常繁琐的工作中。比如在常规工作中，有哪些环节可以优化，可以通过工具来提效，有哪些文档已经有同事整理过了，是可以拿来即用的？熟话说强扭的瓜不甜，如果A和B的目标相差十万八千里，但A又依赖B提供资源，如果A跪求B注定不是长久之计。(1)季末和年末是老板复盘项目，并向大老板汇报进度的关键节点，也往往是下面最忙的时候，比如拉取各维度数据，做数据分析，看与OKR的差距，再基于现状以数据为依托，提出下一步推进的建议。

软件生命周期中每个阶段都有风险，那就通过质量门禁在每个环节设定准入准出标准，降低风险流转到下一环节带来的影响。参与项目的每个人技术能力、工作习惯、理解能力各不相同，那就推动质量内建在团队中落地，通过流程规范和卡点确保工作在执行过程中的满足标准。测试环境不稳定，设计和编码阶段存在风险，那就通过测试左移来推动单元测试、code review、分支管理更好的执行。打包部署线上发布存在不足，那就通过测试右移完善监控体系，制定线上巡检和防资损机制，主导复盘和持续迭代优化。

2022年研发效能实践案例智库集：Docs

L0：手工批量交付、手工运维，这是零能力的DevOps阶段，其服务能力完全取决于开发者个人，业务交付质量普遍不高，随着业务的发展和团队规模的变大会遇到各类问题，通常会首先寻求工具的帮助。 L1：手工为主、工具辅助的批量交付和运维，这个阶段开始引入自动化工具来辅助进行运维、发布等工作，通常已经有了服务化的基础，基础设施已经部分上云，并通过引入开源工具或自建搭建了一些完成特定诉求的工具，但这些工具往往还是孤岛，没有联系起来，业务、开发、运维间采用定期同步的方式，需求的交付还是批量式的。

小型测试：针对单个函数的测试，关注其内部逻辑，模拟所有需要的服务。可以带来优秀的代码质量、良好的异常处理和优雅的错误报告。Google看到测试领域中这种“百家争鸣”的现象后，创立了自己的命名方式，将测试分为。，而单元测试是小型或中型测试的具体实现形式。中型测试：验证两个或多个指定模拟应用之间的交互。小型测试、中型测试和大型测试。

用户主动的把数据上传到后台以换取应用服务，这一阶段叫“数据找应用”。这一模式催生了IT的繁荣，但也有很多问题，比如大数据杀熟，二选一等现象；上世纪网络尚未普及时，数据是静止的，而应用程序必须通过渠道交给用户才能发挥作用，这一阶段叫“应用找数据”。移动的一方总是弱势，比如开发者，他们无法阻止软件通过非法渠道流出，低价供给用户。1）有独立的数据服务商，用户可以从中自由选择，数据不上传到应用后台，而是由数据服务商代为托管。2）应用必须获得用户授权，数据服务商才会开放数据的相应权限。...