引言：良好的开发误入歧途

　　软件开发项目是以成为泛滥、错过的最终期限，和范围的不断变更而出了名的。为什么是这样呢？为什么当您着手开发一个产品时 —— 操作系统、设备驱动程序、内部应用程序，或甚至是 Web 页面 —— 您似乎不能让程序设计人员准时、按预算交付，并达到令您超群的质量等级？

　　 当然，不是所有的开发项目都会遇到这些问题，那么什么使它们不同呢？什么使它们成功呢？在许多情况下，这些项目实现了其目标，因为有了适当的 IT 治理。治理帮助您领导，特别是控制开发项目的进展，并让它们走上正轨。治理不必须是繁重的，也不是整体的。虽然对于开发项目的适当治理不存在“魔术的”解决方案，但是您可以实现一组可以帮助减缓最公共的问题的重要过程。

　　确定您的治理观点

　　治理对所有人来说意谓的不同。首先，治理不意味着刚性，或者，如果是，也只是因为它应用于过程的法规遵循。太多的组织对开发使用不假思索的过程。如果它们使用内部的过程，那么它们会过于严格地或不足地信守。太多，意味着每个人都信守过程的字面意思，经常专注于错误的方面，并且没有关注令过程有效的关键因素。太少，不能指导确保在正确的时间进行过程的正确方面。

　　不，有效的治理意味着进行正确的过程，并且如果您需要，加入正确的工具来支持该过程。但记住，这里的重点是过程本身。必须在正确的时间关注正确的活动，并且依赖一个主要的关键因素：所有的有利害关系的群体之间的沟通。太多的过程失败了，因为在所有的有利害关系的群体之间不存在沟通。

　　理想的开发过程

　　那么，什么组成了理想的开发过程呢？它应该是以生命周期的形式，并且至少包含以下阶段：

　　项目定义

　　准备

　　开发

　　测试

　　代码成熟化

　　部署

　　支持

　　退役

　　内容导航

　　项目定义

　　此阶段可能是过程中最重要的阶段，因为它确定项目将如何演化。此阶段的关键活动是适当地定义需求，并且确定项目范围和预算。在此，会谈的技能是很重要的，因为是对项目涉众的需求的正式获取和重申。

　　将整个项目的范围设定的尽可能小：采用巨大的开发计划只会导致失败，因为有太多可变的部分。令项目简单，您就更可能成功。随着面向服务的体系结构（service-oriented architectures，SOAs）及其可复用的组件的出现，要使项目范围更小比过去容易得多。

　　准备

　　当您定义了组成项目的所有关键要素之后，您可以转移到项目的准备上来。在此阶段，您将精制预算，培养将要参与项目的团队，并且分配他们的职责。确保在所有团队成员之间建立沟通渠道。

　　有太多的组织错误地在此阶段只纳入了开发团队成员，这造成了产品没有准备好向生产环境的交付，并且缺乏它们运行所需的支持、培训，和任何其他的非开发的机制。因为要确保产品的高质量，需要许多团队，此时每个团队都应该派出代表。沟通机制还应该包括对项目涉众的经常反馈，从而确保他们随着开发的进行可以完全地察觉到不可预料的挑战和成功。

　　开发

　　在此阶段，您实际地对产品编码。现今，许多组织在使用地理上分散的开发团队，这导致了范围的蠕变，除非建立了适当的沟通渠道。解决这种分布的开发模型的最佳方法是确保您的开发工具支持适当的源代码管理，为您所编制的代码提供单一的存储库，并且为在编码的人提供审计跟踪。此外，您可以包含带有检查点的，可以帮助指示整个项目进展的频繁的代码构建。

　　测试

　　在您开始发布核心代码组件之后开始测试。需要许多级别的测试：单元、功能、集成、分段、试验，和最后的投入生产。测试涉及不同的团队成员，从开发人员本身到提供最终产品的验收的最终用户。

　　促进该过程的最佳方法之一是确保技术和开发团队之间的有力对话。许多项目在此阶段都会失败，因为开发人员发现他们需要根据他们不知道的环境规范来编码。一个杰出的实例是单元测试和集成测试之间的差别。在单元测试中，开发人员经常在他们自己的计算机上进行测试，在其中他们是作为拥有非常高特权的用户，并且在其中实现很少的标准。当他们达到集成层之后，代码不再有效，因为该层开始提供产品中建立的相同的标准。因此在非常早的阶段向开发人员提供环境规范的完整列表是至关重要的。理想情况下，相同的标准应该用于测试和开发的所有层次上，确保在产品通过各种测试周期中不出现任何惊奇。实现这一点的最佳方法是对开发、生产工作站，和服务器使用相同的构建过程。

