0003-执行阶段 » 历史记录 » 版本 8
Huarui Lin, 2026-04-13 11:29
| 1 | 6 | Huarui Lin | # 执行阶段：敏捷迭代与交付 |
|---|---|---|---|
| 2 | 3 | Huarui Lin | |
| 3 | 1 | Huarui Lin | 核心任务：按照计划行动，通过迭代优化产出。 |
| 4 | 4 | Huarui Lin | |
| 5 | 7 | Huarui Lin | ## 下级目录 |
| 6 | [[0001-Sprint1]] |
||
| 7 | |||
| 8 | 8 | Huarui Lin | |
| 9 | 4 | Huarui Lin | --- |
| 10 | 8 | Huarui Lin | ## 交付规划 |
| 11 | 5 | Huarui Lin | |
| 12 | 8 | Huarui Lin | --- |
| 13 | |||
| 14 | 5 | Huarui Lin | 企业级架构通常涉及**多系统协同、高合规要求、复杂的技术债、以及长远的演进路线图**。 |
| 15 | 4 | Huarui Lin | 一个Sprint不仅仅是“交付功能”，更是**“在架构蓝图上铺下一段经过验证的铁轨”**。 |
| 16 | 7 | Huarui Lin | |
| 17 | 1 | Huarui Lin | --- |
| 18 | 7 | Huarui Lin | ### 一、 Sprint 准备与计划阶段 |
| 19 | 4 | Huarui Lin | *目标：将宏观的企业架构愿景，转化为当前Sprint可执行、可验证的垂直切片。* |
| 20 | 1. **架构对齐与史诗拆解** |
||
| 21 | * **拒绝“纯技术”Sprint**：和架构师一起，确保Sprint目标不是单纯的“搭建底层框架”，而是带有业务价值的垂直切片（例如：“实现用户数据从A系统到B系统的实时同步，并支持X场景的查询”）。 |
||
| 22 | * **NFRs（非功能性需求）确认**：明确本Sprint涉及的性能、安全性、高可用性等企业级标准，并将其转化为验收标准。 |
||
| 23 | 2. **跨团队依赖管理** |
||
| 24 | * **依赖地图**：企业级项目必然涉及多个上下游团队（如基础设施组、安全组、其他业务线）。必须在这一阶段画出依赖关系网。 |
||
| 25 | * **联合Sprint计划**：组织关键依赖团队的代表参加我们的计划会，敲定接口契约、数据格式和联调时间窗口。 |
||
| 26 | 1 | Huarui Lin | 3. **确定Sprint目标** |
| 27 | 4 | Huarui Lin | * 用一句话向高管和业务方说明：这个Sprint我们在企业架构演进上迈出了哪一步？（例如：“本Sprint我们将完成单体订单服务向微服务拆分的第一个节点，并验证新消息队列的稳定性。”） |
| 28 | 7 | Huarui Lin | ### 二、 Sprint 执行与护航阶段 |
| 29 | 4 | Huarui Lin | *目标：在保持敏捷节奏的同时，确保不偏离企业级架构的护栏。* |
| 30 | 1. **每日站会** |
||
| 31 | * **重点关注“阻塞”**：在EA项目中，开发被卡住往往不是因为代码难写，而是因为环境没就绪、跨域网络不通、或者其他团队的API没发布。首要任务是**立刻去扫除这些外部障碍**。 |
||
| 32 | * **防范架构偏移**：听开发者的描述，判断他们是否在“绕过”架构规范写捷径代码（比如直接写数据库跨库查询，而不是走规定的API网关）。 |
||
| 33 | 2. **架构决策记录（ADR）的动态管理** |
||
| 34 | * 如果在开发中发现了架构设计时未考虑到的问题，与架构师和核心开发，迅速召开“闪电决策会议”，输出轻量级的ADR，并更新到Wiki中，确保全员知悉。 |
||
| 35 | 3. **技术债的动态平衡** |
||
| 36 | 1 | Huarui Lin | * 如果本Sprint为了赶进度积累了技术债，需要在Sprint Backlog中显式地记录下来，并在下个Sprint规划时向PO争取“还债”的容量（通常企业级项目要求预留15%-20%的产能处理技术债）。 |
| 37 | 4 | Huarui Lin | 4. **持续合规与安全检查** |
| 38 | * 提醒团队进行代码静态扫描、依赖库漏洞检查。在 enterprise 级别，安全左移是必须的，不能让安全审查成为Sprint末尾的“惊吓”。 |
||
| 39 | 7 | Huarui Lin | ### 三、 Sprint 评审与交付阶段 |
| 40 | 4 | Huarui Lin | *目标：向双重受众（业务价值 + 技术价值）展示成果，并获取反馈。* |
| 41 | 1. **双轨制Demo演示** |
||
| 42 | * **面向业务**：演示新架构支撑下的业务流程是否跑通。 |
||
| 43 | * **面向架构委员会/技术专家**：展示架构约束是否被满足。比如：API的响应时间是否达到了NFR标准？日志格式是否符合全链路追踪的规范？新旧系统的数据一致性如何？ |
||
| 44 | 1 | Huarui Lin | 2. **架构全景图更新** |
| 45 | 4 | Huarui Lin | * 和架构师一起，在评审会上展示更新后的C4模型或系统架构图，把“已变成现实”的部分用绿色标注，让所有人看到物理进度。 |
| 46 | 3. **发布策略协调** |
||
| 47 | * 企业级发布通常不是简单的点个按钮。需要协调灰度发布策略、数据库变更脚本执行顺序、回滚预案确认，以及与运维团队的变更管理流程对接。 |
||
| 48 | 7 | Huarui Lin | ### 四、 Sprint 回顾与持续改进 |
| 49 | 4 | Huarui Lin | *目标：优化“人、流程、工具”在复杂架构下的协作效率。* |
| 50 | 1. **专项复盘主题** |
||
| 51 | 除了常规的协作问题，需要引导团队针对企业级研发的痛点进行复盘，例如： |
||
| 52 | 1 | Huarui Lin | * “本Sprint我们在等待跨团队联调上浪费了多少时间？如何改进契约测试？” |
| 53 | 4 | Huarui Lin | * “开发环境的配置过于复杂，下次如何优化基础设施即代码的流程？” |
| 54 | 2. **架构护栏的反思** |
||
| 55 | * 问团队：“当前的架构规范是帮我们提高了效率，还是变成了绊脚石？”如果是后者，将反馈带给企业架构团队，推动架构治理流程的敏捷化。 |
||
| 56 | --- |
||
| 57 | 7 | Huarui Lin | ### 💡 敏捷项目经理的“隐藏武器”（贯穿始终） |
| 58 | 4 | Huarui Lin | 1. **架构演进路线图**：确保当前的Sprint没有走偏，每一步都在逼近Target Architecture（目标架构）。 |
| 59 | 2. **风险与决策日志**：企业级项目试错成本极高，必须记录每一个“为什么这么做而不是那么做”的技术决策，避免几个月后换了一批人又重新讨论。 |
||
| 60 | 3. **干系人期望矩阵**：CIO关心战略落地，业务线关心功能，开发关心代码质量，运维关心稳定性。需要在这些诉求发生冲突时（比如业务催进度，架构要重构），作为**调音师**来平衡短期交付与长期架构健康。 |