前一阵子发现自己在用“番茄技术”进行时间管理时的一个问题。最初每日作计划的做法是在每天的第一个番茄时段（25分钟）做全天的计划。具体是
- 每天早晨首先重新调整Activity Inventory里面任务的优先级
- 然后根据每天能够完成的工作量（速率）从Activity Inventory中选出最重要的几个任务，放到每日To-Do列表中。
结果发现计划永远赶不上变化。这个计划还是经常需要调整，总是不断的有新的更重要的紧急任务加进来，每天总要调整几次每日To-Do列表。在一次反省中，我突然想到我的这些计划工作是否真的有意义?是不是花功夫做这些计划和调整计划都是在浪费时间？有没有更有效的做法？因此最近我开始启用了一个新的策略：
- 在每天的第一个番茄时段，仅仅对Activity Inventory中的任务按照优先级进行排序，不再事先根据速率和优先级填充To-Do列表。
- 在番茄时段开始时如果手头没有正在做的任务，就从Activity Inventory中取优先级最高的一个任务。
这样做下来最大的好处就是，即使不断地有新的任务进来，我的计划是随时可变，而且每时每刻都在响应最高优先级的任务。另一个好处就是我再也不需要花很多精力去调整计划。问题解决了，但是仔细想一下这其实就是从“推动Push‘走向了”拉动Pull“。对于不确定的未来做预测这种事情，是不是用”拉动Pull“方式更好？
做软件的时候，尤其是传统方式，需要花很多的时间做计划，但这个计划到底多么有用，多么准确，十分令人怀疑。计划永远赶不上变化，即使一天的计划都会被不断涌现出的新的任务所打乱，两个星期的计划，半年的计划正确性可想而知。如果计划注定是不正确的，那我为什么还要不断去调整计划？而这种不断地调整这种注定还是要变的计划的价值到底有多大？花时间设计、调整计划，哪怕仅仅是两个星期的计划，是不是也是一种浪费？如果立刻就能着手最重要的任务岂不是更有效？
不谈传统软件开发方式里面的计划，那显然是太过了。即使是在使用Scrum的团队中，又有多少团队能够真正不受干扰的执行两个星期的计划，又有多少次Product Owner告诉团队需要临时添加紧急任务。为了同时保证Scrum计划，很多团队或者是采用预先留出一部分的缓冲时间（比如40%），或者是计划一个作为占位符的故事，然后把新来的任务都包括到故事里面。但是这种做法意义到底有多大？是否能够真正有效？如果没有紧急任务是不是这40%的时间就白白浪费了？
Mary Poppendieck说过“在基于拉动式的系统中是不需要缓冲时间的。”(The Tyranny of ‘The Plan’)。因为每做完一件事情，就回到队列(Queue)去取下一个最重要的任务去做。任务和任务之间的衔接是自然的，根本不需要预先去计划。预先要做的只是确保有一个排好优先级的队列，队列里面有足够的任务，这就够了。这其实也反映了一种JIT的思想，对于不确定的未来，我没有必要过早为次要优先级事情花费过多的时间，我只要集中尽力把当前最重要的事情做好。只有到次要优先级的任务变成首要优先级的时候我再去考虑，分析，实现。
最近几年开始流行的看板系统(Kanban)就是体现这种拉动式思想的软件过程。看板里面比较有特色的是Arlo Belshee的“赤裸裸的计划Naked Planning”。如下图：
每次在Product Backlog中准备七个故事(绝对不能不超过七个)，每次做完一个任务（Scrum&XP里面称为用户故事，Kaban里面称之为MMF ‘Minimum Market Feature’），开发团队从当前的Product Backlog中取第一个MMF，然后划分任务去实现、测试、集成、。。。发布。发布之后才会去取下一个MMF。在团队实现最重要的MMF期间，Product Owner可以任意调整（或者添加以及删除）Product Backlog里面的七个MMF。但是Product Backlog中必须而且只能有七个MMF。这样的计划不多不少，刚刚好。
