※ 引述《eori (浮光掠影)》之铭言：
: 刚任职某间公司的SA一个多月,
: 隔壁的同事临时接一个专案, 作到奇摩子差，
: 他就离职了..然后工作由隔壁的同事继承, 就是我.
: 因为我有一些SA的经验,
: 自忖案子都是可以解决的吧～
: 隔壁同事未免太不耐扛了吧.
: 结果我接手后,
: 发现还真的事有蹊跷.
: 主管他做情要求的是“一步到位”！
: 比如要设计一个画面, 要一步位,
: 意思是, 一交出就是完美的东西.
: 完美的意思是, 让主管无话可说, 也让客户连连称赞!
: 文件没有错字只是基本,
: 重点是系统的交互设计上, 也是要100分,
: 没有80,90分这种东西存在.
: 因为我临时参与到这个案子,
: 跟主管反映我需要时间和空间，
: 是否可以先交出来一个可行的版本.
: 主管的意思我理解的是：
: 没有可行解, 只有最佳解！
: 时间不够是你的事,
: 因为你是资深的,应该要做到,
: 做不到就是你能力不够.
: 我喜欢敏捷开发的想法, 先求有再求好.
: 主管的想法是: 只求好.
: 在没有时间和空间的情形底下,
: 一步到位真的可以实现吗?
敏捷开发才不是这样勒，敏捷开发是在开发上相对于瀑布流开发，传统开发要先做需求访
谈、定义需求、设计、实作、测试整合、移交文件跟维护。
敏捷开发变成需求、设计、实作、测试周期变得更短，更有弹性应对客户变更需求，可以
做一部分后让客户实际体验在决定下一步。传统开发方式也会没有最佳解，完全看你的需
求跟面临的solution，传统开发方式一样可以跟客户提出阶段解决问题的方法，只要在需
求访谈跟定义需求的时候能明确让客户了解到就好了。
比方说，我们设计一个智能模型，当下资料打标签的样本不够，但是你可以跟客户讨论正
式上线后依然会逐步提升效能。
软件工程这种东西没什么唯一解，完全要看你的情境，传统开发也会有需要改版的状况，
很有可能当初在讨论需求时会觉得说现阶段系统就可以承载负荷，但是上线一段时间后却
超出预期，需要提升系统承载流量的状况。也有可能会有客户等到实际上线后发现某些功
能虽然当时按照需求开发，也符合客户的使用体验，但是实际上上线以后却接收到大量回
报，最后想变更需求的情况。甚至还有自家产品也会遇到内部测试体验都很好，实际上线
却有问题的。
最后，我只想说不管哪种开发模式都是指开发上的，开发跟设计是两件事。