专栏首页Teobler的开发日记小步发布、验收测试和完整团队
原创

小步发布、验收测试和完整团队

上一篇文章中我们花比较大的篇幅介绍了敏捷业务实践中的计划游戏,在这篇文章中我们将介绍介绍生命之环中外围剩下的三个业务实践。

life-cycle

小步发布

ci_cd_circle

小步发布这一业务实践建议开发团队应该尽可能频繁地发布软件。在敏捷早期,这个时间节点大概是“一到两个月”。现如今,发布周期的目标是无限短,即持续交付:每次代码更改后就将代码发布到生产环境中。

虽然缩短的是发布周期,但其实小步发布这个实践的真正目的在于缩短所有周期。但是由于源代码管理的历史原因,缩短周期这件事情从根本上就会面临很大的历史惯性。这一切要从软件行业早期开始讲起。

纸带打孔时期

在软件行业刚刚兴起的时候,所有的”代码“是储存在打孔纸卡上的。一张纸带可以容纳 80 个字符,代表一行程序。程序本身由这样一张张的纸卡组成,最终整个程序将是一大箱成捆的纸卡。

dakong

这些纸卡被存放在柜子里,如果有人想修改代码,这需要签出源代码,在获得所有者的许可后,便可以从柜子里清点出要修改的那部分代码 - 这是真正的签出源代码。

这时由于你从物理角度获得了源代码,意味着只有你有资格修改这部分代码,其他人都碰不到它。只有等你完成了修改,将源代码存回柜子里,其他人才有机会修改。

这个时间周期不固定,可能是几天、几周甚至是几个月。

磁带时期

tape_storage

后来随着科技的发展,代码开始存储在磁带上,除了容量更大,也更容易被复制了。此时修改代码变成了:

  1. 从母带架上取出母带。
  2. 将要编辑的代码从母带上复制到你自己的工作磁带。
  3. 放回母带,其他人可以继续复制。
  4. 将彩色大头钉固定在你正在编辑的模块旁边的签出板上,一个人使用一种单独的颜色(然后人多就会用完所有颜色)。
  5. 在你自己的工作磁带上进行编辑、编译和测试。
  6. 再次取出母带。
  7. 将更改完成的模块从工作磁带赋值回母带中。
  8. 将新的母带放到母带架上。
  9. 从签出板上取回你的大头钉。

这时的好处是你不再在物理上拥有源代码,这代表着别人可以同时修改不同的模块,但这也就意味着别人可以不遵守约定,偷偷修改你正在修改的模块。

这时的工作周期有一定的缩短,变成了几个小时、几天或者是几周。

磁盘和源代码管理系统的出现

再后来源代码的存储介质变成了磁盘,但是仍然使用大头钉的方式来标记谁在修改哪一模块的代码。然后真正的源代码管理工具出现了。

早期的其中一个源代码管理系统 Source Code Control System(SCCS)。SCCS 的行为与签出板一样,将模块以悲观锁(Pessimistic Lock)的方式锁定在磁盘上,防止别人编辑。

后来 SCCS 被 版本控制系统 RCS(Revision Control System) 取代,然后 RCS 又被并发版本系统 CVS(Concurrent Version System) 所取代。这些工具在进行微小改良的同时本质都没有改变 - 都是使用悲观锁来控制相应模块不发生冲突。

虽然此时的周期还是不短,但是磁盘允许我们极大地缩小模块的规模。模块的小型化有效地缩短了周期时间,因为模块越小,保持签出状态进行修改完成的时间就越短。

Subversion

Subversion(SVN) 与上述工具不同,其提供了乐观锁。这使得多个开发人员可以同时签出一个模块。SVN 工具会对此进行追踪,并自动将多人的更改合并到模块中。如果有冲突,则要求先解决冲突才允许签入代码。

这样的流程会大大缩短周期时间,使其缩短至编辑、编译和测试一系列小更改所需的时间。此时签出时间不在是制约周期时间的因素,主要因素变成了修改紧耦合代码所产生的冲突。

Git

如今我们使用 Git,此时已经没有签出时间这个概念了(当然,除了那些超大型的代码库)。程序员可以在任何时间提交对模块的任何修改。如果这些模块出现了冲突,程序员可以在任何时候来解决冲突。

充分解耦的小模块和快速的小步提交共同作用,使得周期时间可以缩短至几分钟。在此基础上覆盖以全面、运行快捷、几乎可以测试任何功能的自动化套件,你就具备了持续交付(Continuous Delivery, CD)的条件。

