这是《落叶》文集里第 82 片落叶，希望你能喜欢，不为别的，只为这份坚持。
“十宗罪”之七：缺乏测试
这个问题在不少的敏捷团队都有，组建的时候，为了追求所谓的快，用开发自己在做每个 User Story 时做的单元测试或者集成测试替代了完整需求的测试验证。为了达到所谓的不用固化角色，可以互相 backup，而由单一的开发人员来组建团队。
这种做法有点本末倒置了，敏捷开发的初衷和目标是提升研发效率和需求实现的契合度，无论是真的做到了敏捷，还是半瀑布半敏捷，甚至于伪敏捷也好，都只是流程问题或者是效率问题，但最核心最基本的原则不能丢，那就是产品的质量。
虽说我很认可一个观点，那就是质量不是靠测试保证的，而是要靠开发的代码质量保证的。但就我这些年来的工作经历看来，70%的开发人员的确没有这个意识，或者说现在绝大多数公司的研发流程中，对开发代码质量的考核，就从来没有严格到那个程度，也没有任何研发模式会引导开发自主的对代码质量重视起来，
所以，现阶段来说，一个产品的质量，还是需要测试去验证和保证的。而在敏捷中，我们更多地应该是去思考如何让开发和测试的配合更加敏捷，而不是简简单单地只是去考虑如何能让开发替代测试的工作，或者让测试能够去写代码，这些其实并不是敏捷思想真正想去达成的目的，我认为这反而是一个相当大的误区。
“十宗罪”之八：忽视用户的反馈
敏捷与瀑布比，有一个很大的优势，就是它有很多个迭代构成，每个迭代都有可工作的产物生成，用户就能看到成品，并且使用体验，同时提出建议和意见。然后团队在根据用户的反馈在下个迭代里进行改进和调整，用户在下个迭代结束的时候又能看到一个改进调整后的功能，在这样连续反复的迭代中，产品经过团队和用户的反馈->改进->反馈。。。，逐渐地被打磨成用户真正想要和真正满意的样子。
而很多团队在一开始，特别抵触，甚至于“反感”这种用户反馈，他们总认为用户是在干扰他们实现某个需求，而不愿意停下来好好去看看，去理解用户的反馈。这是因为大家刚刚转型，还不是特别理解敏捷很多思想的时候，仍然固有自己在实现过程中，不希望被打断。有些人这时候还会拿出 Scrum 的教科书来说，书上不是说每个 Sprint 里不允许发生需求变更吗？
没错啊，我们这里说的用户反馈，并不是打断你当前 Sprint 的进行，他是在两个 Sprint 之间所产生的，它会影响到的只是下个 Sprint Backlog 里的 User Story，并不会中断你正在进行中的工作。
而且我们之所以引入敏捷，不就是想通过短平快的路子来不断地试错，获得用户的及时反馈，再进行持续的改进吗，从而提升用户对产品的满意度吗？如果脱离或者屏蔽了用户反馈，那岂不是又会产生原有瀑布模式下的问题了吗？
所以，不管我们是否采用敏捷，都不能脱离用户需求，不能忽略用户的意见和建议。虽然用户不是上帝，但用户的确是检验你产品成功与否的唯一。
作者简介：14 年测试经验 + 11 年项目管理经验 + 11 年团队管理 = 一个测试老兵
