敏捷 epic 定义
我们可能会开始考虑将敏捷方法视为项目变更。 但是，如果您想“扩展”敏捷性，那么整个文化都会发生变化。 以下是该系列的列表以及一切如何改变组织的文化：
- 定义“缩放”敏捷，第1部分：创建跨功能要素团队。 没有功能团队，我看不到如何才能拥有必要的协作来使敏捷方法成功。 这是从功能孤岛转向产品交付的开始。
- 定义“扩展”敏捷，第2部分：产品开发的程序管理。 计划团队使您可以在组织足够的情况下从项目转移到计划。 这是从小型筒仓过渡到涉及更多组织以产品形式交付价值的扩展。
- 定义“扩展”敏捷，第3部分：创建敏捷产品开发能力。 多个级别的自适应和迭代计划使组织能够立即而不是永久地进行提交。 这创造了一个有弹性的组织的开始。
- 定义“扩展”敏捷，第4部分：在产品开发之外共享敏捷。 工作组需要以不同的方式来思考敏捷方法。 一旦工作组意识到如何为组织的其余部分做出贡献，他们便为组织提供了更频繁地交付价值的能力。
- 定义“扩展”敏捷，第4A部分：在产品开发之外共享敏捷。 不同的工作组需要不同的方法。
- 定义“扩展”敏捷，第5部分：敏捷管理。 管理层在可能的情况下创建和培育协作和优化“向上”的文化。 从资源效率（和财务）转移到流量效率有可能改变一切。 管理人员掌握了创建弹性组织的关键。
所有这些“扩展”的想法都需要改变。
敏捷组织一直非常擅长于微小的更改。 它们具有适应性和弹性。 他们了解变化是如何工作的，并接受变化。 （几乎每个人都很难进行大的更改。小的更改通常会容易得多。）
这是Satir变更模型的图片。 我们以某种程度的性能开始于“旧状态”。 一些异物的到来，而我们在混乱中寻找不一样的表现时，我们的表现却不平衡。 我们发现TI并将其实践并将其整合到我们的工作中，直到我们达到“新状态”，并希望达到更高的性能水平。
变更模型适用于每个人和整个组织。 实际上，在人们对常规的大大小小的变化感到满意之前，我看不到如何建立一个敏捷的组织。 这就是我说我们应该采取敏捷方法进行敏捷的原因之一。 （请参阅“ 敏捷不是银弹” 。）
您需要成为一个完全适应性强且具有弹性的组织吗？ 只有你可以回答那个问题。 也许您从团队和项目组合开始。 也许您正在寻找不会“优化”优化的激励措施。 （为此，我需要一个新词！您对我有建议吗？请这样评论。）
您不必拥有一个完全敏捷的组织就可以在团队和项目组合级别上认识到收益。 敏捷并不适合所有人 。
确定您的组织要成功需要进行多少更改。 尽可能多地练习更改。 这将比敏捷标签提供更多帮助。
最后一个评论：我不确定“缩放”是否是思考此问题的正确方法。 对我而言 ，扩展性想法仍然植根于孤岛思维，而不是流程思维。 那可能就是我。 （咧嘴！）我希望我有更好的方法来解释它。
我关于扩展敏捷性的想法是根据我们的变化能力创建一种文化：
- 我们如何互相对待？ 我们/我们是否可以将彼此视为整体的内在部分？
- 我们讨论什么？ 我们讨论“失败”还是学习机会 ？
- 我们有什么奖励？ 我们如何转向奖励非孤岛工作？ 也就是说，交付产品（在项目或程序中）或其他奖励协作和流程效率的工作。
希望您喜欢这个系列。 请对任何帖子发表评论。 我对您的想法感到好奇。 我将从您的评论中学习。
翻译自: https://www.javacodegeeks.com/2017/06/defining-scaling-agile-part-6-creating-agile-organization.html
敏捷 epic 定义
