《高效研发 硅谷研发效能方法与实践》葛俊|(epub+azw3+mobi+pdf)电子书下载

图书名称：《高效研发 硅谷研发效能方法与实践》

【作　者】葛俊

【页 数】 292

【出版社】 北京：机械工业出版社 , 2021.12

【ISBN号】978-7-111-69817-3

【价 格】89.00

【分 类】软件开发-研究

【参考文献】 葛俊. 高效研发 硅谷研发效能方法与实践. 北京：机械工业出版社, 2021.12.

图书封面：

图书目录：

《高效研发 硅谷研发效能方法与实践》内容提要：

内容介绍本书以Facebook（Meta）等硅谷企业的研发经验为背景，结合作者17年的研发经验，讲解了如何实现个人和团队的高效研发。全书主要从以下5个方面对硅谷的高效研发方法进行了总结，提供了非常系统的指导原则和实践指南。（1）研发效能综述主要了讲解研发效能的定义、模型，以及研发效能度量的正确方法。希望借此帮助读者梳理出研发效能的主脉络，构建一幅清晰的知识图谱。（2）个人高效研发实践主要讲解如何提高个人研发效能，具体涉及深度工作、Git、命令行、VIM、工具环境集成等内容，旨在帮助读者提高技术的专精程度和持续成长。（3）研发流程优化主要讲解研发流程优化的基本目标和原则、代码优化、分支管理、DevOps、团队协同等，希望帮助读者深入理解研发过程中的关键流程，以及流程优化的基本原则，从而能够针对自己的实际情况，找到合适的工程实践，让软件开发的整个流程更加顺畅、高效。（4）团队高效研发实践主要讲解团队高效研发实践过程中各关键步骤的高效工程方法，内容涉及研发环境搭建、代码审查、合理处理技术债、开源利弊分析、测试等，同时对研发流程及工程方法的趋势进行解读，希望帮助读者掌握这些具体工程方法的正确使用。（5）管理和文化系统分析了硅谷研发团队的管理和文化，尤其是Facebook的工程师文化，并根据作者在国内公司的具体落地经验，给出推荐的文化引入和建设方法。

《高效研发 硅谷研发效能方法与实践》内容试读

■■■■■■■■■■■■■■■■■■■■图■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■

■■■■■■■■■■■

■■■■■

■■■■

■■■■■■■

■

■■■■■

◆

第一部分6d

■■■■■

■■■

■■

■■■

■■■■■

研发效能综述

■第1章高效学习、实践方法论■第2章研发效能定义及模型■第3章效能度量谜题

:

本书的第一部分是研发效能综述，主要从以下几个方面对研发效能进行全局介绍：

●

■如何高效学习和实践方法论

:

■研发效能模型■研发效能度量

■圆■■■■■■■■■■■

■■■■■■■■程■

◆

■■■■■

■■

■圆

■■

■■■

■■

第1章Chapier/

”专中甲中中4号9行04卡04中49404404华小年

高效学习、实践方法论

在正式介绍本书内容之前，我们首先对如何高效学习、实践方法论进行一些讨论。本书将讲述大量用于提高软件研发效能的方法，希望能够帮助读者真正把它们应用到自己的工作中去，为团队、公司和个人创造更大的价值。所以，高效学习和实践方法论是高效阅读本书的基础。

在软件研发史上，最不缺的就是方法论。以开发方法为例，从敏捷到精益再到看板，层出不穷。但是，这些方法的实施效果却常常不理想。敏捷是一个典型例子。无论是在硅谷还是在国内，绝大部分实施敏捷开发的团队收到的效果并不理想，导致大家对这个概念争议很大，Scrum有时甚至成了贬义词。

相比之下，Facebook、Google等高效能公司并没有强调使用Scrum、看板等工具，研发效能却很高。这是不是说敏捷开发这个方法论本身有问题呢？

事实上，虽然Facebook、Google等公司没有明确提及敏捷开发这一方法论，或者说没有严格使用Scum等框架，但它们在开发流程中却实实在在应用了敏捷开发方法论的精髓比如Facebook的著名口号“Move Fast And Break Things(快速行动，破除陈规)”就包含很强的敏捷意味。敏捷在这些公司的高效研发中具有非常重要的作用。这也恰恰说明一个问题：方法论实施效果不好，往往是因为使用者没有正确使用。

