El modelo de gestión de proyectos, parte 1: una comparación exhaustiva de Agile, Scrum, Kanban y Lean

Visión de conjunto

Hoy en día se utilizan muchas metodologías en el desarrollo de software. Es posible que haya escuchado palabras de moda como Waterfall, Agile, Scrum, Kanban, Lean, Extreme Programming, etc.

En este artículo, definiré estos términos, discutiré cómo se relacionan entre sí y cómo se diferencian entre sí. Muchas de las palabras de moda antes mencionadas se basan en conceptos de Lean Manufacturing, que originalmente se basó en el Sistema de fabricación de Toyota (TPS), por lo que hablaremos de esto primero.

Metodología esbelta

Orígenes de Lean y Lean Manufacturing

El término "Lean" tiene su origen en la fabricación, donde se acuñó para describir un modelo de fabricación basado en el Sistema de producción de Toyota (TPS) desarrollado originalmente por Sakichi Toyoda, Kiichiro Toyoda y Taiichi Ohno, quienes originalmente se inspiraron en Henry Ford. TPS se centró en la filosofía de "la eliminación completa de todos los residuos" y revolucionó la fabricación en las décadas de 1950 a 1970. TPS se conoció como "Lean Manufacturing" en 1990 cuando se publicó "La máquina que cambió el mundo".

TPS identificó tres tipos generales de desperdicio en Toyota:

• Muda: traducido como "desperdicio". Se identificaron siete tipos de muda en Toyota y luego se agregó un octavo. Estos son:
  • Defectos: esfuerzo involucrado en encontrar y corregir defectos
  • Sobreproducción: producción por delante de la demanda
  • En espera: esperando el siguiente paso de producción, interrupciones, etc.
  • Talento no utilizado: capacidades infrautilizadas, formación inadecuada, etc.
  • Transporte: partes móviles o productos que no se requieren para el procesamiento
  • Inventarios: inventario terminado y trabajo en proceso
  • Movimiento: moverse o caminar más de lo necesario para el procesamiento

  • Procesamiento excesivo: debido a herramientas o diseño de producto deficientes

• Muri: traducido como “sobrecargar”. Muri generalmente resulta de mura pero puede resultar de muda. Muri se manifiesta en averías, absentismo, problemas de seguridad, etc.
• Mura: traducido como “desigualdad”. Mura se puede encontrar en la fluctuación de la demanda del cliente, los tiempos de proceso por producto o la variación de los tiempos de ciclo para diferentes operadores. Cuando mura no se reduce, se aumenta la posibilidad de muri y, por lo tanto, de muda. Mura se puede reducir creando apertura en la cadena de suministro, cambiando el diseño del producto y creando un trabajo estándar para todos los operadores.

TPS trabajó para eliminar el desperdicio aplicando estos dos conceptos básicos:

• Jidoka: traducido libremente como "automatización con un toque humano" estipula que "¡La calidad debe incorporarse durante el proceso de fabricación!" lo que significa que cuando ocurre un problema, el equipo se detiene inmediatamente, evitando que se produzcan productos defectuosos.
• Justo a tiempo: hacer solo "lo que se necesita, cuando se necesita y en la cantidad que se necesita".

A medida que TPS evolucionó, estos pilares y valores centrales se basaron en los conceptos de Jidoka y JIT y se consolidaron:

• Mejora continua:
  • Desafío: formar una visión a largo plazo y enfrentar los desafíos con coraje y creatividad para hacer realidad los sueños
  • Kaizen: mejora continua de las operaciones comerciales, impulsando siempre la innovación y la evolución, eliminando un muda a la vez
  • Genchi Genbutsu: practicar genchi genbutsu, ir a la fuente para encontrar los hechos para tomar decisiones correctas, generar consenso y lograr objetivos a nuestra mejor velocidad
• Respeto por la gente:
  • Respeto: respetar a los demás y hacer todo lo posible por entendernos, asumiendo la responsabilidad y haciendo todo lo posible para generar confianza mutua.
  • Trabajo en equipo: estimular el crecimiento personal y profesional, compartir oportunidades de desarrollo y maximizar el desempeño individual y del equipo.
• Andon: un indicador visual de estado o problema
• Heijunka: significa nivelación o nivelación de producción
• Hansei: significa autorreflexión. Para mejorar la eficiencia, los trabajadores deben desafiar los supuestos detrás de los procesos actuales para encontrar mejores.
• Kanban: un letrero utilizado como herramienta visual para controlar la producción
• Poka-yoke: también conocido como prueba de errores o prueba de errores
• Sistema de extracción: el material se introduce en una estación de trabajo justo cuando se necesita
• Seiri: es el principio que refleja los residuos. Seiri dicta que lo innecesario debe ser eliminado. Esto abarca todos los siete desechos originales de TPS
• Estandarización: organiza todos los trabajos en torno al movimiento humano y crea una secuencia de producción eficiente sin muda. Esto ayuda a conducir a la calidad, a un ritmo constante y permite la mejora continua.

