本文是敏捷開發一千零一問的第三十九篇。（
欄目總目錄
）也是敏捷開發日常跟進系列的第八篇。（欄目目錄
）問題：有一類任務很重要（假設同時也很緊急），但卻很不明確，該怎麼辦？
答案分很多種情況，大致如下：
客戶早就提出的需求
一般而言，除非事出緊急（客戶突然提出），否則不能讓乙個重要的內容處於重要+不明確的狀態。
處理方法應該如下：
1. 盡早做原型，使之明確
由於重要+不明確的任務工作量肯定大於重要+明確的任務，所以早做才能保證同時完成——假設截至點相同。
不過，早做只是使之明確而已，並不需要真的做完，所以可以視同為原型。每個迭代把用來明確的原型展示給客戶看，讓其提出明確的意見。
客戶突然提出的需求
假設只有乙個迭代週期就要上線，該怎麼辦呢？
這時候應該打破原來的評審會制度，因為本來就不明確，被評審通過的概率很低；而是採用「漸進式評審」（參考這裡：即任務完成的同時就馬上拉評審，如果不通過就接著改，甚至可以放棄一些同迭代的次要任務——誰讓它重要呢。
技術預研
po應該在計畫會之外，更早、更長期地與團隊有乙個接觸，內容是遠景展望、最近2～3個迭代的內容等。參與人員是po+技術骨幹。
這樣團隊就能提前獲知一些潛在的預言，提前做準備。
技術改造
這是一類類似「效能優化」的活動，常常難以在實施前確定目標，很容易無始無終。
這時的處理方法是劃分為若干個可跟蹤的點，分期達到。
比如我曾經做過一次效能優化，我們大致分為四個步驟：
1. 確認效能基線，就是現在的記憶體、速度如何。
2. 確認問題點，就是哪些內容佔據了記憶體、時間。
3. 排序問題，從大到小逐個解決；
4. 每解決一些問題，就做乙個判斷是否停止。
當時大約2週後，效能達到了原來的1/6記憶體和1/7時間，且只有sql server自帶工具的兩倍（由此判斷優化空間已經不大了），於是作罷。
這個步驟，也可以變形一下用於技術預研。
敏捷開發一千零一問系列之十四 敏捷開發加班嗎？
這是敏捷開發一千零一問系列的第十四篇。之一，之二，之三，問題總目錄 正逢週末，又是愚人節，群中有人正在加班，想起上次培訓中間休息的時候，討論起這個 敏捷開發加班嗎 的問題，雖然後來沒有作為課後投票入選，但這裡也完整回答一下。敏捷開發加班嗎？樓下有人問到 敏捷和加班有什麼關係 補充這兩句。有些程式設計...
敏捷開發一千零一問系列之十四 敏捷開發加班嗎？
這是敏捷開發一千零一問系列的第十四篇。在這裡提問，之一，之二，之三，問題總目錄 正逢週末，又是愚人節，群中有人正在加班，想起上次培訓中間休息的時候，討論起這個 敏捷開發加班嗎 的問題，雖然後來沒有作為課後投票入選，但這裡也完整回答一下。敏捷開發加班嗎？樓下有人問到 敏捷和加班有什麼關係 補充這兩句。...
敏捷開發一千零一問系列之三十 敏捷怎樣估算（中）？
這是敏捷開發一千零一問系列的第三十篇。在這裡提問，之一 之二，之三 問題總目錄 續前文，預計未來還要有一篇，暫時做為中篇。這個在之前談到過很多次了，具體可以 參考敏捷開發績效管理系列 的之六 之七。另外在敏捷開發使用者故事分類與組織結構 一期 整個活動1期 中有詳細描述。這個是國際上迄今為止唯一被大...