前兩篇文章（十八之一、十八之二）所提的瀑布式和階段式方法，都是傳統的專案管理方法，有人鼓吹，為了要讓專案工作的時間估得準一點，那就多估幾個時間值好了，分別叫它們為「最樂觀」、「最悲觀」、「最可能」，也就是所謂的「三點估計法」。

關於這一點，我的提問是，如果一個人對一項他沒做過的工作都「猜」不準所需要的時間了，那叫這個人多「猜」兩組時間，這樣就會比較準嗎？這不是畫蛇添足，脫褲子放屁嗎？

好，就算專案團隊可以對專案工作時間估得相當準，可是，實務上，各式各樣的干擾、中斷、意外等，都會浪費掉專案團隊很多的時間，讓這些原始的時間估算變得愈來愈不準確。現實的狀況是，專案團隊是靠晚上或假日的加班，來彌補這些被浪費掉的時間，來彌補這些延誤的。

在《敏捷方法的成功密技：未完成的用戶故事的進度怎麼算？》一文當中我談過，就算專案團隊天天、週週都在回報進度的百分比，可是，這個百分比進度其實也都只是個自欺欺人的假象。這並不是在說專案團隊在矇騙專案經理，而是現實上，傳統式專案管理（不論是瀑布式還是階段式）就是沒有一個簡單可靠的好方法，可以讓大家依循，準確跟催進度，這也是為什麼我們這麼難以精準掌握專案進度的原因之一。

三. 敏捷式方法

在《敏捷方法的成功密技》系列文章當中，我們其實已經陸續介紹了許多關於 Scrum 敏捷式方法的精神、施行技巧，以及可以如何緩解，甚至是徹底解決前述的那些問題。這裡我們就來看看，如果本案例的公司想要在專案管理更上一層樓，同時又想凝聚專案團隊的向心力，打造一個高效率的戰鬥團隊，可以怎麼做。以下就是一個簡化版的示意圖：

由於市場應用的快速多變，IC 設計的複雜度也變得愈來愈高，時程要求也變得愈來愈短。因此，現在的 IC 設計早就已經透過像 Verilog 這樣的高階抽象描述語言，來描述晶片內的邏輯電子電路（就像軟體工程師寫程式碼一樣），接著再把這些像軟體程式碼的東西，丟進 FPGA 模擬器去做測試和驗證，看看晶片的電路設計有沒有錯誤。如此一來，就可以節省大量製作實體電路板或實體晶圓的巨大金錢和時間成本。

所以，晶片的功能設計和驗證，其實也早就可以像軟體開發那樣，可以被模組化拆分，再分派給不同的邏輯電路設計人員來分頭同步進行各自的設計和驗證了。

但是，這些邏輯電路模組，還是需要被各自的應用軟體來驅動和使用，整個模組的功能才可以算是完善的。因此，把各模組的邏輯電路設計人員（即本案例公司之 IC Design 團隊），和相關的應用軟體開發人員（即本案例公司之 FAE 團隊）組成一個全功能的敏捷開發團隊（Scrum Development Team），顯然是合理可行的，然後這個敏捷開發團隊，就可以依照 Scrum 的指導原則來運行。

由於 FAE 的成員是最常對客戶溝通的窗口角色，所以理應和產品經理一樣，都是最能理解客戶需求（包括功能規格、功能開發優先序，和各功能的交付時程）的人。因此我覺得，FAE 就是最適合擔任敏捷大師（Scrum Master）角色的人。這樣敏捷大師就既有客戶同理心，又能和產品負責人（Product Owner，通常可由產品經理擔任）溝通需求的開發順序，還具備相當程度的技術能力，能在開發團隊內協助排除各種設計上或溝通上的障礙。

至此，產品負責人、敏捷大師、開發團隊這三類敏捷方法的主要角色就都到位了。

接下來就是，要將這些敏捷團隊聚在同一個辦公空間內，一起朝夕相處地工作。當然了，相關工作所需的儀器設備（電腦、FPGA 等），也必須要安置在這個辦公空間之內，這樣所有的成員就能用最高效的方式近距離溝通、討論所有的議題，敏捷方法也就成功一大半了。

再來就是要充分透明地展現全員的工作狀態。做法可以快速參考《想導入敏捷式方法，我該怎麼跟老闆溝通？》這篇文章。你可千萬別小看這個透明度展現的部份，它可是整個敏捷團隊是否能夠得到高層主管的高度信任和授權，同時激發團隊自我紀律要求和榮譽感的重要關鍵。「透明」是一切信任的基礎，不僅是對組織內的主管，也包括對組織外的客戶。

當每個敏捷團隊都能高度自我管理之後，負責不同晶片設計模組的多個敏捷團隊就可以再參考《敏捷方法的成功密技：中、大型專案可以導入 Scrum 敏捷式開發與專案管理嗎？》這篇文章的說明，定期產出整合各隊小成果之後的大成果，做為定期交付給客戶，做同步開發和驗證的用途。

當然了，每個組織的文化和人員的能力和意願都不盡相同，導入 Scrum 敏捷式專案管理方法時，當然也得做適當的調整和取捨，但，就是不能遇到障礙就輕言放棄！

原文轉貼自：威廉網紙（原文連結）