跳转至

译文

译自西班牙语原文，以原文为规范文本。 状态：草稿，待人工审校。如有歧义，以西班牙语原文为准。

SCAFFOLD — 项目生命周期

概要。 本页按七个阶段完整走一遍软件项目：启动、规划、组织人员与智能体、构建、集成、交付，以及运营与学习。每个阶段都说明做什么、留下哪些可审查的产出、适用 SCAFFOLD 0.1 的哪些要求，以及由谁决定。本页还说明项目并非从零开始时应从何处切入。本页只做解释；规范在要求中。

确定性等级（MILPA）：各项要求所描述的内容是已被接受的规范；阶段的顺序、示例和类比属于编辑层面的呈现。目前没有实测证据表明这一流程能减少错误或缩短工期（假设，无来源）。

适用对象与第一步

适用于协调软件项目的人，项目中可以是人员、人工智能助手，或两者共同工作（参见 人工智能范围）。第一步：先确定从哪里切入（见“从哪里开始”一节），再阅读对应的阶段。批次、交接说明和写入区这几个术语见 SCAFFOLD 简介和词汇表。

施工类比

SCAFFOLD 已经用脚手架来解释。本生命周期把这一形象扩展到整个工程；这是一种编辑层面的对应关系。

施工中的形象 编辑层面的对应 可观察的做法
施工委托：建什么、为谁建、由谁负责。 项目章程。 载明目标、范围、负责人和成功标准的文档。
对既有建筑的勘测：动工前先测量已有的部分。 对既有项目的现状盘点。 带日期的清单，每项数据都标明是有来源的事实还是假设。
施工小组，每组有一名组长。 由人员、智能体或两者混合组成的小组，设有负责人。 小组卡片，列出成员、区域以及每个智能体的监督人。
分配给每个小组的一段脚手架。 写入区。 标明各路径归属者的路径图。
工程验收：委托方检查并接受已建成的部分。 对已完成工作的验收以及对交付的授权。 记录验收人以及已做的检查。
交付建筑前拆除脚手架。 将工程层排除在已部署制品之外。 对已构建制品的检查（R-011）。

局限（DOC-AX-005）。 土木工程有许可、安全规范和法律责任，这一类比既不描述也不替代这些内容。智能体小组不是工人小组：智能体不担任任何责任角色，仍由负责人承担责任（R-030）。这个形象并不能证明某项控制有效、能节省时间或项目是安全的；这些结果需要各自的度量。

图示

flowchart LR
  accTitle: SCAFFOLD 中的项目周期
  accDescr: 七个阶段依次推进，从启动到运营与学习。三条虚线让工作返回：从集成回到构建，从运营与学习回到规划，以及从运营与学习回到章程。
  M1["1 启动：项目章程或现状盘点"] --> M2["2 规划：工作清单"]
  M2 --> M3["3 组织：小组与分配"]
  M3 --> M4["4 构建：批次与交接"]
  M4 --> M5["5 集成：分支与合并请求"]
  M5 --> M6["6 交付：环境与发布版本"]
  M6 --> M7["7 运营与学习：度量与事故"]
  M5 -.->|"检查失败或要求变更"| M4
  M7 -.->|"行动转为工作项"| M2
  M7 -.->|"目标或范围变更"| M1

可编辑的 Mermaid 源文件。

如何阅读。 每个方框是一个阶段。实线箭头表示通常的先后顺序：一个阶段的产出是下一个阶段的输入。虚线箭头表示回流：工作按箭头上所写的原因回到前面的阶段。各阶段可以重叠和重复：一个工作项在交付的同时，另一个在构建。该图并不规定必须遵循的顺序，也不代表已实现的控制。图中没有颜色图例：信息都在方框和箭头的文字中。

七个阶段

1. 启动

  • 做什么。 以书面方式约定要建什么、由谁负责。从零开始时，撰写项目章程。在已有工作的基础上，则先做现状盘点。声明助手将读取的启动上下文；如果有多个仓库，还要声明协调它们的根。
  • 可审查的产出。 带版本和日期的项目章程，或事实与假设分开的带日期现状盘点；关键影响目录；所引用的内容真实存在的启动上下文。
  • 要求。 R-019 章程、 R-020 现状盘点、 R-004 启动上下文、 R-014 和 R-015 复合项目。
  • 由谁决定。 产品负责人决定章程及其变更；技术负责人对现状盘点负责。

2. 规划

  • 做什么。 工作以工作项的形式登记在有序的工作清单中，并带有验收标准。声明就绪条件、完成定义和节奏。细节见工作与节奏。
  • 可审查的产出。 工作项完整的工作清单；带版本的各项定义；已声明的节奏。
  • 要求。 R-021、 R-022、R-023、 R-024。
  • 由谁决定。 产品负责人负责排序、接受和舍弃；协调负责人声明就绪、完成和节奏。助手可以提议，但不做决定。

3. 组织人员与智能体

  • 做什么。 组建小组，声明每个小组的写入区，并把每个工作项分配给一名负责人，即使由智能体执行。区分人员的产能与智能体的产能。小组的细节见小组。
  • 可审查的产出。 每个小组的卡片；区域图；带负责人的分配；按类型声明的产能。
  • 要求。 R-030、 R-031、R-001、 R-003。
  • 由谁决定。 协调负责人。

