发信人: frenger(frenger)
整理人: xiange(2004-08-31 14:32:58), 站内信件
|
記得有一個叫做“阿基列斯與龜”的悖論，阿基列斯的捷步永遠不能追過烏龜的爬行。假設阿基列斯落後于龜一百步而比龜快十倍，當阿基列斯走十步，龜也前進一步，阿基列斯每走一步，龜也走十分之一步。如此永遠追不上前邊的烏龜。
中學的時候是怎麽推翻這個悖論已經忘記了，但是在項目開發過程中遇到的情景好像落入到類似的悖論中。假設在測試過程中，發現的問題總數比已經解決的總數多100個，而解決問題的速度比發現問題的速度（可能是新的測試也可能是對開發人員已經修改好問題的重測）快十倍，由於版本管理的原因，每週才能把修改好的問題提交一次給測試人員，按照這個假設，每週開發人員解決十個問題，同時測試人員發現一個問題。如此問題永遠修改不完。
每每到測試後期，這樣的問題往往會困擾我們。大家經歷了漫長的開發時間，繁複的測試，已經相當疲累，在看到“阿基列斯與龜”的情況下，不管User也好我們自己也好，都想一鼓作氣，在一周内把問題全部解決。但是，“龜”不管你跑得多快，它就跑了那麽一點，令你再一周后發現還有尾巴。於是再次擂響鑼鼓，結果一周過後理目標接近了，但是還有那麽一點。第三次擂鼓，第四次擂鼓……開發人員始終不是神話中的阿基列斯，會“再而衰、三而竭”。這個時候，開發人員、User都會忘記“阿基列斯與龜”的悖論，而且在測試後期的問題往往又都是特別難以解決的問題，特別容易打擊大家的士氣。
對這樣的問題，我是缺乏經驗的，要不是時刻堅信“阿基列斯與龜”是個悖論，我可能也會崩潰。在這個時候，我們使用的是一種“容忍”的方法：在計劃要完成測試的時間點前三周開始擂鼓，經過三周的衝刺，應該會迅速的消滅剩下的大部分問題，一旦到了deadline，就要把剩下的問題進行評估，逐一衡量問題的影響範圍、計劃解決時間等，把所有相關的資料整理為一份Open Points Inventory。在評估不影響（或者影響範圍可控）的前提下，進入下一階段，並公佈這個checkpoint已經完成。後面就是兩個階段的並行，直到所有問題解決。這個方法未必是科學和權威的做法，我也努力在收集學習，看看有沒有更好的解決方法，但是這種“容忍”的方法我覺得有以下好處：
1、 在大家都將盡失望的時候，公佈目標完成，使大家保持信心
2、 鎖定和限定問題，令沒有完成不是作爲全部沒完成，而定義在某些情況底下部分沒完成，不致User全盤否定
3、 不影響（或者減少影響）整個項目的進度
阿基列斯一定是追得上龜的，我堅信，只是需要搞清楚怎麽追比較好，怎麽計算追的時間比較科學而準確。
|
|