敏捷 epic 定义_定义“扩展”敏捷，第5部分：敏捷管理

敏捷 epic 定义

我在组织中看到的挑战之一是经理如何使用敏捷方法。 最大的问题之一是整个组织的组织都是为了提高资源效率（想想职能专家的孤岛）。 敏捷方法利用流动效率 。 思考流动效率会改变一切。

组织中的许多人认为，将工作分配给专家可以更快地完成工作。 制造业就是如此。 （想一想）。制造过程利用资源效率达到合理的效果。 但是，制造业并不能说明创新或学习。 （制造过程的设计是创新的，需要学习。因此，制造过程在开发过程时常常会原型化（重复其工作）。）

需要针对创新或学习进行优化的组织会意识到人们之间的协作。 协作工作（包括管理工作）要求流量效率而不是资源效率。

流动效率可帮助人们优化“向上”性能，以免缺少更好的期限。 （如果您尚未阅读《 这就是精益：解决效率悖论》，建议您这样做。）

一旦开始考虑流量效率，就可能开始考虑吞吐量（可能还有循环时间和累积流量）。 这改变了经理制定决策所需的数据。

现在，任何人的利用率都没有关系。 重要的是延迟成本 （或延迟/持续时间成本）。 瓶颈在哪里以及谁可以消除这些瓶颈甚至可能很重要。

组织可能仍需要跟踪项目，程序甚至工作组（例如客户支持）的运行率。 当您可以衡量收入，客户获取和留存率以及使客户多久返回一次并购买更多商品时，运行率可能并不重要。 （您交付价值的次数越多，您获得的付款客户越多。）

一位经理了解了流量效率。 她管理着负责公司“最重要”项目的团队。 她决定停止跟踪利用率。 她告诉她的团队：“我想跟踪您作为一个团队的吞吐量。 我想知道我能做些什么来改善您团队的工作流程。 请把您的障碍带给我，我将解决它们。”

团队向她介绍了构建时间（太慢），测试自动化不足（不够而太慢）。 她使用“延迟/持续时间成本”构建了案例，以使其他团队帮助该团队减少构建时间并提高测试自动化。

这些团队花了八周的时间进行所谓的基础架构改进。 在这八个星期的头两个星期之后，团队完成了所有故事开始之前的两倍（2个而不是1个）故事。 该团队继续提高吞吐量。 到八周结束时，团队能够完成8到12个故事。 该团队继续保持了目前更高的吞吐量水平。 三个月后，该组织吸引了更多的客户。 他们决定转向其产品的订阅模式，并获得更多收入。

是的，团队具有交付价值的能力，可以快速创建用于管理的反馈循环：产品管理，项目组合管理。

（我仍在阅读有关敏捷有用的指标，因此，我确定这里还有更多内容。）

如果管理人员担心流程效率，他们会问团队：“我该怎么做才能提高您的吞吐量？” 经理们管理项目组合。 工作流经团队，而不是人员。

这改变了经理的工作。 高层经理（可能还有产品经理）定义策略，并与客户交谈以了解客户的需求，以便他们改进策略。 高管人员还考虑了全新产品的新选择-策略的改变。

中层经理计划和重新计划项目组合以实施该策略。 一级经理消除了协作的障碍。

让我总结一下：

敏捷管理者的角色与传统管理者的角色截然不同。 他们的管理方式不同。 敏捷管理者可能会使用精益的两个Struts：尊重人和持续改进作为其管理风格的基础。 对我而言，这意味着与经理“管理”的每个人建立关系，愿意质疑所有假设，并要全面审视：作为一个组织成功，我们需要做什么。 一个功能成功而不是我们所有人成功的想法消失了。

流程效率改变了企业文化：经理改变了他们的讨论。 管理者改变了他们所获得的回报。 经理改变了他们对待人的方式以及他们期望人们如何被对待的方式，因为这与个人的“资源”无关。 这是关于工作系统的。

到目前为止，除了这些帖子：

• 定义“扩展”敏捷，第1部分：创建跨功能要素团队
• 定义“扩展”敏捷，第2部分：产品开发的程序管理
• 定义“扩展”敏捷，第3部分：创建敏捷产品开发能力
• 定义“扩展”敏捷，第4部分：在产品开发之外共享敏捷
• 定义“扩展”敏捷，第4A部分：在产品开发之外共享敏捷

我敢肯定这篇文章并不完美，但是我还有其他工作要做。 我希望再有一个摘要帖子。

翻译自: https://www.javacodegeeks.com/2017/06/defining-scaling-agile-part-5-agile-management.html

敏捷 epic 定义