在 Reifer 2014 年敏捷方法敏捷定量分析研究中得出的敏捷方法的六个知识点

敏捷方法的六个“知识点”

Reifer 咨询顾问有限责任公司最近发布了一份基准管理报告，它比较了采用敏捷方法的软件开发项目和使用传统计划驱动方法软件开发项目所分别达成的生产率、成本和质量绩效。这份报告分析了 100 家组织 1500 个项目（其中有 500 个采用了各种各样的敏捷方法）十年以上的工作数据。这份白皮书以这份名为《敏捷方法定量分析 1》的报告为基础，简明扼要地总结了七个“趋势和知识点”。如果要阅读比这份“知识点”白皮书更加全面的版本，可以点击此处获得免费版。

知识点——敏捷的应用越来越多

通过 100 个正在进行中的敏捷组织投票显示，日常大约有 65% 的软件开发工作中应用了敏捷。这其中包括有大型的敏捷项目，它们代表了 500 个敏捷项目中的 125 个大型项目。这些大型敏捷项目由超过 75 名专业人员的团队协作交付，他们都是跨地域完成软件产品开发的。很遗憾的是，只有大约 10% 的系统和数字工程工作是由那些构建产品的公司完成的，这其中包括采用敏捷激励过程完成的硬件和软件。缺乏统一的敏捷工程过程制约了方法的效果和它的收益。

知识点——敏捷生产率

在 2014 年交付的产品中，敏捷生产率（以输出 / 输入单位进行度量）继续保持着更高的水准，它比计划驱动的项目或传统项目的经验基准高出大约 10 到 25 个百分点。那些采用了敏捷方法的生产率基准平均每年会持续增长大约 13 个百分点。在过去的十年间，那些采用了敏捷方法的生产率每年会有 10 到 25 个百分点的增长范围。和过去一样，应用领域以及那些影响软件生产率的因素会使这些增长数据有所变化，这些因素包括产品复杂度、过程利用率、项目规模、自动化程度等等。

驱动因子：团队合作的改进、轻量级过程的应用、专注于产出可运行的代码，以及霍索恩效率的可能性 4。

问题：与生产率相关的问题中，当前最受关注的前五个问题是：

• 流程不匹配充斥于敏捷和项目管理基础架构实践之间。
• 试图把敏捷引入实践时，过于强调理论而不是实习。
• 合同的观点高于了敏捷强调的时间和资源的约定。
• 产品与项目管理相混淆。
• 价值的度量，它促使开发人员不是模糊不清和非定量化的。

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

• 理解影响生产率的变数（架构稳定性、产品复杂度、员工技能水平和经验等），当你转用敏捷时要处理好这些变数。
• 在自动化和回归测试上给予更多的关注，版本一旦变更就需要这些工具来重新校验版本的有效性了。
• 收集生产率测量和度量结果，这些数据有助于我们做必要的调整。
• 改革时难免会遇到阻力，建议先运行试点项目，收集这些项目的度量和测量数据，用这些数据说明敏捷是一种更好的商业运作方式。
• 星星之火可以燎原，敏捷的一次成功可以带来更多的成功。
• 使敏捷重点关注能够带来差异化的那些应用的开发。

知识点——敏捷成本

敏捷成本（以开销金额 / 产出单位进行度量）比基于计划驱动项目的传统基准的 3 美元每代码行每年持续下降 9 个百分点。在过去的十年间，敏捷方法的用户能节省成本 10 到 20 个百分点。和生产率类似，这种成本变化在很大程度上也取决于所在的应用领域，并且受许多因素（团队协作、劳动力构成结构、工资水平人力资源政策等等）的影响。

驱动因子：积极性高的团队、比较低的人工费用率、缩减管理费用和报告、简化沟通机制、更加关注产品而不是过程。

问题：与成本相关问题中，最受关注的五个问题包括：

• 关键角色和职责（产品所有者、团队成员、项目管理者等等）。
• 针对敏捷的基础架构、设施、设备和工具的投入。
• 不匹配的支持过程（需求工程、质量保证、项目管理、配置管理、人力资源等等）。
• 与管理实践相关的分包和外包的程度。
• 转换成敏捷实践所需的过渡时间。

应对措施：我们提出以下几个提升成本优势的建议：

