现成的软件如何与敏捷开发相适应？

Question

也许我对敏捷开发的理解不像应该的那样好，但我很好奇，当最终系统的需求和知识正在以我理解的速度变化时(通常在每次开发迭代之后)，敏捷开发人员会如何使用现成的(OTS)软件。

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

(1) OTS系统满足最初的一组需求，除了可能集成到现有系统之外，几乎没有修改。但是，在开发的几次迭代中，如果不重写核心代码，这个系统就不能满足需求。开发人员必须选择要么花更多的时间学习这个OTS软件背后的核心代码，要么放弃它，从头开始构建。这两种方法都会对开发时间和项目成本产生严重影响。

(2)最初的需求不像任何现有的OTS系统，但是，最终当客户接受该产品时，由于需求的增加和减除，最终它很像现有的解决方案。如果开发人员有更多的需求，并将更多的时间花在这些需求上，这个解决方案可以被使用而不是重新构建。该项目的交付时间较晚，而且成本高于必要。

作为一名软件工程师，我的职责之一就是以尽可能低的成本(除其他外)，按时向客户交付高质量的软件。敏捷开发允许使用高质量的软件，但在某些情况下，在为时已晚和花费太多之前，可能还没有更好的替代方案。

我的问题是：

敏捷管理人员和敏捷开发人员是如何适应敏捷development?

• How的?敏捷管理器和敏捷开发人员如何处理这些案例？

• 如何看待这些案例？

。

Answer 1

Scenario1：

无论组件的OTS性质如何，都可以发生这种情况。敏捷并不意味着近视眼。你得知道大块..。框架的细节，并花时间对其进行预先思考。也就是说，你只能建立你知道的..。只推迟到最后一个负责的moment.Then，您需要选择一个替代方案并开始它。(我会避免第三方应用，除非内部开发它的成本是不可行的。)但那只是我)。原型多个解决方案，以检查可行性与已知的需求清单。保持松散耦合(可更换)，易于更改和充分测试。如果你到了黑客或重写的分叉，你就需要考虑哪一个对业务有更好的价值，并选择这个选项。“既然我们在这里，我们现在能做的最好的是什么？”

Scenario2：

这种情况可能会发生，尽管与团队花费2-3个月试图“最终确定”需求的机会相比，这种可能性很小，结果却发现市场需求或客户意识发生了变化，“现在我们希望如此”。再次，这是一个时间点的问题，直到你准备调查和探索，然后才采取行动的道路。用你所掌握的任何信息做出明智的决定。后知后觉总是20-20，但顾客不会永远等待。您不能等到需求合并以适应已知的OTS组件的时间点:)

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

Answer 2

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

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

的其余部分。

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

记住，“开放”是最重要的部分，当解决方案不是真正开放的时候，供应商往往会把他们的解决方案吹嘘为开放的。

Answer 3

我想我在某个地方读到过，如果在迭代过程中发现您有超过20%的工作是您最初认为的，那么您应该放弃sprint，开始计划一个新的工作，同时考虑到额外的工作。

因此，这将意味着重新规划与业务，看看他们是否还想继续原来的需求，既然你知道了更多。

在我们公司，我们还利用在sprint之前进行的原型开发来尝试在sprint出现之前识别出这种情况。当然，这可能还不能说明你所描述的情况。