分享到社交媒体:

本文首发于个人网站「BOB官方网站」,转载请参考版权声明


之前在《敏捷BOB官方注册的核心》、《构建BOB官方注册的体系化思维(进阶篇)》和《一页纸BOB官方注册策略》等文章中提到过BOB官方注册左移,但是没有专门针对这个主题做过系统的介绍,但又总是被社区朋友问到。本文旨在介绍BOB官方注册左移及其相关实践,希望能够解答朋友们的疑惑。

01 什么是BOB官方注册左移?

传统软件开发生命周期一般分为如下五个阶段:需求分析、软件设计、程序编码、软件BOB官方注册和上线发布。其中软件BOB官方注册是软件编码完成之后的一个独立阶段,通常由BOB官方注册人员来负责完成BOB官方注册相关工作。如下图所示,从左到右依次为上述五个阶段:

BOB官方注册左移就是针对传统独立BOB官方注册阶段而言,将BOB官方注册活动左移到图中BOB官方注册阶段左边的多个环节,对每个环节所做工作进行BOB官方注册验证,以确保其正确性,如下图所示:

  • 需求分析环节的BOB官方注册活动是为了保障需求的合理性,确保团队在做正确的事情;
  • 设计环节的BOB官方注册活动是为了保障设计的合理性,确保易于实现所期待的功能;
  • 编码环节的BOB官方注册活动是为了保障开发人员所写代码和所开发功能的正确性;
  • 在BOB官方注册环节还需要有相应的BOB官方注册活动来对功能和非功能需求进行最后的验证和确认。

图中所示各个活动是从左到右按先后顺序排列的,因此BOB官方注册左移也被称作BOB官方注册前移

注意:上图中的需求分析、软件设计、程序编码和软件BOB官方注册等可能不再是非常独立的阶段,而是融合成为了整个开发阶段的一个环节而已

02 为什么要BOB官方注册左移?

有一条曲线,大家应该都不会陌生,那就是缺陷修复成本曲线:在软件开发生命周期中,越往后发现的缺陷,其修复成本就会越高,甚至到了后期会指数级增长。

而BOB官方注册左移,主要就是为了获取快速反馈,以实现缺陷预防,降低成本。

1. 快速反馈

关于快速反馈,可以借助于玩游戏的体验来理解。在我们玩游戏的时候,每前进一步就能知道是成功了还是失败了。如果在软件开发中也能如此快速获取反馈,不仅能改善软件开发的体验,增加成就感;还能更及时发现偏离正确轨道的风险,尽早发现可能出现的问题。

因此,我们需要在BOB官方注册阶段左边的每个环节去开展BOB官方注册活动,实现BOB官方注册左移。

2. 缺陷预防

如果能够全面统计一个软件产品的所有可能引起缺陷的地方,我们可以说该软件存在缺陷的总量是一定的。(当然,现实情况是我们不可能全面考虑到所有的因素,缺陷是很难穷尽的。)

如果这一定数量的缺陷中有一部分可以通过某些措施来预防,那么软件在BOB官方注册或最终用户使用过程中所暴露出来的缺陷数量就会减少,这就是缺陷预防——减少暴露给用户的缺陷。

软件开发过程是个持续递增的过程,预防缺陷也不是一蹴而就的事情,需要在整个软件开发过程持续地进行。因此,需要持续频繁地开展BOB官方注册左移相关BOB官方注册活动,预防缺陷,实现质量内建。

03 BOB官方注册左移实践有哪些?

