【IT168 分析评论】

    从1983年——现在的IBM Rational，那时叫做Rational软件——组织成立起之时，我们关于各种软件开发过程和技术的知识一直在增长——通过与客户和合作伙伴的广泛合作。多年来，他们中的很多人加入了我们的组织，并在我们学习哪些方法是有效的，哪些是无效的，以及为什么软件开发始终是一个充满挑战性的工作的过程中，不断塑造着我们对软件开发实践的理解。

    正如我们的客户，合作伙伴和雇员多次听我们说到的那样，软件开发是一项团队工作。理想化地，软件开发活动涉及了良好协调的团队在各种涵盖了整个软件生命周期的规则约束下的工作。但是它不是科学，也不是精确的工程——至少从基于事实的可计量原则的观点看不是。那些假设你可以计划并建立分离的软件部分然后把它们组装起来，就像你造桥或宇宙飞船那样的软件开发活动总是不能按时完成，不能在预算范围内完成，也不能让客户满意。

    因此，在缺乏严密论据的情况下，Rational组织依赖于我们称之为非常好的实践的软件开发技术，这些技术的价值在我们为客户进行的服务中反复得到了证实。它们描述了一个迭代的，递增的，引导开发团队实现结果的过程，而不是为一个软件项目指示一个计划-建立-组装的活动序列。

    十多年以来，我们的六个经检验正确的非常好的实践一直是我们的工具和过程改进的基础。今天，我们有更多公司把软件开发作为核心业务能力来进行研究，于是我们也就看到了这些非常好的实践在更广泛的业务驱动开发的环境下的不断成熟。我们认为现在需要对不断演化的系统的更长生命周期（在这个周期中主要演化的元素是软件）重新阐释我们的非常好的实践了。

    本文阐释了一组原则，我们认为这些原则描述了构建，部署和改进软件密集型系统的工业非常好的实践的特征：

    提高过程的适应性。

    平衡有竞争的涉众的优先级。

    跨团队协作。

    迭代地证明价值。

    提高抽象层次。

    持续关注质量。

    我们将按顺序解释上述这些原则，描述最好地体现了每条原则的行为模式，以及最常见的对软件开发项目造成破坏的“反面典型”。

    提高过程的适应性

    好处：生命周期的效率，开放或诚实的风险沟通

    模式：随着项目生命周期中不确定因素的消减，精确性和形式化程度不断加深。使过程适应于项目团队的规模和分布，适应应用的复杂性，以及灵活性需要。不断改进你的过程。

    反模式：精确地计划或估计，遵循静态计划管理方式。过程越多越好。在整个生命周期中不分轻重地使用过程。

    更多的过程，比如使用更多工件，产生更详细的文档，开发和维护更多需要进行同步的模型，进行更多形式化评论，并不一定有好处。实际上，你需要根据项目需要正确裁减过程的大小。随着项目规模的不断增长，分布范围变得更广，使用更复杂的技术，拥有更多数量的涉众，需要遵循更严格的标准，过程也就需要更多地遵守原则。但是，对于小型的，团队在同一地点工作的，使用广为人知的技术的项目来说，过程应该是较为轻量级的。这些依赖关系如图1所示。

    第二，项目应当使过程适应整个生命周期的各个阶段。在项目的开始，你有很多不确定因素，你希望有更多创造性来开发一种明确业务需求的应用程序。更多的过程往往导致较少的创造性，而不是更多，因此你应当在项目初始，不确定性是最常见因素之时使用较少的过程。另一方面，在项目后期，你往往想要引入更多控制，比如变更控制板，来消除不想要的创造性和相关风险，以免在晚期引入缺陷。这就意味着在项目晚期使用较多过程。

    第三，一个组织应当努力地 不断改进过程。在每次迭代和每个项目最后作一个评估来获得学到的经验，并把这些知识用于改进过程。鼓励所有团队成员不断寻找改进的机会。

    第四，在项目的不确定性和项目计划以及相关估计中取得平衡。这意味着在项目的早期，不确定性很大的时候，计划和相关的估计应集中于全景的计划和估计，而不是着眼于在什么都没有的情况下提供精确到五位的数据。早期开发活动的目标应是找出不确定性来逐渐在计划中提高精确性。

    图1：驱动过程原则的数量因素很多因素，包括项目规模，团队分布，技术复杂度，涉众数量，灵活性需求，以及你在项目生命周期中所处的位置，指出了你需要何种规范程度的过程。

    这一原则的反模式是永远认为更多过程和更详细的前景计划是更好的。强制进行早期估计，并依赖于这些估计。