分享一些能拿来即用，对工作有帮助的方法

DOD

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

完成的定义

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

具体来说

• DoD 是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况

• 开发产品所需的一系列有价值的活动。比如：编写代码、编写测试代码、通过测试人员验收等

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

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

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

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

• A要B做一个事情，但是A不能定义清楚这个事情的dod那A就是有问题的

扩大自己的上下文

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

程序员在具体的工作中就容易陷入“拿着锤子找钉子”的困境，如何避免这样的问题，需要交流一下是不是可以换个做法，许多困惑可能就烟消云散了。而能想到问这样的问题，前提就是要跳出程序员角色思维，扩大自己工作的上下文

工作中，不同角色工作上真正的差异是上下文的不同， 程序员有时只关注到一个具体的任务，而项目leader，产品经理心目中是整个系统，整个需求的进度。开发中遇到了困难，也许凭借对需求的理解就可把这个困难绕过去。在一个局部上下文难以解决的问题，换到另外一个上下文甚至是可以不解决的！扩大自己的上下文，除了能对自己当前的工作效率提高有帮助，对自己的职业生涯也是有好处的。随着你看到的世界越来越宽广，得到的机会也就越来越多。

任务排序

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

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

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

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

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

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

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

用户story

做需求的时候，通常是先开发一段时间后，再进行测试用例评审，是否可以让测试用例和产品文档先出来，然后再开发呢？

• 或者要产品用 “用户****故事”的方式描述需求

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

拆分任务

• 知易行难，需要多实践和练习

几个tips：

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