Микросервисы / распределенные системы

🧩 Виды прототипов в связке с архитектурой

Макет/демо
Цель – получить представление о том, как продукт должен выглядеть. Можно сделать на основе одной или нескольких историй, учитывая, что вы строите продукт основываясь на воображении, а не на действительной обратной свзязи. Люди не оценивают макет так же, как они оценивают продукт. Отсюда можно получить первые очертания NFR.

Spike
Цель – лучше понять проблемную область. Сохраняется только результат исследования, код уничтожается.

MVP
Цель – выпустить минимальное жизнеспособное решение относительно самого себя в будущем, но конкурентноспособное относительо рынка.

Ходячий скелет
Форма PoC для основной концепции архитектуры. Специализируется на реализации одной самой простой функциональности, минималистичной реализации end-to-end сценария. Это не точное отражение архитектуры, лишь «скелет», который тем не менее должен быть «ходячим», то есть потенциально мы имеем возможность отгрузить его заказчику. Он должен быть покрыт тестами.

Alistair Cockburn очень точно описал этот феномен (http://alistair.cockburn.us/Walking+skeleton):

A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

The advantage here for DevOps is that a "Walking Skeleton" should be developed early on in the project and results in working, shippable and testable code. This way DevOps can set up a full continuous integration chain early in the project, instead of being onboarded in the final phase of projects. This means that any issues that would arise are also being tackled in an early stage instead of rush work at the end.

Well, it's not just the CI chain, but it could literally cover the end to end production pipeline, including delivery and deployment. A skeleton of that as well - you don't need to have all QA verifications for the final product in place on day 1, you can progressively add verification "meat" to this skeleton as the story "meat" accumulates on the walking skeleton.

👍1

www.tgoop.com/microservices_arch/496

2.77K viewsSergey Baranov, Nov 2, 2023 at 07:01

🧩 Виды прототипов в связке с архитектурой

Макет/демо
Цель – получить представление о том, как продукт должен выглядеть. Можно сделать на основе одной или нескольких историй, учитывая, что вы строите продукт основываясь на воображении, а не на действительной обратной свзязи. Люди не оценивают макет так же, как они оценивают продукт. Отсюда можно получить первые очертания NFR.

Spike
Цель – лучше понять проблемную область. Сохраняется только результат исследования, код уничтожается.

MVP
Цель – выпустить минимальное жизнеспособное решение относительно самого себя в будущем, но конкурентноспособное относительо рынка.

Ходячий скелет
Форма PoC для основной концепции архитектуры. Специализируется на реализации одной самой простой функциональности, минималистичной реализации end-to-end сценария. Это не точное отражение архитектуры, лишь «скелет», который тем не менее должен быть «ходячим», то есть потенциально мы имеем возможность отгрузить его заказчику. Он должен быть покрыт тестами.

Alistair Cockburn очень точно описал этот феномен (http://alistair.cockburn.us/Walking+skeleton):

A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.

The advantage here for DevOps is that a "Walking Skeleton" should be developed early on in the project and results in working, shippable and testable code. This way DevOps can set up a full continuous integration chain early in the project, instead of being onboarded in the final phase of projects. This means that any issues that would arise are also being tackled in an early stage instead of rush work at the end.

Well, it's not just the CI chain, but it could literally cover the end to end production pipeline, including delivery and deployment. A skeleton of that as well - you don't need to have all QA verifications for the final product in place on day 1, you can progressively add verification "meat" to this skeleton as the story "meat" accumulates on the walking skeleton.

BY Микросервисы / распределенные системы