敏捷开发一千零一问：如何处理重要但不明确的任务？

本文是敏捷开发一千零一问的第三十九篇。（栏目总目录）

也是敏捷开发日常跟进系列的第八篇。（栏目目录）

问题：有一类任务很重要（假设同时也很紧急），但却很不明确，该怎么办？

答案分很多种情况，大致如下：

客户早就提出的需求

一般而言，除非事出紧急（客户突然提出），否则不能让一个重要的内容处于重要+不明确的状态。

处理方法应该如下：

1. 尽早做原型，使之明确

由于重要+不明确的任务工作量肯定大于重要+明确的任务，所以早做才能保证同时完成——假设截至点相同。

不过，早做只是使之明确而已，并不需要真的做完，所以可以视同为原型。每个迭代把用来明确的原型展示给客户看，让其提出明确的意见。

客户突然提出的需求

假设只有一个迭代周期就要上线，该怎么办呢？

这时候应该打破原来的评审会制度，因为本来就不明确，被评审通过的概率很低；而是采用“渐进式评审”（参考这里：http://blog.csdn.net/cheny_com/article/details/7339173），即任务完成的同时就马上拉评审，如果不通过就接着改，甚至可以放弃一些同迭代的次要任务——谁让它重要呢。

技术预研

PO应该在计划会之外，更早、更长期地与团队有一个接触，内容是远景展望、最近2～3个迭代的内容等。参与人员是PO+技术骨干。

这样团队就能提前获知一些潜在的预言，提前做准备。

技术改造

这是一类类似“性能优化”的活动，常常难以在实施前确定目标，很容易无始无终。这时的处理方法是划分为若干个可跟踪的点，分期达到。

比如我曾经做过一次性能优化，我们大致分为四个步骤：

1. 确认性能基线，就是现在的内存、速度如何。

2. 确认问题点，就是哪些内容占据了内存、时间。

3. 排序问题，从大到小逐个解决；

4. 每解决一些问题，就做一个判断是否停止。

当时大约2周后，性能达到了原来的1/6内存和1/7时间，且只有SQL Server自带工具的两倍（由此判断优化空间已经不大了），于是作罢。

这个步骤，也可以变形一下用于技术预研。