敏捷项目管理计划_敏捷计划管理：您将如何交付？

敏捷项目管理计划

我的一个程序管理客户正在组织一个程序，并且在考虑适合他们程序的交付模型时遇到了麻烦。 它们正在过渡到敏捷，并习惯于传统版本。

当我建议他们在核心团队中有代表部署的人员时，这最初是对他们的系统的震惊，现在他们发现这是一个好主意。 他们在核心团队中没有硬件人员，但是在这张照片中，他们看上去很多。

有了敏捷，他们就拥有了前所未有的选择。 由于它们是纯软件产品，因此可以选择像以前一样强制发布。 他们可以像以前一样推出，通过IT安排发布并在人们升级时强制执行。 我问过效果如何。 当我问这个问题时，您应该已经看到人们的视线滚动！

核心计划团队

我建议可能还有其他选择：连续部署和分阶段部署。

通过连续部署，您可以在准备就绪时进行部署。

您确实需要在所有项目团队之间进行持续集成 ，或者您需要以某种方式管理未集成代码的风险。

您需要足够的测试自动化来知道产品不会崩溃，因此您可以继续部署新功能而不破坏旧功能。

记住，程序很大。 想象一下，您至少有50个人正在从事此程序。 该客户预计在满员时将接近150名。 （我认为敏捷方法将意味着他们将需要更少的人员，但这仅是我的意见。目前为止还没有数据。）如果您有5-7人的跨职能团队，则每天或一，两，三个人检查所有已完成的功能，并且每个人都在验证，是的，他们的代码适用于main分支，您每天都有很多进展。 每天。 50个人只有10个团队。 而已。 150个人是30支球队。 谈论一个有自己生命的程序！ 您无法“控制”。 您可以指导它。

有人担心-如果他们在连续部署中首先交付了错误的功能，那会怎样？ 我问了他们的路线图。 谁在更新路线图，多久更新一次？ 迭代进行了多长时间？ 记得短是美丽吗？ 我有机会再次解释。

然后，我们讨论了分阶段部署，其中他们可以在特定时间向客户承诺路线图上的某些功能。 他们可以在特定日期交付构建，并在完成功能后给自己足够的时间来测试那些构建。 我问他们现在是否正在加强冲刺。 他们令人毛骨悚然地说是。 我说那很好，只要他们知道自己在做什么。 我相信对自己诚实。 我问他们是否计划将测试集成到开发冲刺中。 他们试图给我一首关于如何集成测试的歌舞。

我解释说，如果他们现在有强化冲刺的机会，则仅在计划开始8周后，就不会进行测试集成。 他们增加的人越多，他们进行的时间越长，情况只会越来越糟。 他们知道并了解自己的障碍吗？ 做出发布决定是一回事，因为这是业务决定。 这是另一个原因，因为您无法选择其中一个选项。

事实证明，程序产品所有者的功能缺失情况很糟糕。 对于程序来说这可能是一场灾难。 程序产品所有者的所有决策都会被放大，因为这些决策会汇总到功能团队中。 如果您有10个团队，那是一回事。 如果您有30支队伍，那就更大了。 如果您决定不再强调技术债务，而技术团队在创建功能时却没有解决债务问题，那么您可能会得到一些代码，这些代码并非总是可以编译的，不必担心发布。

启动程序时，请考虑如何交付。 正如科维所说：“始于终局。” 没有一个正确的答案。 连续部署可能适合您和您的客户。 可能不会。 您的客户可能会说：“不，我们不希望系统一直在变化。 停下来！” 但是， 您可能会决定希望能够在任何给定时刻发布的规则。 在这种情况下，内部连续部署可能是正确的模型。

如果您有路线图，并且知道何时要提交路线图上的哪些功能，则分阶段部署是一个很好的选择。 您想挑选您的客户并与这些客户仔细合作。 几年前，当我管理Beta版程序并与Beta版客户合作时，我设定了他们对每个Beta版所能获得的期望。 这是相同的想法。 除此以外，您希望有更多的部署。

如果由于硬件或其他一些限制而不得不坚持传统的部署，则必须努力使产品更具吸引力。 您不会将正在进行的工作视为诱惑。

您在内部进行连续部署的工作越多，您的程序产品所有者就越会看到您的工作价值。 这意味着程序可能以更快的速度结束。 值得尝试。

对我来说清楚的是，如果您想在程序中变得敏捷，那么在开始程序管理工作时就需要考虑交付和部署。 交付和发布方式至关重要。 了解发布标准后，您需要知道发布的方式。 没有正确或错误的决定。 这是您的程序的决定。

参考： 敏捷程序管理：您将如何交付？ 从我们的JCG合作伙伴 Johanna Rothman在产品管理开发博客中获得。

翻译自: https://www.javacodegeeks.com/2012/12/agile-program-management-how-will-you-deliver.html

敏捷项目管理计划