¿Qué entregas en las primeras iteraciones en Agile?

Según tengo entendido, la idea con las metodologías ágiles es que entregue algo funcional y lo entregue a menudo. La aplicación obtiene su forma final de incremento tras incremento.

Pero en las primeras iteraciones, puede construir el marco o los cimientos sobre los que se sostendrá la aplicación, por lo que es algo importante pero no visible para los usuarios.

¿Qué se entrega al cliente en estas primeras iteraciones? ¿Cómo muestra el progreso en la dirección correcta cuando crea código de andamio?

Es típico tener sprints de 2 semanas.

Para mí, el primer sprint o 2 probablemente tendrá menos características "visibles" que los sprints posteriores por esta razón exacta (por alguna descripción tenue de "menos").

Dicho esto, ciertamente no debería tomarle 2 semanas construir todo su andamio y no tener nada visible en la interfaz de usuario para mostrarlo.

Tal vez no completes cada elemento del andamio en el primer sprint o 2. Tal vez las partes puedan esperar y agregarse más tarde.

Tal vez su primer sprint tenga "Crear página web X con datos ficticios" para que pueda obtener algo brillante para mostrarle a su cliente. Y luego el próximo sprint tiene "Cambiar la página web X para usar datos de la base de datos".

El Manifiesto Ágil sugiere que el software de trabajo es más valioso que la documentación completa, y el marco de Scrum toma esta noción para sugerir que la entrega de software de trabajo probado con valor comercial sea un requisito en cada sprint.

¿Por qué? Bueno, entre otras cosas, los diseñadores y desarrolladores a menudo son víctimas de pasar mucho tiempo en artículos YNNI (nunca lo necesitará). Desafortunadamente, esos marcos de los que está hablando son a menudo una gran responsabilidad en esta área. Los desarrolladores comienzan a construir todo lo que el marco podría tener que soportar y de repente tienes 3 meses y no tienes nada de valor comercial que demostrar. Entonces resulta que el marco ni siquiera es realmente compatible con lo que terminan necesitando.

Entonces, el enfoque sugerido es construir solo lo que realmente se necesita ahora y entregarlo ahora.

Esto NO significa que no puede construir piezas reutilizables y similares, siempre lo hace en apoyo de la construcción de una necesidad actual. Además, no significa que deba usar anteojeras por completo para lo que viene en el futuro: no construya cosas para que sea imposible cambiarlas / mejorarlas más adelante. Pero la clave es estar siempre entregando valor comercial.

A menudo hay algunas cosas clave que deben establecerse absolutamente antes de que se pueda entregar algo, como la configuración de entornos y similares. Por estas cosas, a muchos equipos les resulta útil tener un "Sprint 0" en el que se sientan las bases. El Sprint 0 puede ser un poco más largo que sus otros sprints, ya que no se aplica a la acumulación o el agotamiento de su producto, pero aún debe tener una duración razonable.

¿Qué se entrega al cliente en estas primeras iteraciones?

Lo que tiene el mayor valor comercial para el usuario. Por ejemplo, si las aplicaciones tienen reglas comerciales complejas, las primeras iteraciones solo contendrán aquellas reglas comerciales codificadas en forma de código. El cliente debe estar satisfecho siempre que tenga un código para esas reglas comerciales. (El problema de persuadir realmente al cliente para que acepte tal cosa es un asunto completamente diferente). Por ejemplo, puede mostrar a los expertos comerciales del cliente sus pruebas de unidad / aceptación que expresan lo que debe hacer el dominio y ese código lo pasa con un resultado verde. O incluso mejor, haga que los expertos en negocios ayuden a crear esas pruebas.

También hay una cuestión de

podrías construir el marco o las bases

Lo que creo es mucho más importante que lo que realmente se entrega. Hay gran cosa para el diseño evolutivo , que dice que debe crear la arquitectura con el tiempo en lugar de intentar crearla al principio. En cuanto a la base, esto generalmente significa algún tipo de base de datos o marco de interfaz de usuario. En ese caso, existe la idea de "La buena arquitectura es aquella que le permite posponer decisiones importantes ". Y elegir una base de datos o interfaz de usuario es una decisión importante. Por ejemplo, podría estar bien con solo el almacenamiento en memoria para los datos en lugar de tratar de usar DB desde la primera iteración.

Lo que intentamos hacer es entregar en las primeras iteraciones la aplicación más simple posible (una versión hello world de lo que estamos entregando). Vemos 3 beneficios importantes en esto:

