在 Azure Boards 中实现开发任务
Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018
开发任务是起源于需求的开发工作的一小部分。 实现开发任务涉及向软件添加适当的新功能。 完成开发任务后，应该对项目进行单元测试、评审、代码分析，并将其集成到现有基本代码中。
估计开发任务的成本
估计开发任务的成本有助于控制功能范围和计划开发工作。 在迭代计划会议前，应完成对所有开发任务的成本估计，并解决任何问题。 如果开发任务的总成本高于能够在一次迭代中完成的量，则应推迟或重新分配任务。 选择开发任务后，开发人员负责为任务付费。
为所选的每个开发任务创建一个任务工作项，并将其链接到作为其创建依据的要求。 此操作是通过任务或要求工作项上的“实现”选项卡完成的。 根据完成类似任务所需的时间进行估计，并确保将写入单元测试的成本考虑在内。 对于每个任务，在任务工作项的“初始估计”字段中输入估计值。
任务工作项的窗体将数据存储在下图所示的字段和选项卡中：
创建并估计任务后，使用“工作细分”查询查看所有需求和任务的分解信息。 有关详细信息，请参阅 CMMi 进程、列出工作项。
创建设计文档
设计文档应包含足够的信息，用于向开发人员描述如何编写代码以实现产品的内在要求。
设计文档可以是规范、需求工作项和其他文档的集合，具体取决于你的团队过程。
在为你的团队确定的设计中，考虑使用设计模式、面向对象的设计、结构化模型、建模语言、实体关系模型和指南中的其他技术。 记录关键决策的理由也是一个好主意。 例如，如果对成本、计划或技术性能产生重大影响，请记录这些影响背后的决策原因，并在设计中包含该信息。
创建必需的设计文档后，将其保存在你的团队成员可以共享的位置。 有关详细信息，请参阅 管理文档和文档库。
进行设计评审
设计评审用于确保新设计或修订的设计在技术上正确、完整、可测试且高质量，并正确实施要求。 设计评审是通过在代码中出现问题之前找出问题，从而尽早保证质量的一个关键方法。 设计评审还提供有关其他开发人员设计的详细信息。
负责创建设计的开发人员应通过确定审阅者、安排评审以及将设计分发给所有审阅者，来组织设计评审。
涉及设计或受设计影响的任何利益干系人均应参与评审。 通常，此评审可能包括项目经理、首席开发人员和设计领域的测试人员。 与要评审其代码的开发人员处于同一个团队的所有开发人员也应参与评审。
安排评审会议，并尽早分发设计文档，让每个审阅者有足够时间来阅读它们。 计划评审会议的持续时间，使之与必须评审的技术性细节数量相对应。
验证设计质量
确保设计可测试。 是否生成不能以合理的方式验证或复核的代码？ 如果是这样，则无法确保代码的质量，并且必须重新处理设计。 检查设计文档中是否存在将导致代码错误的问题。 查找不正确的接口描述、设计错误或命名冲突。 将设计文档与现有的标准（如运算符接口标准、安全标准、生产约束、设计容差或部件标准）进行比较。 创建 Bug 工作项，用于描述在设计文档中找到任何缺陷，并将它们分配给相应的开发人员。
为设计创建审阅工作项
创建评审工作项的目的是为了记录设计评审的结果。 评审团队必须确定设计的后续步骤，具体取决于所需的更改数量。 如果不需要进行任何更改，请将工作项的“状态”设置为“已结束”，将“原因”设置为“已接受（按原样）”，并注意可以对该设计开始编码。 如果需要进行次要更改，请将工作项的“状态”设置为“已解决”，将“原因”设置为“已接受但有次要更改”。 此设置指示在设计中实现次要更改后，编码可以开始。 如果需要进行主要更改，请将工作项的“状态”设置为“已解决”，将“原因”设置为“已接受但有主要更改”。 必须对设计进行返工并再次进行设计评审，才能对该设计开始编码。
单元测试
单元测试将验证代码单元的正确实现。 在开始测试之前编写和完成单元测试可识别 bug，并帮助降低质量控制成本。 对于作为实施开发任务或 Bug 修复的一部分而编写的所有代码，开发人员必须为其编写单元测试。 有关详细信息，请参阅 单元测试代码。
代码分析
代码分析将检查代码是否违反帮助强制实施开发指导原则的一组规则。 代码分析的目标是不出现代码分析冲突或警告。 代码分析可检查代码中是否存在命名约定、库设计、本地化、安全性和性能方面的 200 多个潜在问题。
如果在开发周期的早期开始运行代码分析，就可以最大程度减少开发过程中的冲突和警告。
但是，如果对之前尚未检查过的现有代码运行代码分析，则可能产生许多规则冲突。 如果是这样，你可能想要创建代码必须传递的关键规则的基线集，然后将规则集展开为解决的更关键问题。 这样一来，团队就可以继续开发能够改善现有基本代码的新功能。
有关详细信息，请参阅 Visual Studio 中托管代码的代码分析概述 ，以及 创建或更新标准代码分析签入策略。
代码评审过程
首席开发人员应通过明确审阅者、安排代码评审以及将待评审的代码发送给所有审阅者，来组织代码评审。 要准备代码评审，请执行以下步骤：
创建评审工作项，以跟踪评审中作出的决策。 如果不需要进行任何更改，请将工作项的“状态”设置为“已结束”，将“原因”设置为“已接受（按原样）”，并注意可以对该设计开始编码。 如果需要进行次要更改，请将工作项的“状态”设置为“已解决”，将“原因”设置为“已接受但有次要更改”，这表示实现次要更改之后可以开始编码。 如果需要进行主要更改，请将工作项的“状态”设置为“已解决”，将“原因”设置为“已接受但有主要更改”。 必须对设计进行返工并再次进行设计评审，才能对该设计开始编码。
确定将参与代码评审的人员。 通常情况下，至少应有首席开发人员和负责该代码区域的架构师应参与评审。
与审阅者安排评审会议，让每一位审阅者在会议之前有充足的时间来阅读和理解代码。 计划评审会议的持续时间，使之与必须评审的代码数量相对应。
代码评审
代码评审用于确保新代码或更改的代码在集成到每日生成之前符合既定的质量条。 质量考虑因素有编码标准、与体系结构和设计的一致性、性能、可读性和安全性。 代码评审还提供有关编写代码方式的其他开发人员的更多见解。
| 任务 | 描述 |
|---|---|
| 验证代码相关性 | 待评审的代码与为其编写代码的任务相关。 不应允许更改代码，无法解决实现或更正的功能。 |
| 验证扩展性 | 编写代码使其能够在有需要时进行扩展，或能够在系统的其他区域中重用。 在可以国际化的资源中正确放入了代码中使用的字符串常量。 |
| 验证最小代码复杂性 | 重复的代码可以简化为公共函数。 将类似功能置于公共过程或函数中。 |
| 验证算法复杂性 | 将所评审代码中的执行路径数降至最低。 |
| 验证代码安全性 | 检查代码是否能够保护保护、权限级别以及入口点处数据的使用。 |
重构代码
在代码评审决定必须进行更改以解决代码质量、性能或体系结构问题后，对代码进行重构。
阅读代码评审工作项说明，以确定如何重构代码。
以增量方式应用重构，每次进行一个更改。 根据需要更改代码以及对修改后区域的所有引用。
完成单元测试，使区域在重构后保持语义等效。 修复任何不起作用的单元测试。 运行代码分析并修复任何警告。 如果由于代码分析而进行了代码更改，请再次运行单元测试。
集成更改
最后一步是通过将更改签入到版本控制来集成更改。 在签入代码之前，应执行过程所需的任何测试。 有关如何在签入之前检查代码是否存在问题的详细信息，请参阅 使用团队项目签入策略增强代码质量。
如果与更改关联的工作项是你不是所有者的方案或服务质量要求，请通知所有者更改已完成。 将任务工作项设置为“已解决”，并将其分配给为工作项创建测试用例的测试人员之一。
如果与更改相关联的工作项是一个 Bug，请将该 Bug 工作项设置为“已解决”，并将其分配给其最初创建者。