• 理解影响成本的变数（这些变数与生产率有所不同），降低成本时你要处理好这些变数。
• 在投入时间详细分析单独的迭代之前，先定义项目时间箱，然后针对项目预估总估时（查阅我们的估时指南 5）。
• 购买正确的工具（敏捷度量工具集、回归测试套件等等）并在开工之前设定适当的机制（作战室、任务板等）。
• 监控项目成本，掌握它与预算的关系。
• 做事的时候应该尽可能遵循节俭和简单的原则（不管是流程还是产品）。

知识点——敏捷上市时间

敏捷上市时间（度量软件从开始到最终交付的总体有效时间）平均值比计划驱动项目的经验基准要短 10 到 50 个百分点，在一年之内交付的项目最多能缩短 20 到 40 个百分点。然而，并不是所有承诺的特性都是要交付的。要遵循的价值观是交付的软件产品应具有那些客户或用户认为重要的特性。其他那些不重要的特性留着以后再处理。与此相反，传统开发坚持一种“要么全做要么全不做”的价值观，从以往经验来看交付时间总是会延期。

驱动因子：专注于可工作软件的增量交付，快节奏的流程，在迭代期内持续开发，在最终投入市场之前增量交付演示版本。

问题：有关于上市时间最受关注的五个问题包括：

• 最初的计划和预算是否合理。
• 计划是否应该是时间箱式的，以确保首先交付那些重要的特性（也就是说，那些能够直接贡献价值的）。
• 在交付时考虑特性可验收的百分比。
• 考虑待办事项中在交付时可接受的特性数量和优先级。
• 考虑待办事项中在交付时可接受的缺陷数量和类型。

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

• 理解影响上市时间的变数，转用敏捷时要处理好这些变数。
• 基于内容为项目准备持续的估算，并调整计划去满足它们。
• 在项目开发过程中监控里程碑达成情况。
• 让团队去控制迭代的时间线。
• 设立对增量时间线和内容的期望。
• 坚持在每个增量结束时演示工件，并争取让客户或用户、市场人员和管理者都参加。

知识点——敏捷质量

敏捷质量（以发布后的缺陷密度进行度量）平均比计划驱动项目的经验基准要高 6 个百分点。需要注意的一点是，首次开始使用敏捷方法的交付质量比传统方法要低差不多 20 到 30 个百分点。但是，今后三年质量将迅速提升，一旦充分转换为敏捷方法 6 差不多要提升 5 到 10 个百分点。同样，质量取决于应用的领域并受许多因素的影响，其中包括质量控制和质保实践。

驱动因子：克服对过程监督的恐惧、为产品设置质量目标、尽早把工程质量强调到产品中、建立质量文化以指导贯穿于整个生命周期的决策。

问题：有关于软件产品质量最受关注的五个问题包括：

• 许多敏捷工作间中把质量保证等同于测试。
• 急匆匆创建可工作的软件，经常早期未对质量予以强调。
• 在开发阶段即不收集质量度量数据，也不把它们用于必要的改进。
• 缺乏质量控制和质保实践的实用。
• 不单独考虑产品的质量保证，而寄希望于在发布之前临时处理。

应该要注意是，混淆了如何在规定的环境中应用敏捷方法和应该由谁来验证软件满足了安全、保密和其他类似的治理需求。

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

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

知识点——敏捷价值

敏捷方法强调通过尽早和持续交付为客户提供软件价值。价值是以财务收益来衡量的，即组织的付出收回了多少回报。然而，如何通过他们的工作量推导出量化的价值，敏捷倡导者却没有给出太多的指导意见。要解决这个问题，论证适用于敏捷方法的商业案例，我们推荐使用经典的度量方式（比如成本 / 收益、偿付分析、盈亏平衡分析或者投资回报）去量化敏捷方案的价值，因为这些度量方式能够被高层管理者充分理解 9 并用来辅助决策分析。

驱动因子：讨论价值时没有按财务范畴予以量化，能够确定应用敏捷方法真实的成本和价值。

问题：有关于应用敏捷方法价值的描述，最受关注的五个问题包括：

• 价值定位与当前客户业务目标相关联。
• 以技术语言来描述价值定位而不是经济学术语。
• 当财务数字发生变化时，获取不到客户最近的财务目标和基础设施。
• 未以客户理解的方式去表述这些数字和需要列举的敏捷方法案例。
• 当由外部检查者执行检查时，价值主张不能保持在详细地审查之下。

应对措施：我们针对价值量化提出以下几个建议：

