我希望有一些健康的讨论会比specific解决方案更有效，所以我将社区维基，因为这是一个相当主观的话题。欣赏它是否可以作为有用的资源保持开放。
最近我作为开发经理接管了一个小型技术团队。
业务/市场营销/设计团队将技术团队的数量大约按照4：1进行编程，因此您可以想象有很多工作需要尝试将技术团队与一系列要求隔离开来。
为此，我们已经制定了一些适当的流程，使用SCRUM进行项目开发，要求业务团队成员填写适当的需求文档，用例等......
在我们首次发布主要版本后的几周内，我们将向业务团队介绍正确的UAT流程，发布报告和变更请求流程＆amp;我们自己改进我们的问题分类和错误修复程序。但正如你可以想象的那样，对于所有参与者来说，这是一个非常陡峭的学习曲线和思维方式的变化。
只是寻找技术社区（开发人员，团队负责人和开发经理）的一些常规反馈，他们经历过类似的事情以及他们如何处理任何特定的障碍。
答案 0 :(得分：3)
关键问题是如何确定请求的优先级，每个用户都希望首先完成请求。解决方案是某种定价机制。如果您的部门被视为自助餐，他们会想要所有的东西，并且他们的要求没有限制。另一方面，如果他们需要提交请求并在工作开始之前为其分配价格，他们会在做出冗长而微不足道的请求之前三思而行。
答案 1 :(得分：1)
这是数字1的障碍点。
我的要求太重要了 你的小障碍和篮球。 我不能为你的导航而烦恼 令人困惑的“过程”和“文件”。 我只是有一个简单的事情，我只是 需要告诉开发人员 现在。
这个障碍几乎是不可避免的。 每个人都知道他们的要求超越了流程，工程，纪律，治理和质量保证。
敏捷的观点是允许这种情况以可控的方式发生。
鼓励对话。让他们发泄。积极地创建，更新和优先处理积压。
通过专注于积压工作，您可以 - 在某种程度上 - 规避营销人员遇到开发人员的立方体，立即对生产代码进行“紧急手术修复”。这是一场危机。每个人都有！
战争故事。
我们正在竞标重新设计糟糕代码的泥潭。在与用户会面期间，用户想知道新应用程序是否允许立即修复。
我想说“嘿dingbat！你现在因为立即修复而陷入困境！”
相反，我说，“与最佳质量保证实践一致，我们会尽快做出改变。我们希望能够做出回应。但是......”
文化很难改变。
答案 2 :(得分：0)
首先，不要做出异常并做一些未正确提交给新系统的事情。除非你强制执行，否则他们永远不会学会使用新系统。确实需要坚固，特别是在过程开始时。令人惊讶的是，一旦他们真的需要做更多的工作而不仅仅是打电话，他们的请求会少得多。
第二次发布优先级列表。如果某些东西需要向上移动优先级列表，那么客户端（在这种情况下是内部客户端）只能将其移动到他自己的东西上（当然假设如果没有先完成任务A就可以完成）。如果他需要它超越别人，他必须得到所有其他人的协议，他们的工作领先于他。这不是为了你，而是为了他。这将减少优先顺序的转变。它还可以节省您的时间和参数。每个内部客户端都可以单独与您交谈以设置自己的优先级，但您可以控制整个列表。一旦开发人员启动了一项任务，如果可能的话（并且没有任何关于系统的生产问题），请确保他在完成下一个最高优先级之前完成该任务。重复启动和停止相同的任务会使代码花费更长的时间，并且在我的经验中更容易出错。
您应该保留确定真正的紧急情况需要改变优先级的权利。只有当生产停止并且系统不能被许多人使用时才会发生这种情况（一个人无法登录并不是一个紧急情况，除非当然是首席执行官！）。在这种情况下，请确保告诉内部客户他们的工作正在延迟。沟通是关键。
答案 3 :(得分：0)
我是一名工程师，已经在商业方面工作了一段时间。
关键是允许商业人士与您联系。倾听，提问，内化他们所讨论的内容的价值。您希望让每个人都觉得您是个人礼宾，通过这个过程帮助Shepard满足他们的要求。
有了这些信息，您可以更有效地完成敏捷开发流程 - 您的业务团队将对流程和功能流程开发感到充满活力和自信。