「ウォーキングスケルトン」とは何ですか？

私のアジャイルチームの1つは、プロジェクトの初期段階で興味深いアプローチを採用しました。コードインフラストラクチャをセットアップし、ソリューションアーキテクチャを決定するSprint 0でプロジェクトを開始する代わりに、DevOpsプラクティスと呼ばれる「ウォーキングスケルトン」の構築を開始しました。

これは、非常に小さなもの（APIの場合は、戻るだけの単一のエンドポイント200-OK）を構築し、これを継続的インテグレーションで動作させ、継続的配信パイプラインを構築して各環境に展開することです。

開発►テスト►UAT►プリプロダクション►プロダクション

その過程で、彼らは、展開が最後まで残された場合に見逃されていた可能性のある非機能要件の多くをチェックすることに成功しました。

私の質問は次のとおりです。「ウォーキングスケルトン」とは何ですか。また、DevOpsプラクティスに従ってアジャイルチームにどのようなメリットをもたらしますか。

「ウォーキングスケルトン」は、基本的な建築概念の「概念実証」の一形態です。概念実証が通常単一の機能に重点を置く場合、「ウォーキングスケルトン」は最小限のエンドツーエンドの実装です。「ウォーキングスケルトン」は概念のアウトライン（「スケルトン」のみ）ではなく、実際に実行可能で出荷可能な（「ウォーク」：O）ことができ、テストを伴う必要があります。

アリステア・コックバーンはそれについて説明しています（そしてしばしば引用されています）：

ウォーキングスケルトンは、小さなエンドツーエンド機能を実行するシステムの小さな実装です。最終的なアーキテクチャを使用する必要はありませんが、主要なアーキテクチャコンポーネントをリンクする必要があります。その後、アーキテクチャと機能を並行して進化させることができます。

ここでのDevOpsの利点は、プロジェクトの早い段階で「ウォーキングスケルトン」を開発する必要があり、その結果、動作可能なシップ可能なテスト可能なコードが作成されることです。このようにして、DevOpsはプロジェクトの最終段階でオンボーディングされるのではなく、プロジェクトの初期段階で完全な継続的インテグレーションチェーンをセットアップできます。これは、最後に急いで作業するのではなく、発生する問題も初期段階で対処されることを意味します。