以终为始：一种结果导向的思考框架。
思维导图
结果导向
-
反直觉的思维方式
做事之前，先想想结果是什么样子。 - 想象的共同体
-
规划和发现
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、发布准备
数据库迁移、发布
