开篇词
工作之中有两种复杂度：本质复杂度和偶然复杂度。
本质复杂度是解决一个问题的时候，无论如何都要解决的事情。偶然复杂度是因为选用的方法不当而导致要多做的事。
作者认为的四个原则：
- 以终为始
- 任务分解
- 沟通反馈
- 自动化
- Where are we?（我们现在在哪？）
- Where are we going?（我们要到哪儿去？）
- How can we get there?（我们如何到达那里？）
需要从上至下, 形成一个业务和能力树, 先对整体scope和方向都有了解和分析, 然后对每一点都可以不断的扩展其细节.
- 以终为始: 确定真正的需求, 而不是别人交代的需求; 确定需求的价值, where are we going?
- 任务分解: 把任务分解成微任务的形式, 拆解到最小动作, How can we get there? 如果时间不够, 也可以确定哪些需求是最高优先级, 用来取舍
- 沟通反馈: 把自己的想法说出去, 把别人的想法听进来
- 自动化: 日常 routine 要做到自动化
思考框架
在面对一个需求时，可以问产品经理：
- 这个特性会给用户带来什么样的价值
- 什么用户会用到这个特性，用户一般在什么场景下使用？又是会怎么使用？
- 达成这个目的是否有其他手段？是不是一定一定要开发一个系统？
- 这个特性上线之后，又怎么衡量其有效性？
以终为始
02 | 以终为始：如何让你的努力不白费？
软件就是人们想象共同体的载体, 任何事物都要经过两次创造, 一次是头脑之中的创造, 一次是现实的创造. 现实的创造没弄好, 往往是因为第一次头脑之中的创造没到位.
以终为始，其中的终应当是所有人一起得出的一个结果样本，为了得到这个结果，可以采用：
- 原型图
- demo或者hello world级别的初始文档
先假设所有东西都有了，然后梳理流程，看是否有缺漏或者是否有考虑不周的地方
需要考虑别人怎么使用这平台, 要实现什么价值, 以这个为基础来进行继续的设计和推理. 最后倒推着去写代码.
遇到问题, 倒着想, 先看看自己要什么!
04 | 接到需求任务，你要先做哪件事？
如果按照功能列表去做事情，那么其是将一个完整的需求敲成了碎片，只有所有功能完成大家对接的时候才能看到需求的全貌，从而会忽略很多重点或者问题点。
另外一个可能，是不同的组往往会按照自己所想的重点来开发程序，那么很有可能出现一个组开发完成却因为另一个组将其优先级调低造成的上不了线的情况。如果是多组协作，那么问题更大。
同样的，因为整个需求列表都被打碎，所以当时间不足需要砍需求时候也很难，毕竟一个需求有人做了有人没做，砍不砍都是问题。
怎么解决呢？用user story的形式。因为user story给出了最基本的测试用例，其保证了开发人员完成需求最基本的质量。同时user story之中还应该包含一些错误用例的情况，给开发用来做最基本的判断
user story的作用是定义了验收标准。
06 精益创业：产品经理不靠谱，你该怎么办？
任何一个需求, 都需要独立思考用户是如何使用流程的, 在这个基础之上看流程最需要优化的部分, 这个角度就能提出好问题
如何精益创业
精益创业实际上指的不是创业, 而是如何面对不确定性进行最小成本的试错.
“开发-测量-认知”, 闭环之后加强好想法, 去掉效果不佳的方法. 流程中最重要的是”认知”, 因为其经过检验.
最好的尝试的方式是 MVP.
任何一个产品特性, 都有要验证的东西
-
对于要验证的事物, 就需要有测量标准.
-
要验证的事务是否是当前最重要的?
-
是否有更加简单的解决方案来验证? 比如低频不重要的流程不需要自动化?
默认所有需求都不做，直到弄清楚为什么要做这件事。
07 解决了很多技术问题，为什么你依然在“坑”里？
同样的一个事物, 大家想到和做到的方向一定有差异, 如果不进行沟通, 每个人对于环节的理解不同，就会导致最后大家的方案不同，工期也不同，最后很难对齐。
不同角色工作上真正的差异是上下文的不同。
在整体上来看，问题一定比只在单点上看问题的人有更多的上下文，从而可以做到降维打击
在更大的上下文工作
扩展自己职业工作的上下文，就可以为自己的职业发展做好布局。 上下文的角度越广, 涉及到的利益方越多, 职位就越高.
09 你的工作可以用数字衡量吗？
在 MVP 开发过程中, 整条链路是 “开发-测量-认知”. 测量需要的就是数字. 整体而言就是各种指标
数字怎么用
使用数字进行技术决策, 比如要上线一个新的方案, 新方案的效果如何衡量? 不论是用户角度上的优化还是技术角度上的优化, 都需要一个指标来记录分析
使用数字判断系统稳定性: 一个系统的稳定性是需要指标来记录的, 通过指标的平稳程度, 可以去研判系统的稳定程度
10 迭代0_ 启动开发之前，你应该准备什么？
敏捷开发是由各种 sprint 组成, 在正式开发之前, 需要一个 sprint 0 来做所有项目的准备工作.
需求
1. 细化过的 sprint 1 需求
-
根据优先级, 从任务 backlog 之中选择最重要的事情
-
将这些需求确定好验收标准, 且细化到可执行的程度
2.用户界面和用户交互
给出所有细化的用户界面和用户交互
3. 基本技术准备
-
准备业务相关的技术架构和对应的库表
-
持续集成: CI pipeline 和脚本
-
代码风格的定义
4. 发布准备
-
数据库迁移和管理: 把每次数据库的变更记录文件
-
发布
技术方面
答疑解惑 | 如何管理你的上级？
上级管理主要分为三个方面：
- 管理上级的预期：把每一种他想要的改动的后果都讲清楚，比如有些方案是临时上线的，那么在上线结束之后要对方案进行重写等。把看到的问题暴露给上级，让他有更多的上下文
- 说出自己的想法：自己想做什么，可以更主动一些，承担更多的职责
任务分解
11 | 向埃隆·马斯克学习任务分解
对于一个大任务，首先要知道其如何分解，一个复杂任务往往是由多个部分组合而成，需要对每一个都有比较清楚的认知。
另一个大问题是，分解的任务要可以执行。大部分人对于可执行的粒度认识是不足的，低估了任务分解的程度。要做到好的分解，需要达到“微操作”的程度。任务分解的越小，就越容易完成一个开发循环，也就给计划调整做出了可能。
可执行的定义在于是否清楚的知道这个问题应该如何解决
15 一起练习：手把手带你分解任务
在写代码的过程中, 微任务要分解到层和方法的程度, 层就是比如 controller, service…
17 程序员也可以“砍”需求吗？
砍需求的前提是把需求细化, 不是站在 epic 的角度看, 而是打碎分解, 然后将分解出来的部分低优先级的需求进行省略.
这就需要我们程序员:
-
知道这个需求能拆分到什么程度
-
对于各种细粒度的需求, 可以进行难度的排序
-
知道能省略什么需求
20 为什么世界和你的理解不一样？
改善编解码
在我们给他人叙述的时候, 我们需要先整体后局部, 不要上来就讲自己的实现方案的细节.
21 你的代码为谁而写？
代码实际上是为了人而写, 所以起名的时候需要根据业务含义来做区分
先理解业务, 然后根据业务去拆分模块和代码, 用业务的语言写代码
22 轻量级沟通：你总是在开会吗？
如何减少开会的时间?
减少开会人数: 先和各方有个大概沟通的方向, 分别沟通, 最后再拉大会同步结束. 开会的目的应该是信息同步
如果双方对一个点已经有了分歧, 且彼此的上下文已经确定没有偏差, 就不要再想着去说服对方, 而是搁置这个争议点, 看双方的共识点
24 快速反馈：为什么你们公司总是做不好持续集成？
持续集成的目的实质上是快速反馈, 反馈的越快, 程序员不仅需要修改的越少, 而且其上下文也更清晰, 更容易做修改
出于这个目的, 最快的持续集成一定不是在CI环境里面做, 而是直接本地构建好对应的脚本, 每次开发一个小功能之后就在本地进行CI尝试
25 开发中的问题一再出现，应该怎么办？
针对所有问题, 必须复盘然后给出修改的措施, 并且坚决执行
行动项必须可以检查, 而不是无法验证的内容
27 尽早暴露问题： 为什么被指责的总是你？
如果和上级已经定好了最终目标, 但是在完成最终目标的过程之中发现工作量过大或者工期难以完成, 要及时和上司聊一下备用方案和可能对策.
不是所有问题, 都是值得解决的技术难题.
28 结构化：写文档也是一种学习方式
写作一定是要有中心论点和分论点, 所有的东西围绕着这一个中心论点叙述, 分论点作为支撑, 最后再写论据.
