生产力测量

除软件行业外的其他行业, 生产率测量是驱动公司成功的正常活动. 让我们来看一个单人绘画公司. 对于画家, 衡量他的生产率在逻辑上是合乎逻辑的 每平方米的工作时间. 可能他想将测量结果分为几类,像使用的工具 (例如. 滚筒 / 刷 / 喷雾/等) 和油漆对象特征 (例如. 墙壁/楼梯/门/等). 当画家建立带有生产率数据的数据库时, 他可以轻松引用新的绘画工作, 只需测量平方米的油漆表面, 乘以适当的生产率，然后将结果乘以他要求的小时率. 如果有 (国际的) 该数据库可提供行业中其他公司执行的油漆作业的生产率, 画家了解他在整个行业中的平均表现，如果他还不是一流的, 他知道要赢得新的油漆工作，他必须不断提高生产率 (因为降低小时费率通常不是一个好主意).

他可以做这一切, 但只有当:

  • 他用一个 标准计量单位, 例如. 平方米. 仅使用标准, 生产率可以比较 (标杆) 并用于 估计;
  • 他用一个 记录工作时间的标准方法. 例如, 午餐时间是否包括在内, 是时候与客户交谈以了解其要求包括/排除的时间?
  • 他用 米有意义的类别 使生产力与众不同. 对于画家, 如果油漆对象可能没有太大关系 (假设是一堵墙) 在别墅或渔夫的房子里. 房子的类型可能不是有意义的类别. 然而, 他使用的工具可能是生产力的主要推动力.

现在, 让我们来看看软件行业.

软件产业与生产力衡量