• Configure el procedimiento de entrega (siempre una de las partes más difíciles en mi humilde opinión) (obtenga entornos, servidores en su lugar, actualice la seguridad para este entorno). Como entregaremos a menudo, es importante hacer esto bien lo antes posible.
• Ofrezca a los usuarios un primer vistazo de cómo se verá la aplicación. Esto ayuda a los usuarios y a los desarrolladores a comprender lo que realmente quieren y necesitan.
• Tenga una idea básica sobre cómo se verá la arquitectura de la aplicación (la aplicación debe cubrir las 'capas' o componentes básicos de la aplicación).

Pero en las primeras iteraciones, puede construir el marco o los cimientos sobre los que se sostendrá la aplicación, por lo que es algo importante pero no visible para los usuarios.

Esto está mal, ya que no necesita crear un marco que pueda usar en el futuro. La idea es construir solo lo que se necesita (ver también YAGNI ).

En el sprint cero, debes prepararte para el trabajo real. Mucha gente discute lo que se debe hacer en este sprint, pero en mi opinión, está terminado cuando puedes comenzar a trabajar en los elementos de la cartera de pedidos. Este paso incluye la configuración de PC, el proceso de compilación, la selección de marcos, etc.

Cuando haya terminado con el sprint cero (o la iteración cero), puede comenzar a trabajar en su aplicación. Tome elementos de la cartera de pedidos y termínelos uno por uno. Después de que termine la iteración uno, tendrá algo útil. La primera iteración generalmente incluye algunas de las características más importantes.

¿Qué se entrega al cliente en estas primeras iteraciones? ¿Cómo muestra el progreso en la dirección correcta cuando crea código de andamio?

Después de la iteración cero, obviamente no tiene nada que entregar. La entrega viene después de la iteración uno. Contiene características que estableces para la iteración.

Si su pregunta es "¿cómo elegir qué incluye la iteración X?", Eche un vistazo a estos videocasts (videos para la iteración 0 A y parte de B).

Puedes entregar casi todo lo que quieras. La idea de construir la infraestructura es simplemente incorrecta / no ágil / insostenible.

Por ejemplo: construir una aplicación Hello World completamente funcional se puede construir en horas. Abrir un servidor (incluso temporalmente) en la nube o como una VM se puede hacer en horas.

Estos son suficientes para comenzar a desarrollarse . Luego, si necesita CI, puede agregar una historia de CI, si necesita un servidor físico, seguro, agregue una historia para eso.

¡Pero comience a entregar el día 1 y nunca pare!

Las primeras iteraciones, especialmente la primera, contendrán o al menos deberían planificar picos arquitectónicos, que incluyen una cierta cantidad de tiempo de descubrimiento y tal vez algunos prototipos arquitectónicos.

Como usted dijo, en general, existen requisitos estructurales que pueden no significar mucho para la parte interesada / cliente, pero se requieren para formar una plataforma sólida o una orientación de patrón. No puedes evitar esto ya que no puedes comenzar a construir B hasta que A esté completo.

Parte del enfoque ágil es hacer que el cliente se cierre, por lo que no se necesita documentación porque todo lo que necesita hacer es levantar el teléfono / enviar un correo electrónico, y se espera. Las expectativas de los clientes deben establecerse adecuadamente y cualquier trabajo completado debe ser muy breve y NECESARIO . Sin chapado en oro, sin "Puede que lo necesite", etc. Construya lo que necesita en A para pasar a B.

Dependiendo de cómo esté atacando el proyecto, solo puede construir la base requerida para completar un determinado módulo, por lo que durante la reunión de planificación del sprint, establecería los planes para el sprint actual en función de las prioridades establecidas por el cliente, dependiendo de lo que se necesita para ese sprint, puede haber algunos requisitos fundamentales, por lo que eso es lo que entra en el sprint 1. Después de que se complete el primer sprint y se haya construido A y luego planee completar B.

Si ha acordado un cronograma con el cliente, siempre que cumpla con ese acuerdo, al cliente probablemente no le importará lo que haga primero o segundo. Siempre puedes mostrarles los resultados de la prueba de la unidad, pero si dices que tendremos algo para que veas después del sprint 2 (o 3), y lo entregas, establecerá una fuerte precedencia. Se espera que los clientes sean razonables tanto como lo son los desarrolladores y ambos están trabajando para lograr el mismo objetivo. Un proyecto completado que satisface las necesidades del cliente y funciona como se espera. Entonces, preocuparse de que no haya nada que ver después del sprint 1 es un punto discutible porque el cliente solo quiere asegurarse de que después del sprint 20, el proyecto se realizará (-ish).