El siguiente diagrama muestra cómo los conceptos centrales y los valores centrales se relacionan entre sí.

Gestión eficiente

El Sistema de Productos Toyota y la Manufactura Esbelta evolucionaron con el tiempo y se aplicaron en varias áreas, incluida la gestión.

Lean Management aplicó los valores fundamentales de la mejora continua y el respeto por las personas y los destiló en un conjunto de cinco principios prescriptivos de Lean que se repetirían varias veces para mejorar continuamente y eliminar el desperdicio:

1. Identificar valor: especifique un valor desde el punto de vista del cliente final por familia de productos.
2. Mapear flujo de valor: identificar todos los pasos en el flujo de valor para cada familia de productos, eliminando siempre que sea posible aquellos pasos que no crean valor.
3. Crear flujo: haga que los pasos de creación de valor ocurran en una secuencia estrecha para que el producto fluya sin problemas hacia el cliente.
4. Establezca la atracción: a medida que se introduce el flujo, permita que los clientes obtengan valor de la siguiente actividad ascendente.
5. Buscar la perfección: a medida que se especifica el valor, se identifican los flujos de valor, se eliminan los pasos desperdiciados y se introducen el flujo y la atracción, comienza el proceso nuevamente y continúa hasta alcanzar un estado de perfección en el que se crea el valor perfecto sin desperdicio.

Estos principios y otros aspectos de la gestión Lean se formalizaron cuando Womack & Jones publicaron "Lean Thinking" en 1996.

Desarrollo de software esbelto

Desde entonces, Lean se ha aplicado a la gestión, el desarrollo de software y otros campos.

En las décadas de 1980 y 1990, la industria del desarrollo de software se acercaba a una crisis a medida que los proyectos ejecutados con metodologías tradicionales en cascada tomaban más y más tiempo. Esto a menudo resultó en un gran retraso entre la identificación de una necesidad comercial y la entrega de una solución de software. A veces, este retraso se midió en varios años, o incluso en décadas en ciertas industrias con requisitos específicos, como la industria aeroespacial.

Durante estos plazos de varios años, los requisitos, los sistemas o incluso empresas enteras cambiaron. A menudo, los proyectos se cancelarían a la mitad o completarían su alcance, solo para descubrir que lo que entregaron ya no satisface las necesidades comerciales identificadas al comienzo del proyecto.

La metodología Waterfall recompensó a las partes interesadas por pensar en todo, ya que se vieron obligadas a redactar un contrato a pesar de que probablemente no estaban seguros de lo que necesitaban. La metodología Waterfall obligó a tomar decisiones durante la fase de requisitos o diseño, y estas decisiones fueron muy difíciles de cambiar sin cambiar el contrato y agregar costos al proyecto. Un alto porcentaje de proyectos de software fallaron por completo, o se entregaron tarde y por encima del presupuesto, o no entregaron lo que se necesitaba.

Esta frustración general llevó a varios líderes de opinión a intentar mejorar Waterfall. Los primeros ejemplos incluyen el desarrollo rápido de aplicaciones (RAD), que se centró en reducir el desperdicio al acortar los requisitos y las fases de diseño mediante el desarrollo rápido de un prototipo y la colaboración con empresas para desarrollar aún más el requisito. También hubo un movimiento hacia el desarrollo iterativo en el que se completó un pequeño proyecto y se agregaron funciones en iteraciones continuas. Si bien estas metodologías ayudaron, no resolvieron los problemas centrales asociados con Waterfall.

En la década de 1990 y principios de la de 2000, varios autores publicaron libros sobre la aplicación de los principios Lean al desarrollo de software. El Dr. Robert Charette publicó "Desarrollo de software Lean" en 1993 y "12 principios de desarrollo de software Lean" en 2003.

Tom y Mary Poppendieck publicaron "Lean Software Development: An Agile Toolkit" en 2003. Este libro detalla siete principios de Lean Development, que se correlacionan directamente con las siete formas de desperdicio en Lean Manufacturing. Las similitudes y diferencias entre las dos publicaciones Lean y Agile (discutidas en la siguiente sección) se muestran en el siguiente diagrama.

Diferencias entre Lean y Agile

