ISO/IEC TR 29110-5-6-2：非常小实体软件工程部署包

ISO/IEC TR 29110-5-6-2 为 VSE 框架内的软件工程提供了部署包。它在入门配置文件（5-1-4）的基础上增加了针对软件特定技术实践的更深入指导，同时保持了使 29110 对小团队友好的轻量级、面向结果的方法。

可以将 5-6-2 视为”如何做”，是对入门配置文件”做什么”的补充。5-1-4 定义需要创建哪些工作产品，而 5-6-2 则提供了创建这些工作产品的具体技术——从用例建模到测试驱动开发。

部署包中的软件工程实践

部署包将软件工程实践组织为三类：需求工程、设计与构建以及验证与确认。每类都包括推荐技术、预期工作产品以及针对不同项目类型的裁剪指南。

实践类别	推荐技术	工作产品	何时裁剪
需求工程	用户故事、用例、验收标准（Gherkin）、需求优先级排序（MoSCoW）	产品待办列表、软件需求规格说明、用例图	内部工具→仅用户故事；安全关键→完整SRS加可追溯性
设计与构建	模块化设计、API优先、编码规范、持续集成、重构	软件架构文档、源代码、编码规范文档	原型→最小化设计文档；长期产品→架构决策记录
验证与确认	单元测试、集成测试、系统测试、验收测试、静态分析、同行评审	测试计划、测试用例、测试报告、代码评审检查表	低风险→自动化单元测试+手动验收；高风险→完整测试矩阵+独立评审

VSE 的一个常见陷阱是将测试视为一个阶段而非一项活动。当测试被安排在开发结束时作为一个阶段进行时，团队往往会因为时间不够而交付未经充分测试的软件。部署包强调测试活动必须与构建活动并行进行。

VSE 在持续的资源压力下运作，经常为了赶工期而承担技术债务。部署包不是通过禁止技术债务来应对这一现实——那将是不切实际的——而是提供了技术债务登记册模板。每项债务都记录其估计修复工作量和业务影响。项目经理在每个规划周期审查登记册，并将固定比例（通常为15-20%）的能力分配给债务消減。

第二个关键洞见是完成的定义模式。部署包提供了一个示例 DoD 检查表：代码已评审、单元测试通过（80%+覆盖率）、集成测试通过、静态分析无问题、文档已更新、验收标准已满足。每个 VSE 根据自身情况调整 DoD，并在每次迭代开始时进行审查。

部署包不规定特定的生命周期模型。相反，它提供了决策标准：对于需求明确且技术稳定的项目，可以采用顺序方法；对于不确定性高的探索性项目，推荐迭代/增量或敏捷方法。关键在于，无论选择何种模型，5-6-2 中定义的工作产品都必须适配该模型。

一个开发 SaaS 分析平台的4人团队采用了部署包的测试优先方法。通过在实现之前编写验收测试，他们将错误修复周期从平均3天（在手动QA期间发现错误）减少到4小时（在自动测试执行期间发现错误）。测试自动化的前期投资在前两个冲刺内即收回成本。

问：5-1-4（入门级）和 5-6-2（软件工程）有什么区别？
答：5-1-4 定义了 VSE 运行所需的最少流程和工作产品集。5-6-2 则提供了更丰富的、针对软件的指导，说明如何有效执行这些流程。可以将 5-1-4 视为基准线，5-6-2 是增强版。

问：5-6-2 支持敏捷开发吗？
答：是的，强烈支持。部署包包含其流程与 Scrum、看板和 XP 实践之间的具体映射。工作产品自然地映射到敏捷工件：产品待办列表、冲刺待办列表、完成的定义和燃尽图。

问：部署包强制要求代码评审吗？
答：验证与确认类别中强制要求同行评审，但形式灵活。可以是结对编程（实时评审）、拉取请求评审（异步）或正式审查。最低要求是每次代码变更至少由作者以外的一人评审。

问：如何证明符合 5-6-2 的要求？
答：合规性通过执行所定义实践的证据来证明。关键证据包括：维护中的产品待办列表或 SRS、测试结果（自动化或手动）、代码评审记录和迭代评审会议纪要。部署包包含用于自我评估的合规性检查表。