双带宽敏捷团队？

Question

我正在尝试找出如何解决我的团队在尝试应用敏捷时所面临的一些挑战。目前最令人头疼的是进入业务的项目的双重角色性质。

基本上，我们为不同的市场生产和部署了许多软件。此软件按季度发布周期进行规划和限定范围。与此同时，我们也有一些大合同需要1-3个月的时间才能完成。问题来自于这样一个事实，即管理层希望首先处理传入的合同，而所有正常安排的发布工作都被搁置一边，以便让下一个合同离开。

我们试图将发布的时间限制在3个月以内，这样一份合同就必须等待这么长时间才能开始工作。

有没有人在尝试应用敏捷时遇到过这样的情况？有什么想法/方法来处理发布范围/计划的工作，并让管理层对高优先级合同的及时交付感到满意？

Answer 1

与其把你的情况看作是交错在一个较长项目中的多个较短的项目，不如把它看作是一个较大的项目。然后，小项目就变成了中断，或者等同于范围变化，这是所有大项目都需要学习管理的东西。

与中断和范围更改一样，您将需要解决计划影响、“上下文切换”开销对员工的影响等--并可能考虑删除功能或以其他方式减少，以便完成下一个预定的交付日期。

如果管理层希望先完成新的工作，而主线项目被搁置，那么在我看来，这就是你应该给他们的。为什么要拖上30天或45天才开始新项目呢？从单个大型项目的角度来看，这肯定不是很敏捷。相反，你可以更快地开始，然后传达由此产生的影响。

从长远来看，你可能会发现，某些员工比其他员工更容易受到周期性课程变化的拖累。在这些情况下，您可以考虑进行半永久性的分配，这样即使在中断的情况下，他们也可以继续他们正在进行的工作。在较大的中断驱动的商店中，类似的安排是典型的。

Answer 2

我能看到的唯一方式就是内部市场。

为你的“真正”产品的下一个版本分配一个$值，然后你就可以公平地将精力分配给这个版本和即将到来的合同。

当然，“真正的”产品的价值取决于管理，但至少它以一种理性的方式将问题推给了他们。

Answer 3

即使在敏捷的工作场所，管理层也会有某种“资源规划”。只要对合同何时到来有一定的可预测性，就可以在每次迭代开始之前决定团队和团队之间的人员分配。

如果发生了意外事件，有必要终止冲刺，或者在迭代过程中重新计划，那么这就是你必须要做的。

敏捷方法论应该帮助您“拥抱变化”，并确保最先交付最高价值的需求。它们不会改变这样一个事实，即总是有比人更多的工作要做，但它们确实提供了一个框架，用于管理如果人们对优先级、实际人员配备水平和工作速度(或“速度”)不现实时，这将导致的混乱。

敏捷并不意味着不会有困难的对话，但如果做得很好，那么对话应该会及时发生，以便采取某种纠正措施。

我假设有某种官方认可的敏捷过程。我不相信敏捷方法(例如Scrum)可以在雷达下工作，因为：

1. 敏捷方法是关于自我管理团队的。如果你的管理层不接受团队自我管理的权利，那么就会有一种力量struggle.
2. Agile方法论是关于在团队内部以及团队与其利益相关者之间进行高质量的沟通。如果对利益相关者隐藏该流程，则该流程不起作用。

从上面的评论来看，你的过程看起来相当不错。您已经确定了一个真正的业务问题，并且正在与您的管理团队进行建设性的对话。