---
title: "Runbook: Enterprise Feature Development"
type: source
tags: []
date: 2026-05-02
---

## Source File
- [[Agent/agency-agents/strategy/runbooks/scenario-enterprise-feature.md]]

## Summary（用中文描述）
- 核心主题：企业级产品大型功能开发的多 Agent 编排完整手册
- 问题域：合规、安全、质量门控不可妥协，20-30 个 Agent 并行协作，多方利益相关者需对齐
- 方法/机制：NEXUS-Sprint 模式，12 周五阶段流水线（需求架构→基础构建→开发→硬化→发布），每个阶段设置 Quality Gate，Reality Checker 默认返回 NEEDS WORK
- 结论/价值：可复用的企业级功能开发 Agent 编排模板，量化质量指标 + 结构化风险矩阵 + 分层利益相关者沟通节奏

## Key Claims（用中文描述）
- 多 Agent 编排（20-30 个 Agent）可将企业级功能开发在 6-12 周内完成，同时满足合规、安全和质量门控要求
- 利益相关者沟通必须分层分级：执行层每日、产品周报、主管层双周 SCQA 简报（≤500 词）、合规/财务月度报告
- Reality Checker 质量门默认返回 NEEDS WORK（而非默认通过），强制修复循环直至完全合规
- 代码覆盖率 >80%、API P95 响应时间 <200ms、无关键安全漏洞、品牌一致性 ≥95%、10 倍流量压测通过，才能发布

## Key Quotes
> "Reality Checker → Integration testing (default: NEEDS WORK)" — 最终质量门必须主动修复，不接受默认通过
> "Legal Compliance Checker involved from Day 1" — 合规从项目第一天介入，而非事后补查
> "Sprint Prioritizer enforces MoSCoW, Project Shepherd manages changes" — 范围蔓延通过 MoSCoW 优先级强制管控

## Key Concepts
- [[Quality-Gate]]：每个阶段结束的结构化验收点，未通过则进入修复循环
- [[RICE-Scoring]]：Sprint Prioritizer 用于对 Product Backlog 进行评分排序的方法论（Reach/Impact/Confidence/Effort）
- [[MoSCoW]]：需求优先级框架（Must have/Should have/Could have/Won't have），防止范围蔓延
- [[Canary-Deployment]]：灰度发布策略（5%→25%→100%），通过 DevOps Automator 逐步放量降低发布风险
- [[WCAG-2.1-AA]]：Web 内容无障碍指南 2.1 AA 级，是企业级功能发布的强制可访问性要求

## Key Entities
- [[Agents-Orchestrator]]：流水线控制器，管理 Dev↔QA 循环的核心协调 Agent
- [[Project-Shepherd]]：跨职能协调员，负责利益相关者分析和变更管理
- [[Sprint-Prioritizer]]：Product Backlog 管理，使用 RICE 评分和 MoSCoW 防止范围蔓延
- [[Reality-Checker]]：最终质量门，默认返回 NEEDS WORK，强制修复循环
- [[Evidence-Collector]]：视觉 QA，通过截图记录每个任务的质量证据
- [[Experiment-Tracker]]：A/B 测试追踪，为关键功能设置实验对照
- [[Legal-Compliance-Checker]]：合规审查 Agent，从项目第一天介入直至最终审计通过
- [[Performance-Benchmarker]]：性能基准测试，包括 P95 响应时间 <200ms 和 10 倍流量压测
- [[Executive-Summary-Generator]]：执行层简报生成器，使用 SCQA 框架（Situation/Complication/Question/Answer）
- [[DevOps-Automator]]：CI/CD 和灰度发布（Canary Deployment 5%→25%→100%）执行

## Connections
- [[scenario-marketing-campaign]] ← similar_pattern ← 本 Runbook：两者均为多 Agent 协作+NEXUS-Sprint 框架，营销场景侧重内容传播，本 Runbook 侧重企业合规开发
- [[scenario-incident-response]] ← related ← 本 Runbook：应急响应是第 11-12 周 Week 11 "Final Judgment" 的关键前置知识
- [[NEXUS]] ← managed_by ← [[Agents-Orchestrator]]：NEXUS 框架通过 Agents Orchestrator 实现多 Agent 流水线编排
- [[agent-activation-prompts]] ← template_source ← 本 Runbook：本 Runbook 定义的 Agent 角色使用 [[agent-activation-prompts]] 中的标准化模板激活

## Contradictions
- 与 [[scenario-marketing-campaign]] 无冲突：营销场景重内容传播，本 Runbook 重合规开发，方法论互补而非矛盾
- 与 [[scenario-incident-response]] 无冲突：应急响应是发布后事件，本 Runbook 是发布前流程，时序无重叠