1.1另一个角度看“提高软件工程生产力”
所谓另一个角度，是指从社会学的理论中找到提高软件工程生产力的理论基础。
如果将软件工程看成软件的生产过程，软件工程师是这个生产过程中的一种劳动者，知识是这个生产过程中的劳动对象，我们就会发现，这就是马克思的生产力理论三要素。
生产力三要素是劳动力、劳动资料、劳动对象，其中劳动资料和劳动对象构成生产资料
我们根据这三要素来思考如何提高软件工程生产力。
生产力三要素分别指的是什么？
劳动力：一般意义，指工作人群，通常指在一家公司、各个产业乃至某个社会工作的人，多指体力劳动者，但通常不包括雇佣者（老板）和管理层。
劳动资料：也称劳动手段，是在劳动过程中所运用的物质资料或物质条件
劳动对象：是指劳动本身所作用的客体，比如耕作的土地、纺织的棉花等
在软件工程领域，生产力三要素又分别指的是什么呢？
劳动力：通常将软件开发工程师、测试工程师认为是劳动力。然而，当他们不在工作状态时，就不能称其为劳动力，只能成为劳动者
劳动资料：严格意义来说，办公场所、座椅、生产工具等都被称为劳动资料。本书主要讨论的是生产工具。笔者从硬件、软件的角度对生产工具进行了分类
硬件：开发时使用的电脑、机械键盘、灵敏的鼠标、网络速度等。
软件：IDE、构建工具（Webpack、Maven）、协作工具（Jira）、部署工具（Ansible。Puppet）等。
劳动对象：不像制造汽车，在开发软件时，拉动对象则是看不见、摸不着的知识。笔者将软件工程中的知识分为业务知识和技术知识。
在理解了生产力三要素后，如何根据此理论来提高软件工程生产力呢？我们分别讨论。
1.1.1 从劳动力要素考虑提高软件工程生产力
如果能招到比一般程序员生产力高10倍的程序员，并好好利用，就可以提高生产力。如果这个程序员的生产力比一般程序员高10倍，那么通常意味着其工资也要高10倍。
另外，不论招到什么样的程序员，管理者都要关心的是，如何帮助劳动者达到最佳工作状态，以产出更多的劳动力。不在工作状态，就不能称之为拉动力，只能称为劳动者。也许，那些经常随意打断程序员的管理者需要反思一下了。
另外，注重培养员工的公司，不仅可以提升员工生产力，还可以提升公司的整体生产力。
1.1.2 从劳动对象要素考虑提高软件工程生产力
如果将软件生产过程看成是无形的知识具化为有形软件的过程，那么产品经理需要将想法（一种知识）具化成原型，美工和交互设计师理解产品经理的想法后，将自己的想法具化成设计稿，然后再将自己理解及想法（又是一种知识）传达给前端开发人员。
接着，前端开发人员和后端开发人员又沟通接口的设计（还是一种知识）。。。可以看出，要提高软件工程生产力，知识的流通效率起着很关键的作用。所谓知识的流通效率，指的是让知识从一个人的大脑流动到一个（群）人的大脑的准确性和速度
所以说，沟通能力在软件工程领域十分重要。
我们甚至可以将一些需要重复操作的知识，具化成一个个工具或者模块。这无疑也是提高生产力的方法。这也就等于告诉我们，在管理软件生产过程时，要主动去识别那些需要重复操作的知识。
如果更深入的思考，你会发现对于工厂里的生产流水线，如果工人辞职了并不会带走什么。而知识存在于人的大脑里，人辞职了，就意味着把公司的劳动对象带走了。这对团队、公司是一大损失。想想公司通过发放工资生产出来的劳动成果，就这样被轻而易举的带走了。
那怎么解决这个问题呢？根据劳动力要素，应该尽可能留住这些带有关键知识的人；根据劳动对象要素，应该尽可能提高同一知识在团队中的携带人数。
那怎么做呢？敏捷实践中的站会，结对编程以及看板的应用，都是增加知识流通效率的手段，从劳动对象要素考虑提高软件工程生产力。
1.1.3 从生产工具要素考虑提高软件工程生产力。
从生产工具要素考虑提高软件工程生产力，这似乎不要多谈，大家都知道挖土机比铁锹更具有生产力，然而很多管理者还给程序员使用低配置的电脑。
低配置的电脑会导致程序员无用的等待，比如打开IDE需要等两分钟，多打开两个窗口就卡顿等。
我们算算账。加入一个2万元每月工资的程序员，工作22天，每天8小时，那么每小时就是113.6元。假如程序员每天因为打开程序慢、网络慢、编译慢等而等待的时间总和为0.5小时。那么这0.5小时就属于浪费的，总共约57元，这意味着一个月会浪费1254元。
这只是一个程序员一个月的浪费，还没有算其他的人。虽然计算有些粗糙，但是能反映问题，相对于程序员的工资成本，电脑的成本真的不算什么。
说句题外话，这样计算并不是在压榨员工，而是在8小时范围内计算着如何提高公司整体生产力。
从另一个角度来看，作为软件开发团队的负责人需要深入“开发现场”去了解，当前的生产工具是否变成提高生产力的阻力。生产工具，除了电脑还包括网络、构建工具，IDE等。
1.1.4 生产力三要素的意义。
总而言之，比起管理成功学的心灵鸡汤，从生产力三要素的角度来看，软件工程的意义在于为我们提供了更多的可操作性。管理者可以将生产力三要素作为理论基础，有据可依的来提高生产力。
话说回来，如果你是那位看到“程序员在椅子上打斗”的经理，你会怎么办呢？
从生产力三要素的角度看，你要问平均编译时间是多久，为什么这么久，进而从三个要素发问：
*生产工具是电脑太慢了？是编译工具本身太慢了？
*劳动力（程序员的能力）：是构建逻辑写的不合理？是编译过程中的某个阶段的问题，影响了整体编译速度？
*劳动对象：是不是缺少对当前构建工具（技术知识）的了解？
1.2 Jenkins介绍
买这本书的大多数读者，可能对Jenkinss都已经有了一定的了解，至少知道他大概是做什么的，所以，本书像网络上的大多数文章那样介绍Jenkins是什么显得有些多余。
笔者根据自己对Jenkins的理解，给出另一种介绍：
* Jenkins是一款使用Java语言开发的开源的自动化服务器，我们通过界面或Jenkinsfile告诉他执行什么任务，何时执行。理论上我们可以让它执行任何任务，但是通常只应用于持续集成和持续交付。*
从生产力三要素来看，Jenkins属于劳动资料要素下的生产工具。
使用Jenkins能提升软件工程生产力的根本原因就在于它提供的是一个自动化平台，一个团队引入了Jenkins，就像原来手工作坊的工厂引入了生产流水线，由于知识的特殊性，它还能帮助我们将知识固化到自动化流水线中，在一定程度上解决了知识被人带走的问题。
我们使用Jenkins的过程，有如设计软件生产流水线的过程。
1.3 Jenkins与DevOps
在行业内，DevOps的标杆Amazon WebServices（AWS）这样定义DevOps（http://aws.amazon.com/cn/devops/what-is-devops/）：
DevOps及文化理念实践和工具与一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快的发展和改进产品。这种速度使组织能够更好地服务于客户，并在市场上更高效地参与竞争。
是不是可以理解为能帮助组织更快的发展和改进产品，可以提高组织高速交付应用程序和服务能力的都可以称自己为DevOps？
AWS给出的定义似乎没有可操作性，而维基百科给出的定义可操作性或许多一些。
DevOps（Development和Operations的组合）是一种重视软件开发人员（dev）和IT运维人员（Ops）之间的沟通合作的文化、运动或惯例。通过自动化软件交互和架构变更的流程，使得构建、测试、发布软件能够更加快捷、流畅和可靠。
看到这里恐怕又有人站出来说这个定义不够全面啊，正因为devops的定义没有标准，所以就 devops的定义到底是什么？大家吵得不可开交，但是可以注意到，这些定义都是在给我们一个承诺：能更快、更好的交付软件。大家争吵的只是如何兑现这个承诺，那么问题来了，假如最后兑现不了这个承诺呢？留给读者思考。
对于如何兑现devops的承诺，大家可能又有很多话说了，但是在谈到真正要落地DevOps时，基本上都会谈到jenkins，这是说明Jenkins能帮助我们很好地兑现DevOps的承诺。
1.4 本章小结
如何提高软件工程生产力，软件行为从来不缺少新概念，但是按他们所研究的实践真的能提高生产力吗？我们需要思考他们的理论基础是什么，这才是关键。
本章的内容过于个人化，笔者没有创新创造新概念，而是以原来的已存在的生产力三要素作为理论基础，思考如何提高软件工程生产力的。同时简单介绍了Jenkins以及它与devops之间的关系。
总之，希望能给读者带来一些新的思考。