那么，应该如何高效学习、实践方法论呢？首先推荐黄金圈原则。

1.1使用黄金圈原则

在学习方法论的时候，我推荐使用美国著名作家、企业顾问西蒙·斯涅克(Simon

Sinek)总结的Why-How-What黄金圈原则，运用该原则包含的结构性思考方法学习方法论

4第一部分研发效能综述

的思想、原则，并最终选择或者定制适合自己的具体实践方法。

Why-How-What黄金圈原则包括三个同心圆（参见图1-1）：最里面的圆是Why,是这个方法论的目标，也即最终要解决的问题：中间的圆是

How,指的是这个方法论的原则、指导思想；最外层的圆是What,指的是这个方法论的具体实践。

这三个圆从内向外展开，是一个从抽象到具体、从通用到定制的过程。

抽象+具体

口目标有很强的通用性，基本不会有歧义。比如，

通用十定制

敏捷的目标就是快速应对变化。

How

口原则的通用性则差一些，有些原则并非放之四海

What

而皆准。比如，敏捷中有一条原则一“面对

面交谈是最好的沟通方式”就不一定适合所有图1-1Why-How-What黄金圈原则团队。

口具体实践的通用性就更差了，很少有实践可以完全照搬。

在使用一个方法论的时候，一定要从内向外看，时刻确保该方法论切合实际情况，满足具体需求。我们必须首先深入理解这个方法论的目标和原则，然后根据原则因地制宜地选择具体实践。在真实工作场景中，我们往往还需要在已有实践上根据自己团队或者个人的实际情况做些修改才能达到效果，否则将事倍功半。

还是以很容易出现问题的Scrum为例。敏捷的目标是快速应对变化，而Scrum就是用来服务这个目标的。但是，很多团队在使用Scrum的时候，严格照搬Scrum的具体方法，而严格照搬本身就已经违背了敏捷的目标。

与之形成鲜明对比的是，Facebook的众多团队严格使用Scrum的很少，而是一直在大力优化管理、开发等流程来快速应对变化，以最快速度找到并满足用户的最新需求。具体

来说，他们很早就引入了AB测试、灰度发布、每周定时全量代码部署等实践。这些都是

和敏捷方法论相吻合的，也是Facebook业务成功的关键技术支撑。

1.2如何有效落地实践

了解了方法论的目标和原则，选定了具体实践之后，就到了落地实践的时候了。以我看到的情况而言，很多公司在这一步并不顺利：推行一些高效实践的效果并不好，员工的态度有反弹，有的时候还会产生比较大的负面效果，比如产能下降、内部矛盾激化、离职率升高等。

这里举一个具体的案例。国内某一线互联网大厂的一个团队推行全栈开发模式实践，减少测试人员并让开发人员自测。这种做法在硅谷非常常见，如Facebook、Google、

Spotify等高效能公司都在用，并取得了很好的效果。但是该团队在推行了几个月之后，效

第1章高效学习、实践方法论5

果却不好。最大的负面效果是开发人员工作负担增大，负面情绪比较大。有个开发人员的

原话是：“开发人员写单测就够痛苦的了，现在还要写接口测试和UI测试，请问这样的模

式是否合理？是否可持续？”经过深人了解，我发现核心问题在于该团队从上到下强制推行开发自测的方法，而且在减少测试人员的同时并没有添加任何开发人力，使得每一个开发人员的工作量在短期内大幅度增加，团队成员自然会产生负面情绪。

更具体一些，这次落地实践不成功有以下三点原因。

1)全栈的开发模式是从全局上节省时间。比如原先需要15个开发人员、10个测试人员，转型之后，完成相同工作量只需要18个开发人员、2个测试人员。总体减少5个人，但开发人数有所增加。显而易见，这次实践并没有考虑人员数量这方面。

2)引人效能实践，短期一定会有一个适应的过程，需要耐心和时间。这是正常的现象，而这个团队并没有设立合理的心理预期。

3)测试框架不好、流程不畅导致编写测试耗时增加，这进一步增加了开发人员的负担。

针对这些情况，该团队引入了以下解决办法。

1)让一部分测试人员转型，招聘更多开发人员，以调节不同角色的比例。

2)转型期预留一些过渡时间，避免出现在业务交付量不变、开发人员数量不变的同时突然增加太多效能相关工作的情况」

