敏捷项目管理计划_信任，敏捷计划管理和有效

敏捷项目管理计划

如果您阅读我最近的文章《 比较团队没有用：暴露另一个管理神话》和相关评论，您会发现我对规范故事点以预测程序成本或进度的工作感到rant之以鼻。 这导致了针对程序或其他框架或程序生命周期的关于SAFe的评论。

一切始于信任

您的管理层信任您吗？ 当您的管理层要求您提供的估算值超过一个数量级的估算值时，这是因为他们不信任您。 那是因为您没有为他们提供足够的服务。

现在，您可能对此感到不安，可以不理会这个问题，也可以解决此问题。 我喜欢修理。 解决此问题的方法是在较小的功能（不是基础结构）上工作，更频繁地演示和更频繁地发布，前提是您拥有允许您这样做的产品。 我并不是说这很容易执行。

您通过交付来建立信任。 期。

您信任您的管理层吗？ 信任是双向的。

您的管理层必须创建一个组织，其中每个功能团队都有一个产品负责人。 每个功能团队一次都从事一个项目。 没有人将一个项目拖到另一个项目上—工作流经团队。

如果您已经或愿意创建这些条件，则可以为您进行多种形式的敏捷工作。

如果您在项目级别没有这种信任级别，那么为什么要尝试敏捷程序呢？ （请阅读“ 敏捷不是为每个人准备的” 。）

我知道，您会感到压力。 或者，有人说：“您必须变得敏捷。” 您读过《 什么生命周期》吗？ 为您的项目选择合适的模型 ？ 除了瀑布式或敏捷式之外，您还有其他选择，尤其是对于程序。

如果您想使用敏捷来管理程序…

如果要将敏捷用于程序管理，则组织中需要满足以下条件：

• 致力于交付功能的团队。 他们完成了。 如果不是每次，几乎每次都如此，那么他们，团队都是可靠的。 它们不必具有可预测的速度，但是必须具有可预测的吞吐量。 这意味着他们可能没有意识到功能有多大，但是他们会不断完善功能并发布它们。
• 致力于管理项目组合的管理人员，以便工作流经团队。 团队一次只能从事一个项目。 这样，团队就可以在某个功能上进行蜂拥而入。
• 了解如何创建产品路线图并知道如何创建产品积压以供团队/团队使用的产品所有者。

为什么？ 这是信任的基础。 这允许我们从敏捷宣言中得到什么 ：

流程和工具之间的个人和互动

通过全面的文档工作软件

客户合作而非合同谈判

响应计划变更

为什么这个这么重要？ 更改在程序中发生。 它在程序中的发生比在项目中的发生还要多。 如果您不信任在程序上进行决策的人员，那么可以信任谁？

如果您阅读有关小型世界网络的系列文章，那么您会知道我是团队，团队之间的自治 ， 协作和探索的狂热爱好者。 我还是测量的爱好者，以查看发生的风险。

但是管理层想知道，“这个项目要花多少钱？ 这个项目什么时候完成？” 我了解他们想知道。 （顺便说一句，这给我带来了合同谈判的麻烦。）

请记住，估计的定义是猜测。

估算不足以作为项目组合评估的基础

莱芬威尔（Leffingwell）说很多管理团队想要对大型计划进行估算时是正确的。 我去年写了一系列有关估计的文章。

如果您因评估投资组合中的项目而无法进行评估，那注定会失败。 为什么？ 因为您正在尝试预测成本或最不了解项目的日期。 我保证您没有完整的积压。 我保证您对产品一无所知。 我敢打赌，您的程序上没有所有人。 您可能会花费大量的迭代零，而无法获得准确的估算值。 没关系

您必须使用价值作为在项目组合中对项目进行排名的基础。

您不必盲目地进入项目组合排名，特别是如果您使用敏捷方法。 您可以说：“进行一次迭代（或两次或三次），然后创建行走骨骼。 这告诉我们什么？”

如果您的迭代周期较短（例如一到两周），则此方法有效。 如果您的迭代时间超过两周，则此方法无效。 抱歉，您现在正在合同谈判中。

现在，基于团队的知识（或少量团队知识），对这个程序的规模进行SWAG估算。 我将这一步骤定为时间表。 “这个程序值得做吗？” 是一个有效的问题。 这不同于ROI（投资回报率）分析。 这是在问：“如果我们花时间在这个程序上，在花光所有钱之前，我们会得到一些可发布给客户的有价值的东西吗？”

“该程序值得做”与“我们可以释放每个迭代”或“该程序的投资回报率”是一个不同的问题。 “值得做”的问题是一个规模问题。 “我们能否释放每个迭代”只是一个小问题。 ROI问题试图估计待办事项中的每个项目，根据我的经验，待办事项必定会发生变化，这使估计变得毫无意义。 （我看到团队在估计中浪费了团队时间。是的，我有。）

