“以终为始”这个主题模块已经全部更新完毕，相信通过对各种实践的深入讲解，你已经对“以终为始”这个原则有了更为全面和透彻的理解。

为了帮助你更好地回顾和复习，我为每个主题模块增设了“划重点”的加餐内容。现在，我就带你一起梳理一下“以终为始”主题的核心要点。

重点复习

在这个模块中，我们学习到了一些行业最佳实践。

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

还学习到一些重要的思维转变。

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

实战指南

在每一篇文章的结尾，我们还将全篇内容浓缩为一句实战指南，希望你可以迅速上手，把“以终为始”的原则运用在实际工作之中，我们一起来回顾一下这些实战指南。

  • 遇到事情，倒着想。 — 以终为始：如何让你的努力不白费？
  • 在做任何事之前，先定义完成的标准。 — DoD 的价值：你完成了工作，为什么他们还不满意？
  • 在做任何需求或任务之前，先定好验收标准。 — 接到需求任务，你要先做那件事？
  • 尽早提交代码去集成。 — 持续集成：集成本身就是写代码的一个环节
  • 默认所有需求都不做，直到弄清楚为什么要做这件事。 — 精益创业：产品经理不靠谱，你该怎么办？
  • 扩大自己工作的上下文，别把自己局限在一个“程序员”的角色上。 — 解决了很多问题，为什么你依然在“坑”里？
  • 在动手做一件事之前，先推演一番。 — 为什么说做事之前要先进行推演？
  • 问一下自己，我的工作是不是可以用数字衡量。 — 你的工作可以用数字衡量吗？
  • 设计你的迭代 0 清单，给自己的项目做体检。 — 启动开发之前，你应该准备什么？

额外收获

在这个部分的最后，针对大家在学习过程中的热门问题，我也进行了回答，希望你懂得：

  • 作为程序员，你可以管理你的上级；
  • 拿老板说事的产品经理，你可以到老板面前澄清；
  • 喜欢无脑抄袭的产品经理，让他回去先想清楚到底抄的是什么；
  • 分清楚需求和技术，产品经理和开发团队各自做好各自的事。