前言
最近我在得到APP上学汤君健老师的《怎样成为时间管理的高手》课程，很受启发，特地做下学习笔记，也希望能够给你带来启发。
敏捷开发
敏捷开发（agile development）是目前非常流行的软件开发方法，程序员一般都很熟悉。简单的说敏捷开发就是通过快速迭代持续交付可以工作的软件项目，不求一次性做到完美，讲究持续地快速迭代。
敏捷开发的核心就是把一个大项目拆分成多个子项目，或者把一个大模块拆分成多个小模块，然后一个个小模块分批上线，小步快跑，快速迭代，每次迭代都是一个完整的软件开发周期。
这么做有几个好处：
- 快速交付，从而大大降低成本。比如一个大型项目，不用等开发了几年之后再上线，采用敏捷开发的方法，几周就能上线一个简单的功能模块，可以先让客户用起来。
- 降低需求变更的成本以及风险。客户的需求经常变更，很多时候客户自己都不知道自己的需求是什么，等使用了一段时间之后，才会提出更多需求。让客户尽早的使用软件，就能在项目的早期明确客户的需求，如果需求有变更，早期修改的成本比后期要小得多，船小好调头嘛。
软件开发中使用的敏捷开发方法，没想到也能运用到我们平时的工作中。
提高工作效率的方法
汤老师在课程中讲到了几个提高工作效率的方法，总结如下：
一、把任务拆分成具体的动作
什么是任务？
比如，写年终终结就是个任务。
什么是具体的动作？
比如，给客户打个电话；发起个请假流程，就是具体的动作。
一看到具体的动作，我们就知道该怎么做了。
但是一看到任务，我们就会迷茫，感觉无处下手，不知道怎么开始，这很正常。因为这是一个复杂的任务，不是简单的一个动作就能完成的。
我们可以把某项任务拆分成具体的动作，比如写年终总结就可以拆分成三个动作：
- 工作总结，总结过去一年里自己做了什么工作，得到了什么成绩；
- 能力盘点，过去一年里自己的哪些能力得到了提升；
- 明年计划，明年的具体工作安排。
这样分解了以后，我们就能很容易先从第一个动作开始行动了。
二、不要把时间浪费在努力工作中
不要做完美主义者
除了一些军工、航天、医疗等等高精行业，需要0误差。对于普通的职场人，完美，是不可能，也是没必要的。一旦你真的“完美”了一次，就相当于提升了周围所有人对你的期待。而你下一次只要稍微差那么一点，大家就会非常失望。
同时，完美是有代价的。你的时间、精力的投入，把一个只需要做到80分就可以的事情，做到了100分，这可能需要多花一倍的时间。
看似你非常努力，但这种努力，可能是以牺牲七八件只需要做到60分，而你完全没有时间去做的事情为代价的。这样总体的产出反而要少得多。
不要为了把一件事做到完美，导致延期交付，毕竟理论上完美是不存在的，没有最好只有更好。
完成比完美重要得多。
拒绝“范围蔓延”
范围蔓延就是做超出工作职责之外的事。
很多人都喜欢做职场上的老好人，别人找他帮忙，为了不得罪对方，不管是不是分内事都一口答应，最后结果往往是对方满意了，自己的工作却没做完。
我们在做工作职责范围之外的事之前，首先要问问自己的本职工作做好了吗？如果没有，就果断拒绝。
防止返工
返工意味着你之前做的大量工作都白做了，会浪费大量的时间，这种情况是要极力避免的。
返工的原因可能是你没有理解用户的需求，或者是客户的需求变更，最糟糕的结果就是，等我们把任务全都做完了，才发现在一开始我们就做错了，然后又要全部推倒重新来过。
这是很打击士气的，我们要尽早让客户的参与到项目中，让客户心里先有个底，不至于我们的大方都搞错了。
那如何避免以上三种情况呢？
三、敏捷工作法
这就需要敏捷工作法来拯救你，敏捷工作法的核心就是一种不断迭代的工作方式。
它不提倡“一步到位”，它提倡不断调整、适应，逐步去达成目标。
敏捷工作法包括两个要点：最小可交付和持续迭代。
建立“最小可交付”意识
掌握敏捷工作法，首先，你要建立交付意识。
敏捷工作法是个好名字，把这两个字拆开看，更容易理解：
敏→每 文，每个功能都写文档，表示按功能交付，最小交付。捷→手 走，接手一项，要赶走一项，灵活处置，永远不要被太多的任务压垮，持续迭代。
这个时代是脑力工作的时代，你有多少投入，只有你自己知道。你可能在一项工作中投入了大量的时间和精力，但如果没有交付的动作，在旁人看来，你等于什么都没做。
你很努力，结果只感动了自己。这时候你就需要最小交付。
为什么要强调最小交付呢？
这是因为，计划不是一成不变的。我们经常说计划赶不上变化快，很多时间，就算老板，也没有办法做到100%看准一个方向。
更多的时候，也许需求方也没真正想清楚到底要的是什么。如果只有看到你的最终产出时，他才意识到自己的需求是另外一个东西，然后推倒重来，造成返工。那么，大家的时间就这么浪费进去了。
大家想想看，自己的很多加班是不是就是因为返工重做造成的？
所以，你就需要一个，在早期，就能给需求方看的最初级版本。它要拿得出手，又不至于过于复杂。也就是最小可交付的1.0版本，它可以帮助你确认最终的需求，避免你把时间投入到不必要的地方。
最小交付是解决返工问题的一大利器。
在计划交付节点的时候，我的建议是前紧后松。
假设一件事情，如果你有一个月的准备时间，我建议你第一周，交付两次你的方案，供对方进行反馈和调整，之后可以保持一周一次的交付节奏，这样也给自己留有余地。
所以，当你接到一个任务或项目的时候，我会建议你，第一步不是向对方承诺什么时候交出最终结果，而是承诺什么时间去完成第一次交付。
比如，当你接到领导派活时，更加敏捷的回答方式是“明天上午我就开始去准备，下班前给您一个初步反馈”，而不是“两周后给您最终方案”。
持续迭代，把背上的猴子扔出去
说完了“最小可交付”，接下来就是寻求对方的反馈，然后进行迭代。
迭代，通俗地说，就是一次比一次更好的“交付”。
这里给你反馈的，可以是你的老板，你的同事，也可能是你的客户。你把1.0版本交给他们，然后他们给你反馈，你再进行改进。
把活不断地交付出去，就是我们可以同时处理多个任务的关键秘密。
活交出去，对方就需要开始进行吸收、反馈或者加工。这个时间，你就可以去安心地做下一个活。
这样的好处在于，一方面，你源源不断地有产出。和你合作的伙伴，也始终处于一个合理的忙碌状态。而不是所有人在等你的时间，万一你憋了半天大招，憋出来的东西不是他们想要的，很多东西又要重做，又导致返工，整体效率就会被你拖累。
另一方面，每一次你都是“刚好就好”，你的时间没有被浪费。
一个形象的比喻就是：
一个一个的任务，就好比不断扔到你背上的猴子。聪明的工作者，之所以可以完成更多的事情，不会被累垮，秘密就在于，他总是能够在接一只新猴子的时候，把背上的另一只猴子扔出去。他的背上，始终只能有一只猴子，否则早就被压垮了。
看下课程里的敏捷时间管理示意图：
如果按照一般的机械式时间管理的话，要等一件事完完整整地做好再进行下一件事。你要把整个任务都做好，然后把成果交给客户后，还得等客户的反馈，如果客户不满意，还得再修改，再给客户确认。等这个任务彻底完成后再进行下一个人任务，任务是串行的。
而敏捷时间管理法，采用的是最小交付，我们做出个1.0版本先给客户看看，等客户反馈的同时就可以开始下一件事了。这么多任务虽然同时开展，但是不是并行的，就像单核的CUP能同时执行多个任务，其实CUP是在后台快速地切换任务，只是我们感觉不出来而已。
我们要把背上的猴子先扔出去，才能接下一只猴子，同一时间我们要保证自己的背上始终只有一只猴子。
另外，当同时面对多个项目的时候，我有一个心得：
重要的事情多迭代，紧急的事情先迭代。
比如，一个月后，你要出席一个公司级的重要活动并做一个演讲；两天之后，你要给部门内部员工做一次培训。重要性上，当然是公司级的活动大于部门内的培训。紧急度上，却恰好反过来。不管你先做哪个，心里总会惦记着另外一个。
根据重要的事情多迭代，紧急的事情先迭代的原则，你可以先把最急的内部培训材料，做出一个1.0版本，发出去听听其他人对这个版本的反馈。
然后把这事放一边，开始全力把公司演讲做出1.0版本。因为毕竟还有一个月的时间，接下来你可以根据领导的反馈，慢慢迭代到3.0甚至是10.0。
部门的培训，最终也许只迭代到2.0版本，但因为没有那么重要，2.0已经足够了。
最后
需要强调的是，敏捷工作法，不主张“同时做多件事”。
对我们大部分普通人来说，在小块时间里同时进行多个任务是不可能的，人的大脑就像是单核的CPU，同一时间只能做一件事情。
同时处理多件事，就好比你的电脑，同时开了五个网页、六个PPT、七个Word，你的电脑运行速度肯定快不起来。
虽然敏捷的结果，看起来是多个项目在同时推进，但其实你是把不同项目的不同版本，不断地交付出去，手里仍然始终只留一个任务。
效率高的人，虽然看上去很忙，但是他们永远只是在做一件事。
