A和B
开发两种不同的产品
使用不同的编程语言
使用不同的编程语言项目框架（scrum vs Waterfall）
处于产品开发过程的非常不同的阶段（原型vs已被客户使用了很多年）
使用不同的错误跟踪工具（TFS vs fogbugz）
>
我的问题是：尝试向两个团队介绍相同的工具和流程是否有意义（最终这可能会使我更轻松）。还是我应该接受两个团队都需要两种不同的方法（这会使开发人员的更改变得更小/更少，但是这意味着我不得不在两个团队之间努力使用工具等）。
UPDATE 2017年3月30日
由于我收到了很多有趣的回复，因此我想向您提供过去几个月的进展情况。
直到12月，我只与其中一个团队，我对我们取得的发展感到非常满意：
我们在UX设计师，开发人员，支持，产品所有者和质量保证之间建立了工作流程。
质量检查主要由质量检查人员来完成。
质量检查人员在发布管理中有一种说法
我们正在引入自动化测试，甚至是自动化GUI测试。
质量检查人员不仅是我再也没有了，但我加上一名从事探索性测试的大学生和一名从事自动化测试的大学生。
我们对质量检查人员的重要性达成了普遍共识。
12月，我也开始在另一个团队工作。在这里，团队更大，产品更复杂，更容易出错。因此，进展并不如我所希望的那样快。到目前为止，
旧的，大的，越野车功能已经过首次彻底测试（尽管客户使用了多年……）
新的大型功能正在经过全面的测试（令我伤心的是，我什至不得不提到“进步”）
新的补丁和功能的测试比以前更加彻底，导致许多补丁和功能无法制作已将其纳入计划的发布中。
已经建立了产品管理，开发人员和质量检查人员之间的粗略流程，但我对此绝对不满意。
我不再是这里的唯一质量检查人员，但是有两名大学生在帮助我进行手动测试。
关于团队的方法和工具集成的最初问题，我不得不失望地说，基本上没有两个团队的流程之间存在重叠。我什至更失望地说，我也不会在接下来的几个月里发生这种情况。基本上，这是没有足够的时间来更改现有流程的问题。每个团队中有足够的工作供一个专职质量检查人员使用，我必须同时做这两项工作。由于我已经很清楚地知道我们不会再聘请质量检查人员，因此我专注于这两个团队中的小步骤。对于第一个产品，这意味着：
通过自动化测试获得不错的代码覆盖范围
建立有关如何处理自动化测试结果的过程
推动更好的发布管理（即让产品所有者更多地参与）
由于产品已脱离原型阶段并已为我们的许多客户所使用，因此正在进行支持和质量保证之间的流程。
对于第二个产品，我的下一步是：
自动化构建新的可测试版本的过程（现在它包含很多复制+插入和等待）
推出用于处理发布测试的工具，而不是Excel工作表
推动优先级更高的错误
推动规范和错误的记录方式，使使用该产品已有5年以上经验的人也可以测试功能和补丁。
如您所见，我仍然忙于介绍基本的质量检查流程。也许再过几个月，我就可以将两种产品的质量检查集成在一起。当前的情况（我什至指定了工作日以处理每个产品，并在不同的办公室工作以更接近每个团队）。如果您还有其他意见和建议，我很乐意阅读。
#1 楼
正如Bookeater所说，您绝对希望统一团队之间的工具和流程。也就是说，我将提供一些额外的建议，因为我一直处于这种情况下（在某种程度上我仍然处于这种情况下）。缓慢-每个团队都建立了适用于他们的流程和工具集。一个新来的人告诉他们必须改变一切，这不会顺利进行。
从获得信任开始-两个团队都需要将您视为有价值的团队成员，并相信您知道自己在做什么。您不能通过推动变革来实现这一点：您可以通过执行诸如在两个系统之间建立集成并说明要这样做来简化生活的事情来实现。
第一步-您的第一个流程更改应该是设置集成，因此您不必使用两个单独的系统（可以将其放置在确保不会意外的位置）上。将任何东西归档在错误的地方，导致丢失或延迟）。
期望回击-作为第一位测试专家，我花了一年多的时间“教导”我的团队，他们希望我参与开发的所有阶段。我提出了这个想法，让它被拒绝，然后当项目到达我进行测试时，我问了所有尴尬的问题，如果它们在设计阶段被发现，那将节省每个人的时间和精力。在某种程度上，我仍在为此而努力，直到现在它才处于敏捷过程中，而我正在推动人们更多地了解/监督敏捷过程正在使用的全局。
期望适应时间很长-我在目前的工作场所工作了2.5年。那时，两个开发团队合并为一个团队，应用程序生命周期管理过程已从电子表格和SharePoint列表通过TFS扩展到Rally，并且仍在不断发展。仍然有一个完全不在我团队内部的开发团队，并且进行了其他各种开发活动，这些开发活动涉及不与我的团队互动的人。
尊重团队流程-团队正在使用他们所使用的流程现在有了，因为这些流程对他们有用。我猜想与已建立的应用程序一起工作的团队是Waterfall团队-在一个已知的，易于理解的系统中，Waterfall SDLC可能非常有效。您可能需要将这两个SDLC花费几年的时间。
您需要长期工作-您将需要很多耐心和技巧，并且需要做很多事情。妥协。祝你好运。
#2 楼
您太讨厌这个答案了。是的，是的。在TFS和fogbugz之间有集成的可能性。
http://www.fogcreek.com/fogbugz/docs/70/topics/sourcecontrol/setup /TeamFoundation.html
您的目标应该是：最大程度的工具级别集成（仅输入一次信息）。
定义过程和利用此信息
最大程度地减少差异（使用这种不同的方法很难做到）
获得支持并定义时间表以减少最耗时的差异。
您应该清楚地传达投资团队之间的差异需要QA流程，因此缺乏明智的结果。
最后，任何精简工作都需要管理层决定。您可以进行按摩，调整和提出改善建议，但是惯性却不利于您。
#3 楼
首先，我想从Bug跟踪工具开始。记录下来的旧错误呢？如果您要求其中之一移至同一工具，则它们的信息（错误历史记录）将会丢失。但是，如果刚刚开始产品开发的团队已准备好迁移到fogbugz，那么您始终可以要求团队这么做。学习任何错误跟踪工具只需几个小时。这样，您只需要使用一种工具即可。不同的协议，不同的编程语言和不同的错误跟踪工具不会对要遵循的过程造成任何重大变化。
但是，当涉及到框架时，绝对不能将相同的过程应用于两者。 Scrum和瀑布过程分别类似于技术和恐龙。 Scrum属于敏捷，敏捷QA流程与传统瀑布完全不同。两种产品都必须按照其形成方式进行处理。在Agile上采用瀑布式流程将是一场灾难，反之亦然。
不幸的是，在流程方面，您以及实际上您的整个QA团队在两种产品上都必须有所不同。就个人而言，我觉得这对您来说是一个充满挑战的机会。
有很多有关要实施的敏捷QA流程的信息。您可以参考https://www.scrumalliance.org/system/resource_files/.../AgileQA.pdf
和
http://www.slideshare.net/abagmar/agile-qa-process
#4 楼
您应该使用相同的工具，因为它将使您的工作更加轻松，因为在那种情况下，您将只需要跟踪1个跟踪器，但是就流程而言，我怀疑您将无法遵循与您的两个项目都基于不同的SDLC（如您所述，Scrum和Waterfall）。因此，如果SDLC不同，则两个项目的整个游戏过程都不同，因为在一个项目中，您将拥有用户故事，故事点，产品待办事项列表，Scrum Master等，并且还有sprint，而对于Waterfall项目而言则不会。因此，采用相同的方法和过程将不会使您受益。除此之外，您的测试方法对于两个项目都是相同的（取决于范围），因为该方法将不取决于所使用的编程语言。用过的。这将取决于项目的时间表，范围和未来方面，例如如果它是一个长期运行的项目，具有很多回归周期，则应选择自动化，否则您可以使用手册。
因此您的测试方法和方法可能大致相同，但过程会有所不同。
#5 楼
仅需一点点贡献。我认为有一些问题需要回答才能决定：
您是否需要综合指标或为每个团队分别设置指标？对决策的影响是直接的。我的意思是，如果您要使团队学习并更改他们使用的工具，则它必须为组织增加价值，因为这会产生成本。否则，您应该习惯于分别使用两个工具。
我根据自己的经验回答问题，向不同的团队进行咨询，除非他们对他们做出了非常明显的贡献，否则我不但要采用其他方法来使他们做出改变。
希望有帮助！告诉我们您对这个话题的结论:)
#6 楼
我最近遇到同样的情况，对此感到非常高兴。我担任质量检查工程师3年，然后我有机会在组织中启动“流程实施”，因为他们想变得敏捷。 br />
我做了什么-
我使用了TFS（以前他们使用的是螳螂）。
我只针对一个团队，（公司有9个产品，他们的团队）。
我解释了有关Scrum（方法论）和TFS（工具）的所有内容。并激励他们开始在Scrum中工作。
经过2和3周的2个冲刺，我邀请了团队负责人和团队其他成员的PM在冲刺审查会议中。
现在仅仅两个月，我就开始在3种产品中使用SCRUM。
所以我认为我们应该逐个团队关注。