《软件研发效能提升之美》读书笔记

目前各公司都非常重视效能，也投入团队人力去研发或者推行。作为IT从业者，有必要去关注软件研发效能，它与我们的工作日常息息相关。这里将笔者阅读本书的一些感触比较深的记录下来，作为学习笔记。

1. 研发效能的提升并不一定都有绑定到敏捷开发实践上，事实上，对于那些需求明确并且稳定的项目，传统的瀑布模型依然是最佳的选择，只有那些需求变更频繁的项目才是践行敏捷实践的最佳选择。因此，敏捷对传统瀑布而言并不是取代，而是互补。

不能为了敏捷而敏捷，敏捷也不是银弹，还是要看具体的项目，先有工程实践后有敏捷，但即使是瀑布模型，也可以借鉴敏捷的思想，模型不是僵化的，只要能提高项目开发效率，质量，都可以借鉴应用。

2. 很多横向跨部门的流程优化和整合必须借助管理层的力量才能有效地向前推进。

这个原因有很多，其中有一个原因是目前很多都是面向KPI工作，这也没办法，只要不是其KPI，你向其他部门要求协作或者推进某些工作就会无比困难。这时候，只有领导层介入了，否则是推不动的。

3. 以后的决策一定会基于数据来开展。效能提升实践的效果衡量也会高度依赖于数据，通过收集存储研发各阶段的各种过程数据，实现基于研发效能大数据平台的决策体系。

数据的准确性比较难保证，只能参考

4. 让人们意识到自己正在被关注时，会不自觉去改变自己的某种行为。
5. 渴望尊重和欣赏，是人性的需求之一。
6. 软件生成作为智力密集型活动，掺杂着大量人的因素，很难严格地标准化。

软件质量能通过效能进行衡量吗，软件质量是典型的很难进行标准化衡量的）

7. 传统组织的特质是层级制的结构，用全力与管理来维持运作，每个个体完成专项工作，对结果负责。而敏捷所倡导的自组织，则是用责任和目标作引导，建立自己的团队的规则，它是基于承诺的，而非基于管理和监督的。
8. 一个群体具备三个条件时拥有自组织能力：自治、自我超越、正向交互。
9. 敏捷团队的所有角色需要朝着共同的目标前进，荣辱与共。在实践上，尽量避免针对不同的角色制定可能会产生冲突的KPI，比如测试人员制定Bug数量的KPI，针对研发人员则制定相反（解决Bug数量）的KPI。
10. 当决策者试图以一个事物的客观测量指标作为指针来实行政策时，这一指标就再也不能有效测量事物了。

比如，所在单位有一次通过率的指标，因为有这个指标的存在，所以大家在拆分任务的时候，会不自觉的进行多拆，只为了数据好看，不上黑榜

11. 应以客观、理性的姿态对待度量这件事，用度量来指导改进，而不是生硬地将度量指标加入KPI中，以期达到完美的效果。
12. 持续集成是DevOps中最核心的组成部分，通过频繁地提交代码、频繁地编译代码、频繁地构建项目、频繁地执行单元测试，不断高频集成，贯彻快速失败的原则，尽可能早地收敛问题。
13. 持续测试需要确保软件代码的每一次提交都能够被及时验证，并输出完整的质量反馈。