成本導向的軟體開發

最近遇到兩個軟體開發的決策問題,一個是既有程式的加強,另一個則是全新的專案。有趣的是,同一個邏輯會導出來一個功能上的死結。

大前提是,公司的每一個小組,應該朝向降低軟體開發成本的目標而努力!(Keroro 軍曹如是說)
眾小兵: 喔!!!

[場景一]

Tamama: “Giroro 伍長,關於您先前寫的這個飛彈發射程式…..我發現您當初只實作了即時作戰的指令,平時的維修保養那段在藍星標準上的那部份程式都沒有實作….”
Giroro: “馬鹿野狼,我是軍人,只負責作戰,維修保養這種事應該不需要我來操心吧!”
Kululu: “Kekeke…..我可以 patch 喔~*詭異的笑*”
Tamama: “真的嗎? 太感謝了! Keroro 軍曹, 我們可以修改這個部份的程式讓它支援自動保養的藍星標準嗎?”
Keroro: “當然~~~不可以啊~ 我們現在沒有足夠的人力做回歸測試,雖然你們改的部份只是自動保養,但我們必須要重新跑一次戰爭模擬才行~ 不行不行,等到我們有預算做戰爭模擬再改吧! 要不然萬一為了支援自動保養而讓即時作戰的功能受到影響,總部怪罪下來我的蛙頭可是要落地的…”

摩亞桑: “也就是說,設計程式的時候要 「一步到位」?”

[另一個場景]

Tamama: “Keroro 大哥~ 你要的最新藍星攻擊雷射系統我已經設計好了….”
Keroro: “嗯~~很好~~ 等等,為什麼自動保養的界面也要加入開發的時程呢?我們的規格書上不是寫只要可以發射就好嗎?”
Tamama: “因為軍曹大哥上次說,如果我們要修改已經開發完的系統,就得要做完成的回歸測試;我想,與其到時候重做回歸測試,不如現在一開始就把這功能寫進去….”
Keroro: “不行不行,總部的規劃只有十天,你光是實作藍星標準就得花上八天了,這樣專案會延誤,萬萬不可,萬萬不可啊~~”
Tamama: “可是….現在不做,將來不是更做不了嗎?”
Keroro: “這問題我會反映到總部的,總作戰部後勤科會收集大家的需求然後做出共通的零件….”
Tamama: “那,大概要多久呢?”
Keroro: “依據經驗,大概是一年吧…..”

摩亞桑: “也就是說,「遙遙無期」?”

公司內部的專案如果以成本導向,理論上應該可以讓程式設計者更容易做決定。”成本導向” 並不只是看開發的成本,同時也需要看開發的效益;(收益-付出) 才是真正的成本。每一個新功能理論上 PM 應該要能夠訂出其收益,而軟體開發者可以定出其所需要付出的開發成本,測試者當然也可以列出其測試成本,進而對不同功能的先後順序進行整理。

但是,對於和開發者成本直接相關的函式庫,卻很難由 PM 預估其效應;把散落在程式各處的程式整理成函式庫,會記在本次專案的成本上,但其他獲益的專案卻不會反饋到這個專案上;某個工具程式如果很多專案都會用到,把它一次實作完整,會比每一個專案都自己實作自己需要的部份來得有益,但是這種決定卻很難在底層做出來,因為底層每一個人只希望先顧好自己的成本再說。

可是問題往上反映,就真的能夠被解決嗎?太底層的東西,往上反映顯得太旁枝末節;如果事情只要跨部門就需要大主管協調,似乎也是僵化的前兆啊….

還沒有想到什麼好的解決辦法,只能說,用成本導向來開發是對的,但兩個對的事情加起來可能是個死結,目前看起來,也只有由人來手動介入才有辦法解決這種死結了。

Advertisements

One thought on “成本導向的軟體開發

  1. augustinus

    如果目標全部改成「每個 iteration/milestone 的測試都要過」呢?把要做什麼事情轉換成 relative size, 漸漸地每個週期的成本就會固定了。至於規畫中的釋出時間和交貨期限嘛…… 總之交一個測試全數通過的東西,嘴巴上講的什麼 feature 通常很少會直接衝擊到金流?

Comments are closed.