https://blog.toright.com/wp-content/uploads/2018/12/IMG_1258.jpg

敏捷存在生活的每一天

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

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

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

敏捷開發相關書籍

今天的議程如下：

敏捷高雄之旅議程

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

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

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

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

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

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

缺乏真實情境與環境測試

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

缺乏從客戶來的即時反應

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

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

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

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

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

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

團隊不清楚開發進度現況

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

產品需求被持續修改

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

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

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

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

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

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

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

敏捷之旅戰利品

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

會寫 Code 啊不就好棒棒

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

高雄敏捷開發啤酒節

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

文章由 Soul & Shell Blog 轉貼, 原文：https://blog.toright.com/posts/6118/2018-agile-tour-kaohsiung.html