317 lines
8.4 KiB
Markdown
317 lines
8.4 KiB
Markdown
<!-- 由 BMAD™ 核心驱动 -->
|
||
|
||
# 创建棕地项目故事任务
|
||
|
||
## 目的
|
||
|
||
为棕地项目创建详细的、可随时实施的故事，因为这些项目可能没有传统的、分片的 PRD/架构文档。此任务弥合了各种文档格式（项目文档输出、棕地 PRD、史诗或用户文档）与可供开发代理执行的故事之间的差距。
|
||
|
||
## 何时使用此任务
|
||
|
||
**在以下情况下使用此任务：**
|
||
|
||
- 处理具有非标准文档的棕地项目
|
||
- 需要从项目文档输出创建故事
|
||
- 根据棕地史诗工作，但没有完整的 PRD/架构
|
||
- 现有项目文档不遵循 BMad v4+ 结构
|
||
- 需要在故事创建期间从用户那里收集更多上下文
|
||
|
||
**在以下情况下使用 create-next-story：**
|
||
|
||
- 使用正确分片的 PRD 和 v4 架构文档
|
||
- 遵循标准的绿地或文档齐全的棕地工作流程
|
||
- 所有技术上下文都以结构化格式提供
|
||
|
||
## 任务执行说明
|
||
|
||
### 0. 文档上下文
|
||
|
||
按以下顺序检查可用文档：
|
||
|
||
1. **分片的 PRD/架构** (docs/prd/, docs/architecture/)
|
||
- 如果找到，建议改用 create-next-story 任务
|
||
|
||
2. **棕地架构文档** (docs/brownfield-architecture.md 或类似文件)
|
||
- 由 document-project 任务创建
|
||
- 包含实际系统状态、技术债务、变通方法
|
||
|
||
3. **棕地 PRD** (docs/prd.md)
|
||
- 可能包含嵌入的技术细节
|
||
|
||
4. **史诗文件** (docs/epics/ 或类似文件)
|
||
- 由 brownfield-create-epic 任务创建
|
||
|
||
5. **用户提供的文档**
|
||
- 要求用户指定位置和格式
|
||
|
||
### 1. 故事识别和上下文收集
|
||
|
||
#### 1.1 识别故事来源
|
||
|
||
根据可用文档：
|
||
|
||
- **从棕地 PRD**：从史诗部分提取故事
|
||
- **从史诗文件**：阅读史诗定义和故事列表
|
||
- **根据用户指示**：询问用户要实施哪个具体的增强功能
|
||
- **没有明确来源**：与用户合作定义故事范围
|
||
|
||
#### 1.2 收集基本上下文
|
||
|
||
关键：对于棕地故事，您必须收集足够的上下文以确保安全实施。准备好向用户询问缺失的信息。
|
||
|
||
**所需信息清单：**
|
||
|
||
- [ ] 哪些现有功能可能会受到影响？
|
||
- [ ] 与当前代码的集成点是什么？
|
||
- [ ] 应遵循哪些模式（附带示例）？
|
||
- [ ] 存在哪些技术限制？
|
||
- [ ] 是否有任何需要注意的“陷阱”或变通方法？
|
||
|
||
如果缺少任何所需信息，请列出缺失的信息并要求用户提供。
|
||
|
||
### 2. 从可用来源中提取技术上下文
|
||
|
||
#### 2.1 从项目文档输出
|
||
|
||
如果使用来自 document-project 的 brownfield-architecture.md：
|
||
|
||
- **技术债务部分**：注意影响此故事的任何变通方法
|
||
- **关键文件部分**：识别需要修改的文件
|
||
- **集成点**：查找现有的集成模式
|
||
- **已知问题**：检查故事是否涉及有问题的地方
|
||
- **实际技术栈**：验证版本和限制
|
||
|
||
#### 2.2 从棕地 PRD
|
||
|
||
如果使用棕地 PRD：
|
||
|
||
- **技术限制部分**：提取所有相关的限制
|
||
- **集成要求**：注意兼容性要求
|
||
- **代码组织**：遵循指定的模式
|
||
- **风险评估**：了解潜在影响
|
||
|
||
#### 2.3 从用户文档
|
||
|
||
要求用户帮助识别：
|
||
|
||
- 相关的技术规范
|
||
- 可供遵循的现有代码示例
|
||
- 集成要求
|
||
- 项目中使用的测试方法
|
||
|
||
### 3. 通过逐步收集细节来创建故事
|
||
|
||
#### 3.1 创建初始故事结构
|
||
|
||
从故事模板开始，填写已知信息：
|
||
|
||
```markdown
|
||
# 故事 {{增强功能标题}}
|
||
|
||
## 状态：草稿
|
||
|
||
## 故事
|
||
|
||
作为一名 {{user_type}}，
|
||
我想要 {{enhancement_capability}}，
|
||
以便 {{value_delivered}}。
|
||
|
||
## 上下文来源
|
||
|
||
- 源文档：{{文档名称/类型}}
|
||
- 增强类型：{{单个功能/错误修复/集成/等}}
|
||
- 对现有系统的影响：{{简要评估}}
|
||
```
|
||
|
||
#### 3.2 制定验收标准
|
||
|
||
关键：对于棕地项目，始终包括关于维护现有功能的标准
|
||
|
||
标准结构：
|
||
|
||
1. 新功能按规定工作
|
||
2. 现有的 {{受影响的功能}} 继续正常工作
|
||
3. 与 {{现有系统}} 的集成保持当前行为
|
||
4. {{相关领域}} 没有回归
|
||
5. 性能保持在可接受的范围内
|
||
|
||
#### 3.3 收集技术指导
|
||
|
||
关键：如果信息缺失，这是您需要与用户互动的地方
|
||
|
||
使用可用信息创建开发技术指导部分：
|
||
|
||
````markdown
|
||
## 开发技术指导
|
||
|
||
### 现有系统上下文
|
||
|
||
[从可用文档中提取]
|
||
|
||
### 集成方法
|
||
|
||
[根据找到的模式或询问用户]
|
||
|
||
### 技术限制
|
||
|
||
[来自文档或用户输入]
|
||
|
||
### 缺失信息
|
||
|
||
关键：列出您找不到的、开发人员需要的任何信息，并要求提供缺失的信息
|
||
|
||
### 4. 带安全检查的任务生成
|
||
|
||
#### 4.1 生成实施任务
|
||
|
||
根据收集的上下文，创建以下任务：
|
||
|
||
- 如果对系统的理解不完整，则包括探索任务
|
||
- 为现有功能添加验证任务
|
||
- 包括回滚考虑
|
||
- 在已知时引用特定的文件/模式
|
||
|
||
棕地项目的示例任务结构：
|
||
|
||
```markdown
|
||
## 任务 / 子任务
|
||
|
||
- [ ] 任务 1：分析现有的 {{组件/功能}} 实现
|
||
- [ ] 查看 {{特定文件}} 以了解当前模式
|
||
- [ ] 记录集成点
|
||
- [ ] 识别潜在影响
|
||
|
||
- [ ] 任务 2：实施 {{新功能}}
|
||
- [ ] 遵循 {{示例文件}} 中的模式
|
||
- [ ] 与 {{现有组件}} 集成
|
||
- [ ] 保持与 {{约束}} 的兼容性
|
||
|
||
- [ ] 任务 3：验证现有功能
|
||
- [ ] 测试 {{现有功能 1}} 仍然有效
|
||
- [ ] 验证 {{集成点}} 行为未改变
|
||
- [ ] 检查性能影响
|
||
|
||
- [ ] 任务 4：添加测试
|
||
- [ ] 遵循 {{项目测试模式}} 的单元测试
|
||
- [ ] {{集成点}} 的集成测试
|
||
- [ ] 如果需要，更新现有测试
|
||
```
|
||
````
|
||
|
||
### 5. 风险评估和缓解
|
||
|
||
关键：对于棕地项目 - 始终包括风险评估
|
||
|
||
为棕地特定风险添加部分：
|
||
|
||
```markdown
|
||
## 风险评估
|
||
|
||
### 实施风险
|
||
|
||
- **主要风险**：{{对现有系统的主要风险}}
|
||
- **缓解措施**：{{如何解决}}
|
||
- **验证**：{{如何确认安全}}
|
||
|
||
### 回滚计划
|
||
|
||
- {{如果需要，撤消更改的简单步骤}}
|
||
|
||
### 安全检查
|
||
|
||
- [ ] 在更改前测试现有的 {{功能}}
|
||
- [ ] 更改可以通过功能标志或隔离
|
||
- [ ] 回滚过程已记录
|
||
|
||
```
|
||
|
||
### 6. 最终故事验证
|
||
|
||
在最终确定之前：
|
||
|
||
1. **完整性检查**：
|
||
- [ ] 故事有明确的范围和验收标准
|
||
- [ ] 技术上下文足以实施
|
||
- [ ] 集成方法已定义
|
||
- [ ] 风险已识别并有缓解措施
|
||
|
||
2. **安全检查**：
|
||
- [ ] 包括对现有功能的保护
|
||
- [ ] 回滚计划是可行的
|
||
- [ ] 测试涵盖了新功能和现有功能
|
||
|
||
3. **信息差距**：
|
||
- [ ] 从用户那里收集了所有关键的缺失信息
|
||
- [ ] 为开发代理记录了剩余的未知数
|
||
- [ ] 在需要时添加了探索任务
|
||
|
||
### 7. 故事输出格式
|
||
|
||
使用适当的命名保存故事：
|
||
|
||
- 如果来自史诗：`docs/stories/epic-{n}-story-{m}.md`
|
||
- 如果独立：`docs/stories/brownfield-{feature-name}.md`
|
||
- 如果顺序：遵循现有的故事编号
|
||
|
||
包括说明文档上下文的标题：
|
||
|
||
```markdown
|
||
# 故事：{{标题}}
|
||
|
||
<!-- 来源：{{使用的文档类型}} -->
|
||
<!-- 上下文：对 {{现有系统}} 的棕地增强 -->
|
||
|
||
## 状态：草稿
|
||
|
||
[故事内容的其余部分...]
|
||
```
|
||
|
||
### 8. 交接沟通
|
||
|
||
向用户提供清晰的交接：
|
||
|
||
```text
|
||
已创建棕地故事：{{故事标题}}
|
||
|
||
源文档：{{使用了什么}}
|
||
故事位置：{{文件路径}}
|
||
|
||
已识别的关键集成点：
|
||
- {{集成点 1}}
|
||
- {{集成点 2}}
|
||
|
||
注意到的风险：
|
||
- {{主要风险}}
|
||
|
||
{{如果信息缺失}}：
|
||
注意：一些技术细节尚不清楚。故事中包括了探索任务，以在实施过程中收集所需信息。
|
||
|
||
后续步骤：
|
||
1. 审查故事的准确性
|
||
2. 验证集成方法是否与您的系统一致
|
||
3. 批准故事或请求调整
|
||
4. 然后开发代理可以带安全检查地实施
|
||
```
|
||
|
||
## 成功标准
|
||
|
||
当满足以下条件时，棕地故事创建成功：
|
||
|
||
1. 故事可以实施，而无需开发人员搜索多个文档
|
||
2. 集成方法清晰且对现有系统安全
|
||
3. 所有可用的技术上下文都已提取和组织
|
||
4. 缺失的信息已识别并得到解决
|
||
5. 风险已记录并有缓解策略
|
||
6. 故事包括对现有功能的验证
|
||
7. 回滚方法已定义
|
||
|
||
## 重要说明
|
||
|
||
- 此任务专门用于具有非标准文档的棕地项目
|
||
- 始终将现有系统的稳定性置于新功能之上
|
||
- 如有疑问，请添加探索和验证任务
|
||
- 最好向用户澄清，而不是做出假设
|
||
- 每个故事都应该是为开发代理准备的自包含的
|
||
- 在可用时包括对现有代码模式的引用
|
||
```
|