实现开发任务

开发任务是起源于要求的开发工作的一小部分。 实现开发任务涉及向软件添加适当的新功能。 完成开发任务后，应该对项目进行单元测试、评审、代码分析，并将其集成到现有基本代码中。

主题内容

估计

设计文档

设计评审

单元测试

代码分析

代码评审过程

重构

集成更改

估计

估计开发任务的成本有助于控制功能范围和计划开发工作。 在迭代计划会议前，应完成对所有开发任务的成本估计，并解决任何问题。 如果开发任务的总成本高于能够在一次迭代中完成的量，则应推迟或重新分配任务。 选择开发任务后，开发人员有责任对任务进行成本估计。

为所选的每个开发任务创建一个任务工作项，并将其链接到作为其创建依据的要求。 通过“任务”或“要求”工作项上的“实现”选项卡完成此操作。 根据完成类似任务所需的时间进行估计，并确保将写入单元测试的成本考虑在内。 对于每个任务，在任务工作项的“初始估计”字段中输入估计值。

任务工作项的窗体将数据存储在下图所示的字段和选项卡中：

创建并估计任务后，使用“工作细分”查询查看所有要求和任务的分解信息。 有关详细信息，请参阅共享查询 (CMMI)。

设计文档

设计文档应包含足够的信息，用于向开发人员描述如何编写代码以实现产品的内在要求。

设计文档可以是规范、要求工作项和其他文档的集合，具体取决于你的团队过程。

在为你的团队确定的设计中，考虑使用设计模式、面向对象的设计、结构化模型、建模语言、实体关系模型和指南中的其他技术。 将对所作关键决策的阐释归档也是不错的选择。 例如，如果对成本、计划或技术性能有显著影响，请记录为何作出了造成这些效果的决定，并将该信息包含在设计中。

创建必需的设计文档后，将其保存在你的团队成员可以共享的位置。 有关详细信息，请参阅管理文档和文档库。

设计评审

设计评审用于确保新的或修改的设计在技术上准确、完整、可测试性且质量高，并确保它正确实现要求。 设计评审是通过在代码中出现问题之前找出问题，从而尽早保证质量的一个关键方法。 设计评审还提供来自其他开发人员的有关设计的其他见解。

负责创建设计的开发人员应通过确定审阅者、安排评审以及将设计分发给所有审阅者，来组织设计评审。

涉及设计或受设计影响的任何利益干系人均应参与评审。 通常，这可能包括项目经理、首席开发人员和设计领域的测试人员。 与要评审其代码的开发人员处于同一个团队的所有开发人员也应参与评审。

安排评审会议，并尽早分发设计文档，让每个审阅者有足够时间来阅读它们。 计划评审会议的持续时间，使之与必须评审的技术性细节数量相对应。

验证质量

确保设计可测试。 是否生成不能以合理的方式验证或复核的代码？ 如果是这样，则不能确保代码的质量，必须对该设计进行返工。 检查设计文档中是否存在将导致代码错误的问题。 查找不正确的接口描述、设计错误或命名冲突。 将设计文档与现有的标准（如运算符接口标准、安全标准、生产约束、设计容差或部件标准）进行比较。 创建 Bug 工作项，用于描述在设计文档中找到任何缺陷，并将它们分配给相应的开发人员。

为设计创建评审工作项

创建评审工作项的目的是为了记录设计评审的结果。 评审团队必须决定设计的后续步骤，具体取决于所需更改的数量。 如果不需要进行任何更改，请将工作项的“状态”设置为“已结束”，将“原因”设置为“已接受（按原样）”，并注意可以对该设计开始编码。 如果需要进行次要更改，请将工作项的“状态”设置为“已解决”，将“原因”设置为“已接受但有次要更改”。 这表示在该设计中实现次要更改之后可以开始编码。 如果需要进行主要更改，请将工作项的“状态”设置为“已解决”，将“原因”设置为“已接受但有主要更改”。 必须对设计进行返工并再次进行设计评审，才能对该设计开始编码。

单元测试

单元测试将验证代码单元的正确实现。 编写和执行单元测试能在测试开始前标识 Bug，因此可以帮助降低质量控制的成本。 对于作为实施开发任务或 Bug 修复的一部分而编写的所有代码，开发人员必须为其编写单元测试。 有关更多信息，请参见单元测试代码。

代码分析

代码分析将检查代码是否违反帮助强制实施开发指导原则的一组规则。 代码分析的目标是不出现代码分析冲突或警告。 代码分析可检查代码中是否存在命名约定、库设计、本地化、安全性和性能方面的 200 多个潜在问题。

如果在开发周期的早期开始运行代码分析，就可以最大程度减少开发过程中的冲突和警告。

但是，如果对之前尚未检查过的现有代码运行代码分析，则可能产生许多规则冲突。 如果出现这种情况，你可能希望创建代码必须通过的基础关键规则集，并在解决更关键问题的过程中展开该规则集。 这样一来，团队就可以继续开发能够改善现有基本代码的新功能。

有关详细信息，请参阅使用代码分析工具分析应用程序质量和利用团队项目签入策略提高代码质量。

代码评审过程

首席开发人员应通过明确审阅者、安排代码评审以及将待评审的代码发送给所有审阅者，来组织代码评审。 要准备代码评审，请执行以下步骤：

1. 创建评审工作项，以跟踪评审中作出的决策。 如果不需要进行任何更改，请将工作项的“状态”设置为“已结束”，将“原因”设置为“已接受（按原样）”，并注意可以对该设计开始编码。 如果需要进行次要更改，请将工作项的“状态”设置为“已解决”，将“原因”设置为“已接受但有次要更改”，这表示实现次要更改之后可以开始编码。 如果需要进行主要更改，请将工作项的“状态”设置为“已解决”，将“原因”设置为“已接受但有主要更改”。 必须对设计进行返工并再次进行设计评审，才能对该设计开始编码。

2. 确定将参与代码评审的人员。 通常情况下，至少应有首席开发人员和负责该代码区域的架构师应参与评审。

3. 与审阅者安排评审会议，让每一位审阅者在会议之前有充足的时间来阅读和理解代码。 计划评审会议的持续时间，使之与必须评审的代码数量相对应。

代码评审

代码评审用于确保将新的或更改的代码集成到每日生成之前，该代码满足制定的质量要求。 质量考虑因素有编码标准、与体系结构和设计的一致性、性能、可读性和安全性。 代码审阅还提供来自其他开发人员的有关应如何编写代码的其他见解。

重构代码

在代码评审决定必须进行更改以解决代码质量、性能或体系结构问题后，对代码进行重构。

阅读代码评审工作项备注，以确定将如何重构代码。

以增量方式应用重构，每次进行一个更改。 根据需要更改代码以及对修改后区域的所有引用。

执行单元测试，使该区域在重构后在语义上保持等效。 修复不起作用的任何单元测试。 执行代码分析，并修复任何警告。 如果代码分析导致了代码更改，请再次执行单元测试。

集成更改

最后一步是通过将更改签入到版本控制来集成更改。 在签入代码之前，应执行过程所需的任何测试。 有关如何在签入之前检查代码是否存在问题的详细信息，请参阅利用团队项目签入策略提高代码质量。

如果与更改相关联的工作项是一个方案或服务质量要求，而你不是该方案或要求的所有者，请通知相应所有者已完成更改。 将任务工作项设置为“已解决”，并将其分配给为工作项创建测试用例的测试人员之一。

如果与更改相关联的工作项是一个 Bug，请将该 Bug 工作项设置为“已解决”，并将其分配给其最初创建者。