以终为始，就是在做事之前，先想想结果是什么样子的。以下为极客时间郑烨的10x工作法分享的以终为始的几个准则，希望能在工作上用上一部分。
集体想象-让我们大家想到一块去
赫拉利的《人类简史》中，有一个说法：想象共同体，人类发展的一个重要因素就是”集体想象“。无论是国家、宗教还是法律习俗。
其实，我们做软件的人就是一个想象共同体，这个”集体想象“就是我们要做的软件，任何想象都需要一个载体将其展现出来，而我们编写软件的过程，就是将这个”集体想象“落地的过程。
任何事物都要经过两次创造：第一次在头脑中创造，第二次是付诸实践。相比第一次创造，第二次创造的成本非常大。
所以，我们要尽可能在头脑创造的时候，想清楚我们要做的是什么。像DDD、事件风暴都有助于我们在第一次创造做得更好。
DoD-当我们拿到需求或任务的时候，先定义需求验收的标准
以终为始的思维中，首先要解决的问题就是，”终“到底是什么？一个简单的登录功能，如果不讨论清楚怎样才算是完成，那么就很有可能做出来的东西，别人并不满意。
通常来说，不同立场的人对”终“的理解是不一样的。
开发人员以为，功能只要开发完成，就算完成了。
测试人员认为，功能至少要经过测试，不要出现很低级的错误才是。
项目经理可能还要加上单元测试才行。
产品经理会认为，整个需求测试完成可交付才算完成。。。。。
用户拿到手一看，我要的手机号码登录，你给我一个用户名密码登录！！
DoD(Definition of Done):完成的定义。
如何才能更好地发挥DoD的作用：
- DoD清单，清单是由一个个检查项组成的，用来检查我们的工作完成情况。
- DoD检查项，应该是实际可检查的，只有做完和没做完两种情况。
精益创业-面对不确定性创造新事物
当需求是不确定的，那我们唯一能够做的就是尝试。那么是否能够使用最小的代价去实现这个需求？即MVP(Minimum Viable Product)
下面是精益创业的想法验证框架。
精益创业提出的 开发-测量-认知这样一个反馈循环。
也就是说，当你有一个”想法“时，就把想法开发成”产品“投入市场，然后收集”数据“获得反馈，看看前面的想法是不是靠谱。精益在于，小步伐快速验证。
持续集成-尽早去集成
写代码是程序员的职责，但我们更有义务交付一个可运行的软件。
不要等到所有代码都开发完成再去做持续集成，因为改动量越大，集成过程中出现的问题就会越多，集成的时间也就越长。它们之间会形成恶性循环关系。
业界最佳实践就是，尽早把代码和已有代码集成到一起进行测试。
扩大自己的工作上下文，别局限在一个“程序员”的角色
不同角色工作上的真正差异是上下文的不同。
程序员喜欢以技术实现去思考问题，手里有了锤子，眼里都是钉子。
程序员有自己的盲区，而看不见的原因就在于上下文的缺失。
当你对软件开发的全生命周期有了认识之后，你看到的就不再是一个点了，而是一条线。
单一维度的思考，在多维度思考者眼里几乎是漏洞百出。
在动手做之前，先推演一番
前面讲的内容一致都是看到结果的重要性，但通向结果的路径也同样重要。
对比我们的工作，多数情况下，即便目标是清晰的，路径却多数是模糊的。在动手之前，
将实现路径推荐一番，形成相关的文档一起讨论非常必要。
用数字来衡量我们的工作
可以提炼一些关键的数字来衡量我们的工作，避免个人主观上的判断，避免人们之前“空对空”的对话。
当我们设置了测量工作的有效指标，就可以更有目的地协作和工作。
例如：
单元测试覆盖率
漏洞严重程度
工时填写率
。。
迭代0-启动开发之前，你应该准备什么
总结：
敏捷迭代的思维+以终为始的思维，就是要告诉我们，在开始之前，先想好最终要做成什么样子。在做的时候，尽早去反馈，不要等到全部完成。