[开发测试]工作法：以终为始

阅读整理自《10x程序员工作法》- 郑晔，详细内容请登录 极客时间 官网购买专栏。

如何思考的

软件行业的名著 《人月神话》，他给出了一个统计结果，优秀程序员的开发效率是普通程序员的 10 倍。40 多年过去了，这个数字得到了行业的普遍认同。

如何更高效地工作，怎样才能把时间和精力尽可能地放在处理本质复杂度的事情上，减少在偶然复杂度上的消耗。

思考三个问题：

• 我现在是个什么水平？—— 现状
• 我想达到一个什么水平？—— 目标
• 我将怎样到达那个目标？—— 实现路径

具体问题要怎么问，就可以遵循下面这四项原则：

• 以终为始
• 任务分解
• 沟通反馈
• 自动化

以终为始 就是在工作的一开始就确定好自己的目标。我们需要看到的是真正的目标，而不是把别人交代给我们的工作当作目标。你可以看出这个原则是在帮助我们回答思考框架中，Where are we going?（我们要到哪儿去？）这个问题。

任务分解 是将大目标拆分成一个一个可行的执行任务，工作分解得越细致，我们便越能更好地掌控工作，它是帮助我们回答思维框架中，How can we get there?（我们如何到达那里？）的问题。

沟通反馈 是为了疏通与其他人交互的渠道。一方面，我们保证信息能够传达出去，减少因为理解偏差造成的工作疏漏；另一方面，也要保证我们能够准确接收外部信息，以免因为自我感觉良好，阻碍了进步。

自动化 就是将繁琐的工作通过自动化的方式交给机器执行，这是我们程序员本职工作的一部分，我们擅长的是为其他人打造自动化的服务，但自己的工作却应用得不够，这也是我们工作中最值得优化的部分。

我们不是一个人孤独地在工作，而是与其他人在协作，想要做到高效工作，我们就要“抬起头”来，跳出写代码这件事本身。

大多数人工作低效是由于工作中偶然复杂度太多造成的，只要能够更多地将注意力放到本质复杂度上，减少偶然复杂度造成的消耗，我们“真实”的工作效率自然会得到大幅度提升。

面对问题时，用思考框架问问自己，现状、目标和路径。

如何让努力有效

在做任何事之前，先定义完成的标准（统一共识）。

做事之前，先考虑结果，根据结果来确定要做的事情。

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

定义清楚一个任务完成的标准，期间需要做哪些事情，流程是怎么样的。

DoD（Definition of Done） 的价值

• DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况。
  DoD 的检查项，就是我们开发产品所需的一系列有价值的活动。比如：编写代码、编写测试代码、通过测试人员验收等。什么样的活动是有价值的，也许每个团队的认识是不同的。但如果你的团队认为除了功能代码，其他都没价值，也许这是个信号，说明你的团队整体上是缺乏职业素养的，在这样的团队工作，前景并不乐观。
• DoD 的检查项应该是实际可检查的。
  你说代码写好了，代码在哪里；你说测试覆盖率达标了，怎么看到；你说你功能做好了，演示一下。
• DoD 是团队成员间彼此汇报的一种机制。
  别把“汇报”想复杂了，最简单的汇报就是说一句“这个功能做完了”。当我们有了 DoD，做事只有两种状态，即“做完”和“没做完”。在团队协作中，我们经常会听到有人说“这个事做完了 80%”，对不起，那叫没做完，根本没有 80% 做完的说法。

DoD 是一个思维模式，是一种尽可能消除不确定性，达成共识的方式。

人与人协作中，经常会出现各种问题，根本原因就是，有太多因为理解差异造成的误解，进而浪费了大量的时间，而 DoD 就是一种将容易产生歧义的理念落到实处的方法。

简单的应用场景：

1. 上级分配任务时，应该把完成的指标和工作的边界讲清楚，下级根据要求去做。
2. 下级应不断提高技能，能自己定义DoD，请上级check，毕竟上级不希望每次沟通都占用较多时间。

接到需求任务

验收标准非常重要的一环是异常流程的描述。

采用用户故事之后，在写完主要流程后，再去看一下验收标准，为自己的开发查缺补漏。因为那是标准，达不成就不算任务完成。（用户故事就是一种固定的格式，让需求提出方把应该想清楚的问题想清楚。）

验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量。

如果团队采用用户故事的格式进行需求描述固然好，如果不能，在功能列表中，补充验收标准也会极大程度地改善双方协作的效率。

