l

2012年3月5日 星期一

下一次世界末日是那一天?(上)

March 04 21:00~22:59

image

 

2012年12月21日應該是全世界「公認」最近一次的世界末日,Teddy想請問鄉民們,「下一次」世界末日是那一天?

等一下,世界末日為什麼會有「下一次」?都已經是世界末日,人類全部滅亡,也許地球也消失了,那麼談論「下一次」世界末日有何意義呢。因為有史以來所有關於世界末日的預測沒有一次準過(應該要高興嗎…XD),所以想必最近一次的世界末日預測應該也不準,還是未雨綢繆先問一下「下一次」世界末日是那一天(這個答案真的有意義嗎?有滴,至少可以當作電影的主題或是新聞與談話性節目的話題…XD)。

Teddy覺得軟體的時程預估,就好像在預估下一次世界末日是那一天一樣,從來沒有那一次的預估是準確的。原本預計六個月會做完的軟體,時間到了還沒完成怎麼辦?很簡單,老闆會請你預估「下一次世界末日是那一天」,然後你就要依據這個新的世界末日時程表來繼續過你那生不如死的日子,直到…下一次新的世界末日(這是 程式 人性的bug嗎?看起來像是一個無限迴圈…XD)。

不過軟體畢竟不像世界末日那麼難以捉摸,運氣好的話你的預估軟體時程活動總是會收斂為以下四種狀況之一:

  • 把時程往後延遲了若干年、月、日之後,有一天案子終於做完了
  • 把時程往後延遲了若干年、月、日之後,有一天案子終於被終止了。有可能是公司倒了、客戶倒了,或是以上皆是。
  • 把時程往後延遲了若干年、月、日之後,你還在持續地預估下一次世界末日。原因不外乎老闆想像力的豐富程度加上公司口袋的深度,大大大於你那短短的職業生崖壽命。翻成白話文就是,繼續燃燒生命以換取你那微薄的薪水吧你。
  • 把時程往後延遲了若干年、月、日之後,你看破紅塵遁入空門,另謀高職去了。

傳統所謂的feature boxing專案時程估算方式就會導致上述的狀況。Feature boxing的意思是說,這些X+Y+Z的一狗票有用沒用的功能在已知的世界末日之前你都要全部做出來,如果時間到了你還做不出來就再給你一個新的世界末日繼續折磨你,一直到上述四種情況之一為止。

Feature boxing雖然「表面上」看起來是要估算「做完這些固定軟體需求需要多少時間」,但事實上軟體需求從來就沒有固定過。不要告訴Teddy說你有叫客戶簽名畫押,就算是斬雞頭,發毒誓也沒什麼鳥用。原因不需要Teddy再解釋了吧,總之軟體的需求就是會隨著軟體一邊開發一邊跟著改變就對了。在feature boxing的軟體時程預估模式下,開發人員又不是諸葛亮,也不是劉伯溫,更不是尤達大師,根本不可能知道這個該死的案子需要多少時間可以做完。所以,為了讓自己多活幾天,只能在「合理的範圍之內」,儘量把世界末日的日期往後延(把開發時程拉長)。

但是,專案經理(PM, Project Manager)或是產品經理(PM, Product Manager)這些惡魔的心理可不是那麼想的,牠們當然希望世界末日越早越好啊,這樣牠們才可以早日回到牠們的老家--地獄,十八層的那一種--。所以,為了得到下一次形式上的世界末日時程表,絕地武士與西斯大帝雙方人馬於是展開了一場又一場無意義的嘴砲大戰。

還是擲杯問神明比較科學一點吧…XD

***

Feature boxing造成了客戶與公司,管理階層與工程師,工程師與客戶等多方面的不信任關係。如果大家不要再花費精力猜測世界末日是那一天,坐下來好好談,就把世界末日的日期給固定下來吧。這一天一到,就把手上的引爆開關按下去,結果只有兩個:

  • 燦爛的煙火(來賓請掌聲鼓勵)
  • 炸個粉身碎骨(早點投胎轉世)

這種固定世界末日的作法就是敏捷方法所採用的time boxing。常常有鄉民問Teddy,這種方法客戶與公司都不可能同意的,只要光想到下面兩點就不可能了:

  • 不先談好一個「固定的需求(精確的說,應該是看起來像是固定的需求)」,要如何報價?
  • 如果需求不固定,客戶可以隨時亂改需求,那公司不是賠死了。

在回答這個問題之前,先思考下面這兩個問題:

  1. 如果鄉民們是公司指派的業務負責人,你會每天去看幫你開發軟體的團隊軟體做得如何嗎?
  2. 鄉民們家裡正在請人裝潢,你會每天到工地去看看裝潢的進度如何嗎?

慢慢想,鄉民們有一整天的時間,明日待續…XD。

***

友藏內心獨白:開發人員必修課程--塔羅牌入門與進階。

1 則留言:

  1. System.out.println("世界末日:"+new Date(Long.MAX_VALUE));

    回覆刪除