平衡有竞争的涉众优先级

    好处：使应用程序与业务和用户需求连接起来，减小客户开发，使业务价值最优

    模式：定义并理解业务过程和用户需求；区分项目，需求与软件能力的优先次序；理解你可以使用哪些资产；并平衡用户需求与资产复用。

    反模式：在项目工作开始前实现精确和详细的需求。需求是达到客户解决方案的焦点。

    这一原则阐述了平衡业务和涉众需要的重要性，两者往往是冲突的。作为例子，多数涉众希望应用程序可以完全实现他们想要的功能，同时最小化应用程序的开发成本和时间表。但是这些优先权经常是冲突的。例如，如果你使用一个包装好的应用程序，你可能能够更快，并以更低的价格发布方案，但是你不得不牺牲很多需求。另一方面，如果一个公司决定从底层构建一个应用程序，它可能可以实现所有需求，但是预算和项目完成需要的时间将同时超过它们可行的极限。

    我们要做的不是叫我们的程序设计团队攻克需求清单中每一个元素；我们要做的第一件事是理解并排列业务和涉众需要的优先次序。这意味着掌握业务过程并把它们同项目和软件功能联系起来，这使得我们能够有效地排列出正确的项目和正确的需求，并随着我们对应用程序和涉众需要理解的深入修改我们的优先次序。优先级的排列还意味着我们需要在项目中加入客户或客户代表，来保证我们理解了他们的需要。

    第二，我们需要围绕涉众需要开展开发活动。比如，通过利用用例开发和以用户为中心的设计，我们可以接受这样一个事实：随着业务的变化，以及我们对哪些功能对业务和终端用户更为重要的更好理解，在项目的持续过程中涉众的需要会发生演化。我们的开发过程需要适应这些变化。

    第三，我们需要理解哪些资产是可用的，然后平衡资产复用和涉众需要。资产的例子包括继承应用程序，服务，可复用组件，和模式。在很多情况下资产的复用导致更低的项目成本；而对经过验证的资产，对它们的复用通常意味着新应用程序的更高质量。缺点是，在很多情况下，你需要牺牲资产复用而精确地实现终端用户的需要。对一个具体功能，复用一个组件可以降低开发成本达80%，但是它可能只能实现75%的需求。因此，有效的复用需要你不断地平衡资产复用和发展中的涉众需要。 

 

    图2：平衡需求处理组件的使用。使用一个组件可以从根本上降低成本和发布一组特定功能的时间。在很多情况下它可能还需要你牺牲一些功能或技术需求，比如平台支持，性能，或覆盖区（应用程序的大小）。

    遵循这一原则的反模式是在项目开始详细记录精确的需求，强制涉众接受需求，然后对需求的变更进行协商，而需求的每一点变更都将增加项目的成本或持续时间。由于你一开始就锁定了需求，你降低了使用已有资产的能力，于是迫使你进行定制化的开发。另一个反模式是构建一个只能满足最强势的涉众的需求的系统。

    跨团队协作

    好处：团队生产力，更好地结合商业需求与软件系统的开发和运作。

    模式：鼓励人们拿出最好的表现。分析师，开发人员和测试员的跨职能合作。在集成化的环境中管理演化中的工件和任务来加强协作和进度/质量洞察力。确保业务，开发和运作团队作为一个集成的整体高效地工作。

    反模式：培养英雄个体并为他们配备强大的工具。

    软件是由有才能，有动力，并紧密合作的人制造的。很多复杂的系统需要一定数量的有不同技能的涉众的活动，而最大的项目常常跨越地理和时间的界限，进一步增加了开发过程的复杂度。这就是人的问题和协作——称之为软件开发的“软”元素——成为了灵活开发的主要焦点的原因。1 这一原则指出了很多问题，包括：你如何激励人们，使他们的表现最好？在一个在同一地点的软件团队内，在一个分布式团队内，在共同参与一个业务活动，软件开发，和IT运作的不同团队之间，你如何与人合作？

    有效合作的第一步是激励团队中个人的最好表现。自我管理团队的概念2 在灵活性目标中正在受到越来越多的关注；它是基于使一个团队专注于他们要发布的产品，然后为他们提供决定所有直接影响结果的问题的权力的。当人们感到他们真正要对最终产品负责的时候，他们被激励去很好地完成工作。正如灵活性宣言陈述的：“在被激励的个体周围建立项目。给他们需要的环境和支持，并相信他们将会完成任务。”

    第二步是鼓励跨职能的合作。很多年前我们就指出，“软件开发是一项团队工作。”一个迭代的方法增加了作为一个团队紧密工作的需要。我们经常需要打破建立于分析师，开发者和测试者之间的阻隔，并拓宽成员的角色职责以保证迅速变化的环境下的有效合作。每一个成员需要理解项目的任务和远景。

    随着我们的团队的增长，我们需要提供有效的合作环境。这些环境方便了度量收集和状态报告，并使围绕配置管理的构建管理和日志自动化。这一有效性使得更少的会议成为可能，这样团队成员可以花更多时间在生产和创造性活动上。这些环境还应通过简化交流，沟通不同团队成员在时间和地域上的阻隔来实现更有效的合作。这种环境的例子包括了从共享项目房间到网络或基于网络的方案，比如Wikis或集成开发环境和配置及变更管理环境。

    在这个原则下我们的最终目标是集成化的跨业务，软件和运作团队间的合作。随着软件在我们如何运作我们的业务中变得越来越重要，我们需要与1）决定如何运作我们现有的和将来的业务的团队，2）开发支持软件系统的团队，以及3）运作我们的IT业务的团队进行紧密的合作。 

 

    图3：跨业务、开发和运作团队协作。随着软件在我们如何运作我们的业务中变得越来越重要，我们需要与负责如何运行业务，如何开发应用程序，以及如何运行应用程序的周围团队更紧密地合作。在多数公司中，这三个小组的交流很糟糕。

    这一原则的反模式是培养英雄式的开发者，他们愿意超长时间工作，包括周末。一个相关的反模式是培养高度专业的人，并为他们的工作配备有强大工具，他们与其它团队成员的合作很有限，而且不同工具间的集成也很有限。这里的假设是如果每个人都做好他自己的工作，最终结果就会是好的。