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


    [上一篇]

    上一篇的階段式方法,為了因應專案進度難以被精準掌握的狀況,有人提出所謂的三點估計法來做為解決方案之一,我的看法是,如果開發人員對一項工作估算一個時間都估不準了,那麼要求開發人員估算三個時間,然後分別叫它們為「最樂觀」、「最悲觀」、「最可能」,這又有什麼意義呢?不都是「不準確」嗎?那又何必浪費開發人員的腦力去傷這種腦筋呢?

    好了,就算開發人員真能對各功能的工時估得八九不離十,在實際工作的時候,各式各樣的干擾、中斷、意外等,也會讓原始的工時估算變得異常地不可靠,現實的情況是,開發人員是靠夜間和假日加班來補償這些部份,以趕上進度的!

    在《敏捷方法的成功密技:未完成的用戶故事的進度怎麼算?》一文當中我談過,就算開發人員天天或週週在回報進度百分比,其實那個百分比進度也只是個假的資訊!這並不是在說開發人員在矇騙專案經理,而是現實上傳統式專案管理(不論是瀑布式還是階段式)就是沒有一個簡單可靠的好方法,能讓大家有所依循,準確地跟催進度!這就是為什麼我們這麼難以精準確實掌握專案進度的主要原因之一。

    敏捷式方法

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



    由於市場應用的快速多變和競爭,IC 設計的複雜度也愈來愈高,時程要求也愈來愈短。因此,現在的 IC 設計早已透過像 Verilog 這樣的高階抽象描述語言來描述晶片內的邏輯電子電路(就像是用 Java 程式設計語言來設計軟體一樣),再用 FPGA 這樣的模擬器來測試和驗證晶片的設計(就像是把 Java 程式放進 Java Virtual Machine 去執行運作一般),以節省製作許多實體的電路板或實體的晶圓等所需要的巨大金錢和時間成本。

    所以,晶片的功能其實也早就可以被模組化地拆分,然後分派給不同的邏輯電路設計人員來分頭設計、測試、驗證。但是,這些邏輯電路模組,還需要被各自的應用軟體來驅動和使用,整個模組的功能才能算是完善。因此,將各模組的邏輯電路設計、測試、驗證人員(即本案例公司之 IC Design 團隊),與相關的應用軟體開發、測試人員(即本案例公司之 FAE 團隊)組成一個全功能的敏捷開發小隊(Scrum Development Team),顯然是合理可行的!

    敏捷開發小隊形成之後,這個團隊就可以依照 Scrum 的指導原則來運行。因為 FAE team 的成員是最經常對客戶溝通的窗口角色,所以理應和產品經理一樣,是最能理解客戶需求(包括功能規格、功能開發優先序,和各功能的交付時程)的角色。因此,個人認為,FAE 成員是最適合擔任敏捷大師(Scrum Master)角色的人。這麼一來,敏捷大師既擁有客戶同理心,可以向小隊外的產品負責人(通常可由產品經理擔任)溝通功能需求的開發優先序,又具備相當的技術能力來在小隊內部做各種設計的取捨建議、障礙排除的溝通,以及時程的控管。

    至此,產品負責人敏捷大師開發團隊這三項敏捷方法的主要角色就皆已到位了。接下來就是,必須將這些小組聚在一個辦公空間內,一起朝夕相處地工作。當然,相關工作所需的儀器設備(電腦、FPGA 等),也必須要安置在這個辦公空間之內。如此一來,所有的成員都能夠用最高效的方式溝通、討論所有的議題,敏捷方法大概也就成功了一大半了。

    再來就是充分透明地展現全員的工作狀態。作法可以快速參考《想導入敏捷式方法,我該怎麼跟老闆溝通?》這篇文章,再詳細參考其他的《敏捷方法的成功密技》系列文章。別小看這個透明度展現的部份,它可是整個敏捷團隊是否能夠得到高層主管的高度信任和授權、進而激發出自我紀律要求與榮譽感,達到團隊高凝聚力的重要關鍵。透明,是一切信任的基礎,包括對客戶!

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

    當然,每個組織的文化、人員的能力和意願都不盡相同,導入 Scrum 敏捷式開發與專案管理方法的實際做法上,當然也得做出不同的階段性調整和適當的取捨,可千萬別遇到障礙就輕言放棄喔!