• 只要有可能，就用数字说话。
• 如果可能的话，那么开发价值主张时就把钱当成公分母。
• 确保你对有形收益和无形收益都做了量化。
• 确保你对重复成本和一次性成本都做了考虑。
• 考虑不想干的已支付成本，因为他们已经实际发生了。
• 与财务人员打交道时，一定要重视资金成本。
• 当你表述的金额数字将被管理者用来判定你的结果是否合理时，把已有的财务传奇考虑进去。

主要研究成果

因为对于大多数调查过的组织来说敏捷方法是一种全新的商业模式，所以在前文讨论了大家比较感兴趣的“知识点”。很明显，还有许多问题（比如敏捷外包、一定规模的敏捷等）一直困扰着组织，仍然需要一段时间的过渡可能才能解决。鉴于现在已经掌握的素材，我们整理了以下五个主要研究成果，希望在读者采用敏捷方法时能够有所帮助。一旦完成转变，公司还应建立起一种运维节奏，使他们持续得到大量敏捷方法的收益，但看起来这一点有些困难。目标应该成为持续推广方法论使方法论得到广泛应用的动力。要达成这一点的技术已经有了，那就是以开发为中心，把最佳实践引入到协同工作环境中的工作里，这个环境拥抱跨领域的方法和产品管理的专注性和原则性。

在过去十年我们分析了数百个敏捷项目，基于我们掌握的信息，我们归纳了以下六个设法从敏捷方法获取收益的相关研究结果：

1. 如果针对敏捷方法的应用有明确的商业案例，那么实施最大的障碍就是向新人解释方法论的用法。
2. 当你转用敏捷方法时最主要的是要改变管理原则。在过渡时期，你需要制定策略、落实计划、调整架构、培训员工、训练管理人员，还需要运行敏捷试点项目，找到如何在你的组织环境、组织商业目标、组织流程和组织历史背景下运行敏捷项目的最佳办法。另外，要度量你的进度，以度量引导你走向成功之路。一个好的方法可以避免走弯路，从以往他人的经验来看，可以邀请敏捷教练和指导者加入到团队中，成为团队的一份子。
3. 你应该识别出某些敏捷方法和其他适用于不同软件开发项目类型的方法。比如，Scrum 能很好地用于小型到中型规模商业项目，而大型的项目似乎选择像 SAFe11 这类的大型敏捷方法会更好。其他那些像统一软件开发过程（RUP）12 和团队软件过程这种重量级方法似乎更适用于那些有严格安全要求的项目（空中交通管制、核能发电厂运维等等），以及那些需要有严格管理等级的项目（比如财务系统等等）。还有另外一个选择，公司可以尝试整合敏捷方法作为公司管理和支持的支柱。
4. 一旦整个软件组织都完成了广泛的转变，公司就要设法建立敏捷运维节奏以持续敏捷的势头。随着他们的转换，他们试图将方法论推广到整个组织，使工程和支持组保持一致。虽然这看起来很简单，但其实不是的。像系统工程和测试之类的组织会倾向于抵制变更，因为他们认为敏捷方式就像在肆意妄为。可以想到的是，充足的时间和工作量以及一些行政鼓励是必要的，能够在所有领域推进敏捷的应用。主要的两个经验教训是，这些组应该尽可能地放到板子上，而且从一开始就应该拥抱这个单一的工程方法论。
5. 由于组织和流程不匹配，混淆了项目或产品管理的重点，大型规模的敏捷项目一直难以运作，很难处理组与组之间的控制权冲突。为了避免这些问题，我们推荐单一的工程原则，该原则拥抱有影响力的小组、充分利用真正的跨学科团队的观念、时刻记得通过敏捷思想改进流程、充分利用那些传统项目管理规范（比如项目管理协会在知识体系中 [PMBOK]14 所提倡的那些规范）。在这种情况下，优秀的管理分析师所拥有的敏捷、过程改进以及项目管理的技能、知识和能力会带来一定的帮助，如果他具备你所经营行业和应用领域的相关经验就能带来更加显著的帮助了。
6. 在当前的竞争格局下，转用敏捷方法通常很有意义，主要有三点原因：首先，你可以使用这一套方法论去赶超你的竞争对手，他们极有可能已经准备使用敏捷方法了。第二，你可以使用敏捷方法吸引人才。因为高效的人才希望自己的工作环境能够使用到最新、最好的技术。第三个也是最后一个原因，你可以向客户展示敏捷技术的应用为它们带来了价值，换句话说，就是增加了生产率、消减了成本、缩减了上市时间、提升了质量以及提供了竞争优势。

