Scribd
Cargar
88 vistas2 páginas

Velocidad en Scrum y Mejora Continua

Este documento discute varios aspectos clave de Scrum como marco ágil para el desarrollo de software. Explica que Scrum permite la entrega frecuente de incrementos del producto a través de iteraciones cortas basadas en la colaboración del equipo. También destaca que la estimación de tareas no debe basarse en métricas de tiempo sino en complejidad y riesgo, y que la velocidad del equipo no es una medida adecuada de su productividad o capacidad futura.

Cargado por

José Luis
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
88 vistas2 páginas

Velocidad en Scrum y Mejora Continua

Este documento discute varios aspectos clave de Scrum como marco ágil para el desarrollo de software. Explica que Scrum permite la entrega frecuente de incrementos del producto a través de iteraciones cortas basadas en la colaboración del equipo. También destaca que la estimación de tareas no debe basarse en métricas de tiempo sino en complejidad y riesgo, y que la velocidad del equipo no es una medida adecuada de su productividad o capacidad futura.

Cargado por

José Luis
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

La Velocidad en Scrum

Joel Francia

Scrum se ha convertido en el marco ágil de trabajo más usado en el


desarrollo de software en el mundo. Uno de los beneficios de Scrum es
la entrega de incrementos de producto en periodos de tiempo cortos. El
trabajo se basa en la colaboración y trabajo en equipo. Algunos
aspectos como el descubrimiento, el empirismo y la inspección continua
son claves para lograr un proceso de mejora continua y de innovación
en el producto a construir. Scrum está basado en un proceso de
empírico y sirve para construir productos complejos de forma sostenida.
Empírico significa aprender de la experiencia.

El “Planning Poker” no es una práctica de Scrum. Los "Story Points"


están Basados en tamaño, esfuerzo y complejidad, no representan
horas, minutos, días o cualquier otra métrica que indique duración. Los
"Story Points" son influenciados por el riesgo y la incertidumbre. Tienen
una relación numérica entre sí (Estimación Relativa) y es diferente para
cada equipo. Representan el esfuerzo para terminar un Product Backlog
Item según los criterios de "Terminado". El ejercicio del “Planning Poker”
es fundamentalmente una dinámica de colaboración donde el equipo de
desarrollo aprende mediante la discusión acerca de cómo desarrollar
los PBIs y los supuestos que definen para ello como los criterios de
aceptación y preguntan al Product Owner sobre sus dudas. La
estimación en complejidad es una referencia para que el equipo pueda
tomar decisiones acerca de que ítems podrían requerir más
refinamiento, que ítems tienen más riesgo, que ítems pueden tener
dependencias y que alternativas se tienen, este ejercicio puede afectar
el orden de los ítems en el “Product Backlog” y puede influenciar la
forma en que el equipo define su Sprint Backlog.

Scrum no prescribe una forma de estimación, Scrum se basa en la auto


organización para todo el trabajo que el equipo tiene que lograr para
enfocarse en el objetivo del Sprint.
La velocidad por si sola no necesariamente permite predecir la
capacidad futura de un equipo de desarrollo en los siguientes Sprints.
La velocidad no mide el desempeño pasado de un equipo ya que no
necesariamente refleja la mejora en entrega de valor de negocio ni
mejora continua. Cuando el trabajo es complejo no se debería esperar
que la velocidad sea similar en el tiempo y que ello sirva como
predicción del futuro. Cuando usamos Scrum, siempre debemos
planificar para lo inesperado.

La velocidad tampoco es una medida de productividad. Medir las


mejoras del trabajo en equipo en función de la velocidad puede llevar a
distorsiones en el uso de Scrum y el empirismo. La velocidad no debería
ser normalizada entre varios equipos de Scrum como una métrica para
comparar el rendimiento de diversos equipos de desarrollo. Es peligroso
comparar las velocidades debido a que puede inducir al equipo a
enfocarse en la velocidad y no en mejorar la entrega de valor de
negocio.

Pedirle a un equipo que mejore su productividad mejorando su


velocidad puede provocar que se logré la velocidad esperada
artificialmente, esto es influenciando al equipo para que cambie su
enfoque del objetivo del Sprint y no use los valores de Scrum.

También podría gustarte