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