本文是敏捷開發一千零一問的第三十九篇。（欄目總目錄）
也是敏捷開發日常跟進系列的第八篇。（欄目目錄）
問題：有一類任務很重要（假設同時也很緊急），但卻很不明確，該怎麼辦？
答案分很多種情況，大致如下：
客戶早就提出的需求
一般而言，除非事出緊急（客戶突然提出），否則不能讓一個重要的內容處於重要+不明確的狀態。
處理方法應該如下：
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自帶工具的兩倍（由此判斷優化空間已經不大了），於是作罷。
這個步驟，也可以變形一下用於技術預研。