在基础设施项目中创建用户故事与面向用户的应用程序不同吗？a的大多数定义用户故事将与特定用户或系统无关。然而，用户故事的常见示例通常集中于产品的最终用户。在最近的一个项目中，我们正在将on-prem-tech-estate重新构建到公共云，我发现很难确定最终用户，而且该产品已经存在。这里是我学到的一些经验教训，我觉得这些经验教训可以在大多数重新构建项目（如果不是一般的基础设施项目）中传递。
使用故事图和里程碑了解“完成”
“完成”是什么样子的?对于最终目标，迁移所有东西都是有意义的，但这只留下了一个里程碑，很难重新安排优先级、更改或评估它。它创造了一个极好的、简单的交流目标，帮助我们避免了范围蔓延(Task X是否帮助我们迁移?)但我们需要一些更小的目标，让我们保持正轨，尽早看到价值。
将我们的目标分解成更小的、可衡量的里程碑故事地图效果很好。传统上，故事图将遵循目标>活动>故事结构。我很快发现使用“活动”不适合我们的infra团队和平台SME的工作方式。他们习惯于以与用户与系统交互方式不匹配的方式顺序部署组件。
因此，我们采取了额外的措施确保我们捕获了所有东西。第一步是创建一个目标>组件>故事/尖峰故事地图。我们的最终结果大致如下：
这与系统的初始部署相匹配。第二步是我们引入用户旅程，确定MVP片段，这成为我们的里程碑，同时仍然确保我们在迁移中捕获每个组件。这些里程碑的选择是基于我们平台的用户:组织的开发团队。
通过在捕获所有内容后引入旅程，我们能够将其作为一种方法，来确定启动和快速运行的优先级。这也有助于我们确定我们可能过度工程化的地方。我们想做的事是否达到了目标？如果没有，我们可以保存到以后！
了解技术复杂性的技巧
我们面临的一大挑战是决定如何进行迁移。根据您的需求，Azure提供了几种实现您想要的结果的方法。由于我们对中小型企业的访问受限、复杂的遗留堆栈以及对特定Azure组件的经验不足，我们还没有准备好直接开始完成故事。
峰值通常用于创建“探索潜在解决方案的尽可能简单的程序”。我们对此稍作修改，使用它们来探索并商定迁移组件的方法。这一集中的信息收集和原型设计阶段意味着我们可以降低交付的关键方面的风险。
对于我们的spikes来说，真正重要的是它们包含以下三个方面：
- 需要回答的问题
一旦你对自己的答案有信心，你就不再扣球了。 - 分时间段
如果到那时还没有解决办法，我们需要引入一个更大的论坛或具体的专业知识 - 功能或跨功能考虑
这些是解决方案需要支持的需求。有时会很少，有时会有负载。如果有负载，考虑分裂尖刺，因为你可能试图找到一个银弹。
Spikes还与通过轻量级架构决策记录．每一个峰值的输出都被记录在ADR中，确保不仅是我们的学习记录，而且所有未来的开发和平台团队也可以使用这些信息。
验收标准——结果比我预期的更相似
让ACs很好地工作是很难的。以下是我们尝试过的一些对我们不起作用的事情：
- 详细规格的要点
这个规范将会改变，并完全混淆qa
- 没有详细说明的要点
qa不知道从什么地方开始测试
- 以用户为中心，行为驱动开发(BDD)风格(给定，当，然后)
在可测试之前，我们需要迁移大量的系统，我们最终会得到需要几个月才能交付的故事
- 一个更自由的空间，供开发人员在启动或开发期间添加ACs
这将最终成为QAs应该采取哪些步骤来测试某些东西的列表，这些步骤击败了我们QAs的观点
- 没有一个!
．．.我相信你能想象这是怎么结束的。
真正起作用的是开发人员领导的BDD ACs。
像上面的例子一样，这个动作不是由最终用户触发的(什么时候我按下“OK”（确定）按钮），但按任何对系统组件有意义的按钮。BDD的目的是让项目中的每个人都能轻松理解我们故事的结果。考虑到我们的项目正在为开发人员构建一个平台，BDD应该面向开发人员思维是有道理的。
我学到了什么?
基础设施的故事是不同的，但没有我们最初想象的那么不同。许多传统的用户故事原则都适用，但需要调整。考虑团队成员的经验，在尝试将其转化为旅程之前，利用这些经验提取所需的细节。和往常一样，考虑你的用户!基础架构团队非常同情开发者用户，能够从展会和adr中获得反馈。他们能够支持故事编写过程，一旦看到开发团队对我们平台的热情，他们就会迅速接受目标。
免责声明：本文中表达的声明和观点是作者的，不一定反映Thoughtworks的立场。188bet宝金博app下载
