我希望对此进行一些健康的讨论，而不是specific解决方案，因此我将在社区 Wiki 上讨论它，因为它是一个相当主观的话题。感谢它是否可以作为有用的资源保持开放。
最近，我接任了一个小型技术团队的开发经理。
业务/营销/设计团队与技术团队的比例大约为 4:1，因此您可以想象，尝试将技术团队与一连串的需求隔离开来需要做很多工作。
为此，我们制定了一些适当的流程，使用 SCRUM 进行项目开发，要求业务团队成员填写适当的需求文档、用例等......
在我们第一个主要版本发布后的几周内，我们将向业务团队介绍正确的 UAT 流程、问题报告和变更请求流程以及我们自己改进我们的问题分类和错误修复程序。但正如您可以想象的那样，对于所有相关人员来说，这是一个非常陡峭的学习曲线和思维方式的转变。
只是从技术社区（开发人员、团队领导和开发经理）那里寻找一些一般性的反馈，他们经历过类似的事情以及他们如何处理任何特定的障碍。
一个关键问题是如何确定请求的优先级，每个用户都希望他们的请求首先完成。解决方案是某种定价机制。如果您的部门被视为自助餐，他们昨天会想要所有东西，他们的要求将没有限制。另一方面，如果他们需要在工作开始之前提交请求并为其分配价格，他们会在提出无聊和琐碎的请求之前三思而后行。
这是第 1 个障碍点。
我的要求对于你的小障碍和箍来说太重要了。我懒得浏览您令人费解的“流程”和“文档”。我只是有一个简单的事情，我只需要现在就告诉开发人员。
这个障碍点几乎是无法避免的。 每个人都知道，他们的需求超越了流程、工程、纪律、治理和质量保证。
敏捷性的重点是让这种情况以可控的方式发生。
鼓励对话。让他们发泄。积极地创建、更新和优先处理积压工作。
通过关注积压工作，您可以——在一定程度上——规避营销人员跑进开发人员的工作空间，立即对生产代码进行“紧急手术修复”。这是一场危机。每个人都恐慌！
战争故事。
我们正在竞标重新设计一个糟糕的代码泥潭。在与用户会面期间，用户想知道新应用程序是否允许立即修复。
我想说“嘿 dingbat！由于立即修复，您现在陷入困境！”
相反，我说，“根据最佳质量保证实践，我们将尽快做出改变。我们希望做出响应。但是......”
文化很难改变。
第一件事是永远不要例外，做一些没有正确提交到新系统的事情。除非您强制执行，否则他们将永远学不会使用新系统。尤其是在过程开始时，确实需要坚固性。令人惊讶的是，一旦他们实际上需要做更多的工作而不仅仅是一个电话，那么请求的数量就会减少。
二是公布优先名单。如果需要将优先级列表向上移动，客户端（在这种情况下为内部客户端）可以仅将其移动到他自己的东西之上（当然假设如果任务 A 没有首先完成，它可以完成）。如果他需要它超越其他人，他必须得到所有其他工作在他之前的人的同意。这不是你做的，而是他做的。这将减少优先事项的转移。它还将节省您的时间和争论。每个内部客户都可以单独与您交谈以设置他们自己的优先级，但您可以控制整个列表。一旦开发人员开始了一项任务，如果可能的话（并且不亚于生产问题导致系统瘫痪），请确保他在转移到下一个最高优先级之前完成了该任务。
您应该保留确定是否存在需要改变优先级的真正紧急情况的权利。这应该只发生在生产停止并且系统不能被很多人使用的情况下（一个人无法登录并不是紧急情况，除非它是 CEO！）。在这种情况下，请务必告诉内部客户他们的工作被推迟了。沟通是关键。
我是一名在业务方面工作了一段时间的工程师。
关键是让商业人士经常与您互动。倾听，提出问题，内化他们正在讨论的内容的价值。你想让每个人都觉得你是他们的私人礼宾，在整个过程中帮助 Shepard 提出他们的要求。
有了这些信息，您就可以更有效地开展敏捷开发流程——您的业务团队将对流程和功能管道开发充满活力和信心。