Site icon Soul & Shell Blog

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 幹話貼紙:

會寫 Code 啊不就好棒棒

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

高雄敏捷開發啤酒節

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

Exit mobile version