以前在《结合工具来实现敏捷开发》这篇文章中，我已经谈到了我们公司目前的开发情况，在这里也不再重复介绍了，反正主要是用 TechExcel的 DevSuite 系统来进行管理整个流程。至于很多人可能会问，既然敏捷了为啥还要用工具，其实我是这么想的，敏捷开发/测试，如果对于简单的项目而言，用工具反而会效率下降，因为这么几行代码，这么几个功能，一下子可以弄好了，弄个工具反而浪费时间。

　　但是对于稍微大的项目而言，可能不用工具没法很好地管理项目了，比如说好了，一个团队在一个迭代周期中做了10个功能，测试人员发现了40个Bug，但是修的人（由于部分人还在做功能）每天多只能修20个，那剩下的20个Bug怎么办，当然是延迟到下修了，一个迭代周期往往是一周到二周，假设两周好了，如果每天都能多余20个Bug的话，累积了200个未修的Bug，假设没有缺陷管理工具的话，我这些Bug可能只用Excel文档管理一下，Excel对于单个用户而言，保存信息其实做得很不错，报表也很Ok，但是想想这么多开发和测试需要打开同一个Excel文件，做查看，做更新，我相信Excel数据会被搞乱，而且Excel没法做跟踪，没法设置流程，也是比如说我想知道这个Bug经历过几个状态，经历过几个人的处理，我应该是没法找到的。

　　所以工具有用么，我觉得还是有用，对于大中型项目，既然想用敏捷，我还是建议用工具，不然的话，这个敏捷后肯定会变成不敏捷的。 像乘坐公交车一样，如果是100米的路，我劝你还是走路（敏捷）算了，因为公交车还要起步、停车和等红绿灯了，也许你走得都比它快；如果是10公里的路，您当然会选择公交车（工具）。对于敏捷而言，因为是有很多迭代周期组成，每个迭代周期其实相当于一个100米，但是很多迭代周期组合在一起变成了10公里了。真正的敏捷，它只是一种指导思想，没规定你必须怎么做（也出现各式各样的实现方式），所以，在正常的工作中，我们需要根据每个公司的实际情况来搭配符合你们实际情况的敏捷模式。

　　大家在百度上，只要搜索“敏捷测试”，我相信可以找到一大堆的内容，有概要的，有详细的，仔细看看，大家会发现很多人认为敏捷肯定是这样子的，那样子是不对的，当然大家对于“这样子“的描述又都不是太相同，分析一下，无非是两种原因，一种纯粹是自己瞎想的，可能稍微有点底子，但是没实际用过，按自己的想法，乱分析一番；另外一种是真正在用的，所以用自己公司的情况来解释一下敏捷。当然，我其实也是结合自己公司的情况在说敏捷，所以我不会苛求大家一定要采用我的理论，只是希望大家能从我的文章里发现一点对你们来说有用的知识，那我很开心了。

　　好了，闲话少说了，不管您有没有理解为什么要用工具，我还是继续下去了（有问题可以私聊）。

　　对于TechExcel的DevSuite，以前也介绍过，也一直用到现在，感觉挺好用，不过在这里也不多介绍了，给个图和然后把我们会用到的产品做个交代，不然之后万一提到某个产品，大家可能不知道是啥了。

　　其中对于敏捷测试而言，需要用到的主要是以下三个产品：

　　1、DevSpec：需求管理，用于测试人员（设计测试人员）检查功能的设计

　　2、DevTrack：缺陷跟踪管理，用于测试人员根据功能的设计文档来进行测试与提交Bug，并且跟踪Bug的进度。