![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
我的敏捷开发系列的第 1 部分介绍了敏捷流程、使用敏捷流程的优点，以及对使用敏捷流程的组织作了要求。在本文中，我将讨论不同类型的组织（例如新公司、产品公司和中小型组织）如何适应敏捷开发。您还将了解文化和定价如何影响过程和结果。
在初创型企业工作可能充满了挑战，但是新公司具有某些流程方面的优势。新公司从头开始开发他们的产品，通常没有大量的代码库或历史包袱。它们可以比具有一定历史的组织更自由地选择工具、技术、流程、人员和正在构建的产品的用途。
新公司可以选择其工作方式。如果产品领域没有受到严格管制，或者产品在发布或进入 Beta 测试前不需要获得批准，那么公司可能会快速取得一些成果。即使第一个版本是 Beta——或者只是带有屏幕快照的网站——也最好是一开始就公诸于众。公司流程沿着敏捷的方向推进，对于大多数新的组织来说，这是非常好的。
在某些情况下，现有的公司可以通过允许某个新部门随心所欲，而不是强迫他们遵循公司原则，从而给他们带来新公司的感觉。允许某种程度的行动自由是一种不错的方法，可用于测试现有流程或确认现有流程是为另一种类型或规模的活动而设计的。
如果没有人员，流程不过是纸片或计算机屏幕上的图表。新公司开始选择并培训员工。这是一个极大的优势，因为您可以确保为每个人制定相同的规章制度。如果某人不按规定行事，并且没有提供合理的解释，您必须要求他走人。只需确保在雇佣员工之前制定规章制度。
组织文化是一种很有威力的东西。例如，如果您的文化强调奖金，如果人们认为花在培训或聚会上的资金会减少他们的奖金，那么他们也许不希望参加这些活动。然而，如果您的组织文化适合您的目标，该文化也许就是您所需的一切。在新公司中，您可以创建自己的文化以支持您的需求。强调开放讨论、高质量和团队协作的文化可以为采用敏捷开发流程提供强有力的基础。
新公司通常具有较小的项目，无论是由于他们的产品是新产品，还是由于他们的客户（通常是 Java™ 工作室）比老牌公司的客户规模小。少于 20 个人的小型项目更适合于敏捷开发。
新公司还拥有新客户（对新公司来说，客户无论如何都是新的）。面对新的客户关系，不存在任何不良记录的负担。敏捷开发也需要一些来自客户的不同流程或习惯。作为新的提供商，您可以首先解释过程和客户将享受到的利益。
新公司或新的业务单位是适应敏捷开发方法的肥沃土壤。但是如果不是新公司，又该如何呢？
更常见的情况是，您拥有一家具有自己的文化、流程、客户和人员的发展型企业。对于现有的公司，采用敏捷方法必须表明收益。如果工作没有某种程度的改进，只是为更改而更改并不是个好主意。
对于现有的流程，是否人人都以自己的方式编写流程或进行开发？您应该有做出更改的理由。该更改是为了实际利益还是为了其他什么目的？使用本系列的第 1 部分中的列表，尝试保持中立地检查该更改，并考虑敏捷开发是否很适合您的公司。如果是，您将拥有向团队展示的优点和事实。更好的是，让项目经理和开发人员介入敏捷方法的研究。很可能他们将推动该更改。
正如已经指出的那样，公司文化是很有威力的东西。如果组织需要不同的开发流程，而其组织文化强烈抵制更改，则在尝试改变文化之前，不要尝试采用敏捷方法。
您所从事的项目类型是一个重要因素。您是在开发自己的产品、从事客户项目、提供咨询服务，还是维护和支持遗留系统？具有一定历史的应用程序更难于更改。限制通常来自于现有的代码库或来自于客户需求。例如，如果每个软件更新要花费客户数周的工作，并需要若干人员的参与，则每隔三周发布一个新版本是不合适的。为了简化客户的工作，您可以首先将软件作为服务来提供，并计划和实现版本更新。
在具有一定历史的公司中采用敏捷流程更具有挑战性，但是如果存在这样做的明显好处，也是可以实现的。
要使敏捷原则正常工作，项目规模非常重要。人员数量比项目长度或功能数量更为相关。您始终可以优先安排功能，并使用更多的时间去实现它们。但是如果必须在非常短的时间内实现许多功能，您将需要大量的人员才能完成。研究和经验表明，理想的敏捷团队规模为 20 到 30 个人员——或者更少。 检查本系列第 1 部分中的敏捷原则，并分析团队的人员数量如何影响项目。
大多数原则都需要面对面讨论，这在大型团队中变得非常困难。敏捷开发的强大功能建立在交流的基础上。
对于大型团队来说，自我组织可能是另一个问题。人们可能偏离实际问题，并且一个团队成员可能会认为另一个成员将负责任何给定的问题。但是如果只有 Bob、Eve 和您，某个问题是否正在得到处理将是非常明显的。
在内部更改的过程中通常会忘记客户，从而可能导致困难。客户需要了解新流程的优点，以及它与以前的流程有什么不同。有些客户对您的工作方式感兴趣，而其他客户则仅关心结果。
在理想的情况下，客户仅会注意到积极的效果，而不会意识到已做出的任何更改——在交付产品或按需应用程序的情况下尤其是如此。客户可能注意到某些请求实现得更快了，并且总体质量更好了。
如果您在客户按规范定购开发工作或功能的情况下提供开发服务，则流程就更加可见了。客户需要了解敏捷开发流程的主要原则，因为这影响到工作报酬的最佳支付方式（下一部分将对此进行讨论）。对于敏捷开发，开发人员团队在一定的时间期限内完成大量力所能及的事情，该时间期限支持基于时间的支付模型。如果客户习惯于以固定价格的模型购买开发工作，或者具有正式的指导原则，则采用敏捷开发流程对客户来说是非常大——甚至不可能——的更改。
如果您是在开发自己的产品或服务，例如某个 Web 应用程序，您的客户可能对您如何开展工作不感兴趣。他们只希望您的工作成果是高质量的应用程序。如果您是在提供软件开发服务，则定价模型就变得非常重要了。
客户使用两种基本类型的定价模型：
- 固定价格模型
- 客户和开发人员协商项目的固定价格。指定固定价格通常需要就项目的范围和需求达成一致并作书面记录。正如您可能已经猜到的，此模型对于敏捷开发并不理想。
- 时间和材料模型
- 客户在较长时间内雇佣开发人员或咨询人员，并根据使用的时间支付报酬。此选项更适合于敏捷开发，因为它将范围和需求保持开放。
如果客户喜欢使用固定价格模型，您可能发现很难使用基于时间的价格模型做成销售交易。（客户可能会抵制他们认为自己不能控制的情况。）提出目标定价建议，并解释为什么固定定价不适合于敏捷开发流程。
在本系列中，您了解了敏捷开发方法如何适合新公司和具有一定历史的公司。在按希望的那样开发流程和文化方面，新公司处于稍微更有利的地位。虽然现有的公司可能发现更难适应敏捷方法，但是如果最终的收益非常合理和明显，他们也会这样做的。
项目的规模影响流程。团队成员少于 20 人的小型项目更适合于敏捷方法，因为面对面交流对较大的团队来说更加困难。
对于敏捷开发，基于时间的定价比固定定价更为适当。如果客户购买开发服务（而不是购买产品），客户还应该了解敏捷方法的原则和好处。
学习
- 您可以参阅本文在 developerWorks 全球网站上的 英文原文。
- “An Introduction to Agile Methods”（David Cohen、Mikael Lindvall、Patricia Costa，2004 年）讨论了敏捷的含义、管理层的作用、更流行的敏捷方法，以及用于决定敏捷方法适用场合的指导原则。
- 阅读 Wikipedia 上有关敏捷软件开发的讨论。
- 了解 Scrum，这是一个敏捷流程，可用于管理和控制使用迭代、增量方法的复杂软件和产品开发。
- “Why Fixed Bids Are Bad for Clients”（ScrumAlliance，2007 年 9 月）讨论了敏捷项目和固定价格的投标。
- “OpenUP 精华（OpenUP In a Nutshell）”（developerWorks，2007 年 10 月）探索了 OpenUP，这是最近开发的一个用于软件开发的流程框架，并集中于从 Rational Unified Process 派生的敏捷实践。
- 如果您拥有海外市场，需要在软件开发生命周期中进行相当多的规划，以适应文化和语言差异，请阅读“面向全球化的有效敏捷交付”（developerWorks，2007 年 10 月）。
- developerWorks 访谈: Scott Ambler 谈敏捷开发（developerWorks，2007 年 4 月）介绍了这种迭代和增量开发方法，展示了其业务案例，并揭开了该过程中的一些秘密。
- 使用 developerWorks 演示中心，了解 IBM 提供的各种软件产品和技术。
- 了解最新的 developerWorks Live! 技术讲座。
- 获取 Mikko Kontio 架构宣言 专栏的 RSS Feed。
- 浏览技术书店，以了解有关这些技术主题及其他技术主题的相关书籍。
获得产品和技术
- 下载 IBM 产品评估版，获得来自 IBM® DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。
讨论
- 参与论坛讨论。
- 阅读 developerWorks Blog 中每个人讨论的内容，从而参与到 developerWorks 社区中来。
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。