报名参加CloudWeGo黑客松,奖金直推双丰收! 了解详情
写点什么

敏捷测试中的管理层适应过程

  • 2012-11-18
  • 本文字数:2166 字

    阅读完需:约 7 分钟

对于成功的敏捷实践,管理层的支持是至关重要的。敏捷测试专家 Lisa 和 Janet 详细分析了管理层的文化变化和适应过程。在阶段性项目中,管理层定期得到更新信息,签署表示每个阶段结束的文档。高层经理可能不知道如何度量敏捷项目的进度。他们可能害怕失去控制或缺少“过程”。

而在敏捷项目中,期望改变了。在Janet 以前从事瀑布项目时,每个星期总是听到类似于“功能已经完成90% 了”。这种度量在敏捷项目中是没有意义的。没有“完成标志”来表明阶段的结束,项目的“完成”不是通过条件衡量的。每个项目团队决定其有意义的度量标准。在Scrum 中,sprint 和发布燃烧图跟踪用户故事的完成,能够让经理们衡量进度,但是没有固定的“日期”用来通知客户。测试标准可以用来有效地跟踪测试覆盖率,但是不提供收尾文档。让很多经理不能理解的另一个改变是让团队决定他们自己的技术和管理他们自己的工作量。不再由经理决定哪些已经完成了。团队(包含客户)决定交付成功应用需要的质量水平。敏捷团队在比传统团队更少的时间期限内评估和工作。为了保证技术问题不会增加,团队需要规划足够的时间来实现良好的设计和执行,而不是偶然形成的。敏捷团队的经理关注于清除障碍,让团队成员更出色地工作,而不是糟糕地管理团队的活动。

Janet 举例说:

我请副总裁负责一个大的敏捷项目,他从管理的角度发现这在新的敏捷环境下是最困难的部分。他说,在传统的瀑布模型项目中,在最末期,报告都显示事情根据计划进展顺利,然后所有事情都处于惊慌状态并“都不工作”。

在敏捷项目中,每天都有需要解决的问题。敏捷项目更是在一致的基础上工作,至少获得真实的报告。项目的结尾当然是没有疑问的。

业务相关人员不喜欢惊奇。如果可以说服他们给团队足够的时间和资源来进行转变,他们将发现敏捷开发使计划更精确并达到稳步增长的业务目标。

有时确实是管理层驱动开始敏捷开发的决定。Lisa 公司的业务主管选择尝试敏捷开发来解决他们的软件危险。为了起作用,他们需要有不同的管理层期望。需要对做出巨大改变的困难非常敏感,特别是在运行不正常的组织中。在所有时候,转变到高性能的敏捷团队可能是一个很长的时期,经理需要许多耐心。确保提供必需的资源是他们的工作,确保每一个人都学到如何高效率地工作。

作者讲了一个测试经理转变的故事:

Tae Chang 在 DoubleClick 管理一个执行端到端的测试来确保所有集成点(从上到下所有变化)都被覆盖的团队。当他们使用 Scrum 时,开发团队重组成为许多应用团队。交流问题导致了缺少依赖,所以 Tae 的团队开始帮助确保问题被尽早发现。

Tae 告诉我们:“我相信敏捷开发显著地放大了跨团队交流的重要性和协作的端到端的测试工作。找到一个非扩散的(即适合目前的 sprint 结构的)集成测试过程是很困难的。实际上,我们依旧在尝试,但是测试工作的整体益处很显然。”他们的团队开始进入“小型瀑布”的陷阱。“在回顾总结中,”Tae 解释说,“我们认识到这样做的一个原因是我们在内化敏捷实践前开始了敏捷过程。”

DoubleClick 的团队知道测试自动化和持续集成是关键,就提出了新的想法,例如专门的构建和自动化团队来帮助开发团队应付这些问题。他们引入专家培训来帮助团队学习测试驱动开发和结对编程。开始采取步骤来解决遗留系统中的技术问题。

Tae 的团队参与了所有的 sprint 计划和评估会议,使用正式和非正式的交流来达到跨功能的沟通和协作测试及发布。他发现这有助于保持会议简短和内容相关。他也支持所有人坐在一个开发的区域并反对分隔断的格子。

Tae 给转变到敏捷的测试人员提出了如下建议:“敏捷开发通常一开始会使测试人员感到挫败,因为他们不能获得完整的需求文档或者确定的测试阶段。我认为敏捷开发中,无论何时,测试人员将从事来自传统开发过程中多个阶段的任务。测试人员可以在设计会议中和工程师及产品管理层(她这时需要记录并开始思考建议的代码改变可能会影响的有风险的区域)一起工作,同时对提议的变化进行自动化和运行测试用例。这时在思想上的改变,一些人可能比其他人更快地接受。”

