如何量化技术治理、代码质量的效果？
首先得明确做公共的工作是一定要量化的，只有品味甚至情怀是走不远的。技术的沉淀往往是一步步来的，但是业务的目标却通常很短而且易变，比如先做DAC上升，后面又强调马上GMV上升。DORA (Developer Operations Responsibility Agreement)定义的四个关键指标:
- 变更前置时间
- 部署频率
- 平均恢复时间 （MTTR）
- 变更失败率
下面是建议的一些基本衡量原则：
- 衡量团队效率，而不是个人绩效。
- 衡量成效而不是产出。
- 查看随时间推移的趋势，而不是比较不同团队的绝对值。
- 用看板的数据开启对话，而不是就此结束。
- 衡量有用的东西，而不是容易衡量的东西。
- 工单数
- 测试bug数
- 测试bug 性质
Scrum
在我的理解里，scrum 希望达到的是小团队战斗力最强的模式，那么其实一个有价值的项目还是应该拆成各个任务，然后大家都参与。这样做有助于知识在团队中间的传递。 那最后绩效怎么评判呢? 或许代码是一个判断标准，但也会出现趋同性。代码或者技术的判断本身不够准确，有时也缺乏说服力，比如其实架构设计，技术调研占了很大比重。阿里没有推广scrum,可能和361制度以及对应相差巨大的待遇有关。 我看了一些讲scrum评判绩效的文章。总结来说, 理想的scrum团队是自组织，自驱动，团队，理论上没有上下级之分，也没有绩效评估。在实际践行scrum中，相比考核每个人被分配任务的交付绩效 转变为考核每个成员对自己承诺的已经有共识的工作履约的符合性。