如果使用估计作为评估投资组合中项目的基础，则可能会错过潜在的转换项目。 您将错过那些有能力在竞争中领先光年的项目/程序。 为什么？ 因为你无法估计它们。 为什么？ 因为您之前没有做过！ 您没有奇怪的线索，他们需要多长时间。 你可以撒谎和赃物。 或者，您可以提供行走的骨骼并继续对其进行重新估计。

或者，您可以做我们自远古时代以来所做的事情：在频繁的里程碑上提供临时交付物并显示您的进度。 敏捷使我们能够做到这一点。 分阶段交付也是如此，因为这是一个增量的（而不是迭代的）生命周期，这就是为什么我喜欢它。 您构建产品并显示进度。 如果您来自公司的工程部门，则这是并行工程。

当您显示进度时，便会建立信任。 您可以合作。

改变是好的，尤其是在程序中

记住，敏捷中，我们欢迎变革。 我们希望更改积压的订单。 记得在组织敏捷程序，第4部分：从团队开始并进行工作时 ，我讨论了团队如何在其他积压的整个程序中工作？ 您希望在敏捷程序上使用它。 路线图并非一成不变。 程序路线图注定要改变。

团队需要能够发布每个（简短的）迭代。 这就是使该计划有效的原因。 这样就可以更改程序。 这使公司可以更快地发布有价值的产品。

请记住，功能团队发布与发布产品不同。 产品发布是业务决策。 功能团队发布是集成问题。

改变积压创建一个更有价值的程序

当您更改积压订单时，尤其是在程序中，可以创造更多的价值。 这就是为什么提前估计会限制您在项目组合中的选择的原因。 您可能需要知道该项目是否大于面包箱。 但这就是为什么我在评估项目组合时会与客户一起使用卡片和便签的原因。 人们处理卡片，他们对项目的含义有共同的认识。

一旦他们讨论了卡片，现在他们就了解了项目的规模。 他们说：“好吧，我们让这个项目运行到这个里程碑或直到我们看到这一点，然后我们才能重新评估。” 那很棒。 这正是您想要在项目组合级别进行的讨论。 也许里程碑是您花了多少钱。 但这很有可能实现了功能集。 或在一定时间范围内实现的功能集。

这是您组织的策略。 发起人需要讨论。 他们需要为组织带来什么有价值的问题。 只要产品开发组织逐块交付，他们就可以继续进行讨论。

如果赞助商真的希望您停止交付以开始估算，那就好。 你可以做到的。 只要他们意识到在项目结束之前您对估算值的置信度小于100％，就可以了。 因为待办事项将要更改，对吗？ 因此，您永远无法对自己的估算有100％的信心。

哦，如果您认为可以提出带有假设的单点日期？ 哈哈！ 没有人听过您的假设。 没有人。

管理层想要什么

管理层要安慰。 管理层想要一个水晶球。 管理层希望拥有甘特图的错觉。 我明白那个。

而且，如果您从不稳定的过渡到敏捷，则不能释放每次迭代。 或者，您的迭代周期不短，如两周。 这意味着您不能足够频繁地进行更改，这意味着您需要进行预测。

我了解管理层希望得到一些安慰。 但是我不相信对管理层撒谎。 我不相信管理。 我相信向管理人员提出一些困难的问题，然后告诉他们真相。 这些人赚了大钱。 他们可以处理真相。

我问的问题：

• 如果我发现程序不正常，您什么时候想知道？ 据我所知； 我做了一些补救工作之后； 当我竭尽所能时，这是一场灾难吗？
• 请为该程序排名项目驱动程序矩阵。 查看项目金字塔，并将每一侧作为驱动程序，约束或浮动对象进行排名。 我将在“ 管理它”中说明如何执行此操作！
• 成功是什么样的？ （我还有其他一些与上下文无关的问题。）

成为敏捷项目经理的效率高

当您过渡到敏捷时，您有一些选择：

• 不要做程序。 （是的，对。）从项目开始敏捷，看看您在组织中需要做什么。
• 就像我在projectmanagement.com文章中建议的那样，混合敏捷部分和非敏捷部分， 使用敏捷项目和传统项目管理程序，以及使用发布 培训来步入正轨。 另请参阅博客文章“ 用敏捷项目和传统项目管理程序” 。 （我没有意识到我已经重复使用了标题。）
• 使用分段交付或按计划设计作为生命周期。 它们是递增的生命周期，并且一直存在。 将它们与时间框结合在一起，您将获得接近敏捷的方法，而不会面临敏捷过渡的文化挑战。 跨职能团队仍对其工作负责。
• 使用SAFe，但不要将其称为敏捷。 您得到的反馈不够频繁。 您不允许经常进行更改。 它不敏捷。 这是一个框架。 这是一种方法。 但这并不敏捷。 对我来说，这并不能建立起双方的信任。 那就是SAFe的问题。
• 在我的小型世界网络中进行实验，并向团队成员说明您想要什么。

