ALM是什么？从需求、开发、测试到发布的全生命周期管理

ALM是Application Lifecycle Management的缩写，中文通常译为应用生命周期管理。它是对软件应用从需求提出、规划设计、开发测试，到部署发布、变更维护乃至最终退役的全过程管理。

结合复杂产品研发场景，可以给ALM一个更具操作性的定义：

ALM是一套围绕软件全生命周期建立流程、数据关系和治理机制的管理方法，目标是让每一项需求都能找到来源、实现过程、测试证据、发布版本和后续变更记录。

因此，ALM并不等于把需求、任务和缺陷集中放进一个系统。它更关注这些研发对象之间是否存在清晰、持续且可以验证的关系，例如：

这项需求来源于哪个客户、业务目标或法规要求；

它被拆解成了哪些系统需求和软件需求；

哪些开发任务、代码分支和提交记录实现了它；

哪些测试用例验证了它；

它被纳入了哪个发布版本；

需求发生变化后，哪些设计、代码和测试需要同步调整。

ONES的ALM方案也将ALM定义为从需求提出开始，到设计、开发、测试、发布、变更和维护的全过程管理，并强调研发数据链路能否完整串联。

ALM一般覆盖哪些生命周期阶段？

ALM没有唯一固定的阶段划分，但从管理对象和研发活动来看，通常覆盖需求、设计、开发、测试、发布以及后续维护六个主要环节。

1. 需求提出与分析

软件生命周期通常从业务目标、客户反馈、市场机会、法规要求或产品规划开始。这一阶段需要记录需求来源、业务价值、优先级、适用版本、负责人和验收标准，并将高层业务需求逐步拆解为系统需求、软件需求和可执行工作。

ALM在需求阶段关注的不只是“需求有没有记录”，而是需求能否被评审、拆解、分配、变更和追踪。

2. 设计与任务规划

需求确认后，团队需要形成架构设计、接口设计、详细方案和实施计划。这一阶段应当建立需求与设计对象、研发任务之间的关系，使团队能够明确：

哪项设计用于满足哪项需求；

哪些任务负责实现对应设计；

每项工作由谁负责；

前后置依赖和交付物是什么。

如果设计和需求之间没有关联，后续即使设计发生变化，团队也很难判断哪些需求和测试需要重新确认。

3. 开发与代码实现

在开发阶段，ALM应将研发任务与代码分支、提交记录和合并请求关联，使任务状态能够反映真实的工程进展。通过这种关联，团队不仅能够看到任务是否被标记为完成，还可以继续确认：

是否已经创建对应代码分支；

哪些提交用于实现该任务；

代码由谁提交；

是否完成代码评审和合并；

实现结果是否进入目标版本。

这一步连接了项目管理活动和实际工程活动，也是ALM区别于普通任务管理的重要方面。

4. 测试与质量验证

测试阶段需要建立需求、测试用例、测试任务、执行结果和缺陷之间的关系。对于任意一项需求，团队都应能够回答两个基本问题：

哪些测试用例验证了这项需求？

测试发现的缺陷能否回溯到对应需求和实现任务？

这种关联不仅用于统计测试进度，还能用于检查需求覆盖是否完整、缺陷是否完成验证，以及版本是否具备交付条件。

5. 发布与部署

ALM并不在开发任务完成时结束，还需要继续管理版本范围、发布审批、构建部署和最终交付结果。

发布前，团队应当明确本次版本包含哪些需求、缺陷修复和代码变更，关键测试是否通过，是否仍存在未处理风险。发布后，还要保留版本与需求、代码和测试结果之间的关系，使团队能够在后续出现问题时快速定位对应的交付内容。

6. 变更、维护与持续演进

软件发布后仍会不断发生需求调整、缺陷修复、性能优化和版本升级。IBM对ALM的定义也明确覆盖应用部署后的修订、维护和最终退役。

当需求或设计发生变化时，团队需要识别“变了什么”“影响了谁”以及“谁需要响应”，并推动相关开发、测试和交付人员逐项确认。只有当变更在上下游链路中得到落实，软件生命周期才真正形成闭环。

ALM与项目管理、SDLC有什么区别？

ALM、项目管理和SDLC经常同时出现在研发管理中，但三者所解决的问题并不相同。