你可能想要了解更多关于敏捷优势和弱点的信息，我们建议你到我们的网站上查看我们的博客，为便于你查阅，最近的新闻和最近的报表都总结到了文章最后的表 1 中。

参考资料

1. Reifer 咨询股份有限公司，《敏捷方法的质量分析》编号 8 第一版，2014 年七月
2. Kenneth Rubin，《**Scrum**的本质：最流行的敏捷过程的实践指南》，Addison-Wesley, 2012 年
3. Sondra Ashmore 和 Kristine Runyan，《敏捷方法入门》 Addison-Wesley, 2014 年.
4. Elton Mayo, 《霍索恩和西部电气公司，工业文明的社会问题》, Routledge, 1949 年.
5. Reifer 咨询股份有限公司，《敏捷估算：简单且直截了当》，v1.4, 2014 年六月.
6. 看我们的网站。
7. Reifer 咨询股份有限公司，《敏捷软件质量 **——** 定量分析》，2013 年 10 月.
8. Henrik Kniberg, 《来自于战壕的精益：使用看板进行大规模项目管理》，实用书架, 2011 年.
9. Donald J. Reifer, 《形成软件业务用例：通过数字来改进》 Addison-Wesley, 2001 年.
10. Donald J. Reifer, 《软件变更管理：案例研究与实用性建议》，微软出版社， 2011 年.
11. Dean Leffingwell, 《大规模软件敏捷：针对大型企业的最佳实践》, Addison-Wesley, 2007 年.
12. Ahmad K. Shuj 和 Jochen Krebs, 《IBM 统一软件开发过程和认证指南：解决方案设计师（RUP）》，IBM 出版社, 2008 年.
13. Watts S. Humphrey, 《TSP: 领导开发团队》, Addison-Wesley, 2005 年.
14. 看 这里.

关于作者

Donald J. Reifer是公认的软件工程和管理领域的一位带头人，有超过十五年的行业和政府的先进管理经验。在 1980 年，他创立了两家软件公司，在当时是他们在引领着市场。在此之后，他当过程序管理经理和行业总经理、政府的执行董事以及管理顾问。他的敏捷履历包括：成功管理数个大型敏捷转型项目并具有十年以上敏捷教练和度量专家的经验。

附录A——可用的报告——Reifer咨询股份有限公司

报表标题

说明

日期

十一个敏捷方法《趋势和知识点》

对《敏捷方法定量分析》这篇报表对“趋势和知识点”更加全面的总结。

2014 八月

敏捷方法的定量分析

这份报告比较了采用敏捷方法的软件开发项目和使用传统计划驱动方法软件开发项目所分别达成的生产率、成本和质量绩效。

2014 七月

敏捷度量和测量

这份白皮书为敏捷项目提供了一份度量“购物清单”。另外，它针对流行的敏捷软件开发方法论（比如 Scrum）的应用明确了度量的主张。

2014 七月

敏捷估算：简单且直截了当，V1.4

这份白皮书为读者提供了一套用于评估规模、时间箱的程序，以及针对继续应用敏捷方法的工作量的软件成本评估。

2014 六月

敏捷软件质量——定量分析

这份报告用可靠性、易维护性评估使用敏捷方法开发的软件的质量，以及针对此目标使用已制定措施的适合性。

2013 十月

Reifer/ISBSG/Namcook 联合分析报告：软件规模对生产力的影响

这份 Reifer/ISBSG/Namcook 联合分析报告 (Capers Jones 的公司) 着眼于不同规模下的生产力，展示了存在着规模经济，公司可以随着规模越来越大获得好处。

2013 九月

Reifer/ISBSG 联合报告：软件生产力基准

这份 Reifer/ 国际软件基准组织 (ISBSG) 报告提供了两组基准，订阅者可以用来验证相同应用领域内的结果。

2013 七月

软件生产力、成本和质量基准 *

这份报告针对十八类软件提供了软件生产力、成本和质量基准，并探讨了你可以控制加强的因素。

半年度报告

+ 当前的最新版本、定价和更多的信息请点击这里查看。

查看英文原文： Six Agile Method Take Aways from the Reifer 2014 Quantitative Analysis of Agile Methods Study