2026.5.22
【应急演练子系统】团队SCRUM会议记录：敏捷开发实践全记录
一、敏捷开发方法论
1.1 为什么选择Scrum
应急演练子系统的特点是：
- 需求明确但细节可能变化 - 客户需求相对清晰，但实施过程中可能有调整
- 跨职能团队协作 - 需要后端、前端、AI工程师紧密配合
- 交付周期短 - 计划2-3周完成，需要快速迭代
- 质量要求高 - 作为生产系统，需要稳定可靠
因此我们选择Scrum作为开发框架，通过短周期的Sprint实现快速交付和持续改进。
1.2 团队组成
| 角色 | 姓名 | 职责 |
|---|---|---|
| 产品负责人 (PO) | 客户代表 | 定义需求优先级、验收 |
| Scrum Master | 小李 | 协调会议、移除障碍 |
| 开发团队 | 小王 | 后端开发 |
| 开发团队 | 小张 | 前端开发 |
| 开发团队 | AI工程师小陈 | AI模块开发 |
二、Sprint规划会议
2.1 Sprint 0 规划
会议时间: 2026-06-01 09:00-12:00
参与人员: 全团队
会议目标: 确定Sprint 1-3的总体计划
议题1: 产品待办列表梳理
- 演示系统需求
- 用户故事排序
- 确定Sprint 1-3的目标
议题2: Sprint 1规划
- 选择Sprint 1的Story
- 估算故事点
- 任务分解
产出: Sprint Backlog
2.2 产品待办列表 (Product Backlog)
| ID | 用户故事 | 故事点 | 优先级 | Sprint |
|---|---|---|---|---|
| US-001 | 作为安全主管，我可以通过AI生成演练计划 | 5 | P0 | Sprint 1 |
| US-002 | 作为安全主管，我可以管理演练计划 | 3 | P0 | Sprint 1 |
| US-003 | 作为安全主管，我可以派发演练任务 | 3 | P0 | Sprint 1 |
| US-004 | 作为执行人，我可以开始/结束演练执行 | 5 | P0 | Sprint 1 |
| US-005 | 作为评估人员，我可以填写评估反馈 | 3 | P1 | Sprint 1 |
| US-006 | 员工可以通过AI问答查询应急知识 | 8 | P0 | Sprint 2 |
| US-007 | 管理员可以上传应急预案文档 | 5 | P0 | Sprint 2 |
| US-008 | 用户可以通过微信/QQ登录 | 5 | P1 | Sprint 3 |
| US-009 | 系统可以推送飞书通知 | 5 | P2 | Sprint 3 |
| US-010 | 系统可以Docker一键部署 | 3 | P1 | Sprint 3 |
三、每日站会 (Daily Standup)
3.1 第一天站会
时间: 2026-06-02 09:00
地点: 团队会议室
时长: 15分钟
【小王 - 后端开发】
├── 昨日完成
│ ├── 完成数据库模型定义
│ ├── 完成用户认证模块
│ └── 完成演练计划CRUD基础框架
├── 今日计划
│ ├── 完成演练任务API开发
│ └── 完成演练执行API开发
└── 阻塞问题
└── 无
【小张 - 前端开发】
├── 昨日完成
│ ├── 完成项目框架搭建
│ └── 完成登录页面UI
├── 今日计划
│ ├── 完成演练计划列表页
│ └── 对接演练计划API
└── 阻塞问题
└── 等待API文档
【小陈 - AI工程师】
├── 昨日完成
│ ├── 完成RAG架构设计
│ └── 完成向量数据库选型
├── 今日计划
│ ├── 实现文档解析模块
│ └── 测试ChromaDB集成
└── 阻塞问题
└── 无
3.2 第二天站会
时间: 2026-06-03 09:00
地点: 团队会议室
时长: 15分钟
【小王 - 后端开发】
├── 昨日完成
│ ├── 完成演练任务API
│ ├── 完成演练执行API
│ └── 修复了任务状态流转Bug
├── 今日计划
│ ├── 完成演练反馈API
│ └── 后端整体联调测试
└── 阻塞问题
└── 需要前端确认字段命名
【小张 - 前端开发】
├── 昨日完成
│ ├── 完成演练计划列表页
│ ├── 完成演练计划表单页
│ └── 开始任务管理页面
├── 今日计划
│ ├── 完成任务管理页面
│ └── 开始执行跟踪页面
└── 阻塞问题
└── API响应格式确认
【小陈 - AI工程师】
├── 昨日完成
│ ├── 完成PDF文档解析
│ ├── 完成ChromaDB集成
│ └── 测试Embedding API
├── 今日计划
│ ├── 完成RAG检索核心逻辑
│ └── 对接LLM服务
└── 阻塞问题
└── 等待LLM API Key配置
【Scrum Master - 小李】
├── 议题
│ ├── 确认Sprint 1是否需要缩减范围
│ └── 协调AI模块与业务模块的对接
└── 决策
└── Sprint 1范围不变，按期交付
3.3 第三天站会
时间: 2026-06-04 09:00
地点: 团队会议室
时长: 15分钟
【小王 - 后端开发】
├── 昨日完成
│ ├── 完成演练反馈API
│ ├── 修复了分页Bug
│ └── 开始联调测试
├── 今日计划
│ ├── 完成前后端联调
│ └── 完善API文档
└── 阻塞问题
└── 无
【小张 - 前端开发】
├── 昨日完成
│ ├── 完成任务管理页面
│ ├── 完成执行跟踪页面
│ └── 开始反馈评估页面
├── 今日计划
│ ├── 完成反馈评估页面
│ └── 完成整体UI优化
└── 阻塞问题
└── 无
【小陈 - AI工程师】
├── 昨日完成
│ ├── 完成RAG检索核心逻辑
│ ├── 完成LLM服务对接
│ └── 初步测试通过
├── 今日计划
│ ├── 完成企业级问答实现
│ └── 测试多轮对话
└── 阻塞问题
└── 无
四、Sprint评审 (Sprint Review)
4.1 Sprint 1 评审
会议时间: 2026-06-05 14:00-16:00
参与人员: 团队 + 客户代表
【演示内容】
1. 演练计划管理 - CRUD完整演示
2. 演练任务管理 - 状态流转演示
3. 演练执行跟踪 - 开始/结束流程
4. 演练反馈评估 - 评分功能
【客户反馈】
+ 计划列表的分页体验很好
+ 任务状态用颜色区分很直观
+ 执行记录的时间自动填充很贴心
- 希望增加计划搜索功能
- 希望支持批量导入演练任务
- 评估表单希望增加附件上传
【评审结论】
Sprint 1交付物通过验收
新增用户故事移入Sprint 2
4.2 Sprint 2 评审
会议时间: 2026-06-07 14:00-16:00
【演示内容】
1. RAG知识库 - 文档上传和解析
2. AI智能问答 - 知识库检索问答
3. 演练方案生成 - AI自动生成方案
4. 对话式计划创建 - 多轮对话引导
【客户反馈】
+ AI问答响应速度快，体验好
+ 区分知识库问答和模型问答的设计很专业
+ 方案生成的内容很完整
- 希望增加"追问"功能
- 希望支持导出为Word文档
【评审结论】
Sprint 2交付物通过验收
新需求记录到产品待办列表
五、Sprint回顾 (Sprint Retrospective)
5.1 Sprint 1回顾
会议时间: 2026-06-05 16:30-17:30
【做得好的】
+ 每日站会准时召开，问题及时暴露
+ CRUD基础类封装减少了重复代码
+ 前端和后端并行开发，效率高
+ 代码评审发现了一些潜在问题
【需要改进的】
- 前端页面和API联调时间超出预期
- 缺少自动化测试
- 部分代码注释不够清晰
【改进措施】
1. 后续Sprint中，前端先mock API进行开发
2. 增加单元测试覆盖率目标
3. 统一代码注释规范
【行动计划】
| 行动项 | 负责人 | 完成时间 |
|--------|--------|---------|
| 编写API Mock接口 | 小张 | 06-06 |
| 增加pytest测试 | 小王 | 06-07 |
| 更新代码注释规范 | 小李 | 06-06 |
5.2 Sprint 2回顾
会议时间: 2026-06-07 16:30-17:30
【做得好的】
+ AI模块与业务模块解耦良好
+ 向量数据库选型正确，性能满足要求
+ 知识库问答的防幻觉设计得到客户认可
【需要改进的】
- LLM API调用没有做异常降级处理
- 文档上传没有做进度提示
- 对话生成的状态管理可以优化
【改进措施】
1. 完善LLM调用异常处理和降级逻辑
2. 增加文件上传进度条
3. 使用Redis存储对话状态
【行动计划】
| 行动项 | 负责人 | 完成时间 |
|--------|--------|---------|
| 完善LLM异常处理 | 小陈 | 06-08 |
| 增加上传进度条 | 小张 | 06-08 |
| Redis存储对话 | 小陈 | 06-08 |
六、燃尽图记录
6.1 Sprint 1燃尽图
故事点
↑
25│ ●
│ ╱ ╲
20│ ╱ ╲ ●
│ ╱ ╲╱ ╲
15│╱ ●
│ ╲
10│ ╲
│ ●
5│ ╲
│ ●
0└─────────────────────────────►
1 2 3 4 5 6 7 (天)
● 剩余故事点
━ 理想进度
6.2 Sprint完成情况
| Sprint | 计划故事点 | 完成故事点 | 完成率 | 偏差 |
|---|---|---|---|---|
| Sprint 0 | 8 | 8 | 100% | 0 |
| Sprint 1 | 19 | 18 | 95% | -1 |
| Sprint 2 | 18 | 20 | 111% | +2 |
| Sprint 3 | 15 | 15 | 100% | 0 |
| 总计 | 60 | 61 | 101.7% | +1 |
七、敏捷实践总结
7.1 关键实践
| 实践 | 应用效果 |
|---|---|
| Sprint规划 | 明确目标，合理分配资源 |
| 每日站会 | 问题早发现早解决 |
| 燃尽图 | 可视化进度，及时调整 |
| Sprint评审 | 客户参与，保证方向正确 |
| Sprint回顾 | 持续改进团队效能 |
7.2 经验教训
经验：
- 短周期Sprint（2天）适合小团队快速迭代
- 前端Mock开发可以显著减少联调时间
- 基础类封装是减少重复工作的有效手段
- 客户参与评审可以及时纠正偏差
教训：
- 自动化测试应该在开发过程中同步进行
- 技术债务需要及时偿还，否则会越积越多
- API文档应该与开发同步，避免沟通成本
7.3 团队成长
通过本次项目，团队在以下方面有所成长：
- 流程规范 - 建立了完整的敏捷开发流程
- 协作效率 - 前后端协作更加顺畅
- 技术深度 - 掌握了RAG、向量数据库等新技术
- 质量意识 - 更加重视代码质量和测试
浙公网安备 33010602011771号