完成开发任务

为了处理任务、Bug 或另一个工作项而进行代码更改的实现和测试之后，通常要执行若干其他任务。 在团队环境中，通常要让开发团队的一个或多个成员检查您的代码。 还应执行应用程序的最终完全生成。

可能必须通过一组签入测试，然后才能签入代码。 满足所有条件后，可以签入挂起的代码更改，从而解决任何合并冲突。

只有在完成所有必需的步骤后，才算解决了相应的任务、Bug 或其他工作项。

常规任务

任务	支持内容
让同事检查代码：在许多团队开发环境中，必须让一个或多个同事检查代码更改，然后才能签入这些更改。 应考虑让您的某位同事检查任何复杂代码，即使团队未要求此步骤也是如此。 为了便于代码检查，可能要准备一个包含您的更改的搁置集。 其他团队成员可以检查搁置集的内容。 此外，更改还保存在版本控制中，以使您可以处理其他任务，并且在开发环境发生某些意外情况时不会给更改带来风险。	高质量代码签入准则 使用搁置集
执行最终完全生成：通常，作出代码更改时，仅生成正在更改的那些组件。 在团队环境中，应考虑生成整个应用程序，然后再签入更改。 对于某些团队，可以将签入提交到运行连续生成的计算机。	运行和监视生成
运行所有签入测试：对于许多团队，必须运行应用程序测试的一个子集，称为签入测试。 这些测试确认没有破坏直接修改的区域之外应用程序的行为。	定义封闭签入生成以验证更改 连续的生成中断后使用生成签入策略最大限度地减少代码改动
签入所有更改：确认更改之后，必须将这些更改签入版本控制，以将其提供给团队使用。 通过签入更改，还会使这些更改显示在下一个完全产品生成中。 例如，如果挂起的更改在产品周期的当前阶段会引起太多风险，则还可以恢复这些更改。	签入挂起的更改 解决两个文件之间的冲突 在“挂起的更改”窗口中查看工作项详细信息 重写签入策略 撤消挂起的更改
解决任务、Bug 和其他工作项：签入更改后，可以解决相关的任务、Bug 或与更改关联的其他工作项。 通常将包含各种更改的更改集与工作项关联；如果这样做，则 Bug 稍后重现时，将容易找到相关的那组更改。 应该在工作项注释中包含足够的信息，以便其他读者可以理解所做的更改以及更改的原因。 此外，可能要考虑应用一个标签，以便您可以回头参考此版本的源代码。 完成一个工作项后，如果该项所花费的时间明显比预期时间多或少，则您可能必须调整开发计划。	查找 Bug、任务和其他工作项 解决、关闭或重新激活工作项 将工作项与变更集相关联 将签入说明与变更集相关联 使用变更集 使用标签获取文件快照 使用 Microsoft Project 安排任务和分配资源
提供设计反馈：作出代码更改后，可能必须更改应用程序的设计或体系结构的元素。 如果更改设计，则应更新任何体系结构或设计文档（这包括模型）以反映更改。 此外，如果更正了缺陷，则可能要向其他团队成员提供关于缺陷性质的指导，并指示他们如何在将来避免出现此缺陷。	显示现有代码 开发软件设计模型 用户需求建模 在开发过程中验证系统

相关方案

• 执行常规开发任务
  完成开发任务时，已执行了团队的过程或方法所需的所有必要步骤。

• 标识代码更改对测试的影响
  签入更改并解决相关的工作项之前，应运行测试以确认应用程序中受代码更改影响的各个部分。 可以使用 Visual Studio 高级专业版和 Visual Studio 旗舰版的“测试影响分析”功能查看必须运行的测试。

• 使用单元测试验证代码
  应运行现有的测试，并且可能要创作其他测试，以确认应用程序的行为。 如果应用程序使用一个或多个数据库，则可能要生成符合实际的测试数据用于这些测试。

• 使用代码分析工具分析应用程序质量
  可能要分析代码，以检查是否有常见的设计问题可能给应用程序的用户带来问题。

• 管理开发计划和工作
  已签入更改并解决了工作项后，可能要检查当前迭代的开发计划。 可以发现您是否遵守预定时间。 如果任务时间比预期的长，则可以发现哪些团队成员对您的工作有依赖关系，以使您可以讨论延迟的影响。