什么是最新技术?

如今，敏捷方法因其能够产生很高的客户满意度而变得流行，并已成为软件开发的主流。. 估计和度量咨询收到越来越多的“敏捷任务”，应该为敏捷项目环境提供有价值的建议. 但是敏捷方法与传统的瀑布方法不同，尤其是在估计和度量收集的方式上. 通过文献和互联网对这些主题进行调查可以深入了解差异，扩大我们的知识并增强我们的能力. 发现了如何在敏捷环境中应用现有技术和工具的新方法. 本次调查的结果包括三篇文章. 第一篇论文展示了敏捷软件开发中最先进的度量标准.

一般的软件度量

软件度量或软件度量是来自软件行业的概念. 可以描述如下: 根据定义的原则将值应用于产品或过程的属性，以便代表先前定义的目的进行统计或比较分析.

软件度量通常支持三个感兴趣的领域.

• 规划, 预测
• 监控 & 控制
• 性能改进, 标杆

有许多软件指标用于不同的情况. 普特南和迈尔斯精美地指出了它的全部意义 ‘5 核心指标‘ 用于软件开发: 开发一个 产品 可接受的 质量 具有一定的 努力 在某个 时间. 产品之间的关系, 质量, 努力和时间, 由生产力决定, 因此也必须测量. 我们仔细研究这些核心指标.

产品(尺寸)
测量定量特性, 这决定了产品的大小. 事前或事后完成.
例子: LOC, 功能点, 用例数, 特征数, 用户故事.

质量
产品必须具备一定的品质, 通常通过“每个时间段的缺陷数量”来确定, 平均缺陷时间 (MTTD) 和“缺陷密度” (每个 KLOC 的缺陷数).

努力
以人月为单位，专门用于他的项目.

持续时间
这是项目开始日期和结束日期之间没有中断的周转时间 (例如. 几个月内).

生产率
这是进程的属性, 即. 组织中的软件开发过程. 需要强调的是，这不是一个或多个负责实现的人的生产力! 生产力决定产品之间的关系 (尺寸), 基本形式的所谓软件方程中的努力和时间:

Productivity = product size (with a known Quality) / (effort * time)
(refer to the book for explanation)

这些核心指标支持前面提到的 (主要的) 感兴趣的领域如下.
规划和预测: 生产力和产品尺寸 (以期望的质量) 间接确定成本, 投入时间和精力.
监测和控制: 各种测量作为产品部分, 在某个时间点，与整个产品大小相比，每个交付产品所花费的工作量百分比, 开发过程中发现的错误数量与预期的错误数量相比. 这种测量表征了项目团队的绩效.
改进, 标杆: 通过使用自己已完成项目的关键信息建立历史，可以确定参考点，与未来的项目进行比较. 也可以将自己的表现与其他公司的表现进行比较 (标杆). 通过第二次比较，可以确定组织的表现是否符合市场.

敏捷项目中的指标

敏捷方法与瀑布方法具有相同的起点, 即: 开发一个 产品 可接受的 质量 具有一定的 努力 在某个 时间.

方法和过程可能不同, 但原则上，这是通往同一目的地的另一条路. 毫不奇怪，在敏捷环境中，软件指标占有一席之地. 然而, 瀑布方法有一些显着差异. 首先, 应该说敏捷方法在商业应用的中小型项目中取得了最大的成功.

敏捷度量的重点符合这种有限的规模，主要关注团队, 当前迭代, 当前版本. 较少涉及项目，可能根本不涉及整个项目计划. 简而言之, 重点针对内部. 这一点很重要，因为在这一点上敏捷与瀑布方法明显不同. 敏捷度量和瀑布度量之间的第二个显着区别是使用的度量单位的差异. 产品的敏捷指标(尺寸) 和生产力以主观单位表示 (每次迭代或速度的故事点和故事点) 仅适用于这个项目和这个团队. 这使得团队之间的比较, 不可能的项目和组织. 瀑布指标特别以标准化单位表示，以进行基准测试.

