从Push到Pull

前一阵子发现自己在用“番茄技术”进行时间管理时的一个问题。最初每日作计划的做法是在每天的第一个番茄时段(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。这样的计划不多不少,刚刚好。

 

Share

0 comments

请输入正确的验证码