「老師，聽說 Scrum 敏捷式產品開發方法比較適合軟體產品開發，可是我們公司的產品是 IC，硬體的成分居大部分，軟體開發人員大都是在最後階段才參與產品的開發，這樣還適合導入 Scrum 敏捷式產品開發方法嗎？」
前些時候，跟一些客戶做課程對焦的時候發現，似乎有愈來愈多的 IC Design 公司對於敏捷式專案管理方法感到濃厚的興趣，只是，課程承辦人資與需求單位的主管對於這個「新」管理方法多半感到陌生和誤解（軟體產業專屬）而頗有猶豫，不知道自己這樣類型的組織和工作，到底適不適合來導入 Scrum 敏捷式產品開發與專案管理方法。
半導體產業一直是台灣的領導產業之一，相關的軟硬體從業人員更是為數不少，而這每位從業人員的背後，可能都是一個平均兩三口左右的家庭。如果我們能夠找到辦法提升這個產業的產品開發速度，和專案管理的效能，同時創造出滿意的客戶，那麼，整個產業的競爭力就能得到更大程度的提升，進而帶動整個生態系統更多的正向發展。
只是，有沒有一種管理方法，能夠協助達到這個境界呢？其實是有的，在國外，Scrum 敏捷式產品開發與專案管理方法，早就被實證能在這些面向上做出巨大的貢獻。
在台灣，很多公司仍在使用傳統的瀑布式方法（Waterfall）來開發產品和管理專案，有些先進一點的公司，會採用階段式方法（Phase/Iteration）來做，但是，我們卻不常聽到 Scrum 敏捷式方法被採用在產品開發和專案管理上。
剛好我對於某家影音多媒體晶片設計公司的組織與晶片開發流程略有了解，我就以此公司為例來說明，採用這三種形式的專案管理方法各會有什麼優缺點好了。
一. 瀑布式方法
早期這家公司採用典型的瀑布式方法來開發晶片，大致的流程像下圖這樣：
採用這種方法的缺點，非常顯而易見，例如，
- 絕大多數時候，下一手功能團隊必須等上一手功能團隊完成工作，才能開工，專案的時程相對就會拉得比較長。
- 一旦上一手功能團隊的工作被完成之後，下一手功能團隊（或客戶）往往也就沒啥機會去建議上一手功能團隊做些變更，阻礙相對很大。
- 上、下手功能團隊之間的溝通質量和頻率非常有限，不利於技術和知識在組織內擴散，對產品設計誤解及因此導致重工，機率也非常地高。
- 上一手功能團隊延誤交件，下一手功能團隊就要被迫加班趕工補償延誤。上一手功能團隊的成果品質不良，下一手功能團隊就要想辦法彌補這些缺陷，因為上一手功能團隊的成果已經改不動了。也因此，團隊之間發生衝突和劃地自限的情況就會大為增加。
舉個例子來說，像 FPGA 模擬器這種昂貴又稀缺的設備，就可以先讓 IC Design 團隊全權使用，等邏輯電路都設計完了，也在 FPGA 模擬器上模擬驗證完了，FPGA 模擬器就可以交給 FAE 團隊來使用，測試相關的軟體模組和邏輯電路的匹配，驗證軟硬體整合後的功能是否無誤。這樣組織就不用花大錢準備多套 FPGA 模擬器了。