介绍

系统很少是所有人的一切。经常有太多的浪费，导致了臃肿的系统

为了成功，利益相关人和项目参与者必须致力于对下面三个因素有清晰的理解和认同：

• 待解决的问题
• 开发团队的约束（成本、进度、资源、规范，等等）
• 解决方案的角色

对所有项目参与者来说，创建一个解决方案以最大化交付给利益相关人的价值并满足约束是一个挑战。需要在关键的成本收益和期望的特性之间，以及定义了系统架构的设计决策之间进行权衡。

发现平衡点是具有挑战性的、难以捉摸的、持续的，因为平衡点是动态的。随着系统的演进，利益相关人需求变更、新的机会出现、风险被解决、新的风险出现，开发团队逐渐发现真实的系统。变更发生在整个开发生命周期中，利益相关人和团队成员必须随着系统的演进重新评估承诺、调整预期以及计划。

实践

了解你的听众

如果你不知道谁是你的利益相关人以及他们的真实需求，你无法做出有效的权衡。

去了解你的利益相关人。最好是，和他们一起工作，从而使你知道他们的需要。从识别所有利益相关人开始，而后在他们和开发团队之间保持开放和频繁的沟通与协作。

从解决方案中分离问题

我们经常性地在没有理解问题的时候就一头扎进了解决方案。毕竟，我们被教导如何解决问题，而不是如何定义问题，以至于解决问题看起来更容易。然后，这种对问题理解的限制、强加的人为约束，使得很难做出权衡，即使知道需要权衡什么。

确保在你定义解决方案（系统必须做什么）之前理解了那些问题。依靠清晰的从解决方案中分离问题（客户需要什么），使得更容易维护适当的焦点，也更容易调整解决问题的不同方法。

创建领域的共享理解

领域专家经常缺少技术经验；开发者、架构师以及测试人员则通常缺少领域经验；而评审员和其他利益相关人经常缺少时间去花费在项目和学习问题域上。因此，人们对问题域有不一致和贫乏的理解，这导致了沟通的问题，以及向利益相关人交付的价值少得可怜。

增强并分享所有参与者对领域的理解。一份简明和共享的问题域的理解将增强沟通和项目的有效性。从在愿景（Vision）文档中定义问题开始。随着你的理解的增加，捕获关键的领域概念和术语记录在术语表中，从而确保一份一致的、共享的领域语言。

使用场景和用例捕获需求

许多公司仍旧使用说明性的语句列表来文档化需求，有时这称为“应该XX”。这份列表对于利益相关人通常难以理解，因为这需要最终用户通读并将这份列表翻译为一个可视化的结果，来理解需求是如何和系统进行交互的。

使用场景和用例捕获功能需求对利益相关人来说更容易理解。非功能性需求，例如性能、稳定性、或者可用性需求，可以使用传统方式在系统需求文档中描述。

建立和维护被认可的优先级

当在决定接下来开发什么时做出了不好的决策，会导致工作量浪费、交付了永远不会使用的功能、或者太迟识别项目中的问题（导致延期甚至项目失败）。

在产品演进期间，定期和利益相关人一起对将实现的需求进行优先级排序。在交付价值和降低风险之间做出选择，并同时构建可以演进的系统。

做出取舍以最大化价值 

成本收益权衡不能独立于架构。需求决定了利益相关人获得的系统收益，而架构决定了成本。收益的成本可能影响利益相关人对收益价值的感觉。

利益相关人和团队成员共同工作排定需求优先级，并开发候选架构以实现那些方案。使用候选架构对收益成本进行评估。在判断架构可行性时，是在一个较高的层次上考虑候选方案。不同的架构视图可能导致对成本、收益评估的不同结果。选择最低成本的候选架构进行未来的开发。

管理范围

变更是不可避免的。虽然变更带来了提升利益相关人价值的机会，但是无约束的变更将导致一个臃肿、有缺陷的系统以及未能满足利益人需要。

管理变更同时维护利益相关人的承认。现代过程总是管理变更，不断的调整以适应环境和利益相关人需求、评估变更的影响、做出权衡、以及重新排定工作优先级。在开发生命周期内，利益相关人和开发者的期望必须是现实和均衡的。

知道何时停止

过度设计一个系统不仅浪费资源，还会导致一个过于复杂的系统。

当已获得期望的质量时，停止系统开发。记住“质量是符合需求” [CRO79]。这是此实践的关闭场景。从解决方案中分离问题，保证方案确实解决了问题。在关键的需求被实现和验证后，系统已经做好了被利益相关人接受的准备。