敏捷本质的关键其实是质量，前面我们也介绍了现在的情况是什么样的，我们要实现真正的价值，关键中的关键其实是质量。
我们其实都经历过最终期限的压力，敏捷的本质不是快速，当然我们非常理解，当到家遇到业务上的一个最终期限的压力的时候，其实非常容易就会选择寻求捷径。敏捷要快速，当然也是对的，但是其真正的本质是更加频繁地交付，高质量地交付。这个“高质量”是必须highlight出来的，所以在敏捷团队中工作的时候，我们怎样去落实？
敏捷的理论大家都很认同，但是做起来，很难做，所以在这次交流讲座中，也是侧重怎样去落地，有没有一些技巧，方法论去做这样一件事情？有没有一个方向可以让我在平时的工作中做到真正的敏捷？提高敏捷的水平，其实需要从思维的方式、提升技能、整个团队的参与、聚焦质量这四个方面去展开。接下来我们就一起看一下，如何实际落地去工作。
改变思路，我们需要开放实时纠正这种思维方式，图片上这个火车，其实有很多办法可以到达终点，我们可以采取许多不同的路径，还没走的时候，我们其实是不知道哪条是最正确的，所以敏捷提倡实时的纠正。我们去实时改变信号，火车才可能真正到达想要去的终点。所以为了提高质量，我们需要不断地回顾，设定目标，进行测试，进行改进。
我们有时候可以跟测试人员去聊，你认为你的工作职责是什么？他们常常会说，我需要去找出缺陷，找出bug，或者说看看需求是否得到了满足，或者更极端的会回答，我们就是去把这个系统搞瘫。这些思想从严格意义上来讲，都不符合敏捷测试的思路。不知道大家有没有这样的想法。或者说你的团队是不是也是这样想的？更好的思维是，希望测试人员多问，我能帮助你做什么？这才是协作的一个思路。
所以从找茬到帮忙，这是思路的一个很大的转变。但是找茬的工作需要做吗？需要的。我们改变思维的话，只是说，我们从帮忙的角度去切入，这就是一个很大的敏捷思维的改变。其实不只是测试人员需要改变他们的思维，包括开发人员，他们也需要改变思维，从把代码提交了就行了，到我如何帮忙创建可测试的代码。
这点不知道大家在工作中有没有去认识到，叫“可测试的代码”，这一定要跟团队里的开发人员去进行沟通，达成这样一个共识，促进他们有这样一个思维的改变。需要补充一点，很多时候开发人员会去测试自己的代码，他们做得非常好，只是有时候针对程序的一些分析他们看不到，因为他们关注的还是自己的那一小部分，而不是大局。
如果开发人员从一开始就考虑到测试了，这其实是一种很大的进步了。更贴近整个团队从一开始就考虑测试，大家可以更好地去合作，这个其实是现在也很热门的一种理念，叫测试左移。测试左移在敏捷里面肯定是要的。测试左移就需要测试人员在里面去做到一些引导和培训，或者说跟开发人员来配对一起去做这件事情。总结来说，事情还是原来那些事情，只不过想法不同了，效果就不一样。
第二个是说需要提升技术，提升整个团队的技术，今天我们侧重谈的是测试人员需要提升的技能。说起技能，大家也会非常熟悉下图这个模型，叫“T型模型”，分成广度跟深度，在敏捷开发中，我们应该重视的是能力而不是角色，所以从广度上来说，比如说我们有一些编程的语言，可以很方便地去跟开发人员做结对，使得测试更自动化。这个自动化会在单元、组件或者功能的自动化上可以和开发人员一起做结对。如果有数据库的知识，就可以跟数据库的管理员合作。知道的越多，就能考虑到更多原来考虑不到的盲区。
深度上就是说，我有专业的技能，像功能测试应该怎么做，要注意哪些东西？测试用例应该怎么样去写，怎么样去关注，性能测试专业知识就能够很容易提升软件性能上面的把握。对于功能自动化测试的钻研，确实能够提升整个团队的测试效率 。
所以广度和深度就是大家要有很广的知识，要有自己比较有深度的技巧，后面一个是叫软技能，会沟通。这里要提到一个现状，很多人都不喜欢听到测试人员说的话，因为测试人员一般只要一说都是比较坏的方面，这里有bug，这里有缺陷，马上要去改，所以要学会如何很好地去传递这些信息。
软技能在敏捷测试里面也是很重要，可能大家会比较容易忽略，其实有了这个软技能，大家会协作，后面才会比较顺畅地一起去完成一件事情。所以测试人员应对敏捷，说大了要学习商业语言、业务语言，还要学技术团队的语言，这样我们可以跟业务人员去做沟通，跟技术人员去对话。
另外一个是倾听，因为客户也会有很多隐藏的假设，他会觉得，你其实已经知道了，或者你的整个团都都已经知道我的业务的逻辑，但其实你不知道。所以会倾听也是软技能的一个重要部分。第三个是对开发的技能，其实并不是说测试人员要成为编程人员，团队里面已经有编码的人员了，我们前面也说了，我们在做单元组件自动化测试的时候，就可以跟开发人员去做协调、配合，他们做这块有先天的优势，因为他们可以很快的写代码，但是他们也有一个天生的弱势，就是他们可能没有大局观。
我们可能更需要业务上的一些逻辑和真正专业的一些测试知识，这个是需要帮助开发人员去做提高的。另外，如果我们能够了解更高级的high lever的系统架构，有利于帮助团队去考虑这些风险。有一个很好的办法 ，在每天的例会上，我们可以找开发人员在白板上把某些阶段系统的构架信息画一画，讨论讨论，这样就很容易能找出软件存在的潜在风险，可以找出哪些是架构上的脆弱点。
提升技术还有一个非常重要的点，叫领域技能，不知道大家有没有关注过，这个是可以帮助团队去增加质量上的价值，或者说客户价值的体现，因为我们要实现这个价值，除了代码上，还要放在业务上，如何实现业务目标，怎样才能使业务成功，为最终用户带来价值，这样需要团队里的每个人，特别是测试人员要投入时间去学习这个领域，去了解企业怎么运作，我们开发的这个软件或应用相关的人他们如何去工作，要成为深度的业务域的一个专家，这样才能更好地帮助我们解决业务问题。
这个也是说起来很容易说，怎么落地呢？首先我们还是说，我建议跟业务的客户坐在一起去聊一聊，可能大家也会说，我们的工作模式不可能接触到客户或者说比较少接触到客户，特别是测试人员，如果接触不到，可以尝试去找找公司的客户支持人员，问问他们在支持这个应用的时候，哪些地方会更容易出事情？那这个方面我们后面就需要做更多的测试，更多的回归测试。
领域技能是很重要的，如果没有这种环境的话，还是要去创造条件去了解用户是怎样工作的，实在不行要跟产品的owner一起去推进这个事情。