小步发布的目的不仅仅是为了缩短发布周期。为了实现缩短发布周期这个目的,大家就必须使自己的代码充分解耦,同时采用小步快速提交的策略,将自己的修改快速提交到代码库。而为了使得自己的小步修改是可工作的,又要求有一系列的测试套件来保证代码质量。

而为了缩短发布周期,组织需要打破发布和部署之间的耦合。最终,“是否要部署”只是一个业务决策,每一次决定部署,都已经变成了一次发布。

验收测试

atdd

最令人困惑的实践

验收测试这一敏捷实践的基本思想是:应该由业务方负责说明需求的规格。而问题恰恰出在规格说明上。

许多业务方认为这个词的意思是:我只需要随便比划两下,用几句含糊不清的话来描述我的需求,开发人员就应该自己能够找到所有的细节。而程序员们又希望业务方能够精确定义系统应该做什么,最好能够描述清楚每一个细节。

而我们所需要的其实是介于这两个极端之间的关系。规格说明从某种意义上来讲,本质是一种测试,比如:

当用户输入有效的用户名和密码,点击登录按钮,系统将跳转到欢迎界面。

这就是一个标准的规格说明,但仔细想想,这也是一个标准的测试用例,并且这个测试用例是可以被自动化的。

其实这个实践指的是:只要可行,系统的需求就应该写成自动化测试。虽然看起来简单,但这个实践是所有敏捷实践中最不被理解、使用最少,也最混乱的实践。下面这几个问题将为你揭晓为什么会有这样的情况:

首先是,谁来写这些测试呢?如果按照本节第一句话描述的基本思想来说,既然规格说明是业务方提出来的,那么是不是应该由业务方来写这些测试呢?

下一个问题是,大部分业务方其实并不具备编写代码的能力,编写代码不应该是程序员的工作吗?

但是如果是程序员来写这些测试的话,他们会以以技术的思维来写,并不会以业务的思维来写。这意味着这些测试除了他们自己谁也看不懂,因为里面充满了技术细节。所以这个问题还是推回给了业务方,应该由他们来编写。

但是如果由业务方来编写,他们可能采用与团队完全不相符的技术栈,这意味着我们得重写这些测试以符合我们的技术栈。

尝试解决

实践混乱,就会催生出一系列尝试解决混乱的工具和方法论。FitNesse、JBehave、SpecFlow 和 Cucumber 等工具就是程序员们开发出来为了解决这些问题的工具。它们尝试将这些自动化测试的技术面和业务面分开。由业务方编写测试的业务端,程序员编写粘合代码将这些测试和被测系统绑定起来。

虽然梦想是美好的,但是业务方很是不愿意参与进来,比起形式化的语言,他们更希望用人类的语言,来编写这些规格说明。

于是程序员又做了一步妥协,他们编写测试但希望业务方至少能够去阅读代码形式化的文档,并验证测试是否正确,但业务方更想吧这样的工作交给 QA。

行为驱动开发

BDD

在千禧年之后,丹·诺斯(Dan North) 尝试重新定义 TDD,他称之为 BDD(Behavior-Driven Development, 行为驱动开发)。他的目标是从测试中去掉技术术语,使测试让业务方看起来更讨喜。

BDD 的支持者建议,业务方可以不写测试,但是希望他们能够以一种形式化的、基于场景的语言(比如 Given-When-Then)来详细描述他们的系统,这样的语言对程序员编写测试也有巨大的价值。

合作与实践

既然大家都不愿意一个人完成所有的事情,那如果大家一起来呢?实践的目的没有改变,还是只要可行,系统的需求就应该写成自动化测试。但是方式应该是业务方编写形式化的测试来描述每个用户故事的行为,开发人员将这些测试自动化。

回到最开始的问题,谁来写?答案是业务分析师(BA)和 QA,至于为什么,我们会在稍后解释。他们需要在迭代的前半部分之前完成测试的编写,然后程序员完成故事的开发并将这些测试集成到持续构建(CI)中。只有完成了测试的编写并且代码通过了所有测试,故事才算完成。

业务分析师和 QA

业务分析师负责澄清和理解需求方的需求,然后负责说明功能的乐观途径(happy path),因为他们需要作为中间人在需求方和程序员之间做大量沟通,没有精力描述所有悲观途径(unhappy path)。

而 QA 的工作是写出所有悲观途径,他们是既了解业务又拥有很强技术的人。他们能够站在业务和用户的角度找出如何破坏系统的方法,同时他们还能了解程序员的思路,戳穿他们的“偷工减料”。

QA

这个实践完全改变了传统 QA 的工作职责,他们不再作为测试人员在项目末期把关,而是在前期定义规格;他们也不再在项目晚期提出关于错漏的反馈,而是提早给开发团队提供输入,预防错漏的发生。

