※ 引述《eori (浮光掠影)》之銘言：
: 剛任職某間公司的SA一個多月,
: 隔壁的同事臨時接一個專案, 作到奇摩子差，
: 他就離職了..然後工作由隔壁的同事繼承, 就是我.
: 因為我有一些SA的經驗,
: 自忖案子都是可以解決的吧～
: 隔壁同事未免太不耐扛了吧.
: 結果我接手後,
: 發現還真的事有蹊蹺.
: 主管他做情要求的是「一步到位」！
: 比如要設計一個畫面, 要一步位,
: 意思是, 一交出就是完美的東西.
: 完美的意思是, 讓主管無話可說, 也讓客戶連連稱讚!
: 文件沒有錯字只是基本,
: 重點是系統的交互設計上, 也是要100分,
: 沒有80,90分這種東西存在.
: 因為我臨時參與到這個案子,
: 跟主管反映我需要時間和空間，
: 是否可以先交出來一個可行的版本.
: 主管的意思我理解的是：
: 沒有可行解, 只有最佳解！
: 時間不夠是你的事,
: 因為你是資深的,應該要做到,
: 做不到就是你能力不夠.
: 我喜歡敏捷開發的想法, 先求有再求好.
: 主管的想法是: 只求好.
: 在沒有時間和空間的情形底下,
: 一步到位真的可以實現嗎?
敏捷開發才不是這樣勒，敏捷開發是在開發上相對於瀑布流開發，傳統開發要先做需求訪
談、定義需求、設計、實作、測試整合、移交文件跟維護。
敏捷開發變成需求、設計、實作、測試週期變得更短，更有彈性應對客戶變更需求，可以
做一部分後讓客戶實際體驗在決定下一步。傳統開發方式也會沒有最佳解，完全看你的需
求跟面臨的solution，傳統開發方式一樣可以跟客戶提出階段解決問題的方法，只要在需
求訪談跟定義需求的時候能明確讓客戶了解到就好了。
比方說，我們設計一個智能模型，當下資料打標籤的樣本不夠，但是你可以跟客戶討論正
式上線後依然會逐步提升效能。
軟體工程這種東西沒什麼唯一解，完全要看你的情境，傳統開發也會有需要改版的狀況，
很有可能當初在討論需求時會覺得說現階段系統就可以承載負荷，但是上線一段時間後卻
超出預期，需要提升系統承載流量的狀況。也有可能會有客戶等到實際上線後發現某些功
能雖然當時按照需求開發，也符合客戶的使用體驗，但是實際上上線以後卻接收到大量回
報，最後想變更需求的情況。甚至還有自家產品也會遇到內部測試體驗都很好，實際上線
卻有問題的。
最後，我只想說不管哪種開發模式都是指開發上的，開發跟設計是兩件事。