从Reifer的“敏捷方法定量分析”研究中学到的十个知识点

I. 敏捷方法的十个“知识点”

Reifer咨询有限责任公司发表了一份名为“敏捷方法定量分析¹”的基准报告，这份报告比较了敏捷方法软件生产率、成本、持续时间和质量与传统的计划驱动项目的差异。这份报告分析了800个项目（其中有250个敏捷项目）的工作数据，跨越10年，使用了由60个组织提供的完整工作数据。

读者可以在我们的敏捷研究中找到以下十个“知识点”，我们所参考的基准报告中记录了相关研究成果。这份报告目前售价795美元，可在此订购，点击这里可以详细了解国际软件基准组织。

1. 敏捷生产率——敏捷生产率（以产出/单元投入成本进行度量）高于已交付产品的由计划驱动的项目的经验基准。该经验基准取自10年中在名义值上下浮动50%的数据，采用敏捷后一年内生产率平均最多能提升10%到20%。但是，这些提升取决于应用的领域，并且受许多因素的影响（如劳动力构成结构、产品复杂度、项目规模等等）。例如，有一些项目需要通过认证的形式（比如飞行安全和安全认证等），这些项目看起来就不太适用于敏捷方法。Capers Jones的数据²证实了我们提出的观点，此类项目使用像RUP³（统一软件开发过程）和TSP⁴（团队软件过程）之类的结构化过程可以更快地通过认证。

驱动因子：改善团队工作，使用轻量级过程，重点关注产品、可执行的代码和潜在的霍索恩效应。

问题：开发、维护或组织问题，过程僵化和教条，过于严格的管理，外包问题，缺少产品管理的核心。

应对措施：我们提出以下几个提升敏捷生产率的建议：

• 理解影响生产率的变数（架构稳定性、产品复杂度、员工技能水平和经验等），当你转用敏捷时要处理好这些变数。
• 收集生产率测量和度量结果，这些数据有助于我们做必要的调整。
• 改革时难免会遇到阻力，建议先运行试点项目，收集这些项目的度量和测量数据，用这些数据说明敏捷是一种更好的商业运作方式。
• 在试点项目中调整过程和敏捷方法，找出达成商业目标的最佳方法。
• 如果条件允许的话，最好让大家在一起工作，以避免在第一个项目中就出现管理和合同上面的问题。
• 使敏捷重点关注能够带来差异化的那些应用的开发。
• 星星之火可以燎原，敏捷的一次成功可以带来更多的成功。

2. 敏捷成本——敏捷成本（以开销/单元产出进行度量）低于以计划驱动项目的经验基准。该经验基准范围取自10年间在名义值上下浮动100%的数据。采用敏捷后一年内平均最多能降低20%到40%的成本。同样，这种成本变化在很大程度上也取决于所在的应用领域，并且受许多因素（包括劳动力构成结构和工资水平）的影响。

驱动因子：降低人工费用率、降低管理费用、简化沟通机制、更加关注产品而不是过程。

问题：更重视开发而非规避维护成本、机构重组和角色澄清、僵化的过程、治理过于严格、外包问题以及不重视产品的管理。

应对措施：我们提出以下几个降低敏捷成本的建议：

• 理解影响成本的变数（这些变数与生产率有所不同），转用敏捷时要处理好这些变数。
• 基于事实做项目估算（通常所有sprints估算的交付物之和少于最终产品应有的交付物）
• 监控项目成本、跟踪预算开支。
• 重视敏捷教育和培训的早期投入。
• 在工作开展之前选购适当的工具并设置适当的运作机制（战情室、任务板等）。
• 转用敏捷时应该尽可能遵循节俭和简单的原则。

3. 敏捷上市时间——敏捷上市时间（度量软件从开始到最终交付的总体有效时间）比计划驱动项目的经验基准要短10%到60%，在采用敏捷之后平均最多能缩短20%到50%（不同项目规模会有所差异）。但需要注意的是，一味地想要加速交付周期常常会遗漏一些需求，使交付的功能和特性无法完全满足客户或用户需求，从而降低了客户满意度。

驱动因子：关注正在开发的工件，在sprints期内快速开发，在最终投入市场之前增量交付演示版本。

问题：sprints期内未能完成所有工作承诺，待办任务未能清空，客户或用户可能没有成为团队成员，管理者可能没参加到敏捷工作中来。

应对措施：我们提出以下几个缩短敏捷上市时间的建议：

