写点什么

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

  • 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:411865
用户头像

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

关注

评论

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

java培训SpringBoot自动装配原理

@零度

JAVA开发 springboot

web前端培训nginx配置规则

@零度

nginx 前端开发

2022南京14届-智慧工地-博览会

InfoQ_caf7dbb9aa8a

2022南京14届-人工智能-博览会

InfoQ_caf7dbb9aa8a

【PIMF】开源鸿蒙首款IDE低代码入门OpenHarmony应用开发

离北况归

低代码 OpenHarmony Openharmony啃论文俱乐部 OpenHarmony应用开发 可视化界面

云图说丨不同区块链之间如何跨链交互?

华为云开发者联盟

区块链 跨链 可信 可信跨链服务 跨链交互

解析分布式系统的缓存设计

vivo互联网技术

分布式 服务器 缓存服务

基于Flink-CDC数据同步方案

领创集团Advance Intelligence Group

算法 java

Python 中的鸭子类型和猴子补丁

AlwaysBeta

Python

2022南京14届-物联网-博览会

InfoQ_caf7dbb9aa8a

龙蜥社区成立DeepRec SIG,开源大规模稀疏模型深度学习引擎

OpenAnolis小助手

深度学习 开源 龙蜥社区 sig 稀疏模型

坐实大数据资源调度框架之王,Yarn为何这么牛

华为云开发者联盟

大数据 hadoop mapreduce YARN 资源调度框架

设计消息队列存储消息数据的 MySQL 表格

「架构实战营」

自己动手写Docker系列 -- 5.6实现删除容器

Go Docker 4月月更

react源码解析8.render阶段

buchila11

React

云智慧10年资深架构师带你了解:普通程序员向架构师成长必经之路

云智慧AIOps社区

程序人生 架构师 Meetup 晋升 成长计划

如何做好复盘

Hockor

复盘

腾讯一面:你平时怎么排查并调优慢 SQL 的

老周聊架构

MySQL 4月月更

虎符即将引入稳定币USN 并开启USN专场活动

区块链前沿News

虎符交易所 稳定币

欧拉开发者大会即将开启,全球芯片、整机、软件厂商共建数字基础设施开源操作系统

科技热闻

jackson学习之七:常用Field注解

程序员欣宸

4月月更

react源码解析7.Fiber架构

buchila11

React

如何使用参数化查询提高Cypher查询的性能

华为云开发者联盟

参数化 Cypher查询 华为云图引擎 GES 参数化查询

Thinkphp6实现定时任务功能详解教程

CRMEB

OpenHarmony 3.1 Beta版本关键特性解析——OpenHarmony图形框架

OpenHarmony开发者

OpenHarmony 动画效果

“一只股票一张表”, TDengine 在青岛金融研究院量化分析场景中的应用

TDengine

数据库 tdengine 物联网

云效 Projex是什么?Projex企业级高效研发项目管理平台

阿里云云效

阿里云 项目管理 研发 敏捷研发 项目协作

Docker 实战教程之从入门到提高(二)

汪子熙

Docker 容器 虚拟化 docker image 4月月更

Android技术分享| Android 中部分内存泄漏示例及解决方案

anyRTC开发者

音视频 内存 内存泄漏 移动开发 Andriod

[Day12]-[动态规划]-零钱兑换

方勇(gopher)

LeetCode 数据结构和算法

Linux驱动开发-编写RFID-RC522射频刷卡模块驱动

DS小龙哥

4月月更

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