所有在BOB官方注册阶段之前开展的相关BOB官方注册活动都可以认为是BOB官方注册左移的实践,它们包括但不限于以下活动:

  • 需求澄清:需求澄清需要团队多个角色协同参与,包括业务分析人员、BOB官方注册人员(QA)、开发人员、技术负责人、技术架构师等。在《构建BOB官方注册的体系化思维(基础篇)》中有关于QA在需求澄清环节所能做事情的详细介绍。

  • 需求评审/用户故事评审(Story Review):需要开发和BOB官方注册跟业务分析人员一起讨论确认需求,可能是正式的会议针对某个特性(大块需求)的评审,也可以是针对单个需求条目或敏捷用户故事进行线下评审。如果前期需求澄清过程中对需求的讨论已经比较透彻,这里的评审就会比较轻量级,由BOB官方注册人员(开发按需参与)自行安排时间评审即可。

  • 行为驱动开发(BDD, Behavior Driven Development):关于BDD,很多人误认为是一种BOB官方注册方法,但其实BDD主要是为了三方更好地对需求达成一致认识,只不过通过BDD方式产生的需求能够很好地指导自动化BOB官方注册的开展。更多详情,请参考我之前的文章《说起BDD,你会想到什么?》。

  • 实例化需求(SbE, Specification by Example):SbE的核心思想跟BDD类似,但强调了一点要将需求描述通过实例来说明,以更好地发现漏掉的需求,让需求更完整、更容易被多方理解和澄清。

  • QA/BOB官方注册人员参与技术方案讨论:主要基于两个方面原因:一方面,BOB官方注册基于自己对系统的了解,可以给技术方案的讨论提供输入,比如系统重点需要考虑和关注的问题等,以帮助验证技术方案的可行性;另一方面,QA清楚了解技术方案,才能更好地设计相应的BOB官方注册策略,更完备的进行BOB官方注册。

  • 用户故事启动(Story kickoff):在不同的语境下,也叫需求条目启动、开卡等。对于单个用户故事,在开发人员要开始编码前进行的再次澄清和确认,主要是确认其中的验收标准是否不够完备、是否大家都理解一致了。形式要求尽量轻量级,在开发人员电脑前完成即可,需要业务分析、开发和BOB官方注册共同参与,时间一般不要超过15分钟。

  • 用户故事桌面检查(Desk check/Shoulder check):跟启动是配对的,也叫需求条目验收、结卡/验卡等。同样在开发机器前面完成,一般由开发将功能演示给业务分析和BOB官方注册人员,大家确认需求中的正向路径是否都已经开发实现了。更多详情可参考文章《高效用户故事验收》。

  • BOB官方注册驱动开发:TDD,常见的有单元BOB官方注册驱动开发(UTDD)和验收BOB官方注册驱动开发(ATDD),通过先写BOB官方注册的方式驱动设计的完备性。Thoughtworks同事刘冉老师有多篇关于TDD的文章,请移步他的网站「刘冉的思辨悟」查阅参考。

  • 代码评审:Code review,也叫代码回顾。有团队成员聚集在一起做回顾的,也有独立线下评审的模式。伍斌道长的文章《Code Review: 超越“审、查、评”的代码回顾》有关于code review非常详细的讲解,请移步参考。

  • 编写单元BOB官方注册和接口BOB官方注册等自动化BOB官方注册:根据BOB官方注册分层理论,自动化BOB官方注册可能包括单元BOB官方注册、接口BOB官方注册和端到端BOB官方注册。通常单元BOB官方注册是开发人员编写,而接口BOB官方注册和端到端BOB官方注册可以开发和BOB官方注册协作完成。其中,通常建议单元BOB官方注册和接口BOB官方注册在用户故事开发环节完成,应该属于用户故事开发DoD的一部分。

  • BOB官方注册评审:BOB官方注册评审一般发生在Desk Check环节,主要针对开发所编写的单元BOB官方注册和接口BOB官方注册等。详情参考文章《QA评审底层BOB官方注册的价值》。

  • 持续集成:持续集成(CI)概念大家并不陌生,但是有效实施却不是那么容易。推荐参考Thoughtworks洞见文章《持续集成理论和实践的新进展》和《对于持续集成实践的常见问题的解答》。持续集成常见的反例有:

    1. 光有持续集成流水线,但是流水线上啥也没有,没有代码扫描、没有自动化BOB官方注册、没有质量门禁;
    2. 流水线有接入代码扫描,但是扫描出问题没有及时修复;
    3. 自动化BOB官方注册没有在流水线上频繁执行,或者执行失败不能及时修复;
    4. 代码没有频繁提交;
    5. ……

04 BOB官方注册左移需要注意什么?