ALM与项目管理的区别

PMI将项目定义为为创造独特产品、服务或成果而开展的临时性工作，项目通常通过一系列结构化任务、活动和交付物实现预期结果。因此，项目管理主要关注项目是否能够在既定范围、时间、成本和资源条件下完成目标。

ALM关注的对象则是软件应用及其持续演进过程。一个项目可以在版本上线后结束，但软件仍然需要继续维护、修复和迭代，需求与代码、测试和版本之间的关系也不能随着项目结束而消失。

ALM与SDLC的区别

SDLC是Software Development Life Cycle的缩写，中文通常译为软件开发生命周期。Atlassian将SDLC概括为用于规划、构建、测试和维护软件的结构化流程，常见阶段包括规划、可行性分析、设计、实施、测试、部署和维护。

SDLC主要回答的是“软件按照哪些阶段和方法进行开发”。ALM的范围更广，它还需要管理每个阶段产生的数据、责任、版本、审批和关联关系。三者可以概括为：

项目管理解决项目如何在约束条件下完成；

SDLC解决软件按照什么过程进行开发；

ALM解决软件全生命周期中的流程、数据和责任如何持续连接。

它们不是相互替代的关系，而是从不同角度共同支撑研发管理。

ALM体系应具备哪些核心能力？

ALM的价值不在于增加更多流程和字段，而在于让关键研发对象形成连续、可信且可以验证的关系。一套较完整的ALM体系，通常需要具备以下五类能力。

1. 需求结构化管理能力

需求不能长期停留在Word、Excel和会议纪要中。团队需要将需求转化为有编号、有状态、有负责人、有版本记录的管理对象。结构化管理还应支持需求分层、需求评审、优先级管理和变更记录，使高层业务目标能够逐步传递到可以开发和验证的工作内容。

2. 端到端追溯能力

ALM应建立需求与设计、任务、代码、测试、缺陷和版本之间的关联。端到端追溯的判断标准不是系统中“能够创建关联”，而是团队能否从任意对象向上查找来源、向下查看实现和验证结果。

例如，从一项系统需求出发，应能继续查看对应的软件需求、开发任务、代码记录、测试用例和发布版本；从一个线上缺陷出发，也应能够回溯到相关测试、实现任务和原始需求。

3. 变更影响分析能力

研发管理不能只记录“需求发生过变化”，还要识别变化内容和影响范围。有效的变更影响分析应能够比较不同版本之间的差异，沿上下游关系定位潜在受影响对象，并让相关负责人确认自己的设计、代码、测试或文档是否需要同步调整。

4. 过程与权限治理能力

不同项目可能采用敏捷、瀑布、V模型、IPD或混合研发模式。ALM需要允许企业根据项目类型配置相应的工作对象、字段、流程、角色和权限。对于需求确认、需求变更、测试完成和版本发布等关键活动，系统还应保留评审意见、审批记录、操作历史和责任信息，为质量检查和过程审计提供依据。

5. 工程工具集成能力

ALM不一定要替换代码仓、持续集成和部署工具，但需要与这些工具建立连接。如果研发任务与代码分支、提交记录、合并请求和流水线状态长期分离，管理平台中的进度就无法准确反映真实工程活动。因此，工程集成能力是连接管理实践与研发实践的重要基础。

企业如何逐步落地ALM？

ALM建设不宜从一次性替换所有工具开始，更合理的方式是先识别最关键的链路断点，再逐步扩展管理范围。

第一步：梳理核心研发对象

企业首先要明确在当前研发过程中需要管理哪些对象。常见对象包括：

业务需求和客户需求；

系统需求与软件需求；

架构设计和详细设计；

开发任务；

代码分支、提交和合并请求；

测试用例、测试任务和执行结果；

缺陷；

发布版本。

对象并非越多越好。定义过少，无法构成完整链路；定义过细，则会增加研发人员的维护负担。判断是否需要独立管理某个对象，可以看它是否具有独立负责人、状态、版本或审计要求。

第二步：建立最小追溯闭环

完成对象梳理后，不应马上建立复杂的全景模型，而应先选择一条最重要的交付链路。多数企业可以从以下最小闭环开始：

