现成的软件如何适应敏捷开发？[关闭]

Question

也许我对敏捷开发的理解没有达到应有的程度，但我很好奇当最终系统的需求和知识是这样的时候，敏捷开发人员如何可能使用现成的（OTS）软件正如我所理解的那样，它们的变化速度如此之快（通常是在每次开发迭代之后）。

---

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

(1) OTS 系统除了可能集成到现有系统之外，几乎无需修改即可满足最初的一组要求。然而，经过几次开发迭代，如果不重写核心代码，这个系统就不再满足需求了。开发人员必须选择要么花额外的时间学习该 OTS 软件背后的核心代码，要么扔掉它并从头开始构建。两者都会对开发时间和项目成本产生巨大影响。

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

---

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

我的问题是：

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

Answer 1

场景一：

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

场景2：

这种情况是有可能发生的，尽管与团队花费 2-3 个月试图“最终确定”需求却发现市场需求或客户想法已经改变并且“现在我们想要这样”相比，这种情况发生的可能性很小。这又是一个问题，即在采取行动之前，你准备在什么时间点进行调查和探索。根据您目前掌握的任何信息做出明智的决定。事后看来总是 20-20，但客户不会永远等待。您不能等到需求合并以适合已知 OTS 组件的时间点:)

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

Answer 2

本身并不是一个严格的答案，但我认为使用现成的软件作为软件解决方案的组件可能非常有益，如果：

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

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

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

Answer 3

我想我在某处读到过，如果在一次迭代期间您发现自己的工作比最初想象的多了 20% 以上，那么您应该放弃冲刺并开始计划新的冲刺，同时考虑到额外的工作。

因此，这意味着您需要与企业重新规划，看看他们是否仍然愿意继续执行最初的要求，因为您已经了解了更多信息。

在我们公司，我们还在冲刺之前利用原型设计来尝试在冲刺​​中出现此类情况之前识别它们。当然，这仍然可能无法识别您所描述的情况。

Answer 4

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