将目标结果转化为 initiative

先描述结果，再描述步骤

虚构设备服务需要员工自助功能。有用的请求应说明结果：“已通过身份验证的员工可以创建申请，并且只能查看自己的申请。”

解释原因：目前由经理代员工录入申请。定义范围：创建申请、显示状态、访问检查，以及验证这些行为的证据。不包括自动采购，也不改变经理审批规则。

检查代码仓库前，不要指定必须如何编辑文件。Initiative 记录意图，详细规划再将意图转为实现步骤。

审查请求产生的结果

Taiga 使用请求与产品上下文，创建一个 initiative 或一组有序的 initiatives。新工作进入 Backlog。较大的请求可能需要分成多个可独立审查的变更。

阅读生成的最终状态、Why 和 Scope。检查必要行为是否保留，以及是否遵守排除项。如果现有 initiative 已覆盖请求，Taiga 可以指出它，而不创建重复项。

如果请求被已发布策略阻止，就需要遵循该策略规定的决策路径。阅读说明，并通过这条路径解决冲突。不要仅为隐藏被禁止的操作而改写请求。

将看板视为执行顺序

Taiga 对每个产品一次处理一个 initiative，包括规划。当前 pull request 合并后，才启动下一个排队的 initiative。它不会自动将 Backlog 或 Todo 中的项目移入 Queue。

放入 Queue 是重要决定，它会覆盖等待未完成依赖的行为。将员工自助功能排入队列前，确认身份基础已经存在，或所选范围会正确建立它。

检查详细计划

规划器读取代码仓库、产品文档、策略、指令和部署上下文。根据实际用户结果与环境检查计划。

对于设备服务，验证三种访问情况：员工能看到自己的申请；另一名员工看不到；经理保留预期审查权限。如果实现会改变数据迁移或运维行为，也应纳入这些影响。

如果 Build on its own by default 关闭，完成的计划会等待你的决定。Approve 以批准者身份启动构建，并受其权限限制。Reject 根据反馈重新规划。每个 initiative 可以有自己的设置。

为下一次决定使用正确记录

计划有版本。一次 run 会记录执行了哪个计划。如果预期方案变化，审查 initiative，并选择适当的重新规划操作。用 run 检查上次尝试。

构建、已合并的 pull request 和生产发布是不同状态。工作推进时，保持验收证据和部署职责清晰可见。继续学习自主运行设置。