• 理解影响上市时间的变数，转用敏捷时要处理好这些变数。
• 充分考虑环境因素，把项目作为整体制定务实的时间估算，然后再调整sprint和增量计划。
• 在项目开发过程中监控里程碑达成情况。
• 让团队控制sprint时间线。
• 设立对增量时间线和内容的期望。
• 坚持在每个增量结束时演示工件，并争取让客户或用户、市场人员和管理者都参加。

4. 敏捷质量——敏捷质量（以发布后的缺陷密度进行度量）比计划驱动项目的经验基准要高2%到8%，交付后的质量甚至能高出20%到30%。同样，质量取决于应用的领域并受许多因素的影响，其中包括质量控制和质保实践。

驱动因子：过程监督执行不利，过多地强调测试而没有做整体项目的质量保证，没有产品质量目标，在设计产品时未考虑质量，缺少指导决策的质量文化。

问题：在敏捷初期没有强调质量就急着直接编码、把测试视为质量保证、不执行质量控制、不收集质量指标、不应用成熟的质量控制和质保实践。

应对措施：我们提出以下几个提升敏捷质量的建议：

• 把发布速度优先的文化转变为质量优先的文化。
• 拥抱质量，让它成为所有工作过程中的一部分。还需支持同行评审，在每日站会上讨论质量，从版本控制资源库中收集缺陷信息，在任务板和版本状态报告中展示这些缺陷。
• 让每个团队成员互相检查彼此间产品的质量。可以举办一个竞赛，为了使活动更有趣味性，可以为做得好的成员颁发奖品和奖状。
• 记录质量度量和测量结果，不论是软件开发期还是软件维护期都可以用这些指标量化产品的质量。
• 经常分析质量问题的“根本原因”，不要只关注问题的表面症状，还要关注导致缺陷的原因。
• 永远不要发布很可能有缺陷的产品。当质量和发布速度产生冲突时，应该坚持原则说到做到，勇于承担责任。
• 使用精益和看板法⁵原则能让我们随着产品开发过程关注工程质量。在sprint期找出缺陷并修复它们，或者把它们放到待办工作中随后解决。

5. 敏捷的竞争优势——敏捷最具竞争性的优势在于它能让组织发挥优势、改进不足。使用敏捷不仅可以提高生产力、降低成本、加速上市时间，它还能帮我们吸引和留住人才，这些人才是智力成本，能让我们在竞争激烈的市场中脱颖而出。但是，有些应用领域不要使用敏捷方法，敏捷在这些领域起不到应有的作用也没有什么意义，比如需要认证资质的应用以及大型的分布式的复杂的开发等。

驱动因子：敏捷已经被过度夸大和使用，任何新鲜事物都会被质疑，许多公司并不把软件作为竞争格局的一部分（例如，软件只是辅助性服务而不是创收的生产活动）。

问题：既要了解敏捷的优点，也要了解敏捷的缺点，采用敏捷需要做出一定的组织变更（比如一些新的角色和职责），对于组织来说转用敏捷像采用别的新做法一样充满风险。

应对措施：我们提出以下几个更能发挥敏捷优势的建议：

• 变更组织结构，把敏捷融入到组织的主要流程里。
• 通过岗位职责说明书明确定义敏捷职位说明、角色和团队的概念。然后为岗位配备工作人员，雇用敏捷教练对这些工作人员进行指导和培训。
• 自上而下地转变文化，由领导命令驱动的风格转变为自组织、分享式团队，至少要让你的软件组织转用敏捷。
• 完善必要的治理，使合规性保证不再依赖于上级或外部的监督，让敏捷团队独立自主，即使需求超出了范围也要相信他们可以应对。但是，当度量和其他指标显示工作进展滞涩时，你就需要监控他们的工作并帮他们做些调整了。
• 争取达成商业目标，比如先完成优先级高的任务而不要把主要精力都放在那些即将要交付产品的项目上，这种做法虽然可以满足一个客户（或用户），但却牺牲了其他的客户（或用户）。
• 尽量让事情简单，从产品架构到软件产品本身都要遵循这一原则。此外，还可以把这一原则延伸到组织结构上，承担交付责任的组织也要尽可能地简单。
• 将组织重心从实现单独的目标（按计划执行分派的任务等）转变成通过团队协作为组织及其客户提供价值，把重点放在产出的工作产品上。
• 营造一种鼓励尝试的文化，无论尝试的结果是成功还是失败，鼓励那些勇于做决策、冒风险、努力去解决问题的人。
• 当结果可以预测但没有十足把握时，由团队自己做出决策。
• 尽量创建更好的商业模式，为个人、企业和客户提供更好的工作环境。

