问题描述
在敏捷团队中，有一种有趣的方法在项目的早期阶段采取。他们没有像传统的Sprint 0一样设置代码基础设施和解决方案架构，而是开始构建一个被称为“Walking Skeleton”的东西，他们将其描述为一种DevOps实践。
实际上，这似乎是构建一些非常小的东西（对于API而言，可能是一个仅返回200-OK的单个端点），将其在持续集成中工作，并通过每个环境构建出持续交付管道，以部署到以下各个环境：
开发 ► 测试 ► UAT ► 预生产 ► 生产
在这个过程中，他们成功地解决了许多非功能性要求，这些要求如果在部署留到最后阶段可能会被忽视。
我的问题是：什么是“Walking Skeleton”，以及对于遵循DevOps实践的敏捷团队它提供了什么好处？
解决方案
请注意以下操作可能涉及特定工具和实践，根据具体情况进行适当调整。
“Walking Skeleton”（行走骨架）是你基本架构概念的一种”概念验证”形式。与概念验证通常更侧重于单一功能不同，”Walking Skeleton”是一个极简的端到端实现。”Walking Skeleton”不仅仅是一个概念大纲（只有一个“骨架”），它实际上是可执行和可交付的（它可以“行走”！）并且应该伴随有测试。
Alistair Cockburn在他的描述中对此进行了阐述（并且经常被引用）：
“Walking Skeleton”是系统的一个微小实现，它执行一个小的端到端功能。它不需要使用最终的架构，但应该连接主要的架构组件。架构和功能可以并行演化。
对于DevOps而言，这样做的好处是，在项目的早期阶段开发了”Walking Skeleton”，并产生了可工作，可交付和可测试的代码。这样，DevOps可以在项目早期设置完整的持续集成链，而不是在项目的最后阶段才加入进来。这意味着任何可能出现的问题也可以在早期阶段解决，而不是在最后匆忙处理。
另一个优势是，通过建立一个端到端的“骨架”，你可以逐步地添加验证步骤，从而逐步建立全面的生产流水线。这可以让团队逐步验证每个环节，减少了在最后阶段出现大量验证工作的风险。
正如评论中所提到的，这与“最小可行产品”（MVP）的概念有些相似，但更加精细的层次上，也可以看作是“最小可行组件”。例如，只需返回一个服务的200状态以使其“运行”，听起来就像是一个存根。
通过采用“Walking Skeleton”的方法，敏捷团队可以更早地实现功能并进行持续的验证，从而在整个开发周期中减少风险，保障交付质量。