Aquí hay un resumen de los 9 pasos para decidir la fecha de entrega del producto (y su MVP), basado en Lean Inception:
- Crear el secuenciador de features
- Seleccione dos líneas de secuenciador
- Describir las tareas de cada feature
- Agrupar tareas por tamaño
- Decide el tiempo de cara a cada tamaño de tarea
- Calcular el tiempo promedio por línea del secuenciador
- Calcular la capacidad del equipo
- Decide el tiempo del Sprint 0
- Mostrar fechas y entregables
Este resumen se describe en detalle en el libro sobre Lean Inception y en este post, donde respondo una de las preguntas más frecuentes sobre Lean Inception.
Pregunta: Me encanta el libro Lean Inception. Pero tengo una pregunta muy importante: mi cliente quiere saber cuándo estará listo el MVP y todo el producto. como apreciar
Respuesta: Esta es la pregunta del millón de dólares. Aquí hay una explicación de cómo trato de ayudar con esto.
Siempre hay alguien que quiere saber las fechas de entrega. Y, normalmente, quieren saber esto por el MVP y por todas las funcionalidades previstas para el producto (una contradicción, ya que sabemos que el producto cambiará –pivot– a medida que recibamos y actuemos sobre el feedback de su uso).
Pivote, pivote y pivote; este es el lema de quienes trabajan con Lean StartUp y MVP
Por lo general, no hablo de fechas de entrega y estimaciones en conferencias y capacitación de Lean Inception. Este tema genera mucha confusión; incluso cierta contradicción (¿a qué te refieres con ser ágil y trabajar con MVP, pero con un alcance cerrado?!).
El libro Lean Inception tiene un capítulo sobre esto (casi no quito ese capítulo – de hecho, salieron otros capítulos del libro, para secarlo… este fue, apenas).
1. Crear el secuenciador de features
Utilizo el Secuenciador para esta “estimación” (no me gusta esa palabra ni los recuerdos que trae; soy partidario del movimiento NoEstimates). En el libro Lean Inception, llamo al capítulo que describe esto: Cálculo de esfuerzo, tiempo y costo. En un Lean Inception, cuando es necesario, utilizo la siguiente secuencia de actividades para ayudar al equipo a decidir las fechas.
2. Seleccione dos líneas de secuenciador
Para empezar, le pido al equipo que elija dos o tres líneas en el Feature Sequencer.
3. Describir las tareas de cada feature
Así que le pido que describa todas las tareas necesarias para completar estas features.
Yo suelo decir esto:
Imagina que completamos una feature con la calidad deseada, con todas las pruebas necesarias, con automatización, con los scripts necesarios, con los requisitos no funcionales, etc. Vamos a escribir todas las tareas que tenemos que hacer para lograr esto.
El equipo escribirá las tareas para cada feature. Así que voy a usar estas tareas detalladas para obtener la «estimación».
4. Agrupa las tareas por tamaño
A continuación, le pido al equipo que agrupe las tareas por tamaño relativo: pequeño, mediano y grande.
5. Decide el tiempo de cara a cada tarea
Así que le pregunto al equipo cuánto tiempo lleva entregar algunas de estas tareas. En general, las tareas del mismo tamaño relativo toman una cantidad de tiempo similar (las tareas se agruparon previamente por tamaño relativo, naturalmente esto sucede; este es un buen momento para revisar si alguna tarea debe repensarse, reescribirse y reconsiderarse).
Luego le pido al equipo que me ayude a elegir una duración para cada grupo de tareas. Por ejemplo, las respuestas para tareas pequeñas son: 3 horas, 3 horas, 2 horas, 4 horas, 3 horas, 5 horas, 4 horas, 4 horas, 3 horas, 5 horas, 2 horas, 3 horas, 2 horas, 4 horas; Preguntaré si el equipo se siente cómodo considerando una pequeña tarea que toma alrededor de 4 horas.
Hago lo mismo para cada grupo de trabajo: pequeño, mediano y grande.
6. Calcular el tiempo promedio por línea del secuenciador
Luego sumamos la duración de todas las tareas y luego las dividimos por dos (dos líneas en el secuenciador de características).
Con eso, llegamos a un número. Por ejemplo: 200 horas por desarrollador por línea.
Opcionalmente, puede calcular para llegar al tiempo promedio de una E (una función tiene de una a tres Es).
7. Calcula la capacidad del equipo
Luego empiezo la conversación sobre la capacidad del equipo:
Considere la capacidad del equipo: la cantidad de desarrolladores que trabajan en estas tareas; si el equipo está dedicado; vacaciones y feriados; licencia por enfermedad y porcentaje de ausencias (por ejemplo: el porcentaje de ausencias durante el invierno en Porto Alegre debe ser mayor que en la primavera, dada la cantidad de personas que tienen gripe y resfriado en ese momento).
Luego hago los cálculos y escribo el resultado, como una fecha.
Por ejemplo, el equipo tiene 4 desarrolladores, trabajando con una capacidad dedicada del 80% (días festivos, vacaciones y soporte de nivel 2 para corrección de errores en otro producto)
• 200 horas para 1 dev => 50 horas para 4 dev
• 50 horas al 100 % de capacidad => 62,5 horas al 80 % de capacidad (50 horas * 100 % / 80 %)
• Cada fila en el secuenciador de features debe consumir 62,5 horas para nuestro equipo
8. Decide el tiempo del Sprint 0
Hable sobre Sprint 0 o cuántos Sprints, cuánto tiempo, necesita el equipo para preparar la infraestructura mínima para comenzar el trabajo funcional, la primera funcionalidad de la línea 1 del secuenciador.
9. Mostrar fechas y entregables
Con el tiempo Sprint 0 y el tiempo por línea del secuenciador, podemos estimar las fechas para los entregables. Por lo general, a las personas que pagan para construir el producto les encanta esta actividad. Obtienen una fecha para el MVP y pueden extrapolar el cálculo a todo el producto (todas las filas en el secuenciador).
A continuación se muestra un resultado de ejemplo. Tenga en cuenta en esta imagen que el equipo usó los nombres V1 y V2 en lugar de MVP e incremento. también tenga en cuenta que el equipo decide quedarse con un par de desarrolladores para las mejoras de V1. Ambas decisiones tienen que ver con el contexto de la empresa. Y esto es esencial. Sigue estos pasos, pero adáptate a la realidad de tu contexto actual.
Entrega el MVP!
Tal vez los desarrolladores desconfíen de tener una cita (yo era un desarrollador y soy un agilista, entiendo quién está agotado debido a fechas y plazos fijos). Pero eso no es malo para los desarrolladores. Al contrário. Tienen algo para ayudarlos: el MVP con sus características.
El punto es que el resultado de Lean Inception, como se describe en el secuenciador, describe las funcionalidades de MVP. Pero no detalla cómo se crearán (las tareas descritas en esta publicación solo se usaron para el muestreo).
Por lo tanto, el equipo puede (y debe) ser creativo y responsable de entregar el MVP a tiempo. Repensar cómo entregar funcionalidad con tareas más simples, que requieren menos trabajo, para lograr el producto mínimo viable.
![[WSJF + RICE] Tabla de priorización colaborativa](https://caroli.org/wp-content/uploads/2020/02/prioritization-wsjf-rice-scaled.jpg)