Según el Dr. Charette, una de las principales diferencias entre Lean y Agile es que Agile es de abajo hacia arriba, mientras que Lean es de arriba hacia abajo.

Marco ágil

Orígenes de Agile y el manifiesto ágil

Casi al mismo tiempo que Charette y los Poppendieck publicaron sus libros, se creó Agile Framework para ayudar a resolver los mismos problemas. En febrero de 2001, un grupo de pioneros ágiles se reunió en la infame reunión de Snowbird en Snowbird, Utah, para intentar encontrar una solución.

El resultado fue el Manifiesto Agile, que estableció un conjunto de valores y principios para una metodología que intenta adaptarse a los requisitos cambiantes y las necesidades de los clientes, reducir los desperdicios y brindar beneficios más rápidamente mediante un enfoque incremental e iterativo.

El Manifiesto Ágil dice lo siguiente:

“Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a otros a hacerlo. A través de este trabajo hemos llegado a valorar:

• Individuos e interacciones sobre procesos y herramientas.
• Software de trabajo sobre documentación completa
• Colaboración con el cliente sobre la negociación del contrato
• Responder al cambio sobre seguir un plan

Es decir, mientras hay valor en los artículos de la derecha, valoramos más los artículos de la izquierda”.

Alineados con los valores del manifiesto están los 12 principios detrás del Manifiesto Ágil:

“Seguimos estos principios:

1. Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y continua de software valioso.
2. Da la bienvenida a los requisitos cambiantes, incluso al final del desarrollo. Los procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.
3. Entregue software que funcione con frecuencia, desde un par de semanas hasta un par de meses, con preferencia a la escala de tiempo más corta.
4. Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el proyecto.
5. Construir proyectos en torno a personas motivadas. Bríndeles el entorno y el apoyo que necesitan, y confíe en ellos para hacer el trabajo.
6. El método más eficiente y efectivo para transmitir información a un equipo de desarrollo y dentro de él es una conversación cara a cara.
7. El software que funciona es la medida principal del progreso. Los procesos ágiles promueven el desarrollo sostenible.
8. Los patrocinadores, desarrolladores y usuarios deberían poder mantener un ritmo constante indefinidamente.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.
12. A intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo, luego sintoniza y ajusta su comportamiento en consecuencia”.

Los valores y principios anteriores son aplicaciones de principios Lean como Jidoka, JIT, Genchi Genbutsu, Kaizen, Hansei, Heijunka y la reducción de residuos.

Principios ágiles aplicados al desarrollo de software

Agile es un marco general que se aplica a cualquier proceso que aplique el conjunto de valores y principios de Agile.

Algunos ejemplos son:

• Programación extrema
• Melé
• Kanban

Melé

Breve historia de la escoria

Scrum es un marco que aplica principios ágiles que fue inventado por separado por varias personas, varias de las cuales firmaron el Manifiesto ágil:

• Hirotaka Takeuchi e Ikujiro Nonaka inicialmente introdujeron el término "scrum" en un contexto de fabricación en su libro blanco "El juego de desarrollo de nuevos productos". publicado en 1986 en Harvard Business Review.
• Jeff Sutherland, John Scumniotales y Jeff McKenna implementaron Scrum en Easel Corporation en 1993.
• Ken Schwaber usó lo que se convertiría en Scrum en su empresa, Advanced Development Methods en la década de 1990.

Schwaber y Sutherland colaboraron a lo largo de la década de 1990 para desarrollar y refinar el marco en un contexto de desarrollo de software, hablando en varias conferencias. Schwaber trabajó con Mike Beedle para describir el método en el libro "Desarrollo de software ágil con Scrum" en 2001.

Schwaber pasó a crear las dos principales autoridades de certificación de Scrum:

• Scrum Alliance: creada en 2001. Configura la serie de acreditaciones Certified Scrum .
• Scrum.org: creado en 2009 después de que Schwaber dejara Scrum Alliance. Configure la serie paralela de acreditaciones de Professional Scrum .

Con el tiempo, se crearon varios marcos/organismos de certificación para abordar la escala del marco Scrum a equipos y proyectos más grandes, ya que Scrum se diseñó originalmente para equipos pequeños (7 más o menos 2 miembros):

• SAFe: marco ágil escalado
• LeSS: Scrum a gran escala
• Scrum@scale: Scrum a escala creado por Jeff Sutherland

Valores Scrum

Según la Alianza Scrum:

Scrum es un conjunto de principios y prácticas simple pero increíblemente poderoso que ayuda a los equipos a entregar productos en ciclos cortos, lo que permite una retroalimentación rápida, una mejora continua y una rápida adaptación al cambio.