这意味着 QA 需要承担相对于传统项目更大的压力。为了确保产品的质量,QA 需要在每一个迭代的全期做不同的工作,而不是仅仅在结尾进行测试,他们是系统是否可部署的“批准者”。

这样做有什么好处呢?

减少遗漏测试的可能性

传统测试人员会在项目尾声才开始测试,这意味着他们会成为项目部署的瓶颈,为了部署,他们需要尽快完成测试工作。同时这样的工作方式会让上游所有的日期推迟都堆到测试身上,假如程序员的工作延迟了一周,测试的工作就就少了一周,因为管理者不会因为程序员的推迟交付多给测试时间,上线日期是几乎不会改变的。

那么在这样的情况下,QA 会如何测试呢?很简单,加速,不测所有功能,只测试新的需求或者那些改变了的功能,放弃测试没有改变的功能。于是遗漏开始了,全量回归被放弃,期许下次能有时间全量测试,可是下次往往意味着永不

bug数即API

上述问题至少还有补救的办法,另一个将测试工作放在项目尾声的致命问题是,组织应该如何判断他们做好了自己的工作?很简单,发现的bug越多,他们做的就越好。以发现的bug数量来作为QA团队尽职尽责的证据。

于是,发现 bug 被认为是好事,且在一些偏激的组织内成为了 QA 团队的 kpi。

这样的问题或许在短期内不会致命,但是长此以往,组织内部一定会逐渐虚弱。

程序员

业务分析师和 QA 完成了测试的编写,但是他们并不运行这些测试。这个任务交给了程序员,程序员需要确保它们的代码通过所有的测试。此时形成了一种开发即测试的有趣局面。换句话说,程序员虽然在做开发的工作,其实他们也在做测试的工作,因为他们的代码通过了测试,这些刚实现的功能已经被测试过了。

这些测试会和开发过程中编写的单元测试一起被加入到持续构建中。每当一个程序员加入了新的模块,服务器会自动运行所有测试,而团队中的所有人都会关注这些运行,我们会在稍后的文章中有更详细的讨论。

完整团队

scrum_team

完整团队的事件最初被称为现场客户(On-Site Customer)。其理念是:用户和程序员之间的距离越短,交流就越好,开发就越快、越准确

这里的客户是一个隐喻,指的是理解用户需求并与开发团队共同工作的某个人或团队。在 Scrum 里这个人或团队被称为 产品负责人(Product Owner, PO),他负责选择故事、设置优先级并及时提供反馈。

后来这个实践被改名为完整团队。这是为了强调一个团队里不是只有客户和程序员。开发团队不应该由一个个职能部门组成,同一个团队中应该有客户、业务分析师、程序员、测试人员、经理等等。同时这些所有角色应该尽量处于同一个房间中。这个实践的目的是无限缩短这些角色之间的物理距离,打破只能壁垒。

这样可以极大地提高团队效率,消息不用层层传递,有相应的问题直接能够找到对应的角色进行解决,从问题发生、提出到开始讨论只有短短几秒钟。

而且团队坐在一起总会触发神秘力量。客户可以无意从程序员或测试人员屏幕上立马发现不对的东西;一场激烈讨论中,可能坐在旁边的另外一个角色本来就有正确答案;两个程序员对需求的描述被业务分析师发现与自己的想法不符......

需要注意的是,虽然这个实践一直在描述团队的行为,但这的确是一个业务实践,因为这个实践受益最大的是业务,当团队在同一地点时,业务运行会更加流畅。

远程办公的今天

在今天,日新月异的技术已经让远程办公成为了可能,特别是视频会议的兴起一定程度上弥补了物理上无法坐在一起办公的遗憾,甚至编译器已经让远程结对做到毫无延迟。

敏捷团队可以分散在各处吗?在之前这个答案是未知的,但经历了2020年的疫情,这个答案大概是肯定的。至少我们团队和我们各个办公室的团队做的都挺好,但这的确需要付出更多的精力和拿出更多的纪律和规则

