ALM 与 Scrum：面向 .NET 团队的实用指南

ALM 不只是工具，更是一种纪律

应用程序生命周期管理（ALM）是对软件从构思到退役进行端到端管理的一门纪律。对于 .NET 团队而言，ALM 贯穿需求收集、架构设计、开发、测试、部署、维护和治理——所有环节都通过一套既定流程协调进行。

Scrum 提供迭代框架，ALM 提供纪律。二者结合，为 .NET 团队提供了一条从创意到生产、可复用的路径，并在每个环节都具备可见性。

本指南基于 15 年以上使用 Scrum 交付 .NET 项目的经验，涵盖完整的生命周期、工具选型（Azure DevOps、GitHub、Visual Studio），以及真正能够预测交付成功的度量指标——而非虚荣指标。

ALM 框架：五个阶段，一种节奏

ALM 将软件交付拆分为五个相互关联的阶段，它们与 Scrum 的节奏直接对应：

关键洞见是：ALM 的各个阶段并非顺序执行的瀑布，而是在每个冲刺内并发进行。到冲刺结束时，你得到的是可运行、已测试、具备潜在可交付能力的软件——而不仅仅是“代码写完了”。

阶段 1：真正行之有效的需求与规划

产品待办列表：不只是一份清单

一个健康的产品待办列表是高效 ALM 的基础。对于 .NET 团队，每个待办项都应包含：

• 用户故事：“作为[角色]，我希望[功能]，以便[结果]。”
• 验收标准：定义“完成”的具体、可测试的条件。为清晰起见，使用 Given/When/Then 格式。
• 技术说明：架构决策、数据库架构变更、API 契约、NuGet 包影响。
• 估算：故事点或理想工时。我们建议根据复杂度、工作量和不确定性来使用故事点——而非时间。
• 依赖项：此待办项所依赖的其他待办项、外部服务、第三方 API 或基础设施变更。

冲刺规划：承诺会议

冲刺规划分为两部分：

第一部分——做什么：产品负责人展示优先级最高的待办项。团队提出澄清性问题并协商范围。产出：冲刺目标——用一句话概括本次冲刺交付的内容。

第二部分——怎么做：团队将每个待办项拆分为任务（通常每个 2-8 小时）。对于 .NET 项目，任务通常包括：数据库迁移、API 端点实现、服务层、单元测试、集成测试、前端组件、代码评审和文档更新。

需要避免的规划反模式：

• 诸如“为功能 X 编写代码”这类任务——过于含糊。将其拆分为具体的交付物。
• 100% 满负荷规划——为计划外工作、缺陷和协作留出 20-30% 的缓冲。
• 忽视技术债——每个冲刺至少分配一个待办项用于重构或债务削减。

阶段 2：开发——代码与流程交汇之处

面向 .NET 团队的分支策略

我们建议采用基于主干的开发模式，配合短生命周期的特性分支：

master (always deployable)
  └── feature/dotnet9-migration (1-3 days)
  └── feature/payment-plugin-pix (1-3 days)
  └── fix/checkout-null-reference (hours)

规则：

• 从最新的 master 分支切出，最多在 3 天内合并回去。
• 每个特性或缺陷对应一个 PR。小型 PR 能更快得到评审、更早合并。
• 每个 PR 在评审前必须通过 CI（构建 + 测试）。
• 要求至少一位审批人。所有评审意见都必须在合并前得到处理。
• 使用 squash-merge 以保持 master 历史整洁。

面向 .NET 的代码评审标准

代码评审应检查以下方面：

• 正确性：代码是否实现了验收标准？边界情况是否得到处理？
• 安全性：没有硬编码的密钥。输入验证。防止 SQL 注入。端点上有恰当的鉴权检查。
• 性能：没有 N+1 查询。全程异步。恰当的缓存。连接池。
• 可测试性：逻辑位于可注入的服务中，而非静态方法或控制器中。依赖被抽象到接口之后。
• 约定：遵循项目命名约定、文件夹结构和编码规范。

每日站会：不是状态汇报

每日站会是一场协调会议，而非微观管理工具。每位团队成员回答：昨天我完成了什么，今天我将完成什么，以及有什么在阻碍我？如果出现阻碍，Scrum Master 会在每日站会之外予以解决。会议应控制在 15 分钟，而不是 45 分钟。

