agile - 现成的软件如何适应敏捷开发？

Question

也许我对敏捷开发的理解没有达到应有的水平，但我很好奇当最终系统的需求和知识应该是什么时，敏捷开发人员可能会如何使用现成的 (OTS) 软件以我理解的速度变化（通常在每次开发迭代之后）。

---

我看到了两种我特别感兴趣的情况：

(1) OTS 系统满足初始要求集，除了可能集成到现有系统之外，几乎没有修改。然而，在开发的几次迭代中，这个系统在不重写核心代码的情况下已经不能满足需求。开发人员必须选择要么花更多时间学习此 OTS 软件背后的核心代码，要么将其丢弃并从头开始构建。两者都会对开发时间和项目成本产生巨大影响。

(2) 最初的需求不像任何现有的OTS系统可用，但最终当客户接受产品时，由于需求的增加和减少，它最终与现有的解决方案非常相似。如果开发人员有更多的需求并在前期花费更多的时间来解决这些问题，则可以使用此解决方案而不是再次构建。该项目已交付，但较晚且成本高于必要。

---

作为一名软件工程师，我的部分职责（正如我被教导的那样）是以尽可能低的成本（除其他外）按时向客户交付高质量的软件。敏捷开发允许高质量的软件，但在某些情况下，可能不明显有更好的替代方案，直到为时已晚并且花费了太多钱。

我的问题是：

1. 现成的软件如何适应敏捷开发？
2. 敏捷经理和敏捷开发人员如何处理这些情况？
3. 敏捷范式对这些案例有什么看法？

Answer 1

场景1：

无论组件的 OTS 特性如何，都会发生这种情况。敏捷并不意味着近视......你需要了解大块......框架位并事先花时间思考。也就是说，您只能根据您所知道的内容进行构建.. 仅延迟到最后一个负责任的时刻。然后您需要选择一个替代方案并开始使用它。（我会避免第三方应用程序，除非在内部开发它的成本是不可行的......但这只是我）。对多种解决方案进行原型设计，以检查已知需求列表的可行性。保持松散耦合（可替换），易于更改和全面测试。如果您要继续进行黑客攻击或重写，您需要考虑哪个对业务具有更好的价值并选择该选项。它下来了'现在我们在这里，什么'

场景2：

尽管与团队花费 2-3 个月试图“最终确定”需求但发现市场需求或客户的想法已经发生变化并且“现在我们希望这样”相比，这种情况发生的可能性很小。再一次，这是一个问题，即在采取行动之前，您准备调查和探索的时间点是多少。明智地决定你所拥有的任何信息。事后诸葛亮总是 20-20，但客户不会永远等待。您不能等到需求合并以适应已知的 OTS 组件的时间点:)

敏捷说做任何有意义的事，去掉非增值活动:) 敏捷不是灵丹妙药。只是我的 2 敏捷美分 :)

Answer 2

本身并不是一个严格的答案，但我认为在以下情况下使用现成的软件作为软件解决方案中的一个组件会非常有益：

• 它的数据是开放的，例如一个开放的数据库或与之交互的网络服务
• 现成的系统可以使用与您解决方案的其余部分类似的编程范例轻松定制
• 它可以无缝适应您的其他工作流程

我非常喜欢不重新发明轮子，并且使用您的开发技能来设计现成解决方案之间的“胶水”可能是一个巨大的胜利。

请记住，“开放”是重要的部分，供应商通常会吹捧他们的解决方案是开放的，但实际上并非如此。

Answer 3

我想我在某处读到过，如果在迭代过程中你发现你的工作量比你最初认为的多 20%，那么你应该放弃冲刺并开始计划一个新的冲刺，同时考虑到额外的工作。

因此，这意味着与业务部门重新计划，看看他们是否仍然希望在您了解更多之后继续执行原始要求。

在我们公司，我们还在 sprint 之前使用原型设计来尝试在 sprint 出现之前识别这些情况。当然，这仍然可能无法确定您描述的那种情况。

Answer 4

C2 wiki 讨论：http ://c2.com/cgi/wiki?BuyDontBuild