訂閱本網誌: 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)

  • 不盡然如此,實際還要看開發軟體產品的性質與範圍,當你對工具或工作的熟悉度很高時,你能算出很精準的完工時程(不是完美 穩固 產品的完成時間),嚴格來說,在好還要更好的原則上,做軟體沒有所謂真正的完工,但絕對可以有準時的中間物產出,”設定上線時間” 正是這個道理

  • Rolence0515

    軟體工程之所以難以估算時間的原因,我想並不是那麼簡單。

    我們都習慣於找答案,而且找”一個”答案。
    因此我們會說:「喔,因為A,所以沒辦法估算」,或「就是B,所以沒辦法估算」。
    其實真正的答案往往不是那麼單純,有可能是A跟B Mix的C,或者是A, B都不是。

    軟體開發有時也不見得每次都是”創造”,如果你蛋炒飯天天煮,那麼你很快的就能估算出開發時間。但是如果你開發的專案是屬於創造型的專案,那麼時間的預測自然很難準確了。

    而在實務上,專案通常介於”傳統””創造”之間。只是比重不太一樣罷了。

    不過本文提出的觀點中,有一點是確定的,那就是”管理「生產力”這件事,這是非常重要的大前提。在管理生產力的同時,你給了團隊一個優良的開發環境,這是開發出穩定軟體開發的必要條件,也是媽媽孕育孩子的子宮,在這個前提之下,談如何估算時間才有意義。

  • 某種程度來說,軟體工程跟”設計”專業很像,它們都是由模糊階段,慢慢地走向聚焦階段的過程,最後才可能有一個結果出來。用硬體工程的思維套用在軟體設計,顯得很不適宜。

    Mr. Jamie 對於軟體開發者提供的高效的 solution,跟設計的專業的思考模式其實也很像。設計最重要的是要先”實作模型”,以最快的速度開發一個 prototype 出來,這裡講的 prototype 不一定是 physical 的東西,用 sketch、用木條、用筷子、用LEGO,用什麼材料都好,只是能清楚表達想法即可,有了這第一步模型階段,才有後來的成品。

  • AAA

    後面兩個比前面兩個有用,Trust Me.

    AAA

  • 注意到這裡有一連幾篇對於軟體時程的分享,非常簡短有力。我也強力推薦 Mythical Man-Month 這本書,每隔一段時間我就會再去翻閱一下,每一次都會有一些收穫,很難想像這是超過三十年前的書。

  • 是的,這個網誌主要是寫給創業人看的,所以比較專注在創造上。話說回來,如果常常重複寫的 code,那早該被做成 module 才是。

  • 是的,如果是神人,那當然不能用一般人的標準看,只是世上神人幾希啊。

  • 改天好好來拜讀一下

  • 是的,每個團隊應該要看屬性採用

  • 是的,軟體工程 (尤其是做給消費者的) 跟設計、藝術、時尚,其實比較接近

  • 除了pair programming
    iteration也很實用

  • Yes, of course.

  • 在合理的時程規劃裡;準時完工與品質伸縮有關,如果你這麼看這件事,你會有相反的看法,是符合規格 還是完美呈現 或是 穩定好用? 跟品質有關的事務通常與對工作的熟悉度有關,雖然實務上我們很難精準說明,我哪天哪時哪刻會好, 但說好要開車從台北到台中的路,很難10天還不到達目的,至於中途出車禍 塞車 地震讓橋樑不通 或是繞道苗栗走走 , 這些不會是經常性發生,畢竟我們說的是開發而不是研發

  • 我同意,所以我的看法是,如果你能確定車速是快的,方向是對的,那總有一天會到台中,而且可能比你想像中的還快。

  • Jameschu888

    軟體工程(Software Engineering)並沒有難以估算的問題, 工程就是方法論(RUP,CMMI,Aglie…), 以工程的觀點來看, 時間肯定是估的出來, 執行面就是另外一回事了, 畢竟軟體工程也不是萬靈丹, 沒有包生子這回事, 倒是文中的建議是偏向Aglie的開發方式

  • kimi

    好像在杜拉克的知識管理裡面有看到類似的觀念
    這篇很有趣

  • 這麼說我好像也有點印象

  • 時間當然一定估得出來,問題是誤差值有多大。以「消費者網路」而言,大多的情況下 agile 是比較好的策略。

  • Pair Programming 是我個人認為能大幅提高生產力的方式。但這個方式也有其限制,那就是你得聘請兩個可以互相信任、有足夠能力完成你交付任務的工程師。
    這個條件蠻難達到的,尤其是在創業初期。

  • 是的,軟體工程確實很難估算時間,我自己本身就是web程式設計師,不少專案或者功能開發會難以估算,是因為spec變動太頻繁…..提出需求的單位/人/客戶和PM溝通,寫出spec估算時間後,每週例行會議輕易的就被提出需求者/使用者給改了…..

    另一個問題是,有時提出的是功能面的需求,但使用者三不五時會對快完工時的測試不滿意(尤其使用者很多的時候,每個人都有自己的使用習慣),web程式設計很常碰到「改流程跟UI」的需求,這個工也很大….

    當然大家會說問題在於一開始spec就不明確,不過實務上的確會碰到不少客戶其實自己想像的功能跟流程自己也說不清楚了….

    版主所提的最後兩點確實是比較有用的。

  • 沒錯,我以前做的專案,也都是碰到這種問題。

  • 的確沒有很容易,但是可以的話可以盡量採用,就算是 Part-time pair programming 也好

  • Victor

    正確的估算時間,應該是軟體工程人員的核心能力之一吧!需要不斷的練習才有辦法估計的越來越準.
    要管理生產力的話,XP裡面的small releases也很重要,如此可以更有效的評估時間跟並確認客戶需求。另外,coding standard也是很重要的,提升很多團隊裡面合作的效率… :p

  • 沒錯,small releases 和 coding standards 的確非常重要。

  • Pei-Hua Huang

    的確~ 我本身從事工業設計, 然而工作上最常拿來用, 最欣賞的書籍卻是”人月神話”~ 😀

  • Pei-Hua Huang

    的確~ 我本身從事工業設計, 然而工作上最常拿來用, 最欣賞的書籍卻是”人月神話”~ 😀

  • 覺得寫得挺好的,就是立場沒先講明。

    從回覆中感覺很多人是從軟體製造公司的角度在看這篇內容,
    如果標的換成是「開發新創服務為什麼無法估算時間」那麼應該認同的人就會比較多吧。

    通常接案寫程式交差是有規格可循,完成日是可以被估算的(尤其是已經作過類似案件),但是為理想而寫程式在達到理想前會發現還可以提供更多的服務或功能給使用者,於是造成範圍不斷擴大或目標不斷延伸,就像現在可以說Facebook的專案已經完成了嗎?我覺得充其量是陸續完成某部分功能並且還是持續修改中。Nio 個人淺見

  • 覺得寫得挺好的,就是立場沒先講明。

    從回覆中感覺很多人是從軟體製造公司的角度在看這篇內容,
    如果標的換成是「開發新創服務為什麼無法估算時間」那麼應該認同的人就會比較多吧。

    通常接案寫程式交差是有規格可循,完成日是可以被估算的(尤其是已經作過類似案件),但是為理想而寫程式在達到理想前會發現還可以提供更多的服務或功能給使用者,於是造成範圍不斷擴大或目標不斷延伸,就像現在可以說Facebook的專案已經完成了嗎?我覺得充其量是陸續完成某部分功能並且還是持續修改中。Nio 個人淺見

  • 不小心看到著篇文章, 對於”如何管理”

    不是這麼確定 你在軟體開發管理領域的實作經驗如何. 看起來講得蠻硬的. 

  • Birdy_1980

    說起來,人類在發明火車以前,也要經過好久的摸索才有火車,一開始是用馬車,後來才想到利用兩條軌道來引導一小節一小節的台車,在礦坑中將礦物運送出來。
    直到英國人兌比茲克,以及史蒂芬生等人,運用蒸汽動力,才有蒸汽火車的雛形。兌比茲克用的雛形,日後影響了史蒂芬生,但是要是沒有瓦特改良紐科門教授的蒸汽機模型的話,蒸汽引擎就別想問世了。至於史蒂芬生為何稱之為鐵路之父?原因是有很多鐵路的規則是他跟兒子一起想出來的,包括轉轍器與路牌行車制度(通行證),還有軌距的制定等等。人類先有馬車,過了近4000年後才有軌道馬車或是礦業台車,進入工業革命時代,才開始有鋼鐵與蒸汽引擎,進一步讓火車問世,甚至火車剛問世時,牽引力不佳、笨重、容易故障,即便問世了也會有鍋爐控制上的問題引發爆炸等等,這些都是探索的過程。版主說的沒錯,寫程式基本上就跟製造知識一樣,還得知道為何會出錯,一開始人們也沒想到火車不遵守時間或路牌規定的話,誤點事小、相撞事大,一百多年前火車行車只能仰賴時刻表與路牌,沒有無線電等工具,即便摩斯發明了電報,也頂多就是減少撞車的機會罷了。所以一套系統的誕生,都是經過無數次錯誤才能累積而成,所以想用「生產線」的作法來進行軟體的研發,這種人如果不是天才,要不就是個大外行。

  • photodesignch

    Agile 模式, 因為開發時是以每週或每兩週為週期, 因此錯估時可以很快的糾正. 不會一拖再拖. 無法估計時間的策劃通常是沒有經過完整的 Agile 開發模式.

  • CoodyChou

    人月神話是20年前的書,到現在還是我們軟體工程的聖經書籍!

  • 推薦scrum,從上述的Daily Stand-Up Meeting拓展到整個產品開發的模式,在 Agile methods 中算是很好上手又有效率的。

  • Ming Chen

    更重要的一點,請讓辦公室連接到網際網路。
    工程師需要隨時吸收新的知識,
    而不是等下班後再利用自己的私人時間去尋找答案。

  • Alan Feng

    個人認為有一個很大的原因是,一個案子裡面的角色太多,每個角色間都需要溝通,很多時間是花在 information syncing, decision making.. 就一個很簡單的例子:前端串 API 遇到問題,需要與後端討論,兩方一起檢查全部可能的原因後才得出一個簡單的造因,但因為後端工程師沒辦法立即與前端在問題發生的時候做溝通,問題會延遲解決的時間 (往往只是一個很小的問題,等待時間遠比解決時間要來得長)。

    因此溝通的複雜度與溝通所花的時間是幾乎每個案子都無法估算的一部份,因為當一個人發現 / 遇到問題,要解決時需要的可能是好幾個人的參與,更何況很多案子的需求頻繁的變更。

    以上是當自己開始做全端工程師以後的體悟 (需要同步的只有自己的腦袋)。

  • Yau Kwan Kiu

    somewhere down the line you will hit the halting problem.
    you cannot programme programming ad infinitum.

  • AllenYeh

    愛因斯坦曾說 E = MC^2

    Error = (More * Code) ^ 2
    軟體工程很難估算的原因,就是因為你很難預估究竟後來的新功能的程式碼與舊的功能產生相依或交相作用,或者因為新的程式破壞原本架構造成更多錯誤,於是產生更多成本或更多Bug…

©2016 MR JAMIE ─ 創業者需要的啟發,新鮮供應.
網站由 Allen Hsu 設計 | Logo 動畫由 Wen Chen 完成