2018 高雄敏捷之旅 - Agile Tour Kaohsiung

敏捷存在生活的每一天

今天要分享的遊記比較特別， 這個景點都是靜態的，而且對文青來說可能有點悶，內容比較適合 RD 宅閱讀，失眠也可以透過閱讀本文幫助入眠。

由於我生活在高雄，從事軟體相關開發相關工作好幾年了。相對於台北，高雄軟體產業的發展規模較小。雖然軟體產業工作沒有地域限制，但是軟體依然非常重視資金、市場與技術聚落等等效應，大部分的大型軟體公司與研發中心都會選擇設立在台北。南部高雄的軟體開發相關社群與研討會也不像北部那麼多，所以有機會就鼓勵各位軟體開發同好盡量參加與支持囉。

今天參加的「 高雄敏捷之旅 」是第二屆，在會議中聽了很多關於軟體敏捷開發的故事，會場也賣很多軟體開發相關的書籍，一不小心就買了幾本書：

今天的議程如下：

這一天完了不少遊戲，聽了不少演講。來歸納一下今天聽到的幾個心得，順便在 Blog 記錄一下。

產品 (專案) 失敗的八大原因

分享一下「新加坡商鈦坦科技總經理 李境展」大師所分享的「跟我的失敗致敬」主題，其中提到的產品失敗的幾個原因：

1. 缺乏真實情境與環境測試
2. 缺乏從客戶來的即時反應
3. 對於產品需求的誤解，錯估整合開發的時程
4. 第三方服務的品質及時程控制不易
5. 團隊不清楚開發進度現況
6. 產品需求被持續修改
7. 不確定的新技術能力及對產品知識的缺乏
8. 無向心力與達標決心的團隊

上述提及的失敗原因，相對於 產品開發 我覺得在 專案執行 更為貼切。對我而言，產品與專案是不一樣的，專案必須有明確的目標 (一定要符合 SMART 原則 )，但 產品開發 對於目標卻是很模糊的，因為成功的產品目標並不是開發完成就是完成，而是產品達到 PMF ( Product Market Fit ) 的狀態。

關於上述的失敗原因中我相當認同，先簡單檢討一下每一點：

缺乏真實情境與環境測試

一開始就建置持續整合系統是必要的，我們往往把測試工作放在開發完成最後的階段才進行，是錯的！一但遭遇軟體開發迭代 (階段) 時間很長時，就會存在了很大的風險，在最後一刻砍掉重練是很慘的。一般我們會在專案一開始，就建置持續整合與佈署測試環境自動化，並且盡可能與產品上線保持一樣環境，才有辦法做到持續交付、測試

。

缺乏從客戶來的即時反應

這個原因與第一項有關係，如果你沒有辦法提供即時的測試環境與當下的開發狀態，功能都是在最後完成才交付到客戶手上，必然無法獲得客戶即時的反應。即使功能做得很好，但不是客戶想要的需求， 無法解決問題的功能注定要作廢 。透過敏捷開發中的「Small Release」實現 小版本交付 到客戶手上，隨時將開發的功能與客戶的需求做驗證，如此失敗的成本會大大降低。

對於產品需求的誤解，錯估整合開發的時程

軟體開發有一個工作叫做「需求發展」，這項工作會將需求轉變為實際的功能與規格，有了 可能明確 的功能之後，我們就會進行開發時程的評估。要如何才能更準確地估算時程呢？在「 The Clean Coder 」一書中有提及，將工作切分的越細，可以降低每一個 Task 錯估時程對整體專案的影響與衝擊。所以我們才會在 Scrum 裡頭的每一 Task 去注意是不是太長了 (超過兩天)，是不是需要切割！？

軟體開發相當複雜，除非你這個系統已經開發過一次，才會有絕對豐富的經驗，否則估不準是正常的 (反正 Dead Line 到了軟體自然會好)。因此我們才需要敏捷開發，透過短時間 (或許兩週) 的產品迭代，降低錯估時程的對於整個案造成的影響。

第三方服務的品質及時程控制不易

特別是比較大型的專案進行時，往往會有第三方廠商的參與，第三方廠商有時候就很難控制專案風險。特別是交貨品質不良、溝通成本過高、關鍵路徑延遲等等問題。我遇過很多大型專案都是大公司得標後，然後外包外包再外包，真正執行的團隊已經距離使用者需求太遠，整個程式的品質往往不佳，發案方說不清楚要做什麼，接案方也不清楚自己在做什麼，專案風險往往高的誇張。

團隊不清楚開發進度現況

「透明」就是管理的根本 (Scrum 三隻腳之一)，一但所有事務無法透明，就缺乏彼此的信任，協作時就需要花上更多時間溝通，以取得信賴。透過敏捷方法論中的 站立會議 ，每天同步團隊成員彼此的工作狀態，對專案執行來說是有幫助的。如果專案進度原本是定在每一次交付才進行盤點，透過站立會議將可能縮短為每天盤點，監控頻率變高，漸漸讓團隊成員養成自我管理、自我驅動的特質 (小精靈模式)。

產品需求被持續修改

在軟體開發中「需求變更」是最惱人的問題，需求改變會直接影響到成本與專案時程。在敏捷思維中，團隊應該擁抱變化，相對於 產品開發到 PMF 的過程，面對市場需求變更是合理的。但是在專案的情況下，需求變更變成為恐怖的時程殺手，如同時程預估的困難一樣，我們都是在開發一項以前沒有開發過的系統，需求有時候做了才會想到問題，然後直接影響反映到原本的計畫上。

遇到專案時程落後，增加人力是最直覺的問題解決辦法，但是增加人力並不能完全解決問題 ( 與熊共舞 一書提及)，或者是說能幫助的效果有限。對我而言，砍需求或技巧性地規避需求，才是最有效的辦法。

不確定的新技術能力及對產品知識的缺乏

RD 使用當前最酷炫的技術是必要的！笑～XD～當專案使用了以前沒有深度掌握的技術時，絕對會提高專案的風險，有時候一個 Framework 的雷就可以炸掉整個系統。初期需要警慎的評估新技術的使用，也需要確認團隊中有足夠能力的神人，可以讓技術風險發生時，幫助團隊度過難關。

對於產品而言，我覺得沒有掌握市場 Know-how 是一件相當危險的事，單靠著創辦人的 Idea 創造市場需求來開發功能，很有可能會讓船走在錯誤的道路上 (船應該駛在海上)，還容易再次犯下某個領域大家都知道的錯誤，相當不切實際。

無向心力與達標決心的團隊

這一點我實在沒辦法評論，會發生這個原因基本上已經行屍走肉，大概是欠薪兩個月才會出現的情況吧…

敏捷之旅戰利品

每次參加會議，都是拿了一推貼紙。這次比較特別，拿了許多 RD 幹話貼紙：

其他場還有玩了很多敏捷開發的遊戲，中午吃完便當也喝主辦單位提供的酒精飲料，研討會有提供啤酒真的很狂：

整體來說活動辦得很好，聽了許多對軟體開發有強烈熱忱講師演講，每次參加都會被那種熱衷的氣氛所感染。對我來說敏捷思維，不應該只是儀式，應該是一種信仰，一種做事與生活的方式，即使不是軟體開發，也能貫徹這種精神！供勉之～