10x程序员工作法 学习笔记

前言

这篇文章是在学习极客时间专栏《10x程序员工作法》后，做出的学习笔记。

工作中应该如何思考：

以终为始

沟通反馈

 

以终为始：遇到事情，倒着想

网上流传着一个帖子，亚马逊 CTO 介绍亚马逊是如何开发一项产品的，简单来说，他们采用向后工作的方法，开发一项产品的顺序为：

1. 写新闻稿；
2. 写 FAQ （常见问题解答）；
3. 写用户文档；
4. 写代码。

任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造（Mental/First Creation），然后才是付诸实践，也就是实际的或第二次创造（Physical/Second Creation）。我们应该在第一次创造上多下功夫，统一集体想象，让目标更明确。

“以终为始”的思维可以帮助我们更好地规划我们手头任务，也可以帮助我们发现过程中的问题。

 

DoD的价值：在做任何事情之前，先定义完成的标准

DoD（Definition Of Done，完成的定义），这个概念本身并不复杂，它就是告诉我们怎样算完成了，尽量减少因为理解偏差造成的各种浪费。

比如一次开发完成，表示：

• 开发人员编写好功能代码
• 编写好单元测试代码
• 编写好集成测试代码
• 测试可以通过
• 代码通过了代码风格检查、测试覆盖率检查。

 

一旦 DoD 确定好了，谁该做什么事、该做到什么程度就一目了然了。

如何更好得使用 DoD呢？

• DoD 是一个清单，由一个个检查项组成的，用来检查工作完成情况。
• DoD 的检查项应该是实际可检查的，比如代码写好了，可以展示代码，单元测试代码写好了，可以进行现场测试。
• DoD 是团队成员间彼此汇报的一种机制。有了 DoD，做事只有两种状态，即 “做完” 和 “没做完”。

 

在做任何需求或任务之前，先定好验收标准

我们都知道，需求是软件开发的一个重要组成部分，但你可能没有仔细想过，不同的需求描述方式，可能会影响程序员对需求的理解。

很多公司的软件开发模式是基于功能列表的，这个列表 “ 规定 ” 了程序员要做的功能，这种方式把一个完整的需求拆成了碎片。不到最后一刻，大部分人并没有一个完整的概念，这也就会在最后关头遇到很多意料之外的问题，结果必然是手忙脚乱。

那么，这个时候验收标准变得极为重要，验收标准不仅仅描述了正常流程，也会关注到异常流程的处理。它给出了这个需求最基本的测试用例，保证了开发人员完成需求最基本的质量。一旦定义好验收标准，大量的扯皮工作就随之烟消云散了。

 

尽早提交代码去集成

持续集成指的是，频繁地将代码集成到主干。

它的好处主要有两个。

• 快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
• 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量

Martin Fowler 说过，”持续集成并不能消除 Bug，而是让它们非常容易发现和改正。”

 

在没弄清楚之前，需求都不做

精益创业：这个名字并不是指导人们创业挣大钱的方法论。它要解决的是面向不确定性创造新事物。

精益创业中的 “精益”这个词，让人们开始理解价值创造和浪费之间的关系。创造价值是每个人都能理解的，但减少浪费是很多人忽略的。所以，精益创业就是在尽可能少浪费的前提下，面向不确定性创造新事物。

既然是面向不确定性创造新事物，我们唯一能做的就是 “ 试 ”。也就是说，当你有了一个新的想法时，就把想法开发成产品投入市场，然后，手机数据获取反馈，看看前面的想法是否靠谱。好想法继续加强，不靠谱的想法丢掉。

既然是试，也不确定想法的有效性，最好的办法就是以最低的成本试。许多软件团队都会陷入一个非常典型的误区，不管什么需求都想做出来看看，殊不知，把软件完整做出来是最大的浪费。

精益创业提供给我们的是一个做产品的思考框架。当产品经理要做一个新产品或是产品的新特性，我们就可以用精益创业的概念检验一下产品经理是否想清楚了。比如，你要做个产品特性，你要验证的东西是什么呢？要验证的目标是否有数据可以度量呢？要解决的这个问题是不是当前最重要的事情？稳了这些，我们能更好地确定产品经理提出的需求确实是经过严格思考的。