本文是敏捷開發一千零一問的第三十九篇。（欄目總文件夾）

也是敏捷開發日常跟進系列的第八篇。（欄目文件夾）

問題：有一類任務非常重要（如果同一時候也非常緊急）。但卻非常不明白，該怎麽辦？

答案分非常多種情況。大致例如以下：

客戶早就提出的需求

一般而言，除非事出緊急（客戶突然提出），否則不能讓一個重要的內容處於重要+不明白的狀態。

處理方法應該例如以下：

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自帶工具的兩倍（由此推斷優化空間已經不大了），於是作罷。

這個步驟，也能夠變形一下用於技術預研。

敏捷開發一千零一問：怎樣處理重要但不明白的任務？