在Scrum的讨论中审视QA

A:你对软件流程方法论有多少了解？
B:你指的是哪些？
A:Agile/RUP/Scrum/XP/CMMI？
B:有那么一点点研究,我在项目中正在实施scrum
A:你是什么角色？
B:pm啊
A:靠，应该是ScrumMaster或者Product Owner
B:哦 你是说在scrum中的角色啊
------------------------------------------------------------------------------------------------------------------------------
这位老兄可能对Scrum没多少了解（他也承认）就在实施，他似乎更关心行政上的PM title.

------------------------------------------------------------------------------------------
B:我们没有完全的按照scrum checklist中的方法去组织项目,毕竟，这些方法论在实践中要灵活的使用，不能一味的完全照搬。xp，scrum的一个很大问题，就在于它们和传统的QA制度简直是格格不入。
A:传统QA都具体做些什么？
B:传统qa主要是通过在开发和集成阶段的一系列测试来保证qa质量
A:那么QA的工作应该转移到ScrumMaster这里，test成员应该是开发Team的一部分，对吧
B:不能这么简单的来转移,qa并不属于开发team，在任何一个公司都不属于
A:我的意思是，没必要专门成立QA部门,质量的保证是一个Scrum团队的责任和义务
B:你不可能在全局范围上 让公司的建制跟着你的项目变动，那样的话，你根本推不动scrum
A:思维的转变，管理层的支持是推进敏捷的必不可少的东西
B:如果这是必不可少的，那就不要实施敏捷好了 ：）,你不可能让老板们放弃传统的qa制度，仅仅因为你说敏捷可以解决一切问题
A:敏捷和传统的方式都能解决问题，只是敏捷可以更好的交付真正有价值的产品。如果老板不能放弃，那么真的很难
B:站在老板的视角，你凭什么说敏捷能交付更好的产品呢
A:实践是检验真理的唯一标准
B:公司不是实验室，产品也不是实验室里的小白兔。况且敏捷的方法并不是万能药，特别在大型项目上，要掌控好敏捷项目，对pm是一个很大的挑战
A:就是为了掌控好项目，所以才采用敏捷的方法论。当然不是万能药，敏捷是一个框架，你可以根据自己的需要扩展。有那么多的成功软件企业都在实践敏捷（最多的是Scrum），他们不是在闹着玩吧
B:有实践的结果吗？微软的哪一个大型产品是敏捷开发的？adobe呢？sap，oracle，IBM呢
A:Nokia是Scrum实践最好的，还有google http://www.infoq.com/presentations/Agile-Management-Google-Jeff-Sutherland
B:什么产品？
A:我认识的诺西的一个Manager，他们的网管产品NetArt,他们自己部门在实践Scrum
B:google只是在试验scrum罢了 成果还没看到呢。说实话 像NetArt这种大型产品，根本没有做scrum的必要，我不看好这种胡乱上马的架势。
A:Scrum是一种软件开发的方法论。任何东西，千万不要上来就排斥，兼容并包......
B:我怎么排斥了 我正在自己的项目中实践scrum
---------------------------------------------------------------------------------------------------------------------
一个正在实践Scrum得管理者对Scrum抱着种种猜疑，我很怀疑其实践Scrum的动机。

对于Agile和QA/Test的讨论，发现有很好的一篇讨论文章,援引几段文字表达我的看法。

The problem with QA is that programmers lose the responsibility for quality, because they start to think "it's QA's job." No, quality is not QA's job. It is the programmer's job, and the designer's job, and the architect's job.

You want quality in software? Make your programmers do peer reviews of all code before it gets checked in.

You want quality in software? Don't let your programmers start writing code until they can explain it clearly in English (or whatever spoken language your team has standardized on) to someone else on the team. Make sure the design makes sense before they get half-way done building the new pile of spaghetti code.

Our industry -- the software industry and those who write application -- as a whole produces mostly crap.

忘了粘贴讨论中的一句话：scrum的整体架构大话都知道，它起源自制造业的精益生产的变革，它是为了解决传统瀑布的问题，没有限定使用在什么软件开发环境。当然工程性的软件开发用起来最有效果。说到解决什么问题：根据市场变化就是快速生产，减少浪费（制造业的视角）。

当然对于偏产品研发的项目，适当保留QA的角色是合理的，但要求在项目中更多的参与并成为团队的一员。

还是很感谢B先生，思路和想法真的在讨论/辩论中才会越来越清晰。