訂閱本網誌: Facebook, Google+, 電子報, RSS

為什麼軟體工程無法估算時間?

April 11th, 2011 by Jamie

我們都有這樣的經驗:要開發一個東西,請工程師估算時間,大概要五天。結果過了一個禮拜,東西還沒出來。一問之下,碰到了原先完全沒有預期的情況,否則就是某個套件原來不能這樣用,必須要換一個,否則就是一個莫明的錯誤,找了一個下午還是不知道為什麼。久而久之,工程師開始習慣在回報的時間裡面灌水,預留空間給這些「未知數」,而我們也常常把他們給的時間乘以二,來得到最壞情況的數字。問題是這樣的方法之下,最後整個組織開始習慣用最龜的速度前進,因為估算精準、動作快,在這中間一點好處也沒有。更壞的情況,是叫九個女人去生一個小孩,那才是災難的開始。

為什麼軟體工程無法估算時間?

要了解這件事情發生的原因,你必須要先知道為什麼軟體工程是無法估算時間的。我以前常常喜歡用「常態分布」來解釋軟體工程時間的花費 — 上述的情況,讓大家慢慢從 Average 變成 (Average + 3 STD) 估算,最後平均浪費了 3 STD 的時間 — 不過這只是統計學上的解釋,並不是真正的「原因」。直到我前幾天看到這篇文章:「Why Can’t Developers Estimate Time?」,才給了我超大的一個領悟。(文章有點難,不過英文不錯的人,我鼓勵你們去讀讀。)

作者 Ashley Moran (愛許麗‧莫倫) 說:

我們無法預測軟體開發中每一個項目的時間,是因為這些工作的本質就是「創造新知識」。開發軟體的目的是創造「自動化的流程」,一但目標達到,自動化後的流程就可以重複的被執行,在可預測的時間裡面。所以一個軟體就像是「食譜」一樣,而電腦就是「廚師」,輸入的資料是「食材」,而輸出的資料是「晚餐」。

因此,我們在做的事情是讓未來從不可預測,變得可預測,讓大哥小弟、老爸老媽、只要想煮飯的,人人都可以當食神,給他三十分鐘,都可以弄出一鍋超級無敵海景佛跳牆。所以,「開發食譜」這件事情的本身,是一個創造新知識的過程,時間上當然很難預測。

如何管理

因此,軟體工程用硬體工程的模型去管理,從出發點就是錯誤。一個建築案是先有了「藍圖」,才去估算每個細項需要的時間。當我們在做的是藍圖本身,怎麼能夠沿用他們的模型?如果是這樣,一個創業團隊該如何「管理」開發的時間?

我的答案是你沒辦法 — 你怎麼能夠控制臭蟲什麼時候要出現?但是你可以管理「生產力」,也就是確認團隊總是在高效率的情況下工作,那最後你會得到的是 Average 的工作時間,比起前述 Average + 3STD 快上了 3 STD,這前後有可能就快了 2-3 倍。

而要管理「生產力」,一個現代化的軟體開發團隊,我認為有以下的幾個好工具可以用:

  • Pair Programming (兩人小組) — 一個人寫程式常常會有盲點,兩個人一起則可以看到對方遺漏的地方。更重要的是兩個人都會從對方身上學到很多知識和技巧,彼此都會成長。而當兩個人都了解一組程式碼,日後的維護也有了兩個選擇,不會因為一個人請假、離職,這些 code 就變成孤兒。記得給他們兩個鍵盤,實務上這會比鍵盤移來移去有效率。
  • Daily Stand-Up Meeting (每日早會) — 每天早上固定開一個快速早會,全部人都站著,每個人依序報告昨天的進度,碰到的問題,和溝通彼此程式間該如何傳遞資料。這讓團隊明確的知道彼此的進度,也省去很多溝通不良的麻煩。
  • 高效率的工作環境 — 開放、明亮、舒適的工作環境,或許讓大家換上拖鞋,確認團隊成員們可以取得他們需要的飲料、食物,但是不會吃得過飽、或是喝下過多的咖啡因。當其中一個成員困惑時,確認有人可以幫助他。
  • 隨時找得到使用者 — 代表「使用者」的那個人 (通常是 PM),最好是使用者本身,必須要隨時在現場,幫團隊解釋開發上細節不明確的地方。
  • 設定上線時間 — 雖然你沒辦法知道每一個子項目會花的時間,但是你可以設定一個上線的時間,然後所有的人通力合作在那個時間之前,盡可能做出一個可以推出的版本。當然,如果第一個版本推出時你不會覺得丟臉,那就是花了太多的時間

以上,希望可以幫助你們重新思考軟體開發該如何做,也希望對你們正在做的網站、行動應用有幫助。(當然這不是完整的列表,歡迎大家提出你們喜歡用的工具。)

___

除了網誌,我每天都會在 Facebook 分享許多創業者應該關注的資訊,歡迎追蹤

(Image via purecaffeine@flickr under CC license)

歡迎訂閱 MR JAMIE 電子報
讓新文章自動寄到你的信箱

©2024 MR JAMIE.
網站由 Allen Hsu 設計 | Logo 動畫由 Wen Chen 完成