How does off-the-shelf software fit in with agile development?也许我对敏捷开发的理解不如应有的那样，但是我很好奇，当最终系统的要求和知识是什么时，敏捷开发人员将如何潜在地使用现成的(OTS)软件？改变的速度据我所知(通常在每次开发迭代之后)。 我看到两种情况对我特别感兴趣： (1)除了可能集成到现有系统之外，OTS系统几乎不需要修改即可满足最初的要求。但是，在开发的几次迭代中，如果不重写核心代码，该系统将无法满足需求。开发人员必须选择花更多的时间来学习该OTS软件背后的核心代码，或者将其扔掉并从头开始构建。两者都会对开发时间和项目成本产生巨大影响。 (2)最初的需求与现有的OTS系统不同，但是最终客户接受产品时，由于需求的增加和减少，最终与现有的解决方案非常相似。如果开发人员有更多要求，并且花了更多时间在前期，则可以使用该解决方案，而不必再次构建。该项目已交付，但后来又超出了必要的成本。 作为软件工程师，我的部分职责(正如我所教过的)是按尽可能低的成本(除其他事项外)按时向客户交付高质量的软件。敏捷开发允许使用高质量的软件，但是在某些情况下，直到为时已晚并且花了太多钱，似乎还没有更好的选择。 我的问题是： 方案1： 无论组件的OTS性质如何，都可能发生这种情况。敏捷并不意味着近视..您需要知道大块..框架的各个部分，并事先花时间思考一下。就是说，您只能建立自己所知道的..只能延迟到最后一个负责任的时刻。然后，您需要选择一种替代方法并从中开始。 (除非内部开发成本不可行，否则我将避免使用第三方应用程序。但这就是我自己)。制作多个解决方案原型，以检查已知需求列表的可行性。使事物保持松散耦合(可替换)，易于更改并经过全面测试。如果您想继续进行黑客入侵或重写，则需要考虑哪种对企业更有价值，然后选择该选项。这是因为"现在我们在这里，现在我们能做的最好的是什么？" 方案2： 尽管与花费2-3个月的团队试图"最终确定"需求的机会相比，这种可能性很小，但发现市场需求或客户的想法已经改变，并且"现在我们要这样"。再一次，这是一个问题，即您准备采取行动之前要准备调查和探索的时间点是什么时间。明智地决定您在那之前拥有的任何信息。.后见之明始终为20到20，但客户不会永远等待。您不能等到需求合并以适应已知的OTS组件的时间点：) 敏捷说：做任何有意义的事情，剔除那些非增值活动：)敏捷不是万能的子弹。只是我的2敏捷分:) 本身并不是一个严格的答案，但是我认为在以下情况下使用现成的软件作为软件解决方案的组件可能会非常有益：
我非常喜欢不重新发明轮子，并且使用您的开发技能来设计现成解决方案之间的"胶水"可能是一个巨大的胜利。 请记住，"开放"是很重要的部分，供应商常常会在解决方案并非真正开放时就吹捧它们。 C2 Wiki讨论：http：//c2.com/cgi/wiki？BuyDontBuild 我想我在某处读到，如果在迭代过程中发现您原本以为的工作量多20％，那么您应该放弃sprint，并考虑到额外的工作来开始计划一个新的。 因此，这意味着您需要与业务部门重新计划，以了解他们是否仍然愿意继续执行原始要求。 在我们的公司中，我们还利用冲刺之前的原型制作来尝试找出此类情况，然后再在冲刺中出现。尽管这当然可能仍无法识别您所描述的情况。 |
