通过坏味道提高敏捷实践在项目中的适用性

相信每个团队对敏捷实践的应用都不尽相同，都会根据项目的具体情况进行调整。这是因为敏捷是一种“适应性”而非“预见性”的方法，这意味着，你很难预测哪 些敏捷实践在你的项目中一定是好的，从而使用它们并且保持一成不变。那么如何做出合理的调整呢？通常情况下我们可以结合以前项目的成功经验、以及其他人改 进的最佳实践，从而决定采用何种实践，或者对实践做出哪些改动。与此同时，敏捷自身也提供了一个很好的方法：回顾会议，可以发动所有组员，在项目开发过程 中发现存在的问题，并且能够针对性地解决。

但是“预见性”的调整是否完全切合项目的实际情况？回顾会议中提出的改进意见能否被切实执行？本文提出可以在开发过程中及时识别各种坏味道，通过坏味道调整已有敏捷实践，或者引入新的实践，甚至检查敏捷实践在项目中的执行程度。

我 们知道编程过程中如果出现了坏味道，通常意味着我们需要对代码进行重构。同样，敏捷项目开发过程中如果出现了坏味道，也意味着我们需要对相关的实践进行调 整了。我最近参与的项目就是这样的一个敏捷项目，即使采用了很多好的敏捷实践，开发过程中仍然会不断地出现一些问题──或者说坏味道，在一定程度上影响了 生产效率。下面我就结合该项目的实际情况，介绍我们是如何发现项目中的坏味道，从而改善提高我们的敏捷实践的。

首先对项目做一个简单的介 绍：这是一个航运业的fixed size的项目，规模不大，除去PM和QA（二人均兼BA），开发人员大约有6名（不同阶段人数不同）。虽然项目不大，但确实遇到了一些困难，主要有：对 我们来说船运业是一个陌生的行业，而且需要集成原有系统；项目开发的前期，客户需求有过很大的变动；由于种种原因，开发人员变动频繁；刚开始在客户现场开 发，不久后有半数开发人员回到北京的office，进行离岸开发，带来了分布式的问题；另外这个项目实际上包括两个子项目，它们关系很小，而且用到的技术 有很大的不同。最后的结果是，经过5个月的开发，在没有增加人员、没有任何加班的情况下，项目提前一周成功交付。
项目能够成功，可以总结的原因很多。在这里我从一名组员的角度讨论一下，我们是如何通过发现坏味道不断改进敏捷实践，并对项目产生正向促进作用的。

通过坏味道引入敏捷实践
坏 味道可以暴露一些已有的问题，并让我们有机会引入新的实践。项目初期，我们没有“代码审查”。某次，为了统一代码编写风格，并提高代码质量，PM提出大家 互相之间进行代码审查。根据事先估计，把别人代码阅读一遍，查看有无明显的问题，只需要半小时就够了。但实际上过了1个多小时，所有人还在忙碌着审查。这 就暴露了一个严重的坏味道：虽然我们结对编程，并且经常交换结对，但每个人对其他人的story了解太少，而且积累了一段时间之后，对很多代码感到陌生。 这让我们觉得有必要每天都进行代码审查，这样每次可以只看当天的代码，所以一般20多分钟就够了。随后，我们在开发流程中增加了代码检查这一步骤：每天下 班前半小时进行代码检查，发现问题可以跟编码者立即讨论，或者所有人一起讨论；简单问题随时修改过来，复杂或者难以解决的，记录下来以后再看。在此后的时 间里，代码审查确实起到了很好的效果：有时发现了一些比较低级的bug，偶尔甚至发现了测试用例本身考虑不全；有时能对原有代码做更好地优化，想出更好的 思路；当然，如果代码写的很棒，我们也不忘赞扬两句，甚至可以偷偷学到了一些东西。

通过坏味道改善已有的技术实践
坏味道不但可以提示我们引入新的实践，同样可以提醒我们对已有的实践进行改进。
估 计集成已有系统的项目都会遇到脏数据的问题，而且让人非常头疼。我们采用TDD开发时也遇到了类似的问题：很多story在单元测试时都能测试通过，而 BA验收，或者QA测试时则经常出现莫名其妙的问题，经过检查发现很多情况是脏数据引起的。一开始我们还抱怨自己单元测试写的不好，没有覆盖所有情况，想 提高单元测试的覆盖度。但很快发现这是不可能的，因为脏数据之多、情况之复杂，超乎我们的想像。经过简单讨论，我们还是坚持编写基本的单元测试，但是每对 Pair开发story到一定程度时，都是连接本地备份的生产数据库查看结果。BA验收时也使用生产数据，这样一旦发现脏数据的问题，就整理出来交给客 户，让他们修改生产数据库。
开发人员在连接本地的生产数据库时，需要启动整个系统，而系统启动非常慢，经常需要等待将近10分钟。于是不知不觉中 就会有人抱怨：系统启动太慢了等等。其实这种抱怨就是坏味道的一个例子，说明大家的心情受到了影响，并可能导致生产效率有所降低。发现这个问题之后，就有 人开始研究系统启动慢的原因。最后发现使用ant自动构建的过程中，每次都会把所有的Java类文件删掉重新编译。而由于该项目集成了旧系统，旧系统规模 很大、代码很多，每次都会重新编译旧的代码和新写的代码，从而导致系统启动过程很慢。找到原因之后，我们就在ant自动构建中增加了一个任务，可以只重新 编译新写代码，系统启动速度大大提高。
这些都是很小的例子，但是我们意识到了坏味道并进行了改进，对项目产生了良性的影响。

通过坏味道检查敏捷实践在项目中的执行程度
另外通过坏味道还可以检查我们 敏捷实践的执行效果，比如对那些确实有用的实践你一直在坚持吗？项目后期，我们发现QA测出来的bug中，有一些bug原因非常简单，连简单的验收条件都 没有达到。而项目前期很少出现这样的bug。为什么会这样呢？这个坏味道也引起了我们的注意。经过简单分析发现：这些bug多数是离岸团队的人开发的。由 于离岸团队成员少，没有BA，所以测试、开发完成story后就直接提交了，缺少了BA signoff这个重要的步骤。而开发人员更关注于把story开发完成，认为单元和功能测试已经覆盖了全部验收条件，导致出现了一些不必要的bug。在 随后的开发过程中我们注意了这一点，每次离岸团队开发完story之后，由BA远程验收。与现场验收相比，远程验收花费的时间多一些、代价高一些。但是对 减少不必要的bug还是有所帮助。
另外还有一个小例子，我们有两个子项目，所有的开发人员会在两个项目间频繁switch，尽量保证每个人对所有 模块的代码都比较熟悉。这样每个人都能知道每个模块，并能修复bug。但是在项目后期，出现了这样问题：离岸团队准备修复几个优先级比较高的bug时，发 现它们属于同一个比较大而复杂的模块，而离岸团队从没有开发过该模块，对相关的功能和代码都了解甚少，想修复bug非常困难。虽然之前我们强调过在项目和 story开发时频繁switch，但这个例子说明我们没有很好地遵守。通过这次的坏味道，让我们及时意识到这一点，并且以后尽力避免。

坏 味道虽然最早是Kent Beck在重构时提出的，但它不仅仅适用于重构，也适用于我们的敏捷实践。推而广之，它也适合于项目的方方面面。聪明的人总是随时能够嗅出坏味道，并找到 解决办法。所以当你再次听到抱怨之声，或者不断地做重复工作时，都是坏味道的身影，也是你一展身手的好机会。
那么，还犹豫什么呢？