Scrum es un marco prescriptivo, incremental e iterativo para desarrollar software que aplica principios ágiles. Los valores y principios de Scrum se describen en los cuadros a continuación y tienen una alineación significativa con los valores y principios de Lean y Agile.

Descripción general de Scrum

El trabajo se divide en iteraciones de breve duración denominadas sprints, que suelen durar de 1 a 3 semanas. Esto está en marcado contraste con la planificación en profundidad de Waterfall. El trabajo planificado para el sprint actual se elige de la parte superior de una acumulación priorizada de elementos de trabajo llamado Product Backlog (Pull System, Heijunka), y se fija una vez que comienza el sprint. El objetivo es tener un software que funcione al final de cada sprint, lo que permite una retroalimentación rápida.

Al final del sprint, el equipo se reúne para revisar el trabajo completo realizado, cómo fue el sprint y planificar el próximo sprint. La duración del sprint, así como los rituales y la cadencia del sprint, se fijan para cada sprint.

Los sprints son ejecutados por equipos multifuncionales que contienen todas las habilidades necesarias para completar el trabajo en el sprint. La planificación diaria y el seguimiento del progreso se realizan mediante artefactos visuales como el tablero Scrum y los gráficos de trabajo pendiente de sprint.

El trabajo en un sprint se extrae de un backlog priorizado. Seguir estos métodos permite cambiar los requisitos con el tiempo y fomenta la retroalimentación constante de los usuarios finales.

El siguiente diagrama de mapa mental describe algunos de los conceptos principales de Scum que se discutirán en las próximas secciones.

Roles de Scrum

Scrum tiene tres roles:

• Scrum Master : el Scrum Master es un líder servidor del equipo Scrum. Son el entrenador del equipo que ayuda a facilitar la colaboración, elimina los impedimentos, hace cumplir y salvaguarda el proceso Scrum y protege al equipo. Por lo general, esto significa que organizan y facilitan los rituales del sprint, se aseguran de que el propietario del producto tenga un backlog ordenado y priorizado correctamente, se asegura de que el equipo no esté presionado para comprometerse demasiado con un sprint, se asegura de que el alcance no se agregue a un sprint, asegura que se cumpla la Definición de Listo. No asignan tareas a los miembros del equipo (Genchi Genbutsu) y no son responsables de la entrega de un proyecto.
• Propietario del producto: el propietario del producto es 'el único cuello retorcido' responsable de la entrega del producto. El propietario del producto define la visión de lo que quiere construir y transmite esa visión al equipo y a la organización. El propietario del producto es dueño de los requisitos comerciales y del mercado y prioriza todo el trabajo que debe realizarse mediante la creación y gestión de la cartera de pedidos del producto. Ellos deciden qué características enviar y cuándo. Trabajan con el equipo y otras partes interesadas para asegurarse de que todos entiendan los elementos de la cartera de productos. Aceptan o rechazan el trabajo completado en un sprint en la demostración de sprint.
• Miembro del equipo : el equipo Scrum es un equipo interdisciplinario y autoorganizado que normalmente se compone de cinco a siete miembros. Todos en el proyecto trabajan juntos y se ayudan entre sí y no están necesariamente vinculados a roles distintos como arquitecto, programador, diseñador o evaluador. Todos completan el conjunto de trabajo juntos. El equipo Scrum planifica cuánto trabajo puede completar cada sprint y es dueño del plan (Genchi Genbutsu).

Scrum Flow, Actividades y Ceremonias

Como se discutió anteriormente, Scrum tiene un flujo definido y un conjunto de rituales y actividades. El flujo de un sprint es el siguiente.

Planificación de Sprint:

Antes de que comience un sprint, el Scrum Master facilita una reunión con el equipo scrum y el propietario del producto, llamada reunión de planificación del sprint, donde el propietario del producto identifica los objetivos del próximo sprint y luego el equipo planifica su trabajo de acuerdo con los objetivos.

Esto generalmente se hace con las siguientes actividades:

