那么记忆中与敏捷沾边的工作，就是2009年在广联达公司的测试工作。印象最深的几点：

　　一、测试用例简化，以往的花了很长时间编写的测试用例，除了在第一轮测试时候会参考执行以外，作用非常有限，而且维护困难，每次例会讨论用例维护的方案总是不了了之。用例简化后，针对每个功能点列出简要的测试点在QC中，而不去写详细的用例。在每一轮的测试过程中都会去维护增加新的测试点。

　二、测试提前，区别以往等待开发人员给出正式版本后再进行测试。而是，在得到需求的第一时刻，列出相应的测试点并发给开发人员确认，在与开发的沟通过程中得到对于需求的统一认识。然后在开发做完每一个新功能时，一个测试和一个开发坐在开发的工位上按照测试点，逐一在本机上验证。这样就不用从服务器上等到正式版本再测试了。

　三、组织结构，拆散原来独立的测试部和开发部，根据产品、功能、地区版本划分，开发和测试以大概2：1的比例组成一个团队，当然由于需求人手紧张，所以一个需求人员会同时参与几个团队的工作。这样转变了原来开发与测试的对立局面。

　四、每日站会，其实当时对于每天早上开会有些反感，也许是因为还没有真正体会到他的意义。

如果说敏捷中的测试必然都是需要自动化的，那么我们当时的自动化测试只是应用于冒烟测试和基本功能验证。无论是不是完全意义上的敏捷，还是有所收获的。记得后来曾经参加其他公司的面试，说起敏捷经历，我还会拿出此段经历来充数，汗!

那么回到现在的测试项目中，是否可以按照敏捷的思想来施行呢?会起到什么作用?解决什么问题?

　从贺炘老师的PPT中看出，分析现在项目是否适合敏捷可以从以下几点来看：

　　1.项目特点

那么我们的项目是离岸的测试项目，作为开发的客户是在美国，在项目特征上我们无法实现开发和测试结合的团队结构。而且由于时差问题，我们发出的问题只能在第二天得到答复，就无法实现敏捷所要求的及时反馈和沟通。

　2.支持环境

正因为我们是独立的项目，在自主性上比较强，采取何种形式的测试流程和方式，不会太受制于人。另外我们的自动化回归测试一直在比较稳定得运行。以此来说，是属于比较适合的。

　3.人员素质

我们的项目一直以来秉承着建立一个小而强的团队的原则，仅有的5个测试人员，从业务水平、代码能力、测试能力方面来说，都是能够独当一面的。

那么是无法做到敏捷了?敏捷的真谛是什么?是一定要符合几个关键字吗?还是一种解决问题的思路呢?

今天的会议中嘉宾们对于敏捷的意义探讨有几点：快速的价值交付、更加透明和有效的沟通、减少项目中的不必要的时间浪费。

回过头来，这不正是我们项目中存在的问题吗?

不得不说我们有很多人已经非常习惯于这个功利社会的游戏规则，也许一个人推动敏捷测试、推动探索测试、推动自动测试，真正目的是为了绩效、薪资和升迁。我们不能否认这是错的，但是如果解决了不了实际问题，反而由此产生的很多问题会给这些优秀的思想和技术脸上抹黑。还是在以后的项目中，踏踏实实学习，小心翼翼实践吧，共勉!