本节书摘来自华章出版社《敏捷可执行需求说明 Scrum提炼及实现技术》一 书中的第1章，第1.1节，作者：（美）Mario Cardinal，更多章节内容可以访问云栖社区“华章计算机”公众号查看。

第1章

解决正确的问题
敏捷是一组鼓励快速、灵活地响应变更的软件开发框架。它们基于迭代开发实践，需求和解决方案都在跟客户合作过程中逐渐演进并完善。2001年发布的“敏捷软件开发宣言”[1]引入了敏捷这个词。
Scrum[2]现在已经成为最著名且使用最广泛的敏捷框架。Ken Schwaber和Jeff Sutherland[3]设计的Scrum框架，由角色、事件、工件以及将它们整合在一起的一系列规则组成。Scrum使研发团队通过频繁地检查和调整，并不断优化产出成果，最终构建复杂的产品。这个术语来自橄榄球中的scrum（或者scrummage），即用来重新启动强制暂停后的比赛。在2011年发起的年度“敏捷研发现状”调查中，选择使用Scrum或Scrum的变种形式的人数继续在被使用到的敏捷框架中占据三分之二以上的比例[4]。因为Scrum被如此广泛地采用，所以本书也仅关注这种框架形式。对于采用其他敏捷框架的情况，本书所介绍的经验教训因其通用性也足够使用。
将“敏捷”与“需求说明书”两个词绑在一起看起来有点怪异。而特别为这个话题撰写一本书看起来更加怪异。对很多人来说，需求说明书只与“传统”的以文档为中心的工程实践相匹配。在敏捷背景下，可运行的软件是度量开发进度的基本标准，人们很容易认为需求说明书将不再有存在的必要。然而，需求说明书仍然是需要的——甚至比以往任何时候都更需要。区别在于产出物有本质上的不同。需求说明不仅简短，而且也需要在计算机上以一种固定的格式发布成可执行的文档。——因此得名为可执行的需求说明书。
本书的目标旨在解决众多软件开发团队不断遇到的问题：他们无法生产“正确”的软件。这是一个很严重的问题，甚至令你震惊。不管怎样，仍然有大量的软件系统成功地解决了“正确”的问题。其中很多这样的系统都是由实施Scrum框架的团队生产的。我不仅从这些团队那里学习到了关于敏捷的技能，而且也是他们中的一员。如果你也属于这样杰出的团队，你就会意识到本书中介绍的这些纲要性的实践正是你所熟知的。
不幸的是，仍然存在着大量的过于臃肿和复杂的软件系统。即使研发团队写的代码都是对的，结果往往是他们没有有效地解决实际的问题。客户想要的或需要的功能跟产品实际能够提供的功能有着巨大的差距。一个经常被引用的Standish Group [5]的统计结果显示，在一个典型的系统里，64%的功能很少被用到或几乎从不被使用。图1-1是根据Standish Group的准确数据画的饼图。

从饼图上来看，非常有意思的是有20%的功能一直或者经常被用到。这个结果更重要的是吻合了80–20原则，同时也符合帕累托原则。帕累托原则说的是在很多事件中，几乎80%的成果（产出物）都来自20%的付出（投入）。比如说，在生意场合，通常几乎80%的销售业绩都来自20%的客户。在软件开发行业，如果你能正确地选择最重要的20%的需求来实现，就能满足80%的业务需求了。随着对可用性和可靠性的期望值不断增长，要构建符合要求的软件是很困难的。因此专注于那20%的功能就显得很重要。这样你就可以拥有必要的资源来实现符合预期的技术解决方案。
本章将介绍为了解决正确的问题，必须首先学会从解决方案中甄别出需求。紧接着，必须在描述需求时识别出不确定性的影响。这是因为描述我们需要构建的是什么，同时还要拥抱变化是很有挑战的。最后，我们将得出结论，当前从传统工程中继承来的实践根本满足不了这种需要。当需求难以把握，并且持续变动时，你必须以一种非传统的方式来应对不确定性。Scrum框架下的可执行需求说明被证明行之有效。本书的目标就是要分享这一经验。