当现代项目，不断要求人去差异化，让大家成为零件的时候，这样的一种方法，能够让我们自身认识到自己的价值，并且在项目的发展中完善自己，我认为非常重要。

　　有时候，扪心自问，我们是否真的随着产品的成熟而进步？历经了一两年甚至几年的测试工作，是否在技术，视野等方面有了显著的提升？客观的说，我曾经的一些同事，负责某个产品已经数年，却连产品基本的一些业界通用的方法都不了解，不能自己实现，这样的结果让我感到非常悲哀。或许，每个人都应该从内心明确的认识到，自我的发展也是项目的产出之一，的测试工程师同样能够提高效率，提高产出，制造更多的价值。

　　再看看这条：可以工作的软件胜过面面俱到的文档。公司在进行流程的梳理与制定，以往很多的文档缺失，现在在弥补一些以往的稳定缺失，当是否需要很多文档呢？

　　在敏捷里面给出了一些指导的意见：没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。然后，过多的文档比过少的文档更糟！编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，要花费更多的时间。如果文档和代码之间失去同步，那么文档会变成庞大的、复杂的谎言，会造成重大的误导。

　　在文档方面，我从来不是文档排斥者，我只是排斥过多的文档，你有没有发现你的团队用大量的时间做一些没有意义的文档？我有过这样的经历，在调查部门其它同事的工作，发现他们大量的时间用来做文档，真正的测试工作相比于文档反而少很多。这样的文档的受众有多少？不过是部门的寥寥几个人。。。

　　也许有人会认为，文档是知识传承的良好媒介，有了详细的文档可以抵御人的流失。我不得不说，太多的文档正是人的流失的原因之一。同时，还要指出：好的知识传承的媒介是人！一个系统，如果能够保持耐心的给予新人足够的指导，我相信他们对于系统的理解要远远超越于枯燥的文档，当然，如果你能把文档写得像老舍的小说那样精彩，我也会认同你写文档的方式。

　　还有是，对于很多功能，为什么非要采用文档的方式来保存细节？我一直不明白，为什么不直接去看代码？类似我们的产品，每个人都有权限看代码，可以还是很多人愿意电话去问研发怎么回事，怎么回事，我有的时候很不理解。代码是真实的文档，也一定比编写人员的描述更准确，更多的时候，我们应该查阅代码，相信代码，而不是别人的描述或者某些早已过时的文档。

　　其实模式没有好坏之分，还是要根据应用的场景来选择开发模式。到目前来说，我认为在我们的自动化测试框架和脚本开发工作中，敏捷的模式可能更适用。

　　比如我们可以无障碍的保持和客户的交流，甚至把客户作为我们开发团队的一员；

　　比如我们可以并不关注文档，而已可工作的代码作为交付；

　　比如我们可以测试驱动开发，让我们测试人员编写的代码同样经过测试，让代码健壮，而不是总是问一些，为什么代码会报错，难道是wait不够吗等等问题；

　　比如我们可以在功能实现后进行不断的重构，让我们的代码更清晰，结构更合理；

　　。。。。。

　　有太多的比如让我们选择敏捷作为我们的开发模式。

　　当然，正如前面所说，模式本无好坏，而是看场景。敏捷本身也有他自身的弊端，但至少当前，是满足我们的需求的，也激励我们更多的使用和尝试，现在还浅薄，希望伴随着使用，能够对这种开发模式有更深入的理解。