#1 楼
我觉得某些团队或人需要艰难的爱情。当存在质量问题时，请指出，团队的其他成员可以遵循一些最佳实践来预防该问题。例如，如果由于错误而经常发生内部版本中断，部署中断或整个功能被阻止或无法运行的情况，那么您可以指出，可以通过以下方法防止这些错误：基本质量单位测试
签入之前在开发环境中的验证
可能的代码审查
持续集成如果遇到重大问题，质量检查人员就无法完成工作，特别是每个团队只有一个质量检查资源。向您的团队说明，如果产品不是处于可测试状态，则无法对其进行测试，这是他们的责任。不要坐下来怪不是您自己的错，否则人们将继续把这一切归咎于质量保证。将来，即在经常出现错误或部署到开发环境的功能周围添加单元测试，并在部署进行任何更改时进行基本测试。完全破坏了构建，部署或功能，建议您需要在计划中增加X个小时才能完成测试，或者建议您需要X个小时的开发人员资源来参与测试以赶上进度。确保每个人都看到您被阻止，这将影响您的工作能力和发现潜在错误的能力。在发行版末尾，如果有错误，您可以将无法测试所花费的所有时间指出为原因之一。
您必须谨慎以有效的方式执行此操作，并明确表示您正在尝试提高质量，而不是手指或责备。通常，当面对事实并了解这如何影响您的工作能力时，开发人员会采用合乎逻辑的方法并提供帮助。
#2 楼
其中一部分从顶部开始。除其他外，团队的表现应根据质量来判断。您需要仔细选择质量指标，以便团队的目标是提高质量，而不仅仅是改善指标。例如，如果您按错误计数来衡量团队，人们将停止记录错误。更大，更厌恶风险的客户期望比早期采用者更高的质量。如果您的产品要求的质量比以前更高，则管理层需要明确说明。其中的另一部分是允许时间/金钱用于改善质量。它可能意味着新的工具/培训/人员，但也可能意味着减慢开发速度，以便开发人员有更多时间在声明完成之前查找/修复错误。
您可能还需要更改一些人员。这可能很痛苦，应该慎重地完成，但是如果开发人员倾向于使用低质量的代码，则正确的答案可能是让他们改用其他角色或组织。测试人员也是如此。
我建议逐步提高质量。如果要将自动化的单元测试插入不使用它的团队中，请从一些适度的目标开始。注意什么有效，什么无效，并准备在必要时改变策略。
#3 楼
一种方法可能是让他们与最终用户和客户一起完成最终时间，以便他们意识到工作的影响，而不仅仅是与键盘和屏幕互动。还要有一种文化，并且必须从上至下以管理者为榜样。快速搜索“质量文化”的Google会带来很多好处，例如http：// www .aleanjourney.com / 2012/05 / creating-quality-focused-culture.html，但请注意，这并不容易，否则每个人都会这样做。
评论
这种想法在实践中如何体现？你能举个例子吗？抱歉回复晚了。好吧，对于开发人员而言，质量并不是一个严肃的话题。有些人至少在进行单元测试，但是当涉及到与测试人员的合作...或消除技术债务，重构等时，没人真正意识到这一点。