6. 具有一定规模的敏捷——一直以来，在大型项目中都难以应用敏捷方法。基于我们的数据分析（60个不同组织的800个项目，其中有很多已经使用了10多年的敏捷），敏捷不适用于大型复杂项目。虽然有一些大型项目也使用敏捷取得过一些显著的成就，但由于缺乏针对大型项目的体系和指南，软件工程实践者需要面对很多不利条件。从我们收集的数据来看，当项目员工总数超过100人，而且他们处于不同的地理位置、分属多个民族时，应用敏捷方法的工作效果是达不到平均值的。另外，从我们和Capers Jones的数据来看，当用户和客户总数超过100时敏捷就会出现问题，因为大家对系统愿景有着各自不同的理解。或许，造成这种局面的根本原因就是大多数大型项目并不直接面对用户，这与敏捷是有所背离的。反之，这些项目在真正投入使用之前要先交付给一些集成和测试组，经历各种严格的系统测试（性能、可用性等）。

驱动因子：敏捷实践在大多数情况下只适用于小型团队和项目。虽然也有人提出过一些针对一定规模项目的敏捷方法，但由于它们并未重视和应用传统的项目管理技术，我们并不太认可这些方法。此外，正如前文所说，敏捷项目应快速交付给客户或用户，但大型系统要先经过系统集成和测试后才能交付使用。

问题：无法协调、监控、跟踪和调整分散在不同地域、不同团队的开发人员，无法跟踪产品业绩和里程碑完成情况，流程不当，无法满足客户期望。

应对措施：针对大型项目的敏捷应用我们提出以下几个建议：

• 借鉴敏捷的观念通过建立自组织、分享式团队突破组织级障碍。例如，因为做计划管理时矩阵式管理方式会产生很多冲突，所以应舍弃这种方式。
• 在具有一定规模的敏捷项目中你可以继续沿用传统的项目管理计划、日程安排和控制的概念，用它们设定目标和跟踪业绩。你们在项目运行过程中可以使用传统方法，在sprints运行过程中可以使用敏捷技术。
• 不要让敏捷组织和团队成为特例，而要让它们成为常态。并使它们能够面对更多的客户和用户，处理一定规模的问题，这些正是传统大型项目（比如通信项目）所要解决的问题。
• 为团队提供了推荐的大规模敏捷项目管理体系和指南。
• 在软件开发过程中做每件事都需要兼顾敏捷性和纪律性。
• 针对敏捷确立系统工程，并请客户当测试代表。除此之外，内部讨论时也不要忘了系统实际的用户、客户或甲方，因为最终完工交付的时候，是由他们评判特性、功能和性能是否达到要求。
• 为了确定迭代、项目和组织等各个级别开发基线的程度，你需要定义并执行度量和测量。
• 找出指南中不适用的过程和问题，并完善它们。特别要注意那些用于配置管理、发布管理、质量控制（或保证）和供应商管理的敏捷实践。

7. 敏捷系统工程——你需要更新系统工程实践以提升敏捷化程度。否则，因为不适用的过程会使组织产生很多冲突。举个例子，因为系统工程师开发系统需求，并把它们从硬件到软件进行逐层定位，所以应随着软件开发过程同步开发系统需求。未来的发展趋势是系统扮演客户，但如果不暴露出各种操作角色，就无法达成这样的目标。再举一个例子，由于架构是软件运行的平台，所以在过程初期应该拥有稳定的系统架构。

系统工程经常无法做到这一点，即便他们采纳了软件工程师针对面向特性和即插即用功能的建议。最后再举一个例子，通常情况下测试工程师也隶属于软件工程师，为了确保增量开发出的系统能够满足需求，需要他们支持持续集成和测试的理念。不幸的是，系统工程师不接受这种按待办任务交付的方式，因为他通常都认为每次增量之间要交付的内容是不能延迟的。为了集成和测试系统中的软件部分，测试工程师还需要与软件团队一起定置相应的机制和工具。有时系统在交付使用之前需要让实际用户（或系统操作人员）用真实的设备先予以验证。

驱动因子：过于严谨和理论化的系统工程，孤立的系统、软件文化和过程，缺乏真正的跨领域的和整体团队的概念。

