以终为始

以终为始：一种结果导向的思考框架。

思维导图

结果导向

• 反直觉的思维方式
  做事之前，先想想结果是什么样子。
• 想象的共同体
• 规划和发现
  1、“以终为始”的方式，不仅仅可以帮助我们规划工作，还可以帮助我们发现工作中的问题。
  2、践行“以终为始”就是在做事之前，先考虑结果，根据结果来确定要做的事情。

完成的定义（DoD）

• 理解的鸿沟
• 完成的定义
  1、DoD是一个清单，清单是由一个个的检查项组成的，用来检查我们的工作完成情况。
  2、DoD的检查项应该是实际可检查的。
  3、DoD是团队成员之间彼此汇报的一种机制。当我们有了DoD之后，做事只有两种状态：做完和没做完。
• 站在DoD的肩膀上
  DoD是一种思维模式，是一种可能消除不确定性，达成共识的方式。

需求任务

• 需求描述的问题
  需求功能列表：这种功能列表式的需求描述方式，将一个完整的需求敲成了碎片。
• 用户故事
  1、描述
  2、概述
  As a （Role）, I want to （Activity）, so that （Business Value）.
  3、详述
  4、验收标准
  验收标准最重要的一环是异常流程的描述。
  验收标准给出了这个需求最基本的测试用例，它保证了开发人员完成需求最基本的质量。
• 你的角色
  扮演不同角色的时候，我们的思考模式是不同的。
  最好维护的代码是没有写出来的代码。

持续集成

• 集成之“灾”
  所有的小组功能模块开发完成，最后统一召集精英进行代码集成。
• 迈向持续集成

由功能完成再集成到缩短开发时间就集成一次。Daily Build（每日构建）
集成间隔时间足够小的时候，持续集成
持续交付

• “地面上”的持续集成
  持续集成服务器的出现

产品经理

• 产品经理
  面对产品经理提出来的需求，我们必须要有自己的独立思考，多问几个为什么，尽可能的减少掉到“坑”里之后再求救的次数。
• 精益创业
  它要解决的是面向不确定性创造新事物。既然是不确定的，那唯一能做的就是不断的“试”。

• 为什么学习精益创业
  精益创业提供给我们的是一个做产品的思考框架，我们能够接触到的大多数产品都可以放到这个框架内思考。

跳出角色

• “独善其身”不是好事
• 角色的差异
  1、不同的角色工作上真正的差异是上下文的不同。
  2、虽然写的代码都一样，但是你看到的是树木，他看到的是森林，他更能从全局思考。
  3、我并不是靠技术解决了问题，而是凭借着对需求的理解把这个问题绕过去了。
  4、能想到换个角度问这样的问题，前提就是要跳出程序员的角色思维，扩大自己的上下文。
  5、当你对软件开发的全生命周期有了认识之后，你看到的就不再是一个点了，而是一条线。
• 在更大的上下文工作

推演

• 一个技术任务
  以上线的情况思考问题。
• 一次个人回顾
  最后一公里。
  1、先从结果的角度入手，看看最终上线需要考虑哪些因素。
  2、推演出一个可以一步一步执行的方案，用前面考虑到的因素作为衡量指标。
  3、根据推演出来的上线方案，总结要做的任务。
• 通往结果之路
  通向结果的路径才是最重要的。
  对比我们的工作，多数情况下，即便目标清晰，路径却是模糊的。

用数字说话

• 熟悉而陌生的数字
  一些人说，自己靠直觉就能把事情做好，其实这是一种误解，因为那种所谓的直觉，通常是一种洞见，洞见很大程度上依赖于一个人在一个领域长期的沉淀和积累，而这其实是某种意义上的大数据。
  当事情复杂到一定程度时，简单的靠直觉是很难让人相信的。
• 从数字出发
  从数字中发现问题，让系统更稳定。

开发准备

• 需求方面
  1、细化过的迭代1需求
  2、用户界面和用户交互
• 技术方面
  1、基本技术准备
  持续集成、测试
  2、发布准备
  数据库迁移、发布