• 对齐工具、流程、标准、指标和术语跨团队尽可能多
• 使团队定期交付功能障碍最小化
• 大多数决定下放到小,授权团队
• 协调/编排更小的努力,而不是作为一个大的程序管理
• 使用回顾和持续过程改进保留敏捷实践

程序与多个开发团队需要协调跨团队超越日常团队会议。这可能发生在每个团队满足每日scrum master或根据需要基于集成的水平——否则称为开会scrum的scrum。其他功能专家可能会需要满足跨团队协调架构、测试、成本、资源、性能和其他集成触摸点。反过来,这可能需要员工水平高于团队促进协调和集成和企业负责设计、架构、流程、标准、和工件。这些工程的项目团队必须调整每个努力确保适当使用严格的方法没有引进重量级过程就否定敏捷方法的好处。

大型敏捷项目必须有清晰的结构,定义了任务和商业环境的分区指导更大范围的开发工作12个月或更少,可能为多个并行开发工作。如前所述,技术架构框架应该单独的开发工作,确保单个产品可以在目标环境中运行。

敏捷强调速度和响应不断变化的用户需求超过高度详细的预先定义的系统架构。每个程序必须包括定期评估发展的技术架构,以确保整个系统继续反映出健全的工程原则,如可扩展性、可支持性和可伸缩性。

集成多个较小的开发工作需要一个严格的方法,从高层开始“路线图”计划描述了进化更大的系统以扩展敏捷框架“架构是有意的,设计中”。作为单独的开发努力完成他们的任务,测试必须确保独立的组件结合路线图和符合总体技术架构。下列事项代表额外风险管理相关领域的大规模的、多方面的项目使用敏捷方法:

• 成本估算。当多个团队并行工作完成一个工作,估计成本会变得复杂,随着团队估计,完成他们的任务在不同的利率。项目经理必须了解团队使用评估过程以及它们与程序的总体成本。
• 架构。虽然敏捷方法中心快速交付能力,项目经理不能忽视重要的基础架构需求。短期计划以满足迭代功能可能会导致紧密耦合的架构,如果程序征收沉重的代价必须添加新功能。特别是当一个项目涉及横切需求如安全性、性能和可用性,项目经理必须确保开发人员花时间在项目的早期设计一个能够支持迭代开发和基础设施总体质量属性。
• 沟通。敏捷实践需要关闭和恒定的所有利益相关者之间的沟通。如果多个团队正致力于一个项目,所需的交流增加每n (n - 1) / 2的公式,其中n是团队的数量。项目经理必须考虑如何加快通信,尤其是在地理位置分散的团队。
• 软件代码集成。持续集成涉及端到端构建代码库的变化频繁,这就变得尤其重要的软件开发工作范围的增加,需要多个系统交互,以满足最终用户的需求。项目经理应该确保他们的程序使用适当的环境中开发和测试工具,版本控制和变更管理机制将持续集成到开发工作。
• 测试。敏捷强调的重要性进行测试在整个软件开发生命周期早期和持续。除了单元测试和验收测试,回归测试提供更短和更频繁的迭代是至关重要的。介绍了每个更改,程序应该执行回归测试,以确保整个系统的完整性。在敏捷环境中自动化测试工具是至关重要的。
• 派生需求。大规模项目自然包括许多可能成为积压的需求。项目经理和产品所有者应该定义隐含需求,优先考虑质量和架构上重要的属性,并将优先支持端到端功能的需求。然后他们应该定期审核活动计划安排,并确保项目优先顺序处理。

以下是主要的商业规模敏捷方法。有许多共同的主题和方法,但每个人都需要为独特的收购在联邦政府承包商的关系。在未来的AiDA版本,我们将强调政府的几个例子的应用这些方法对他们的环境。

Scrum的Scrum

scrum技术范围内的多个团队工作在相同的产品,他们的相互依赖关系,允许团队讨论进展集中在如何协调交付软件,特别是在重叠的地方和集成(维基百科)。72%的受访者最近VersionOne调查使用Scrum的Scrum敏捷在其组织规模。看到更多的细节Scrum。

安全知识库是一个经过验证的成功模式实现Lean-Agile软件和系统开发在企业规模。它提供了全面的指导工作在企业投资组合,价值流,项目和团队的水平。多见于按比例缩小的敏捷框架和下面的视频。

少提供了两种不同的大规模Scrum框架。大多数扩展元素的重点是导演的关注所有的团队在整个产品,而不是“我的一部分。“全球和“端到端”的焦点可能是占主导地位的扩展来解决问题。这两个框架——基本上是单一团队Scrum扩大——是:

• 少:8个团队(8人)。
• 减少巨大:几千人在一个产品。

看到更多的细节少和下面的介绍视频。

战略敏捷性尺度指的是敏捷和精益战略的应用程序在您的整个组织。从IT的角度来看这包括大多数,如果不是全部,你的IT交付团队以及IT级别的团队活动,如企业架构的支持,操作,支持(服务台),项目组合管理,IT治理和其他话题。从企业的角度包括组织内所有部门和团队,不仅你的IT部门。看到更多的细节爸爸。