Tae 的经历反映出我们和曾经交谈过的许多其他团队的情况。

Lisa 特别强调要使用经理的语言:什么是业务经理最容易明白的?是底线—ROI(投资回报率)。为了从经理那获得需要的支持,把需要放入他们可以理解的上下文环境中。团队的效率转化为新功能,获得更多的收益。如果需要时间和资金学习和使用自动化工具,向管理层解释自动化的回归测试将使团队更快,每个迭代交付更多的功能。

Lisa 举例说:

我的团队需要很多时间来做危险的重构,例如尝试将代码分成多个模块使其可以独立构建。也需要时间将现有工具升级到最新版本,或者尝试新的工具。所有这些任务很难在为期两周的 sprint 中实现,因为我们还要努力向业务交付用户故事。

我们向管理层解释如果这些“项目”任务推迟太长时间,技术债务将会积累,速度将会放慢。每个迭代交付的用户故事的数量将减少,并且新的用户故事将使用更长的时间来编码。业务方面将会用更长的时间获得为了吸引客户所需的新特性。

业务人员很难同意让我们每六个月投入一个两周的迭代来做管理技术债务的内部工作,但是随着时间发展,他们将会在我们的速度中看到结果。最近,其中一个经理实际上问我们是否需要更频繁的“优化 sprint”。产品和团队都在成长,业务人员也希望确保我们同时在基础设施和工具方面进步。

2012-11-18 13:411669
用户头像

发布了 501 篇内容, 共 264.9 次阅读, 收获喜欢 61 次。

关注

评论

发布
暂无评论
发现更多内容

图计算之开局女朋友跑了2

Zhuan

图计算 GraphScope 图分析

时序数据到底是什么,为什么我们需要时序数据库?

数据库 大数据 时序数据库 tsdb 数据智能

CSS的设计模式(一)OOCSS

Augus

CSS 8月日更

坚持“一城市一矿山” 拾起卖争当循环产业领跑者

InfoQ 天津

基于一万小时定律去规划职业

非著名程序员

生涯规划 职场 职业规划 8月日更

10 个超棒的 JavaScript 简写技巧

前端依依

程序员 大前端 js 代码规范

网络攻防学习笔记 Day111

穿过生命散发芬芳

网络安全 8月日更

【六顶思考帽】学习心得

LeifChen

8月日更 六顶思考帽 创新思维

Fil火爆的原因是什么?fil未来价格会多少钱一枚?

分布式存储 IPFS fil fil价格 fil行情

上游思维:用小行动获取反馈

石云升

读书笔记 8月日更 上游思维

3天倒计时!百度机器学习训练营正式开播啦!(加QQ群941354305)

有只小耳朵

人工智能 深度学习 学习 AI AI Studio

前端自动化测试及 Karma 介绍

devpoint

单元测试 自动化测试 Karma 8月日更

秀到飞起!Alibaba全新出品JDK源码学习指南(终极版)限时开源

今晚早点睡

源码

前端基础五之jQuery基础

ベ布小禅

8月日更

fil挖矿必看!fil挖矿步骤有哪些?fil挖矿的效率如何?

分布式存储 IPFS fil fil挖矿

Springboot 结合 Netty 实战聊天系统

声网

音视频

开源应用中心 | 做项目,不敏捷?快来部署这款灵活的项目管理系统

fil挖矿难度大不大?fil挖矿1T收益是多少?

fil挖矿难度大不大 fil挖矿1T收益是多少

【回帖赢大奖】AI+开发者=?

百度大脑

极光开发者周刊【No.0820】

极光JIGUANG

【得物技术】浅谈Redis集群下mget的性能问题

得物技术

redis 性能优化 性能 redis集群 mget

金九银十旗开得胜!秋招字节正式批4面,顺利拿到offer

编程susu

Java 编程 程序员 面试 编程开发

markdown不支持代码块和表格,离开这里了

DBKernel

Go- 基本类型和运算符

HelloBug

Go 语言 布尔类型 基本类型和运算符 数字类型

百度智能云最新成绩单亮相百度世界大会2021,“云智一体”再升级!

百度大脑

人工智能 百度

云计算成为趋势,北鲲云超算平台布局云计算市场?

北鲲云

CRLF、CSRF、SSRF攻击与利用

网络安全学海

黑客 网络安全 信息安全 WEB安全 漏洞挖掘

netty系列之:netty中的懒人编码解码器

程序那些事

Java Netty nio 程序那些事

如何利用 SEI 实现音画同步?

ZEGO即构

音视频 音画同步 数据流录制 flv

地府鬼神图关系构建

6979阿强

图算法 图计算 GraphScope

Flink生态提供的其它工具(十一)

Databri_AI

sql flink CEP

敏捷测试中的管理层适应过程_语言 & 开发_崔康_InfoQ精选文章