以下矩阵显示了 Putnam 和 Myers 在两种环境中的核心指标.

核心指标	敏捷	瀑布
产品(尺寸)	特征, 故事	FP, CFP, UCP
质量	缺陷/迭代, 缺陷, MTTD	缺陷/发布, 缺陷, MTTD
努力	故事点 *)	人月
时间	期间 (月)	期间 (月)
生产率	速度 (故事点/迭代) **)	小时/FP ****)

*)	故事点是主观的，仅适用于这个项目和这个团队
**)	速度是主观的，只适用于这个项目和这个团队, 无法进行基准测试.
***)	FP和CFP是客观的，是表达功能规模的国际标准.
****)	小时数/FP 被多个估算值使用 & 用于基准测试的度量工具.

 

在 Web 上浏览敏捷社区中的度量标准会产生不同的画面. 一些顾问提出的指标“保持接近 显现 '. 在这个类别中，目标表现为“洞察赞助商的信心”, ‘ 了解客户满意度”和“团队动力”. “敏捷者”的视角’ 看指标, 演示文稿很好地说明了 Mike Griffith 的敏捷指标. 除了“敏捷者”之外，还有专注于传统指标的顾问, 尽管这些指标使用敏捷自己的概念和单元，如特性, 迭代, 故事点和速度.

在这种情况下，一份了不起的文件, 最近的 汉娜·库拉斯的论文. 本文档指出了敏捷为何如此特别以及如何将某些产品指标纳入敏捷项目. 此外，将测量什么以及可以建立什么收益. 由于更高的产品质量和更低的开发成本，这些产品指标的应用可能会导致客户满意度的提高，而这反过来又是对软件开发过程的更好理解的结果.

敏捷的显着特点是缺乏用于基准测试或任何其他形式的外部比较的指标. 产品使用的计量单位 (尺寸) 和生产力是主观的，仅适用于相关项目和团队. 从采购经理或发起人的角度来看，不可能比较开发团队或招标承包商的生产力. 因此，基于合理理由的承包商的选择过程 (生产率) 几乎不可能.

以下总结了在 Web 上遇到的“敏捷”指标; 他们的目的以及如何衡量他们. 请注意，大多数指标都支持“监控 & 控制'. 显然，对于这个感兴趣的领域，敏捷环境与传统的瀑布环境并没有太大的不同.

“敏捷”指标, 网络调查的结果

下表显示了各种“敏捷顾问”在许多情况下根据自己的实践推荐的指标. 这些指标围绕本文档前面提到的关注领域进行分组.

指标 规划, 预测

公制	目的	如何测量
特征数	1. 洞察产品尺寸 (和整个版本). 2. 当状态应用于特征时: 正在进行中的洞察力.	产品包含的功能反过来又包含故事. 功能被分组为“待办事项”, '进行中', 和“接受”.
每次迭代/发布的计划故事数	1. 洞察产品尺寸 (和整个版本). 2. 当状态应用于故事时: 正在进行中的洞察力.	作品在故事中有所描述, 在故事点中量化. 故事被归类为“待办事项”, '进行中', 和“接受”.
每次迭代/发布接受的故事数	跟踪迭代/发布的进度	接受故事的正式注册.
团队速度	请参阅监控 & 控制
LOC	表示已完成工作的数量 (进展), 其他指标的计算，即. 缺陷密度.	根据商定的规则，计算哪个 LOC.

指标 监控 & 控制 (进步和表现)