可以肯定的是,这是可行的,但是如果大家都在同一个房间,我们可以做的更好。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 软件测试团队对产品验收的三步骤

    软件测试的最终目的是尽可能多的找出软件的缺陷,是开发人员和测试人员两大团体就可以决策的事情。但是对于产品的最终验收,那是可能除了软件测试团队外,整个公司所有团体...

    新梦想IT职业教育
  • 《硝烟中的Scrum和XP》第14章 我们怎样做测试

    yeedomliu
  • 创业公司项目管理中必踩的那些坑 | TAPD经验谈

     导读  “组织结构混乱”、“团队协作不透明”、“项目交付不及时”、“人员流动性大”…… 创业公司成长迅速,业务蓬勃发展,团队不断扩张。这本是令人高兴的事情,...

    TAPD敏捷研发
  • 《持续交付:发布可靠软件的系统方法》第5章 部署流水线

    yeedomliu
  • ​产品经理如何使用 CODING 进行项目规划

    CODING 为您的企业提供从概念到软件开发再到产品发布的全流程全周期软件研发管理,为您的研发团队提供全程助力,帮助研发团队捋清需求、不断迭代、快速反馈并能实时...

    CODING
  • 产品经理如何使用 CODING 进行项目规划

    随着数字化转型浪潮的开始,越来越多的企业开始使用信息化的管理系统取代传统办公工具。在转型的过程中最大的挑战之一就是如何给相应信息设置权限管理,确保不同职能部门的...

    CODING
  • 超有料!万字详解腾讯微服务平台 TSF 的敏捷开发流程

    ? ? 导读 相比传统的应用研发流程,以微服务架构为基础的研发团队更需要和依赖整体流程的敏捷属性。为了帮助更多将要或者正在以微服务为架构的项目,了解和解决诸多...

    腾讯云中间件团队
  • 详解IBM的大规模敏捷框架SAFe

    常规的敏捷框架适用于中小型项目团队,而且不具有扩展性。基于常规的敏捷框架,SAFe定义了一个可扩展的敏捷框架模型,它适用于大型多个团队的合作开发,可以提高团队之...

    PM吃瓜
  • 敏捷开始的一些个人感悟

    “小步快跑,快速迭代”这是我们听到的最多的关于敏捷开发的描述,关于个人工作经历中的实践,谈谈我的看法:

    Sahara
  • DevOps时代,测试该如何应对?

    DevOps的概念最早起源于2009年的欧洲,但由于当时配套技术和工具的匮乏,导致DevOps并没有迅速兴起。近几年随着云计算和大数据等新技术的高速发展以及微服...

    DevOps时代
  • 平台抗住日访问量 7 亿次,研发品控流程全公开

    产品质量是吸引和积攒用户的重要因素,业内不乏由微小Bug引起的灾难事故,对用户或公司造成巨大的损失。从业务角度,质量是产品口碑、市场、收益背后的助力;从技术角度...

    腾讯云开发TCB
  • 测试流程?项目管理流程?

    背景 工作五年了,一直是做测试。认识了很多人大牛,也接触到很多新人,从他们身上看到了很多,自己的过去,自己的未来(当然很多是自己达不到的高度)。 做这测试这一行...

    千往
  • 「敏捷测试」敏捷方法论:理解敏捷测试的完整指南

    事实上,根据VersionOne的敏捷状态报告,截至2018年,97%的组织以某种形式实践敏捷。 然而,受访者表示,这种采用在其组织中并不总是很普遍,这意味着在...

    首席架构师智库
  • 千人规模组织级 DevOps 演进的 9 个实践及技巧

    在 2018 年年底,我参与了某一个大型产品团队的 DevOps 转型。这个产品的团队分为三个组织:产品业务部门(50 多人),产品 IT 部门(250 多人)...

    顾宇
  • 如何改进团队流程,最大限度发挥Scrum的优势?

    在充满不确定性且不断变化的环境中交付复杂的产品会涉及到很多方面。因此,我们尝试简化过程并聚焦具体的行动。 下面是改进团队流程的5个步骤,希望能对你的团队有所帮助...

    Worktile
  • 敏捷软件质量保证的方法与实践

    来源:https://www.cnblogs.com/wintersun/p/5297352.html

    小老鼠
  • 有料丨如何实施数字化云平台的集成与交付(PPT)

    EAII 元元博士 ? 今天的内容会从:“识别挑战、制定策略、给出方案” 三个维度说起。 ? ? 数字化云平台MVP的集成与交付工作会受多团队、多技术栈、多领域...

    yuanyi928
  • 持续测试 | 测试流程提效:在 CODING 中实践迭代内的持续测试

    持续测试(或者敏捷测试)要求测试作为基础活动贯穿于软件交付的整个过程中。相比起在 DevOps 时代陷入困境的传统测试模式,持续测试首要改变的是“测试后置“的状...

    CODING
  • Flutter 的新功能、Dart 开发工具以及一行神奇的 CSS 代码 | Google 开发者大会见闻

    2020 年 11 月 16 日,Google 开发者大会 (Google Developer Summit) 在线上举行。本次大会以“代码不止”为主题,全面介...

    深度学习与Python

扫码关注云+社区

领取腾讯云代金券