开篇词

工作之中有两种复杂度：本质复杂度和偶然复杂度。

本质复杂度是解决一个问题的时候，无论如何都要解决的事情。偶然复杂度是因为选用的方法不当而导致要多做的事。

作者认为的四个原则：

思考框架

在面对一个需求时，可以问产品经理：

以终为始，其中的终应当是所有人一起得出的一个结果样本，为了得到这个结果，可以采用：

先假设所有东西都有了，然后梳理流程，看是否有缺漏或者是否有考虑不周的地方

如果按照功能列表去做事情，那么其是将一个完整的需求敲成了碎片，只有所有功能完成大家对接的时候才能看到需求的全貌，从而会忽略很多重点或者问题点。

另外一个可能，是不同的组往往会按照自己所想的重点来开发程序，那么很有可能出现一个组开发完成却因为另一个组将其优先级调低造成的上不了线的情况。如果是多组协作，那么问题更大。

同样的，因为整个需求列表都被打碎，所以当时间不足需要砍需求时候也很难，毕竟一个需求有人做了有人没做，砍不砍都是问题。

怎么解决呢？用user story的形式。因为user story给出了最基本的测试用例，其保证了开发人员完成需求最基本的质量。同时user stroy之中还应该包含一些错误用例的情况，给开发用来做最基本的判断

user story的作用是定义了验收标准。

上级管理主要分为三个方面：

对于一个大任务，首先要知道其如何分解，一个复杂任务往往是由多个部分组合而成，需要对每一个都有比较清楚的认知。

另一个大问题是，分解的任务要可以执行。大部分人对于可执行的粒度认识是不足的，低估了任务分解的程度。要做到好的分解，需要达到“微操作”的程度。任务分解的越小，就越容易完成一个开发循环，也就给计划调整做出了可能。