• Sprint Capacity: el equipo determina la capacidad para el sprint, teniendo en cuenta el número de días, número de miembros del equipo, vacaciones, etc.
• Sprint Objectives: el propietario del producto identifica cuáles son los objetivos para el sprint. Es fundamental que la cartera de productos se priorice de acuerdo con los objetivos (es decir, las historias relevantes estén en la parte superior) y se arregle.
• Selección de trabajo: las historias o tareas se extraen de la parte superior de la cartera de pedidos en el sprint hasta que se alcanza la capacidad estimada. A medida que se ingresan las historias, el propietario del producto explicará la historia y responderá las preguntas del equipo, actualizando la historia según sea necesario, hasta que el propietario del producto y el equipo Scrum tengan una buena comprensión común de la historia. Una vez que se completa esta actividad, el equipo tiene un alcance de sprint inicial propuesto.
• Desglose de tareas: el equipo de Scrum analiza cada historia en detalle con énfasis en planificar cómo completarán la historia y abordarán todos los criterios de aceptación y el DoD. Producirán una lista de subtareas necesarias para completar la historia. Una vez que la lista de subtareas está completa, la estimación de la historia se revisa y actualiza si es necesario.
• Compromiso de Sprint: una vez que se desglosan todas las historias y se actualizan las estimaciones, se revisa el alcance del Sprint inicial propuesto. Las historias pueden eliminarse del sprint y volver a colocarse en la cartera de pedidos y/o pueden agregarse historias adicionales. Una vez hecho esto, SOLO el equipo Scrum (y no el Scrum Master o el propietario del producto) se compromete a completar el trabajo en el sprint y se inicia el sprint.

La cantidad total de trabajo o alcance comprometido para el sprint se mide en puntos de historia.

Ejecución de Sprint

Durante el sprint, los miembros del equipo extraen elementos de trabajo (historias de usuario, tareas, etc.) de la parte superior de la lista de tareas pendientes del sprint para trabajar en ellos. Varios miembros del equipo trabajarán en los diversos elementos de trabajo o sus subtareas. Actualizarán el estado de un elemento cuando sea apropiado moviéndolo de una columna a la siguiente (normalmente Por hacer > En progreso > Prueba > Terminado o alguna variación del mismo) en el Scrum Board hasta que esté terminado.

El progreso se rastrea mediante un gráfico de trabajo pendiente que muestra la cantidad de trabajo completado y restante medido en puntos de la historia. Los puntos de historia restantes se muestran en el eje Y y el tiempo restante se muestra en el eje X. El gráfico de trabajo pendiente se actualiza cuando se terminan las historias.

Diariamente, el Scrum Master se enfoca en:

• Facilita la reunión diaria de pie para planificar el día y revisar el progreso (ver más abajo)
• Se asegura de que el equipo tenga un plan para el día.
• Elimina obstáculos
• Protege el sprint scope y al equipo de las distracciones
• Ayuda al equipo a mantener su tabla de trabajo pendiente y otras estadísticas de Scrum.

Reunión diaria

Al comienzo de cada día del sprint, el Scrum Master facilita una breve reunión de 15 minutos con el equipo de scrum y el propietario del producto para planificar el día y revisar el progreso del sprint. Esta es una reunión breve en la que todos están parados frente al tablero de Scrum y cada persona en la reunión responde las siguientes preguntas en 2 minutos o menos, refiriéndose a elementos específicos en el tablero de sprint:

• ¿Qué hiciste ayer?
• ¿Qué planeas hacer hoy?
• ¿Hay algún impedimento que le impida completar su trabajo?

Esto permite que todos vean en qué están trabajando todos, ver qué progreso se está logrando o no, e identificar los impedimentos y/o la ayuda necesaria.

Finalización de Sprint

El Scrum Master facilita dos ceremonias para cerrar el sprint antes de planificar el siguiente sprint.

Demostración de Sprint

Al final del sprint, el Scrum Master facilita una reunión de demostración del sprint donde se demuestra cada historia completa en el software en funcionamiento al propietario del producto y al resto del equipo. El propietario del producto aceptará la historia si se cumplen todos los criterios de aceptación o la rechazará. Si se rechaza una historia, se identifican las deficiencias y la historia se vuelve a colocar en la cartera de productos en su orden de prioridad para completarse más adelante o no completarse. A menudo, las partes de una historia que el propietario del producto no acepta se dividen en historias separadas y se cierra la historia original.

Se calcula el número total de puntos de historia completados por sprint (Velocidad) y se cierra el sprint. La velocidad se usa para rastrear el nivel de producción del equipo y se usa para estimar cuándo se completarán las funciones o los lanzamientos.

Retrospectiva de Sprint

Después de la demostración del sprint, pero antes de la próxima reunión de planificación del sprint, el Scrum Master facilita una retrospectiva del sprint en la que el equipo reflexiona sobre el sprint que acaba de completar y analiza qué salió bien y qué no, para que puedan mejorar el proceso de forma continua e incremental. y calidad a lo largo del tiempo (Kaizen, Hansei). Hay una plétora de formatos retrospectivos o ejercicios que pueden usarse para ayudar al equipo a generar debate.

