部门测量程序员工作方法方案思维导图

本图是部门测量程序员工作方法方案思维导图，一张图带你完全了解相关内容，帮你提高效率，赶紧来试一试吧~

部门测量程序员工作方法方案思维导图

• 度量的目的
  • 3个目的
    • 帮助跟踪和理解发生了什么
      • 主观观察
        • 有时非常有洞察力
        • 但经常带有个人偏见和经验色彩
      • 度量
        • 提供了更科学的、实证分析的历史记录
    • 帮助人们沟通发生的事情
    • 帮助人们关注真正需要改善的事情
  • 度量不是评级
    • 度量一般没有好/坏的分界线
    • 成功的团队由不同的个体组成
      • 个人度量差异
  • 团队动态
    • 更详尽细节和更高的精确度来理解人们的相关技能和贡献
    • 度量的使用可以增强个体与团队之间的满意度
    • 构建健康写作的团队环境
  • 连接活动与目标
    • 最有意义和有用的度量允许将程序员和团队关联到组织目标上
    • 如何做
      • 需要定义软件团队所共享的组织目标
        • 可以精确/近似测量
      • 确定程序员和团队的哪些技能是可以测量的
      • 建立模型或度量将技能与目标关联在一起
  • 好的度量像探照灯
    • 评估度量的好坏
      • 是否相对易于描述和理解？
      • 是否展示了我还不知道的一些事情？
      • 是否清楚的涉及了我关心的目标？
    • 好的度量不只跟踪活动，还可以直接关联到或者产出成就
    • 例
      • 救援/救援失败
  • 假设检验
    • 在假设中真正重要的是什么，不重要的又是什么
• 案例：局部地揭露魔力三角
  • 魔力三角
    • 更多的特性、更紧迫的进度、更高的质量只能同时满足两个
  • 通过度量证实是错的
• 模式、异常点和离群点
  • 模式识别
    • 单个时间段
      • 收集到的一组度量或许会揭示出一些有趣的信息
      • 可能会因此得出一些有趣的假设
    • 多个时间段
      • 收集多个度量可以改进我们的推测
      • 把推测转化为知识
    • 并不是所有模式都是简单化的
    • 以不连续时间间隔收集度量数据是有用的
    • Stephen Wolfran的《A New Kind of Science》
      • 混沌或极端复杂的事物中或许存在一些待发现的模式
      • 可以直接应用到任何领域的统计分析中
  • 异常点
    • 不可解释或不可再现的异常发生事件
    • 定义
      • 不协调性或不一致性，对标准的偏差
    • 经验法则
      • 如果可以清楚地解释为一次性发神的偶然事件
  • 离群点
    • 违背常理的事件，并且可能再现，甚至伴随“可预知”的模式
    • 定义
      • 那种距离整体较远的某个数值
    • 经验法则
      • 如果无法清楚地解释为偶然事件
      • 需要更严密的检验，持续观察，确定是否有意义或是模式的一部分
    • 忽视会限制对成功模式的理解，有必要认真分析
      • Mike Piazza
      • 林书豪
  • 峰值和谷值
    • 局部极大/小值
    • 持续的峰值和谷值
  • 涟漪效应
    • 团队中一个人对其他成员的影响
    • 特定人一起工作所产生的结果
    • 最难识别
  • 可重复的成功
    • 生意的成败和软件开发团队的成败
• 理解度量的限制
  • 并不能给出一幅完整画面
• 案例：意料之外的成功因素
  • 关于打断的度量
• 有价值的数据
  • 一些有用的数据示例
    • 程序员加入团队的时间
    • 团队规模、团队优化和团队建设
    • 按复杂度分类并由程序员完成的任务
    • 程序员协同完成的任务或程序员帮助他人完成的任务
    • 特别紧急的任务
    • 显示程序员超常的创造力、创新和主动性的任务
    • 延期的、失败的或者取消的任务
    • 程序员参与的项目、产品和产品领域
    • 花在任务上的时间
    • 花在会议上的时间，或处理自己中断花费的时间
    • 客户发现的问题，以严重性和复杂度分类
    • 为了客户支持工作而进行联系的次数
    • 购买或使用产品或特性的客户数
    • 使用了产品或特性，但不再使用的客户数
    • 取消或停止使用产品或特性的客户数
    • 维持、获得或直接竞争对手失去的客户数
    • 从产品或特性的改变中获益的现有客户数
    • 从产品、特性或其他完成任务中获益的内部员工数
  • 排除的数据类型
    • 千行代码量KLOC
      • 更像是活动而不是度量指标
      • 难以关联到明确的团队目标
        • 客户接受度
        • 满意度
        • 产品质量
      • 不同编程语言不同
      • 程序员很难认为其与工作业绩和成败有什么关系
    • 开发阶段的bug数量
      • 存在太多可变性
      • 任务的复杂度和花费时间的度量即可包括
    • 产品收入
      • 是商业/产品规划的关键部分
      • 很多软件没有收入
        • 开源软件
        • 内部项目
      • 收入不总与软件和软件开发团队有关
      • 金钱作为度量，容易转移注意力和带来误导
  • 数据选择
    • 更多的是试错
    • 经验法则
      • 选择最容易获得的数据
      • 选择最容易让非程序员解释和理解的数据
  • 数据获取
    • 项目跟踪系统
      • 例
        • VersionOne
        • Greenhopper
        • Rally
        • Microsoft Project Manager
      • 有效数据
        • 任务数
        • 任务持续时间
        • 任务复杂度
      • 粒度
        • 按不同程序员和项目领域每周统计
    • bug跟踪系统
      • 例
        • Bugzilla
        • JIRA
        • FogBugz
      • 有效数据
        • 发布后的bug数量
        • bug的严重性
        • bug的复杂度
      • 粒度
        • 按不同程序员和项目领域每周统计
    • 销售机会跟踪系统
      • 例
        • Salesforce
        • Microsoft Dynamics
        • Siebel
      • 有效数据
        • 机会数量
        • 机会损失数
        • 成交数
      • 粒度
        • 按产品每月统计
    • 用户支持问题跟踪系统
      • 例
        • Salesforce
        • Microsoft Dynamics
        • RightNow
        • Zendesk
      • 有效数据
        • 支持联系数
        • 支持案例数
        • 案例严重性
      • 粒度
        • 按产品每周统计
    • 软件产品（内置适当监控设施）
      • 有效数据
        • 用户激活数
        • 登陆次数
        • 特性使用量
        • 用户错误
        • 性能
      • 粒度
        • 按产品每周统计
  • 观测员和统计表
    • 无法从现有系统获得数据时
    • 选择观测员
      • 团队主管、项目经理或scrum主管
      • 自己
  • 公平性和一致性
    • 公平
      • 精确
        • 系统的可靠性
        • 观测员对所记录的东西的理解
      • 一致
    • 一致性
      • 标准化
        • 移除由于在不同分组和时间里出现的“非主观的”不一致的过程
        • 相当于归一化
      • 校准
        • 移除由于人们在评定时引入的“主观的”不一致的过程
        • 现场会议
• 案例：度量和怀疑论者