当拿到一个需求的时候，要做的事不是立即动手写代码，而是扮演产品经理的角色，分析需求，圈定任务范围。

扮演不同角色的时候，我们的思考模式是不同的。

小结：

• 需求，是软件开发中的一个关键环节，一旦需求理解出现问题，势必会造成大量的浪费。传统的功能列表只是简单罗列了要实现的功能，丢失了大量的上下文，会导致团队成员对于需求“只见树木不见森林”。
• 而在比较大的团队中，更是会将一个功能分拆到多个小团队中，每个人看到的只是功能碎片。于是，后来产生了其他的需求描述方式，比如用例和用户故事。
• 验收标准不仅仅描述出了正常流程，也会关注到异常流程的处理，它也是验收测试用例的起点。一旦事先定义好验收标准，大量的扯皮工作就没了。

持续集成

在软件开发中，编写代码是很重要的一环，但程序员的交付物并不应该是代码，而是一个可工作的软件。当我们在一个团队中工作的时候，把不同人的代码放在一起，使之成为一个可工作软件的过程就是集成。

1996 年，Steve McConnel 出版了一本著作《Rapid Development》，国内译作《快速软件开发》。在这本书中，作者首次提出了解决集成问题的优秀实践：Daily Build，每日构建。通过这个名字，我们便不难看出它的集成策略，即每天集成一次。

在 2000 年时，“软件行业最会总结的人” Martin Fowler 发布了一篇重量级文章“Continuous Integration”。后面，以持续集成为基础，进一步拓展出持续交付的概念

虽然我们在同一个时代写代码做开发，但在技术实践层面，不同的团队却仿佛生活在不同的年代。这也是我们要学习的原因。

尽早提交代码去集成。

一个好的做法是尽早把代码和已有代码集成到一起，而不应该等着所有代码都开发完了，再去做提交。
不能再说代码写完了，就差集成了，因为这不叫开发的完成。

关于产品经理

我们必须要有自己的独立思考，多问几个为什么，尽可能减少掉到“坑”里之后再求救的次数。

要做产品，那就需要倒着思考，这个产品会给谁用，在什么场景下怎么用呢？

IT 行业是这样一个有趣的行业，一旦一个问题变成通用问题，就有人尝试总结各种最佳实践，一旦最佳实践积累多了，就会形成一套新的方法论。

从前的 IT 行业更多的是面向确定性的问题，所以，需要更多的是分析。只有当面向不确定性工作时，产品经理才成为一个行业普遍存在的职业。

当产品经理让我们做一个新的产品特性时，我们可以从精益创业这个实践上得到启发，向产品经理们问一些问题，帮助我们确定产品经理提出的需求确实是经过严格思考的。

默认所有需求都不做，直到弄清楚为什么要做这件事。

如何更好解决问题

我们一直在强调“以终为始”。所谓“终”，其实就是我们的做事目标。虽然大家工作在一起，朝着一个共同的大目标前进，但真的到了一个具体的问题上，每个人看到的目标却不尽相同。

有时有的人看到的是需求，而他看到的是一个要解决的技术问题。所以，不同人在对目标的理解上是有根本差异的。

不同角色工作上真正的差异是上下文的不同。

• 比如在项目里打杂，你只能关注到一个具体的任务，而项目主力心目中是整个系统。虽然写的代码都一样，但你看到的是树木，人家看到的是森林，他更能从全局思考。
• 同样，项目负责人的工作，虽然包括在项目组内的协调，但还有一部分工作是跨项目组的，他需要考虑你们项目组与其他组的互动。所以，他工作的上下文是在各组之间，包括技术和产品等方面。
• 部门负责人要协调内部各个组，同时要考虑部门之间的协调。而公司负责人考虑的上下文甚至要跳脱公司内部，进入到行业层面。

程序员总喜欢用技术去解决一切问题，但很多令人寝食难安的问题其实根本不是问题。之所以找不出更简单的解决方案，很多时候原因在于程序员被自己的思考局限住了。

多问几个为什么，交流一下是不是可以换个做法，许多困惑可能就烟消云散了。而能想到问这样的问题，前提就是要跳出程序员角色思维，扩大自己工作的上下文。

• 虽然我不是项目主力，但不妨碍我去更深入地了解系统全貌；
• 虽然我不是项目负责人，但不妨碍我去了解系统与其他组的接口；
• 虽然我不是项目经理，但我可以去了解一下项目经理是怎样管理项目的；
• 虽然我不是产品经理，但了解一个产品的设计方法对我来说也是有帮助的。

