在胡凯近期组织的新任PM/TL经验交流会上，提到了什么是合适的leverage模型。碰巧Mike Gualtieri最近一篇文章中提到了没有QA的团队，让我觉得，没有QA的团队，不但靠谱，而且没准会有奇效。

　　没有QA，缺少了最后的保障，软件质量是否会一降千里？不会的。没有单独的QA，并不意味着没有人去做测试和质量保证，而是让每一名dev承担测试的责任。很多人的经验表明，开发过程很常见的一个问题是，Dev匆匆忙忙做完story，就认为任务已经完成，剩下都是QA的事情，即使出了问题，也是QA测试不周。在心理学上，这是一种典型的心理依赖。由于认为自己只承担开发责任，Dev会用很大的精力追求开发速度，这是导致缺陷过多、质量下降的主要原因。在没有QA的团队，Dev要100%对质量负责，这种责任的转移，让Dev去掉了侥幸心理，从而会重视每一个Story的质量。

　　另外，敏捷软件开发中，常提的一个概念是“关注交付”。软件被开发完成，没有任何价值，只有上线，并给客户带来价值，才算真正交付。这种说法很多人在很多场合都曾提过，但是“纸上得来终觉浅”，不亲身体验，很难体会其中含义。没有了QA的团队，会创造这样一个“绝知此事要躬行”的条件，让Dev的视角不再局限于开发，而延伸到软件生命周期中更接近交付的地方。这样的体验，会不断冲击Dev惯有的思维，让他们思考并理解交付的真正含义。

　　没有QA，很容易实现完全的自动化测试。自己完成的story被别人破坏怎么办？没有Dev愿意每次都手工回归测试，只能是用自动化。而Dev编写自动化测试，具有QA无可比拟的优势。举个常见的例子，很多项目会采用依赖注入机制，不光可以减少代码的耦合，同时可以提高项目的可测试性，非常易于编写单元测试。这对自动化的功能测试同样有效，Dev在基础架构上，在开发中时刻都会关注可测性，从而避免很多问题，比如我经历的一个案例：某Web开发团队，Dev只开发Story，QA则经常抱怨，Web页面非常难于编写自动化测试。

　　谈了一些没有QA的好处，我觉得它的局限在于：

　　1、某些遗留系统中，对环境的依赖性比较强，很难做到完全的自动化测试，必须依赖QA的手工测试。相反可以从新项目开始尝试，引导甚至强制团队编写易于测试的程序。

　　2、大团队怎么办？敏捷中，几十人的团队就算作大团队了，而我认为大团队是反敏捷的，应该拆成十人以下的小团队。小团队更具可控性，对软件质量会有更高的保障。

　　如果下半年有机会开始新项目，我一定要做这样的尝试：没有QA的团队，可以交付更高质量的软件。