问题：太晚提供软件需求，未定义系统接口，直到编程末期才开始关注系统测试而在初期根本就没有关注，系统测试和集成的机制建立得太晚，系统和软件过程不匹配，缺乏跨领域团队协作，缺乏其他领域体制的尊重，发生系统工程故障时互相推诿。

应对措施：我们提出以下能够改善敏捷系统工程的几个建议：

• 邀请客户或用户代表参与到团队中来，作为团队成员与大家在一起工作。
• 真正拥抱整体产品团队或跨领域团队的概念，平等对待团队中的每一个成员。让客户或用户代表参与到团队中成为团队成员。
• 引领工程改进而不要反被其制约。
• 不仅仅让系统、硬件和软件支持敏捷宣言，还要让工程支持敏捷宣言。
• 嫁接所有的工程和制造过程，使工作切换同步、简单。
• 制定一个单一的基于敏捷的工程过程，胜过让每个独立的领域（系统、软件、硬件、特定工程等）都有各自的过程。
• 在过程早期专注于开发客户需要的工件，胜过专注于那些独特的工程理论。
• 抱着探险家的心态去挖掘需求，胜过仅仅遵循规范的过程。
• 在整个开发过程中把重点放在开发工作产品上，胜过那些面面俱到的、有些官僚主义的文档。
• 拥抱持续集成实践，使它成为所有工程的统一框架。
• 集成还有一个好处，它简化了完备的系统为团队提供了一套简单的模型，使团队清晰哪些已经构建、哪些已经准备测试了、哪些正在测试、哪些已经可以投入使用了。
• 可以定义同步点在适当的时间集成半成品，以处理过程中必要的同步。

8. 敏捷软件维护——敏捷是否适用于软件维护？评审委员会还没有给出最后的定论。本阶段的开发使用敏捷方法有哪些利弊？我们可以从Reifer咨询公司近期针对软件维护的研究成果中找到一些答案。本次研究发现，由开发期的预算和进度计划是由需求驱动的，会有较大差异，而用于软件维护任务的资源较为固定。所以，软件维护团队的一项很重要的任务就是充分考虑工作（修复、变更、更新、优化等）的优先级，使他们能在固定的预算下尽可能完成更多的工作。其实，完成那些积累下来的变更申请和待处理的故障报告只是他们最基本的工作任务。

本次研究还发现，同一个团队要并行完成以下四种版本的开发任务：

• 当前版本——维护团队的主要任务是开发新的版本，通过升级代码为客户完成需求变更、问题修复和性能优化。
• 现场版本——维护团队的首要任务，支持现场版本，为保障系统运维执行必要的修复和补丁。
• 完整版本——维护团队的次要任务，配置和定制近期的完整版，并发布到各个现场。他们的工作内容包括做更多的测试和协调各个现场。
• 需求版本——维护团队的次要任务，目标是开发下个版本的内容（举例来说，必要时要开发原型去界定需求范围）。

为了在软件维护期能够更好地执行敏捷方法，必须让敏捷方法能够处理以上四种版本的相关工作。我们的研究表明，与软件开发期相比这些工作环节的组成和分布均有所不同。例如，这类工作在很多时候要用回归测试的方式验证最新的版本变更。另外，这类工作可能需要现场支持和运行测试的参与。

驱动因子：不清楚维护期的工作性质，当计划内的任务和紧急任务产生冲突时，不清楚怎么为维护活动或设施做预算才能更合理地完成功能增强、问题修复、性能优化等任务。

问题：分不清做的是软件开发项目还是维护项目，不适用于维护的过程或预算，预算不足导致工作积压，每次变更都要重新验证版本，产品分布式管理的问题和缺乏产品管理规范。

应对措施：我们针对软件维护期的敏捷提出以下几个建议：

• 考虑如何让敏捷方法适用于上述四种版本的所有相关工作，讨论在软件维护阶段需要做哪些工作。
• 提供一份指南，解释在上述四种版本的开发过程中如何应用敏捷技术和实践。例如，如何让sprint不仅能为完整版本引来价值还要在当下产生价值。
• 软件维护工作主要是保障系统的运行，甚至可能要在现场做功能增强、问题修复和性能优化，你需要确定这些工作的优先级。
• 设计适当的支撑架构（例如，针对所有项目的配置、分布、质量、供应商和风险管理实践），在软件维护期内使不同的设备上的不同软件都能保持最新的发布，即使它们是不同的版本和遗留系统。
• 清楚维护设备和客户支持职能需要单独做预算。你们在预算时要基于待办任务中涉及的所有工作量，而不仅仅是单独的工程，在协调计划和员工时要充分考虑这些工作。
• 持续拥抱持续集成和自动化回归测试的实践。因为，在维护期投入到验证版本变更的测试工作量要占到总工作量的75%，这些活动能产生巨大的影响。
• 坚持过程规范，特别是处理多样的发布、客户和产品版本时，一旦放松就可能酿成大祸。