　　代码成熟化

　　成熟化是将新产品的功能的所有方面都集成到一个相干的组件中。如果在测试周期中实现了适当的沟通，那么此阶段大部分是敷衍的，并且专注于文档的小部分修正、安装说明、支持材料，和培训工具。它还专注于确保代码的稳定并且能够提供期望从产品中得到的可靠性等级。在此阶段版本化对于确保所有的团队成员都了解他们应该处理的产品的等级是很重要的。

　　部署

　　如果在前面两个阶段中使用了适当的分段过程，那么部署仅仅就是重复同样的过程，但是在更大的范围上。应该通过试验项目提供对所有部署机制的反馈。然后您可以做出调整，从而确保产品部署可以尽可能平稳地进行。

　　支持

　　既然产品已经出品，那么它就进入了支持和维护阶段。依赖于源自产品的商业价值，该阶段会比其他任何阶段都持续久得多。随着发现一些未预料的小故障，该阶段会包含一些补丁的交付。这些需求常常起因于产品的使用：现在用户发现他们的需求已经变更，因为产品现在支持他们之前不可用的过程。

　　退役

　　在商业过程之后，产品支持变更（因为现今的快节奏的商业），它准备要退役或替换。这可以通过一些方式实现，准备并部署全然不同的产品或者仅仅对现有版本进行升级。在一些情况下，整个过程都过时了，并且产品必须完全地退出生产。如果在开始适当地确定了项目的范围，那么将计划并安排这样的退役。

　　该过程如图 图 1 所示。对于大多数开发团队来说，该过程会令人惊奇，因为他们倾向于认为，开发是以交付生产为结尾的。然而，每个产品都拥有一个直到从生产中退役才结束的生命周期。生命周期的完整的观点用来在准备和交付产品时增加产品的价值和质量。

　　图 1. 开发产品生命周期 内容导航

　　指望您的同级

　　治理是通过确保对每个开发项目的这一过程的法规遵循来应用的。企业信息技术架构师（Enterprise Information Technology Architect，EITA）是确保在所有这样的项目中实现法规遵循的理想角色。事实上，这应该是 EITA 的主要职责之一，其他还有概述所有的有利害关系的团队成员之间的沟通过程，以及所有需要的架构的文档编制。

　　确保适当地准备并设计代码，从而达到预期目标的另一种方法是在整个生命周期中执行常规的同级评审。同级评审可以发生在过程的每个层次上，并且应该不仅包括同事开发人员，还有用户、项目涉众、技术和支持员工，以及 EITA。该过程只能帮助确保产品的整体质量，因为它帮助在开发过程早期找到缺陷，使开发团队可以提供立即的修正。经常执行同级评审，并且确保您的开发过程为对适当的团队成员的反馈提供合适的机制。

　　经验是您错误的总和！

　　如您所知，不存在对于成本泛滥、范围蠕变，或其他开发项目失败的魔术的解决方案，但过程 —— 特别是专注于正确的项目因素的过程 —— 可以大大减缓这些问题。您可以在大部分项目中见到。

　　最近，我们的团队正忙于新应用程序的交付，以及在它投入生产之前在一系列不同环境中的测试。随着测试的进展，我们发现应用程序操作的许多问题。一个团队成员 —— 团队的办公抄写员 —— 将我们让应用程序适当工作所执行的所有纠正步骤放在一封电子邮件消息中。团队成员将该消息发送给整个团队，其中包括负责准备下一个版本的开发人员。在下一次重新设置之前过了两个星期。我们再一次遇到了同样的操作问题，并且我们不得不深入发掘什么错了。

　　EITA 建议我们停止在最近设置之后发送的电子邮件消息，并且你瞧，每个决定都写在消息中，但它被切断了，负责做这些修改的开发人员已经将该消息收起来，并且忽略了它，因为它只来自于抄写员，并且只不过是个办公的团队成员。总之，一个本该花费 10 分钟的设置会议用去了五个多小时，并且涉及了许多团队成员。该问题没有实际地分辨出来，直到 EITA 回忆起我们正在看的许多问题已经写在文档中了。

　　您完成的每个项目都增加了知识和专家经验，它们可以帮助您更好地了解整个过程。经验是您错误的总和！学会依靠您的队友 —— 他们所有人。治理不过是确保您在开发项目中使用合适的行动过程，并且您始终贯彻它们。常常，仅仅是期望的调整——不仅有您的项目涉众的期望，还有您的开发人员和每个其他的团队成员的期望。