Agile BA Practices

敏捷 BA 实践技能

目的

指导 AI 助手在敏捷和混合方法中运用 BA 实践，在轻量级文档与全面分析之间取得平衡。

BA 在敏捷中的角色

传统 BA 与敏捷 BA

方面	传统 BA	敏捷 BA
文档	前期全面编写	适量、及时编写
需求	开发前完整确定	逐步涌现、持续演变
交付物	BRD、FRS、用例	用户故事、验收标准
方法	瀑布式／分阶段	迭代／增量
反馈	项目结束时	持续进行、每个冲刺均有反馈
变更	正式的变更控制	接纳变更

Scrum 中 BA 的角色

冲刺规划：

• 与团队一起澄清用户故事
• 解答需求相关问题
• 协助估算复杂度
• 识别依赖关系

冲刺期间：

• 随时提供澄清
• 验收已完成的故事
• 梳理后续故事
• 编写验收标准

冲刺评审：

• 与 PO 一起演示功能
• 收集利益相关者的反馈
• 记录变更请求

冲刺回顾：

• 反思 BA 流程
• 改进协作

待办事项梳理：

• 细化后续故事
• 添加验收标准
• 拆分大型故事
• 与 PO 一起确定优先级

核心敏捷 BA 工作成果

产品待办事项列表

结构：

Epic > Feature > User Story > Task

示例：

Epic: Customer Self-Service Portal
├── Feature: Account Management
│   ├── User Story: View profile
│   ├── User Story: Update profile
│   └── User Story: Change password
├── Feature: Order History
│   ├── User Story: View orders
│   └── User Story: Track shipments
└── Feature: Support
    ├── User Story: Submit ticket
    └── User Story: View FAQs

用户故事模板

**Title**: [Short, descriptive title]

As a [user role]
I want [goal]
So that [benefit]

**Acceptance Criteria**:
- Given... When... Then...
- Given... When... Then...

**Notes**: [Technical notes, wireframe links]

**Story Points**: [Estimate]

就绪定义（DoR）

满足以下条件时，故事即为就绪：

• 用户故事符合格式（作为……我希望……以便……）
• 验收标准清晰且可测试
• 故事独立于冲刺中的其他故事
• 故事规模足以在一个冲刺内完成
• 已与团队讨论技术方案
• 已识别并解决依赖关系
• 已提供线框图／设计稿（如涉及 UI 工作）

完成定义（DoD）

满足以下条件时，故事即为完成：

• 满足所有验收标准
• 代码已通过同行评审
• 已编写并通过单元测试
• 集成测试已通过
• 没有严重缺陷
• 文档已更新
• 已部署到预发布环境
• PO 已验收

敏捷文档方法

适量文档

在以下情况下编写文档：

• 合规／审计要求
• 多个团队需要理解相关内容
• 业务规则复杂
• 集成规范
• 需要保留知识

以下情况下保持精简：

• 团队规模小且沟通顺畅
• 频繁面对面交流
• 领域简单且易于理解
• 项目周期短

轻量级工作成果

传统方式	敏捷替代方案
100 页 BRD	1 页项目简介 + 待办事项列表
详细的 FRS	用户故事 + 验收标准
用例文档	验收场景
数据字典	故事中的实体定义
测试计划	自动化测试 + DoD

持续更新的文档

• 将文档存储在版本控制中（Git）
• 随需求演变更新文档
• 使用维基（Lark、Notion、Confluence）
• 尽可能实现自动化

待办事项梳理

目的

• 拆分大型故事
• 补充后续故事的细节
• 澄清需求
• 估算故事
• 确定待办事项的优先级

频率

• 每周 1-2 小时
• 提前 1-2 个冲刺
• 保持固定节奏

梳理活动

故事拆分：

• 按工作流步骤拆分
• 按业务规则拆分
• 按数据差异拆分
• 按平台拆分（iOS/Android）
• 按用户角色拆分

估算：

• 计划扑克
• 故事点（斐波那契数列）
• T 恤尺码估算法
• 相对估算

与 PO 一起确定优先级：

• 业务价值
• 降低风险
• 依赖关系
• 技术债务

故事地图

什么是故事地图？

一种沿用户旅程组织用户故事的可视化技术。

结构

Activities (top row)
    ↓
Tasks (second row)
    ↓
Details/Stories (lower rows, by priority)

示例：电子商务故事地图

Browse Products → Add to Cart → Checkout → Order Tracking
     ↓              ↓             ↓            ↓
View catalog     Add item      Shipping      View status
Search products  Update qty    Payment       Track shipment
Filter/sort      Save for later Review order  Get notifications

MVP ─────────────────────────────────────────────────
View catalog     Add item      Shipping      View status
Search           Update qty    Payment

Release 2 ───────────────────────────────────────────
Filter/sort      Save for later Review order Track shipment

混合方法

何时使用混合方法

• 大型企业项目
• 监管要求
• 固定范围合同
• 分布式团队
• 成熟度水平不一

混合方法

瀑布式元素：

• 初始探索／分析阶段
• 用于审批的正式 BRD
• 预先进行架构设计
• 上线规划

敏捷元素：

• 迭代开发
• 用户故事和冲刺
• 持续交付
• 冲刺演示

混合流程示例

Discovery (2-4 weeks): Requirements, BRD, Architecture
    ↓
Sprint 0: Setup, detailed design, initial stories
    ↓
Sprints 1-N: Agile development
    ↓
UAT Sprint: User acceptance testing
    ↓
Go-live: Deployment, hypercare

规模化敏捷（SAFe 基础）

层级

• 组合：战略计划
• 项目群：敏捷发布列车（ART）
• 团队：Scrum 团队

关键角色

• 产品经理（组合）
• 产品负责人（团队）
• 系统架构师
• 发布列车工程师

关键活动

• PI 规划（项目群增量）
• 系统演示
• 检视与调整

敏捷 BA 工具

待办事项管理

• Jira
• Azure DevOps
• Trello
• Lark Base

文档

• Lark Docs
• Notion
• Confluence

协作

• Miro/FigJam（故事地图）
• Figma（线框图）
• Lark Meetings

最佳实践

沟通

✅ 面对面交流优于文档 ✅ 可运行的软件优于详尽的文档 ✅ 通过每日站会保持同步 ✅ 尽早且频繁地演示

需求

✅ 接纳变化 ✅ 按需及时细化 ✅ 协作完善 ✅ 制定可测试的验收标准

文档

✅ 只写必要内容 ✅ 保持内容最新 ✅ 确保易于访问 ✅ 尽可能自动化

协作

✅ 与 PO 密切合作 ✅ 随时为团队提供支持 ✅ 促进协作，而非发号施令 ✅ 学习技术基础知识

常见反模式

❌ 预先进行大量设计：开发前进行过多分析 ❌ 单方面倾倒需求：未经协作编写故事 ❌ BA 缺席：冲刺期间无法提供支持 ❌ 过度设计：事事过度记录 ❌ 否认范围变化：不适应不断变化的需求

参考资料

• 敏捷宣言
• Scrum 指南
• 《用户故事地图》（Jeff Patton）
• SAFe 框架
• BABOK 敏捷扩展