logo标签列表

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

agile
3
也许我的敏捷开发理解不如应该好，但我很好奇敏捷开发人员在需求和对最终系统的认知迅速变化（通常在每次开发迭代之后）的情况下，如何潜在地使用现成的软件（OTS）。
我看到了两种特别值得关注的情况：
（1）一个OTS系统在很少或没有修改的情况下满足了最初的一组要求，除了可能集成到现有系统中。然而，在几个开发迭代之后，这个系统再也不能满足需要，必须重写核心代码。开发人员必须选择花费额外的时间学习OTS软件背后的核心代码，或者放弃它，从头开始建立。无论哪种情况都会对开发时间和项目成本产生重大影响。
（2）最初的需求与任何现有的OTS系统都不一样，然而，最终当客户接受产品时，由于增加和减少需求，它最终变得像现有的解决方案一样。如果开发人员有更多的需求并花更多时间在前期工作上，就可以使用这个解决方案，而不是再次构建。项目被交付了，但时间和成本比必要的要高。
作为一名软件工程师，我的责任之一（根据我的学习）是按时以最低的成本向客户交付高质量的软件（还有其他事情）。敏捷开发允许高质量的软件，但在某些情况下，直到为时已晚并且已经花费了太多的钱才意识到有更好的选择可能是不明显的。
我的问题是：
  1. 现成的软件如何与敏捷开发相结合？
  2. 敏捷经理和敏捷开发人员如何处理这些情况？
  3. 敏捷范例对这些情况有什么说法？
4个回答
4

场景1：

这可能会发生，无论组件的OTS性质如何。敏捷并不意味着目光短浅...你需要知道大块头..框架部分并花时间思考它。话虽如此，你只能根据自己所知道的构建...直到最后一个负责任的时刻才延迟。然后你需要选择其中一种替代方案并开始执行。(我会避免使用第三方应用程序，除非在公司开发它的成本是不可行的...但这只是我的想法)。通过已知要求列表原型多个解决方案以检查可行性。保持松散耦合(replacable)，易于更改和完全测试。如果你到达了保持黑客或重写的分岔口，你需要思考哪个对业务价值更好，并选择该选项。这归结为'既然我们在这里，现在我们能做的最好是什么？'

场景2：

虽然与团队花费2-3个月试图使需求“最终确定”相比，这种情况可能发生的几率很小，只是发现市场需求或客户思维发生了变化，“现在我们希望这样做”。再次强调，这是一个问题，直到你准备在采取行动的道路上进行调查和探索的时间点是什么。在那个时候，根据你拥有的任何信息做出明智的决策...事后诸葛亮，但客户不会永远等待。你不能一直等到需求凝聚以适应已知的OTS组件才采取行动：）

敏捷开发说：“做有意义的事情并剥离无价值的活动:) 敏捷开发不是万能的解药。 这只是我的两个敏捷角)

3

虽然不是严格的答案，但我认为在软件解决方案中使用现成的软件组件可以带来很多好处，前提是：

  • 它的数据是开放的，例如一个开放的数据库或一个可与之交互的 Web 服务
  • 这个现成的系统可以使用类似于您解决方案其余部分的编程范例进行自定义，而且是容易的
  • 它能够无缝地适应您的工作流程

我非常支持不重复造轮子，并且使用您的开发技能来设计连接现成解决方案之间的“粘合剂”可以取得巨大成功。

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

澄清一下 - 这取决于开放式第三方系统（OTS）的程度。如果它很容易修改系统并共享数据，那么这是一个考虑因素，否则就不是考虑因素？ - Thomas Owens
1

我记得在某个地方读到过，如果在迭代过程中发现你的工作量比最初预计的多20%以上，那么你应该放弃这个冲刺并开始规划一个新的冲刺，考虑到额外的工作。

这意味着需要重新计划与业务的合作，看看他们是否仍然想要按照最初的需求继续进行。

在我们公司，我们还会在冲刺之前使用原型制作来尝试识别这些情况，以避免在冲刺期间出现。当然，这仍然可能无法识别您所描述的情况。

1
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接