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

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

问题：有一类任务非常重要（如果同一时候也非常紧急）。但却非常不明白，该怎么办？

答案分非常多种情况。大致例如以下：

客户早就提出的需求

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

处理方法应该例如以下：

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

由于重要+不明白的任务工作量肯定大于重要+明白的任务，所以早做才干保证同一时候完毕——如果截至点同样。

只是，早做仅仅是使之明白而已，并不须要真的做完，所以能够视同为原型。

每一个迭代把用来明白的原型展示给客户看，让其提出明白的意见。

客户突然提出的需求

如果仅仅有一个迭代周期就要上线，该怎么办呢？

这时候应该打破原来的评审会制度，由于本来就不明白。被评审通过的概率非常低。而是採用“渐进式评审”（參考这里：http://blog.csdn.net/cheny_com/article/details/7339173）。即任务完毕的同一时候就立即拉评审。如果不通过就接着改，甚至能够放弃一些同迭代的次要任务——谁让它重要呢。

技术预研

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

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

技术改造

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

比方我以前做过一次性能优化，我们大致分为四个步骤：

1. 确认性能基线，就是如今的内存、速度怎样。

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

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

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

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

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