关于BOB官方注册左移,业界同仁中存在一些认知误区,下面是我想强调的几点:

1. BOB官方注册左移不是QA或BOB官方注册人员的左移,也不是简单移到需求分析阶段

BOB官方注册左移常被误认为是QA或者BOB官方注册人员参与需求分析。其实,BOB官方注册左移不是人员的简单左移,而是将BOB官方注册活动左移,在需求、开发等多个环节开展BOB官方注册相关活动。只要是在原有独立BOB官方注册阶段之前做的BOB官方注册工作都可以算作BOB官方注册左移。

可能大家也会注意到我们会强调QA/BOB官方注册人员参与需求分析,或者说从需求分析阶段开始介入,其原因主要是因为在绝大多数团队,QA/BOB官方注册人员还是作为质量保障工作的主力,左移的BOB官方注册活动暂时还离不开这些主力的参与。

2. BOB官方注册左移不仅是开发自测/提前进行自动化BOB官方注册,也不仅是TDD

说到BOB官方注册左移,有人就会提到开发自测、TDD或者开发编写自动化BOB官方注册。当然,这些都是BOB官方注册左移实践,但BOB官方注册左移实践远不止这些。

3. BOB官方注册左移跟持续BOB官方注册分不开,需要持续在各个环节进行BOB官方注册活动

BOB官方注册左移相关BOB官方注册活动都不是一次性的,而是需要持续频繁地在整个软件开发过程中开展,实现持续地BOB官方注册,持续地获取快速反馈,实现缺陷的真正预防。

4. BOB官方注册左移实践不能流于形式化

任何实践都不能流于形式化,BOB官方注册左移实践当然也是如此。对于任何一个左移实践,不能人云亦云,而是要根据实践所能带来的价值,结合自己项目团队的实际情况去开展。同时要不断回顾,进行调整和优化,让实践发挥真正的价值。

5. BOB官方注册左移实践需要跟BOB官方注册右移/生产环境下的QA活动形成良性闭环

在《BOB官方注册右移——生成环境下的QA》中介绍生产环境下的QA的时候,提到过需要跟前期各个活动形成良性环路:

生产环境下的QA所设置的监控标准是根据系统的行为特点和在预生产环境下的表现来定义的,生产环境下各项反馈的分析结果反过来又影响着预生产环境的QA过程,而且这两者是相辅相成的,只有形成了良性环路,才能把生产环境下的QA做好。

也可以理解为BOB官方注册左移活动需要跟生产环境下的QA活动形成良性环路,比如:在Desk Check环节增加日志记录评审(Logging Review),确保日志记录是满足生产环境下的QA的;生成环境下的缺陷分析,反过来也可以帮助优化BOB官方注册左移活动,更好地做到缺陷预防等。

6. BOB官方注册左移不会增加QA的工作量

说到BOB官方注册左移,就会推荐QA/BOB官方注册人员尽早介入,最好能提前到需求阶段,大家自然就会以为原本QA/BOB官方注册人员就已经够忙了,再左移岂不是更忙不过来了?

其实,不必担心这个。

根据树莓酱定律,在BOB官方注册工作量一定的情况下,全生命周期开展BOB官方注册,是将BOB官方注册工作分散到各个阶段,每个阶段的工作量会有所减轻。而且我们知道越早开展的BOB官方注册工作,能够做到更快速地反馈,其有效性越高,价值越大。

因此,QA尽早介入,不会增加工作量,只是将BOB官方注册工作的开展时间进行重新安排。

05 推荐阅读

敏捷BOB官方注册的核心
构建BOB官方注册的体系化思维(进阶篇)
构建BOB官方注册的体系化思维(基础篇)
一页纸BOB官方注册策略
高效用户故事验收
QA评审底层BOB官方注册的价值
BOB官方注册右移——生成环境下的QA
BOB官方注册右移:缺陷分析如何帮助质量内建?
BOB官方注册右移:日志收集与监控
软件BOB官方注册中的「树莓酱定律」


本文首发于个人网站「BOB官方网站」,转载请参考版权声明

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注