Se produce una lista de elementos de acción de mejora y, a veces, dan como resultado que se agreguen elementos a la cartera de productos, cambios en el DoD o en el estatuto del equipo, etc.

Gestión de la cartera de productos

Creación de cartera de productos

Antes de que se pueda planificar o ejecutar un sprint, el propietario del producto debe crear una acumulación de trabajo del producto. El backlog generalmente comienza con elementos de desarrollo de características llamados historias escritas por el propietario del producto y, con el tiempo, también se completa con tareas de desarrollo o control de calidad, picos y defectos, etc. potencialmente creados por cualquier miembro del equipo. Todos los elementos de la cartera de pedidos se organizan en orden de prioridad.

Preparación de trabajos pendientes

Una vez que se crea y se prioriza la cartera de productos inicial, el proceso continuo de preparación de la cartera de pedidos se hace cargo. El objetivo es tener siempre, como mínimo, una cantidad suficiente de los principales elementos del backlog preparados y estimados para que estén listos para ser arrastrados a un sprint durante una reunión de planificación de sprint. Por lo general, esto se logra mediante la celebración de reuniones periódicas continuas de preparación del trabajo pendiente con el gerente de producto y el equipo facilitado por el Scrum Master.

Antes de la reunión, se envía una lista de historias al equipo para que puedan revisar y prepararse para la reunión de preparación. En la reunión de preparación, cada elemento se analiza en términos de criterios de aceptación, complejidad, riesgo, tamaño, estrategia de implementación, etc. Los criterios de aceptación y otros detalles de la historia se revisan y revisan hasta que el equipo, el propietario del producto y Scrum Master tener una comprensión común de la historia. En ese punto, la historia se estima en puntos de historia utilizando una técnica llamada póquer de planificación.

Estimación de puntos de historia

Los puntos de historia son una unidad de esfuerzo que utiliza un tamaño relativo donde las historias se comparan con piezas de trabajo anteriores, conocidas y bien entendidas. Siempre estás haciendo la pregunta "¿esta historia es más grande, más pequeña o aproximadamente del mismo tamaño" que cualquier otro trabajo.

La escala de Fibonacci (1, 2, 3, 5, 8, 13, 21…) es la escala más utilizada donde cada incremento es aproximadamente el doble que el anterior (es decir, una historia de cinco puntos es más o menos el doble de grande que la anterior). grande como una historia de tres puntos). En ocasiones se utilizan otras escalas como tallas de camiseta (XS, S, M, L, XL) o incluso de peces (minnow, goldfish, trucha, atún, ballena, etc.). Cualquier escala que te permita comparar el tamaño de algo con respecto a otro funcionará.

Los puntos de historia representan todo el esfuerzo del equipo para implementar una historia, incluido el desarrollo, las pruebas, el diseño y otras tareas misceláneas necesarias para la Definición de Listo. La estimación tiene en cuenta la cantidad de trabajo, la complejidad y el riesgo. Una vez que se determina el tamaño relativo de la historia, se asigna un tamaño en la escala como estimación.

Los equipos se preparan para el proceso de estimación de puntos de la historia estableciendo primero una línea de base para la estimación eligiendo una historia de tamaño "más mediano" que todo el equipo entienda como una historia de referencia. También se eligen algunas historias de referencia adicionales que son más grandes y más pequeñas.

La estimación del punto de la historia se realiza durante las reuniones de preparación y, a veces, durante la planificación del sprint utilizando Planning Poker:

1. Cada miembro del equipo/estimador tiene un juego de cartas.
2. Los elementos pendientes se discuten uno a la vez como se describe anteriormente.
3. Una vez que se ha discutido completamente el artículo, cada estimador elige en privado una tarjeta para representar su estimación.
4. Cuando todos los estimadores han hecho sus estimaciones, revelan sus cartas al mismo tiempo.
   • Si todas las estimaciones coinciden, los estimadores seleccionan otro elemento del backlog y repiten el mismo proceso.
   • Cuando las estimaciones difieren, los estimadores discuten el tema para llegar a un consenso.

Las ventajas de la estimación puntual de la historia son:

• Rápido: las estimaciones son relativas a los elementos de la cartera de productos ya completados.
• Lo suficientemente preciso : lo suficientemente preciso para dar una visión general del alcance, planificar el trabajo futuro, priorizar y gestionar las expectativas.
• Acepta la incertidumbre: los puntos de la historia especifican un rango de tiempo desconocido. Seleccionar de una secuencia específica de puntos de la historia similar a Fibonacci permite capturar la incertidumbre.
• Deporte de equipo: involucra a todos (desarrolladores, diseñadores, control de calidad, gerentes de producto). Utiliza múltiples perspectivas para determinar el tamaño del trabajo, pero solo los miembros del equipo que realizan el trabajo pueden estimar
• Mide la velocidad del equipo: mide cuánto trabajo hace un equipo en un sprint en comparación con la cantidad de tiempo que dedica a realizar el trabajo. A medida que el equipo mejora, completarán historias del mismo tamaño más rápido, lo que resultará en una mayor velocidad de puntos de historia con el tiempo.

