我刚搬到一家公司，制作团队有 15 人，由后端和前端开发人员、测试人员和创意人员组成。该团队正在同时开展多个项目。它的代理工作，所以项目相当小，一个CMS公司网站，一个基本的电子商务网站，诸如此类。
目前，项目经理每周提出超过 6 小时的资源请求，以将其添加到可提前 6 周运行的长期生产计划中。然后在周五将其转移到下一周的短期计划中。除此之外，还有少于 6 小时的请求。如果我们资源短缺，我们就会聘请成本高昂的自由职业者。
这个每周计划发生了很多变化。由于未满足依赖关系或另一个优先项目进入，工作在发生的那一天被取消。客户没有及时向我们提供创意等。
部分原因是有很多糟糕的计划正在进行，所以我可以从那里开始。虽然，我一直在研究理想的管道/工作时间表应该是什么样子，但找不到任何适用于这种结构的敏捷方法。
有谁知道代理类型的工作是否有敏捷理论？
看板将很容易适应。它是一种精益敏捷方法，允许稳定的流程和重复的东西（例如，重复的计划、重复的演示和发布、重复的回顾，等等），但是因为它是基于流程的和及时的，所以它非常适合优先级每天都在变化或有很多消防的情况。
要启动看板，您可以保留当前的流程和工作流程，开始一些实践（在大型海报/板或电子工具上按工作流程状态可视化工作，对每个工作流程状态设置正在进行的工作限制，并定期召开回顾会议不断改进流程。
精益和看板谈论了很多关于排队理论和约束理论。计划的想法是只计划你需要的。在一个完美的世界里，你只需要知道次高优先级的项目，因为如果你做了太多的批次计划（或批次任何东西，因此 WIP 限制），这可能被视为库存，这是浪费。
看板允许使用服务等级和服务级别协议，根据紧急客户需求、截止日期（例如，错过日期的处罚）、正常工作等来确定优先级。
例如，阻碍客户的问题是第一优先级，甚至可能导致我们超出 WIP 限制并从正在进行的工作切换到满足。这样的工作将在 3 天内完成 90% 的时间。（此类协议应源自真实数据，如果您每天记录项目状态，您将开始积累这些数据，例如，在累积流程图中。）
除了服务等级和 SLA，您还可以规定团队 20% 的时间应该花在这些紧急（“加急”）问题上，60% 用于正常工作（例如功能开发），也许 20% 用于持续改进、卫生、技术故事等。
一般来说，SCRUM 将适用于这种工作负载。唯一的区别是您可能需要稍微修改它，以便您可以将与特定项目相关的任务分组到相同的冲刺中，这样您就不会为每个任务不断切换项目。
从好的方面来说，您似乎已经在进行每周冲刺，所以这不应该是一个艰难的过渡。
最后，如果在 1 周的 sprint 周期中似乎有太多的流失（您提到了当前导致问题的“灭火”心态），您可能想要尝试 1/2 周的 sprint。