企业层面的敏捷开发：可能危害成功的误解-InfoQ

关键点

当大型、复杂的企业试图将敏捷应用扩展至在监管合规性、很长的资金周期以及涉及许多利益相关者需求的层面上时，必须解决许多关于敏捷的常见误解。

企业规模的敏捷要求的不仅仅只是用用户的故事来代表需求；用户故事必须用其他的工具和信息来支持，以传达对整体性的理解，并提供一个有质量的需求的持久的、可追溯的来源。

一些前面的分析工作可能需要有坚实的需求基础，但你不必因此而牺牲或放弃敏捷性。

业务分析人员仍然在敏捷开发中发挥着关键作用。他们使用他们的人际关系和分析能力来定义和验证真正的业务需求。

为了实现成功的敏捷，组织需要一个有针对性的需求解决方案，强调协作并且使业务分析师们与开发团队的 sprints 同步去迭代进化需求。

敏捷开发过程保证了好处，但大型企业在他们自己的环境中很难找到适合自己的有效的敏捷方法。它从根本上不同于应用开发和交付的瀑布式方法。它采用递增方法，集中精力在期限内完成工作即可。挑战接踵而至，因为企业有必须满足的一定的工程标准，比如：

考虑审计和合规性规定
在一个明确定义的范畴内，创建商业案例以确保资金
把在用户之外的广泛的利益相关者也考虑进来，比如法律、营销和运营等

“敏捷交付中遗漏的需求的影响”是Forrester 最近做的一项研究。这项研究揭示了在采纳敏捷的过程中出现遗漏的需求、以及组织用更好的管理工具可以实现的有形的商业利益的根本原因。96% 的受访者报告了由于遗漏的需求所造成的软件开发项目中的问题。60% 的受访者期待能通过避免遗漏的需求来实现更快的交付，增加客户的满意度。

当在企业中推行敏捷工作时，信息技术和商业领导人需要区分事实和虚构之间的关系。以下是组织在实施企业敏捷实践时，应解决的六个最常见的误解。

1. 不需要提需求。

在企业中推行敏捷是有确定的好处的，但免于定义需求并不是其中之一。发现和设定范围仍然是我们必须要做的重要工作，尽管详细程度可以缩减到只涉及那些要做业务级的决定所需要的内容。但我们不要犯错误，还是有许多关键元素需要有明确定义的，比如：

确定业务规则
进行利益相关者分析
确定和阐明业务需求和目标
为项目提供资金保障
获取和分析业务流程
定义解决方案的范畴
创建和维护商业案例

这些元素提供公司业务作出关键的决定所需要的信息。必须要做一定量的前期分析工作，以奠定坚实的需求基础，但团队并不必因此牺牲或放弃敏捷性。

敏捷的一个关键原则是其“简单性”：最大限度地提高未完成状态工作的数量。

在企业敏捷实现中的业务分析师可以提供足够（和不会更少）的细节以建立范围和业务需求，同时在以后的迭代中提供剩余的细节。

2. 谁需要业务需求？用户故事将会需要业务需求。

从用户的角度来看，用户故事虽然提供了一个功能强大的应用程序粒度的视图，但它只有一个角度。虽然它很关键，这它并不是唯一的角度。其他的利益相关者，比如产品经理、管理人员、财务人员和那些维护、运维和支持应用程序的人员各自有不同的需求。并且这些需求中许多都表现为对应用程序的非功能性需求或约束。

只有用户故事是不够的，另一个原因是它们缺乏抽象性——能够提供业务需要的不同的视图，无论是通过提升多个层次并从中获得完整的需求，还是通过向下钻研多个层次进入到细节之中。相比其他方法和技术，用户的故事在这方面就会受他们本身的能力局限。可视化建模、仿真和业务流程管理（Business Process Management，BPM）都可以帮助传递业务需求。这些轻量级模型可以很容易地通过手工或技术完成。

3. 遵守和审计需求？你所需要的只是用户故事而已。

当涉及到确保开发和部署的内容可以满足或超出审计和合规性的需求，有两个主要原因可以解释为何不能单纯地依赖于用户故事。首先，用户故事是暂时的。一旦实施，它们会被丢弃。第二，用户故事缺乏内在的可追溯性，意味着即使它们被保存下来，也没有直接的、容易识别的在用户故事内容和特定的应用功能之间的联系。

在企业内持续的、可追溯的需求成了面对审计和合规性时的一个强制任务——无论由内部还是外部的力量驱动。一种有效的去适应这些需求的方式就是将可追溯性和可审计性的技术自动化，确保有在项目的每个阶段的合规性和可视性的证明。

合规性文档可以逐步建立。这需要有一个存储库或单一的真相来源，这样可以作为文档的参考点。使用存储库可以定期地重建和更新文档。在完成迭代的时候，能够跟踪用户故事一直回到原来的需求，这一点能给你信心，说明你已经充分覆盖了需求并且所产生的工作是合规的。

4 当企业敏捷出现时，为企业变革做好准备。

无论项目是否涉及敏捷，作项目管理都是一场持续的成本效益分析过程。项目经理们总是在基于预期成果和降低风险寻找衡量进度的方法。

事实是，不同的数据将被各级管理层用来作出相同的决定。例如，项目经理可能使用工作分解结构作为对传统项目决策的基础。然而，在企业敏捷环境下，产品积压的燃尽图将被用来作为做出同样的决定的基础。

5。我们不需要业务分析–它使我们陷入停顿。

业务分析和需求定义是不一样的。如果错误地相信这个观点就会导致谬论：“如果采用敏捷我们将能摆脱需求，那么我们同样也可以摆脱业务分析。”但是业务分析不是简单的对需求的收集，就好像从灌木丛里采摘浆果一样。它也不是一个“一气呵成”的命题。它涉及到理解业务战略和目标，寻找和激活不同层次众多来源的“原始”信息，从无关信息中分离出有关的信息，并进行分析以推导出一套业务需求并检验它们。

一个业务分析师的工作就是定义和管理需求，了解它们的关系，并评估它们对业务的影响。在所有项目中都需要进行很多的业务分析——不断地创造、分析和改进需求。在企业敏捷中，这项工作仍然一如既往地重要。它仍然贯穿在整个项目的生命周期，是一项关键的正在进行的活动。

6. 不需要需求管理软件。

当一个企业的敏捷过程是由一个集成了敏捷开发组和其他业务部分的需求的应用程序支持时，她就把握住了最好的成功机会。

如上文所述，敏捷并不意味着“没有需求”，相反，它应该由一个专门为敏捷环境配置的应用程序所支持。它使业务分析师们可以分析业务，并在项目进程中迭代式地产生出一套与开发团队的短 sprints 同步的系统需求。通过这样的方式，就不仅仅是业务分析师们在从需求工具中获取价值，业务利益相关者和开发团队也都可以。去找到一个为企业敏捷环境专门配置的有针对性需求的应用程序吧。

为更大的成功寻求协助

组织采用敏捷的原因是它可以保证快速的交付，但在实施和成功之间还有大量的工作要做。敏捷开发环境本身的属性是迭代的，同时按时交付最小的有效工作量——但这并不意味着跳过关键的细节。相信上面列出的六个误解中的任何一个都可能让你失败。用户故事、需求定义和协作是敏捷使用过程中的重要方面，具有可追溯性和合规性也一样重要。需求管理软件能够让所有的利益相关者在同一页面中进行有效的合作，保证一个详细周密的开发过程。适当的提前计划和真正了解需要什么，将有助于保证项目一次成功并且避免返工。