阶段 3：持续集成——一切自动化

面向 .NET 项目的 CI 流水线

对特性分支的每次提交都应触发：

1. 还原：dotnet restore——解析 NuGet 依赖。缓存包以提升速度。
2. 构建：dotnet build --configuration Release --no-restore——以优化方式编译。将警告视为错误。
3. 测试：dotnet test --no-build --configuration Release——运行所有单元测试和集成测试。测试失败则构建失败。
4. 分析：运行 StyleCop、SonarQube 或 .NET 分析器。如果引入了新的警告，则阻止合并。
5. 打包：对于库：dotnet pack。对于应用程序：dotnet publish。对于 Docker：docker build。

示例：Azure DevOps YAML 流水线

trigger:
  branches:
    include:
      - master
      - feature/*
      - fix/*

pool:
  vmImage: 'ubuntu-latest'

variables:
  buildConfiguration: 'Release'

steps:
- task: UseDotNet@2
  inputs:
    version: '9.x'

- script: dotnet restore
  displayName: 'Restore packages'

- script: dotnet build --configuration $(buildConfiguration) --no-restore
  displayName: 'Build solution'

- script: dotnet test --no-build --configuration $(buildConfiguration) --collect:"XPlat Code Coverage"
  displayName: 'Run tests'

- task: PublishCodeCoverageResults@1
  inputs:
    codeCoverageTool: 'Cobertura'
    summaryFileLocation: '$(Agent.TempDirectory)/**/coverage.cobertura.xml'

构建验证测试（BVT）

除了单元测试之外，还应包含一小组作为 CI 一部分运行的冒烟测试——验证应用程序能否启动、数据库能否连接、主要 API 端点是否返回 200，以及关键用户流程是否正常。这些测试能够捕获单元测试无法发现的环境和配置问题。

阶段 4：测试与质量——超越“在我机器上能跑”

.NET 测试金字塔

测试原则：在能让你有信心的最低层级编写测试。并非每个功能都需要端到端测试——一个测试充分的服务层，配合针对数据库层的集成测试，比浏览器自动化更快、更可靠地捕获大多数缺陷。

冲刺评审：演示可运行的软件

冲刺评审是对可运行、已测试软件的演示——而不是一套幻灯片。以功能呈现给用户的实际方式来展示它们。直接收集反馈。根据所学更新待办列表。如果一个功能无法演示，那它就没有完成。

阶段 5：发布与运维——从完成到部署

面向 .NET 的发布管理

发布应当平淡无奇——自动化、可预测、可回滚。以下是我们在 SplatDev 使用的流程：

1. 版本递增：语义化版本控制（MAJOR.MINOR.PATCH）。在冲刺过程中随着功能落地即时递增，而不是在发布时才递增。
2. 发布分支：从 master 切出并打上版本标签。只有热修复才合并到发布分支。
3. 预发布部署：自动部署到镜像生产环境的预发布环境。运行回归测试套件。
4. 冒烟测试：在预发布环境中手动验证关键路径。留存截图证据。
5. 生产部署：蓝绿部署或金丝雀部署。部署后监控错误率、响应时间和业务指标 30 分钟。
6. 部署后验证：对照发布清单确认部署。更新发布说明。

监控：在用户告诉你之前就知道

生产监控是 ALM 的一部分——部署完并不算完成，只有确认系统健康才算完成。.NET 应用程序的关键指标：

• 应用程序错误：未处理的异常、500 响应。立即告警。
• 响应时间：每个端点的 P50、P95、P99 延迟。在出现劣化时告警。
• 吞吐量：每秒请求数。在出现异常时告警。
• 资源使用：CPU、内存、GC 暂停、线程池耗尽。警惕内存泄漏。
• 业务指标：下单量、已处理付款、完成注册数。这些才是你真正的健康指标。

使用 Application Insights（Azure）、Datadog 或 Prometheus + Grafana 进行 .NET 监控。将日志记录到结构化日志系统（Serilog + Seq/Elasticsearch）——切勿从生产环境的控制台输出中调试问题。

真正能预测成功的 Scrum 度量指标

大多数 Scrum 度量指标都是虚荣指标。以下是真正与交付结果相关的指标：

前置时间与周期时间

