敏捷開發一千零一問：如何處理重要但不明確的任務？

標籤：style   blog   http   color   io   strong   art   ar   

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

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

問題：有一類任務很重要（假設同時也很緊急），但卻很不明確，該怎麼辦？

答案分很多種情況，大致如下：

客戶早就提出的需求

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

處理方法應該如下：

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內建工具的兩倍（由此判斷最佳化空間已經不大了），於是作罷。

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