敏捷架构宣言，第 1 部分：敏捷开发是否适合您的组织？

随着敏捷开发在过去几年来日益流行，许多公司正在考虑如何利用敏捷开发流程和技术。虽然我不是敏捷开发的倡导者，但是敏捷开发技术已证明在某些类型的组织和项目中是非常有益的。

在开发流程和与流程开发相关的问题中，敏捷性已成为热门话题，因为：

• 企业希望能够更快地对市场变化做出反应。
• IT 部门希望交付结果而不需要正式（或通常）的六个月发布周期。
• 开发人员喜欢稳定的开发环境，以便能够在其中集中精力处理正在构建的软件的功能和质量。

敏捷开发并非对所有的组织、项目或客户都适合。存在某些使得敏捷开发适合于某些组织而不太适合其他组织的条件。此外，一如既往地，实际执行流程的是人员（并且人员具有各种各样的类型）。

在本专栏中，我将讨论帮助您评估敏捷开发是否适合您的组织的条件。了解敏捷开发的优点以及敏捷开发流程的“人员”方面。

回页首

敏捷的含义

下面首先定义 “敏捷”这个单词的涵义是什么。存在许多不同的敏捷开发方法。它们全都集中于面对面的交流和快速的发布周期，并且它们的目标都是在短时间内交付软件的可工作部分。敏捷方法是减少开发过程中的官僚作风的尝试，以发布实现了客户的最重要需求的可工作软件。有人可能会说，敏捷开发是处于过度官僚主义中间的理性呼声，是有文档记录的开发流程；但是这种说法并不完全正确。其含义完全取决于具体的情形。

与某些观点相反，敏捷开发人员并非不按规则或限制编写代码的特立独行者。“牛仔编码”是缺乏规则和管理糟糕的迹象，并且很不专业。如果在您的公司（或者更糟糕，在您的团队）存在进行牛仔编码的人员，为了客户的利益着想，您应该竭尽全力地改变这种情况。

人们经常使用一个小型项目团队（比方说五个人）开发一个两年项目的案例来描述敏捷开发。如果该团队使用传统的瀑布式方法，如图 1 所示，则需要花两到三个月的时间来详细记录所有的需求。然后该团队将分析那些需求。需求分析之后是系统设计，包括架构。到此时为止，客户将引入首批更改，从而进入更改管理流程。更改管理流程本身将需要少量的需求修改、另一次需求分析以及可能的更多设计。

在六、七个月之后，该团队最终为实现做好了准备。正如您可能猜测的那样，客户将需要附加的更改，从而再次经历更改管理流程。现在请不要误会我——在有些情况下，这也许是唯一的可能流程——例如任务关键型或生命支持系统。

图 1. 传统的瀑布式开发

我将在本专栏的第 2 部分更详细地讨论大型项目。

如果此示例中的团队使用了敏捷方法，如图 2 所示，则应该已经大致拟定了需求，但是允许项目所有者对需求进行优先排序。然后项目所有者和开发人员将共同从需求中选择一小组功能，并在一系列分别持续两到三周的迭代中实现所选的功能。通过几次迭代，他们将开发该应用程序的工作运行版本，并且项目所有者可以开始试用或使用该应用程序。在经过几次更多的迭代

 

本文转自IBM Developerworks中国

        请点击此处查看全文