[心得] Agile 學習手冊 — 敏捷原則第二條
計劃趕不上變化…？
第二條：竭誠歡迎改變需求，甚至已處開發後期亦然．敏捷流程掌握變更，以維護客戶的競爭優勢．
沒有人喜歡變化．好不容易做好的功能要改，API 要修，都是很痛苦的事情．但是回過頭來想想，為甚麼要變化？環境改變？當時開的規格不符合需求？沒有想到？等等原因．再想想開發的目的是什麼？火力展示？還是為了提供客戶更好的產品？
如果客戶的需求變更是合理的，的確是對產品有幫助，那開發端沒什麼理由拒絕，評估好變更需求需要花費的時間提供給客戶參考，如果兩邊都 ok 就可以動手做了．客戶自己需求變更，也只好承擔開發時程延後的風險．
那如果從開發端來看這樣的問題，如果一開始就抱著需求有可能變更的情況，在一些程式架構，或系統架構，是不是能提供足夠的彈性做調整，未來在這部分假使需求改變，也不會花太長的時間調整？
比如說之前有個專案，一開始的需求是從 s3 上讀取 csv 檔案，所以一開始我的做法是讓使用者輸入網址，程式再自己從副檔名判斷是不是 csv 檔後再做處理．但是到了快 demo 的前幾天，突然發現除了 csv 檔案之外，也要能讀取內容是 csv 的 .gz 檔案．收到這個需求後，就開始想：
- 如果不能自動從網址判斷，就必須由使用者提供檔案格式
- input 如果多一個參數，相關的 function 有哪些要改？
- 後面處理檔案的地方有沒有辦法直接處理壓縮格式？
- 後面處理檔案的地方有沒有辦法處理其他種資料格式？
- 多一個參數要往後傳的話，哪些相關的 API 需要做修改．
開始改的過程中，需要注意：
- 針對新需求增加對應的 UnitTest
- 舊有的 UnitTest 要能通過
- 有沒有更彈性的做法來接受多出來的參數？（例如使用 **kwargs，或請外部傳一個 dict 進來．）
整個流程判斷下來，再到改完加測好的時間大概也只花了半天左右．（再次強調好的自動化測試帶你上天堂．）
敏捷本來就是為了擁抱改變而生的開發流程，什麼叫擁抱改變？
1. 要做出改變的時候，沒有人會覺得麻煩．公司最好允許成員經常犯錯並且改正，而不是期望第一次就把事情做到完美．
2. 大家都在同一艘船上．每一個人（包括客戶）都有各自需求，針對需求的變更是所有人一起承擔．
3. 儘早修正，讓傷害降到最低
4. 不再視改變為犯錯．大家總是盡當下的狀況做到最大的成效．
5. 改變是團隊成長以及打造優質軟體的最有效方法．
由於有這些原則，也才衍伸出像是 TDD 以及 DevOps 這樣的觀念和文化．由於要面對快速改變，又要保證軟體品質，寫好測試以及良好的自動化測試是不二法門．雖然廣式這點又可以再寫好幾篇了，但是要知道做這些事的原因都是因為來自敏捷原則，我們想更快的把成果交付給客戶，同時也透過快速迭代來適應變化．
