最近碰巧看到ThoughtWorks的技术雷达第20期，提到研发人员绩效度量的四个指标，即：前置时间、部署频率、平均修复时间 (MTTR) 和变更失败率。关于这四个指标的进一步解释，可以参考这篇文章：《软件交付效能度量——从吞吐量和稳定性开始》。

度量研发人员的绩效是个复杂的问题。很多直接可见的简单指标是无法直接用来做量化分析的。在实际项目运行中，最常见的办法就是主观评价。上面的文章是从DevOps开发方式分析得出的结论，其分析角度似乎更偏向于互联网服务开发，但对于其他类型的项目仍具有参考意义。无论从项目还是从研发人员的角度去考虑，吞吐量和稳定性，或者说“快”和“稳”，都是需要分析的最重要的点。要从这两个角度出发，去寻找对应的简单指标。而不是找一个大而全的度量体系。关于软件度量，ThoughtWorks咨询总监有一本书：《精益软件度量》，对此问题进行了更多分析，可以作为参考。

另一项值得记录的技术，是Lightweight Architecture Decision Records（LADR）。这项技术在18年5月的技术雷达中被列为ADOPT级别。从名字可以看出，这项技术是用来记录重要的架构决策的。很明显，在新项目的开发和旧项目的演进过程中，这项技术有着很重要的意义。以我个人的实践经验来看，在开发新项目的过程中，需要有多方参与，对一些架构关键点进行共同决策。因此在开发过程中，可以将LADR集成在项目文档中。由于其轻量化特征，因此不会对项目开发过程产生明显的阻碍。又由于其对于重要架构决策的背景和讨论进行了记录，因此在后期追溯设计方案时，可以有效的追索到最初产生此设计的根源。

目前为止，LADR尚未有固定的模式，这也是其灵活性的体现。一些可参考的模板可以在这里获取。