Estimación y seguimiento de lanzamientos

La estimación de puntos de historia también se usa en un contexto de planificación de lanzamiento utilizando la siguiente técnica:

1. Enumere todas las historias para ser dimensionadas
2. Ponlas en orden de menor a mayor
   • Tome la primera y la segunda historia de usuario.
   • Decide cuál es más grande y pon el más grande debajo
   • Luego tome el siguiente y decida dónde encaja en relación con los otros dos
   • Repita el proceso hasta que todas las historias estén ahora en la lista (en una secuencia de menor a mayor)
3. Tamaño de las historias

Las estimaciones de historia para todas las historias en un lanzamiento combinadas con la velocidad del equipo le permitirán estimar cuándo se completará un lanzamiento y realizar un seguimiento de su progreso. Esto se muestra a menudo en un gráfico de quemado de liberación.

Los artefactos y términos de Scrum

• Product Backlog: una lista de trabajos pendientes de todos los elementos de trabajo para un producto determinado que puede incluir características (historias), tareas técnicas, picos y defectos
• Release Burn-up: un cuadro gráfico que se usa para mostrar el progreso en un nivel de lanzamiento y para predecir cuándo terminará un lanzamiento usando Sprint Velocity. Los puntos de historia completados se muestran en el eje Y y los sprints se muestran en el eje X.
• Sprint Backlog: una lista de trabajos pendientes de todos los elementos de trabajo que se completarán en un sprint determinado. Los contenidos del Sprint Backlog se acuerdan durante la reunión de planificación del Sprint.
• Scrum Board: un tablero estilo tabla que rastrea el progreso del trabajo comprometido para el sprint. Los estados se muestran en la parte superior en columnas verticales y los elementos de trabajo se mueven a través de cada estado hasta que finalizan. El tablero de scrum se completa durante la reunión de planificación del sprint y se restablece al final de un sprint.
• Sprint Burndown: un cuadro gráfico que muestra la cantidad de trabajo completado y restante medido en puntos de historia a lo largo del sprint. Los puntos de historia restantes se muestran en el eje Y y el tiempo restante se muestra en el eje X.
• Velocidad de sprint: la cantidad de puntos de historia que un equipo Scrum completa en un sprint.
• Impediments Backlog: una lista de impedimentos que el Scrum Master debe abordar para que el equipo pueda continuar trabajando. Cuando un miembro del equipo está bloqueado, agregará un elemento a la acumulación de impedimentos para brindar visibilidad al equipo y al Scrum Master.
• Épica: una épica es una gran cantidad de trabajo que consta de múltiples historias de usuarios relacionadas.
• Historia de usuario: una historia de usuario es una descripción de una función de software desde la perspectiva del usuario final. La historia de usuario describe el tipo de usuario, lo que quiere y por qué. Una historia de usuario ayuda a crear una descripción simplificada de un requisito e incluye criterios de aceptación. Las historias de usuario son creadas y mantenidas por el propietario del producto.
• Tarea: una tarea es un trabajo que ingresa el Scrum Master o un miembro del equipo que puede estar directa o indirectamente relacionado con las historias de los usuarios. Suelen ser de naturaleza técnica e incluirán criterios de aceptación.
• Pico: un pico es un tipo especial de tarea que se usa cuando necesita investigar, crear prototipos y/o diseñar en algún momento antes de poder decidir cómo implementar o estimar una historia de usuario.
• Subtarea: una subtarea es una tarea que se ingresa como un paso de implementación para completar una historia de usuario o una tarea. Por lo general, el equipo los ingresa durante una reunión de planificación de sprint.
• Estimaciones de puntos de historia: una escala de estimación de tamaño relativo que se basa en la escala de Fibonacci (1, 2, 3, 5, 8, 13, 21...)
• Criterios de aceptación: la lista de elementos comprobables y específicos de la historia incluidos en cada historia que deben completarse antes de que el propietario del producto acepte una historia como completada.
• Definición de Terminado (DoD): Una lista de pasos o criterios comunes que deben completarse antes de que cualquier historia pueda considerarse terminada. El equipo está de acuerdo con esto y lo documenta para que no tenga que aparecer en todas las historias.

Ventajas y desventajas de Scrum

