上周又和朋友聊起了质量内建与效能提升相关的话题，仔细想想，好像很少把这两个话题放在一起思考，其实，质量和效能是 “既要、也要” 的关系，效能的提升能够将软件研发中的风险更快、更及时地暴露出来，同时减轻团队负担，反过来又能提升质量本身。所以实际上可以放在一起来看。
在《从一个小角度观察敏捷实践》一文中，我曾经提到过，可以通过缺陷的发现时间节点来判断团队是否是在做敏捷迭代，还是小规模的瀑布。核心思想来自于自己的思考：研发发布了一段代码后，需要多久才能知道自己的代码质量如何，是否会影响到其他的业务功能？在传统的研发模式下，研发的代码合并主干后，要很久才能得到反馈，因为依赖测试人员的验证。而在敏捷的模式下，我们希望这段代码能够快速地被验证，获得质量反馈。这不也正是研发效能中所提倡的么，不管是本地验证、集成 CICD 还是各类专项测试，都是为了尽快得到这个反馈。
如上图，我们把重要性和紧迫性关联想来，画出如上的象限图。在理想的情况下，我们希望把更多的时间放到 “未雨绸缪象限” A 当中，去思考团队未来的发展，去思考如何通过更好的方法论或者技能去提升效率或者构建质量。但现实的情况是，多数情况下，我们会把更多的精力放到 “救火象限” B 象限中，感觉每天都在忙着很紧急的事，陷入无尽的 “很忙” 旋涡中。如果你的团队一直处于 B 象限中，其实很难去保证质量，越急越错是很常见的事件。所以需要团队中有人去思考如何改进，如何提升效能，让团队从 B 象限中释放出来，做更多有意义的改进，来反哺产品质量。
“信息熵衰减对研发效能的影响是巨大的，要想方设法将信息传递的效率提升上去”
在以前，我们是通过文档来沟通和沉淀信息的，需要写很细致的需求文档、概要设计、测试用例等等。因为我们认为文字是很有力量的，能够准确的传达编写者的意图。但实际上大家对于文字的理解又有自己的想法，随着传递人员的增加，信息熵衰减会越来越严重。导致信息不对称，带来研发上的修改甚至返工。
现在我们提倡的测试左移、看板方法等形式，都是希望能够尽快对齐信息，并把信息透明化，让团队可以随时看到自己想要的信息。减少信息熵的衰减。
“自解释的代码不是无注释和无文档的代码，而是伴随着高信息熵的代码体系。内容简洁合理的注释与文档，同样也是优秀代码的一部分，能够给效能的提升带来帮助”
代码注释其实非常重要，现在大家更多的提倡的是编写自解释的代码，更规范命名，而忽略了注释的编写。没有注释的代码，会给后期的代码维护和修改带来不便，进而影响整体的研发效能。
不论是敏捷实践，还是研发效能的提升，对于团队的意义都相当的清晰。这里不再赘述。对于个人而言，敏捷实践和研发效能的提升，是解放了个人，还是毁灭了自己？团队如何去向成员传递这个价值，是我一直在思考的问题，也问过很多人，现在基本上是想明白了。
对于团队来说，我们不单单需要去宣导理论层面的东西，还要有更为具体的落地规则，让成员先动起来，让成员养成习惯，形成团队惯性。个人能理解最好，如果不能理解，那就被动接受。不要期望每个人都有学习的动力和意愿，改变他人其实是很难的，也是不受控的。团队需要把更多的精力放在那些可控的事情上面，比如制定规则，比如提供工具或者方案。
对于个人而言，如果你有主动改变的意识，那就去学习相关的知识和技能，尝试做出改变，因为能力的提升是自己的。不论的是质量观的改变，还是具体研发效能的提升，都会给你后续的职业生涯带来帮助，现在团队有这样的要求和氛围，远比你单纯的自己去学，要高效得多。个人从团队中的收获不应仅仅是薪酬，还需要从团队中获取到更多有利于提升自己的东西。
PS：部分观点来自于《软件研发效能提升之美》一书，推荐大家看看。
原文链接：https://mp.weixin.qq.com/s/WdHoGmJpSo9l0-SWZF6URQ
