Aprende a cómo dividir historias que generen valor, y cómo manejar el agilísimo en un juego rápido y divertido

Ejercicio Carpaccio de Elefante
Cómo Escribir buenas Historia de Usuario.
(Adaptado de Henrik Kniberg & Alistair Cockburn, 2013-07-11)

Aprende cómo crear historias que generen valor, y cómo manejar el Agilísimo en un juego rápido y divertido.

¿De qué se trata este Ejercicio?

El ejercicio Carpaccio de elefante es una excelente manera para que las personas de software practiquen y aprendan a dividir historias en rodajas verticales muy delgadas. También conduce a interesantes debates sobre calidad y prácticas tecnológicas.

El ejercicio fue inventado por Alistair Cockburn. Lo hemos co-facilitado muchas veces y alentamos a las personas a que lo ejecuten en todas partes.

Esta es una guía de facilitación detallada, basada en cómo Alistair lo ejecuta más algunas adaptaciones menores de Henrik.

El ejercicio dura 90-120 minutos y se adapta bien. Normalmente lo hacemos con 10-20 personas, pero también lo hemos hecho con grupos de hasta 30.

Tiempo de Dedicación:

2 horas es lo mejor, 1.5 horas funciona, pero se siente un poco apresurado.

• Discusión de 15-20 m sobre historias de usuarios.
• 20-30m desglosando la cartera de pedidos
• 40m de codificación
• 15-20m de informe

Es posible omitir la parte de codificación y solo practicar creando el trabajo atrasado. Pero le quita gran parte de la diversión, y también se pierde una discusión interesante sobre la calidad del código al final.

Antes de Empezar:

• Imprima este folleto para todos (o escriba la mitad inferior en una pizarra).
• Asegúrese de que la mitad de los participantes tengan una computadora portátil con un entorno de desarrollo de trabajo. Menos está bien, pero al menos cada tercer participante debe tener uno.
• Asegúrese de que haya enchufes en la habitación.
• Internet no es realmente necesario para el taller, pero es útil poder buscar cosas durante la programación.

¡Hora de Trabajar en equipo!

Introducción

• El propósito de este taller es aprender a dividir historias realmente pequeñas.

¿Por qué dividir historias? (opcional)

Esta parte solo es necesaria si aún no ha discutido el valor de dividir historias

Historia = vertical, comprobable, valiosa para el usuario. Corta en múltiples capas arquitectónicas.

Corte de historias = hacer historias más delgadas (pero aún verticales)

• ¿Qué tan grandes son tus historias? ¿Tareas? ¿Se compromete? (marca en la línea de tamaño)
• Objetivo: Historia = unos días. Tarea = unas pocas horas. Comprometerse = varias veces por hora.
• ¿Por qué dividir historias? Discutir en parejas. (solicite a cada par que informe, pregunte qué falta, agregue cualquiera de los siguientes que aún faltan).
• Aprende más rápido. Entregar más a menudo. Interesados más felices. Más sincronizado con otras personas y equipos. Mejores priorizaciones. Mejor producto antes. Más opciones de negocios. Menos riesgo (menos tiempo «bajo el agua»). Sentido de la velocidad. Planificación más fácil.
• Dibujar curvas de valor para cascadas, grandes historias e historias pequeñas. Discutir. ¿Por qué la curva de «historias pequeñas» termina con un valor acumulado más alto?

• La decisión de «cuán pequeño» no debe estar limitada por «no podemos dividir esta historia». En este taller practicaremos exagerando. Haremos historias tan pequeñas que cualquier cosa que hagas hoy parece grande en comparación.
• Cree una aplicación simple en 40 minutos, dividida en 5 iteraciones x 8 minutos.
• La mayoría de las personas construirían esta aplicación en 2-3 segmentos, lo haremos en 15-20 Min.
• Carpaccio de elefante = rodajas muy finas, cada una con forma de elefante. Juntos forman todo el elefante.

Ejemplo:

¿Cuál es nuestro Producto?

