OpenUP核心原则一：平衡，在竞争优先级以及最大化干系人利益之间建立平衡

在竞争优先级以及最大化干系人利益之间建立平衡

      允许项目成员和干系人共同开发一个解决方案，在考虑到项目的各种约束的前提下，让干系人的利益达到最大化。

简介

      软件系统并非为所有的用户提供所有的功能。如果以提供全面的功能为目的必然造成浪费，并且导致系统臃肿庞大。

为了能够开发出成功的系统，项目干系人和项目开发团队成员必须对以下三个因素有清晰的理解并且达成一致的认识：

• 解决什么问题
• 开发团队的约束（成本、进度、资源、规章制度等等）
• 解决方案的约束

      开发团队最大的挑战是创建一个解决方案，这个解决方案能够交付给项目干系人最大的业务价值并且遵从一定的约束。

      所谓平衡，即在所需开发的系统特性和定义了系统架构的后续设计决议之间权衡成本和收益，找到平衡点。

      发现平衡点充满挑战，持续进行，并且不那么简单，因为平衡点是动态变化的。在系统不断演进的过程中，干系人的需求也在变化，新的机会不断出现，风险也逐步被解决，开发团队同时也挖掘出了系统新的问题和需求。在整个开发周期中，变更会持续出现。项目干系人和团队成员需要准备好重新评估所委托的开发任务，重新调整期望值，在系统演进的过程中逐步调整计划。

实践

了解你的“观众”

      如果你不知道项目干系人是哪些人以及他们真正想要什么，你将无法知道如何做出有效的权衡。
      了解你所处项目的项目干系人。最好能够和他们紧密工作在一起确保你了解他们的需求。从识别出所有的干系人开始，并且维持一种机制，让干系人和项目开发团队能够以开放的心态频繁沟通和协作。

从解决方案中分离出问题

      通常情况下，我们在没有理解问题时就热衷于提出解决方案。毕竟，我们的教育体制教育我们如何去解决问题，而不是如何定义问题，因为解决问题更简单一些。这种做法会限制我们对问题的理解，强加人为约束，并且让权衡上述的平衡变得困难，甚至无法了解要需要权衡的因素是哪些。

创建一份能够达成一致理解的领域知识

      领域专家缺少技术知识；开发人员、架构师和测试人员常常却缺少领域知识；而对项目最终进行审核的领导和其他项目干系人常常缺少时间参与项目，也缺少时间了解项目业务领域的具体问题是什么。因此，大家对业务领域问题的理解往往是不一致的，甚至是理解深度不够，这将导致出现沟通问题，并且还将导致交付给干系人的软件没什么价值。
      我们需要增强并且让大家对业务领域知识达成一致的理解。一份对业务领域准确描述并且理解一致的问题描述文件可以加强沟通有效性和项目高效性。我们可以从愿景文档中开始定义问题。当理解程度加深后，我们需要捕获核心领域概念并且在项目词汇表中定义这些术语，以保证领域语言的使用是一致的。

使用场景和用例捕获需求

      很多公司依然用陈述语句的列表描述需求，这些需求有时被称为“应该提供xx功能”。这份列表对于干系人而言通常难以理解，因为这些需求需要最终用户通读文档，并且把文字转化为这些需求如何和系统交互的可视化景象才能更好的理解。
     我们可以使用场景和用例捕获功能性需求，采用这种方式干系人更容易理解。非功能性需求，例如性能，稳定性，或可用性需求，同样很重要，我们可以使用传统的技术记录为系统范围的需求文档（system-wide requirement）。

确立优先级，并且维持一致

        对于即将开发的内容没有进行良好决策将导致事倍功半，同时还会交付从未被用到的功能，甚至是在项目后期才识别出存在的业务问题。（这将导致项目延期甚至是项目失败。）
        在产品开发过程中和干系人一起设置需求开发的优先级。在构建不断演进系统的同时，做出可以交付价值并且降低风险的选择。

权衡各种因素确保利益最大化

      进行成本收益权衡时，不能脱离架构进行。需求确定了系统给干系人带来的利益，而架构则决定了实现系统苏需的成本。每一项收益的成本将影响干系人对收益价值的感知。
和干系人以及团队成员一起设置需求的优先级并且开发出实现解决方案的候选架构。使用候选架构评估收益的成本。在决定架构可行性时，候选解决方案可以被视为一种高层面的考虑方案。不同的架构观点将导致对不同的成本收益比较的评估。成本更低的候选架构将作为后续开发的最佳选择。

管理需求范围

      需求变更无法避免。虽然变更的出现也呈现出一种为干系人增强利益的机会，但是没有约束的变更将让系统臃肿不堪，而且充满缺陷，同时还无法满足干系人的需求。
与干系人一起维持最初达成一致性的同时管理变更。现代流程都包含管理变更的内容，持续的进行调整以适应环境变化和干系人需求的变更，评估变更的影响，进行权衡并且重新设定优先级。干系人和开发人员的预期目标必须是切实可行的，而且在整个开发生命周期中保持一致。

清楚何时停止

     系统的过度设计不仅仅浪费资源，而且导致系统过于复杂。
     在系统达到质量目标后就应该停止下来。请记住“质量应该和需求保持一致”。我们应该遵循这个原则对开发实践有个闭环。从解决方案中分离出问题，确保解决方案确实解决了需要解决的问题。在关键需求实现和验证后，系统也就为干系人的验收做好了准备。

 

 

更多：《如何在团队中学习和应用OpenUP》