9. 敏捷风险管理——你们必须要拥抱敏捷风险管理实践，特别是面向更具规模更加复杂的敏捷项目时。虽然有一些现有的技术可以用来做敏捷风险管理（比如风险燃尽表），但在我们的数据中却很少有组织使用过这些技术。按我们通常的理解这些技术可能更适用于国防和通讯领域。

驱动因子：把风险管理看成重量级过程，团队领导并不把它当成项目管理（比方说没有风险管理任务），缺少项目管理规范和实践（特别是具有一定规模的敏捷项目）。

问题：移除在预算内按时交付高质量产品的不利因素，尽可能地满足客户的预期，提升识别风险和缓解风险的能力。

应对措施：我们提出以下几个加强敏捷风险管理的建议：

• 把敏捷风险管理实践实际开展起来，让团队、管理者、客户、用户共同参与风险的识别、量化、排序和缓解。
• 制定“前十”风险列表，把它们放在任务板上,在站立会和分派任务时掌控它们的状态。
• 按潜在的技术和编程影响排出“前十”风险列表。使用类似风险燃尽表之类的技术去跟踪这些风险的缓解过程。
• 让客户或用户参与到风险管理过程中，让他（她）们根据你评估的影响为风险排出优先级。创建类似于风险委员会的组织，让大家就风险优先级达成共识。
• 当风险合理存在并且不会造成严重后果时可以冒这个险。
• 鼓励冒险，当你觉得有必要冒险并能够最小化和控制冒险带来的潜在后果时你就可以鼓励冒险。

10.敏捷外包——我们需要精确的敏捷外包实践。目前，合同管理员和甲方并不清楚如何规定敏捷承包或分包的具体合同类型、工作范围、工作状态、交付物、里程碑、支付、条款和条件。我们可以通过这些条款准确地推导出敏捷合同中要使用的时间和资源，而不是为了鼓励组织高效地工作笼统地制定激励措施。

驱动因子：敏捷是一个相对较新的商业模式，几乎没有公司做过涉及到采购方的敏捷，在实际工作中也没有多少可供参考的合同样本。

问题：缺乏针对工作效率的激励和鼓励机制，没有合约性的控制与保障措施，甲方觉得敏捷无法控制所以不想采用。

应对措施：我们针对敏捷外包提出以下几个建议：

• 制定一套合同模版，软件甲方可以用它拟定会用到敏捷方法的软件开发承包或分包，识别里程碑和交付物，并在合同中规定如何鼓励效率提升（比如激励措施等），如何处理违规（比如撤销条款等）。
• 制定一份敏捷承包或分包样本，为敏捷采购提供一套有理有据的条款和条件（包括支付条件和里程碑）。
• 为了描述交付物的形式和格式，制定一套交付物模版，尽量提供电子文档，而不要到供应商的办公室去拿纸制的文件。
• 制定一份法律模版，使客户（或用户）代表根据有限责任保护伞条款作为成员参与到开发团队中。
• 为甲方和合同管理员制定敏捷承包或分包的培训和认证课程，使大家在工作时能够拥抱这些概念。

II. 主要研究成果

因为对于大多数调查过的组织来说敏捷方法是一种全新的商业模式，所以在前文讨论了大家比较感兴趣的“知识点”。很明显，还有许多问题（比如敏捷外包、一定规模的敏捷等）一直困扰着组织，仍然需要一段时间的过渡可能才能解决。鉴于现在已经掌握的素材，我们整理了以下五个主要研究成果，希望在读者采用敏捷方法时能够有所帮助。

