由於自己沒有真的很理解過敏捷開發或 Scrum 到底是怎麼一回事，但公司的新專案又開始想要嘗試用這種方式來做 MVP，基於凡事問網友的心態，在 ALPHACamp 社群以及 Twitter 上得到了很多有價值的回饋，很感謝大家分享意見讓我知道。
我的問題大概是這樣的：
「想要請問大家所謂的敏捷開發？
團隊認為敏捷開發就是要快，不用管太多細節，先推出去收到市場回饋再來修改。但很多工程面的東西像是 DB 的設計，API 的規格的改動，添加幾個欄位還好，但若是動到比較大的架構改起來都很痛。
是真的想要了解大家在碰到這種情況是怎麼處理？因為我沒有深入理解過敏捷開發，不清楚在實際執行上的細節，只知道每次都說就是要快，先不考慮其他情況。
團隊認為敏捷開發就是要快，不用管太多細節，先推出去收到市場回饋再來修改。但很多工程面的東西像是 DB 的設計，API 的規格的改動，添加幾個欄位還好，但若是動到比較大的架構改起來都很痛。
是真的想要了解大家在碰到這種情況是怎麼處理？因為我沒有深入理解過敏捷開發，不清楚在實際執行上的細節，只知道每次都說就是要快，先不考慮其他情況。
是不是我們沒有掌握到敏捷開發的核心？還是具體來說有那些東西是可以很「敏捷」？哪些東西不適合嗎？
先謝謝有經驗到大家」
先謝謝有經驗到大家」
下面則整理大家的想法和意見。
:::caution
本人並沒有任何實際了解過敏捷或 scrum 的學習經驗，因此若有任何錯誤或想法，都歡迎提出並一起討論。
:::
本人並沒有任何實際了解過敏捷或 scrum 的學習經驗，因此若有任何錯誤或想法，都歡迎提出並一起討論。
:::
敏捷的重點在於快速應對市場需求變化的能力
首先，敏捷的重點在於快速應對市場需求變化的能力，同時也驗證自己對於產品能否達到市場需求的概念（Proof of Concept, POC），減少過多的時間或人力成本在開發某個專案，做到非常完整，但推出去之後才被市場打臉。
這裡直接 quote Jack Sung 所說的：
Jack Sung：「敏捷開發並不是短期的速度快，畢竟開發還是需要跑完基本的流程，而是面對市場變化的反應速度比起瀑布流還快，就像 POC(Proof of Concept)，敏捷開發是更務實的去驗證想法，而非一個美好的想像去花費很高的時間跟成本去開發一個未經驗證的產品，等到真的推上線才被市場賞兩巴掌。」
:::info
至於什麼叫「完整」或「非常完整」真的是非常藝術的問題，有的人認為東西可以 work 就可以推出，有的人認爲至少要通過自己這一關後才算可以，而設計、工程、一直到商業端每個人的想法也都不同。也許業務認為有東西可以賣就好，設計認為的會是這個產品拿出去可以見人嗎？工程思考的可能是產品夠不夠穩定，有沒有漏洞，資料庫後續如何修改等等。
:::
至於什麼叫「完整」或「非常完整」真的是非常藝術的問題，有的人認為東西可以 work 就可以推出，有的人認爲至少要通過自己這一關後才算可以，而設計、工程、一直到商業端每個人的想法也都不同。也許業務認為有東西可以賣就好，設計認為的會是這個產品拿出去可以見人嗎？工程思考的可能是產品夠不夠穩定，有沒有漏洞，資料庫後續如何修改等等。
:::
敏捷的目的是要提早發現問題：對象是市場而非開發團隊
之所以要敏捷是因為市場的變化太快速，因此當有產品沒有收到預期的回饋時，適時且立即的停止、停損或轉換方向是敏捷的重點與核心。
然而，這並不表示要壓縮開發時程或開發品質，如同 Yan 所說的，整個開發流程應該還是嚴謹可靠的，而不是隨便快就好的。
Yan：「敏捷開發不單單是針對開發團隊而是整個軟體工程，從訪談>需求>規格>設計>開發>測試>發布，整個流程應該還是嚴謹的，只是它縮小整個目標進行對目標進行快速迭代，中途有錯應該立即修改或終止，這是 scrum 所謂的「快速試錯」，而已經成型產品遇到要整個砍掉重來，長遠來說如果是必要，我也認同需要去做，根據我的經驗以開發來說敏捷並不會減少「開發時間」。」
敏捷開發不會比較快速：敏捷 != 快
如同上面所述，敏捷的重點是為了因應市場的快速變化，避免到後來才發現一場空。但這個敏捷並不是快的意思，該有的開發流程還是不能省，Rafeni 分享的這張圖我覺得很到位：
這裡直接引用 ALPHACamp 助教 Yan 所說：
Yan：「目標是造車，縮小目標往往會被誤認為先造輪子，但其實應該是「可用的」滑板車，因為只造輪子根本收不到市場/客戶回饋，根本無法知道產品方向對不對；壓縮開發時間＝壓縮開發品質，各種開發模式都是透過流程改善來減少時間成本，而非去壓榨單位去達到節省目的。」
每次開發出來的「可用的產品」，到底是要驗證什麼概念，是否能實際收到市場的回饋都是要考慮的問題。至於給人使用的「產品」和有功能就好的「東西」之間的界線要如何定義，又是另一門藝術了。
盡可能在開發時做到解耦、模組化
據 Jack Sung 所說，一般來說走敏捷開發對工程團隊來講是痛苦的，太多東西是無法預期或事先規劃的，因此打掉重練是常有的事，能做的是盡可能在開發時做到解耦、模組化，以減少這個痛。
畢竟以上圖來說，腳踏車和滑板車已經是完全不同的概念了，要做到擴充性和預留彈性幾乎就是不可能的事，所以要認知到打掉重練可能是必經的過程。
打掉重練是常有的事，但⋯再想想⋯
雖然說打掉重練可能是常有的事，但如果總是在經歷「整個」打掉重練，而不是部分功能或模組打掉，或是整個系統架構的調整，這時候就需要再多想想了。
如同前幾個段落中的金字塔圖（MVP）所示，在敏捷開發中並非省略掉開發流程來達到敏捷。Rafeni 提到，不應該打著敏捷開發就跳過了規劃、跳過了去思考產品是設計給誰用的、是要幫誰解決問題。 Jacob 則提到，PM 和 RD 溝通不良，或當問題都沒有先想清楚就馬上進到開發，產品設計沒有做好使用者研究時，常常才是導致架構需要不斷大改。
Rafeni：「因為起點對了，過程與終點才可能對。否則錯誤的流程也是會導致錯誤的結果的。」
也就是說，如果你覺得常常是整個系統在進行大架構的改動，甚至是經常感受到隕石擊落般的痛快時，那麼不要乖乖的抱著「打掉重練是正常的想法」，而是需要好好的再想想。