我正试图弄清楚如何解决我的团队在尝试应用敏捷时面临的一些挑战。目前引起最大麻烦的是由于项目进入业务的双重角色性质。
基本上，我们有许多软件可供我们为各种市场生产和部署。该软件按季度发布周期进行规划和确定。与此同时，我们签订了大合同，需要1-3个月才能完成。问题来自这样一个事实，即管理层希望首先处理收到的合同，并且所有正常安排的发布工作都被搁置一旁，以便将下一份合同推出门外。
我们试图将发布范围限制在3个月以内，以便合同必须等待很长时间才能开始工作。
在尝试应用敏捷时，有没有人处理过这样的场景？有哪些想法/方法可以处理发布范围/计划工作，并使管理层对及时交付高优先级合同感到高兴？
答案 0 :(得分：2)
我能看到的唯一方法是内部市场 为您的“真实”产品的下一个版本分配一个$值，然后您可以相当地分配与传入合同相比的努力。
当然，“真实”产品的价值取决于管理层，但至少它以合理的方式将问题推到了它们身上。
答案 1 :(得分：1)
即使在敏捷的工作场所，管理层也存在某种“资源规划”。只要合同何时进入可预测性，就可以在每次迭代开始之前决定团队和团队之间的人员分配。
如果发生意外事件并且有必要终止冲刺，或者在迭代中重新规划它，那么这就是你必须做的事情。
敏捷方法应该帮助您“拥抱变革”，并确保首先提供最高价值要求。它们并没有改变这样一个事实：人们总是要做更多的工作，但它们确实提供了一个管理混乱的框架，如果人们对优先事项，实际人员配置水平和工作率不切合实际，这将导致混乱（或“速度”）。
敏捷并不意味着没有困难的对话，但如果做得好，那么对话应该主要及时发生以采取某种纠正措施。
我假设有某种官方批准的敏捷程序到位。我不相信敏捷方法（例如Scrum）可以在雷达下工作，因为：
从上面的评论中，您的流程看起来状态非常好。您发现了一个真正的业务问题，并且正在与您的管理团队进行建设性对话。
答案 2 :(得分：1)
您可能会将其视为一个较大的项目，而不是将您的情况视为多个较短的项目，而这些项目会交错进入一个较长的项目。然后小项目变成中断或相当于范围变化，这是所有大型项目都需要学会管理的事情。
与中断和范围更改一样，您需要解决计划影响，“上下文切换”开销对员工的影响等等 - 并且可能考虑删除功能或以其他方式减少以便使您的下一个预定交货日期。
如果管理层希望首先完成新工作，而主线项目被搁置，那么在我看来，你应该给他们什么。为什么在开始新项目之前拖你的脚30或45天？从单个较大项目的角度来看，这当然不是很敏捷。您可以改为更快地开始，然后传达产生的影响。
从长远来看，您可能会发现某些员工因定期更改课程而放慢速度。在这些情况下，您可以考虑进行半永久性分配，这样他们就可以继续他们正在进行的工作，即使在发生中断的情况下也是如此。类似的安排在较大的中断驱动的商店中是典型的。
答案 3 :(得分：0)
如果你没有得到管理层的支持，那么做敏捷是非常困难的。
听到它的声音，管理层目前没有问题。他们放弃了你的合同，你这样做，季度发布单，但他们得到了不错的合同款。
你的团队是否足够大，你可以把它分成两个团队：一个专注于内部发布，一个专注于合同工作，或者可能是两个团队在每次发布后交换责任，这样他们每个人都可以花一些时间在绿地和BAU项目的一段时间。
在一般的敏捷方法论文中，你最好使用看板而不是Scrum，因为听起来好像你试图计划迭代，你最终将90％的工作放在意外的“合同进来”中列。
谁在推动您产品的季度发布：客户要求或您想做什么？就像mgb说的那样，企业从中赚取了多少利润？
答案 4 :(得分：0)
我认为首先要明确“应用敏捷”的含义。敏捷有很多不同的部分，我会尝试从你可以做的部分开始。例如，你有连续构建运行吗？您是否开发了产品待办事项？
很难开始处理多个项目，但没有管理层的支持（如Wysawyg所述），很难变得更加敏捷。您需要在管理成本节约方面展示敏捷开发的好处。你确定了为什么要变得灵活吗？它将如何帮助？一旦你说明原因，然后开始做一些你可以做的事情，在你开始看到一些改进后，与管理层讨论更大的部分。