1. 敏捷方法最适合用于明确的业务用例，在此前提下实施最大的障碍无非就是向新人解释方法论的用法。
2. 当你转用敏捷方法时最主要的是要改变管理原则。在过渡时期，你需要制定策略、落实计划、调整架构、培训员工、训练管理人员，还需要运行敏捷试点项目，找到如何在你的组织环境、组织商业目标、组织流程和组织历史背景下运行敏捷项目的最佳办法。
3. 某些类型的软件开发项目可能不适用敏捷方法。前文白皮书中曾经提到，那些安全和安保项目可能并不太适用敏捷方法，而适用于其他同样轻量级的方法（比如RUP、TSP等等），因为这些项目会涉及到一些认证资质。另外，如果不解决外包问题就难以在一个采购环境中使用敏捷方法，因为不容易界定任务是否实际完成了。另外，优秀的敏捷专家能帮你做出决策，找出适用的方法、时机和理由，以及对客户（或用户）带来的价值。
4. 由于组织和流程不匹配、缺少项目管理规范，一定规模的敏捷项目一直难以运作，很难处理组与组之间的控制权冲突。为了避免这些问题，我们推荐单一的工程原则，该原则聚拢受到影响的小组，探索真正的跨学科团队的概念,时刻记得通过敏捷思想改进流程，充分利用那些传统项目管理规范（比如项目管理协会在知识体系中[PMBOK]⁷所提倡的那些规范）。在这种情况下，优秀的管理分析师所拥有的敏捷、过程改进以及项目管理的技能、知识和能力会带来一定的帮助，如果他具备你所经营行业和应用领域的相关经验就能带来更加显著的帮助了。
5. 在当前的竞争格局下，转用敏捷方法通常很有意义，主要有三点原因：首先，你可以使用这一套方法论去赶超你的竞争对手，他们极有可能已经准备使用敏捷方法了。第二，你可以使用敏捷方法吸引人才。因为高效的人才希望自己的工作环境能够使用到最新、最好的技术。第三个也是最后一个原因，你可以向客户展示你使用的敏捷技术，向他们说明这就是他们所希望采用的最好的技术。

你可能想要了解更多关于敏捷的信息，比如敏捷的优势和弱点，敏捷投资回报率，这十年的动态和我们关于敏捷软件生产率、成本和质量调查研究相关的细节，我们建议你从[email protected]或从这里订购“敏捷方法定量分析”报告。这份报告在下列十个应用领域中按行业报告了这些敏捷软件生产率、成本和质量的结果。

• 自动化
• 指挥控制
• 金融
• 国防
• 信息技术
• 医疗
• 移动应用
• 软件工具
• 通信
• 电子商务

参考文献

¹ Reifer咨询有限责任公司2013年7月1日发表的《敏捷方法定量分析》No. 7, v1.3。

² Capers Jones2013年6月25日在Namcook起草的《软件方法与结果的并行比较》。

³ Ahmad K.Shuja和Jochen Krebs在IBM出版社2008年发表的《IBM统一软件开发过程参考和认证指南》。

⁴ Watts S.Humphrey在Addison-Wesley在2005年发表的《TSP: 领导开发团队》。

⁵ Henrik Kniberg在2011年在Pragmatic Bookshelf发表的《源自战壕的精益：用看板管理大规模项目》。

⁶ Donald J.Reifer在CRC出版社2011年发表的《软件维护成功秘诀》。

⁷ 点击此处查阅。

致谢

作者非常认可评论者对本文做出的有价值的评论。

许多评论者对本文收集的敏捷项目数据进行了检验，文中也记录了这些检验结果，这些检验证实了此白皮书提供的大量研究成果和结论。

关于作者

Reifer咨询股份有限公司是Arizona的一家股份有限公司，它专门研究软件工程经济、度量与测量、基准管理和经验性分析等领域。自1980年创立以来，Reifer咨询向客户提供了全方位的软件服务,包括准备软件商业策略和案例、开发独立估算、插入度量和测量程序、开发估算模型、指导竞争力分析和执行独立风险评估。该公司具备十年以上的教练经验，指导客户规避大量不利条件，以充分利用敏捷方法。他们曾经帮助过十多个居于财富500强中的公司，帮他们有序地过渡到敏捷方法。联系方式：Reifer咨询股份有限公司，地址：14820 N. Dragons Breath Lane, Prescott, AZ 86305,电话：928-237-9060, 电子邮箱: [email protected].

警告

本文发表了特定主题的官方信息。Reifer咨询公司不对特定内容、表述和暗示做任何担保和承诺，包括商销性担保和特定应法的适用性。另外，Reifer咨询公司不对本文内包含的任何信息的准确性、完整性和（或）有效性做任何担任。最后，Reifer咨询公司在文中提到了若干商品、过程或服务，但这并不代表Reifer咨询公司对它们的支持和认可。

所有商业名称、商标或注册商标均由它们的所有者所有。

查看英文原文：Ten ‘Take Aways’ from the Reifer “Quantitative Analysis of Agile Methods” Study