• ¡Cierra tus computadoras portátiles! (o las personas jugarán con su entorno en lugar de escuchar)
• Remita a las personas al TABLERO/FOLLETO O CARTA DE INSTRUCCIONES).
• Construiremos una calculadora minorista. Es una aplicación ejecutable con interfaz de usuario, tres entradas y una salida.
  • Use cualquier lenguaje de programación. La interfaz puede ser consola, línea de comando, web, guia, lo que sea.
• Tres entradas:
  • ¿Cuántos artículos
  • Precio por artículo
  • Código de estado de 2 letras

• Salida: precio total del pedido. Ofrezca un descuento basado en el precio total, luego agregue el impuesto al consumo (IVA) basado en el código estatal y el precio con descuento.

¿Cuáles serán nuestras Prioridades?

• Se ilustrarán las prioridades en esta curva de valor.

El objetivo es 5 descuentos, 5 estados.

• Lo dividirá en 10-20 rebanadas.
• Un segmento solo es válido si tiene una HU, entrada y salida, y es visiblemente diferente del último segmento.
• Quiero 5 estados antes de hacer algo con descuentos. ¿Por qué? (¡para que podamos implementarlo! El impuesto estatal es un requisito legal, el descuento no lo es)

• Validación de excepciones y GUI elegante, viene después de 5 estados y 5 descuentos. ¡No gastes tiempo en eso antes! (La casa se decora a lo último de la obra)

• ¡Sin adornos! Practique en la construcción de la cosa de mayor valor primero, todo el tiempo. Por ejemplo, antes de tener 5 estados, ¡no desperdicie una sola pulsación de tecla en el código relacionado con el descuento!
• No me importa qué tan lejos llegues en esta curva. Lo importante es que practiques microslicing. Si llegas hasta el final con solo 3 rebanadas, has perdido tu tiempo y has perdido el objetivo de este ejercicio.

¿Pudiste evaluar lo que hemos hecho?, nunca arranques tu backlog de trabajo sin antes un análisis (Prioridad, legal, impactos, riesgos)

Ahora si creemos nuestro Backlog

• Divida en grupos de 2 o 3 (2 es mejor). Cada grupo debe tener al menos un programador con un entorno de desarrollo de trabajo.
• 10 minutos: escriba su trabajo atrasado en papel (las computadoras portátiles aún están cerradas).
  • Escriba entre 10 y 20 historias de usuario con capacidad de demostración («cortes») que lo llevarán de la nada a 5 estados y 5 descuentos.
  • Guía de corte válida:
    • Implementable (incluida la interfaz de usuario) en 2-6 minutos.
    • Notable diferencia de la última rebanada
    • Más valioso para el cliente que la última porción (excepción: para el primer par de porciones, está bien centrarse en reducir el riesgo).
  • Ningún segmento es solo una maqueta o interfaz de usuario, una estructura de datos o un caso de prueba.
