I. 敏捷方法的十个“知识点”
Reifer咨询有限责任公司发表了一份名为“敏捷方法定量分析1” 的基准报告，这份报告比较了敏捷方法软件生产率、成本、持续时间和质量与传 统的计划驱动项目的差异。这份报告分析了800个项目（其中有250个敏捷项目） 的工作数据，跨越10年，使用了由60个组织提供的完整工作数据。
读者可以在我们的敏捷研究中找到以下十个“知识点”，我们所参 考的基准报告中记录了相关研究成果。这份报告目前售价795美元，可在此订购， 点击这里可以详细了解国际软件基准组织。
1. 敏捷生产率——敏捷生产率（以产出/单元投入成本进行度量） 高于已交付产品的由计划驱动的项目的经验基准。该经验基准取自10年中在名义 值上下浮动50%的数据，采用敏捷后一年内生产率平均最多能提升10%到20%。但是 ，这些提升取决于应用的领域，并且受许多因素的影响（如劳动力构成结构、产 品复杂度、项目规模等等）。例如，有一些项目需要通过认证的形式（比如飞行 安全和安全认证等），这些项目看起来就不太适用于敏捷方法。Capers Jones的 数据2证实了我们提出的观点，此类项目使用像RUP3（统一软件开发过程）和TSP4 （团队软件过程）之类的结构化过程可以更快地通过认证。
驱动因子：改善团队工作，使用轻量级过程，重点关注产品、可执行的代码和 潜在的霍索恩效应。
问题：开发、维护或组织问题，过程僵化和教条，过于严格的管理，外包问题 ，缺少产品管理的核心。
应对措施：我们提出以下几个提升敏捷生产率的建议：
理解影响生产率的变数（架构稳定性、产品复杂度、员工技能水平和经验等） ，当你转用敏捷时要处理好这些变数。
收集生产率测量和度量结果，这些数据有助于我们做必要的调整。
改革时难免会遇到阻力，建议先运行试点项目，收集这些项目的度量和测量数 据，用这些数据说明敏捷是一种更好的商业运作方式。
在试点项目中调整过程和敏捷方法，找出达成商业目标的最佳方法。
如果条件允许的话，最好让大家在一起工作，以避免在第一个项目中就出现管 理和合同上面的问题。
使敏捷重点关注能够带来差异化的那些应用的开发。
星星之火可以燎原，敏捷的一次成功可以带来更多的成功。
2. 敏捷成本——敏捷成本（以开销/单元产出进行度量）低于以计 划驱动项目的经验基准。该经验基准范围取自10年间在名义值上下浮动100%的数 据。采用敏捷后一年内平均最多能降低20%到40%的成本。同样，这种成本变化在 很大程度上也取决于所在的应用领域，并且受许多因素（包括劳动力构成结构和 工资水平）的影响。
驱动因子：降低人工费用率、降低管理费用、简化沟通机制、更加关注产品而 不是过程。
问题：更重视开发而非规避维护成本、机构重组和角色澄清、僵化的过程、治 理过于严格、外包问题以及不重视产品的管理。
应对措施：我们提出以下几个降低敏捷成本的建议：
理解影响成本的变数（这些变数与生产率有所不同），转用敏捷时要处理好这 些变数。
基于事实做项目估算（通常所有sprints估算的交付物之和少于最终产品应有 的交付物）
监控项目成本、跟踪预算开支。
重视敏捷教育和培训的早期投入。
在工作开展之前选购适当的工具并设置适当的运作机制（战情室、任务板等） 。
转用敏捷时应该尽可能遵循节俭和简单的原则。
3. 敏捷上市时间——敏捷上市时间（度量软件从开始到最终交付 的总体有效时间）比计划驱动项目的经验基准要短10%到60%，在采用敏捷之后平 均最多能缩短20%到50%（不同项目规模会有所差异）。但需要注意的是，一味地 想要加速交付周期常常会遗漏一些需求，使交付的功能和特性无法完全满足客户 或用户需求，从而降低了客户满意度。
驱动因子：关注正在开发的工件，在sprints期内快速开发，在最终投入市场 之前增量交付演示版本。
问题：sprints期内未能完成所有工作承诺，待办任务未能清空，客户或用户 可能没有成为团队成员，管理者可能没参加到敏捷工作中来。
应对措施：我们提出以下几个缩短敏捷上市时间的建议：
理解影响上市时间的变数，转用敏捷时要处理好这些变数。
充分考虑环境因素，把项目作为整体制定务实的时间估算，然后再调整sprint 和增量计划。
在项目开发过程中监控里程碑达成情况。
让团队控制sprint时间线。
设立对增量时间线和内容的期望。
坚持在每个增量结束时演示工件，并争取让客户或用户、市场人员和管理者都 参加。