在敏捷中，如何使用严格的管理框架（例如TFS在线）计划和分配项目开始时的基本基础架构任务？

在这里，我正在确定和估计一个相对较小的新软件开发项目。我已经遍历了客户建议的用户案例，并针对每个案例放置了任务，并提供了估算和一些简短的注释，说明如何完成任务。有验收标准。所有人都应该对世界有益。

在查看我计划的工作时，我意识到缺少一些东西。只需设置一些我们可以固定功能的东西，这是最初的支出。属于所有用户故事的事物，而不是一个特定的用户故事。

例如，此应用程序的一部分是解析XML的服务。从用户的角度来看，有一些特定的故事，根据XML的内容，需要做不同的事情。实际上，编写XML解析器（查找文件的位，读取文件并提取相关数据，然后再决定如何处理内容）是所有这些故事的一部分。就像使用安装程序等将其包装在Windows服务中一样。这是以开发人员为中心的任务，与用户没有直接关系。

该特定应用程序的另一个相关示例是获取并重写一段不良的旧代码，这对此应用程序的功能很有用。同样，这对用户没有立即的结果，但这是必要的工作。在针对用户故事的项目计划中，如何计划和执行这项工作？

我已经看到人们通过写用户故事“作为开发人员，我想...”来解决这个问题，但是正如其他地方所讨论的，这不是用户故事。是开发人员。

我正在为此寻求一个具体的答案，以帮助我（和其他人）使用严格的管理框架（例如TFS在线）来计划项目。这些往往不具有编写“利益相关者故事”或其他模糊的元解决方案的功能，这些解决方案在Scrum团队如何在计划会议中解决基础架构任务的答案中提到。

我喜欢其他回答，它们表示要在“迭代0”中放入尽可能多的“工具”代码。但是，有时，这些类型的工具会在项目开始后出现。也许在迭代3中您意识到需要一个通用的XML解析器小部件以用于以后的各种故事。

在这种情况下，依赖于这些内部体系结构的第一个用户故事就是它们所属的用户故事。如果您要处理Story＃345，并且在您将XML解析器视为“完成”之前将取决于您的XML解析器，那么您的可重复使用的解析器将作为该故事的完成工作的附件。

我的团队已使用上述方法，对我们来说似乎很好。

如果是基础架构，通常将其置为零迭代。什么是零迭代？通常是在实际迭代开始之前，从启动到计划之间的时间。

例如，我们需要一个新的Web服务。因此，我需要创建项目，设置持续集成，设置源代码控制存储库，设置构建脚本和自动部署等。用户并不真正关心这些，但是无论如何我们都需要它们。

因此，该工作将在迭代0中完成。到迭代1开始时，已经有一个新的项目shell可以编译，具有自动构建脚本并可以部署。现在，没有任何用户功能，但是可以使用了。

我仍将在迭代0工作中跟踪和计划这项工作。

重构听起来像是一个技术故事，可以在任何迭代中进行。

取决于基础架构。

如果基础架构非常重要，或者必须遵守复杂的合规性规定，那么您可能会有一个单独的基础架构团队，他们可能有自己的时间表。它可能是敏捷的，可能是瀑布。在这种情况下，基础架构的构建将作为外部依赖项在您的项目中进行管理。

如果基础结构将由您的团队管理，并且仅设置一次，则可以使用Jon描述的迭代0技术。

如果基础结构的设置需要进行多次迭代（例如，也许您现在就设置构建服务器，但是QA和preprod服务器将在稍后构建），则可以将它们的构建作为无功能的PBI管理。功能性PBI可能对此有某些依赖性，您可以使用“前任”链接在TFS中进行编码。

当然，您可以混合并匹配以上所有内容。例如，没有连续的构建服务器就无法做很多事情，因此可以将其放入迭代0中。同时，您的preprod服务器可能被定义为迭代2和3的任务，并且它们可能对DBA团队具有外部依赖性（谁不敏捷）谁将在您的数据中心分配数据库实例。或者，也许您必须等待某些功能的SSL证书发布；它们可以在迭代4中进行，并且依赖于这些证书的任何功能项都应通过前辈/后继关系链接到它们。

在所有情况下，请记住：

1. 始终定义明确的验收标准。硬件专家有一种烦人的倾向，那就是站起来一台服务器，并在完全未经验证的情况下将其完成。
2. 在团队的迭代启动过程中，团队将需要检查依赖关系及其可用性，然后再提交给任何PBI或工作项。