Mikko Kontio 带着他的架构宣言专栏回来了。了解组织如何向敏捷流程迈进，并了解与最终更改相关的问题。在有关该主题的第一篇文章中，了解敏捷流程是什么、使用它们的优点以及对实现敏捷流程的组织所施加的要求。下个月，第
2 部分将讨论敏捷流程在不同类型的公司（包括传统公司和新型公司）中的使用，以及小型和大型项目如何影响客户和销售人员的体验。
随着敏捷开发在过去几年来日益流行，许多公司正在考虑如何利用敏捷开发流程和技术。虽然我不是敏捷开发的倡导者，但是敏捷开发技术已证明在某些类型的组织和项目中是非常有益的。
在开发流程和与流程开发相关的问题中，敏捷性已成为热门话题，因为：
- 企业希望能够更快地对市场变化做出反应。
- IT 部门希望交付结果而不需要正式（或通常）的六个月发布周期。
- 开发人员喜欢稳定的开发环境，以便能够在其中集中精力处理正在构建的软件的功能和质量。
敏捷开发并非对所有的组织、项目或客户都适合。存在某些使得敏捷开发适合于某些组织而不太适合其他组织的条件。此外，一如既往地，实际执行流程的是人员（并且人员具有各种各样的类型）。
在本专栏中，我将讨论帮助您评估敏捷开发是否适合您的组织的条件。了解敏捷开发的优点以及敏捷开发流程的“人员”方面。
下面首先定义 “敏捷”这个单词的涵义是什么。存在许多不同的敏捷开发方法。它们全都集中于面对面的交流和快速的发布周期，并且它们的目标都是在短时间内交付软件的可工作部分。敏捷方法是减少开发过程中的官僚作风的尝试，以发布实现了客户的最重要需求的可工作软件。有人可能会说，敏捷开发是处于过度官僚主义中间的理性呼声，是有文档记录的开发流程；但是这种说法并不完全正确。其含义完全取决于具体的情形。
与某些观点相反，敏捷开发人员并非不按规则或限制编写代码的特立独行者。“牛仔编码”是缺乏规则和管理糟糕的迹象，并且很不专业。如果在您的公司（或者更糟糕，在您的团队）存在进行牛仔编码的人员，为了客户的利益着想，您应该竭尽全力地改变这种情况。
人们经常使用一个小型项目团队（比方说五个人）开发一个两年项目的案例来描述敏捷开发。如果该团队使用传统的瀑布式方法，如图
1 所示，则需要花两到三个月的时间来详细记录所有的需求。然后该团队将分析那些需求。需求分析之后是系统设计，包括架构。到此时为止，客户将引入首批更改，从而进入更改管理流程。更改管理流程本身将需要少量的需求修改、另一次需求分析以及可能的更多设计。
在六、七个月之后，该团队最终为实现做好了准备。正如您可能猜测的那样，客户将需要附加的更改，从而再次经历更改管理流程。现在请不要误会我——在有些情况下，这也许是唯一的可能流程——例如任务关键型或生命支持系统。
图 1. 传统的瀑布式开发
如果此示例中的团队使用了敏捷方法，如图 2 所示，则应该已经大致拟定了需求，但是允许项目所有者对需求进行优先排序。然后项目所有者和开发人员将共同从需求中选择一小组功能，并在一系列分别持续两到三周的迭代中实现所选的功能。通过几次迭代，他们将开发该应用程序的工作运行版本，并且项目所有者可以开始试用或使用该应用程序。在经过几次更多的迭代之后，应用程序将具备基本功能，并为发布做好了准备。
图 2. 敏捷开发过程中的最初迭代
图 2 所示的敏捷方法产生应用程序工作版本的速度比瀑布式方法仅产生应用程序设计的速度还快。该工作应用程序仅包含基本功能，但它仍然是个工作版本。拥有一个工作版本是非常有用的——虽然是仅有基本功能的工作版本——这样您就能够开始使用内部应用程序来更快地创建业务流程，或者发布某个商业服务的
Beta 版本以开始吸引客户。
下一个部分将讨论使用敏捷流程的优点。
如果组织无法从敏捷方法中获得任何优点，则不存在使用它们的理由。通过列出敏捷原则可以最清楚地讨论其优点，如下所示：
- 快速、连续的交付
- 通过快速、连续的有用软件交付来获得客户满意度。这对您的组织是否重要？您的公司是否为希望开始用某个应用程序的
Beta 版本来吸引客户的新公司？您的应用程序是否将通过取代手动工作来节省内部开支？
如果是，您可能会从敏捷开发中获得好处。
- 频繁的交付
- 可以按照数周而不是数月的间隔频繁地交付可工作的软件。如果您的应用程序是 Web 应用程序，您可能希望频繁推出更新以添加新功能，或者在获得客户的反馈时改进该应用程序。您不必担心繁重的版本控制任务，或者维护文件以跟踪哪个客户端具有哪个版本。
如果版本发布涉及到客户端的更改或工作，您可能不希望频繁地做出更新。此外，频繁的迭代也许是个好主意，因为您知道自己可以在数周而不是数月内实现和发布更改。
- 工作软件
- 主要的进度度量标准是工作软件。已编写的文档和幻灯片演示并不足以满足大多数业务需求——您需要相关的工作软件。
如果您从事的是咨询业，也许文档和幻灯片就足够了，但是部署工作软件最终是大多数组织的目标。
- 适应
- 在敏捷开发方法中，即使是后期的需求更改也是受欢迎的。很长时期以来，软件专业人员竭尽全力地避免或减少做出后期更改。然而，由于业务环境可能快速变化，软件需求也应当如此。
- 亲密无间，日常协作
- 业务人员和软件开发人员应该每天就解决方案交换意见并展开协作。后期需求更改可能来自于业务人员，并且开发人员应该实现那些需求。如果流程允许需求变更，则日常协作是必需的。
对于实现接口或规范的应用程序，需求应该与指定的权威机构发布的规范文档相同。对该文档的更改不只是大事，这种更改根本就不应该出现。
- 积极主动、熟练人员
- 项目是围绕积极主动、熟练的受信任个人而构建的。（这确实应该是任何组织的基础。）无疑可以编写另一个专栏来讨论为什么某些人积极主动，而其他人则不是。
您是否拥有用于激励和培训没有动力和不熟练的工作人员的资源，或者您是否需要确定已经充满动力并且高度熟练的可雇用人员？
- 自组织的团队
- 自组织的团队在大多数软件开发工作中还不是现实。他们需要大量的开发和管理方面的经验。自组织的团队将决定他们可以在某个迭代中实现需求的哪个部分，并将决定由谁负责该实现。团队成员的角色基于他们的兴趣和知识，而不是基于管理层的任命。
组织涣散的团队将仅接受少量需求，并且产出成果也不多。为了正确地工作，团队必须了解他们在做什么，并且管理层必须信任他们。
应该参照其他团队而不是参照不明确的所需工作量估计来对自组织的团队进行评估。您的组织是否拥有熟练人员？作为团队成员或经理，您是否对完成的任何工作感到担心？
此时，您可能怀疑敏捷原则或自组织的团队在您的组织中是否有效.这无疑会导致下一个重要问题。
在具有某些特征的组织中，适应敏捷方法要更为容易。最初由 Cohen
等人 指出的那些特征包括：
- 协商文化。
开放和诚实的讨论在任何组织中都非常重要，但是如果您计划采用敏捷方法，则组织的各个部门必须良好沟通并且能够在必要时做出妥协。
- 组织中的工作的人员之间的信任。
如果管理层不信任开发人员，或者开发人员不信任销售人员，您就麻烦了。
- 规模较小、能力级别较高的团队
只需使用少量不必应付额外官僚作风的非常优秀的开发人员即可完成大量的工作。
- 促进团队成员之间快速沟通的环境。
业务需求需要在眼下而不是在下周得到满足。您的组织文化需要是快速响应的文化，而不是在过程中一筹莫展的文化。
- 小型项目团队规模（少于 20 或 30 人）。
随着规模的增长，面对面沟通将变得更加困难。
几年前，我曾经在一家公司工作，并在那里应用 IBM Rational® Unified Process
(RUP®) 的简化版本。该流程的特征相当敏捷，虽然我们没有将其称之为敏捷。我谈到了迭代，如何使用它们，以及为什么它们非常好。由于某种原因，人们没有真正响应。后来一位项目经理解释说，因为需求不清楚，人们将“迭代”解释为反复不断地做同一件事情。他们以前的经验导致他们听不进我所说的内容。我认识到，无论您准备得多么充分，值得了解的是实现流程的人员，以及有历史经验的人员。
下一次我将讨论不同类型的组织中的敏捷开发方法，例如新公司、内部开发机构和大型公司。届时将介绍小型和大型项目。我还将从客户的角度研究敏捷开发、将开发外包的情况，以及固定价格和计时项目如何影响交易。
学习
获得产品和技术
- 下载
IBM 产品评估版，获得来自 DB2®、Lotus®、IBM Rational®、IBM
Tivoli® 和 IBM WebSphere® 的应用程序开发工具和中间件产品。
讨论
|
