将现有代码库导入 Taiga

从现有系统开始

一个虚构设备申请服务已经存在。团队希望使用 Taiga 维护它，同时保留正常工作的集成。

创建产品时选择 Import codebase。连接代码仓库并开始分析。这条路径使用代码仓库分析，替代新产品对话。从零创建的产品，之后不能再添加这条导入路径。

确认代码仓库访问，以及 Taiga 应使用的分支。在适当上下文层级添加持续适用的限制。本例中，应说明必须继续使用现有员工身份集成。

先审查推导出的规格说明

Taiga 从代码推导产品文档，并包含代码仓库引用。引用有助于核查解释，但不能确立每种现有模式背后的业务意图。

检查规格说明中的三项内容：

• 目的： 描述的目标是否符合服务存在的原因？
• 限制： 哪些模式是有意设定的要求？
• 已知缺陷： 哪些当前行为应该改变？

设备服务包含旧版授权模块。文档可能准确记录了它的使用，但这不代表团队应该扩展该模块。

打开引用文件，将相关行为与文档表述比较。记录现有证据的局限，例如代码仓库之外的配置或运行行为。

选择正确修正方式

导入文档跟随代码。不要把它们当作人工维护的未来系统描述。刷新一份文档，也会重新推导它依赖的文档。因此，刷新靠后的文档可能需要更多工作。

对于旧版模块，指令可以写成：“不要新增对旧版授权模块的调用。新工作使用已批准的替代接口。”验证该接口确实存在，并写出其实际代码仓库位置。

评估首批 initiatives

导入工作流还会运行代码仓库扫描、根据已发布策略进行评估，并开展初始 initiative 规划。某个阶段如果缺少必要前置条件，可以跳过，并说明原因。规划会使用可用的发现和策略评估。

根据代码仓库审查提出的缺口。初始 initiatives 处理缺失能力、基础工作，或相关且尚未解决的依赖问题。它们不是一份无人提出需求的新功能清单。

保留有用的现有能力。拒绝或修正不必要的重建提案。新的业务要求应单独添加一个 initiative。

保留有证据支持的起点

完成 Discovery，并审查 initiative 提案。详细规划前，确认环境和交付职责。工作推进时，保持导入内容、代码变更和产品指令一致。

结果是团队理解的起点，以及可以编辑的待办列表。这不代表所有现有行为都正确。继续学习 initiative 规划。