我想跟踪可用于改进团队软件开发过程,改进时间估算以及检测项目执行期间需要解决的特殊情况变化的指标.
请将每个答案限制为一个指标,描述如何使用它,并投票给好的答案.
http://www.osnews.com/images/comics/wtfm.jpg
投资回报率.
软件带来的总收入减去生产软件的总成本.按总成本的百分比细分成本,并在投资回报率方面隔离最差的最差和最昂贵的区域.如果可能,改进,自动化或消除该问题区域.相反,找到您最高的投资回报率区域,并找到进一步扩大其影响的方法.如果您的投资回报率的80%来自您的成本或工作量的20%,请扩展该特定区域并通过比较最小化其余部分.
成本将包括工资单,许可证,法律费用,硬件,办公设备,营销,生产,分销和支持.这可以在整个公司的宏观层面上完成,也可以在团队或个人的微观层面上完成.除收入外,它还可以应用于时间,任务和方法.
这并不意味着忽略所有细节,而是找到一种方法来量化所有内容,然后专注于产生最佳(客观)结果的区域.
反码覆盖
获取测试期间未执行的代码百分比.这与Shafa提到的相似,但用法不同.如果在测试期间运行了一行代码,那么我们就知道它可能会被测试.但是如果没有运行一行代码,那么我们肯定知道它还没有经过测试.针对这些区域进行单元测试将提高质量,并且比审核已覆盖的代码花费的时间更少.理想情况下,你可以做到这两点,但永远不会发生接缝.
"改进我的团队的软件开发过程":缺陷查找和修复费率
这与已经提交或验证的修复数量相关的缺陷或错误数量有关.
我不得不说这是一个非常重要的指标,因为它给你两件事:
1.代码流失.每天/每周更改多少代码(当您尝试稳定发布时这很重要),以及
2.显示缺陷是否在修复之前,反之亦然.这向您展示了开发团队对质量保证/测试人员提出的缺陷的响应情况.
较低的修复率表明团队正忙于处理其他事情(可能是功能).如果错误计数很高,您可能需要让开发人员解决一些缺陷.
较低的查找率表明您的解决方案非常出色且几乎没有错误,或者QA团队已被阻止或有另一个焦点.
跟踪执行具有估计值的任务所需的时间.如果他们很好,请问为什么.如果他们结束了,请问为什么.
不要把它变成消极的东西,如果任务爆炸或估计不足,那就没问题了.您的目标是不断改进您的估算流程.
速度:每给定单位时间的特征数.
由您决定如何定义特征,但它们应该大致相同的数量级,否则速度不太有用.例如,您可以按故事或用例对功能进行分类.应该对它们进行细分,使它们的大小大致相同.每次迭代,确定实现(完成)了多少故事(用例).平均特征/迭代次数是您的速度.根据功能单元了解速度后,您可以使用它来帮助估算基于其功能完成新项目所需的时间.
[编辑]或者,您可以为每个故事指定一个类似功能点或故事点的权重作为复杂度的度量,然后将每个已完成要素的点相加,并以点/迭代计算速度.
跟踪您找到的错误的来源和类型.
错误源代表了引入错误的开发阶段.(例如规范,设计,实施等)
错误类型是广泛的错误风格.例如.内存分配,条件不正确.
这应该允许您更改在该开发阶段中遵循的过程并调整编码样式指南以尝试消除过度表示的错误类型.