公制	目的	如何测量
迭代燃尽	每次迭代的性能, ‘我们是否走上了正轨?’.	剩余的努力 (在几小时内) 对于当前迭代 (花费/计划的努力表示绩效).
每次迭代的团队速度	了解特定团队的历史速度. 不能用于比较不同的团队.	此版本中每次迭代的已实现故事点数. 速度是团队和项目特定的.
释放燃尽	跟踪从迭代到迭代的发布进度“我们是否在整个发布的轨道上”.	完成版本中的迭代后“待办事项”的故事点数 (以一定速度外推显示结束日期).
释放燃尽	在给定的时间范围内可以交付多少“产品”.	完成迭代后实现的故事点数超过故事点总数 (发布的). 在时间线上，它显示了“范围完成”的进度.
每次迭代的测试用例数	了解每次迭代的测试工作量. 跟踪测试进度.	每个迭代的测试用例数记录为“持续”, “失败”和“要做”.
周期 (团队能力)	确定流程的瓶颈; 能力最低的学科是瓶颈.	迭代中每个学科可以处理的故事数 (即. 分析- UI设计编码 - 单元测试- 系统测试).
利特尔定律——“周期时间与队列长度成正比”.	洞察持续时间; 我们可以根据队列长度预测完成时间.	工作正在进行中 (# 故事) 除以工艺步骤的容量.

指标 改进 (产品质量和工艺改进)

公制	目的	如何测量
累计缺陷数	跟踪测试的有效性.	在缺陷管理系统中记录每个缺陷.
测试次数	跟踪测试工作并将其与累积的缺陷数量进行比较.	从缺陷存储库中提取数据.
缺陷密度	用“缺乏缺陷”来确定软件的质量.	累积缺陷数除以 1000LOC (KLOC).
每个来源的缺陷分布	决定在哪里分配质量保证资源.	通过在缺陷存储库中记录缺陷的来源并通过自动化工具提取数据.
每种类型的缺陷分布	了解最常见的缺陷类型并帮助将来避免它们.	通过在缺陷存储库中记录缺陷类型并通过自动化工具提取数据.
缺陷周期时间	洞察及时解决缺陷 (缺陷解决速度). 分辨率越快, 将产生较小的“顶部”编码.	缺陷的开始日期减去解决日期 (通常是缺陷存储库中的截止日期).

笔记: 还有“指标”’ 发现该措施“洞察客户的信任 ‘ 和 ‘ 洞察客户满意度”. 然而，对于这些指标，敏捷社区无法解释为什么这些方面特别适用于敏捷，因此不包括在内. 参考我自己的经验超过 30 年这些方面在各种项目环境中进行测量. 或多或少同样适用于挣值法的使用.

结论

通过网络和出版物进行的这次旅行得出以下结论.

1. 敏捷方法中使用的指标和使用的单位 (故事点, 速度) 不标准化. 这使得基准测试成为问题, 如果不是不可能.
2. 当实现的故事点表示为 LOC 时，可以建立与标准化功能大小单位的对应关系 (FPn); 甚至可以确定组织的生产力或团队的生产力.
3. 通过提高对软件开发过程的理解，提高产品质量和降低开发成本，从而提高客户满意度，敏捷方法可以受益于整合产品指标.
4. 在敏捷社区中开发了许多指标, 本质上与瀑布方法中的指标相同, 尽管他们使用敏捷自己的单位和概念.
5. 敏捷方法不承认“功能规模”. 发布的“大小”表示为功能或故事的数量. 测量“故事点”不会产生 (功能性) 尺寸, 而是需要付出的努力.

一些网站的链接

• 大可见 – 敏捷指标和诊断
• 规模化敏捷框架 – 指标
  Dean Leffingwell 的这个网站占据了一个特殊的位置. 规模化敏捷框架是一种哲学和方法论，它将敏捷开发框架为“精益”企业战略. 图表中提到的一些“艺术”指标包含在上表中.
• 软件工程学院 – 七类敏捷指标
• 领先的答案 – 质量项目管理

 

 

关于作者

John Kammelar 是 Metrics 顾问 米特里肯.nl, 这有助于组织获得洞察力并控制软件开发和管理的成本和时间. 他们使用功能点分析来量化功能. 基于此分析，可以对时间和成本做出现实的估计. 作为广泛调查的结果，该博客是三篇系列文章的一部分. 第一部分展示了敏捷软件开发中最先进的度量标准. 所有文章都可以从 米特里肯.nl 网站.

博文代表作者个人观点
而并不一定与官方NESMA政策一致.