业务需求—研发需求—开发任务—代码记录—测试用例—发布版本。

这条链路建立后，团队应能够判断需求是否完成开发、是否经过测试、最终进入了哪个版本。等最小闭环稳定运行后，再逐步扩展到设计、缺陷、风险和外部供应商等对象。

第三步：规范关键状态和责任

团队需要明确每类对象从创建到完成要经过哪些状态，每个状态由谁负责，以及进入下一阶段必须满足什么条件。

例如，一项需求从“草稿”进入“已确认”前，是否必须完成产品、研发和测试评审；一个缺陷关闭前，是否必须完成修复验证；一个版本发布前，是否必须完成关键需求覆盖检查。

流程设计应围绕关键风险展开，而不是把所有活动都变成审批。

第四步：建立需求变更响应机制

记录需求修改历史只能说明“需求变了”，并不能保证下游团队完成响应。变更发生后，还需要完成三个动作：

比较新旧版本，确认具体变化；

沿关联关系识别受影响的设计、任务和测试；

由相关负责人确认是否需要修改，并保留处理结果。

通过这种机制，变更才不会停留在需求负责人或项目经理手中，而是能够沿研发链路逐层落实。

第五步：连接代码、测试和发布活动

当需求、任务和流程稳定后，企业应逐步接入代码仓、持续集成、测试和发布工具。连接工程工具后，项目状态可以更多地由真实研发活动驱动，例如：

创建代码分支后自动关联任务；

提交代码时带入需求或任务编号；

合并请求状态同步到研发工作项；

测试结果关联需求和版本；

构建、部署结果回传发布记录。

这可以减少人工更新状态的工作，也能提高项目数据的可信度。

第六步：用交付问题检验ALM效果

判断ALM是否落地，不应只看创建了多少流程、字段和报表，而要看团队能否快速回答真实的交付问题：

本次版本计划交付哪些需求；

每项需求是否完成开发和测试；

哪些需求还没有测试覆盖；

某项需求变更会影响哪些对象；

某个缺陷对应哪项需求和代码修改；

发布版本是否存在断链或未关闭风险。

如果这些问题仍需要临时开会、查表和人工拼接，说明研发链路尚未真正建立。

以ONES为例：如何连接管理实践与工程实践？

在管理侧，ONES ALM方案将相关能力分为过程合规、需求追溯和变更影响分析三个方向。

团队可以通过项目模板沉淀工作项类型、字段、流程和角色权限，通过项目目录组织不同阶段需要交付的文档与工作项，从而降低不同项目重复配置和执行口径不一致的问题。

在需求管理方面，ONES支持将Word需求文档按标题结构导入为需求工作项，并保留段落、图片和表格内容。导入后的需求可以配置负责人、状态和层级关系，从静态文档转化为可评审、可拆解、可追踪的研发对象。

在需求变更场景中，需求基线用于比较不同阶段的需求版本，回答“变了什么”；关系追溯图用于展示需求与下游任务、测试和文档的关联，回答“影响了谁”；可疑分析则用于提醒受影响对象的负责人查看变化并确认处理结果。

在工程侧，ONES V7企业版支持与GitLab、GitHub、Bitbucket和SVN等代码仓对接。团队可以从需求或工作项创建代码分支、关联合并请求，也可以通过提交信息中的需求编号建立代码记录与研发任务的关系。

这类研发平台的价值，不是简单增加一套项目管理工具，而是把管理对象和工程活动连接起来：从需求查看任务、代码和测试，从代码返回业务背景，从测试结果判断需求是否真正完成。

结语

ALM不是单纯的软件工具，也不只是研发流程的另一种名称。它真正解决的是一个贯穿软件研发全过程的问题：

从需求提出到产品发布，再到后续变更和维护，企业能否始终知道每项工作为什么做、由谁完成、如何验证，以及变化会影响什么。

项目管理帮助团队在约束条件下完成目标，SDLC规范软件按照什么过程开发，而ALM进一步将需求、设计、任务、代码、测试、缺陷和版本连接成连续的数据链路。

当团队能够从一项需求追踪到实现、测试和发布，也能在需求变化时快速找到受影响对象并推动责任人响应，软件研发才真正从分阶段管理走向全生命周