Що таке "Ходіння скелет"?

Один з моїх спритних команд на ранніх етапах свого проекту застосував цікавий підхід. Замість того, щоб розпочати проект зі Sprint 0, де вони встановлюють інфраструктуру коду та приймають рішення про архітектуру рішення, вони почали будувати "Скелет для ходьби", який вони описують як практику DevOps.

Це, здається, зводиться до того, щоб створити щось дуже мале (у випадку API єдину кінцеву точку, яка щойно повертається 200-OK), налагодити цю роботу в постійній інтеграції та створити конвеєр безперервної доставки для розгортання цього в кожному з середовищ:

Розробка ► Тест ► UAT ► Передвиробництво ► Виробництво

У процесі роботи їм вдалося відзначити багато нефункціональних вимог, які могли бути пропущені, якби розгортання залишилися до останньої хвилини.

Моє запитання таке: що таке "Пішохідний скелет" і яку користь він дає команді Agile, яка дотримується практики DevOps?

"Скелет, що йде" - це форма "доказ концепції" вашої базової архітектурної концепції. Якщо доказ концепції, як правило, зосереджується більше на одній функціональності, "Ходячий скелет" - це мінімалістична реалізація "в кінці". "Скелет для ходьби" не є контуром вашої концепції (лише "скелет"), але він справді виконується і може бути доступний для доставки (він може "ходити": O) і повинен супроводжуватися тестами.

Алістер Кокберн описав це (і його часто цитують):

Пішохідний скелет - це крихітна реалізація системи, яка виконує невелику функцію "від кінця до кінця". При цьому не потрібно використовувати остаточну архітектуру, але вона повинна поєднувати між собою основні архітектурні компоненти. Потім архітектура та функціональність можуть розвиватися паралельно.

Перевага для DevOps полягає в тому, що «Пішохідний скелет» повинен бути розроблений на початку проекту та приводить до роботи коду, який можна виправити та перевірити . Таким чином DevOps може налагодити повний ланцюг безперервної інтеграції на початку проекту, замість того, щоб він був на борту у завершальній фазі проектів. Це означає, що будь-які проблеми, що виникли, також вирішуються на початковій стадії, а не поспіхом працювати в кінці.