2015/10/08

軟體開發的長鞭效應 Software Development and Bullwhip Effect

這篇文章是從 2008 年 7 月的文章《軟體開發過程的長鞭效應》改寫後重新發表。

在製造業供應鏈中有所謂「長鞭效應」:「下游的訂單產生變異時,訂單資訊因為某些因素而被逐級放大的現象」。

其實在軟體業,也有製造業供應鏈「長鞭效應」的現象,但其負面結果及解法不同。
Bullwhip effect
Photo from wikipedia

長鞭效應(Bullwhip Effect)


「長鞭效應」(Bullwhip Effect)是把整個產業供應鏈比做一條鞭子,而鞭子的一頭是握在最終端的客戶手中。

隨著客戶購買需求的改變,就像搖動鞭子,於是整條鞭子的各環節也跟著不停地擺動。當鞭子越長時,鞭梢擺動的幅度就越大,於是整個產業供應鏈就向上遊影響而變得非常不穩定。

在製造業的解決方法,利用資訊科技將供應鍊的庫存串連,使資訊透明。另一個方式,就是利用電子商務的方式,直接跨過中間的批發商和零售商,由製造商(網站)直接賣給最終的消費者。

我知道這個例子大家可能聽了不是很懂,沒關係,我拿一個在軍中看到的實例。

「長鞭效應」在軍中的實例


我在部隊服役時,每個月的辦伙軍官會計算由各連執星官彙報的開伙人數,以此來決定採買的主副食及每日的菜量,假設一營有4個連,每連120人。

改善前:各連執星官彙報的開伙人數,在考量不確定的差勤、臨時公差、請假、或其他因素,會多報一些人。如果每個連隊都多報5人,四個連就多報了20人。再加上辦伙軍官不知道各連隊已經多報了人數,所以又會再加上營級的彈性人數15人,多報的人數加總就有35人。

以一個人一餐的副食30元計算,光是一餐最多可能浪費了1050元,一個月扣掉放假後剩23天來計算,一個月最多可能浪費24150元(30元*35人*23天=24150元)。

改善後:營長要求各連的值星官改採精準的計算人數方式,統一由辦伙軍官計算彈性人數15人。這樣一個月最多只會浪費了10350元(30元*15人*23天=10350元)。

和改善前相比,精算開伙人數的效應是省下了13800元,這筆錢在月底的慶生會就能發揮用處了!

長鞭效應的差異


其實在軟體業也會有類似製造業供應鍊長鞭效應的問題,但情況稍有差異:
產業供應鏈差異處軟體開發
下游訂單發生點上游需求
逐級預防缺貨發生原因逐級延遲/延後
過度生產和存貨結果軟體品質不佳、時程延後、增加人力成本

以我們公司目前的軟體的開發過程:
  • 上游「硬體部門」 member 負責開發硬體,並依照硬體的開發進度,告訴中游的同事需要在模擬器內模擬的功能(提出需求)。
  • 中游「模擬器」 member ,在接收了需求後,會依照Spec文件,在模擬器內實作出這些功能,使得模擬器能模擬出與硬體的功能相符的結果;並告訴下游 member 這些功能的interface。
  • 下游「前端IDE」
    下游的 member 知道了interface後,要在IDE的前端作出這些interface的GUI,讓User可以透過GUI,將命令傳到後端的模擬器模擬出這些功能。

軟體開發長鞭效應的結果1-軟體品質不佳、時程延後


當我們把實際的情況套入軟體的開發過程後就發現問題了。

在前一版軟體 Release 後,我們就一直內部討論下一版軟體的內容。

但即使軟體內容確定,也確定下一版軟體 Release 的時間在六月底,但上游 member 並未凍結這個內容,反而隨著外在環境、與內部開發的情況,一直在改變軟體內容。

有時是為了某個客戶的要求,而必須新增客戶需要的功能;有的時候則是硬體上的限制、或缺陷,為了讓程式在硬體和模擬器上表現的行為一致,所以得用軟體修正硬體的Bug,以符合一致性的要求。

這些變動使得下游的 member 一直無法決定該版軟體實際的GUI介面,搞得在最下游負責V&V的我,為了避免重覆測試,得一直將測試時間向後遞延,以避免因為實際需求變更而重覆測試。

當這個軟體內容一直到 Release 前二十天才總算確定時,最大的影響是壓縮到最後面V&V的時程竟然得在一個星期內作完。

但實際上這有執行上的困難;即使我執行了,軟體品質就能提高嗎?

軟體開發長鞭效應的結果2-增加人力成本


我當然理解,在軟體開發的過程,需求本來就會隨著實際變化作修正,但這些修正理應要記錄在文件內。

但我們公司缺乏「文件版本控制」機制,上游的 member 始終沒有控管文件版本並發布,這才導致下游的 member 仍依照舊版文件實作軟體。一直要等到匹配後發現錯誤,一追查問題,才知道是上游的某些關鍵資訊已經修正或更新,卻未通知下游的 member 。