哦，我没有提到的选项：确定敏捷过渡出了什么问题并修复。 为什么不能每两周发布一次产品？ 您的“开销”是多少？ 还是“障碍？” 你为什么每周不能释放？

如果您不能每两个星期作为一个团队发布，那么作为程序的不发布将不会变得更好。 随着团队的增加，情况只会变得更糟。 敏捷将使其透明。 任何程序都将使其透明。 敏捷将使您的问题更加透明。

您应该选择哪种敏捷方法？

我写信并咨询您，以实用的方式帮助您提高工作效率。 这就是为什么我不学任何东西。 我不信奉任何敏捷方法。 我经常为客户混合并融合敏捷方法。 他们在其中发现了巨大的价值。

如果您要开始向敏捷过渡，请先问自己：“我们为什么要过渡到敏捷？” 敏捷与应对变化的能力有关。 您可以通过技术和管理学科获得此功能。 两者都需要。

您不能仅仅从提供功能的技术团队那里得到它。 如果管理层不能通过创建产品所有权，创建合理的工作环境以及管理项目组合来发挥作用，那么技术团队将无法交付。

在进入程序之前，请先练习一个小型敏捷项目。 习惯于每周提供功能。 习惯于根据价值评估项目组合。 习惯于让一个产品所有者为产品制定路线图以及该产品的产品积压。 那很困难。

了解组织的问题所在并可以解决之后，现在就可以移至某个程序。 您将遇到更多不同的问题和风险。 但是，至少您不会开始敏捷过渡。

敏捷与反馈和变革能力有关

如果您以某种方式过渡到敏捷，但是每季度仅从产品所有者那里获得一次反馈，那么敏捷吗？ 我看不出来 也许这不是SAFe的意图。 但这就是我听说过的一些实现的方式。 我就是这样看的。 也许我只是不明白。 这是可能的。

当我与团队合作时，我告诉他们：“我们将从两周的迭代开始。” 他们都gro吟着，告诉我迭代太短了 。 然后我们开始将他们的故事切成小方块。 我曾经问过项目经理， 您对项目的要求有多低 。 现在，我问产品负责人和技术团队：“这个故事的接受标准是什么？ 完成是什么意思？ 我们能做多少，仍然能增加价值？”

你是聪明人。 您可以使任何工作正常进行。 我知道。 但是，要付出多少人的代价？

在我看来，SAFe就像是X理论管理。 我是Y型理论的人。

获得信任并扩大信任

无论您是功能团队还是管理团队的一员，如果您在敏捷的旅途中，都必须赢得并扩大信任。 在功能团队中，您的工作是交付完成的功能。 期。 如果您是管理部门的一员，那么您的工作就是创建一个允许功能团队蓬勃发展的环境。

如果您彼此信任，则管理层可以要求进行数量级估算，并根据价值做出项目组合决策。 通常，如果项目组合团队正在执行工作，而团队正在交付，则他们不需要估算。 管理团队要学会在取消沉没成本之前就取消/杀死项目。

学会有效

在过渡到敏捷时，技术团队和管理团队都需要学习新的行为。 根据我的阅读，SAFe强化了旧的行为。 它推迟了反馈，并没有帮助管理层学习寻找价值而不是估计。 正如我所说，在我看来，它就像是Theory X的管理。

敏捷是Y理论的管理。 告诉别人你想要什么。 为他们提供执行此任务的资源。 滚开 看看他们做了什么。 不久之后，看看积压中是否还有更多价值。 如果是这样，请继续为项目/计划提供资金。

如果您需要有关项目管理和生命周期的更多详细信息以及有关项目和程序的思考方式，请参阅“ 管理它”！ 您的现代实用项目管理指南 。

我仍在努力准备敏捷和精益计划管理的第一个版本：整个组织的合作 。 “秋天”是我最好的估计。 不是早秋

有关敏捷和精益方法的项目组合管理，请参阅管理项目组合：增加容量并完成更多项目 。

参考： 信任，敏捷计划管理，以及来自我们JCG合作伙伴 Johanna Rothman的有效 产品开发博客。

翻译自: https://www.javacodegeeks.com/2013/09/trust-agile-program-management-being-effective.html

敏捷项目管理计划