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

据我了解，敏捷方法论的思想是，您交付的是功能性的东西，并且您经常交付。递增后，应用程序进入其最终形状递增。

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

在这些最初的迭代中，什么交付给客户？在构建脚手架代码时，如何显示正确方向的进度？

通常有2周的冲刺。

对我来说，由于这个确切的原因，第一个sprint或第二个sprint的“可见”功能可能会比后来的sprint少（出于对“ less”的一些简短描述）。

话虽这么说，构建整个脚手架肯定不需要花费2周的时间，并且UI中没有任何内容可以显示。

也许您没有在第一个冲刺或第2个冲刺中充实每个脚手架项目，也许零件可以等待，以后再添加。

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

敏捷宣言指出，工作软件比全面的文档更有价值，并且Scrum框架采用这一概念来建议交付具有业务价值的经过测试的工作软件是每个sprint的要求。

为什么？好吧，除其他外，设计师和开发人员经常成为在YNNI（您永远不需要）上花费大量时间的受害者。不幸的是，您正在谈论的那些框架通常是这方面的主要责任。开发人员开始构建MIGHT框架必须支持的所有内容，然后突然您进入了3个月，就没有任何商业价值可证明。事实证明，该框架甚至没有真正支持他们最终需要的东西。

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

这并不意味着您不能构建可重复使用的零件等，而只是为了支持当前需求而一直这样做。而且，这并不意味着您必须完全为即将发生的事情戴上遮光罩-不要制造东西，以免日后更改/增强它们。但是关键是要始终提供业务价值。

通常，在交付任何东西之前，绝对需要建立一些关键的东西，例如设置环境等。对于这些事情，许多团队都发现有一个“ Sprint 0”奠定基础非常有用。Sprint 0可能比其他Sprint更长，因为它不会应用于您的产品积压或燃尽，但仍应在适当的时间范围内进行时间限制。

在这些最初的迭代中，什么交付给客户？

对用户而言具有最高业务价值的东西。例如，如果应用程序具有复杂的业务规则，则第一次迭代将仅包含以代码形式编码的那些业务规则。只要您拥有这些业务规则的代码，客户就应该感到满意。（实际上说服客户接受这样的问题是完全不同的问题。）例如，您可以向客户的业务专家展示您的单元/接受测试，以表达域应做的事情以及代码以绿色结果通过该测试。甚至更好的是，让业务专家帮助创建这些测试。

还有一个问题

您可能会建立框架或基础

我认为比实际交付的重要得多。进化设计（Evolutionary Design）有一件大事，那就是，您应该随着时间的流逝来创建架构，而不是一开始就尝试创建它。对于基础，这通常意味着某种数据库或UI框架。在这种情况下，会有一个想法：“ 好的体系结构可以使您推迟重要的决定。” 选择数据库或UI是一个重要的决定。例如，您可能只用内存存储数据就可以了，而不是尝试从最初的迭代开始使用DB。

我们试图做的是在第一次迭代中交付最简单的应用程序（我们正在交付的东西的世界版）。我们看到以下三个重要好处：

• 设置交付过程（始终是最困难的部分之一）（安装环境，服务器，并为此环境更新安全性）。正如我们将经常交付的那样，重要的是要尽快做到这一点。
• 首先让用户了解应用程序的外观。这有助于用户和开发人员了解他们真正想要和需要的东西。
• 对应用程序的架构有一个基本的了解（应用程序应涵盖应用程序的基本“层”或组件）。

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

这是错误的，因为您不需要构建将来可能使用的框架。这个想法是只构建所需的内容（另请参见YAGNI）。

在零冲刺中，您需要为实际工作做准备。许多人争辩说在此Sprint中应采取的措施，但我认为，当您可以开始处理积压中的项目时，它就完成了。此步骤包括设置PC，设置构建过程，选择框架等。

完成sprint零（或迭代零）后，就可以开始处理应用程序了。从待办事项中取出项目，并一一完成。完成第一个迭代后，您将获得一些有用的东西。第一次迭代通常包括一些最重要的功能。

在这些最初的迭代中，什么交付给客户？在构建脚手架代码时，如何显示正确方向的进度？

零迭代之后，显然您没有任何要交付的东西。可交付结果在迭代一之后出现。它包含您为迭代设置的功能。

如果您的问题是“如何选择迭代X的内容？”，请看一下这些视频广播（迭代0 A和B的一部分的视频）。

您可以提供几乎任何您想要的东西。建立基础设施构想完全是错误的/不是敏捷的/不可持续的。

例如：可以在数小时内构建功能完整的Hello World应用程序。在云端或虚拟机中启动服务器（甚至是暂时）可以在几小时内完成。

这些足以开始开发。然后，如果您需要配置项，则可以添加配置项故事，如果需要物理服务器，则可以为此添加一个故事。

但是，从第一天开始交付就永远不会停止！

早期迭代，尤其是第一个迭代，将包含或至少应该计划架构高峰，其中包括一定数量的发现时间以及一些架构原型。

就像您说的那样，通常存在一些结构要求，这些要求对利益相关者/客户而言可能并不重要，但是需要形成一个强大的平台或模式导向。您无法解决这个问题，因为在A完成之前您无法开始构建B。

敏捷方法的一部分是与客户保持联系，因此不需要文档，因为您要做的就是拿起电话/发送电子邮件，这是可以预期的。客户的期望应该适当设定，完成的任何工作都应该非常简洁和必要。没有镀金，没有“您可能需要”，等等。在A中构建您需要的东西，然后移动到B。

根据您对项目的攻击方式，您可能仅会建立所需的基础才能完成某个模块，因此在sprint计划会议期间，您将根据sprint设置的优先级来计划当前sprint的计划。客户，根据该Sprint的需求，可能会有一些基本要求，所以这就是Sprint 1的内容。在完成第一个Sprint并构建A之后，然后计划完成B。

如果您已经与客户达成了时间表，那么只要您要达成协议，客户可能就不会在意第一或第二的工作。您总是可以向他们显示单元测试结果，但是如果您说在sprint 2（或3）之后我们将为您提供一些东西供您查看，并且交付了，它将为您设定一个很重要的优先级。期望客户与开发人员一样合理，并且两者都朝着同一目标努力。满足客户需求并按预期工作的已完成项目。因此，担心在sprint 1之后看不到任何东西是有争议的，因为客户只是想确保在sprint 20之后，项目将完成（-ish）。