La principal ventaja de Scrum es la aplicación de valores y principios ágiles, así como conceptos Lean como Seiri, Jidoka, Just-in-Time, Kaizen, Genchi Genbutsu, Heijunka, Pull System e Iteraciones. Applying these principles allow project teams to receive continuous feedback, quickly adapt to changing requirements and uncertainty, reduce waste, increase visibility and transparency, and strive for continuous improvement. By always focusing on the most important items in the product backlog and only working in short iterations that always produce working software, Scrum is more customer focused and allows customers to see what they like (and don't like) and make changes as needed. The overhead cost in terms of process and management is smaller, thus leading to quicker, cheaper results.

Scrum is a great methodology for projects with requirements that are not clearly known and/or expected to change. This applies to most projects. Scrum is also great for experienced, motivated teams as it allows teams to organize the work themselves and it provides visibility, transparency, and accountability for both progress and problems. All of this will result in teams improving and becoming more productive over time.

Scrum does have some disadvantages and is not the best methodology in some situations:

• Transparency: Scrum increases transparency and accountability which is both an advantage and disadvantage as problems and poor performance within and outside the team and are exposed. This can be uncomfortable and can lead to resistance if not handled properly within the Scrum framework of continuous improvement.
• Team Experience and Commitment: Inexperienced and/or uncommitted Scrum teams or Scrum Masters can cause serious problems through misapplying the Scrum methodology. There are no defined roles in the Scrum team as everyone does everything, so it requires committed team members with technical experience to follow the Scrum process and improve over time. It can also be very detrimental if other parts of the organization are resistant to Scrum.
• Scope Creep: There is a risk of scope creep, especially if there isn't a defined end date as stakeholders are allowed to add to the scope. Being able to change scope and priorities is one of the main advantages of Scrum, but it can also be a disadvantage if discipline isn't used.
• Poorly defined work: Poorly defined and understood user stories or tasks can lead to rework, inaccurate estimates, and scope creep. Although Scrum is focused on working software over documentation, the product owner needs to be clear on what they want and be able to clearly communicate that in conversations and in the user stories.
• Scaling: Adopting the Scrum framework in large teams is challenging as Scrum is meant for smaller teams.

Kanban

What Is Kanban?

Kanban is a lighter weight process that applies many of the Lean and Agile values as well as a subset of the Scrum values and principles but there are also some fundamental differences. Kanban focuses on visualization, flow, and limiting work in progress.

Kanban is Japanese for “signboard” or “billboard.” Toyota line-workers used a kanban (ie, an actual board) to signal extra capacity in various steps in their manufacturing process. In software, this is done with a Kanban board, which is very similar to the Scrum board. There is a prioritized backlog of To Do items and vertical columns for each status that a work item can have. Like Scrum, work items are moved from one status to another; however, in Kanban, the amount of work in progress is strictly limited to a maximum number of items in each status based on team capacity. New work cannot be pulled in until existing work is moved to the next step in the process. In Scrum, work in progress in indirectly limited by controlling the amount of work planned for a sprint.

In Kanban, there are no fixed iterations or sprints, just a constant flow where work items are pulled from one stage to the next. This means that the Kanban board is never reset. It also means that many of the Scrum rituals not used. Kanban teams often have daily standup meetings but they are not prescribed. There are no regularly planned sprint planning meetings, sprint demos or sprint retrospectives, so the process is more lightweight. Some of the activities in those rituals may or may not be performed at an informal level. Continuous improvement is accomplished by tracking and analyzing the flow of items from one state to another and making constant incremental improvements based on what issues are uncovered.

Kanban also doesn't prescribe the roles that Scrum does. The only role needed is the team member role, however, there is often a project manager that manages the team and the backlog. Often a single Kanban board can serve multiple function based roles and/or teams that only work on items in a certain status. For example, a development team might pull items from To Do to In Progress and move them to Testing, and the test team might test items in Testing and move them to Done.

Many of the backlog management activities for prioritizing and grooming of work items still need to be done to ensure that a given work item is well understood and ready to be worked on, however, estimating the work items is prescribed as optional.

Kanban vs. Scrum

The following table compares Scrum and Agile:

Summary: The End of Part 1

In this part, we reviewed a few of the most popular methodologies used for Software Development. By now you should have a good understanding of Lean, Agile, Scrum, and Kanban and their historical roots in Lean Manufacturing and TPS. In the next part of the series, we will continue reviewing and comparing other Software Development methodologies such as Waterfall, JTBD, and SAFe (and other scaling frameworks), as well as hybrid methodologies, so you have all of them conveniently explained in one place.