如今敏捷已经成为一个流行词，甚至软件开发之外的团队也试图将其纳入他们的工作流程中。但是敏捷并不适合所有人。
例如，营销机构永远无法实现敏捷，因为客户不想为半成品的营销活动和迭代买单。虽然有修改，但数量在合同中有明确的规定。另外，没有所谓的“工作增量”，你要么有可交付成果，要么没有。
敏捷也不一定是每个软件项目的正确方法。如果你不能接触到客户，不能迭代，或者你有个复杂的组织架构，那么就很难坚持敏捷原则。
敏捷在如下情况运转得最好：
◇ 你无法估算所需的时间，也不知道需求的全部范围
◇ 你不知道市场是否需要你的软件
◇ 你无法规划出业务需求，所以设计需要通过试验和错误来实现
◇ 你可以无限制地访问准备广泛参与的客户
◇ 你可以进行迭代，不需要一次交付功能齐全的软件
◇ 你和你的客户都没有复杂的官僚作风来拖延决策
◇ 客户没有固定的预算/计划
◇ 你需要在有任何竞争之前占领市场
◇ 你的客户在更新软件时不会遇到麻烦（或者根本没有注意到，例如，他们使用web应用程序）
正如你所看到的，与公司相比，敏捷更适合中小型组织。原因很简单：人越少，就越容易做出决定并对变化做出反应。此外，敏捷更适合产品公司而不是咨询公司。
敏捷对初创公司也很有用，因为“快速失败”是他们的
最低0.47元/天 解锁文章
1000
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
