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