Jira 中的规范驱动型开发
规范驱动型开发，是指在支持人员开始构建代码前先编写一份结构化规范，确保支持人员构建符合预期的成果，而非做出看似合理的推测。在 Jira 中，这份规范存放于您日常使用的工作项当中，承载着真实的开发意图：成果、工作范围、约束以及验收标准。一个工作项可以包含单项任务的完整规范，也可以存放一份大型功能规范拆分后、分配至多个工作项中的其中一部分。
本指南将介绍一份规范需要具备哪些条件才可交付支持人员使用、为何工作项是存放该规范的合适载体，以及如何编写您的第一份规范。简言之，Jira 中的规范驱动型开发可为您带来三项益处：
单一事实来源：支持人员以此为依据开展开发，审查人员据此对照检查
验收标准：为支持人员和人工统一界定“完成”的定义
减少返工：在支持人员编写任何一行代码之前就敲定开发意图
什么是规范驱动型开发？
规范驱动型开发是这样一种实践：您编写一份结构化规范，明确待开发内容以及成功的衡量标准，再交由支持人员实现，而非仅靠一行提示词让支持人员自行猜测。
这份规范便成为单一事实来源。它推动计划制定、开发以及检查，并且在 Jira 中，以上三项工作全都在同一个工作项上完成。该理念早于人工智能诞生，起源于 API 设计与形式化方法实践，核心思路是：在着手开发之前先定义行为。
随着工具的成熟，其定义本身也在持续变化，因此应当将其视作一套实践，而非一套固定不变的规范格式。但其核心做法始终不变：在支持人员开始编码之前，先定义清楚工作内容。
二者的区别在于厘清模糊问题的时机。直觉式编码是在代码写完之后才解决模糊问题；规范驱动型开发则在编码启动之前就消除歧义。
直觉式编码：您通过提示词引导支持人员，并接收它返回的成果。因此，支持人员自行假定的工作范围、约束条件与边界问题，只会在代码生成完成之后才暴露出来。
规范驱动：您先敲定意图、约束条件以及验收标准，支持人员便依照这份既定定义开展工作，而非凭直觉猜测；后续审查也将依托这份定义，在保存的工作项上进行核验。
对于需要长期保留在真实代码库中的代码，如果支持人员缺少确定完整的上下文，它可能只会刻板地完成工作单，忽略关键的约束条件，返工也就由此产生。
提示词往往会模糊两件事：规范代表您所要构建的内容，计划代表构建的方式。规范驱动型开发会先敲定“做什么”，再据此制定“怎么做”。这正是人工智能编码工具的计划模式常常跳过的环节：它直接根据提示词草拟实现方案，而背后通常没有一份达成共识的规范。
计划模式可以充当一份轻量化规范，但它是即时根据提示词草拟出“实现方式”，而非基于一份留存于工作项、已经达成共识的规范。
为什么规范对人工智能编码至关重要
当代码生成的成本变得低廉，难点就不再是编写代码，而是定义出正确的开发目标。这就让规范，而非提示词，成为您产出的最高效益工件。
一次性提示词会把诸多信息缺口留给支持人员，支持人员将依靠自身假设补齐缺口，生成看似正确却解决了错误问题的代码。而规范会先填补这些缺口，让支持人员依照既定定义开展开发，而非进行猜测。在 Jira 中，这份规范就是团队已经用来规划、分配以及评审任务的工作项。
一份可供支持人员遵照执行的规范需要包含哪些内容？
适配支持人员的规范，应当回答一名优秀工程师开工前会提出的各类问题。在 Jira 中，这些信息存放于工作项的摘要、描述、关联需求以及验收标准内。有六项要素至关重要：
成果：变更所要达成的目标，采用审查人员可核验的措辞进行描述。
范围：明确包含的内容，以及同等重要的排除项。
约束条件：需要遵守的架构、安全以及性能限制。
先前决策：已经敲定的上下文信息，避免支持人员重新讨论已有信息。
任务拆解：将工作拆分为足够细小、可核验的步骤。
验收标准：可测试的完成定义，支持人员以此为开发目标，审查工作也据此开展。在 Jira 中，验收标准存储在工作项上，人工审核之前，人工智能代码审查便可对照这些标准检查变更内容。
工作项如何在 Jira 中成为规范
一份格式完善的工作项，可以作为支持人员开发与审查所依据的规范。规范也可存放于一份关联文档中，许多 SDD 工具正是采用这种方式；而 Jira 可将规范直接保存在工作开展的地方。当工作项具备上述六项要素时，它便达到了规范标准。仅写着“修复登录缺陷”的单行工作项不是规范。
将规范保存在工作项上具备一项结构性优势：规范与工作本身处于同一位置，相较于存放在代码存储库内、无人再会打开的 Markdown 文件，这份规范更不容易被弃置。但这并不代表规范能够自行维护。它仅仅意味着规范和工作内容永远不会出现脱节。
所有内容统一归集一处：摘要、描述、关联的 Confluence 需求以及验收标准，支持人员与审查人员均可查阅。
相比之下，代码存储库文件独立于工作跟踪、审查和办结的载体，因此一旦计划变更，文件内容就会立刻过时。
支持人员完成工作后，该工作项就转为审查界面，团队可在此就需求、待解决问题达成共识。
Jira 可制定包含清晰需求、任务与预估工时在内的计划。
Jira 规划器如何生成结构化规范
上一节介绍了基础方式：由您手动将单个工作项转化为一份规范。Jira 规划器适用于跨多个团队的复杂项目举措，在这类场景下，手动编写每一份规范无法规模化推进。Jira 规划器会从项目举措着手，将其拆解为多个结构化工作项，并且每一项都附带独立的规范。
Jira 规划器是加速器，而不是基础工具。SDD 的基础实现方式，就是一份完善的工作项搭配验收标准，目前所有团队均可落地。Jira 规划器可以加快这项工作中最棘手的环节：将复杂、模糊的请求转化为结构化规范。
对于复杂项目，Jira 规划器依托 Teamwork Graph，整合代码库、Jira 与 Confluence 历史记录以及团队上下文信息，定义需求并生成 Confluence 内的结构化技术规范，可供开发人员或编码支持人员直接基于其开展开发。一份计划，面向两类受众：人类可读，支持人员可用。
功能说明：
提供可供您和团队协作的共享界面，在支持人员执行工作之前提前达成共识。
从您全部的工作中提取上下文，让规范基于团队已有的信息生成，而非从空白提示词开始。
成一份人类易读、支持人员可顺畅解析的规范，同一份工件既可用于审查，也可用于开执行。
将规范保存在 Confluence 中并与工作相关联，以便意图与各项决策均可留档保存。
Jira 规划器可将粗略想法转化为适配支持人员的结构化规范
Jira 规划器目前处于抢先体验阶段—注册以加入候补名单
如何在 Jira 中编写第一份可供支持人员执行的规范
选取一个工作项，以六项要素作为清单，手动将其转化为可供支持人员执行的规范。
从一个工作项开始。在描述栏中写明成果、范围边界以及约束条件，而非仅填写标题。
将意图转化为结构化的规范。这才是 SDD 的核心工作。在工作项上把已有上下文梳理成成果、范围与约束条件，让支持人员可以获取定义。
编写可测试的验收标准。验收标准是支持人员的开发依据，也是审查人员的核查准则。大多数标准都需要经过数次修改，才能达到可测试的要求。
将其分配给编码支持人员。达到规范标准的工作项可为支持人员提供充足信息，使其完成实施并创建关联到此工作项的拉取请求。
对照验收标准审查拉取请求，随后迭代优化。针对支持人员自行推断决策的地方完善规范，并将这套模式复用到下一个工作项。
规范驱动型开发常见问题解答
开展规范驱动型开发是否必须使用 Jira 规划器？
不需要。基础实现方案就是一份填写完善、附带验收标准的工作项，任何团队当下都可以编写。针对复杂工作，Jira 规划器能够提升效率：它从顶层计划（项目举措）出发，将其拆解为多个结构化的 Jira 工作项，并且每个工作项都填入对应规范，免去您手动逐条编写的工作。
规范与验收标准有何区别？
规范定义了变更的全部内容：成果、范围、约束条件以及上下文信息。验收标准属于规范的一部分，是可测试的“完成定义”，既是支持人员的开发目标，也是审查人员的核查依据。
一份高质量的提示词是否就足够了？
对于规模较小、可回滚的工作，通常来说足够了。但对于复杂任务或是难以撤销的工作，提示词会导致支持人员对您遗漏的信息自行揣测。而一份规范则能够消除这种猜测行为。
规范应当存放在代码存储库文件还是 Jira 工作项中？
工作项将规范保存在跟踪、审查和关闭工作的位置。相比于存放在代码存储库内、无人再会打开的 Markdown 文件，这种方式更不容易出现内容偏离问题。
规范驱动型开发会不会拖慢团队进度？
该模式会增加前期投入工作量，但能够避免后期返工。对于复杂工作而言，这种取舍能够带来净收益。若是简单微小的修复工作，则可跳过规范，直接使用提示词。
什么时候应当编写规范，什么时候可以跳过？
对于复杂、高影响、难以回滚的工作，或是存在架构、安全约束的任务，请编写规范。对于规模较小、可回滚的修复任务，使用简短提示词效率更高，则可以跳过规范。