在敏捷的前几次迭代中，您提供了什么？

Question

正如我所理解的，敏捷方法的思想是，您交付一些功能强大的东西，并且经常交付它。应用程序在增量后进入其最终形状增量。

但是在早期的迭代中，您可能会构建应用程序所赖以生存的框架或基础，因此它是重要的，但对用户来说是不可见的。

在这些第一次迭代中，什么被传递给客户端？如何在构建脚手架代码时向正确的方向显示进展？

Answer 1

这是典型的有两个星期的冲刺。

对我来说，第一次冲刺或第二次冲刺可能比以后的冲刺有更少的“可见”特性，这正是因为这个原因(因为对“较少”的一些模糊描述)。

尽管如此，它当然不应该花你两个星期来构建你的整个脚手架，并且在UI中没有任何东西可以显示出来。

也许你没有在第一次冲刺或第二次冲刺中充实每个脚手架项目，也许部分可以等待，然后再添加。

也许你的第一次冲刺有“用虚拟数据创建网页X”，这样你就可以得到一些闪亮的东西来展示你的客户。然后下一个sprint有“更改webpage X以使用数据库中的数据”。

Answer 2

敏捷宣言建议，工作软件比全面的文档更有价值，Scrum框架认为交付经过测试的、具有业务价值的软件是每个sprint的要求。

为什么？嗯，除其他外，设计师和开发人员常常会在YNNI (您永远不需要它)项目上花费大量的时间。不幸的是，您正在讨论的这些框架在这方面常常是一个很大的负担。开发人员开始构建框架可能需要支持的所有内容，突然之间，您已经进入了3个月，没有任何业务价值可供展示。结果发现，这个框架甚至不支持他们最终需要的东西。

因此，建议的方法是只构建现在实际需要的，并立即交付。

这并不意味着您不能构建可重用的部件等等，您总是这样做，以支持构建当前的需求。而且，这并不意味着你必须对未来的事情完全戴上眼罩--不要建造东西，这样以后就不可能改变/增强它们。但关键是要始终提供业务价值。

在交付任何东西之前，通常都需要建立一些关键的东西，例如设置环境等等。对于这些事情，许多团队认为有一个"Sprint 0“是有用的，其中奠定了基础。Sprint 0可以比您的其他Sprint稍微长一点，因为它不应用于您的产品积压或刻录，但它仍然应该被限制在一个合理的持续时间内。

Answer 3

在这些第一次迭代中，什么被传递给客户端？

什么对用户具有最高的商业价值。例如，如果应用程序具有复杂的业务规则，则第一次迭代(S)将只包含以代码形式编码的业务规则。只要您有这些业务规则的代码，客户就应该感到满意。(实际上说服客户接受这样的事情是完全不同的问题。)例如，您可能会向客户的业务专家展示您的单元/验收测试，这些测试表示域应该做什么，并且代码以绿色的结果通过它。或者更好的是，让业务专家帮助创建这些测试。

还有一个问题是

您可以建立框架或基础。

我认为这比实际交付的要重要得多。对于进化设计来说，有一点是很重要的，它说，您应该随着时间的推移创建体系结构，而不是在一开始就尝试创建它。至于基础，这通常意味着某种数据库或UI框架。在这种情况下，就有了“好的架构允许你推迟重要的决策。”的概念。选择数据库或UI是一个重要的决定。例如，您可以在内存中存储数据，而不是尝试在第一次迭代中使用DB。