不幸, IT (和软件) 在使用标准和提高生产率方面，该行业还很不成熟 (性能) 测量, 基准化和持续改进. 业界已经摆脱了很长时间, 因为:

  • 很难衡量 输出 (软件不是物理的东西, 传统的测量仪器无法触摸和测量).
  • 软件项目更像是R&D项目比制造产品. [R&D难以测量. 测量输入相对容易, 但是产出很难衡量，而且天生就无法预测.

现在, 慢慢地，该行业变得越来越透明，客户组织越来越多地要求潜在的供应商根据历史数据来量化其绩效. 这条路, 可以为工作选择最佳的供应商. 请注意，最佳选择通常不是最便宜的选择 (经常导致项目失败…甚至灾难).

标准品

虽然在组织中实施生产率衡量过程似乎很容易, 现实表明，这比人们想象的要困难得多. 原则上, 就像画家, 足以 测量输入 (通常工作时间) 和输出 (测量单位, 单位) 每个软件项目, 而 使用有意义的类别来区分项目, 像技术 (Java / .Net / Oracle / Etc。), 项目类型 (新发展/增强) 和/或实施 (包实施/修改/定制软件).

能够建立有意义的和可比较的生产率指标, 至关重要的是 (国际的) 使用标准. 必须做出许多选择:

测量输入

必须做出的一些决定:

  • 工作时间进/出测量范围, 例如
    • 技术设计, 编码, 单元测试, 系统测试, 其他供应商测试, 范围内的开销;
    • 功能设计, 支持验收测试, 实施活动超出范围.
  • 超时进/出测量范围;
  • 旅行时间, 会议时间, 进/出的间接费用小时数;
  • 如果是包裹, 门户网站/ CMS或其他可配置软件, 可能需要进行单独的工作量注册活动以进行自定义, 设置参数和定制软件不在包装中.

能够分析供应商的生产力, 部门或团队, 努力注册系统应以标准方式实施. 如果选择功能设计时间超出范围, 所有项目都应将其功能设计工作与其他工作时间分开进行注册. 强烈建议草拟标准的“工作分解结构 (工作组)’ 每个项目类型并在工作量注册系统中实施此WBS. 注册工作时间的每个人都应该意识到在系统中正确预订工作的重要性.

测量输出, 应避免的方法

测量输出比测量输入要难一些, 由于软件的无形性质. 许多组织会评估交付的代码源代码行 (地块) 完成后交付的软件产品的数量，并使用生产率指标（例如，每个工作时间 1000 地块. 这似乎是个好方法, 但是实际上，有很多原因不建议这样做:

  • 没有 (ISO或其他) 代码源代码行标准. 结果是产生了不同的自动代码计数工具 (非常) 相同代码的不同结果.
  • 尚不清楚是否有更多代码“好”’ 还是不好'. 源代码行对客户组织没有价值. 功能很有价值. 顾客永不说:”请给我 100000 源代码行”. 没有, 就其所需功能而言，这是功能. 功能越多越好，成本也更高, 更多的sloc可能不是更好.
  • 不同的编程语言 (以及这些的混合) 导致代码结果的源代码行截然不同.

美国的“软件指标专家”’ Capers Jones在论文“软件缺陷的起源和清除方法”中写道 (2013) 位置测量非常不准确, 实际上在软件测量中使用slocs “专业渎职”.

行业中经常使用的其他尺寸度量, 但也 不建议 用于生产率测量:

  • 故事点 (SP) 在敏捷项目中: 一种非常主观的措施，仅在一个团队中具有价值. 与其他团队的比较, 部门和组织是不可能的. 请注意，SP对于计划冲刺和跟踪一个团队的速度非常有用, 但是对于生产力测量，SP几乎是无用的.
  • 用例点 (UCP): 仅在文档包含用例时适用. UCP也是一种高度主观的方法, 特别是在确定技术复杂性因素和环境因素时. 也, 没有编写用例的标准方法, 例如，参见所描述的五个可能的粒度级别 这里.
  • 复杂点: 主观而非标准化的方法来衡量应用程序的复杂性.
  • IBRA积分: 衡量应用程序中业务规则的非标准化方法. 根据说明书使用时, 所有应用的结果均为零.
  • 快速功能点 (实物保护区) (由Gartner): Gartner部署的一种无法与ISO标准化功能点分析方法相比的测量方法. FFPA被认为是一种商业方法，缺乏理论基础并且部分是主观的. 尚未证明该方法比Nesma估计的方法快，也没有证明更准确. 不幸的是，它经常被推向更高的管理级别，而没有必须与之合作的专家的支持。.

测量输出 – 强烈推荐的方法

它是一个 强烈推荐的做法 使用 ISO / IEC标准 用于软件项目的生产力度量中的功能大小度量. 符合ISO / IEC标准的五种功能尺寸测量方法:

  • NESMA功能点 (ISO / IEC 24570);
  • 联合会 功能点 (ISO / IEC 20926);
  • COSMIC 功能点 (ISO / IEC 19761);
  • 马克二世 功能点 (ISO / IEC 20968);
  • 光纤SMA 功能点 (ISO / IEC 29881).

使用这些功能大小测量方法之一进行生产率测量的优点是:

  • 目的, 可重复的, 可验证的, 确定软件大小的合理方法;
  • 实现应用程序所需的功能大小和工作量之间有明确的关系。对此已进行了多次研究和验证。;
  • 客户组织和供应商组织都清楚该措施. 更多功能意味着更多价值, 需要更多的努力和更高的价格;
  • 功能大小独立于技术解决方案和/或非功能要求. 一个应用 500 用Java实现的NESMA功能点与 500 FP. 这样就可以在技术领域进行比较和基准测试，并可以使用历史项目数据 (适当分类时) 评估新软件项目.

有用的数据收集类别

为了能够比较和基准化您的生产率, 使用标准类别从您的项目中收集数据很重要. Nesma强烈建议使用以下定义和类别： 国际软件基准标准小组 (ISBSG) 在他们的数据收集活动中使用.

国际软件基准用户组 (ISBSG) 是“非营利性’ 收集软件行业数据并不断发展的组织, 维护和利用两个存储库: ‘新的发展和改进’ 和“维护 & 支持'. 只有以标准方式收集数据时，ISBSG才能执行此操作. “数据收集问卷”’ 可以从 ISBSG网站 并已经显示了很多定义和类别. 存储库随附的词汇表也很有用.

实施软件生产力测量

所以, 就像上面例子中的画家一样, 可以衡量软件项目的生产率. 请参阅此页面的一些示例.

成功实施软件生产力测量, 强烈建议使用文档“测量基础’ 在列表中列出 出版物.