当对软件开发的全生命周期都有了认识之后，看到的就不再是一个点了，而是一条线。

当扩大了自己工作的上下文时，我们的目标就不再局限于一个单点，而是会站在更高的维度去思考，解决问题还有没有更简单的方案。许多在低一级难以解决的问题，放到更大的上下文里，根本就不是问题。

想把工作做好，就需要不断扩大自己工作的上下文，多了解一下别人的工作逻辑是什么样的，认识软件开发的全生命周期。

突破了自己只愿意思考技术的限制，世界一下子宽阔了许多。所以，有机会走到客户现场，看到更多公司的项目运作、公司是如何工作的。

机会总是垂青那些有准备的人，尤其在公司规模不大的时候，总有一些跳跃式的发展机会。

做事前先推演

对比我们的工作，多数情况下，即便目标清晰，路径却是模糊的。所以，不同的人有不同的处理方式。有些人是走到哪算哪，然后再看；有些人则是先推演一下路径，看看能走到什么程度。

即便已经确定了自己的工作目标，我们依然要在具体动手之前，把实施步骤推演一番，完成一次头脑中的创造，也就是第一次创造或智力上的创造。这种思想在军事上称之为沙盘推演，在很多领域都有广泛地应用。

在软件开发过程中，我们就假设软件已经就绪，看就绪之后，要做哪些事情，比如，如何上线、如何推广等等，这样的推演过程会帮我们发现前期准备的不足之处，进一步丰富我们的工作计划。为了不让我们总在“最后一公里”摔跟头，前期的推演是不可或缺的，也是想让团队进入有条不紊状态的前提。

想清楚了才能写清楚，它可以说是区分合格与不合格开发工程师的重要区别。软件开发过程中，最常见的例子就是拿到需求后不管三七二十一，上来就开始撸代码，但最后往往返工不断，质量问题层出不穷，而且加班没完没了，这里面一个根本原因就是没有系统地想清楚，但很多人都觉得前期澄清需求、分析设计是浪费时间，只有编码才是真正的创造价值，这就是差距。

用数字衡量工作

一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见（Insight），洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据。

在一些简单的情形下，或者说大家信息对称、知识背景相差无几的情况下，这样的讨论是很容易得到认同的。而当事情复杂到一定程度时，简单地靠感觉是很难让人相信的。

从数字中发现问题，让系统更稳定。

IT 人在通过数据为其他人服务的同时，却很少把数字化的思维带到自己的工作范围内。这也是工作中很多“空对空”对话的根源所在。

问一下自己，我的工作是不是可以用数字衡量。汇报工作加入数字量化。

管理上级

要敢于管理上级，对上级不合理的要求说“不”，这是一个思想上的转变。勇于改变，是有效管理上级的前提条件。

管理上级的预期

领导要临时加其他任务，不要立即答应，客观地说明想做这个调整，你需要放弃的内容是什么，将自己看到的问题暴露给上级，让其根据TA的上下文做出选择，平衡该做的事情。

帮助上级丰富知识

不是每个上级都是经验丰富的，知道所有事情。

在那些他做得不够好的领域，他肯定有许多烦恼。比如，盲目给需求的产品经理，可能也会影响到他对需求的判断。

说出你的想法

如果你有自己的想法和打算，不妨提出来，主动承担一些职责。比如，你接下来打算多学点某方面的东西，那就大大方方地告诉上级，下次有相关的活，考虑一下自己，上级再安排工作的时候，他就会多想想。

更可能出现的场景是，你还没去尝试改变就放弃了，将全部责任都归结于上级的问题。如果你是这种思考问题的逻辑，不论到哪个公司，结果都不会比现在更好。

小结

最佳实践

• DoD，确定好完成的定义，减少团队内部的理解不一致
• 用户故事，细化出有价值的需求
• 持续集成，通过尽早集成，减少改动量，降低集成的难度
• 精益创业，减少过度开发不确定性产品带来的浪费
• 迭代 0，在项目开始之前，做好一些基础准备

思维转变

• 任何事物都要经过两次创造：一次是在头脑中的创造，也就是智力上的或者第一次创造，然后才是付诸实践，也就是实际的构建或第二次创造
• 在更大的上下文内发现自己的“终”
• 通过推演，找到通往“终”的路径
• 用可度量的“数字”定义自己的“终”