内容简介：今天要分享的遊記比較特別， 這個景點都是靜態的，而且對文青來說可能有點悶，內容比較適合 RD 宅閱讀，失眠也可以透過閱讀本文幫助入眠。由於我生活在高雄，從事軟體相關開發相關工作好幾年了。相對於台北，高雄軟體產業的發展規模較小。雖然軟體產業工作沒有地域限制，但是軟體依然非常重視資金、市場與技術聚落等等效應，大部分的大型軟體公司與研發中心都會選擇設立在台北。南部高雄的軟體開發相關社群與研討會也不像北部那麼多，所以有機會就鼓勵各位軟體開發同好盡量參加與支持囉。今天參加的「
敏捷存在生活的每一天
今天要分享的遊記比較特別， 這個景點都是靜態的，而且對文青來說可能有點悶，內容比較適合 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 幹話貼紙：
其他場還有玩了很多敏捷開發的遊戲，中午吃完便當也喝主辦單位提供的酒精飲料，研討會有提供啤酒真的很狂：
整體來說活動辦得很好，聽了許多對軟體開發有強烈熱忱講師演講，每次參加都會被那種熱衷的氣氛所感染。對我來說敏捷思維，不應該只是儀式，應該是一種信仰，一種做事與生活的方式，即使不是軟體開發，也能貫徹這種精神！供勉之～
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
