第一部分 f-laws 定律
A1 最佳学习方法 A2 PPT 投影 A3 改进个别部分不能改进总体 A4 把成功经验归零 A5 知识分显性和隐性 A6 服从度与创新 A7 应对未来变化，假设比预测好 A8 引导学生自己找答案 A9 如不能容错，大家都尽力少做 A10 难教老人新把戏 A11 乐队指挥更懂管理 A12 行政 / 管理 / 领导 A13 问消费者想要什么没有意义 A14 扁平化管理 A15 智慧= 16x理解 A16 计算机不会比程序员聪明 A17 管理者只追求可衡量的东西 A18 要收集多少变量 A19 对被收购公司的增值比给收购公司的增值重要得多 A20 从外面评价公司比内部更容易 A21 幸福的大家族更需要的是忠诚，而伟大企业更需要的是能力 A22 无论企业多成功，如果不能适应变化，就会像恐龙一样灭绝 A23 下属与经理（上） A24 下属与经理 （下） A25 好奇心 A26 对下属期望越低，得到的就会越少 A27 高层认为他人是非理性的，但其实自己也一样 A28 官僚只有权利说“不可以” A29 是否听取建议取决于与提出者的关系 A30 职位越高越觉得不需要继续学习 A31 专注于组织的“核心竞争力” A32 能用现有的资源做些什么 A33 领袖的必要条件是才华 A34 要跳出盒子思考 A35 已经到了不可能变得更糟的情况 A36 电话会议 A37 电话第二部分 应用场景
B1 敏捷开发如何改善 B2 与高层交流 B3 现场培训 B4 从A3报告到量化持续改进不知道如何衡量自己所追求目标的管理者，最终只能满足于有相关衡量数据的目标。
Ackoff教授（第51条）：Managers who don't know how to measure what they want settle for wanting what they can measure.
Ackoff教授： 许多人追求高质量的工作与生活，却不知道如何衡量，所以往往转而追求“高标准”的生活（如购置房产、车辆），皆因后者易于量化。遗憾的是，他们误以为生活质量等同于生活标准。事实上，进一步提升已经很高的生活标准，通常会降低生活质量。 同样，人们常常误以为产品或服务的质量（难以量化）与价格（可量化）成正比。然而，价格通常反映的只是产品或服务的生产成本，而非质量，而生产成本又通常与组织的浪费和管理的低效正相关。 与经济学家类似，管理者通常因其难以量化而忽视无须付费的工作。然而，正是这些难以量化的工作，如抚养子女、维系家庭等，往往最为重要。经济学家通常关注那些破坏价值的工作，因其成本可量化，这导致价值判断被颠倒了。例如，长期战争虽然提升了国民生产总值，却显著降低了人民的生活质量。 |
成都某软件开发公司采用敏捷开发方式，每两周进行一次迭代。
我询问某开发组长：“每轮迭代会收集哪些度量指标？”
答：“主要就是衡量开发新功能的速度。”
问：“度量开发的速度只能反映出开发的功能数，无法反映开发的质量。你们如何衡量开发的质量？”
答：“代码开发后须首先通过静态扫描，还有内部自测，从扫描和测试结果评估团队的缺陷和代码异味是否超标。”
问：“是否遇到过产品通过验收却在客户使用时出现报错的情况？”
答：“3个月前曾发生过，我与另一名工程师耗费数周，排查了各类原因，最终才找到根本原因并解决。”
问：“具体是什么问题？”
答：“是编码失误，某个开发者没注意到，在open描述满足后未关闭（close）。该缺陷位于某软件模块的宏部分，我们最初审查相关代码时，没有细查宏包，因而没有怀疑代码本身。”
针对这个缺陷分析案例，我们继续讨论，一致认为如果在开发时用脚本编写自动化单元测试，结合静态扫描和核心代码评审，应能有效避免此类缺陷重现。因此，开发团队在每轮迭代中除了收集速度外，还应收集与质量相关的度量。
关键度量指标
领导仅关注开发团队的生产率，所以只要求每周统计有效代码行数。然而，开发团队在收集此类度量时，还会引发诸多问题：
● 代码开发通常涉及代码的复用，在计算代码行数时，如何界定哪些代码行应计入？哪些不应计入？
● 如何收集相关数据？依赖开发者手动统计？如何确保数据可信，防止随意上报？
即使解决了上述问题，代码行数也不会无限增长，初期或有较大改进空间，到了后期想持续优化就不容易了。
更关键的问题是，若管理者仅关注少数“关键”指标，团队便会聚焦于这些指标，而忽视其他度量指标。例如，代码行数（生产率）受质量的影响显著——如果开发没有做好自测、代码评审和扫描，到了系统测试或验收测试时将暴露出大量缺陷，导致大量返工、降低生产率。因此，建议度量的指标不宜太单一。每轮迭代由团队共同收集并讨论度量数据，成员方能清晰洞察自身的状况，才能发挥度量的真正价值。