¿Qué es un "esqueleto andante"?


42

Uno de mis equipos ágiles ha adoptado un enfoque interesante en las primeras etapas de su proyecto. En lugar de comenzar el proyecto con un Sprint 0 donde configuran la infraestructura de código y deciden sobre la arquitectura de la solución, han comenzado a construir un "Esqueleto andante", que describen como una práctica de DevOps.

A lo que parece llegar esto es a construir algo muy pequeño (en el caso de una API, un único punto final que simplemente regresa 200-OK), hacer que esto funcione en una integración continua y construir la tubería de entrega continua para implementar esto a través de cada uno de los entornos:

Desarrollo ► Prueba ► UAT ► Preproducción ► Producción

En el proceso, han logrado marcar muchos de los requisitos no funcionales que podrían haberse pasado por alto si las implementaciones se hubieran dejado para el último minuto.

Mi pregunta es esta: ¿qué es un "Esqueleto ambulante" y qué beneficio le brinda a un equipo ágil que sigue las prácticas de DevOps?


1
Me encanta este, puedo compartir una cosa real (la semana pasada) y cuáles fueron los resultados de esto después del almuerzo
Tensibai

Respuestas:


38

Un "esqueleto andante" es una forma de "prueba de concepto" de su concepto arquitectónico básico. Donde una prueba de concepto generalmente se enfoca más en una sola funcionalidad, un "Esqueleto andante" es una implementación minimalista de extremo a extremo. Un "Esqueleto andante" no es un esbozo de su concepto (solo un "esqueleto") pero es realmente ejecutable y transportable (puede "caminar": O) y debe ir acompañado de pruebas.

Alistair Cockburn lo ha descrito (y se lo cita a menudo):

Un esqueleto ambulante es una pequeña implementación del sistema que realiza una pequeña función de extremo a extremo. No necesita usar la arquitectura final, pero debe vincular los componentes arquitectónicos principales. La arquitectura y la funcionalidad pueden evolucionar en paralelo.

La ventaja aquí para DevOps es que se debe desarrollar un "Esqueleto andante" al principio del proyecto y que resulte en un código funcional, enviable y comprobable . De esta forma, DevOps puede configurar una cadena de integración continua completa al principio del proyecto, en lugar de incorporarse en la fase final de los proyectos. Esto significa que cualquier problema que surja también se está abordando en una etapa temprana en lugar de un trabajo apresurado al final.


44
Bueno, no es solo la cadena de CI, sino que literalmente podría cubrir la línea de producción de extremo a extremo, incluida la entrega y la implementación. Un esqueleto de eso también: no es necesario tener todas las verificaciones de control de calidad para el producto final en el día 1, puede agregar progresivamente "carne" de verificación a este esqueleto a medida que la historia "carne" se acumula en el esqueleto andante.
Dan Cornilescu

1
Me gusta el término "carne", encaja muy bien con la terminología utilizada: P
7ochem

3
Gran respuesta. Supongo que es el gasoducto de entrega equivalente a un producto mínimo viable.
Adrian

44
Esto suena similar al producto mínimo viable, pero a un nivel más granular, quizás "componente mínimo viable". Devolver 200 de un servicio solo para que se "ejecute" me parece un trozo.
Dave Swersky
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.