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

对于成功的敏捷实践，管理层的支持是至关重要的。敏捷测试专家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”。产品和团队都在成长，业务人员也希望确保我们同时在基础设施和工具方面进步。