4. 构建

  • 做什么。 每个工作项在一个或多个批次中执行，并声明区域和助手。更换助手时留下交接说明。对契约和第三方依赖进行审查；过时的契约不得用于功能类型的批次。探索如果被允许，须单独进行，并被舍弃或纳入正式批次。
  • 可审查的产出。 载明目标、负责人、区域、时间段、状态、结果以及实测成本或“未知”的批次；带状态的交接说明。
  • 要求。 R-009、 R-002、R-005、 R-006、R-007、 R-008、R-016、 R-018、R-012。
  • 由谁决定。 批次负责人决定其批次；技术负责人决定契约和依赖。

5. 集成

  • 做什么。 变更通过引用工作项或批次的合并请求进入主分支，通过已声明的检查，并由一个人审查。助手不直接写入主分支。
  • 可审查的产出。 已声明的分支约定；引用了工作项或批次的分支和合并请求；检查结果；人工审查者。
  • 要求。 R-025、 R-026、R-010。
  • 由谁决定。 技术负责人定义分支模型；由人审查并合并每个合并请求。

6. 交付

  • 做什么。 通过检查的制品在各环境之间晋级，无需重新构建；上线生产之前有回滚计划；每个发布版本带有标签、说明和授权。只服务于工程的内容留在制品之外。紧急通道如果存在，须事先定义。细节见交付。
  • 可审查的产出。 环境声明；部署记录；回滚计划；标签和发布说明；对制品的排除检查。
  • 要求。 R-027、 R-028、R-029、 R-011、R-013。
  • 由谁决定。 交付负责人。部署到生产被视为关键影响：由人授权，而不是助手 （ASILO-R-005）。

7. 运营与学习

  • 做什么。 度量已声明的交付指标。每次生产事故和每次回滚都要审查，列出事实、作为假设的可能原因以及行动。定期开展对已完成工作的评审和流程改进。
  • 可审查的产出。 带来源的指标；事故审查；评审与改进的纪要；由行动创建的工作项。
  • 要求。 R-032、 R-024。
  • 由谁决定。 协调负责人；事故由其与交付负责人共同处理。

从哪里开始

生命周期并不要求从第一个阶段开始。切入点取决于已有的内容。这些阶段不是成熟度等级；参见分步采用。

情形 第一步 随后
从零开始 在开设第一个功能类型批次之前，撰写项目章程（R-019）。 工作清单、小组、第一个周期。
从既有仓库开始 登记现状盘点（R-020）：仓库、环境、检查、发布版本、归属者、技术债和进行中的工作。 根据盘点结果撰写项目章程；由盘点产生工作项。
项目进行到一半，有工作在途 做现状盘点，把每项在途工作转为工作项，或说明理由后舍弃。 整理工作清单，声明节奏和完成定义；已经合并的不返工。
一个人加一个助手（最小可行） 一个简短文件，包含：简短的项目章程（R-019）、最小工作清单（R-021）、完成定义（R-023）、已声明的节奏（R-024）、简单的分支模型（R-026）以及合并前的检查（R-010）。 每个任务一个批次并声明区域，合并前登记结果和检查。

各情形说明：

  • 从零开始。 章程确定目标、范围、排除项、负责人、关键影响目录、数据限制和可观察的成功标准。一份完整的章程也可能描述了错误的目标（R-019 的残余风险）。
  • 既有仓库。 现状盘点把已检查的内容与假定的内容分开。没人记得的内容不会出现（R-020 的残余风险）：在验证之前宜将其视为假设。
  • 项目进行到一半。 这是最常见的情形。已经开始的工作项以其真实状态（例如 en_curso）进入工作清单，不重新开始。状态见工作与节奏。
  • 一个人加一个助手。 在只有一个人的项目中，这个人担任卡片中的所有角色。只有一个助手时无需组建小组（R-030 适用于以小组方式工作的项目，而助手依据 ASILO-R-004 保持其身份和范围），也无需交接说明：交接说明适用于在同一批次内更换助手的情形。所有内容放在一个文件里即可。这一最小集合是对各项要求的编辑性解读；每项要求都保留其适用条件，适用于所有项目的要求（例如 R-019、R-021、R-023、R-024 和 R-026）依然有效。裁剪时若省略了某项适用的要求，须按要求公共字段所述登记例外。

连续的虚构示例

Ana 维护一家网店，有两个助手：一个写入 src/，另一个写入 tests/。在阶段 1，她撰写了章程（v1），其可观察的成功标准是管理团队能下载当月订单。在阶段 2，她创建了“导出”这一倡议和工作项 TIE-12“将订单导出为 CSV”。在阶段 3，她把 TIE-12 分配给自己作为负责人，尽管由助手执行。在阶段 4，她开设了引用 TIE-12 的功能类型批次。在阶段 5，分支和合并请求引用 TIE-12，Ana 在合并前审查。在阶段 6，她在看过检查结果后授权部署。在阶段 7，一次 CSV 编码错误的事故催生了一次审查和一个新工作项 TIE-19。所有数据均为虚构。

局限

  • 本页不新增要求，也不修改已被接受的要求。关闭批次、完成工作项或部署只是登记一个事实，其本身并不批准结果的质量。
  • 这些阶段描述的是软件项目；使用人工智能而不构建软件，不在 SCAFFOLD 的范围之内。
  • 本页没有关于采用情况、节省、安全或合规的证据。
  • 与其他工作框架（例如 Scrum）的对应与差异见工作与节奏。

继续阅读：工作与节奏、小组、 交付、模板。返回 SCAFFOLD。