Me han preguntado qué debe hacer un equipo cuando la naturaleza del proyecto impide cortes verticales en sus historias entregables.
La definición de 'Desarrollo incremental' se proporciona aquí: https://www.agilealliance.org/glossary/incremental-development/
Cerca de la parte superior de ese documento está lo siguiente:
en un contexto Agile, esto significa que cada versión sucesiva del producto es utilizable, y cada una se basa en la versión anterior agregando funcionalidad visible para el usuario.
Recientemente he tenido una consulta de la forma:
¿Qué sucede en un proyecto ágil cuando la naturaleza del software que se está construyendo simplemente no tiene una versión anterior sobre la cual construir y, por lo tanto, no puede entregar una versión utilizable sucesiva? Por ejemplo, las capas de software en un teléfono móvil que aún no tienen un "teléfono" del que formar parte y que probablemente no impliquen la entrada del usuario y simplemente brinden un servicio a otras unidades de funcionalidad.
En resumen, ¿cómo puede implementar INVEST cuando parece que no hay suficiente profundidad en la historia para hacerlo?
(Anteriormente fui testigo de un experto en scrum que impuso, en un proyecto web, un trabajo completo de DB a UI en cada historia, literalmente, y, sí, esto causó mucha fricción).
Después de los primeros Sprints, un producto Scrum siempre debe estar en un estado potencialmente liberable. Eso significa inherentemente que siempre hay algo que demostrar en una demostración de Sprint, pero es posible que deba ser creativo y "pensar fuera de la caja" para encontrarlo. Trate las demostraciones como productos de trabajo de primera clase durante la planificación de Sprint para que las demostraciones sean más fáciles e intuitivas de desarrollar.
¿Qué sucede en un proyecto ágil cuando la naturaleza del software que se está construyendo simplemente no tiene una versión anterior sobre la cual construir y, por lo tanto, no puede entregar una versión utilizable sucesiva? Por ejemplo, las capas de software en un teléfono móvil que aún no tienen un "teléfono" del que formar parte y que probablemente no impliquen la entrada del usuario y simplemente brinden un servicio a otras unidades de funcionalidad.
Este es un malentendido común de lo que significa "iterativo" o "incremental" en un contexto ágil. De ninguna manera significa que debe tener una versión anterior del software; significa que las versiones futuras pueden (y generalmente deberían) construir sobre el trabajo que se ha hecho antes. Los proyectos ágiles se benefician enormemente del diseño emergente y los marcos ágiles se optimizan para eso.
Las API y el middleware pueden crecer y evolucionar en incrementos pequeños y comprobables de la misma manera que cualquier otro software, por lo que no hay nada ortogonal para INVEST en dichos sistemas. Las API y el middleware se pueden versionar, modificar y ampliar de la misma manera que el software más tradicional.
No hay nada inherente a las API o al middleware que les impida mantenerse en un estado potencialmente liberable o demostrable. Dichos sistemas aún deberían hacer algo , y si puede probarlo, entonces puede demostrarlo.
Habiendo dicho todo eso, lo que parece desconcertar a muchas personas es la dificultad de demostrar una nueva funcionalidad en un producto que no se presta fácilmente a las presentaciones visuales. Hacerlo a menudo requiere un poco más de creatividad y experiencia en pruebas ágiles que la que tienen muchas tiendas cuando comienzan sus viajes ágiles. Algunas soluciones comunes incluyen:
Uso de pruebas ejecutables para la demostración.
El pepino es un gran ejemplo de esto. Ver pruebas bien escritas (y, por lo tanto, documentación que describe el comportamiento) volverse ecológicas es una demostración perfectamente válida para muchos tipos de software.
Aproveche su arnés de desarrollo o prueba de control de calidad para demostraciones.
Casi cualquier marca de TDD/BDD o integración continua requerirá algún nivel de abstracción de prueba. Mocks, stubs, fixtures y factory a menudo sustituyen a otras piezas de la arquitectura "real", incluso en las pruebas de integración. No hay nada que le impida utilizar dichas técnicas para probar la funcionalidad de los clientes de API o middleware en sus demostraciones de Sprint.
Cree un "cliente de demostración".
El punto es mostrar su producto haciendo algo. Si no puede mostrarlo in situ, al menos puede crear una maqueta o un simulador que muestre cómo interactuaría una API o un cliente de middleware con su código. ¡Demostración de esa interacción!
Documentación, gráficos circulares y otras ayudas visuales.
La demostración de Sprint tiene como objetivo mostrar el progreso y solicitar comentarios de las partes interesadas para alimentar Sprints futuros. Si bien todas las abstracciones tienen fugas, si realmente no puede imaginar otra forma de demostrar su incremento de trabajo, siempre puede aprovechar los artefactos secundarios. Guíe a las personas a través del código, el historial de confirmaciones, la documentación viva de la API como Swagger u otras cosas que brinden una vista válida del estado actual del producto.
Scrum exige que se demuestren los incrementos de trabajo, pero no prescribe cómo deben realizarse las demostraciones. No existe ningún mandato de que una demostración deba requerir un teclado o una interfaz gráfica. Si es relevante para el producto, la escritura en el cielo o la danza interpretativa podrían ser igualmente legítimas para la demostración.
El objetivo del marco es evitar los informes de estado tradicionales y brindar a las partes interesadas "más espectáculo, menos narración". Si el equipo no puede encontrar una manera de demostrar el incremento de trabajo, me atrevo a decir que también tendrán dificultades para probarlo.
Los marcos TDD/BDD funcionan mejor cuando diseña las pruebas primero, en lugar de escribir sus pruebas a posteriori; facilita las pruebas y garantiza que el producto esté diseñado para ser probado desde el principio . Las demostraciones de Sprint no son diferentes. Durante la planificación de Sprint, el equipo debe tener en cuenta cómo planean demostrar el trabajo en sus historias de usuario y estimaciones en la parte delantera en lugar de en la parte posterior.
A veces, la planificación en torno a las demostraciones puede cambiar la forma en que divide las historias o cómo planifica o estima el trabajo. Si es así, ¡genial! Eso significa que está aprovechando el marco.
Trate las demostraciones como productos de trabajo de primera clase, no como ideas de último momento. Cuando reformula el trabajo de esta manera, la mejor manera de demostrar los incrementos de trabajo suele volverse evidente.
tl;dr; Haz tu mejor esfuerzo. Trate de producir siempre conocimiento validado o funcionalidad utilizable. Busque siempre los comentarios de los usuarios. No te preocupes cuando no veas una buena opción.
El propósito de esta práctica era producir incrementos de un producto. En Agile queremos deshacernos de la idea de que conocemos la solución "correcta" y solo tenemos que codificarla. Eso casi nunca es el caso.
Este video explica los diferentes tipos de control de procesos y aprovecha firmemente Scrum empíricamente. ( https://www.youtube.com/watch?v=S-VaiB3uPdk ) En él, el objetivo siempre es dar un pequeño paso y ver cuánto más nos acerca a nuestra respuesta. Diseñar una base de datos es excelente si estamos en un control de proceso definido porque ya sabemos con certeza cuáles son todos los pasos y solo es cuestión de seguirlos. Es horrible para el control empírico de procesos porque aprendes poco o nada de él. Sabes que hiciste un trabajo, pero no hay manera de saber si es el trabajo correcto.
Entonces, si se pregunta cuál es el siguiente paso y cómo usará el próximo incremento del producto para aprender algo sobre cómo su cliente usará el producto y qué significa realmente "hecho" para usted, probablemente esté en lo correcto. camino correcto, incluso si no termina codificando la funcionalidad de la interfaz de usuario.
Daniel