• ¿Cuál es tu primer corte?
  • (cualquier cosa más grande que hello-world o echo-input-to-output es demasiado grande.
  • Discuta el valor de reducción de riesgos de implementar y «entregar» hola mundo como primer segmento. Valor = valor del cliente + valor del conocimiento
  • Discuta el valor de construir rápidamente una versión de «esqueleto ambulante» de la aplicación (todos los componentes arquitectónicos clave están en su lugar y conectados, pero no hay «carne», por lo que tenemos un esqueleto ambulante).
• En algún punto del camino, debe alcanzar el hito del «valor del pedido», donde tiene 2 entradas («# de artículos» y «precio por artículo») y multiplicarlos. Sin descuentos / estados.

• ¿Cuál es su próximo segmento, después del valor del pedido? (probablemente será demasiado grande, ¡desafíelos a que sea más pequeño!). Muestra de trabajo atrasado:
  • Valor del pedido. 2 entradas, 1 salida. Sin impuestos estatales, sin descuentos.
  • Impuesto estatal codificado. Todavía 2 entradas, 1 salida. Impuesto IVA agregado automáticamente.
  • 3 entradas (precio por artículo, número de artículos, % de impuesto). La salida es el valor del pedido con impuesto estatal agregado.
    • El usuario ingresa la tasa impositiva real en lugar del código IVA. Esto proporciona un código más simple, por lo que obtenemos una entrega más rápida.
  • 3 entradas (precio por artículo, número de artículo, impuesto), pero solo se admiten dos estados. Cualquier otro da mensaje de error.
  • Agregue los otros 3 estados. (discuta por qué hay un valor limitado al agregar 1 estado a la vez en este momento; no hay un valor de reducción de riesgo y, literalmente, lleva solo unos segundos más a los 3 estados a la vez)
• Punto clave: ¡Pulsaciones mínimas de tecla por segmento! Queremos el máximo valor con el mínimo esfuerzo (= ¡Lean!) (UX)
• 5 minutos: reduzca las rodajas. Pruebe por lo menos 15 rebanadas.

¿Cómo vas a trabajar? (Opcional)

Este taller trata principalmente sobre el corte de historias, pero agregar un aspecto de prácticas tecnológicas le da más sabor.

• ¿Cómo escribirás y probarás tu código? Toma una decisión y apégate a ella. ¡Hágase responsables!
  • Opción 1: TDD. Por el libro TDD. Refactor verde rojo. Comience cada segmento escribiendo una prueba que se ejecuta, pero falla. Luego haga la prueba verde. Luego re-factorice el código y hágalo limpio.
  • Opción 2: rojo-verde. Igual que el anterior, pero la refactorización es opcional.
  • Opción 3: algunas pruebas. Escribirá algunas pruebas, pero no para todas las rebanadas, y no necesariamente para probar primero.
  • Opción 4: NFT (sin pruebas de f * ing). (Agregar emoticones de Risa)
• ¿Vinculará el programa (= cambiará con frecuencia) o tendrá una persona de negocios y un programador (prueba de persona de negocios, retroalimenta y mejora la cartera de pedidos)?

Constrúyelo

• 40 minutos, 5 iteraciones, 8 minutos por iteración.
• Al final de cada iteración, llamaré «¡tiempo de demostración!» . Eso significa dejar de codificar y demostrar su aplicación a otro equipo. Luego vuelve a la codificación.
  • ¡El tiempo no se detiene entre iteraciones! Así que no gastes demasiado tiempo en la demostración.
• Grita «corte» cada vez que termines un corte.
• ¡Ve!
  • (inicie el temporizador de 8 minutos. Recuerde reiniciarlo inmediatamente después de cada sprint. También haga un seguimiento cuidadoso de la iteración en la que estamos ahora, es fácil de olvidar).

Revisión

• ¿Hasta dónde llegaste? (marque la posición aproximada de cada equipo en la curva de valor)
  • (resultado típico: algunos equipos obtienen más de 5 estados y 5 descuentos. La mayoría de los equipos al menos obtienen impuestos codificados).
• ¿Cuántas rebanadas tuviste?
• Prueba de aceptación:
  • Inicie su aplicación e ingrese estos valores: estoy en Utah, compro 978 artículos, cada artículo cuesta $ 270.99. (o elija los valores que desee).
  • ¡Dime la salida! (escriba el resultado de cada equipo en la pizarra).
  • No juegues, solo ejecuta la aplicación e ingresa los valores y mira lo que sale.
  • (compare los resultados. A menudo los resultados difieren, lo cual es divertido. Discuta la posible razón de esto. Algunos equipos no admiten números decimales para el precio del artículo, discuten suposiciones falsas y cómo revelarlas).

Interrogatorio =), Retrospectiva.

• No programadores: ¿Cómo fue?
• Programadores: ¿Cómo fue?
  • ¿Cómo es la calidad de su código, qué tan orgulloso está de su código? (cada programador levanta de 1 a 5 dedos).
    • Las personas con TDD deben tener 4 o 5, de lo contrario se han salteado o mal entendido el paso de refactorización en TDD.
    • La mayoría de los programadores serán 1-2. Discuta cómo esto es un peligro potencial de iteraciones cortas y pequeñas historias. Discuta la importancia del ritmo y la calidad sostenibles, y cómo los desarrolladores son responsables de esto (Principio ágil básico: el equipo elige cuánto trabajo realizar). Discuta la presión «percibida» versus la presión real.
  • ¿Alguna otra pregunta o reflexión?
  • Round-robin: ¿Qué aprendiste? ¿Qué harás? Nombra una visión para llevar de hoy y una cosa que harás de manera diferente en el futuro.