敏捷软件开发团队必须确保他们开发出来的产品质量能够满足要求，管理团队也经常希望开发团队能够提高速度以实现为客户提供更多的功能。本篇文章中多个作者探讨了质量和速度之间的关系，并提出了一些既能提高质量也能加快进度的方法。

　　敏捷是一个“质量游戏”，如果你以正直，承诺以及平衡的心态来玩这个游戏的话，那么结果将会是非常好的“速度游戏”，但它（速度）却并非没有代价。。。

　　如果你无法玩转这个质量游戏，你所采纳的敏捷开发方法甚至比你以前使用的开发方法更慢。

　　团队必须致力于把工作在一个迭代中完成，这也就意味着这些工作需要满足定义工作完成的所有标准。

　　很多敏捷团队允许返工 – 修复漏洞，完成测试自动化，重构，或者设计不良导致sprint迭代的延误。即使大多数的敏捷工具允许拆分用例故事以捕捉在sprint迭代中已经完成的工作对比延期的工作，我也还是认为这给团队传达了错误的信息，让他们认为工作不在一个sprint迭代内完成是可以接受的。

　　正如Bob解释的：一个组织不应该总是力图让进度变得更快，而应该更加注重质量。

　　因此，下一次当你听到有人在激情澎湃的谈论着敏捷代表了更快的速度时，请打断他们，尝试向他们解释敏捷并不是一个“速度游戏”，而是应该强调敏捷是一个“或许能够快速运转的质量游戏”。

　　Tim Ottinger曾今写过关于敏捷团队进度的14个奇怪观点，其中一个观点中就提到了质量和速度之间的关系。

　　尽管大家通常会降低质量要求以求在较短时间内尽快完成工作，但是如果团队所开发的代码质量不高的话，经过全部sprint迭代后的进度最终都还是会被降低。

　　Stephen Haunts在他的题目为进度并不是目标或者目的博客帖子中，描述了当管理者设定团队的进度目标后对质量会产生什么影响：

　　（…）为了增加交付的功能点数目以满足绩效目标，团队会牺牲掉系统的质量，但从长远来看这样最终还是会降低团队的进度，并且会引入技术隐患。敏捷团队最好关注正在开发系统的质量与流程过程（持续交付和集成等等），以及负责开发系统的团队成员本身。

　　软件开发者必须在进度和质量之间掌握平衡，正如Blake Haswell在文章什么是代码质量中解释的那样：

　　虽然经常会有很多的外部压力向进度方面倾斜，但是如果你不够重视质量的话，进度最终还是会趋于缓慢以及停滞，以至最终整个项目走向颠覆。考虑到一个项目的代码质量决定了它能够在多大程度上适应需求的变化，一个可以持续改进的事情是你需要花费一部分时间来优化自己项目的代码质量。

　　Blake提供了一个可以用来检查代码质量的属性列表：

　　可理解性： 代码需要在各个层面上能够被容易地理解。理想情况下，软件应该非常简单，并没有非常明显的缺陷。

　　可测试性： 代码需要被编写的非常容易被测试。

　　正确性： 代码需要满足功能和非功能性的需求。

　　有效性： 代码需要有效的使用系统资源（内存，CPU，网络连接，等）。

　　Hugo Baraúna在他的博客文章名为内部质量低下软件的症状中解释了软件是如何因为变更而“变得更糟”的，最终导致质量低下并且降低进度。

　　假如你正在领导一家创业公司的技术或者产品团队，你是首席技术官，并且已经推出了你们产品的第一个版本，做的还挺成功的。你们的业务模型已经得到了验证，现在你们正处于快速发展期。这真是太棒了！但这也是有代价的，它带来了一系列新的挑战。

　　你们产品的第一个版本工作的很好，但是代码库却无法满足持续发展的要求。或许你的团队进度并没有像以前那样好了，团队成员一直在抱怨代码的质量问题，首席执行官和产品经理想要一些新的功能，但你现在代码规划根本无法满足业务的需求。

　　他提供了一个指示质量低下的症状列表，这个列表能够帮助你来决定是否需要重写或者重构：

　　所有事情都很艰难

　　进度慢

　　测试套件运行缓慢

　　无法避免的缺陷

　　你的团队是消极的

　　知识缺乏共享

　　新开发人员成长周期太长

　　你又是如何平衡质量和进度的呢？

本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标软件测试之测试管理频道！