通过敏捷流程，许多团队都能非常好的交付运行中的软件，但是所交付的软件却不能够满足业务需求。应用程序需求专家Ellen Gottesdiener和Mary Gorman说，通常，交付周期非常紧迫的情况下，开发团队在没有周全地考虑业务需求和用户需求就会开始进行编码。为了发现敏捷流程中的需求，他们说出了这些技术和工具的价值。

Gottesdiener和Gorman是位于马赛诸塞州萨德伯里EBG咨询公司的主要负责人，也是《Discover to Deliver》一书的作者。

Gottesdiener说：“为了追求方便，许多敏捷项目直接跳过项目的分析环节。他们为此支付了一大笔钱。一旦这些软件投入使用，无论是下一次是迭代还是发布，他们都会意识到有好多企业的需求与问题是他们回答不了的。”

通向无名之地的一种途径

简单的需求分析方法通常会引起“旅游事件”，意思就是在开发阶段开发人员会发现新的用户需求。因为，在迭代或者发布期间，他们无法满足那些需求，只能扩展敏捷项目流程。

如果团队花过多时间计划，并且无法了解他们所要交付的产品需求，那么还会发生旅游事件，会严重影响项目开发。Gottesdiener说：“他们经常积压大量的工作或者问题较多的工作。”

情况变得越来越糟糕

分析不充分也会导致评估不足。Gottesdiener说，评估虽然不是敏捷开发流程中的一部分，但是一般情况下，敏捷团队的评估都会走样。进入一次迭代后，又进入了建立阶段，然后发现忘记了一次迭代，或者忘记了考虑了业务规程的细节。在修改订单以发现个人所需求的宽度和深度时，团队之间的合作不够充分。她解释说：“因此，他们没有任何进展也没有理解他们需要做多少工作，或者如何满足服务水平协议。”

就需求本身而言，项目团队已经构建了产品某些特定方面，为了能使产品的其他方面正常运行。数据记录已经记载下来这些特殊的细节。

Gorman认为，没有预测到依赖性是另外一个项目问题。就需求本身而言，项目团队已经构建了产品某些特定方面，为了能使产品的其他方面正常运行。数据记录已经记载下来这些特殊的细节；开发人员必须建立数据，在更新或者执行其他任务之前必须保证这些数据是可以获得的。

Gorman说：“对实际业务需求和产品需求没有共同的理解，他们就没有办法一起做可行性评估。”

完成与优秀

作者提到的“结构性对话”流程可以提高发现、共同理解、评估和建立满足业务、用户需求的应用程序的效率。

在结构性对话中，开发团队探索、评估和确认业务和技术需求。

Gorman说：“结构性对话属于元构架，你可以将其用于任何一个项目计划阶段中。”探索、评估和确认产品需求的过程是不间断的、经过反复实践的。其中包括有计划的和自发的，而所开展的即时会话包括团队中所有成员，也包括业务、用户和技术的合作伙伴们。

在项目的探索阶段，团队需要考虑产品维度的选择，包括用户需求、界面、数据、控制、环境、质量和其他更多方面。探索期，团队要研究和评估竞争对手的市场和产品标准、现有和潜在市场和技术的趋势。组织对产品和技术团队的能力有一定的期望，而如上信息对于评估团队是否达期望非常重要。

随着项目进度的发展，探索程度也有所变化。Gottesdiener说，起初是“重大新闻”这个特色，“你将要开始用无数的点来描绘画面的轮廓。”最终，这些新闻成为小小的迭代，而几天之后可以交付软件。

Gorman说，结构性会话的第二个部分是评估阶段，敏捷团队根据风险和未来交付顺序来权衡软件选择。估计是评价关键部分。此时系统就要对软件的规模、复杂性和影响构建产品的其他属性进行测量。其中还要考虑产品生命周期、用户体验和业务需求。需要指出的是，产品选择的评估价值对于建立功能性交付订单来说是至关重要的。

只有当团队成员所选择的软件能够正常运行并且能满足业务需求时，结构性会话才可以结束。

交付的每个阶段对软件进行检查是结构性会话流程的第三步。团队必须不断评估和核实应用程序，保证应程序可以满足业务需求。只有当团队成员所选择的软件能够正常运行并且能满足业务需求时，结构性会话才可以结束。

Gottesdiener说：“计划中，团队必须界定‘完成’与‘优秀’的评判标准。”她曾经参与过一个项目，该项目中只有首席开发人员有编码的基础。项目每个迭代或者发布阶段的“完成”和“优秀”评判标准是由项目中资历稍浅的开发人员完成评判代码。她说：“可以这么说，除非这些资历稍浅的开发人员曾将学习过代码知识，否则项目管理者会意识到实际上评判标准根本就没有完成。”如果不是这样，项目未来所开发的功能或者产品就会出现缺陷。

开始进入会话阶段

根据Gottesdiener和Gorman所说，在结构性会话期间，敏捷开发团队需要一个或者多个经验丰富的技术支持人员来引导和传授跨职能的项目开发人员。项目领导者想要获得产品、技术、和业务知识，当然，也想获得敏捷开发的方法、业务分析和辅助技能。团队的领导者应该帮助团队成员建立一个合作和快速使用分析工具的框架，这样就可以以简单而又完善的方式来完成需求的探索、计划和交付。Gottesdiener说，“为了确定基于整个社区价值的产品需求，”技术支持人员应该“以辅助而不是直接回答和选择的方式来引导整个会话过程。”

Gorman解释说，价值是发现和交付需求之路的明灯。从会话的探索阶段到评估阶段，我们总是问：“这些产品能够提供哪些使用价值？”