也许我对敏捷开发的理解不如应有的那样，但是我很好奇，当最终系统的要求和知识是什么时，敏捷开发人员将如何潜在地使用现成的(OTS)软件？改变的速度据我所知(通常在每次开发迭代之后)。

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

(1)除了可能集成到现有系统中之外，OTS系统几乎不需要修改就可以满足最初的一组要求。但是，在开发的几次迭代中，如果不重写核心代码，该系统将无法满足需求。开发人员必须选择花更多的时间来学习该OTS软件背后的核心代码，或者将其扔掉并从头开始构建。两者都会对开发时间和项目成本产生巨大影响。

(2)最初的需求与现有的任何OTS系统都不一样，但是最终，当客户接受产品时，由于需求的增加和减少，最终与现有的解决方案非常相似。如果开发人员有更多要求，并且花了更多时间在前端上，那么可以使用此解决方案，而不必再次构建。该项目已交付，但后来又以比必要的更高的成本进行了交付。

作为软件工程师，我的部分职责(正如我所教过的)是按尽可能低的成本(除其他事项外)按时向客户交付高质量的软件。敏捷开发允许使用高质量的软件，但是在某些情况下，直到为时已晚并且花了太多钱，似乎还没有更好的选择。

我的问题是：

• 现成的软件如何与敏捷开发配合？
• 敏捷管理者和敏捷开发者如何处理这些情况？
• 对于这些案例，敏捷范例怎么说？

解决方案

回答

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

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

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

请记住，"开放"是很重要的部分，供应商常常会在不真正开放的情况下吹捧他们的解决方案。

回答

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

因此，这意味着与业务部门进行重新计划，以了解他们是否仍然愿意继续执行最初的要求，因为我们已经了解了更多信息。

在我们的公司中，我们还利用冲刺之前的原型制作来尝试识别出这种情况，然后再在冲刺中出现这些情况。当然，这可能仍无法识别我们所描述的情况。

回答

方案1：

无论组件的OTS性质如何，都可能发生这种情况。敏捷并不意味着近视..我们需要了解大块..框架的各个部分，并事先花时间思考一下。就是说，我们只能建立自己所知道的..仅延迟到最后一个负责任的时刻。然后，我们需要选择一种替代方法并从中开始。 (除非内部开发成本不可行，否则我将避免使用第三方应用程序。但这就是我自己)。制作多个解决方案原型，以检查已知需求列表的可行性。保持事物松散耦合(可替换)，易于更改并经过全面测试。如果我们想继续进行黑客入侵或者重写，则需要考虑哪种对企业更有价值，然后选择该选项。这是因为"现在我们在这里，我们现在能做的最好的事是什么？"

方案2：

尽管与花费2-3个月的团队试图"最终确定"需求的机会相比，这种可能性很小，但发现市场需求或者客户的想法已经改变，并且"现在我们要这样"，这是可能发生的。再一次，这是一个问题，即我们准备采取行动之前要准备调查和探索的时间点是什么时间。明智地决定我们拥有的任何信息。.后见之明始终为20到20，但客户不会永远等待。我们不能等到需求合并以适应已知的OTS组件的时间点：)

敏捷说：做任何有意义的事情并剔除非增值活动：)敏捷不是万能的子弹。只是我的2敏捷分:)

回答

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