《10X程序员工作法》阅读笔记

最近看了一个极客时间的专栏《10x程序员工作法》，分享一些我觉得对工作有帮助的小tips

DOD

工作中和其他人协作，总会有这样或那样的理解差异，开始协作之前，我们要先同步一下彼此的理解，确保之后不会因为理解不一致。弥合差异的方式有很多，有一个比较好的实践，它的名字叫 DoD（Definition of Done，完成的定义）

完成的定义

• DoD 这个概念本身并不复杂，它就是告诉我们怎样算是完成了，尽量减少因为理解偏差造成的各种浪费具体怎么做呢？就是团队在开始工作前，先制定 DoD
• 例子：一个功能的开发完成，表示开发人员经过了需求澄清、功能设计、编写代码、单元测试，通过了测试人员的验收，确保代码处于一个可部署的状态，相关文档已经编写完毕。

具体来说

• DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况。 开发产品所需的一系列有价值的活动。比如：编写代码、编写测试代码、通过测试人员验收等

• DoD 的检查项应该是实际可检查的

• DoD 是团队成员间彼此汇报的一种机制

  • 有时候同步进度的时候，会说这个任务做了百分之多数，其实这个占比很难估计
  • 当我们有了 DoD，做事只有两种状态，即“做完”和“没做完，不会出现一个任务做了百分之XX这个情况

dod其实就是来尽可能消除不确定性，达成共识的思维方式，无论是做需求，还是其他临时做的事情，都可以用到dod的思想。

A要B做一个事情，但是A不能定义清楚这个事情的dod，那A就需要明确好dod

扩大自己的上下文

工作中，不同角色工作上真正的差异是上下文的不同， 程序员有时只关注到一个具体的任务，而项目leader，产品经理心目中是整个系统的运行和整个需求的进度。

程序员大多数时间还是与代码打交道，有时会想用技术去解决一切问题，在具体的工作中有时会陷入“拿着锤子找钉子”的困境，但其实这个“钉子”在整个需求和或项目而言，也许不算是“钉子”。

如何避免这样的问题，需要跳出程序员角色思维，扩大自己工作的上下文
。开发中遇到了困难，也许凭借对需求的理解就可把这个困难绕过去。

扩大自己的上下文，除了能对自己当前的工作效率提高有帮助，对自己的职业生涯也是有好处的。随着你看到的世界越来越宽广，得到的机会也就越来越多。

任务优先级排序

将事情按照重要和紧急两个维度进行划分，也就形成了四个部分：重要且紧急，重要不紧急，不重要且紧急，不重要不紧急。

• 让系统不能正常运行的线上故障，就属于重要且紧急事情，不赶紧解决，就影响公司的正常运营。

• 团队对系统升级改造就属于重要不紧急：改造好，性能也好，可维护性也得到提升；不改造，一时半会也能用。

• 一些临时任务都属于紧急不重要

• 而刷朋友圈则属于既不紧急也不重要。

• 按照时间管理的理念，重要且紧急的事情要立即做。重要但不紧急的事情应该是我们重点投入精力的地方。紧急但不重要的事情，可以委托别人做。不重要不紧急的事情，尽量少做。

当在你自己的上下文确定不了这个任务的 重要紧急程度时，要找你的上级沟通，来协助你排优先级

用户story

是一种描述需求的方式， 一个完整的用户故事大致包含以下几个部分：

• 标题，简要地说明这个用户故事的主要内容，比如：注册用户使用用户名密码登录。
• *概述，简要地介绍这个用户故事的主要内容，一般会用这样的格式：As a （Role）*, I want to （Activity）**, so that *（Business Value）**.*意思就是：作为一个什么角色，要做什么样的事，以便达成一种怎样的效果。其中最重要的是，告诉别人为什么要做这件事，虽然只有一句话，却往往是很多人欠缺的思考，只知做，不知为何做。举个概述的例子：作为一个注册用户，我想要通过用户密码登录，以便我可以使用注册用户才能够使用的服务。
• 详述，详细地描述这个用户故事的完整流程，我们会把操作流程、用户界面等信息都放到这里。比如：用户使用正确用户名和密码登录，就可以登录成功；如果密码不正确，则登录页面提示用户“用户名密码不正确”。基本上，看到这个部分，程序员就可以在心中描绘出这个用户故事的样子了。超出范围的部分，比如：第三方登录不在范围内，这个部分主要是限定人们不要进一步发散。
• 验收标准，这个部分会描述一个正常使用的流程是怎样的，以及各种异常流程系统是如何给出响应的，这是程序员常常会欠缺的思考。它会把详述中很多叙述的部分变成一个具体的测试用例。比如，下面我给出的两个验收用例：正常场景：给定一个注册用户张三，其用户名是 zhangsan*，密码是* foobar*，当张三使用* zhangsan 和 foobar 登录系统时，可以成功登录，登录成功后，跳转到用户中心。异常场景：给定一个注册用户张三，其用户名是 zhangsan*，密码是* foobar*，当张三使用* zhangsan 和 wrong 登录系统时，登录失败，在登录页面上提示“用户名密码不正确”。

拆分任务

知易行难，需要多实践和练习，几个tips：

• 每个任务完成之后，代码都是可以提交的
• 任务分解的关键在于：小。小到什么程度呢？有时甚至可以小到你可能认为这件事不值得成为一件独立的事。比如升级一个依赖的版本，做一次变量改名
• 检验每个任务项是否拆分到位，就是看你是否知道它应该怎么做了
• 按照完整实现一个需求的顺序去安排分解出来的任务。