敏捷实践之Desk Check | TW洞见

今日洞见

文章作者来自ThoughtWorks:曲正平。图片来源于网络。

本文所有内容,包括文字、图片和音视频资料,版权均属ThoughtWorks公司所有,任何媒体、网站或个人未经本网协议授权不得转载、链接、转贴或以其他方式复制发布/发表。已经本网协议授权的媒体、网站,在使用时必须注明"内容来源:ThoughtWorks洞见",并指定原文链接,违者本网将依法追究责任。

在推广敏捷的过程中,虽然ThoughtWorks有过很多应用的经验,但是当我们把一个实践介绍给其他人,总会遇到为什么要这样做的问题。在带领大家做之前,口头上的介绍和说服工作是必不可少的,毕竟这是给团队成员打消疑虑,树立信心,建立目标的一个过程。做到团队的每个成员都理解了这个实践的意义,对实践的执行就能很容易的达到要求。否则,团队执行的人很难心悦诚服的执行,结果就是这一环节会很快被大家无视,慢慢消亡了。

说起来deskcheck是一个非常简单的事情,但是越简单的东西,越难以引起团队成员的重视。下面我会通过之前参与过的一个项目的总结,来分析一下我们没有做desk check的时候产生的浪费,以及各参与角色在一个标准的desk check中的职责。

我们先来看看在没有这个环节的情况下,一个issue从这里启程进入下一阶段会产生多大的破坏力和消耗团队多少生产力。

Developer在完成开发工作后,测试打包包含这个issue的应用,Smoke test需要一定时间,因为smoke test主要包含以往功能的主干测试,也许包含你刚开发的功能,但是基于你的理解可能也是错误的测试,所以这个测试运行完肯定是通过的。(我们的产品打包和运行完smoke test需要至少15分钟。)

Issue随部署进入测试阶段。(我们通过pipeline部署需要30分钟。)

测试人员需要准备测试环境(OS,Test data,很多时候测试数据在使用之后就不能再用了,除非有完善的脚本。有时候有些功能跟时间或者日期相关,半个小时或者第二天就会失效,比如一些scheduled jobs,下次也需要重新创建。)

然后测试人员执行测试:Scenario 1,2,3,4,5,6。我们在执行到Scenario 5的时候发现了这个issue,之后停止测试将issue提交bug track system。

Issue需要被PM或者PO等Stakeholder分析,排定优先级之后,返回开发团队。此时之前工作在包含此issue的功能的那对developer已经工作在其他的任务上了,不管是等待当事人来修复还是找空闲的人员来修复,都需要一定的等待时间或者了解上下文的时间。

当此issue成功被修复之后,测试人员仍然需要准备测试数据,重复测试Scenario 1,2,3,4,5,6。这样才能确保这个功能在所有的情景下满足需求,而不可能从上次出问题的scenario开始。

如果有desk check,这个流程会变成什么样子呢?

我们不需要跑Pipeline进行部署, 发现的问题不需要提交到bug track system,所以也不需要后期的bug triage。

如果同样的issue在Desk Check的过程中被发现,developer会马上开始修复这个漏洞并为之创建test,保证此问题不会再次发生。

所以,标准的Desk Check该怎么做?

开发人员在完成需求之后,快速在本地开发环境建立功能验证条件。

开发人员要做的具体工作是:需要测试数据的,建立mock data;然后对照Acceptance Criteria给团队的BA、QA展示完成的功能。这里需要注意的是,开发人员最好自己先完成一遍测试。自测能够发现一些问题,提高deskcheck的成功率,也吻合越早发现问题修复的代价越小的原理,否则不但耽误了自己的时间也耽误了BA和QA的时间。

BA的职责是:验证开发之前提出的需求是否实现,是否有跟开发人员理解不一致的地方,是否有遗漏的需求。

QA的职责是:从测试人员的视角评估这个功能有没有“ready for testing”,并且做一个快速的测试,验证是否有Sad Path没有考虑周全。

不管怎么说Desk Check还是处于developing的阶段,在这个阶段矫正一下需求,修复一些快速的defects,这样才能让功能ready进入下一个阶段:测试环境的测试。

之前一直错误地理解Desk Check是我们开发流程的一部分,是流程上的一个要求。但是结合最近项目的实践和敏捷宣言的理论,意识到Desk Check实际上是践行了宣言的第一条:个体之间的合作,而且合作比流程更重要。Desk Check同时也体现了反馈在敏捷开发中的作用,及时的反馈能够尽早的纠正工作的偏差,让我们一直向正确的方向前进。

原文发布于微信公众号 - 思特沃克(ThoughtWorks)

原文发表时间:2015-11-10

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏安全领域

给道德黑客的十大建议

你是否每天都突破各种防火墙?睡觉都在想着利用漏洞?可以轻而易举入侵加密网站?为了人们的利益而做这些事?如果你对这四个问题的回答都是肯定的,你就是道德黑客——或者...

15920
来自专栏漫漫全栈路

R.I.P. :传统整体式架构 VS 微服务

我咨询了十几个微服务项目。有些人表示,微服务真棒(这是未来!),而有些人很沮丧(谁发明了这个废物?)

16020
来自专栏PPV课数据科学社区

干货 : 聚焦于用户行为分析的数据产品。

因为工作需要,我的收藏夹里收集了很多数据相关的产品,其实加入收藏,也一直没有时间好好去研究。这几天恰好有时间翻出来逐个体验了番,顺手贴出来,大家一起研究。 受篇...

56680
来自专栏美团技术团队

初探下一代网络隔离与访问控制

概述 安全域隔离是企业安全里最常见而且最基础的话题之一,目前主要的实现方式是网络隔离(特别重要的也会在物理上实现隔离)。对于很小的公司而言,云上开个VPC就实...

58370
来自专栏TEG云端专业号的专栏

裴泽良:海量存储与CDN的自动化运维

架构平台部提供的服务大家都使用过,微信QQ聊天的图片,朋友圈图片,QQ音乐里面的歌曲,腾讯游戏,应用宝里面的app的下载,腾讯云的COS对象存储,点播,直播,以...

7.6K70
来自专栏北京马哥教育

如何接手一个新业务的运维工作

如何接手一个新业务的运维工作?有些东西我们还是要把话说在前面,以免前期不明确造成后期工作的混乱。

21200
来自专栏数据和云

YH10:分布式存储解决方案zData

云和大数据时代的到来导致各行各业数据量的爆发,面对业务数据的日益剧增,企业的IT系统在性能、稳定性和扩展性等方面都面临前所未有的巨大挑战。如何有效应对云和大数据...

45940

有效的云服务报警系统

原文作者:Venkat Pothamsetty

30310
来自专栏腾讯社交用户体验设计

腾讯文档品牌设定

28830
来自专栏镁客网

Android N的新特性以及优化功能大盘点

20040

扫码关注云+社区

领取腾讯云代金券