实现开发任务

开发任务是起源于要求的一小部分开发工作。 实现开发任务会涉及向软件添加适当的新功能。 完成开发任务后，它应已经过单元测试、评审、代码分析并且集成到现有基本代码。

主题内容

估计

设计文档

设计评审

单元测试

代码分析

代码评审过程

重构

集成更改

估计

估计开发任务的成本可帮助控制功能范围和安排开发工作。 在召开迭代计划会议之前，应已完成对所有开发任务的成本估计并已解决任何问题。 如果开发任务的总成本超出一次迭代可承受的成本，则必须推迟或重新分配某个任务。 选择一个开发任务后，开发人员负责估计该任务的成本。

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

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

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

设计文档

设计文档中应包含足够的信息，以向开发人员介绍如何编写代码以实现产品中的要求。

设计文档可以是一个包含规范、要求工作项和其他文档（具体取决于团队过程）的集合。

请考虑使用设计模式、面向对象的设计、结构模型、建模语言、实体关系模型以及专用于您团队的设计的指南中的其他技术。 此外，最好是记下做出这些关键决策的理由。 例如，如果存在对成本、时间表或技术性能的重大影响，请记下依据这些影响做出决策的原因，并将这些信息融入到您的设计中。

在创建必需的设计文档之后，将这些设计文档存储在团队成员可以共享它们的位置。 有关详细信息，请参见管理文档和文档库。

设计评审

使用设计评审可确保新的或修改后的设计在技术方面的准确性、完整性、可测试性和高质量，并确保该设计正确实现要求。 设计评审是一种用于提前确保质量的主要方法，它通过在问题在代码中出现之前确定问题来做到这一点。 设计评审还提供其他开发人员对设计提出的其他观点。

负责创建设计的开发人员应通过以下方式来组织设计评审：确定审阅者、计划评审并将设计分发给所有审阅者。

设计所牵涉或影响的任何利益干系人都应参与评审。 通常可能包括项目经理、开发人员主管和设计区域的测试人员。 与正在评审其代码的开发人员同一个团队的所有开发人员也应参与评审。

安排评审会议并尽早分发设计文档，使每个审阅者有充足的时间来阅读这些文档。 计划评审会议的时间长度，使其与必须评审的技术细节的数量相对应。

验证质量

确保设计是可测试的。 是否生成无法按合理方式验证或检验的代码？ 如果是这样，您将无法确保代码的质量，并且必须改编设计。 检查设计文档中是否存在将导致代码错误的问题。 查找不正确的接口描述、设计错误或命名冲突。 根据现有标准（如运算符接口标准、安全标准、生产约束、设计公差或部件标准）来比较设计文档。 创建描述在设计文档中找到的任何缺陷的 Bug 工作项，并将这些工作项分配给负责的开发人员。

为设计创建评审工作项

可创建评审工作项来记录设计评审的结果。 评审团队必须决定设计的后续步骤，这取决于必需的更改的数量。 如果没有必需的更改，请将工作项的“状态”设置为“已关闭”，将“原因”设置为“已接受(按原样)”，并请注意可以在设计上启动编码。 如果次要更改是必需的，请将工作项的“状态”设置为“已解决”，并将“原因”设置为“已接受但有次要更改”。 这将指示编码可以在设计中实现次要更改之后启动。 如果主要更改是必需的，请将工作项的“状态”设置为“已解决”，并将“原因”设置为“已接受但有主要更改”。 必须改编设计并且必须执行另一次设计评审，然后编码才可以在设计上启动。

单元测试

单元测试可验证代码单元的实现是否正确。 编写并执行单元测试可在测试启动前标识 Bug，从而有助于降低质量控制的成本。 开发人员必须为将作为实现开发任务或 Bug 修复部分的所有代码编写单元测试。 有关详细信息，请参阅使用单元测试验证代码。

代码分析

代码分析将根据一组用于帮助强制实施开发准则的规则来检查代码。 代码分析的目的是为了避免代码分析冲突或警告。 代码分析可检查您的代码是否存在命名约定、库设计、本地化、安全性和性能方面的 200 多个可能的问题。

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

但是，如果对之前尚未检查的现有代码运行代码分析，则可能会出现多个规则冲突。 如果是这种情况，您可能需要创建一个代码必须通过的基准关键规则集，然后在解决更关键的问题的过程中扩展该规则集。 通过这种方式，团队可以在改进其现有基本代码的同时，扩展新的功能。

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

代码评审过程

开发人员主管应通过以下方式来组织代码评审：确定审阅者、安排代码评审并向所有审阅者发送要评审的代码。 若要做好代码评审的准备工作，请采用下列步骤：

1. 创建一个评审工作项来跟踪评审中做出的决定。 如果没有必需的更改，请将工作项的“状态”设置为“已关闭”，将“原因”设置为“已接受(按原样)”，并请注意可以在设计上启动编码。 如果次要更改是必需的，请将工作项的“状态”设置为“已解决”，并将“原因”设置为“已接受但有次要更改”，这指示编码可以在实现次要更改之后启动。 如果主要更改是必需的，请将工作项的“状态”设置为“已解决”，并将“原因”设置为“已接受但有主要更改”。 必须改编设计并且必须执行另一次设计评审，然后编码才可以在设计上启动。

2. 确定代码评审的参与者。 通常，至少开发人员主管和负责代码区域的架构师要参与评审。

3. 安排审阅者参与的评审会议，使每个审阅者在会议召开之前有充足的时间来阅读和理解代码。 计划评审会议的时间长度，使其与必须评审的代码数量相对应。

代码评审

使用代码评审可确保在将新的或更改后的代码集成到每日生成之前，这些代码能满足制定的质量要求。 质量注意事项是符合体系结构和设计、性能、可读性以及安全性的编码标准。 代码评审还提供其他开发人员对代码的编写方式提出的其他观点。

重构代码

在代码评审已确定必须进行相应更改以满足代码质量、性能或体系结构需求后，将重构代码。

阅读代码评审工作项说明以确定重构代码的方式。

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

执行单元测试，使区域在重构后在语义上保持等效。 修复无法运行的所有单元测试。 执行代码分析并修复任何警告。 如果代码分析导致代码被更改，请再次执行单元测试。

集成更改

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

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

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