前置时间（Lead time）：从待办项创建到部署所用的时间。周期时间（Cycle time）：从开始工作到部署所用的时间。越短越好——它意味着更小的批次、更快的反馈和更少的在制品。目标：大多数事项的周期时间控制在 5 天以内。

冲刺燃尽图（谨慎使用）

燃尽图展示剩余工作量与时间的关系。如果冲刺前半段燃尽图平坦、到结尾才骤降，说明你的团队在临近结束时才完成工作，而没有增量式交付。理想的燃尽图是平稳的——工作在整个冲刺期间持续完成，而不仅仅是在结尾。

逃逸缺陷

本应更早被发现、却在生产环境中出现的缺陷。这是最重要的单一质量指标。如果你的逃逸缺陷数量没有向零趋近，那么你的完成的定义或测试策略就是不充分的。

部署频率

你向生产环境部署的频率。精英团队每天部署多次。对于大多数 .NET 团队来说，每个冲刺至少部署一次是一个不错的目标。如果部署得更少，你就是在累积过多的风险。

冲刺回顾：真正带来改变的反馈循环

回顾会是最重要的 Scrum 仪式——也是最常被跳过的。每个冲刺都要开。问三个问题：哪些做得好，哪些做得差，下个冲刺我们要改变什么？然后——至关重要地——挑选一个行动项并去落实它。没有什么比一个冲刺又一个冲刺地讨论同样的问题却毫无改变更能扼杀回顾会的价值了。

工具：.NET 的 ALM 技术栈

Azure DevOps（推荐用于企业级 .NET 团队）

Azure DevOps 提供一套集成的 ALM 套件：Azure Boards（待办列表管理、冲刺规划、看板）、Azure Repos（带分支策略的 Git 托管）、Azure Pipelines（对 .NET 一流支持的 CI/CD）、Azure Test Plans（手动测试和探索性测试）以及 Azure Artifacts（NuGet 包托管）。对于已经在使用 Azure 的团队，这种集成是无缝的。

GitHub + GitHub Actions（推荐用于开源和现代团队）

GitHub 提供用于待办列表管理的 Projects、用于工作跟踪的 Issues、用于 CI/CD 的 Actions，以及用于 NuGet 托管的 Packages。GitHub Advanced Security 增加了代码扫描、密钥扫描和依赖项审查。对于不需要 Azure Boards 那种深度的团队，GitHub 提供了一种更简单、更以开发者为中心的体验。

Visual Studio + VS Code

Visual Studio Enterprise 包含多项 ALM 功能：架构图、IntelliTest（自动化测试生成）、实时依赖验证和代码克隆检测。对于重视这些工具的团队来说，Enterprise 许可证凭借减少的调试时间就能物有所值。

起步：30 天 ALM 实施计划

1. 第 1 周：搭建你的工具链——Azure DevOps 或 GitHub、CI 流水线、测试框架。定义你的完成的定义。
2. 第 2 周：填充产品待办列表。开展第一次冲刺规划。建立每日站会的节奏。
3. 第 3 周：完成第一个冲刺。演示可运行的软件。开回顾会。测量你的周期时间和逃逸缺陷基线。
4. 第 4 周：部署到生产环境（如果政策要求，则部署到预发布环境）。回顾各项指标。根据回顾会调整流程。周而复始。

目标不是完美的 Scrum——而是一套能够可预测、可见地产出可运行软件的流程。从简单开始，度量一切，并循序渐进地改进。

SplatDev 如何借助 ALM + Scrum 交付

自 2009 年以来我们一直在交付 .NET 项目——那时 Scrum 尚未成为主流，Azure DevOps 也还不存在。我们的 ALM 咨询业务帮助团队采纳本指南所述的实践：待办列表管理、冲刺纪律、CI/CD 流水线搭建、测试自动化和发布管理。

我们为任何规模的 .NET 团队提供 ALM 咨询——从 3 人的初创团队到 50 人的企业团队。我们的服务通常包括：流程评估、工具搭建、冲刺辅导（我们会与你的团队并肩运行 2-3 个冲刺），以及向自给自足的过渡。

想要更快地交付 .NET 软件，同时减少缺陷、降低压力吗？让我们聊聊你当前的流程，以及 ALM + Scrum 能在哪里带来最大的影响。

获取 ALM 咨询

或联系我们：[email protected]