如何運用 Scrum 敏捷式專案管理到 IC 設計產品開發專案(上)


    「老師,聽說 Scrum 敏捷式產品開發方法比較適合軟體產品開發,可是我們公司的產品是 IC,硬體的成分居大部分,軟體開發人員大都是在最後階段才參與產品的開發,這樣還適合導入 Scrum 敏捷式產品開發方法嗎?」

    前些時候,跟一些客戶做課程對焦的時候發現,似乎有愈來愈多的 IC Design 公司對於敏捷專案管理方法感到濃厚的興趣,只是,課程承辦人資與需求單位的主管對於這個「新」管理方法多半感到陌生和誤解(軟體產業專屬)而頗有猶豫,不知道自己這樣類型的組織和工作,到底適不適合來導入 Scrum 敏捷式產品開發與專案管理方法。

    半導體產業一直是台灣的領導產業之一,相關的軟硬體從業人員更是為數不少,而這每位從業人員的背後,可能都是一個平均兩三口左右的家庭。如果我們能夠找到辦法提昇這個產業的產品開發速度、專案管理效能,同時創造出滿意的客戶,那麼,整個產業的競爭力就能夠得到相當程度的提昇,進而帶動整個產業生態系統的正向蓬勃發展,也能塑造社會向上成長的正能量氛圍。

    然而,有沒有一種管理方法,能夠同時達到上面講的這些效果呢?其實是有的,Scrum 敏捷式產品開發與專案管理方法,在國外,早就在這些面向上被實證,能做出強大的貢獻!

    我們知道,有些公司在整個產品的開發與專管理流程上,仍然停留在傳統的瀑布式開發方法(Waterfall)上,而有些公司則比較先進,採用了所謂的階段式開發方法(Phase/Iteration),但是,在台灣,會採用 Scrum 敏捷式開發方法的公司,卻不是很常能聽得到。

    有一家影音多媒體晶片設計公司的組織與晶片開發流程,我略有了解,我們就以此公司為例來說明,這三種形式的專案管理方法各有什麼優缺點。

    瀑布式方法

    早期的時候,這家公司是採用典型的瀑布式方法來開發其晶片的,大致的開發流程是像下圖所示:


    採用這種瀑布式方法的缺點,非常地顯而易見,那就是,
    1. 所有的功能團隊,絕大多數時候,都必須等到上一手的功能團隊完成其工作之後,才能夠開始自己的工作,專案的時程相對就會拉得比較長。
    2. 一旦前一手功能團隊的工作完成之後,下一手功能團隊(或客戶)往往就再也沒有機會建議上一手功能團隊去做些更好的功能變更!
    3. 上下手功能團隊之間的溝通的質量和頻率非常地有限,不但不利於技術與知識在組織內的擴散傳播,對於產品設計上的誤解和因此而導致的重工,機率也非常地高!
    4. 下一手功能團隊往往被迫為上一手功能團隊的延遲而加班,為上一手功能團隊的不良品質產出彌補缺陷,功能團隊之間發生衝突與劃地自限的情況大增!
    每一種方法一定都會有正反兩面,那麼,瀑布式方法難道都沒有一些好處嗎?

    當然是有的。舉個例子來說,昂貴少量的稀缺設備,如 FPGA 模擬器,就可以先讓 IC Design團隊全權使用,等到邏輯電路都設計完,也在 FPGA 模擬器上模擬測試完畢之後,FPGA 模擬器就可以交給 FAE 團隊來使用,測試其開發的軟體模組,以驗證軟硬體整合後的功能是否無誤。這麼一來,組織就不需要花費大量金錢去準備多套的 FPGA 模擬器,以讓各功能團隊能「同時並行」使用了!