C.C. Agile 56心得

April 28 15:55~16:49

 

昨天是C. C. Agile 第56次聚會，邀請服務於NEXCOM公司的Cobalt Chang分享Software Driven Hardware Development這個題目，談談敏捷開發如何應用於嵌入式系統開發中。

第一次認識Cobalt是在去年（2016）某一次C. C. Agile聚會，當時採用open space（開放空間）的形式討論敏捷開發的問題。Cobalt與他的主管和同事一起參加，Teddy剛好參與他們的討論小組，當下聽到了他們所遭遇到的許多問題，也聽到與會者給他們許多不錯的建議。

本以為活動結束就結束了，沒想到之後每個月Cobalt他們都來參加C. C. Agile聚會，在一次聊天當中Cobalt提到他們落實了幾項當初在open space活動中所聽到的建議之後，解決了不少團隊的問題。當下Teddy覺得很意外，因為說實話大部分的人參加活動聽到建議都只是「聽聽而已」，回去公司之後並不會採取什麼改善行動。沒想到Cobalt他們不但行動，而且還有不錯的改善成效，所以Erica和Teddy便邀請他們來C. C. Agile分享。更難得的是，Cobalt他們的產品是屬於軟硬整合的產業，在與硬體相關的產業落實敏捷開發相較於純軟體產業更加困難。

***

在Cobalt昨晚的分享中，Teddy聽到幾個很有幫助的做法：

• 以縮短交期（lead time）為做事原則：Cobalt他們採用許多Scrum實務做法與看板方法（Kanban Method）的精神，因為產品包含硬體設計，所以很難用iteration-based的開發方式在iteration開始的時候計畫這個iteration要完成的功能。因此他們採用看板方法的作法，針對專案的每一個工作項目，首先排列優先順序，在施工的時候運用各種方式儘量縮短每一個工作的lead time。因為觀念轉換，傳統上在硬體部門、韌體部門、軟體部門之間丟來丟去沒人管的工作，就由傳統工作流下游的軟體團隊一肩扛起，往上游追朔找與其他部門的人一起合作完成工作。
• 說對方聽得懂的語言：Cobalt在演講中舉了一個例子，他們有一個案子因為硬體的限制需要把網路速度控制在100M，但原本的硬體設計並不支援。如果軟體團隊跑去跟硬體設計師說：「請把硬體改成網路速度控制在100M」那麼硬體的人會不知道你在說什麼，無從改起。但如果你跟他說：「把某個接線跳到另一個接線」那麼硬體的人就知道該如何做，也會很樂意幫忙。
• 說明「為什麼」並請求協助：軟體團隊若只是一味地「指使」其他團隊的人改這個、做那個，對方可能會覺的「我為什麼要聽你的？」如果可以先跟對方說明遇到什麼問題，所以要做一些調整或改變，則比較容易得到對方的配合。
• PM很弱不一定是壞事：不管軟體或硬體專案，許多團隊都遇到「PM（專案經理）」有點弱（擺爛？！）的冏境，團隊成員除了碎念以外，還能怎麼辦？Cobalt提到其實團隊成員大可直接去面對客戶，既然PM不管事那就自己管，到頭來反而順利完成專案（自組織團隊的概念）。
• 把繁瑣的固定知識記錄在Wiki上：軟硬體整合的專案有很多關於設定的細節，如果設定錯誤便會造成系統無法運作。這些知識一定要在解決問題的當下趕緊記錄下來，以減少「重複學習」的浪費（精實開發的作法）。

***

Cobalt在整場演講中並沒有對於Scrum或看板方法作任何說明，而是用四個專案作為例子，告訴我們如何落實敏捷與精實開發精神。許多敏捷開發的初學者經常會糾結於「XXX算不算Scrum？」而忘了原本採用敏捷開發的原意—如何在競爭的環境中保持成功。Cobalt的演講以解決問題為出發點，選用任何可以幫助他們縮短lead time並保持持續改善精神的方法，是一場非常棒的分享。

***

友藏內心獨白：從人鬼殊途到通靈少女。