3)在框架、流程、工具等方面投入人力物力，帮助开发人员更高效地自测。

采取这些措施之后，落地过程比原先顺畅了很多。开发人员渐渐体会到开发自测对产品质量、对个人把控全局的益处，越来越喜欢这种做法。几个月以后，开发自测这一高效实践顺利落地，在提高产品质量的同时降低了总人力的投入。

通过这个例子可以看到，落地高效研发实践时，简单粗暴地应用是不行的，需要运用

一定的技巧。通常来讲，可以参考以下步骤和方法。

从全局出发寻找并解决最主要瓶颈

首先要从全局出发，找到系统的最主要瓶颈，并集中精力解决这个瓶颈，再寻找并解决下一个瓶颈。要从全局人手，避免一上来就扎到某个竖井中去。非重点的局部优化即使有效，对整体效能的提升也有限。另外，在解决瓶颈问题的过程中，应该收集数据并将其作为检验改进是否有效的参考标准。

采用从试点到全局的顺序进行推广

可以采用试点的方式进行推广。在高效实践落地的过程中，我们常常需要寻找合适的实践，还需要对这个实践做一些调整和定制。在这个摸索的过程中，先在小范围内试点，第一个好处是，发现问题比较容易调整，能够较快找到合适的实践。

试点的第二个好处是能够降低风险。如果一上来就在整个公司进行推广，那么在寻找最佳实践的过程中走的弯路，整个公司都要体验，这样会造成巨大的浪费。而如果采用试

6第一部分研发效能综述

点的方式，则可以先在小范围内进行摸索，在找到合适的实施方式之后再推广到全公司。虽然试点团队不能完全代表全公司，在将通过试点得到的实践推广到公司范围时常常需要做些调整，但是试点的实践还是可以大大减少这个摸索过程中产生的浪费。

试点的第三个好处是试点团队在适应新的实践之后，可以作为“教练”去帮助其他团队进行推广。有这样一个拥有成功经验的种子团队，实践推广起来会顺畅很多。

自下而上与自上而下相结合

落地研发效能实践与落地其他实践一样，如果能够同时得到管理层和基层研发人员的支持，推广起来就会顺畅很多。换句话说，自上而下与自下而上的推动结合起来最有效。

在缺乏自上而下的支持的情况下，最有效的办法是让公司的决策层看到引入研发效能实践会对公司带来哪些好处，且这样的好处是决策层最关心的。举个例子，如果你用数据证明采用某个发布实践可以使公司服务的宕机时间减少80%，使公司成本降低5%，那么你就比较容易得到决策层的支持。如果你只是口头阐述这个实践能够提高发布效率，说服力会大大降低。

而在缺乏自下而上的支持的情况下，首先不要给基层研发人员太大压力，比如在引入新工作任务时要预留时间。其次要让大家看到个人的收益。比如，全栈的开发模式不仅可以让大家在开发过程中不需要依赖测试人员，从而行动更快，更有掌控感，而且可以让大家对系统有更全面的了解，从而有利于自己的技术成长和职业发展。针对不同的实践找到这些收益，让研发人员了解并真正感受到，团队自然有了自下而上的动力。

对引入新实践的阵痛有心理预期，有全局对策

在引入新的实践时，需要看到除了改进点之外的其他需要调整的地方，因为实践的引人往往不是孤立的。只对一个具体实践进行调整，其他相关措施不能跟上的话，效果肯定不好。上面提到的引人全栈实践就是一个典型例子。全栈是一个实践的点，但是也需要采取增加开发人员等其他措施。

每个具体实践会有特定的相关措施，但一般来说均包括以下几个方面。

口人员结构调整：采取新的实践之后，人员的工作内容有所改动，我们需要对团队的人员结构进行调整。

口计划调整：引入新的实践后，往往会在短期增加工作量，这就需要为这些工作量计算工作时间，进而调整工作计划。

口绩效考评调整：采取新的实践之后，需要调整考评的关注点，从而在管理方面推动新的实践。

口技术设施建设、框架建设：需要投入技术设施、框架等方面的建设来推动高效实践的落地。

总的来说，推广实践的落地是一项充满挑战性的工作。尤其是在短期，在高效实践的效果还不是那么明显的时候，团队容易产生挫折感，甚至半途而废。不过，只要我们从长

···试读结束···