溝通 特別是面對面溝通

[Anthony Tsai]

先前還沒進入研究所就讀時 , 在神來也是負責做德州撲克的遊戲功能設計以及除錯 , 那時候在公司就有聽過其他遊戲企劃以及工程師在討論別款休閒遊
戲 , 那是我第一次聽過agile這個字眼 , 不過那時候也只是很粗略聽到大家在談敏捷式開發 , 那時候的印象就只是 “很快的做出一個系統的模
型 , 然後再慢慢去改 , 大家直接提出意見去做討論”。當時一進去新人也是從小東西開始做慢慢改 , 所以根本沒想過也不用擔心碰到中大型專案的一
天 , 後來就有些小問題開始出現 , 因為要去讀別人所寫的東西 , 雖然有文件可以看 , 不過文件上面所寫的常常跟code裡面寫的內容不一
致 , 反而造成更難閱讀 , 又或者常常碰到的狀況是遊戲企劃寫了需求文件 , 但是工程師做出來的卻不是企劃想要的樣子 , 有時候覺得直接看文件
就好了 , 就缺少了面對面的溝通 , 效率反而降低了不少 , 還有員工位子的安排也是一個很重要的因素 , 先前工程師跟企劃是坐在隔壁桌而
已 , 後來調到比較遠的地方 , 雖然說現在即時通訊軟體非常方便 , 但跟面對面直接溝通比起來 , 還是差了一截 , 有時候也會因為位置太遠的
關係 , 就只在MSN上討論 , 有時候問題的重點或癥結點就沒有去發現。
在讀過agile ppt教材之後 , 發現有很多可以學習的地方 , 其中滿強調面對面的溝通來取代傳統大量的專案文件方式 , 大型專案只需要一份
簡單的文件就夠了 , 真的能節省很多不必要的時間與精力 , 教材中也有提到pair-programming(1+1 > 2) 在討論的時候滿有
幫助的 , 以前在學校分組的時候 , 有遇過兩人一組的分組報告方式 , 彼此可以提出自己的意見 , 同時在對方提出意見時還可以順便修正自己的看
法 , 例如找出程式中的BUG等等 , 但是自己的經驗發現如果討論的人一多起來 , 很可能就會變得非常沒有效率 , 因為大家雖然都各自提出自己
的意見 , 但是因為人數一多 , 東西就難以整合再一起 , 非常沒效率 , 此外 , 雖然pair-programming可以大幅提升專案品質
以及效率 , 但是在工作中很少見到有公司採取這種方式運作 , 因為老闆會想節省人力 , 通常都是把兩人份的工作丟給一個人做 , pair-
programming中的溝通討論 , 可能會被老闆當作是不認真工作。
在開發中大型專案時 , 設計草圖以及虛擬碼就顯得很重要 , 好處在於可快速塑造專案雛形 , 且虛擬碼不需實際寫出code , 在閱讀上可以更加
的簡潔 , 可以拿來當作流程圖使用 , 另外在實際撰寫時 , API的運用就很重要 , 有些人會強調程式裡面的code都是自己一行一行所寫出來
的 , 但其實沒有必要這樣 , 因為很多東西其實已經有人寫好且分享出來了 , 以前在寫Perl的時候 , 有個網站叫
CPAN(Comprehensive Perl Archive Network) , 裡面存放著世界各地的人所寫的模組 , 這些程式碼都是經過
詳細的測試 , 若能拿來有效利用 , 遠比自己重新開方要來的好太多了 , 此外 , 軟體的品質要好 , 測試是一個不可缺少的環節 , 常常程式
更改或者是維修之後 , 沒有重新測試 , 又或者是測試的不夠嚴密周到 , 使得軟體本身的品質低落 , 因此在專案開發到一個雛型時 , 先找出所
有的測試情況與使用情節 , 只要程式一有更改 , 便重新再跑一次完整測試流程 , 才能確保軟體品質。
在工作中常常會需要修改別人的程式 , 如果能善用pair-programming , 這樣一來 , 彼此都能了解對方的程式思維 , 要改起來就
容易的多 , 傳統方式都是看一堆繁雜的文件 , 因此常常會有一種要我改別人的程式 , 倒不如重新寫算了 , 所以大家都很不想去維護其他人所寫的
code , 再加上用先前所提到的設計草圖以及虛擬碼 , 使得專案的細節容易閱讀 , 能夠使得之後的維護人員能夠快速掌握專案內容 , 也能參考
虛擬碼去閱讀及修改 , 若能加上小組式的溝通 , 使得每個成員之間都能夠培養高度的信任感 , 這樣每個人都樂意去改別人的code , 也能使得
團隊合作間更有默契 , 整個專案的品質才能夠向上提升 , 而不是煩惱專案會被夥伴扯後腿 , 進而影響整體專案的進度時程。