• Author / Uploaded
• José Luis

Citation preview

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.