TOGAF 敏捷冲刺：15 天 Scrum 冲刺实践

TOGAF的定义：

（开放群组架构框架）是一种企业架构方法，它提供了一种用于设计、规划、实施和治理企业信息系统的结构化方法。其核心组件架构开发方法 (ADM) 可指导组织完成架构开发的各个阶段，以确保 IT 战略与业务目标保持一致。通过推广标准化和最佳实践，TOGAF 可帮助组织提高架构计划的效率并降低风险。 

TOGAF 的关键组成部分：

1. 架构开发方法 (ADM)：TOGAF 的核心部分，概述了架构开发的分步方法。它包括准备阶段、架构愿景、业务架构、信息系统架构、技术架构、机遇与解决方案、迁移规划、实施治理以及架构变更管理等阶段。
2. 架构内容框架：它定义了可以生成的各种类型的架构内容及其关系。这包括可交付成果、工件以及架构描述的结构。
3. 企业连续体：一种将架构和解决方案工件按从通用到具体的不同抽象级别进行分类的方法。这有助于组织了解其架构的全部范围。
4. TOGAF 资源库：一套指南、模板和其他资源，可帮助您有效地实施 TOGAF。
5. 架构能力框架：重点关注有效架构治理和管理所需的组织能力。

TOGAF 的优势：

• 标准化：为整个组织提供通用的语言和方法。
• 高效协作：促进不同利益相关者之间的协调和沟通。
• 降低风险：有助于在开发过程的早期识别和降低风险。
• 灵活性和可扩展性：适应各种组织环境和需求。

简介：Scrum 与 TOGAF 10 敏捷架构的契合

TOGAF 10 引入了模块化、敏捷性和支持迭代和增量开发的架构模式。它强调数字化企业，并在更广泛的架构开发方法 (ADM) 中支持敏捷交付。

Scrum 是一个流行的敏捷框架，可以无缝衔接 TOGAF 的架构实现和变更交付阶段。它使架构团队和产品团队能够持续交付与业务目标相符的价值。

为什么要采用 15 天冲刺？

15 天冲刺（3 个工作周）在价值交付和架构适应性之间取得平衡。它通过启用短反馈循环并保持架构完整性，与 TOGAF 10 的模块化 ADM 周期相契合。

Scrum 中的角色（与 TOGAF 术语对应）：

• 核心 Scrum 工件（与 TOGAF 保持一致）：
• 产品待办事项列表：与架构需求库关联。
• 迭代待办事项列表：源自基于能力的规划输出。
• 增量：与解决方案构建块 (Solution Building Block) 和能力交付保持一致。

15 天迭代时间表：与 TOGAF 保持一致的 Scrum 仪式

我们假设每周工作时间为周一至周五，持续三周。以下时间表包含与 TOGAF 10 个模块相关的活动。

第一天：迭代规划（ADM 阶段：变更交付规划）

• 目的：定义与业务能力和架构护栏保持一致的迭代目标。
• 参与者：产品负责人 (PO)、开发团队、项目经理 (SM)（如有需要，可与架构负责人共同参与）。
• 活动：
• 从与架构构建块 (Architecture Building Block) 相关的史诗故事中选择高优先级待办事项。
• 定义冲刺目标：例如，“交付符合身份架构的安全用户身份验证”。
• 分解成与构建块相关的技术任务。
• 时间限制：4 小时
• 输出：冲刺待办事项列表、冲刺目标、架构工件的可追溯性。

第 2-14 天：每日站会和迭代开发（ADM 阶段：变更实施）

每日站会（站立会议）

• 目的：同步进度、识别阻碍因素并保持架构一致性。
• 参与者：开发团队，可选的 PO/SM。
• 活动：
• 我完成了哪些工作（相对于冲刺目标）？
• 下一步我将做什么？
• 有任何架构/技术阻碍因素吗？
• 时间限制：15 分钟
• 输出：更新的看板，发现的风险。

开发活动

• 编码、测试、集成、UI/UX 设计
• 持续验证 TOGAF 的架构契约（例如，遵循身份/数据架构）。
• 通过燃尽图和看板跟踪工作进度。

待办事项细化（第 7 天和第 12 天）

• 目的：准备与即将发生的功能变更或架构优先级相符的故事。
• 参与者：产品负责人、开发团队、可选的架构师。
• 活动：
• 整理与架构路线图相关的史诗故事。
• 添加与业务/技术约束相符的验收标准。
• 时间限制：1 小时/场次
• 输出：细化的产品待办事项，并考虑架构方面的考量（例如，非功能性需求）。

第 15 天：迭代评审和回顾（ADM 阶段：收益实现）

迭代评审

• 目的：演示工作增量并收集反馈。
• 参与者：Scrum 团队 + 利益相关者（例如，企业架构师、业务负责人）。
• 活动：
• 展示可运行的功能（例如，移动设备上的安全登录）。
• 根据功能目标状态和架构标准进行验证。
• 收集反馈意见以供将来改进。
• 时间：2 小时
• 输出：已验证增量，反馈循环至产品待办事项列表和架构库。

迭代回顾

• 目的：检查团队协作、工具、架构遵循情况，并规划改进措施。
• 参与者：仅限 Scrum 团队。
• 活动：
• 哪些方面进展顺利（例如，CI/CD 流水线与基础架构架构保持一致）？
• 哪些方面有待改进（例如，数据流图中的差距）？
• 行动计划（例如，在下一次改进中纳入架构评审）。
• 时间：1.5 小时
• 输出：改进待办事项列表，调整后的团队流程。

实际示例：移动应用 - 符合 TOGAF 标准的迭代

项目背景：构建移动健身应用的身份验证模块。

迭代目标：

“使用 Azure AD B2C 实现安全的用户登录，并与企业身份架构保持一致。”

产品待办事项：

epic：“用户管理”
story：作为用户，我可以使用邮箱/密码注册。
story：作为用户，我可以通过 OAuth2 安全登录。
story：作为管理员，我可以查看新用户统计数据。

架构集成：

架构视图：身份架构、集成层。
ABB：身份验证服务模式、可重用的 Azure API 网关。
SBB：Azure B2C 配置、移动 SDK 集成。

冲刺输出：

增量：已与 Azure AD B2C 集成的登录功能。
可追溯至：TOGAF 能力图 → 架构路线图 → 解决方案构建块。

最佳实践和 TOGAF 驱动技巧

高级实践：

1. Sprint 规划中的架构护栏：
使用 TOGAF 参考模型（例如 TRM、III-RM）作为架构边界。

2. 治理接触点：

使用架构契约验证交付是否符合非功能性约束（例如性能、安全性）。

3. 基于能力的待办事项管理规划：

将故事与战略业务能力相结合，确保企业可追溯性。

挑战与解决方案：

架构漂移：

• 解决方案：在细化和审查期间纳入架构师或治理检查表。

交付成果不一致：

解决方案：应用与 TOGAF 架构库（标准、模型）关联的共享“完成定义”。

存储库（标准、模型）

缺乏战略一致性：
解决方案：将 Sprint 目标与架构能力（而不仅仅是功能请求）联系起来。

总结与类比

将 TOGAF 中的 15 天 Scrum Sprint 视为一个迷你 ADM 周期，其中：

• Sprint 计划类似于初步 + 变更计划；
• 每日 Scrum 类似于迭代变更实施；
• Sprint 评审和回顾反映了收益实现 + 架构治理。