在 Taiga 中创建新产品

准备一个明确结果

本场景使用虚构的设备申请服务。经理记录员工的设备申请及处理决定。员工自助功能留待后续扩展。学习时使用合成记录。本场景不授权使用真实人事数据。

创建产品前，确认组织和相关共享上下文已经设置好。确定谁对服务结果负责，以及哪个团队负责运行环境。

写出初始边界：首个版本记录申请与决定，不订购设备、不自动批准支出，也不修改薪资记录。

选择产品起点

为这个新服务选择 Start from scratch。如果应以现有代码仓库为起点，则选择 Import codebase。导入是在创建产品时作出的选择，因此要明确决定。

创建时还会询问，是否由 Taiga 编写 Infrastructure code 和 CI/CD pipelines。这是两项独立职责。如果平台团队已经提供其中一项，就关闭该项生成选项，并说明当前工作方式。

例如：“我们的平台通过现有代码仓库流水线部署经过审查的容器镜像。使用其工作负载身份和环境配置。”依赖这段描述前，先确认它准确。

对话前先提供上下文

Discovery 从 Context 开始。对话前添加相关产品参考材料和持续适用的指令。多个产品共用的规则，应放在组织或工厂层级。

对于设备服务，有用上下文包括员工身份验证方式、获准数据服务，以及经理访问规则。明确写出尚未解决的问题。不要为了填完表格，就编造保留期限。

随后在对话中描述服务。解释用户、预期结果、限制和范围外事项。工作过程中，规格说明会保存为草稿。

审查并发布意图

阅读规格说明，查找会改变实现的假设。本场景中，应检查经理可以查看所有员工的申请，还是仅自己团队的申请。这一区别会影响权限、数据流和测试。

内容适合下游工作时，发布规格说明。再次发布前，草稿修改不会替换已发布版本。继续完成必需文档，并审查其中的假设。Discovery 课程解释了依赖关系和过期文档。

八份必需文档全部发布后，完成 Discovery，再规划 initiatives。生成的顺序是提案，可以检查和修改。

连接真实交付目标

详细规划 initiative 前，连接代码仓库。同时定义预期环境，虽然开始规划并不要求已有环境。

环境描述不会授予云访问权限。部署由你的流水线执行。与负责团队核对代码仓库分支、身份、基础设施职责，以及必要设置任务。

本场景的有用结果是定义清楚的产品，以及基于真实交付环境、可供审查的工作。在 Taiga 工作流模拟中练习决策顺序。