敏捷 epic 定义
关于缩放敏捷性，我一直感到困惑。 我正在写我认为是由四部分组成的系列来定义它，所以我们都谈论同一件事。
当我要求人们定义敏捷扩展的含义时，他们谈论的是以下可能性：
- 他们有敏捷的开发人员。 他们想要敏捷的测试人员。 这将为项目创建跨职能的敏捷团队。
- 他们已经成功完成了一个或两个团队的敏捷项目。 现在，他们已经准备好进行敏捷程序。
- 他们拥有敏捷的产品开发（可能称为IT或工程或R＆D或其他产品），并且他们希望在市场营销，财务，人力资源领域共享敏捷方法。
- 他们想建立一个完全敏捷的业务。
每个都不同。 每个问题都为组织解决了一个不同的问题。 这篇文章是关于＃1的：开发人员在其单一职能团队中一直很敏捷。 他们希望带动测试人员，并创建跨职能的团队。 （这可能是测试人员敏捷的另一种方式，但是我还没有看到。我看到测试人员使用迭代和增量方法，但这通常是对开发人员的React。）
我在第1部分的迭代中写了关于交错迭代的问题。 当开发人员与测试人员的节奏不同时，他们的行为就不会像跨职能的功能团队那样。 “团队”没有提供完成的功能。 他们没有像团队一样解决问题。 他们经常有大量的在制品。 使用迭代不会使团队敏捷。
另一方面，如果您可以从这里开始，那就从那里开始。 敏捷“扩展”的下一部分是转到跨功能的功能团队。 这是团队以协作的方式一起工作以创建完成的功能的地方。 您可能需要反复进行此操作，尤其是在您仅听说过Scrum的情况下。 您可以使用看板来查看团队中所有工作流程和瓶颈。
我一直在谈论“您的团队”。 敏捷方法使用跨职能团队专注于交付功能。 我在组成团队方面并不大。 那是因为他们推迟完成功能的交付。 我也讨厌“共享服务”的想法（和名字）。 稍后再写博客。
您可能会想，“开发人员很敏捷。 我们将敏捷地扩展到测试人员。” 如果这是人们在您的组织中考虑敏捷的方式，那么也许这就是您可以做的最好的事情。 这可能是您的重新构架：
从一个职能扩展到跨职能团队。
当您（和您的经理）开始考虑跨职能团队而不是职能部门时，您就开始意识到敏捷的好处。
如果您认为扩展敏捷度是职能团队之间共享敏捷度，请考虑阅读我即将出版的《 创建成功的敏捷项目》一书。 我仍在编辑中，然后将其审核。 我们预计它将在7月上市。
我确实有审稿人，但是如果您在敏捷方法方面苦苦挣扎，请告诉我您是否想成为审稿人。 我们可能还有空间供另外几位审稿人使用。
翻译自: https://www.javacodegeeks.com/2017/05/defining-scaling-agile-part-1-creating-cross-functional-feature-teams.html
敏捷 epic 定义
