导图社区 程序员开发过程绩效评估使用度量思维导图
本图是关于程序员开发过程绩效评估使用度量知识的思维导图,一张图带你完全了解相关内容,帮你提高效率,赶紧来试一试吧~
编辑于2023-02-19 16:56:17 广东程序员开发过程绩效评估使用度量思维导图
着手开始
找一个发起人
发起人
组织里能够批准一项程序员度量试验,并且如果试验成功后能支持或授权广泛使用的人
建立焦点小组
决定组织里谁先参与到度量的选择、收集和评审中来
团队里经验丰富和有威望的成员是最佳参与者
可以一人,最好不超过5人
试验成功,扩大到多个焦点小组,直到较大的团队里
保持过程开放
其他人可能提供有用建议
如果焦点小组推荐扩大使用度量,为后续讨论奠定基础
焦点小组的成员选择初始度量和挑选待测量的软件团队
选择试验度量
首选包含与整个团队有关的和感兴趣的度量,三四个即可
胜场
输场
胜场速度
输场速度
罚球
PPW
选择与程序员个体技能和贡献相关的度量
得分
多能
救援
错误
选定软件团队
焦点小组至少一名程序员来自研究的软件团队
研究团队在组织里有象征性,可提高普适性
确定试验研究时间段
一个月太短
一年太长
3-4个月刚好
如果有固定的迭代周期,使用几个迭代作为时段
也可以是整个项目
注意
选择不需要重新记录和收集数据的度量最为简便
不建议初始时选择第6章的度量
进行试验并评估结果
开始收集收据和计算度量
分配给一个/几个人
最难
可以将度量存储在电子表格中或使用其他简单的文档格式
焦点小组至少每月会面一次讨论度量
该度量揭示了之前不知道或不确定的信息吗?
该度量证实了或挑战了现存的假设吗?
该度量可以被团队经理用来改善软件团队吗?如何改善?
该度量能被程序员提高自己的贡献吗?可以学到什么,如何做?
试验完成时,确定潜在效益和相关成就/失败
当事人可决定跟随的可能路径
成功:扩大
部分成功/不确定:继续当前试验,开始新试验
选择新的焦点小组
不同的度量
不同的软件团队
失败:总结并中止
将度量引进团队
渐进
创建一个度量存储系统
是否允许每个人都看到所有度量
作者赞成
扩大度量的使用
废弃需谨慎
建立一个供讨论的论坛
现场会议
隔月/季度一次
保持随意性
在线论坛
案例:7%规则
一个开始使用程序员度量的软件团队将会在他们核心业绩(生产效率和精度)上有至少7%的暴涨
在开发过程中使用度量
团队会议
评估为每个团队收集的关键度量,包括技能、响应和价值度量
不建议每天,应每周、双周或月
将程序员个体度量包含在每个团队的定期评审和规划会议中
将所有项目成功和用户响应的度量包含在所有团队参与的定期组织或部门会议中
尴尬或非生产性竞争意识可能是有益的
避免赞美或指责
项目后剖析
用以评估项目进行期间有效的、无效的和将来可以改善的东西
文档/演示文稿
确定特定管理或过程的改变是否有效的好时机
导师制
度量的一个有用应用是建立或改进软件开发组织里的导师计划
哪些人从导师制中受益,哪些人可能是好的导师
不是擅长某事的人都善于传授经验给他人
确立团队目标和奖励
不只是项目截止时
需要追踪度量一段时间来确定团队目前的水平
决定目标改进量和目标时间表
案例:转机
在绩效评估时使用度量
谨慎
选择适当的度量
价值度量和技能度量有价值
价值度量
价值度量可以在整个评审阶段汇总
可以帮助评估程序员对团队成功/失败的责任
考虑
胜场份额
输场份额
领先份额
与其他同事比较
团队合作
守场
爆发力
战斗力
技能度量
所有的都值得分析
特别有用
得分
多能
火力
助攻
救援
抢断
活动范围
失误
错误
注意擅长/弱势/前后矛盾
与同事相比
自我评价和同事反馈
在准备自我评价或反馈时回顾度量
对其他人提供建议时,查看该人的度量很有帮助
不建议对度量如何使用提供更详细的指导
同事比较
评审直接同事的技能度量和价值度量,能发现评估中强调的关键差别
使用名字产生负面影响
和均值/最大值/最小值比较
为改进设定目标
晋升
非常有用
标志
得分
火力
助攻
救援
抢断
错误
加-减
胜场份额
输场份额
领先份额
进一步采用度量
目的
寻找运用度量的新方式
创立更新和更好的度量
从已有度量中发现实用的新见解
建立程序员度量委员会
寻求更广泛的分配职责和程序员度量领导力的方法
创立正式委员会或鼓励其他人更多地参与程序员度量
创建分析项目
花更多时间分析收集到的数据可能进一步受益
有时间的人少
经理
有足够兴趣和综合分析能力的人,可准许一段时间专注度量分析项目
“草拟”某人执行一个分析项目
主题
开放的
具体的
可能不会得出突破性的结果
雇佣统计人士
案例:相同与不同
用度量提供额外详细信息
通过度量提供的关于离职程序员贡献水平的额外细节,能更好评价现存团队成员能提高多少,或是否需要额外职员
帮助更早的了解这些情况
通过了解情况间的真正差异,避免得出错误结论