程序员度量数据判定方法总结

关于程序员度量数据判定方法总结的思维导图，主要内容有度量可以帮助回答哪些问题、度量数据、案例:双队记。

程序员度量数据判定方法总结

度量可以帮助回答哪些问题

程序员在其核心职责方面做得如何

代码

设计

测试

程序员在其核心职责之外的贡献如何

程序员能覆盖多少领域？

程序员足够主动吗？

程序员创新吗？

程序员处理压力的能力如何？

程序员应对逆境的能力如何？

程序员和他人的互动如何

人员

团队其他成员

团队经理

团队以外的人

度量

是否展示了领导力

是否激励了他们的队友

指导他人的情况如何

理解和遵循方向的情况如何

能协助他人多少

软件团队是成功还是失败

因素

客户响应

质量指标

效率

用户对每个软件发布版的响应是什么

测量响应

采用、选择购买、积极使用

停止使用、测试但决定不用

问题

价格

产品以外的其他因素

缺乏更精确的方法

同竞争对手比，软件做得如何

另一种评估顾客关注度和响应方面的方法

评定相对成功水平提供了额外的输入

每个软件发布版的质量趋势是什么

团队交付新的软件发布版的效率如何

度量数据

关于程序员技能及贡献的数据

生产力

定义

完成工作的总量

关注

编码

设计

测试

测量方法

代码行数LOC

不含注释的语句数NCSS

实现的对象、函数或方法

其他项

发布版库的提交次数

跟踪方式

程序员已完成的分配任务

任务

开发新特性、增强特性或开发或增强已有特性的一部分

设计、调查、编写测试或修复bug

用来组织、规划和管理程序员工作和软件项目的基本单位

建议

将设计、编码和测试作为（单独的）任务进行跟踪

为任务建立复杂度评分体系，并且为每个任务进行评分

不要用估计时间和实际时间作为复杂度

如果任务不能落在复杂度级别范围内，分割或合并

任务完成后对复杂度评分进行调整，以确保准确和一致

多个程序员负责同一任务，处于追踪目的对复杂度进行等分

不跟踪开发阶段发现和修复的bug

如同其他任务一样，分别跟踪生产环境的bug修复

对编码阶段的设计、测试和测试开发工作和编码任务进行合并

如同其他任务一样，分别跟踪独立于编码的设计、测试或测试开发任务

对程序员未能完成任务的次数进行跟踪

如果任务是部分完成的，下调任务的复杂度评分

速度

定义

程序员在单位时间内的生产力

建议

以每周/两周为周期跟踪速度，或使用其他一致的时间间隔。不要使用h/d

用每个程序员在每个时间周期内完成的工作（任务数和复杂度）作为速度的测度

准确性

质量的关键因素，但不是唯一指标

简单分级

建议

对发布后的所有产品问题进行跟踪

按对用户影响的严重程度对每个产品问题进行评分，保持度量的一致性和简单性，并考虑调高“回归”bug严重性

对每个问题影响到的客户百分比进行估计和跟踪

定义细分的产品领域，把每个产品问题分配给相应的产品领域，识别出从事每个领域的程序员

如果一个产品问题分配到多个程序员负责的领域，则等分

不要根据修复这些问题的复杂度来进行评分

广度

关于整体复杂性的关键指标

跟踪

使用和跟踪bug的产品领域相同的粒度定义，确保所有任务都根据产品领域进行了跟踪

持续跟踪程序员在发布版控制系统中的检入，对涉及文件计数，或将源文件和特定产品领域等同起来

建议

定义精细的产品领域

保证每个程序员任务都分配到一个/多个产品领域

用此数据跟踪每个程序员从事的产品领域

乐于助人

跟踪

一个程序员接收到请求后帮助别人的次数

程序员在没有收到任何请求情况下主动帮助他人的次数

报告人

团队成员

被帮助者（最佳）

公开可激励

收集更详细的数据很难，并且没有更多无法从其他地方得到的信息

创新性和主动性

“惊喜”

建议

让团队成员在程序员呈现显著的创新和主动性时报告

要求团队领导为每一个程序员保持这些事件的数量记录

关于软件采用、问题以及竞争的数据

关注与采用

对响应进行跟踪的最基础的指标是使用情况

数据源

核心的软件开发团队以外的数据源

自力更生创建自己收集和测量的能力

对处在评估阶段的用户进行识别和跟踪

区分

不同安装包

用户帐户类型

数据

事务的持续时间

页面访问

事务数

使用时长

集中收集

托管软件

预制的或分发的解决方案

web

email

每个用户的软件使用量的减少也非常重要

停用

取消账户或卸载软件

不再登陆软件

建议

使软件能跟踪和集中报告不同类型的用户的活动以及活动的日期

使软件跟踪和集中报告能够按用户进行汇总，如果可能细化到不同的产品领域或特性

用软件或数据采集系统跟踪和集中报告用户的取消、不再活跃或长时间闲置的情况以及检测到的日期

显著效益

测量

监控

询问

目标

找出你的团队是否成功交付了程序员希望提供的效益

而不是实现了合适的需求或满足了所有的客户期望

是重要目标，但不是此处讨论的

建议

使用软件来测量、汇总和集中报告相关的数据和关键统计数据

表明是否该软件满足了设定的目标

对于不能使用软件度量的效益

确定用户的一个目标子集

询问他们一个具体的判断型问题来确定是否他们获得了预期的效益

用户问题

拥有用户是一回事，让用户满意是另一回事

测量

调查

跟踪客户支持活动

严重性评分

建议

保持对客户支持问题的跟踪，并按照软件领域进行分类

根据客户需要解决问题的迫切程度对支持问题进行评分

竞争地位

跟踪

首要因素：与主要竞争对手的功能比较

客户获取

信心因子

建议

与竞争对手对比的产品特性

与竞争对手对比的客户获取评分

案例：双队记

经验教训

将更高复杂度的任务集中于少量的程序员

一定数量的程序员跨多个产品领域工作

程序员感到挑战并且希望证明自己