因為不斷地發生類似的錯誤,使得公司的人力配置,一直耗在這類非關鍵的地方。常見的情況是才剛花時間作完的東西,卻可能因為一句話、一次小修正,就導致下游的 member 得重作、甚至將完成的產品棄之不用,既浪費時間、也浪費人力。

軟體開發長鞭效應的解法


我一直思考「難道我們不能一次解決這類的問題嗎?」

後來,我發現長鞭效應的問題並不在揮動鞭子的動作,而在鞭子本身,也就是軟體開發的過程。原來是因為我們沒有做好軟體開發過程的某些關鍵活動,才讓小問題透過長鞭效應而逐級放大成更嚴重的問題。

所以我歸納了該做的事,能徹底解決一直困擾我們的問題:
  • 需求管理
  • 建立開發流程
  • 文件版本控制
  • 型態管理

需求管理


其實「需求管理」已經不只是軟體開發專案的範疇了,也是所有專案管理的重點。

在我遇到的情況中,已經不只是在軟體開發層面把描述清楚這樣簡單,還得考量商業機會與內部資源。有時,非得要在某個特定時間點完成特定的功能,才能達到商業目的,對公司產生實際的助益。

有時,也得砍在某個時間點(Feature Freeze Date),因為資源永遠有限!否則軟體永遠沒有完成的一天!

建立開發流程


在還沒導入 ISO 系統前,我們公司並沒有制定嚴謹的開發流程。但即使未來導入ISO系統,也因為我們的管理階層一直很擔心在執行了制定的開發流程後、會使我們的軟體開發效率降低、和人員反彈,甚至導致人員離職,所以一直在推行軟體建立開發流程上有所顧慮。

我曾經和同事討論這個問題,我們的結論是:一個錯誤的開發方式,即使效率再高,也只是很有效率的產出有問題的產品。

這句話說來殘酷,但一針見血的點出了目前軟體開發部門的情形。

我們的主管一直要求有效率的開發,結果卻導致我們不斷浪費時間用錯的方式作錯的產品,然後再不斷的花時間去修正,這個情況我已經在《軟體開發的遭遇戰》中已經說明。

文件版本控管


要做好「文件版本控管」,必須先有嚴謹的開發流程,才知道在開發流程的不同階段執行該完成的事,每個階段的作業才能依照上個階段的產物進行開發,這樣作「文件版本控制」才會有意義。

但是,我們公司的管理層一直輕忽建立開發流程,自然也無法要求 member 在何時必須產出那些必要文件。

因為我們的管理階層認為:寫文件是一件浪費時間、金錢的工作。影響上遊的開發人員並不會在規畫、構思階段就寫出必要的設計文件,並先想清楚自己的工作內容。最後導致上游的開發人員無法產出一份能對下游同事說明的文件。

當SQA要去Verify這些功能時,就只能依靠僅僅數頁在開發前期、為了討論設計內容而作的Power Point檔、和口述片斷資訊來制定Test Plan/Case,但這些片斷資訊卻不足以讓SQA去V&V這些實作出的功能。

但即使有了文件,也做好版本控管,事情也只完成了一半,另一半得靠文件的公告、發布,才能讓必要的相關人員,了解這些關鍵文件,不過,這已經是後話了。

型態管理


「型態管理」(CM, Configuration Management)是在CMMI Level 2就要執行的項目,可見這個工作是相當基本且重要的工作。

「型態管理」是系統生命週期內從頭到尾,針對硬體、軟體、韌體、以及文件所做的變更(包括其衍生出的紀錄)的管制。和「版本控制」不同的是,「型態管理」著重持續追蹤內容的變化過程記錄。

型態管理的過程,含括了一個變更管理的過程:提出的變動編號、內容、相應改變的評估(變動輻度、人力評估、時程的影響、可能的影響與風險、變動方式、方案評估)、變更的確認(客戶、執行單位)、相應所需的其他變更內容(如:相關文件、測試個案)。

不過,我們公司既然欠缺需求管理、尚未建立開發流程、也未完成文件版本控管,自然也無法達成「型態管理」。這導致我們根本無法追蹤每個版本的變化及其影響,最後當然無法了解每個版本實際的情況。

小結


以上這四類的問題在小公司、以及新公司特別常見。

小公司往往因為案子規模不大、金額不高、時程緊迫,導致無法落實這些看似無用的活動;新公司則因為未建立有效的開發流程,使得其他三項工作無法有效達成。

但如果真的以總成本(開發成本 + 維護成本),更應該得這麼做,只是管理階層始終不這麼認為!
  1. MBA智庫百科-長鞭效應
  2. 青空-長鞭效應
  3. Wiki-型態管理
  4. Wiki-版本控制

1 則留言:

  1. 大公司也是一樣常見,台灣軟體沒幾個像樣的

    回覆刪除